XCOM to FTP question

[Neil Rogers]

Hi, apologies in advance if I am posting this in the wrong forum! I am a new user of the CA site and of CA products. The issue I have relates to XCOM v11.5 running on Z/OS 1.13 we currently run an XCOM job on the mainframe and it sends a file containing customer names and addresses onto a windows server running Microsoft Windows Server 2003 (32-bit). The file in question contains addresses of residents in French/Spanish addresses, the data is coming across to the windows server and there are special characters such as a spanish "í" which when transferred to the windows server and opened up using ultra  edit (Version 11.10a+1) shows that the character is represented by a hex code of 62 and the character now looks like the letter "b". What we are trying to do is move this particular transfer onto FTP. However when the same file is transferred using FTP from the mainframe we open up the same file on the windows server (again using ultra edit) and the same character is now represented by a hex code 8D and the character is displayed as a space. I have tried various locsite commands on the IBM mainframe to stop FTP from "manipulating" the data however to no avail. If anyone has any suggestions as how to FTP the file without FTP changing the data that would be great.

 

The XCOM is sending using the options below:-

 

TYPE=SEND

DROPSESS=YES

COMPRESS=LZSMALL

FILEOPT=REPLACE

CKPT=0

FILETYPE=FILE

 

The FTP is using the following options:-

 

Trace: FALSE, Send Port: TRUE
Send Site with Put command: TRUE
Data type:a, Transfer mode:s, Structure:f
Automatic recall of migrated data sets.
Automatic mount of direct access volumes.
Data set mode. (Do not treat each qualifier as a directory.)
ISPFSTATS is set to FALSE
Primary allocation 1 track, Secondary allocation 1 track.
Partitioned data sets will be created with 27 directory blocks
FileType is SEQ (Sequential - the default).
Number of access method buffers is 5.
Confidence level of data transfers is neither checked nor reported
ENcoding is set to SBCS
Outbound SBCS ASCII data uses CRLF line terminator
Outbound MBCS ASCII data uses CRLF line terminator
local site variable UNICODEFILESYSTEMBOM is set to ASIS
local site variable MBREQUIRELASTEOL is set to TRUE
local site variable REMOVEINBEOF is set to FALSE
DBSUB is set to FALSE
SBSUB is set to FALSE
SBSUBCHAR is set to SPACE
RDW's from VB/VBS files are discarded.
Records on input tape are unspecified format
DB2 subsystem name is DB2
Volid of Migrated Data Sets is MIGRAT
Trailing blanks in records read from RECFM F datasets are discarded.
Record format: VB, Lrecl: 256, Blocksize: 6233.
Data not wrapped into next record.
Truncated records will not be treated as an error.
Checkpoint interval is 0
Checkpoint data set will be opened for GET
CHKPTPrefix uses Home to determine the HLQ of the FTP.CHECKPOINT file.
No automatic mount of tape volumes.
CCONNTIME is 40
DATACTTIME is 40
DCONNTIME is 40
INACTTIME is 40
MYOPENTIME is 40
FTPKEEPALIVE is 0
local site variable DATAKEEPALIVE is set to 0
local site variable DSWAITTIME is set to 0
VCOUNT is 59
Prompting: OFF, Globbing: ON
ASA control characters transferred as ASA control characters
New data sets catalogued if a store operation terminates abnormally
Single quotes will override the current working directory
UMASK value is 027
Data connections for the client are not firewall friendly.
local site variable EPSV4 is set to FALSE
local site variable SECUREIMPLICITZOS is set to TRUE
local site variable PASSIVEIGNOREADDR is set to FALSE
local site variable TLSRFCLEVEL is set to DRAFT
local site variable READVB is set to LE
local site variable EXTDBSCHINESE is set to TRUE
local site variable LISTSUBdir is set to TRUE
local site variable PROGRESS is set to 10
local site variable SEQNUMSUPPORT is set to FALSE
local site variable UNIXFILETYPE is set to FILE
local site variable FIFOIOTIME is set to 20
local site variable FIFOOPENTIME is set to 60
local site variable EATTR is set to SYSTEM
local site variable DSNTYPE is set to SYSTEM
Authentication mechanism: None
Tape write is not allowed to use BSAM I/O
Using FTP configuration defaults.

 

Thanks in advance, Neil.

[Kenneth Vollmer]

 

  Hello Neil,

               I don’t know how you can accomplish this translation issue with FTP, but I can tell you how you can address this with CA XCOM. From your inquiry, we noticed that the CODE= parameter, which identifies the type of transfer data, was not provided in your XCOM list of transfer options.  The default for the CODE parameter on z/OS is EBCDIC. From this we are going to assume that a value of EBCDIC was used and that an EBCDIC to ASCII translation was performed on Windows.

Note: the receiving system is responsible for performing any necessary conversion.

CA XCOM Data Transport performs the EBCDIC to ASCII translation in the following manner:

When an EBCDIC code 0 is received, CA XCOM Data Transport substitutes the ASCII value from the first line (line 1) of the table; for EBCDIC code 1, CA XCOM Data Transport takes the value from the second line (line 2), and so on. Because the first line is for code 0, it is necessary to add 1 to the line number when determining which line of the table to modify.

Note: CODE=BINARY Indicates that the transferred data are coded in binary format. For example, a binary file, such as an executable file, is being transferred and indicates to a remote system not to translate the data it is exchanging with your system.

Also note that the CA XCOM r11.6 versions also support Unicode file translation based on the UTF8/16 encoding.

For further details please refer to the CA XCOM™ Data Transport® for Windows Server/Professional User Guide r11.5 Chapter 2: The Command Line Interface: Create Custom Character Sets for File Conversion, which can be found on support.ca.com   or contact CA XCOM Support 

 

Regards,

The CA XCOM Team

 

 

[Neil Rogers]

Hi Kenneth, thank you for your speedy response! I suspected that the route I would need to go down would be the custom character set route. Thank you for confirming this! it looks like you have got it covered in the 11.6 release of XCOM with the use of unicode......  I have passed this information on to the relevant developer at our site.

 

Kind regards, Neil.

[benamiy]

Hello Neil,

We are having this type of challenge routinely, translating the Hebrew alphabeth from EBCDIC in the mainframe to ASCII in the Windows server. What we do is, we use the translation tables that are supplied with XCOM for Windows (on c:\xcomnt\config\convtab). We create a new pair of tables (E to A, A to E), and there, we substitute the hex representations of the Hebrew characters.

I'd assume you need to do the same for data that contains special Spanish and French characters (with tildas, accents, circumflexes and all). For each of these characters, you need to find out the hexa representation in EBCDIC and the hexa representation in ASCII, and update both tables accordingly. Finally, code the CODETBL= parameter in the mainframe job, to indicate that a translation table other than the default is to be used (the default table is coded in xcom.glb on the Windows server).

Hope this helps,

Yohai