DFSMS Transactional VSAM Services
DFSMS Transactional Virtual Storage Access Method (VSAM) Services (DFSMStvs) is an enhancement to VSAM record-level sharing (RLS) access that enables multiple batch update jobs and customer information control system (CICS) to share access to the same data sets. DFSMStvs provides two-phase commit and backout protocols, as well as backout logging and forward recovery logging. DFSMStvs provides transactional recovery directly within VSAM.
As an extension of VSAM RLS, DFSMStvs enables any job or application that is designed for data sharing to read-share or write-share VSAM recoverable data sets. VSAM RLS provides a server for sharing VSAM data sets in a sysplex. VSAM RLS uses Coupling Facility-based locking and data caching to provide sysplex-scope locking and data access integrity. DFSMStvs adds logging, commit, and backout processing.
To understand DFSMStvs, it is necessary to first review base VSAM information and VSAM RLS.
In this chapter we cover the following topics:
•Introduction to VSAM RLS
•Introduction to DFSMStvs
This chapter includes the following sections:
7.1 VSAM record-level sharing introduction
VSAM RLS is a method of access to your existing VSAM files that provides full read and write integrity at the record level to any number of users in your Parallel Sysplex.
This capability enables different tasks to access the same data set at the same time, while ensuring data integrity. VSAM RLS reduces the contention between different tasks by locking data at a record level, leaving the other logical records within a control interval (CI) available for read/write by other tasks.
Figure 7-1 shows a sample implementation of VSAM RLS with multiple CICS.
Figure 7-1 Parallel Sysplex CICS with VSAM RLS
VSAM RLS provides these benefits:
•Enhances cross-system data sharing when the scope is sysplex.
•Improves performance and availability in CICS and non-CICS VSAM environments.
•Provides data protection after a system failure.
•Provides automation for data recovery.
•Provides full read/write integrity to your existing VSAM files. The user does not need to serialize using ENQ/DEQ macros.
•Allows CICS to register as a recoverable subsystem, which automates recovery processing and protects the data records to be recovered.
The level of sharing that is allowed between applications is determined by whether a data set is recoverable:
•Both CICS and non-CICS jobs can have concurrent read or write access to unrecoverable data sets. There is no coordination between CICS and non-CICS, so data integrity can be compromised.
•Non-CICS jobs can have read-only access to recoverable data sets concurrently with CICS jobs, which can have read or write access.
7.1.1 Supported data set types
VSAM RLS supports access to these types of data sets:
•Key-sequenced data set (KSDS)
•Entry-sequenced data set (ESDS)
•Relative record data set (RRDS)
•Variable-length relative-record data set cluster (VRRDS)
VSAM RLS also supports access to a data set through an alternate index, but it does not support opening an alternate index directly in VSAM RLS mode. Also, VSAM RLS does not support access through an alternate index to data stored under z/OS UNIX System Services.
Extended format, extended addressability, and spanned data sets are supported by VSAM RLS. Compression is also supported.
VSAM RLS does not support these objects:
•Linear data sets (LDS)
•Keyrange data sets
•KSDS with an imbedded index (defined with IMBED option)
•Temporary data sets
•Striped data sets
•Master catalogs and VVDSs
Keyrange data sets and the IMBED attribute for a KSDS are obsolete. You cannot define new data sets as keyrange or with an imbedded index anymore. However, there still might be old data sets with these attributes in your installation.
7.1.2 Coupling facility overview
The coupling facility (CF) is a shareable storage medium. It is Licensed Internal Code (LIC) running in a special type of IBM PR/SM™ logical partition (LPAR) in certain zSeries processors. It can be shared by the systems in one sysplex only. A CF makes data sharing possible by allowing data to be accessed throughout a sysplex with assurance that the data will not be corrupted and that the data will be consistent among all sharing users.
VSAM RLS uses a CF to perform data-set-level locking, record locking, and data caching. VSAM RLS uses the conditional write and cross-invalidate functions of the CF cache structure, avoiding the need for control interval (CI) level locking.
VSAM RLS uses the CF caches as store-through caches. When a control interval of data is written, it is written to both the Coupling Facility cache and the direct access storage device (DASD). This feature ensures that problems occurring with a CF cache do not result in the loss of VSAM data.
7.1.3 VSAM RLS sharing control data sets
The sharing control data set (SHCDS) is designed to contain the information required for DFSMS to continue processing with a minimum of unavailable data and no corruption of data when failures occur. The SCDS data can be either SMS or non-SMS managed.
The SHCDS contains the following data:
•Name of the CF lock structure in use
•System status for each system or failed system instance
•Time that the system failed
•List of subsystems and their status
•List of open data sets that use the CF
•List of data sets with unbound locks
•List of data sets in permit non-VSAM RLS state
Both the primary and secondary SHCDS contain the same data. With the duplexing of the data, VSAM RLS ensures that processing can continue in case VSAM RLS loses connection to one SHCDS or the control data set got damaged. In that case, you can switch the spare SHCDS to active.
To calculate the size of the sharing control data sets, follow the guidelines that are provided in z/OS DFSMSdfp Storage Administration Reference, SC26-7402.
 
