VSAM RLS and DFSMStvs

The need for File Sharing

Back in the good old days of mainframe computing, your customers went home at 18:00, so you brought your online systems down, spend a few hours backing up the data, then the rest of the night processing the overnight batch. At 08:00 you brought the online systems back up again, and all was well. You probably also had one production MVS machine with one CICS system, which was easy to manage.

Today, you will have several production systems that may need to share files, and new fangled products like the internet means you need the systems available all the time. This is where VSAM Record Level Sharing (RLS) and DFSMS Transactional VSAM Services (tvs) come in.

The fundamental issue here is data integrity. If several processes are accessing the data at the same time, its necessary to ensure that the data is consistent. Formerly, the only way to preserve data integrity was to use a combination of VSAM sharelevel parameters and JCL disposition parameters.

When a Batch job was updating a file, then you specified DISP=OLD in the JCL DD name for that file. What that meant was, I want exclusive access to the file while I have it open. No one else can write to it or read from it. You could not run batch alongside on-line systems as the entire file was locked, but data integrity was assured.

If you specify DISP=SHR, then several programs can access a file concurrently. You could then control access by using the SHRLEVEL VSAM file allocation parameter. However, VSAM did not actually manage concurrent access, it was left to the applications to ensure consistency.

Finally, several CICS systems can share VSAM files if one of them is designated a File Owning Region (FOR), and the others Application Owning Regions (AOR). When an AOR wants to access data it passes the request to the FOR, which provides file access to the VSAM spheres. However, this does not manage any work running outside of CICS.

There are some third party products which can help here, SYSB-II for vsam file sharing is one that springs to mind.

VSAM RLS

VSAM RLS allows users on different LPARS or machines to share VSAM spheres with read and write integrity with serialization at record level. RLS requires a Sysplex as it stores the VSAM control blocks in a coupling facility cache. It also requires that all shared VSAM files be SMS managed. It is possible to run RLS on a single system to permit data sharing at record level, but it still needs a SYSPLEX running in monoplex mode with a coupling facility.

You open a VSAM cluster in RLS mode by either specifying this in your program ACB macro, or by using the RLS JCL keyword. Options are

• RLS=NRI, No Read Integrity; the application will read every record, even records that are in use elsewhere
• RLS=CR, Consistent Read; the application will put a share lock on the record while reading and will not read records that are held for update by another user.
• RLS=CRE, Consistent Read Explicit; the application will hold a record it is reading until is issues a commit point. CRE only works with applications that log updates and use commits to manage transaction backout.

Sample JCL

//DDNAME    DD  DSN=dataset.name,DISP=SHR,RLS=CR

Installing RLS

You need to install a few components to get RLS to work.
RLS requires an address space on every participating z/OS system, called SMSVSAM, which looks after the file sharing. These address spaces have VSAM data buffers associated with them for caching. You start the address space automatically at IPL time with an RLSINIT keyword in the IGDSMSxx parmlib member, or manually with a

 VARY SMS,SMSVSAM,ACTIVE

The SHCDS or Sharing Control Datasets are used for system recovery if any of the RLS components fail. They must have a naming standard of SYS1.DFPSHCDS.anyname.Vvolser, and must be placed on a single volume as identified by the Vvolser statement. An SHCDS is a linear VSAM file and you probably need three for resilience.

The Coupling Facility Cache structures are defined with the IXCM2APU system utility and are used store the shared VSAM file control block structure.

The Coupling Facility Lock structures are defined with the IXCMIAPU system utility and are used store the all locks currently held on VSAM records.

An SMS storage class that defines the cache set name, the direct weight and the sequential weight for preferred performance.

An RLSINIT Entry in the IGDSMSxx parmlib member to define some RLS timeout and pool size parameters.

RLS SMS COMMANDS

VSAM RLS introduced some new SMS commands

Display coupling facility lock structure, which will report on lock contention

 D SMS,CFLS

Display VSAM spheres in quiesce status (only for this system)

 D SMS,SMSVSAM,SPHERE

Change the status of a cache structure called 'cfname' to either allow it to store RLS records (ENABLE) or stop it (QUIESCE)

 V SMS,CFCACHE(cfname),ENABLE/QUIESCE

Allow or disallow the contents of a volume to be held in coupling facility cache.

 V SMS,CFVOL(volser),ENABLE/QUIESCE 

DFSMStvs

TVS builds on the RLS facilities by extending the control of VSAM sharing to batch jobs, and any other work which runs outside CICS control. SMStvs just uses RLS locking. When an application requests a record for read or write (GET or PUT in programming terms) RLS locks out the records (not the whole file), and holds the locks in the coupling facility. As both RLS and TVS store data in the coupling facility, this means that the products require a parallel sysplex.

SMStvs complements RLS by adding recovery logs for non-CICS updates. The MVS System Logger can read both the RLS logs and the TVS logs and consolidate them, to provide a consistent view for roll forward or roll backward processing. The System Logger writes its logs to Disk or the Coupling Facility or both, depending on the configuration. SMStvs can have three types of logs, Primary, Secondary and Forward Recovery. It can also have a fourth log, called the 'log of logs'

SMStvs can recover in either direction. Every time a 'unit of recovery' is updated, SMStvs writes the image of the record as it was before the update to the undo log. These before images can be re-applied to get the file back to a previous state after a failure, and are deleted once a commit point is reached. SMStvs also writes a copy of a committed record to the forward recovery log, provided the file was defined with LOG(ALL). This log can be used to roll the file forward from a full file recovery to the point of failure.
All recoveries are managed by z/OS RRS (Recoverable Resource Services), which calls SMStvs to perform the backout. RRS will also manage backouts on behalf of DB2 UDB, IMS and MQ series. RRS uses a two-phase commit mechanism, to ensure that either all updates to all resources are committed, or no updates are made at all.

This stuff does not come free. Both RLS and TVS require that synchronisation points, or commit points be added to application programs. The unit of recovery is the set of all changes made to all resources between two synchronisation points. If these are not added, then each program runs as a single, huge transaction. This means that the undo log will be huge, and will probably spill out of the coupling facility onto DASD, and cause performance problems. Also, as records are locked for the duration of the transaction, then they are locked out for the whole job. Batch jobs running under SMStvs will take longer, due to the logging and locking overhead. You should consider re-designing your batch run to take advantage of the data sharing, by running more jobs in parallel.
Also, be aware once you start sharing VSAM files between CICS and batch, then you can not use traditional batch recovery methods. If you back a file up at the start of a batch job, then restore the file when the job fails, you will back it out, but you will also back out any updates made by CICS.
Backout and roll forward applies to VSAM files only. Any updates made to non-VSAM files will not be backed out.

SMStvs introduces some new SMS commands

To display SMStvs information, including log data.

 D SMS,TRANVSAM,ALL

To stop or start transactional vsam

 V SMS,TRANVSAM,QUIESCE/ENABLE

New IDCAMS ALLOCATE/DEFINE/ALTER parameters are

Enable backup while open for tvs

 BWO(TYPECICS)

Permit transaction backout

 LOG(UNDO)

Permit transaction backout and forward recovery

 LOG(ALL)

back to top

                           VENDOR SHOWCASE

By entering and using this site, you accept the conditions and limitations of use