An Overview of Using Data Translation in z/OS FTP

Content

I. Why Does FTP Translation Occur?

FTP is a protocol standardized by the Internet Engineering Task Force (IETF), defined by RFC 959. In this RFC, the IETF mandates that, unless otherwise specified, all FTP implementations should transmit data in ASCII. Because many operating systems today are ASCII-based, this requirement has little impact: the FTP implementations can simply send data as it exists on the disk.

z/OS systems, however, are EBCDIC-based. As such, in order to comply with the RFC, the z/OS Communications Server must by default translate EBCDIC to ASCII data when sending a file to a remote system, or translate ASCII data to EBCDIC when receiving a file. This is illustrated as follows:

It is important to note that translation can be performed in two different contexts: for the FTP Control Connection, and for the FTP Data Connection

Translation on the FTP Control Connection
The control connection, which generally occurs across port 21, is the connection over which interactive or batch FTP commands are sent from the FTP client to the FTP server, and over which replies and status messages are sent from the FTP server to the FTP client. For example, all of the following interactions would be sent over the control connection:




RFC 959 dictates that these control messages be exchanged in ASCII, but only by default. As such, individual implementations can opt to have messages exchanged in non-ASCII codesets. However, the remote client or server must also be using this same codepage. Though possible, this is not common, and most variations in data translation occur on the data connection.


Translation on the Data Connection
The data connection, which generally occurs across port 20, is the connection over which data constituting a file or dataset is sent. The important distinction between control connection data and data connection data is that control connection data is used only for managing the FTP session itself. Data connection data is what the FTP session is intended to transfer between two hosts. One exception to this is the output of list (LS) or directory (DIR) commands. In this case, the data returned in response to these commands is treated like file data and is transferred via a data connection.

In the case of a data connection, FTP translation occurs between the point at which the FTP implementation sends or receives the data, and the point at which the data is read or written from the disk. For example, if an FTP implementation is receiving data, the following steps must occur:
1. The TCP/IP stack receives data on the port.
2. TCP/IP passes the data to FTP.
3. FTP translates the data using translation tables or ICONV (see How FTP Translation Occurs, below).
4. FTP writes the data to the disk.

Conversely, if FTP is sending data, the process is reversed:
1. FTP reads data from the disk.
2. FTP translates the data using tables or ICONV.
3. FTP passes the data to TCP/IP.
4. The TCP/IP stack sends the data out from the port.

A code set, also called a code page or character set, is a mapping of human-readable text to the string of bits used to store that text on disk media. A common misconception is that a single code set contains the information needed to translate data. This is only half correct. Translation is done from one code set to another. As such, a translation utility must know the information contained in both code sets, and how the characters in one code set map to the other.

To better explain this, consider ASCII encoding. A common ASCII code set is ISO 8859-1. This code set indicates that the character B should be stored on disk as the bitstring b'01000010'. This is more easily represented in it's hexadecimal form, x'42'. However, using the EBCDIC 1047 code set, this B would be stored as bitstring b'11000010', or x'C2'. Thus, imagine a file containing a single character B residing on an ASCII-based PC. When we FTP this file to an MVS dataset, FTP will translate the data as depicted in the following illustration:

The above example illustrates the concept behind single-byte character sets (SBCS), which can accommodate up to 255 characters. While this is sufficient for most data needs in Europe and the Americas, this does not provide enough characters to accommodate languages with more than 255 characters, such as Chinese or Japanese. To resolve this, a second type of code set exists, called multi-byte character sets (MBCS).

Multi-byte character sets use two (or more) bytes per character, allowing the code set to represent a far greater number of characters. An example of this is UTF-8, which is a variable length character encoding representing each character using one to four bytes. z/OS Communications server provides numerous multi-byte character sets, including languages such as Japanese Kanji, Traditional Chinese, and Simplified Chinese.

In the z/OS Communications Server implementation, FTP uses two methods when translating data: translation tables and the ICONV utility.

