If you haven’t seen the rest of the Game Changing Series Blog posts you can check them out here to get a high-level explanation of CDA and the other enhancements!

The DFSMSdfp CDA team has been working hard to bring you the next enhancement to the Cloud Data Access functionality! This enhancement increases the compatibility between z/OS datasets and cloud objects, allowing z/OS datasets to be shared between Sysplexes, including things like DFSMSdss backup datasets.

Data on z/OS often comes in a format where the separation between logical pieces is baked into the container (z/OS Data Set). In an object store, objects are simply a byte-stream, most equivalent to a UNIX flat file. Objects that contain text usually have logical pieces separated by newline characters. Otherwise, the application reading the object needs to understand what the separators are.

z/OS Data Set and Cloud Object Compatibility

We have extended the CDA functionality by supporting the upload and download of most datasets! CDA already supported the transfer of sequential data (PS, PDS members and z/OS UNIX System Services files); With this new enhancement you can transfer your VSAM Key-Sequenced Data Sets (KSDS), Entry-Sequenced Data Sets (ESDS), and record format U datasets to Cloud Object Storage and back! It can also re-form variable record sequential datasets.

CDA will also preserve the record boundaries of the data within datasets so your datasets are restored upon download exactly as they were during upload.

GDKUTIL has been updated with some new keywords so it can be used to perform this function as well.

How do I use the Cloud Compatible Datasets feature?

GDKUTIL users can specify the ‘FORMAT(RECORD)’ keyword with the UPLOAD command to use the feature. No extra keywords are needed when downloading the dataset using DOWNLOAD command. If a dataset with the name found on the LOCNAME DD doesn’t exist, it will be created using metadata associated with the object (captured when the object was uploaded).

For CDA API users, use the GDKWRITE API and GDK_PATH_DATALOCATION mode, add the new optional parameter ‘cloudformat’ and set its value to ‘record’.

All objects that are uploaded this way will have the metadata tag ‘zos-filedata:record’associated with it. Note: the data is stored into the cloud object with IGGRPFX record areas preceding the record data.

When downloading these objects using the GDKGET API call, CDA will detect that the contents of the object are in the record format and restore the dataset exactly as it was. No additional configurations are needed.

Now what if the object was uploaded in IGGRPFX record format, but not using this Cloud Compatible datasets feature? No worries. Specify the optional parameter ‘cloudformat’ with the value ‘record’ on the GDKGET API call and CDA will restore the dataset.

If you are using GDKUTIL, specify the FORMAT(RECORD) keyword with DOWNLOADcommand when downloading such objects. You may want to override some dataset creation attributes such as SMS class names, or volume serial when downloading to a different system. New keywords, STORCLAS, MGMTCLAS, DATACLAS, and VOLSER, are added to help you with those overrides.

Note :

As you know, GDKWRITE and GDKGET APIs support three modes GDK_BUFFER_DATALOCATION, GDK_PATH_DATALOCATION and GDK_EXIT_DATALOCATION. This Cloud Compatible Datasets feature works with the GDK_PATH_DATALOCATION mode and is ignored for GDK_BUFFER_DATALOCATION and GDK_EXIT_DATALOCATION (As only a Data Set can have record boundaries).

This feature is delivered via the APAR OA66579 on z/OS 3.1 and OA67785 on z/OS 3.2.

If you have old DFSMSdss backups on disk or tape, you can now move them to object storage, and download them to other systems for recovery. What other cool things could you do with the shared cloud object storage between Test and Production systems?

Check out the publication documentation to get more details.

Check out our Cloud Data Access content solution page to learn more and get started!

We would love to hear your thoughts on CDA and these new enhancements! Leave a comment on this blog post, start a discussion on the DFSMS Community Page, or join Mainframe Data Management LinkedIn group to discuss there!

Author:  

Shikhar Shreshtha - CDA Developer

Editors:

Andrew Wilt – CDA Product Owner

Alexis Kapica – z/OS DFSMS Product Manager