Tip: Place the SHCDSs on separate volumes to maximize availability. Avoid placing SHCDSs on volumes for which there might be extensive volume reserve activity.
7.1.4 Data set sharing under VSAM RLS
The VSAM share options specification applies only when non-VSAM RLS access like NSR, LSR, or GSR is used. They are ignored when the data set is open for VSAM RLS access. Record-level sharing always assumes multiple readers and writers to the data set. VSAM RLS ensures full data integrity. When a data set is open for VSAM RLS access, non-VSAM RLS requests to open the data set fail.
Exception: SHAREOPTIONS(2,x)
For non-VSAM RLS access, SHAREOPTIONS(2,x) handled the same as VSAM RLS access. One user can have the data set open for read/write access and multiple users can have it open for read access only. VSAM does not provide data integrity for the readers.
If the data set is open for VSAM RLS access, non-VSAM RLS opens for read are possible. These are the only share options, where a non-VSAM RLS request to open the data set will not fail if the data set is already open for VSAM RLS processing. VSAM does not provide data integrity for non-VSAM RLS readers.
Non-CICS access
VSAM RLS access from batch jobs to data sets that are open by CICS depends on whether the data set is recoverable or not. For recoverable data sets, non-CICS access from other applications (that do not act as recoverable resource manager) is not allowed.
7.2 VSAM RLS locking
The granularity under LSR, NSR, or GSR is a control interval, whereas VSAM RLS serializes on a record level. With VSAM RLS, it is possible to concurrently update separate records in the same control interval. Record locks for UPDATE are always exclusive. Record locks for read depend on the level of read integrity.
Read integrity has three levels:
•NRI (no read integrity)
This level tells VSAM not to obtain a record lock on the record accessed by a GET or POINT request. This level avoids the overhead of record locking. This is sometimes referred to as a dirty read because the reader might see an uncommitted change made by another transaction.
Even with this option specified, VSAM RLS still performs buffer validity checking and refreshes the buffer when the buffer is invalid.
•CR (consistent read)
This level tells VSAM to obtain a shared lock on the record that is accessed by a GET or POINT request. It ensures that the reader does not see an uncommitted change made by another transaction. Instead, the GET or POINT request waits for the change to be committed or backed out. The request also waits for the exclusive lock on the record to be released.
•CRE (consistent read explicit)
This level has a meaning similar to that of CR, except that VSAM RLS holds the shared lock on the record until the end of the unit of recovery, or unit of work. This option is only available to CICS or DFSMStvs transactions. VSAM RLS does not understand end-of-transaction for non-CICS or non-DFSMStvs usage.
Figure 7-2 shows the following situation:
1. CICS transaction Tran1 obtains an exclusive lock on Record B for update processing.
2. Transaction Tran2 obtains an exclusive lock for update processing on Record E, which is in the same CI.
3. Transaction Tran3 needs a shared lock also on Record B for consistent read. It must wait until the exclusive lock by Tran1 is released.
4. Transaction Tran4 does a dirty read (NRI). It does not have to wait because in that case, no lock is necessary.
With NRI, Tran4 can read the record even though it is held exclusively by Tran1. There is no read integrity for Tran4.
Figure 7-2 Example of VSAM RLS serialization
VSAM RLS locking is performed in the coupling facility by using a CF lock structure (IGWLOCK00) and the XES locking services.
When contention occurs on a VSAM record, the request that encountered the contention waits for the contention to be removed. The lock manager provides deadlock detection. When a lock request is in deadlock, the request is rejected, resulting in the VSAM record management request completing with a deadlock error response.
7.3 Buffering under VSAM RLS
VSAM RLS is another method of buffering that you can specify in the MACRF parameter of the ACB macro. VSAM RLS and NSR/LSR/GSR are mutually exclusive. Unlike NSR, LSR, or GSR, the VSAM buffers are in a data space and not in private or global storage of a user address space. Each image in the sysplex has one large local buffer pool in the data space.
The first request for a record after data set open for VSAM RLS processing causes an I/O operation to read in the CI that contains this record. A copy of the CI is stored into the cache structure of the coupling facility and in the buffer pool in the data space.
Buffer coherency is maintained by using CF cache structures and the cross-system coupling facility (XCF) cross-invalidation function. For the example in Figure 7-3 on page 125, that means these steps:
1. System 1 opens the VSAM data set for read/write processing.
2. System 1 reads in CI1 and CI3 from DASD. Both CIs are stored in the cache structure in the Coupling Facility.
3. System 2 opens the data set for read processing.
4. System 2 needs CI1 and CI4. CI1 is read from the CF cache, and CI4 from DASD.
5. System 1 updates a record in CI1 and CI3. Both copies of these CIs in the CF are updated.
6. XCF notices the change of these two CIs and invalidates the copy of CI1 for System 2.
7. System 2 needs another record from CI1. It notices that its buffer was invalidated and reads in a new copy of CI1 from the CF.
Figure 7-3 Buffering under VSAM RLS
For further information about cross-invalidation, see z/OS MVS Programming: Sysplex Services Guide, SA22-7617.
7.4 VSAM RLS/CICS data set recovery
VSAM record-level sharing introduces a VSAM data set attribute called LOG. With this attribute, a data set can be defined as recoverable or non-recoverable. A data set whose log parameter is undefined or NONE is considered non-recoverable. A data set whose log parameter is UNDO or ALL is considered recoverable. For recoverable data sets, a log of changed records is maintained to commit and back out transaction changes to a data set.
A data set is considered recoverable if the LOG attribute has one of the following values:
•UNDO
The data set is backward recoverable. Changes made by a transaction that does not succeed (no commit was done) are backed out. This is also referred as transactional recovery.
•ALL
The data set is both backward and forward recoverable. In addition to the logging and recovery functions provided for backout (transactional recovery), CICS records the image of changes to the data set after they were made.
The forward recovery log records are used by forward recovery programs and products such as CICS VSAM Recovery (CICSVR) to reconstruct the data set in the event of hardware or software damage to the data set. This is referred to as data set recovery. For LOG(ALL) data sets, both types of recovery are provided: Transactional recovery and data set recovery. For LOG(ALL), you need to define a logstream in which changes to the data sets are logged.
A data set whose LOG parameter is undefined or NONE is considered as non-recoverable.
7.5 Backup and recovery of VSAM data sets
DFSMSdss supports backup-while-open (BWO) serialization, which can perform backups of data sets that are open for update for long periods of time. It can also perform a logical data set dump of these data sets even if another application has them serialized. Backup-while-open is a better method than using SHARE or TOLERATE(ENQFAILURE) for dumping VSAM data sets that are in use and open for update.
To allow DFSMSdss to take a backup while your data set is open, you need to define the data set with the BWO attribute or assign a data class with this attribute.
If you use the DSS BWO processing for a forward recoverable data set, CICS will log the start and end of the copy/backup operation. The data set can then be fully recovered from this backup.
For information about BWO processing, see z/OS DFSMSdss Storage Administration Reference, SC35-0424.
7.5.1 Recover a VSAM data set
Sometimes it is necessary to recover a data set, such as if it becomes broken. Recovery differs based on the type of data set:
•Recovery of a non-recoverable data set
Data sets with LOG(NONE) are considered non-recoverable. To recover such a data set, restore the last backup of the data set. All updates to this data set after the backup was taken are lost. If the backup was taken after a transaction failed (did not commit), the data in the backup might be inconsistent.
•Recovery of a backward recoverable data set
Data sets with the LOG(UNDO) attribute are considered backward recoverable. To recover such a data set, restore the last backup of the data set. All updates to this data set after the backup was taken are lost. The data in the backup is consistent.
•Recovery of a forward recoverable data set
Data sets with LOG(ALL) and a log stream assigned are forward recoverable. Restore the last backup of the data set. Then, run a tool like CICSVR, which uses the forward recovery log to redrive all committed updates until the data set became broken. No updates are lost.
7.5.2 Transactional recovery
During the life of a transaction, its changes to recoverable resources are not seen by other transactions. The exception is if you are using the NRI option, in which case you might see uncommitted changes.
Exclusive locks that VSAM RLS holds on the modified records cause other transactions that have read-with-integrity requests and write requests for these records to wait. After the modifying transaction is committed or backed out, VSAM RLS releases the locks and the other transactions can access the records.
If the transaction fails, its changes are backed out. This capability is called transactional recovery.
The CICS backout function removes changes made to the recoverable data sets by a transaction. When a transaction abnormally ends, CICS performs a backout implicitly.
In the example in Figure 7-4, transaction Trans1 is complete (committed) after Record 1 and Record 2 are updated. Transactional recovery ensures that either both changes are made or no change is made. When the application requests commit, both changes are made atomically. In the case of a failure after updating Record 1, the change to this record is backed out. This feature applies only for recoverable data sets, not for non-recoverable ones.
Figure 7-4 Sample committed and failed transactions
7.6 The SMSVSAM address space
SMSVSAM is the MVS job name of the VSAM RLS address space. It is started automatically at IPL time if RLSINIT(YES) is specified in the IGDSMSxx member of SYS1.PARMLIB, or was started by operator command.
The SMSVSAM address space needs to be started on each system where you want to use VSAM RLS. It is responsible for centralizing all processing necessary for cross-system sharing, which includes one connect per system to XCF lock, cache, and VSAM control block structures.
The SMSVSAM address space owns two data spaces:
•SMSVSAM
This space contains VSAM RLS control blocks and a system-wide buffer pool.
•MMFSTUFF
This space collects activity monitoring information that is used to produce SMF records.
The following terms are used to describe a VSAM RLS environment:
•RLS server
The SMSVSAM address space is also referred to as the RLS server.
•RLS client
Any address space that calls an RLS function that results in a program call to the SMSVSAM address space is called an RLS client. Those address spaces can be online applications and batch jobs.
•Recoverable subsystem
A subsystem is an RLS client space that registers with the SMSVSAM address space as an address space that provides transactional and data set recovery. CICS, for example, is a recoverable subsystem.
•Batch job
An RLS client space that does not first register with SMSVSAM as a recoverable subsystem is called a batch job. An example of such a batch job is HSM.
7.7 DFSMStvs introduction
The objective of DFSMStvs is to provide transactional recovery directly within VSAM. It is an extension to VSAM RLS. It allows any job or application that is designed for data sharing to read/write share VSAM recoverable files.
DFSMStvs is a follow-on project/capability based on VSAM RLS. VSAM RLS supports CICS and IMS as transaction managers. This feature provides sysplex data sharing of VSAM recoverable files when accessed through CICS or IMS. They provide the necessary unit-of-work management, undo/redo logging, and commit/back out functions. VSAM RLS provides the underlying sysplex-scope locking and data access integrity.
DFSMStvs adds logging and commit/back out support to VSAM RLS. DFSMStvs requires and supports the recoverable resource management services (RRMS) component as the commit or sync point manager.
DFSMStvs provides a level of data sharing with built-in transactional recovery for VSAM recoverable files that is comparable with the data sharing and transactional recovery support for databases provided by DB2 and IMSDB.
DFSMStvs enhances VSAM RLS to perform data recovery in these forms:
•Transactional recovery (see 7.5.2, “Transactional recovery” on page 126)
Before DFSMStvs, those two types of recovery were only supported by CICS.
CICS performs the transactional recovery for data sets defined with the LOG parameter UNDO or ALL.
For forward recoverable data sets (LOG(ALL)), CICS also records updates in a log stream for forward recovery. CICS itself does not perform forward recovery. It only performs logging. For forward recovery, you need a utility like CICSVR.
Like CICS, DFSMStvs also provides transactional recovery and logging.
Without DFSMStvs, batch jobs cannot perform transactional recovery and logging. That is the reason batch jobs were granted only read access to a data set that was opened by CICS in RLS mode. A batch window was necessary to run batch updates for CICS VSAM data sets.
With DFSMStvs, batch jobs can perform transactional recovery and logging concurrently with CICS processing. Batch jobs can now update data sets while they are in use by CICS. No batch window is necessary anymore.
Like CICS, DFSMStvs does not perform data set forward recovery.
7.7.1 Components used by DFSMStvs
The following components are involved in DFSMStvs processing:
•RRMS to manage the unit of recovery
DFSMStvs uses the RRMS to manage the unit of recovery that is needed for transactional recovery. For more information about RRMS, see 7.7.2, “DFSMStvs use of z/OS RRMS” on page 129.
•System logger to manage log streams
There are three kinds of logs used by DFSMStvs:
 – Undo log: Used for transactional recovery (back out processing)
 – Forward recovery log: Used to log updates against a data set for forward recovery
 – Shunt log: Used for long running or failed units of recovery
