You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Storage > Data Management

Reintroducing Object Access Method

The latest z/OS release brings file system support for OAM

The latest z/OS release brings file system support for OAM
Illustration by Dustin Miller

How it Works

Within zFS, a file system is created on disk storage attached to z/OS (i.e., IBM System Storage* DS8700* device). This file system is defined by creating a VSAM linear data set in which the zFS file system will reside.

Alternatively, in NFS the file system resides on disk storage within an NFS file server, which is typically a separate hardware device (i.e., IBM N Series) that’s connected via a network attachment to z/OS. TCP/IP is then used to process access requests for files within mounted NFS file servers.

“OAM then uses basic file I/O functions to create, open, read, write, close and delete files in the file system based on policies you’ve established through the SMS ACS routines,” says Kevin Goldsmith, IBM senior software engineer.

To begin making OAM work for your company, it’s important to follow a few steps. First, you must plan where data is stored and when it can be moved, as well as who is allowed to access it.

Implementing configuration steps is also necessary before using OAM. The new file system support expands on OAM’s current use of the SMS storage class construct, which manages where in the OAM storage hierarchy an object should be placed. Within the storage class construct, the Initial Access Response Seconds (IARS), the Sustained Data Rate (SDR) and the OAM Sublevel (OSL) parameters are used to determine where an object should reside in the storage hierarchy. OAM uses a new SETDISK to determine in which file system an object should be stored. It specifies the directory location in the UNIX file system hierarchy where the objects may be stored and also identifies to OAM the type of file system being used.

Also applicable for the new file-system sublevel of support is the Recall to Disk functionality, which has new configuration options in OAM. These options specify whether objects should be recalled to the DB2 sublevel or the file-system sublevel.

OAM maintains each object’s metadata in a DB2 table, which provides an object directory (i.e., tracking information like where in the OAM storage hierarchy an object resides). Used to identify objects that will be deleted from the UNIX file-system hierarchy, a File System Delete Table has been added to the OAM Configuration Database in support of the file-system sublevel. Deletion occurs because either the object’s lifecycle has expired or objects written to the file system haven’t been committed (i.e., application rollback).

OAM Two Decades Later

OAM has come a long way from its humble beginnings. Each layer of support added since it was first introduced has provided groundbreaking ways to store and manage data. The latest file-system sublevel support is no different, giving users more data-storage options and easy data access.

“In the beginning, it was to replace microfiche and OAM is now replacing file cabinets,” says Sherrie Niederbrach, IBM senior software engineer. “It’s about immediate access to your data instead of leafing through your file cabinets.”

Caroline Vitse is a freelance writer based in Rochester, Minnesota.



Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Finding the Perfect Fit

IBM System Storage Easy Tier tailors SSDs for your workloads

Encrypt and Protect

IBM Tivoli Key Lifecycle Manager solves security problems and meets new standards

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters