z/OS DFSMS provides access to data on disk or tape, while a relatively recent addition to the world of data storage is cloud objects. Cloud object storage introduces a new dimension to the data landscape. With disk and tape, the media needs to be attached to your z/OS system, but cloud object storage only needs a TCP/IP connection in order to access it. Since cloud object storage uses a REST API, any operating system may access it with the correct credentials. This opens up new horizons for z/OS applications to ingest and share data with applications running in other environments, such as cloud computing and distributed environments.

Today, a z/OS application doesn’t need to worry about whether the data it’s reading is coming from a disk or tape; we believe a z/OS application developer shouldn’t have to worry about the details of accessing data in a cloud object store, either.

z/OS Cloud Data Access (CDA) is a base component of z/OS that provides simple API access to objects in cloud object stores. There is an array of different cloud object storage providers with their own unique REST APIs and methods of authenticating with their service.

CDA handles all of the painful, tedious, and time-consuming details for communicating and authenticating with your target cloud. The provided APIs communicate appropriately to any of the compatible providers. Additionally, CDA provides APIs as well as an ISPF application to securely store the cloud credentials needed to access the cloud object store. When the CDA API is processing, it retrieves the cloud credentials to be used on the request. This means that the user (application developer) doesn't have to enter the credentials during execution of the application, further simplifying the process.

All S3-compatible cloud object stores are supported on z/OS V2R4 and above. With z/OS 3.1, support is introduced for Microsoft Azure Blob Storage and Google Cloud Platform JSON APIs, as well as BASIC, TEMPAUTH, and KEYSTONE authentication methods.

CDA provides GET, WRITE, LIST, and DELETE actions and more. You can check out the full list of CDA’s API actions in the Elements of Cloud Data Access documentation.

Additionally, you can see all of the callable services and the appropriate syntax in the Cloud Data Access Callable Services documentation.

Configuring CDA needs to be considered from two perspectives, the system administrator and the user. For more information, see these quick start guides:

• System administrator configuration quick-start
• User configuration quick-start

In addition, some files must be set up for CDA. For more information, see:

• Cloud Data Access files

You can use the GDKUTIL (cloud object utility) program to verify your CDA configuration. See sample JCL to use GDKUTIL for CDA configuration verification.

JCL batch jobs might need to upload a generated report in PDF format or retrieve the current version of data in a cloud object. A JCL utility, GDKUTIL, enables batch access to cloud objects. The GDKUTIL utility has UPLOAD, DOWNLOAD, DELETE and LIST commands. It uses a LOCAL or LOCNAME DD statement to refer to the z/OS sequential data set or UNIX file that is to be involved in the operation. GDG versions and PDS or PDS/E members are also allowed.

A CONVERT keyword can be used to indicate that the data is text data and should be converted from EBCDIC to UTF-8 on an UPLOAD, or from UTF-8 to EBCDIC on a DOWNLOAD.

Additionally, a DELSRC keyword is available to assist with ‘movement’ of data between the cloud object store and z/OS. After a successful DOWNLOAD of an object, the object is deleted from the cloud object store. Likewise, after a successful UPLOAD of a z/OS data set or UNIX file, it is deleted from z/OS.

For details on the use of the GDKUTIL utility see GDKUTIL (Cloud Object Utility) Program in z/OS DFSMSdfp Utilities.