Exactly: Foundation: 1) CDA base: Configure a Cloud provider (end point, credentials (security admin), settings) 2) RACF authorize a user to use the defined cloud provider. This gives the security admin the role of managing the credentials and who can access which cloud provider accounts. (One for backup, one for ApplicationX, one for test...) 3) GDKUTIL: Simple JCL to upload / download from z/OS of defined cloud provider (can convert between codepages, eg EBCDIC to ASCII and back to EBCDIC) This allows you to test your configuration and do small scale movement. Now you have your base to leverage object storage: 1) Utilize one of the DFSMS products to target object storage: DFSMShsm, DFSMSdss, DFSMScdm and OAM all use the CDA defined cloud providers 2) Your own application owners can put/get data directly to object storage via the 2nd aspect of CDA which are the S3 APIs. Why use CDA? In step one, you defined the provider: IBM, AWS, Azure, Google... CDA leverages a single API for PUTs / GETs and then based on the provider, will create the specific request for that provider. (The greatest benefit of CDA is that it manages the credentials. Each of these providers have very different methods to authenticate, and your application owner does not have to know any of that).
CDA: https://www.ibm.com/support/z-content-solutions/cda/ Glenn Wilcock ([email protected]) DFMSMS Chief Product Owner ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