You can also define a log of logs for use to automate forward recovery.
These logs are maintained by the MVS system logger. For information about the various log types, see 7.7.5, “DFSMStvs logging” on page 131.
•VSAM RLS
Used for record locking and buffering. The need for VSAM RLS is discussed in prior sections.
Atomic commit of changes
DFSMStvs allows atomic commit of changes. That means, if multiple updates to various records are necessary to complete a transaction, either all updates are committed or none are, if the transaction does not complete. See also 7.5.2, “Transactional recovery” on page 126 and 7.7.3, “Atomic updates” on page 130.
Peer recovery
Peer recovery allows DFSMStvs to recover for a failed DFSMStvs instance to clean up any work that was left in an incomplete state and to clear retained locks that resulted from the failure. For more information about peer recovery, see z/OS DFSMStvs Planning and Operation Guide, SC26-7348.
7.7.2 DFSMStvs use of z/OS RRMS
z/OS provides RRMS that includes these features:
•Registration services
•Context services
•Resource Recovery Services (RRS), which acts as sync point manager
RRS provides the sync point services and is the most important component from a DFSMStvs use perspective.
DFSMStvs is a recoverable resource manager. It is not a commit or sync point manager. DFSMStvs interfaces with the z/OS sync point manager (RRS).
When an application issues a commit request directly to z/OS or indirectly through a sync point manager that interfaces with the z/OS sync point manager, DFSMStvs is called to participate in the two-phase commit process.
Other resource managers (like DB2) whose recoverable resources were modified by the transaction are also called by the z/OS sync point manager. This process provides a commit scope across the multiple resource managers.
RRS is a system-wide commit coordinator. It enables transactions to update protected resources managed by many resource managers.
It is RRS that provides the means to implement two-phase commit, but a resource manager must also use registration services and context services with Resource Recovery Services.
Two-phase commit
The two-phase commit protocol is a set of actions used to make sure that an application program either makes all changes to the resources represented by a single unit of recovery (UR), or it makes no changes at all. This protocol verifies that either all changes or no changes are applied even if one of the elements (such as the application, the system, or the resource manager) fails. The protocol allows for restart and recovery processing to take place after system or subsystem failure.
For a discussion of the term unit of recovery, see 7.7.4, “Unit of work and unit of recovery” on page 131.
7.7.3 Atomic updates
A transaction is known as atomic when an application changes data in multiple resource managers as a single transaction, and all of those changes are accomplished through a single commit request by a sync point manager. If the transaction is successful, all the changes are committed. If any piece of the transaction is not successful, then all changes are backed out.
An atomic instant occurs when the sync point manager in a two-phase commit process logs a commit record for the transaction. Figure 7-5 shows a sample atomic update.
Figure 7-5 Example of an atomic update
For more information about recovering an uncompleted transaction, 7.5.2, “Transactional recovery” on page 126.
7.7.4 Unit of work and unit of recovery
A unit of work (UOW) is the term used in CICS publications for a set of updates that are treated as an atomic set of changes.
RRS uses unit of recovery to mean much the same thing. Thus, a unit of recovery is the set of updates between synchronization points. There are implicit synchronization points at the start and at the end of a transaction. Explicit synchronization points are requested by an application within a transaction or batch job. It is preferable to use explicit synchronization for greater control of the number of updates in a unit of recovery.
Changes to data are durable after a synchronization point. That means that the changes survive any subsequent failure.
Figure 7-6 shows three units of recovery, noted as A, B, and C. The synchronization points between the units of recovery can be one of these types:
•Implicit: At the start and end of the program
•Explicit: When requested by commit
Figure 7-6 Unit of recovery example
7.7.5 DFSMStvs logging
DFSMStvs logging uses the z/OS system logger. The design of DFSMStvs logging is similar to the design of CICS logging. Forward recovery logstreams for VSAM recoverable files will be shared across CICS and DFSMStvs. CICS will log changes made by CICS transactions, while DFSMStvs will log changes made by its callers.
The system logger
The system logger (IXGLOGR) is an MVS component that provides a rich set of services that allow another component or an application to write, browse, and delete log data. 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.
Types of logs
Various types of logs are involved in DFSMStvs (and CICS) logging:
•Undo logs (mandatory, one per image) - tvsname.IGWLOG.SYSLOG
The backout or undo log contains images of changed records for recoverable data sets as they existed before being changed. It is used for transactional recovery to back out uncommitted changes if a transaction failed.
•Shunt logs (mandatory, one per image) - tvsname.IGWSHUNT.SHUNTLOG
The shunt log is used when backout requests fail and for long running units of recovery.
•Log of logs (optional, shared with CICS and CICSVR) - Default name is CICSUSER.CICSVR.DFHLGLOG
The log of logs contains copies of log records that are used to automate forward recovery.
•Forward recovery logs (optional, shared with CICS) - Name of your choice
The forward recovery log is used for data sets defined with LOG(ALL). It is used for forward recovery. It needs to be defined in the LOGSTREAMID parameter of the data set.
The system logger writes log data to log streams. The log streams are put in list structures in the Coupling Facility (except for DASDONLY log streams).
As Figure 7-7 shows, you can merge forward recovery logs for use by CICS and DFSMStvs. You can also share it by multiple VSAM data sets. You cannot share an undo log by CICS and DFSMStvs; you need one per image.
Figure 7-7 DFSMStvs logging
7.8 Accessing a data set with DFSMStvs
The MACRF options NRI, CR, and CRE are described in 7.2, “VSAM RLS locking” on page 122. CRE gives DFSMStvs access to VSAM data sets open for input or output. CR or NRI gives DFSMStvs access to VSAM recoverable data sets only for output.
You can modify an application to use DFSMStvs by specifying RLS in the job control language (JCL) or the ACB and having the application access a recoverable data set using either open for input with CRE or open for output from a batch job.
Table 7-1 shows the cases in which DFSMStvs is called.
Table 7-1 DFSMStvs and VSAM RLS usage
Data set type and Type of OPEN
NRI
CR
CRE
Recoverable open for input
VSAM RLS
VSAM RLS
DFSMStvs
Recoverable open for output
DFSMStvs
DFSMStvs
DFSMStvs
Non-recoverable open for input
VSAM RLS
VSAM RLS
DFSMStvs
Non-recoverable open for output
VSAM RLS
VSAM RLS
DFSMStvs
DFSMStvs is always called in these circumstances:
•RLS and CRE are specified in the JCL or MACRF parameter of the ACB macro
CRE is also known as repeatable read.
•RLS is specified in the JCL or MACRF parameter of the ACB macro and the data set is recoverable and it is opened for output (update processing)
This feature allows DFSMStvs to provide the necessary transactional recovery for the data set.
7.9 Application considerations
For an application to participate in transactional recovery, it must first understand the concept of a transaction. It is not a good idea to modify an existing batch job to use DFSMStvs with no further change, as doing so causes the entire job to be seen as a single transaction. As a result, locks would be held and log records would need to exist for the entire life of the job. This circumstance can cause a tremendous amount of contention for the locked resources. It can also cause performance degradation as the undo log becomes exceedingly large.
7.9.1 Break processing into a series of transactions
To use the DFSMStvs capabilities, break down application processing into a series of transactions. Have the application issue frequent sync points by calling RRS commit and backout processing (MVS callable services SRRCMIT and SRRBACK).
VSAM RLS and DFSMStvs provide isolation until commit/backout. Consider the following rules:
•Share locks on records accessed with repeatable read.
•Hold write locks on changed records until the end of a transaction.
•Use commit to apply all changes and release all locks.
•Information extracted from shared files must not be used across commit/backout for the following reasons:
 – Need to reaccess the records.
 – Cannot get a record before a sync point and update it after.
 – Do not position to a record before a sync point and access it after.
