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 John McKown:
On Mon, Sep 8, 2014 at 8:46 AM, Werner Kuehnel
<[email protected]> wrote:
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,
Werner
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.
--
Bernd Oppolzer
—————————————————————
*Oppolzer-Informatik
* Dipl. Inf. Bernd Oppolzer
Bärenhofstraße 23
70771 Leinfelden-Echterdingen
—————————————————————
Tel.: +49 711 7949591 (neu!)
priv.: +49 711 7949590
eMail: [email protected] <mailto:[email protected]>
—————————————————————
Für Umsatzsteuerzwecke:
SteuerNr.: 97 076 / 29921
USt-ID-Nr.: DE 147 700 393
—————————————————————
7. April 1964: Ankündigung IBM S/360
2014: 50. Geburtstag der Plattform
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
