Using VSAM record-level sharing
VSAM record-level sharing (RLS) is a VSAM data set access mode, introduced in DFSMS, and supported by CICS®. RLS enables VSAM data to be shared, with full update capability, between many applications running in many CICS regions. With RLS, CICS regions that share VSAM data sets can reside in one or more MVS™ images within an MVS sysplex.
RLS also provides some benefits when data sets are shared between CICS regions and batch jobs.
RLS involves the use of the following components:
- A VSAM server, subsystem SMSVSAM. This subsystem runs in
its own address space to provide the RLS support required by CICS application owning regions
(AORs) and batch jobs, within each MVS image
in a Parallel Sysplex® environment.
The CICS interface with SMSVSAM is through an access control block (ACB), and CICS registers with this ACB to open the connection. Unlike the DB2® and DBCTL database manager subsystems, which require user action to open the connections, if you specify RLS=YES as a system initialization parameter, CICS registers with the SMSVSAM control ACB automatically during CICS initialization.
A CICS region must open the control ACB to register with SMSVSAM before it can open any file ACB in RLS mode. Each normal file ACB remains the interface for file access requests.
- Sharing-control data sets. VSAM requires a number of these
data sets for RLS control. The VSAM sharing control data sets are
logically partitioned, linear data sets. They can be defined with
secondary extents, but all the extents for each data set must be on
the same volume.
Define at least three sharing-control data sets. VSAM requires two active data sets for use in duplexing mode, and a third data set as a spare in case one of the active data sets fails.
For more information about sharing-control data sets, and for a JCL example to define them, see z/OS DFSMS Storage Administration Reference.
- Common buffer pools and control blocks. For data sets accessed
in non-RLS mode, VSAM control blocks and buffers (local shared resources
(LSR) pools) are located in each CICS address
space. They are thus not available to batch programs, and not even
to another CICS region.
With RLS, all the control blocks and buffers are allocated in an associated data space of the SMSVSAM server. This structure provides one large buffer pool for each MVS image, which can be shared by all CICS regions that are connected to the SMSVSAM server, and also by batch programs. Buffers in this data space are created and freed automatically.
DFSMS provides the RLS_MAX_POOL_SIZE parameter that you can specify in the IGDSMSxx SYS1.PARMLIB member. There are no other tuning parameters for RLS as there are with LSR pools. Management of the RLS buffers is fully automatic.
- When new records are added to the end of an ESDS in RLS access mode, the acquisition of locks on the various calls required to VSAM to satisfy the request might cause long response times for the operation.
- If a CICS region fails while writing to an ESDS, the data set might be locked until the CICS region is restarted.
- Define the required sharing control data sets.
- Specify the RLS_MAX_POOL_SIZE parameter in the IGDSMSxx SYS1.PARMLIB member.
- Ensure that the SMSVSAM server is started in the MVS image for which you want RLS support.
- Specify the system initialization parameter RLS=YES. This parameter enables CICS to register automatically with the SMSVSAM server by opening the control ACB during CICS initialization. RLS support cannot be enabled dynamically later if you start CICS with RLS=NO.
- Ensure that the data sets you plan to use in RLS-access mode are defined, using Access Method Services (AMS), with the required recovery attributes using the LOG and LOGSTREAMID parameters on the IDCAMS DEFINE statements. If you use an existing data set that was defined without these attributes, redefine the data set with these attributes specified.
- Specify RLSACCESS(YES) on the file resource definition.
CICS can use three different modes to access a VSAM file. These are non-shared resources (NSR) mode, local shared resources (LSR) mode, and record-level sharing (RLS) mode. (CICS does not support VSAM global shared resources (GSR) access mode.) The mode of access is not a property of the data set itself, it is a property of the way that the data set is opened. This means that a given data set can be opened by a user in NSR mode at one time, and RLS mode at another. The term non-RLS mode is used as a generic term to refer to the NSR or LSR access modes supported by CICS. Mixed-mode operation means a data set that is opened in RLS mode and a non-RLS mode concurrently, by different users.
Although data sets can be open in different modes at different times, all the data sets within a VSAM sphere must normally be opened in the same mode. A sphere is the collection of all the components—the base, index, any alternate indexes, and alternate index paths—associated with a given VSAM base data set. However, VSAM does permit mixed-mode operations on a sphere by different applications, subject to some CICS restrictions.
Effects
The tests and measurements described were carried out using RLS with key-sequenced data sets (KSDS). As described earlier in this topic, RLS is not suggested for use with entry-sequenced data sets (ESDS), as it can cause problems with performance and availability when you are adding records.
- Switching from local file access to function-shipping across MRO cross-memory (XM) connections incurred an increase of 7.02 ms per transaction in a single CPC.
- Switching from MRO XM to RLS incurred an increase of 8.20 ms per transaction in a single CPC.
- Switching from XCF/MRO to RLS using two CPUs produced a reduction of 2.39 ms per transaction.
- Switching from RLS using one CPC to RLS using two CPUs there was no appreciable difference.
- Function-shipping with MRO XM is better than RLS, but this choice restricts function-shipping to within one MVS image, and prevents full exploitation of a Parallel Sysplex with multiple MVS images or multiple CPUs.
- RLS is better than function-shipping with XCF/MRO, when the FOR is running in a different MVS image from the AOR.
- Because more applications need to share the same VSAM data, the load increases on the single FOR to a point where the FOR can become a throughput bottleneck. The FOR is restricted, because of the CICS internal architecture, to the use of a single TCB for user tasks, which means that a CICS region generally does not use multiple CPUs
- Session management becomes more difficult as more AORs connect to the FOR.
These negative aspects of using an FOR are resolved by using RLS, which provides the scalability lacking in a FOR.
Monitoring
- CICS monitoring
- For RLS access, CICS writes
performance class records to SMF containing:
- RLS CPU time on the SMSVSAM SRB
- RLS wait time
- SMSVSAM SMF data
- SMSVSAM writes Type 42 records, subtypes 15, 16, 17, 18, and 19, providing information about coupling facility cache sets, structures, locking statistics, CPU usage, and so on. This information can be analyzed using RMF III post processing reports.
//RMFCF JOB (accounting_information),MSGCLASS=A,MSGLEVEL=(1,1),CLASS=A
//STEP1 EXEC PGM=IFASMFDP
//DUMPIN DD DSN=SYS1.MV2A.MANA,DISP=SHR
//DUMPOUT DD DSN=&&SMF,UNIT=SYSDA,
// DISP=(NEW,PASS),SPACE=(CYL,(10,10))
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
INDD(DUMPIN,OPTIONS(DUMP))
OUTDD(DUMPOUT,TYPE=000:255))
//POST EXEC PGM=ERBRMFPP,REGION=0M
//MFPINPUT DD DSN=&&SMF,DISP=(OLD,PASS)
//SYSUDUMP DD SYSOUT=A
//SYSOUT DD SYSOUT=A
//SYSPRINT DD SYSOUT=A
//MFPMSGDS DD SYSOUT=A
//SYSIN DD *
NOSUMMARY
SYSRPTS(CF)
SYSOUT(A)
REPORTS(XCF)
/*
CICS file control statistics contain the typical information about the numbers of file control requests issued in the CICS region. They also identify which files are accessed in RLS mode, and provide counts of RLS timeouts and EXCP counts for RLS files. They do not contain any information about the SMSVSAM server, or its buffer usage, or its accesses to the coupling facility.