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:-
The FTP is using the following options:-
Trace: FALSE, Send Port: TRUESend Site with Put command: TRUEData type:a, Transfer mode:s, Structure:fAutomatic 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 FALSEPrimary allocation 1 track, Secondary allocation 1 track.Partitioned data sets will be created with 27 directory blocksFileType is SEQ (Sequential - the default).Number of access method buffers is 5.Confidence level of data transfers is neither checked nor reportedENcoding is set to SBCSOutbound SBCS ASCII data uses CRLF line terminatorOutbound MBCS ASCII data uses CRLF line terminatorlocal site variable UNICODEFILESYSTEMBOM is set to ASISlocal site variable MBREQUIRELASTEOL is set to TRUElocal site variable REMOVEINBEOF is set to FALSEDBSUB is set to FALSESBSUB is set to FALSESBSUBCHAR is set to SPACERDW's from VB/VBS files are discarded.Records on input tape are unspecified formatDB2 subsystem name is DB2Volid of Migrated Data Sets is MIGRATTrailing 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 0Checkpoint data set will be opened for GETCHKPTPrefix uses Home to determine the HLQ of the FTP.CHECKPOINT file.No automatic mount of tape volumes.CCONNTIME is 40DATACTTIME is 40DCONNTIME is 40INACTTIME is 40MYOPENTIME is 40FTPKEEPALIVE is 0local site variable DATAKEEPALIVE is set to 0local site variable DSWAITTIME is set to 0VCOUNT is 59Prompting: OFF, Globbing: ONASA control characters transferred as ASA control charactersNew data sets catalogued if a store operation terminates abnormallySingle quotes will override the current working directoryUMASK value is 027Data connections for the client are not firewall friendly.local site variable EPSV4 is set to FALSElocal site variable SECUREIMPLICITZOS is set to TRUElocal site variable PASSIVEIGNOREADDR is set to FALSElocal site variable TLSRFCLEVEL is set to DRAFTlocal site variable READVB is set to LElocal site variable EXTDBSCHINESE is set to TRUElocal site variable LISTSUBdir is set to TRUElocal site variable PROGRESS is set to 10local site variable SEQNUMSUPPORT is set to FALSElocal site variable UNIXFILETYPE is set to FILElocal site variable FIFOIOTIME is set to 20local site variable FIFOOPENTIME is set to 60local site variable EATTR is set to SYSTEMlocal site variable DSNTYPE is set to SYSTEMAuthentication mechanism: NoneTape write is not allowed to use BSAM I/OUsing FTP configuration defaults.
Thanks in advance, 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
The CA XCOM Team
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.
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,