Who would’ve thought that after 35 years of using the assembler OSREQ interface, you can now mange your DFSMS OAM (Object Access Method) data using a REST interface! On z/OS 3.1 and above, you can now use REST to Store, Retrieve, Delete, Query and Change (management polices) for your OAM objects.
OAM is supporting the AWS S3 REST interface for object storage. Since the published AWS S3 API is already the industry standard for applications to use when storing object data, this made AWS S3 a natural fit for OAM! With OAM’s REST support, you can easily develop and enhance new OAM applications using more readily available, industry standard, skills. The following AWS S3 methods and their corresponding OSREQ functions are being supported:
|
S3 Method
|
OSREQ Function
|
|
PutObject
|
STORE
|
|
GetObject
|
RETRIEVE
|
|
DeleteObject
|
DELETE
|
|
HeadObject
|
QUERY
|
|
GetObjectTagging
|
QUERY
|
|
PutObjectTagging
|
CHANGE
|
To be fully compatible with the existing OSREQ interface you can store objects through REST, retrieve them through OSREQ, and vice versa. This lets you develop new applications to not only store new data through REST, but to also retrieve existing data through REST. Think of the millions of OAM objects that are now accessible through a simpler interface! OAM custom headers are used where an equivalent OSREQ parameter is not available. In essence, what you are used to doing today through the OSREQ API you’ll be able to do through REST.
Use of z/OS WebSphere Liberty and OAM REST Overview
OAM uses the z/OS WebSphere Liberty Application Server to receive the HTTP request from a client application. That HTTP request is then forwarded to the OAM Web Application that is running within a Liberty Server. The request is processed and forwarded to the OAM Bridge Program that runs as an MVS started task through the use of the WebSphere Optimized Local Adapters (WOLA). The OAM bridge program then interfaces with the traditional OAM (OSREQ) support to get the request processed by OAM. The OAM Bridge Program is also referred to as “OAMREST”. The S3 “bucket name” is the OAM collection name and the S3 “key name” is the OAM object name.
Use with OAM’s Object Support and Overview
All the existing OAM support works regardless of where the request started (REST or OSREQ). All the same functions and features that you are used to with OAM continue to be supported with REST.
An OAM object is simply a string of bits. Based on policies defined through DFSMS System Managed Storage (SMS), OAM manages that object data from creation to expiration. Objects can be stored directly to disk (Db2 or File System), Tape, or the Cloud and can transition to any layer of the storage hierarchy based on access time requirements to the data. As the data ages, it is typically moved to “slower” storage with the ability to recall the object to “faster” storage. If it is backup or archive data that is infrequently accessed, the data can be directly stored to “slower” storage. OAM supports a primary copy of the object and up to two OAM managed backup copies.
Use of Cloud Data Access (CDA)
As with OAM’s Cloud support, DFSMS Cloud Data Access (CDA) is also used to securely store the S3 credentials used by the OAM REST API. There are a new set of CDA panels (z/OS Cloud Data Access OAM REST API Credentials Utility) for use with OAM’s REST support.
Resources
For more information on the installation steps for both OAM and CDA and for details on the support, refer to the installation and usage guides. The installation guide walks you through the steps that a system administrator, a storage administrator, and a security administrator would perform to setup the support and the usage guide discusses how to use the REST API support. For additional information refer to:
This awesome new functionality is provided to you at z/OS 3.1 and above with OA64282; Supporting APARs include OA65068, OA65069 and OA66996.
We would love to hear your thoughts on these new OAM 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:
Erika Dawson
Editors:
Alexis Kapica
Barbara McDonald