Translation using tables
The first method is through the use of a translation table, which maps how ASCII encoding should be converted to EBCDIC, and how EBCDIC encoding should be converted to ASCII. The source data for single-byte tables shipped with the z/OS Communications Server product can be found in the SEZATCPX partitioned dataset. Examples of some of the members include:
AUSGER (7-bit ASCII <-> IBM 273)
BELGIAN (7-bit ASCII <-> IBM 500)
CANADIAN (7-bit ASCII <-> IBM 037)
DANNOR (7-bit ASCII <-> IBM 277)
EAUSGER (7-bit ASCII <-> IBM 858-1141)
EBELGIAN (7-bit ASCII <-> IBM 858-1148)
ECANADIA (7-bit ASCII <-> IBM 858-1140)
Additionally, multi-byte tables can be found in the SEZADBCX partitioned dataset, and includes members
EZACHLAT
EZAHGLAT
EZAKJLAT
EZAKJ941
EZASCLAT
When FTP attempts to translate data but can find no translation table, it uses an internally coded mapping corresponding to the table listed in the STANDARD member. This mapping translates between the 7-bit ASCII and EBCDIC 1047 code sets. The contents of STANDARD member are:



An example of how these tables are used can be seen in converting the ASCII character B to the EBCDIC character B. In ASCII, B is encoded using hexadecimal digits x'42'. Using the ASCII-to-EBCDIC table above, we see that row 40 and column 02 converge on the value x'C2', which is the hexadecimal encoding for an EBCDIC B. Similarly, using the EBCDIC-to-ASCII table, we see that row C0 and column 02 converge back to the value correct x'42' ASCII valur for B.

To use these tables, the source data member must be compiled using the CONVXLAT command, which produces a binary table used by FTP. This table can then be placed into FTP's search hierarchy, and will be used by FTP when translating the data. The search hierarchies for the FTP server and client can be found in the z/OS Communications Server IP Configuration Reference.

Translating through ICONV
The z/OS UNIX shell provides a command line utility, called ICONV, which provides translation capabilities between different code sets (see What is a Code set, above). More importantly, ICONV provides an interface for applications, such as FTP, to invoke the utility. FTP does this whenever it has been configured with certain SBDATACONN or MBDATACONN values, or if the SITE/LOCSITE SBDATACONN or MBDATACONN command has been issued to specify code sets. This is discussed at greater length in How can I change my code set?, below.

The list of translations available through ICONV are listed in Appendix D.b

When a user or implementation wishes to send data across the control connection using something other than 7-bit ASCII, the connection can be customized dynamically using FTP commands, or statically using FTP.DATA statements. There are numerous statements which can be used, but the primary--and preferred--configuration is the CTRLCONN statement. This statement instructs the client or server which ASCII codepage to use in translating FTP commands and replies, and can be coded in any of the following manners:


CTRLCONN 7BIT
This tells the client or server to use the default 7-bit ASCII translation


CTRLCONN iconv_ascii
This tells the client or server to use the ICONV utility to translate the data using the specified standardized ASCII codepage. For example, to instruct FTP to send messages on the control connection using the Canadian French PC code set, the statement CTRLCONN IBM-863 can be configured in the FTP.DATA file. A complete list of supported code sets and their IBM designation can be found in Appendix C.


CTRLCONN FTP_STANDARD_TABLE
This tells the client or server to use the internal translation tables built into FTP.

For temporary or session-specific changes in control connection code sets, it is often easier to use the SITE or LOCSITE command to specify the CTRLCONN configuration.

While controlling the code set used on the FTP control connection is a useful functionality, the need to control translation is much more common for the data connection. This is discussed in detail in the next section.

Note that, unlike with data translated on the control connection, translating data on the data connection requires specifying two code pages. This is because the z/OS FTP server and client message catalogues are encoded using EBCDIC. Thus, for the control connection, only the other code page in the pair needs to be identified. With a data transfer, however, the data may be encoded using any number of code pages. As such, both code pages in the pair must be identified.

As noted previously, if no action is taken to specify a particular pair of code sets to be used in translation, FTP will assume that network data is 7-bit ASCII, and that it is to be translated to EBCDIC 1047. If the network data truly is 7-bit ASCII, this implementation works as expected. However, if the network data is not 7-bit ASCII, this will be sufficient for most characters (A-Z, a-z, 0-9, etc.), but there are some characters which this default does not handle properly.

