Hi Andrew,
You have a good point. The GDKUTIL utility is pretty new to z/OS, and
we were going for meeting the customer requirement. That was specifically to
provide a JCL utility that could download the sequential data in a Cloud Object
to z/OS, as well as upload z/OS data to a Cloud Object with the intent that the
data was usable by applications running in the Cloud. I specifically added that
note to the documentation so that no one was surprised by the behavior when
targeting a z/OS data set.
We are actively updating the functionality of the utility and would
love some customer-driven direction. So, please open an RFE (or now Aha! Idea)
against the cloud_data_access component under z/OS with whatever ideas or
wishes you have.
The GDKUTIL utility does allow an Upload of something with RECFM=U.
This was done at the behest of a customer that was using ftp to put SMF data
out for processing by the SAS tool. Apparently, they are able to decipher the
RDW records resulting from uploading a RECFM=VBS as a RECFM=U. Unfortunately,
at this time, GDKUTIL doesn't have the smarts to parse the bytestream as
RDW+data as it is writing to the output data set. That is a current Request For
Enhancement, though.
Sincerely,
Andrew Wilt
DFSMSdfp Cloud Data Access Product Owner
DFSMShsm development
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Andrew Rowley
Sent: Monday, January 23, 2023 3:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Transmitting SMF records
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
