PC/Mainframe File Transfer
By Ron Merrell
PC control characters, usually a carriage return (CR) and a line feed (LF). If you have a Cobol source line that has a sequence number of 000001 and an asterisk in column 7 followed by 73 spaces, its hex representation on the mainframe would be X’F0F0F0F0F0F15C404040.....40’ out to 80 positions (get your old "yellow" cards out). When that is translated from EBCDIC to ASCII and transferred to the PC, it will be X’3030303030312A0D0A’ and only occupy 9 positions (bytes). That is because the trailing blanks are truncated and replaced with a CR and LF. When transferred back up to the mainframe, the opposite happens in that the CR and LF are stripped and the remaining positions are blank-filled.
"To CR/LF or not to CR/LF"
Any time you are transferring text (not binary data), you will want to either add or remove the CR and LF depending on whether you are receiving from the mainframe or sending to the mainframe. Text is not the area of confusion for most people. The confusion is when wanting to transfer a data file. In general, you should always transfer data files as "binary" and never add or remove CR and LF’s. Two reasons you typically want to transfer data files to the PC are 1) so you can transfer the same file to another mainframe, or 2) so you can test on the PC using Realia Cobol (the same is true for MicroFocus Cobol) with the EBCDIC file option. Assume we have a small record with three fields. Also assume field 1 is a 5-character name, field 2 is a 4 byte pack-signed (7-digit) number, and field 3 is a 2-byte binary number (digits from 1 to 65,535 not signed). A sample EBCDIC record containing "RON" in field 1, -310 in field 2, and 2624 in field 3 would look like this in hex:
X’D9D6D540400000310D0A40’
Notice that the last byte of the packed signed field is X’0D’ and the first byte of the binary field is a X’0A’. Together they just happen to make up the CR and LF. If you told your system to transfer this file to the PC and remove CR and LF’s, those two bytes would be removed during the transfer and the record would be garbage. This is not just a coincidence that would be considered rare (although even a rare occurrence would be disastrous). There are many hex control codes other than the CR and LF that either would be translated wrong or cause other errors in the data. If you transferred the sample record to the PC and told it to translate EBCDIC to ASCII and remove CR/LF’s, it would look like this:
X’524F4E202000003120’
Note as previously mentioned, the X’0D0A’ were removed because they were thought to be CR/LF’s, when in reality they were part of a pack-signed and binary fields. The last byte of the binary field of X’0A40’ (the X’40’) was erroneously translated as an EBCDIC space to an ASCII space (X’20’).
The general rule of thumb is to translate and remove CR/LF’s any time you are transmitting source code or any data that is completely "displayable/printable", and to use a pure binary option when transmitting data that has any numeric internally represented data (e.g. pack signed, binary, floating point), even if it only has one field/byte in that format.
Before the PC Cobol development tools had an EBCDIC emulation option, we would have to have pieces of the mainframe file translated from EBCDIC to ASCII, while leaving the data portions alone. To do this you would have to identify every data field’s position and length in bytes that you did not want translated. You could then use a mask or filter telling the transfer software what not to translate, or, you could transfer the whole file down as binary and write a "file to file" program to translate the relevant fields yourself. I have written many of those programs, and I can personally appreciate the amount of time the EBCDIC emulation has saved.
Copyright © 2000
[Softech Solutions, Inc]. All rights reserved.