In this blog post I show an example of how I used the base z/OS utility GDKUTIL to copy a tape data set to an S3 compatible cloud. I must admit when I first pointed GDKUTIL at a tape data set I was expecting an error on the input data set with a message like ‘invalid device type’, so I was surprised when I was able to copy a tape data set created by IDCAMS to my S3 compatible cloud without having to copy it to a disk data set.
This made sense once I realized that GDKUTIL, which uses the new Cloud Data Access method (aka CDA), simply uses QSAM to read data sets that are to be written to the cloud. QSAM is only concerned with the data set organization; In other words, any physical sequential data set (DSORG=PS) with a fixed or variable length record format (RECFM=F or V) can be read or written by GDKUTIL regardless of its device type.
At first, I tried a DFSMSdss backup tape, however they have undefined record format (RECFM=U) so they cannot be copied with GDKUTIL. Then I tried another popular backup method IDCAMS which creates backups with a RECFM=V. In this test case I used a VSAM Keyed Sequential Data Set (KSDS) and unloaded it to a sequential tape data set with the following JOB.
Then, I used GDKUTIL to copy that tape data set out to my S3 compatible cloud. There are three DD statements that define how GDKUTIL will determine the data set, container and cloud object that will be used (SYSIN, OBJNAME and LOCAL).
1) SYSIN:
a. The UPLOAD statement in the SYSIN data set specifies my cloud provider name which is MINIO that is defined in my CDA providers file.
b. I use the CONVERT option since the tape data set is a variable length record format (see the comments in the example).
c. In this example the LOG option is set to DEBUG which will show me details about data transfer and cloud connection. However, in most cases this option can default to NONE as detailed trace information is generally not required.
2) OBJECT: The OBJNAME DD defines container and cloud. The standard format is that the container name is before the first /. The object name in that container is anything after that first / and the object name can also contain multiple / characters. Object and container names are generally lower case. The / is not really a directory but rather a method for organizing object names and most cloud object names can be up to 1024 bytes, however I prefer a reasonable self-imposed limit of 256.
3) LOCAL: The LOCNAME DD defines the local z/OS data set name in this example my tape data set name is JHH60.VSAM. TAPE.UNLOAD1
Information about how to define your cloud providers and configure CDA can be found in the Cloud Data Access chapter in the z/OS MVS Programming: Callable Services for High-Level Languages manual.
If you think about it, I now have a safe copy of my z/OS VSAM data set that is completely air-gapped from my z/OS operating system and I can later download it to any z/OS operating system in the world to recover that data set. I started back in the days when a company used to come by our data center every day to move tapes to an offsite facility and now, I can do that myself from the comfort of my home office!
You can learn more about CDA and GDKUTIL on the CDA Content Solution page here.
Have you tried using CDA or GDKUTIL yet?
Comment here if you have used it and let me know if there is any other content you would like to see a post about going forward!
#IBMChampion