Oppolzer - Informatik / Blog

So true!

I also had a hard time some time ago to explain this simple facts to some people
who tried to send me a binary VB data set from a z/OS system by FTP across other
(non-z/OS) systems. The information about record length etc. simply gets lost,
because the VB file (if binary) will be transferred as a byte string without
record structure (one large string of bytes), or otherwise, you will get record
termination characters inserted, which is also plain wrong.

The problem is not EBCDIC; you can do a transmission without code translation by
FTP by using "binary"; the problem is the record oriented file structure of the
z system compared to the byte oriented paradigm of FTP (unix tool). This works
fine, if you do FTP between two z systems, but if there are other systems in
between, you're in a real mess.

"Fixed length" would be a solution, too; if FTP inserts record termination
characters at some stage of the transmission, they all appear at fixed known
offsets and can be easily removed at the target system. But: the sender will
have to fill all records to the same maximum length ... don't know if the
sending party is able to do this.

If variable length is really needed: generate fixed length records anyway, but
put a logical length field in front of each record. This, too, has to be done by
the sending party.

Kind regards

Bernd



Am 08.09.2014 16:25, schrieb J.M.:
> On Mon, Sep 8, 2014 at 8:46 AM, W.K.:
>> It's not my creation, it was delivered by a bank for a test. Thanks for
>> your suggestions, but if there are no standard ftp commands I refuse to
>> work with that file.
>> Anyway, I tested your way and it almost worked, Unfortunately there are
>> packed fields in the records containing x'15' which are not a line end.
>>
>> Thanks,
>> W.
>>
> If the bank is trying to send you EBCDIC information from a z/OS
> system, but needs it to survive transfer across non-z/OS systems, then
> the bank really needs to either use AMATERSE or TRANSMIT to put the
> data into a more transportable format. Those both result in an FB
> file, which can easily be binary ftp'ed from z/OS to Windows, then
> back to z/OS and restored. Doing a normal BINary FTP of variable data
> will just result in frustration and data corruption.
>


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@listserv.ua.edu with the message: INFO IBM-MAIN