For example, assume that the network data is encoded using the ISO 8859-1 code set, which is very common. Because ISO 8859-1 is 8-bit, there are some characters in the code set which cannot be represented by 7-bit ASCII. As a result, when FTP uses the standard tables, erroneous translation may occur for characters that 7-bit ASCII cannot accommodate. Additionally, some of the 8-bit EBCDIC characters cannot be translated into 7-bit ASCII. Examples of these occurrences include:

• An ISO 8859-1 Â will be translated to an EBCDIC 1047 B
• An EBCDIC 1047 ö will be translated to an ISO 8859-1 ¾.

In such cases where translation other than the 7-bit default is needed, FTP users must intervene and explicitly tell FTP what code set translation should be used. There are several ways to do this.


Using Translation Tables with SBCS Data
One way, discussed previously, is to use CONVXLAT to compile one of the tables provided in SEZATCPX or SEZADBCX partitioned datasets into a binary translator. This also allows custom translation tables to be implemented. A user with a specific translation need that is not addressed by an existing table can change one of the source tables as needed. Upon compiling the table, the resulting binary translator will reflect the user's change.

As an example, let us assume that a user wishes to use the SEZATCPX(US) translation table. Note that this table effectively provides translation between code sets ISO 8859-1 and IBM-037. The format of the CONVXLAT command is:


CONVXLAT source_table binary_table


To compile the desired table and name it USER1.US.TCPXLBIN, the user can issue the following command:


CONVXLATE 'HLQ.SEZATCPX(US)' 'USER1.US.TCPXLBIN'


Had the name of the resulting binary table been in the FTP search hierarchy (listed in Appendix A), FTP would use this table in every FTP transfer for this user. However, because it is not, the user must specifically direct FTP to use this table. A series of commands exist which the user can specify during an FTP session. This way, the desired translation can be implemented without affecting other FTP sessions which might use the same FTP.DATA configuration file.


SITE ENCODING=SBCS SBDATACONN=dsname
This command is used when transferring single-byte data to or from a z/OS CommServer FTP server. It tells the remote FTP server to use the dsnamedataset for single-byte data translation. Note that the dataset must exist on the server's system, not the client's. SBCS is the default value for ENCODING, and thus the ENCODING=SBCS string may not be needed as part of the command. This can also be set up for use at FTP server initialization by including the following statements in the FTP.DATA file being used by the server:
ENCODING=SBCS
SBDATACONN=dsname

LOCSITE ENCODING=SBCS SBDATACONN=dsname
This command is used when transferring single-byte data using the z/OS FTP client. In this case, the dsname translation table must reside locally on the client's system. Again, because SBCS is the default value for ENCODING, the ENCODING=SBCS string may not be needed as part of the command. Similarly, this can be set up for use at FTP client initialization by encoding the following statements in the FTP.DATA file being used by the client:
ENCODING=SBCS
SBDATACONN=dsname

In our example, after compiling the source data into a binary table, our user could FTP to the z/OS FTP server and issue the following command:


SITE SBDATACONN='USER1.US.TCPXLBIN'


Any subsequent data transfers for this FTP session would be translated using that particular table.

NOTE: The SITE/LOCSITE XLATE command performs the same function as the SBDATACONN command. Its syntax is the same, an example being:

SITE XLATE='USER1.US.TCPXLBIN'

An asterisk (*) can also be supplied, indicating that the translation table identified at initialization should be used. However, the preferred method is the newer SBDATACONN command.