7.9.2 Modify the program or JCL to request DFSMStvs access
You need to change the ACB MACRF or JCL specifications for a data set to request DFSMStvs access. See the previous section for more information.
Prevent contention within a unit of recovery
If the application uses multiple RPLs, care must be taken in how they are used. Using various RPLs to access the same record can cause lock contention within a UR.
Handle potential loss of positioning at sync point
The batch application must have a built-in method of tracking its processing position within a series of transactions. One potential method of doing this is to use a VSAM recoverable file to track the job's commit position.
Do not use file backup/restore as a job restart technique
Today's batch applications that update VSAM files in a non-shared environment can create backup copies of the files to establish a restart/recovery point for the data. If the batch application fails, the files can be restored from the backup copies, and the batch jobs can be executed again. This restart/recovery procedure cannot be used in a data sharing DFSMStvs environment because restoring to the point-in-time backup erases changes made by other applications that share the data set.
Instead, the batch application must have a built-in method of tracking its processing position within a series of transactions. One potential method of doing this is to use a VSAM recoverable file to track the job’s commit position. When the application fails, any uncommitted changes are backed out.
The already-committed changes cannot be backed out because they are already visible to other jobs or transactions. In fact, it is possible that the records that were changed by previously-committed UR were changed again by other jobs or transactions. Therefore, when the job is rerun, it is important that it determines its restart point and not attempt to redo any changes it had committed before the failure.
For this reason, it is important that jobs and applications using DFSMStvs be written to run as a series of transactions and use a commit point tracking mechanism for restart.
7.10 The DFSMStvs instance
DFSMStvs runs in the SMSVSAM address space as an instance. The name of the DFSMStvs address space is always IGWTVnnn, where nnn is a unique number per system as defined for TVSNAME in the PARMLIB member IGDSMSxx. This number can be in the range 0 - 255. You can define up to 32 DFSMStvs instances, one per system. An example is IGWTV001.
As soon as an application that does not act as a recoverable resource manager has VSAM RLS access to a recoverable data set, DFSMStvs is called (see also 7.8, “Accessing a data set with DFSMStvs” on page 133). DFSMStvs calls VSAM RLS (SMSVSAM) for record locking and buffering. With DFSMStvs built on top of VSAM RLS, full sharing of recoverable files becomes possible. Batch jobs can now update the recoverable files without first quiescing CICS's access to them.
As a recoverable resource manager, CICS interacts directly with VSAM RLS.
7.10.1 Interacting with DFSMStvs
This section provides a brief overview of a few commands that were introduced particularly for displaying and changing DFSMStvs-related information.
There are a few display commands you can use to get information about DFSMStvs:
•To display common DFSMStvs information:
DISPLAY SMS,TRANVSAM{,ALL}
This command lists information about the DFSMStvs instance on the system where it was issued. To get information from all systems, use ALL. This information includes name and state of the DFSMStvs instance, values for AKP, start type, and the quiesce timeout value, and also the names, types, and states of the used log streams.
•To display information about a particular job that uses DFSMStvs:
DISPLAY SMS,JOB(jobname)
The information about the particular job includes the current job step, the current ID, and status of the unit of recovery used by this job.
•To display information about a particular unit of recovery currently active within the sysplex:
DISPLAY SMS,URID(urid|ALL)
This command provides information about a particular UR in the sysplex or about all URs of the system on which this command was issued. If ALL is specified, you do not obtain information about shunted URs and URs that are restarting. The provided information includes age and status of the UR, the jobname with which this UR is associated, and the current step within the job.
•To display entries currently contained in the shunt log:
DISPLAY SMS,SHUNTED,{SPHERE(sphere)|
URID(urid|ALL)}
Entries are moved to the shunt log when DFSMStvs is unable to finish processing a sync point for them. There are several reasons that this might occur, including an I/O error. Depending on what was specified, you get information for a particular VSAM sphere, a particular UR, or for all shunted URs in the sysplex.
•To display information about logstreams that DFSMStvs is currently using:
DISPLAY SMS,LOG(logstream|ALL)
If ALL is specified, information about all log streams in use is provided from the system on which the command is issued. The output includes the status and type of the log stream, the job name, and URID of the oldest unit of recovery using the log. It also uncludes a list of all DFSMStvs instances that are using the log.
•To display information about a particular data set:
DISPLAY SMS,DSNAME(dsn)
Use this command to display jobs currently accessing the data set using DFSMStvs access on the systems within the sysplex.
IDCAMS command SHCDS
The IDCAMS command SHCDS was enhanced to display and modify recovery information related to DFSMStvs. For more information about this command, see z/OS DFSMS Access Method Services for Catalogs, SC26-7394.
 
Important: This chapter simply provided an overview of new operator commands to understand how to work with DFSMStvs. Before using these commands (other than the DISPLAY command), read the official z/OS manuals carefully.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.124.232