This section provides an overview of DFSMStvs including its relationship with RLS.
The RLS connection
As we saw in the previous chapter on RLS, which was introduced in DFSMS/MVS 1.3, RLS provides for a new mode of access to VSAM data. Also, we learned that RLS uses the System/390® Coupling Facility to provide the lock structures and data caching abilities to manage and ensure data integrity when VSAM data is shared. This is the reason that a Coupling Facility is required for RLS even if you want to share VSAM data in a monoplex. DFSMStvs extends the sharing of data to CICS and batch level sharing similarly maintaining data integrity for reads and updates. To accomplish this, DFSMStvs must provide the same abilities that CICS provides, such as logging for forward and backward recovery, backout, and a two-phase commit process.
When a VSAM application issues a GET or a PUT (or the high-level language equivalent of these VSAM macros), VSAM RLS will acquire locks on behalf of the application. A coupling facility is used to hold the locks so that they can be shared by all the SMSVSAM address spaces in a sysplex.
In general, VSAM RLS will obtain share locks for read requests and exclusive locks for update or delete requests. It will wait for a certain period of time if another task holds the required locks. A share lock may be obtained for a resource if there is no lock for that resource or there are share locks held. An exclusive lock may only be obtained if no other locks are held. Note that CICS publications refer to share locks as shared locks.
The DFSMStvs access mode uses VSAM RLS locking and so it is compatible with CICS locking.
The z/OS system logger is used to provide the logging functions that are needed to ensure data consistency after failure. The redo log name is held as an attribute of a recoverable data set while the undo log name is fixed. Forward recovery logging will be done by both CICS and DFSMStvs to the same redo log. CICS will log changes made by CICS transactions while DFSMStvs will log changes made by its callers as shown below.
Merged forward recovery log
The system logger is used because it can merge log entries from many z/OS images to a single log stream, where a log stream is simply a set of log entries. A single log stream across a sysplex eases management and protects data integrity.
This ability to merge log entries is used for the forward recovery logs to ease recovery. The system logger writes log entries to the coupling facility, disk or both. However, note that each instance of DFSMStvs has a private undo log; the undo logs are not shared. An instance of DFSMStvs is the single version of DFSMStvs running in one z/OS image and defined by the IGDSMSxx PARMLIB member for that z/OS image.
DFSMStvs uses these log streams:
There is one backout log stream for each instance of DFSMStvs (SMSVSAM). It is not shared between SMSVSAMs. The name of the backout log stream is constructed from the unique name for an instance of DFSMStvs which you define in SYS1. PARMLIB (IGDSMSxx). It is named tvsname.IGWLOG.SYSLOG, where tvsname is of the form IGWTVnnn.
There is one shunt log stream for each instance of DFSMStvs. It is not shared between SMSVSAMs. The name of the shunt log stream is constructed using the unique name for an instance of DFSMStvs that you define in SYS1. PARMLIB (IGDSMSxx).
It is named tvsname.IGWSHUNT.SHUNTLOG, where tvsname is of the form IGWTVnnn.
The shunt log is used when backout requests fail and for long running units of recovery. In these cases log records are moved so that DFSMStvs can better manage space in the primary log.
Forward recovery logs are used by data sets for which LOG(ALL) is specified. When LOG(ALL) is specified you must also specify LOGSTREAMID to provide the name of the forward recovery logstream. This logstream is used by all instances of DFSMStvs and CICS to provide forward recovery capability.
This is an optional log stream, it is specified in SYS1.PARMLIB(IGDSMSxx). If it is defined, it contains copies of log records that are used to automate forward recovery.
Although the log of logs is optional, we recommend that it be used if you want to use forward recovery at all. However, when you define a log of logs, it must be present otherwise DFSMStvs fails.
This shows a simple example with undo and redo logging. The vertical arrow shows the commit point at which time the undo log records are effectively forgotten. Note that the undo log records show how the records existed before the transaction, while the redo log records show how the records exist after they are updated. The log records are prefixed with header information used for recovery or backout.
Undo and redo logging
In the case of DFSMStvs, the resources that are being protected are the records within recoverable VSAM data sets. There are three types of participants in resource recovery:
Insertion of records
Erasure of records
Back out changes
z/OS Recoverable Resource Services are used to coordinate commit and backout requests from applications and any other resource managers that may be needed. Apart from DFSMStvs, other resource managers using z/OS RRS are DB2 UDB, IMS and MQSeries. This means that an application can use a combination of VSAM, IMS, DB2 UDB and MQSeries services and have commit and backout performed atomically for all these resources.
RRS as the sync point manager
The DFSMStvs code calls RRS to register its interest in a unit of recovery. A unit of recovery represents the set of changes made by an application to a resource since the last commit (implicit or explicit) or backout. Each unit of recovery is associated with a context.
DFSMStvs writes a copy of an unmodified record (the record as it existed before an update) to the undo log and, when the data set’s log attribute is set to ALL, writes a copy of the modified record (as it exists after an update) to the forward recovery log.
When an application requests either a commit or a backout, z/OS RRS will call DFSMStvs to do the commit or backout on behalf of the application. The processing flow is shown here in a simplified form for a successful commit:
Commit processing participants
In Step 1, the application decides that it is ready to commit changes. It requests a commit and that request is passed to the syncpoint manager. The syncpoint manager sees what resources are involved and, in Step 2, asks each resource manager that has expressed interest in this unit of recovery to prepare to commit and notify it of readiness. If all the resource managers reply that they are ready to commit, the syncpoint manager tells them to complete the process in Step 3.
When that is done, the syncpoint manager can then confirm that the commit has completed to the application in Step 4.
VSAM Related Interview Questions
|IBM - VSAM Interview Questions||JCL Interview Questions|
|File Maker Interview Questions||IBM DB2 Interview Questions|
|COBOL Interview Questions||IBM-JCL Interview Questions|
|DB2 Using SQL Interview Questions||IBM-JCL&VSAM Interview Questions|
|IBM Mainframe Interview Questions||COBOL, CICS, JCL, VSAM, DB2 Interview Questions|
|Cisco Interview Questions||IMS/DB Interview Questions|
|Mainframe DB2 Interview Questions|
Vsam Problem Determination And Recovery
Managing Your Vsam Data Sets
Vsam Record Level Sharing
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.