Using Translation Tables with MBCS Data
Specifying multi-byte translation tables is slightly different than specifying SBCS tables. A series of steps must be taken to implement multi-byte transfers.
1. Similar to compiling SBCS tables, CONVXLAT is used to compile the source datasets found in SEZADBCX into binary tables. The syntax of this command is nearly the same for both multi-byte and single-byte tables, with the addition of an option for MBCS tables.
CONVXLAT source_table binary_table (option
The option used will depend on the MBCS table being compiled, and are listed in the table below:

The binary MBCS table produced by the CONVXLAT command must reside with in the search hierarchy, discussed in Appendix B.

2. With the table in place, the LOADDBCSTABLES configuration statement must be specified in the TCP.DATA file used by the FTP client or server. The syntax of this statement is

LOADDBCSTABLES option1 option2 option3...
Multiple options can be specified on one statement, and multiple statements can exist in one TCP.DATA file. The options specified indicate which MBCS tables FTP is allowed to load. The options which can be configured are the same as those specified on the CONVXLAT command, listed in the table above.

3. Before a table can be specified, the user has to tell FTP that multi-byte data translation is desired. This is done using one of the following commands:

SITE ENCODING=MBCS
This is used when the data is being transferred to or from a z/OS FTP server. The ENCODING parameter can also be specified in the FTP server's FTP.DATA files.
LOCSITE ENCODING=MBCS
This is used when the data is being transferred using the z/OS FTP client. The ENCODING parameter can also be specified in the FTP client's FTP.DATA file.

4. With the table in place, the LOADDBCSTABLES correctly configured, and the encoding set to MBCS, an FTP user can use various commands to indicated that data translation should use a specific table. Each commands corresponds to a specific TYPE command, and can provide information regarding the Shift-In Shift-Out (SOSI) characters FTP can use to determine when double-byte translation should be performed. The following table lists the types of translations which may be desired, the FTP subcommand which can be issued to invoke that translation, and the alternate TYPE commands which correspond to the subcommands.

Using ICONV
Translating data using ICONV simplifies the process significantly. There is no need to compile tables, enact special configurations, or hassle with multiple FTP subcommands. Instead, only one of four commands is needed, and the user only has to know what two code sets are to be used in the translation. Conveniently, the four commands are actually the SITE/LOCSITE SBDATACONN/MBDATACONN commands already discussed. However, instead of specifying the translation tables to be used, the two code sets are indicated. The commands are as follows:


SITE ENCODING=SBCS SBDATACONN=(file_system_codeset, network_codeset)

LOCSITE ENCODING=SBCS SBDATACONN=(file_system_codeset, network_codeset)

SITE ENCODING=MBCS MBDATACONN=(file_system_codeset, network_codeset)

LOCSITE ENCODING=MBCS MBDATACONN=(file_system_codeset, network_codeset)

In these commands, the file_system_codeset is the code set of the data as it resides (or will reside) on the disk. The network_codeset is the code set in which the data will be transferred. As noted previously, the ENCODING and SBDATACONN statements can be specified in the FTP.DATA files of both the client and server if these parameters are to be used by default. Similarly, the MBDATACONN can be configured here as well.

As an example, let us first examine our user's previous transfer in which the SEZATCPX(US) translation table was used. As noted previously, this table maps values between the ISO 8859-1 code set and the IBM 037 code set. Let us further assume that the user is on an ASCII-based workstation, and wishes to transfer the file to the z/OS mainframe such that the data will be stored there using the IBM 037 code set. To do this, the user can simply execute the following subcommand:
SITE SBDATACONN=(IBM-037,ISO8859-1)
Again, the ENCODING=SBCS is not necessarily required on this command, as SBCS is the default value. Intuitively, one might think that the user could retrieve IBM 037 data from the z/OS mainframe to the workstation simply by swapping the two code sets (SBDATACONN=(ISO8859-1,IBM-037)). However, this is not the case. Because in both cases the data resides on the z/OS mainframe in the IBM 037 encoding, the file_system_codeset will be IBM-037 each time. Similarly, because the data is to be transferred in ISO 8859-1 code set in both cases, the network_codeset will be IOS8859-1 each time.

The same is true for a user who implements the z/OS FTP client to transfer data to or from a remote ASCII based server. In fact, the only difference is that the SITE keyword is replaced by the LOCSITE keyword. In both instances, the file_system_codeset and network_codeset remain the same:
LOCSITE SBDATACONN=(IBM-037,ISO8859-1)
The same concepts are applied to the use of ICONV for multi-byte data. The only requirement is that the SITE or LOCSITE command should also include the ENCODING parameter in order to indicate that the transfer is for multi-byte data.

For example, consider the BIG5 FTP subcommand. As noted in the table above, this implements the TYPE B 8 transfer. Effectively, this translates between file_system_codeset IBM-937 and network_codeset IBM-950. As such, the process of compiling a table, configuring LOADDBCSTABLES, issuing a SITE ENCODING command, and then issuing the BIG5 FTP subcommand can be circumvented using the following:
SITE ENCODING=MBCS MBDATACONN=(IBM-937,IBM-950)


A Word About the SITE Command
Not every FTP client supports the SITE and LOCSITE commands. Obviously, when using the z/OS FTP Client, then this is a moot point as the client does in fact use this implementation. However, when FTPing to a z/OS server from a non-z/OS client, that client may not allow the use of site commands. A prime example of this is the DOS FTP client. So what can a user do when he or she needs to FTP data that requires alternate translation mechanisms?

The answer is the QUOTE option. This is an RFC-architected command, so every RFC-compliant FTP client will honor it. The command essentially tells the client "pay no attention to the command I am executing. Simply pass it to the FTP server exactly as I give it to you."

For example, imagine FTPing to a z/OS FTP server from a DOS-based machine to transfer a file which contains special characters that will not be correctly translated by the standard 7-bit ASCII-to-EBCDIC translations. Instead, the data needs to be transferred with a file system code set of IBM 037, and a network code set of ISO 8859-1. This can be achieved through the DOS FTP client using the following command:

QUOTE SITE SBDATACONN=(IBM-037,ISO8859-1)


The command which will be sent to the FTP server is:

SITE SBDATACONN=(IBM-037,ISO8859-1)


and the DOS FTP client will never be the wiser

As noted previously throughout this document, several code sets are commonly used. ISO 8859-1, IBM 1047, and IBM 037 are examples. Given their ubiquitous nature, the encoding for these code sets (in hexadecimal) are included below (grayed areas indicate control or non-printable characters).

While some of these obviously lend themselves to particular implementations, others may vary only slightly, making them hard to distinguish from one another. For example, ISO 8859-1, comprised mostly of text, lends itself to encoding readable data. Additionally, IBM 437 and PC 850 contain numerous graphics and symbols, making these code sets useful for encoding graphical data. However, note that the IBM 037, 500, and 1047 code sets vary only slightly, primarily in the encodings of the [, ], |, ¨, and Ý characters. As such, the need to distinguish between these will be based primarily on application needs.

COMMON ASCII-BASED CODE SETS
ISO 8859-1

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

1x

2x

SP

!

"

#

$

%

&

'

(

)

*

+

,

-

.

/

3x

0

1

2

3

4

5

6

7

8

9

:

;

<

=

>

?

4x

@

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

5x

P

Q

R

S

T

U

V

W

X

Y

Z

[

\

]

^

_

6x

`

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

7x

p

q

r

s

t

u

v

w

x

y

z

{

|

}

~

8x

9x

Ax

nb-sp

¡

¢

£

¤

¥

¦

§

¨

©

ª

«

¬

shy

®

¯

Bx

°

±

²

³

´

µ

¶

·

¸

¹

º

»

¼

½

¾

¿

Cx

À

Á

Â

Ã

Ä

Å

Æ

Ç

È

É

Ê

Ë

Ì

Í

Î

Ï

Dx

Ð

Ñ

Ò

Ó

Ô

Õ

Ö

×

Ø

Ù

Ú

Û

Ü

Ý

Þ

ß

Ex

à

á

â

ã

ä

å

æ

ç

è

é

ê

ë

ì

í

î

ï

Fx

ð

ñ

ò

ó

ô

õ

ö

÷

ø

ù

ú

û

ü

ý

þ

ÿ


IBM 437

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

null

(

)

!

"

#

$

•

3

F

4

%

&

*

+

'

1x

4

3

q

.

¶

§

,

q

m

o

t

r

Ö

v

5

6

2x

!

"

#

$

%

&

'

(

)

*

+

,

-

.

/

3x

0

1

2

3

4

5

6

7

8

9

:

;

<

=

>

?

4x

@

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

5x

P

Q

R

S

T

U

V

W

X

Y

Z

[

\

]

^

_

6x

`

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

7x

p

q

r

s

t

u

v

w

x

y

z

{

|

}

~

-

8x

Ç

ü

é

â

ä

à

å

ç

ê

ë

è

ï

î

ì

Ä

Å

9x

É

æ

Æ

ô

ö

ò

û

ù

ÿ

Ö

Ü

ø

£

Ø

×

ƒ

Ax

á

í

ó

ú

ñ

Ñ

ª

º

¿

¬

¬

½

¼

¡

«

»

Bx

!

"

#

*

1

I

M

D

@

<

5

7

8

E

A

,

Cx

.

0

2

/

)

