Object Access Method (OAM) is an access method under z/OS which is designed for the storage of a large number of large files, such as images.
OAM has a number of distinguishing features compared to access methods such as VSAM:
- OAM datasets do not have an internal record structure. They are accessed as binary data streams.
- OAM datasets are not directly cataloged. Rather, they are stored into OAM collections, with only the OAM collection being cataloged.
The reason for this is to prevent the catalog from being overloaded with the large number of (e.g. image) files.
- OAM is used in conjunction with DB2. An example use case for OAM would be storing medical images in a DB2 database running under z/OS.
- OAM collections are "pseudo-datasets" and their access-permissions are NOT controlled by the resource class DATASET in CA Top Secret.
- OAM collections are cataloged in ICF catalogs where real datasets are also cataloged.
- OAM collections are cataloged like other DATASETs. Their names should be carefully chosen in a way to avoid conflict or collision with other DATASETs.
There isn't anything that can be done in CA Top Secret for OAM datasets because it is the catalog management that handles the updates to its catalogs.
For example, when trying to catalog a duplicate dataset, a NOT CATALG2 error is received. (No CA Top Secret error message or violation occurs for this.)
- OAM collections security can be implemented using the exit CBRUXSAE so the OAM-collections security is handled separately from dataset security.
- When the default CBRUXSAE is used and not customized, CA Top Secret does NOT care about OAM collections itself.
CA Top Secret only cares about the rights to update the catalog where you are trying to catalog an OAM collection or a dataset.
If the user should not be allowed to catalog an OAM collection, do not give the user UPDATE or higher access to the catalog.