On 20/01/2023 7:07 am, Glenn Wilcock wrote:
Late to the party on this discussion... DFSMS recently shipped a new utility
named GDKUTIL. It converts z/OS data sets and UNIX files to cloud objects and
visa-versa.
Reading the documentation, the following note looks like a problem:
=====================
/When specifying a z/OS Data Set for LOCAL or LOCNAME for a DOWNLOAD
command without the CONVERT keyword, the Record Format should not be
Variable. (RECFM=V or RECFM=VB) This is because in binary mode, there
are no indicators in the data where a record ends, so the data is placed
up to the maximum logical record length. If a Data Set with variable
records was uploaded to a Cloud Object in binary mode, the indicators of
where a record begins and ends are lost. Therefore, a download operation
of that same data to a Variable record data set cannot tell when to
start a new record in the data set./
=====================
A useful function should be able to round trip the data to and from
cloud storage and end up with exactly what you started with.
If there is not enough information to recreate the records on z/OS with
the correct length, there is probably not enough information to usefully
process the data on another platform. FTP made the same mistake,
assuming that the record length information was not part of the data.
For variable length records it is critical.
RECFM U presumably preserves the block & record length information, but
makes it unnecessarily complex to decipher. From the documentation I
can't tell whether uploading RECFM U data results in the same data you
started with. At a minimum there must be complications to end up with
the real/correct DCB attributes.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