3

G

K

9

6

;

=

:

4

>

N

Dx

J

L

H

F

B

?

C

O

P

-

+

$

(

%

'

&

Ex

a

b

G

o

S

r

l

t

F

Q

W

d

z

w

e

3

Fx

h

±

m

[

ó

õ

÷

l

°

·

·

Å

n

²

Ò


PC 850

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

null

(

)

!

"

#

$

•

3

F

4

%

&

*

+

'

1x

4

3

q

.

¶

§

,

q

m

o

t

r

Ö

v

5

6

2x

!

"

#

$

%

&

'

(

)

*

+

,

-

.

/

3x

0

1

2

3

4

5

6

7

8

9

:

;

<

=

>

?

4x

@

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

5x

P

Q

R

S

T

U

V

W

X

Y

Z

[

\

]

^

_

6x

`

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

7x

p

q

r

s

t

u

v

w

x

y

z

{

|

}

~

-

8x

Ç

ü

é

â

ä

à

å

ç

ê

ë

è

ï

î

ì

Ä

Å

9x

É

æ

Æ

ô

ö

ò

û

ù

ÿ

Ö

Ü

ø

£

Ø

×

ƒ

Ax

á

í

ó

ú

ñ

Ñ

ª

º

¿

¬

¬

½

¼

¡

«

»

Bx

!

"

#

*

1

Á

Â

À

©

<

5

7

8

¢

¥

,

Cx

.

0

2

/

)

3

ã

Ã

9

6

;

=

:

4

>

¤

Dx

ð

Ð

Ê

Ë

È

i

Í

Î

Ï

-

+

$

(

|

&

Ex

a

b

G

o

S

r

l

t

F

Q

W

d

z

w

e

3

Fx

±

_

¾

¶

§

÷

¸

°

¨

·

¹

³

ý

þ

ÿ


COMMON EBCDIC-BASED CODE SETS
IBM 037

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

1x

2x

3x

4x

SP

nb-sp

â

ä

à

á

ã

å

ç

ñ

¢

.

<

(

+

!

5x

&

é

ê

ë

è

í

î

ï

ì

ß

!

$

*

)

;

¬

6x

-

/

Â

Ä

À

Á

Ã

Å

Ç

Ñ

¦

,

%

_

>

?

7x

ø

É

Ê

Ë

È

Í

Î

Ï

Ì

`

:

#

@

'

=

"

8x

Ø

a

b

c

d

e

f

g

h

i

«

»

ð

ý

þ

±

9x

°

j

k

l

m

n

o

p

q

r

ª

º

æ

¸

Æ

¤

Ax

µ

~

s

t

u

v

w

x

y

z

¡

¿

Ð

Ý

Þ

®

Bx

^

£

¥

·

©

§

¶

¼

½

¾

[

]

¯

¨

´

×

Cx

{

A

B

C

D

E

F

G

H

I

shy

ô

ö

ò

ó

õ

Dx

}

J

K

L

M

N

O

P

Q

R

¹

û

ü

ù

ú

ÿ

Ex

\

÷

S

T

U

V

W

X

Y

Z

²

Ô

Ö

Ò

Ó

Õ

Fx

0

1

2

3

4

5

6

7

8

9

³

Û

Ü

Ù

Ú


IBM 500

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

1x

2x

3x

4x

SP

nb-sp

â

ä

à

á

ã

å

ç

ñ

[

.

<

(

+

!

5x

&

é

ê

ë

è

í

î

ï

ì

ß

]

$

*

)

;

^

6x

-

/

Â

Ä

À

Á

Ã

Å

Ç

Ñ

¦

,

%

_

>

?

7x

ø

É

Ê

Ë

È

Í

Î

Ï

Ì

`

:

#

@

'

=

"

8x

Ø

a

b

c

d

e

f

g

h

i

«

»

ð

ý

þ

±

9x

°

j

k

l

m

n

o

p

q

r

ª

º

æ

¸

Æ

¤

Ax

µ

~

s

t

u

v

w

x

y

z

¡

¿

Ð

Ý

Þ

®

Bx

¢

£

¥

·

©

§

¶

¼

½

¾

¬

|

¯

¨

´

×

Cx

{

A

B

C

D

E

F

G

H

I

shy

ô

ö

ò

ó

õ

Dx

}

J

K

L

M

N

O

P

Q

R

¹

û

ü

ù

ú

ÿ

Ex

\

÷

S

T

U

V

W

X

Y

Z

²

Ô

Ö

Ò

Ó

Õ

Fx

0

1

2

3

4

5

6

7

8

9

³

Û

Ü

Ù

Ú


IBM 1047

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

xA

xB

xC

xD

xE

xF

0x

1x

2x

3x

4x

SP

â

ä

à

á

ã

å

ç

ñ

¢

.

<

(

+

!

5x

&

é

ê

ë

è

í

î

ï

ì

ß

!

$

*

)

;

^

6x

-

/

Â

Ä

À

Á

Ã

Å

Ç

Ñ

¦

,

%

_

>

?

7x

ø

É

Ê

Ë

È

Í

Î

Ï

Ì

`

:

#

@

'

=

"

8x

Ø

a

b

c

d

e

f

g

h

i

«

»

ð

ý

þ

±

9x

°

j

k

l

m

n

o

p

q

r

ª

º

æ

¸

Æ

¤

Ax

µ

~

s

t

u

v

w

x

y

z

¡

¿

Ð

[

Þ

®

Bx

¬

£

¥

·

©

§

¶

¼

½

¾

Ý

¨

¯

]

´

×

Cx

{

A

B

C

D

E

F

G

H

I

shy

ô

ö

ò

ó

õ

Dx

}

J

K

L

M

N

O

P

Q

R

¹

û

ü

ù

ú

ÿ

Ex

\

÷

S

T

U

V

W

X

Y

Z

²

Ô

Ö

Ò

Ó

Õ

Fx

0

1

2

3

4

5

6

7

8

9

³

Û

Ü

Ù

Ú


Appendix C contains a list of some of the code pages, and the languages or implementations for which they can be primarily used.

FTP CLIENT:
1. Data set specified in the SBDATACONN configuration statement in FTP.DATA
2. Data set specified in the SBTRANS configuration statement in FTP.DATA
3. user_id.FTP.TCPXLBIN
4. hlq.FTP.TCPXLBIN
5. user_id.STANDARD.TCPXLBIN
6. hlq.STANDARD.TCPXLBIN
7. The same translation tables established for the control connection
8. FTP internal 7-bit tables

FTP SERVER:
1. Data set specified with DD: SYSFTSX in the FTP start procedure
2. Data set specified in the SBDATACONN configuration statement in FTP.DATA
3. Data set specified in the XLATE configuration statement in FTP.DATA
4. jobname.SRVRFTP.TCPXLBIN
5. hlq.SRVRFTP.TCPXLBIN
6. jobname.STANDARD.TCPXLBIN
7. hlq.STANDARD.TCPXLBIN
8. The same translation tables established for the control connection
9. FTP internal 7-bit tables

Search hierarchies for DBCS tables differ from SBCS in that each code set has it's own search order. However, each search order follows the same pattern, described as follows:

FTP Client
1. user_id.FTP.codeSetIdentifier
2. hlq.FTP.codeSetIdentifier
3. user_id.STANDARD.codeSetIdentifier
4. hlq.STANDARD.codeSetIdentifier

FTP Server
1. jobname.SRVRFTP.codeSetIdentifier
2. hlq.SRVRFTP.codeSetIdentifier
3. jobname.STANDARD.codeSetIdentifier
4. hlq.STANDARD.codeSetIdentifier

The italicized fields are summarized as follows:

user_id	The user_id of the of the FTP user (such as user33)
jobname	The FTP server's jobname (such as FTPD1)
hlq	The system's high level qualifier
codeSetIdentifier	The particular code page which has been requested by an FTP command. These are as follows: Hangeul............TCPHGBIN Kanji.................TCPKJBIN SChinese...........TCPSCBIN TChinese...........TCPCHBIN