The DFR/NDF specification in the ACB does not apply to either RLS or DFSMStvs.

For sequential and skip-sequential processing, RLS and DFSMStvs defer writing the current data buffer of the string. A subsequent request against the RPL in the string that positions the string to another control interval (CI), causes the modified buffer to be written to DASD.

VSAM hides load mode with either RLS or DFSMStvs access. Loading a data set in either RLS or DFSMStvs mode forfeits load mode optimizations available with nonshared resource access (for example, SPEED). If you want these options, load the data set with nonshared resource access.

An OPEN request for a data set with RLS or DFSMStvs does not establish an implicit position to at beginning of the data set. An explicit POINT request or GET NSP request is required.

VSAM RLS and DFSMStvs obtain a record lock on POINT for consistent read and consistent read explicit. The record positioned to by the POINT request is the record that is returned on a subsequent GET SEQ request.

You can use the DISP=OLD parameter for data sets that are accessed with RLS or DFSMStvs, but this is not recommended.

Recommendation: Use the DISP=SHR parameter. The DISP=OLD parameter causes backouts to fail because DFSMStvs tries to allocate the data set with the DISP=SHR parameter.

The access method services DELETE command causes an exclusive enqueue on the data set name for the length of the job. Backouts in the same job fail, even if they are in different steps, because they are unable to allocate the data set dynamically.

For RLS and DFSMStvs access, use SHAREOPTIONS(2,X). This allows concurrent non-RLS readers while the data set is in use in RLS or DFSMStvs mode. RLS and DFSMStvs ignore all other specifications and assume that there are multiple concurrent writers and readers.

The parameters on the DEFINE command that are ignored or changed for RLS are also ignored or changed for DFSMStvs.

RLS and DFSMStvs support alternate indexes through path access. However, RLS and DFSMStvs do not support a direct open request of an alternate index.

Neither RLS nor DFSMStvs access supports the JRNAD exit. RLS and DFSMStvs ignore it. Use the RLSWAIT exit to perform a similar function; RLS and DFSMStvs access supports the RLSWAIT exit.

The RLSWAIT exit is optional. Applications that cannot tolerate VSAM suspending the execution unit that issued the original record management request use it. The exit must do its own wait processing. The wait processing is associated with the record management request that is being asynchronously executed. When the record management request is complete, VSAM posts the event control block (ECB) specified in the request parameter list of an event control block (RPLECB).

A VSAM RLS or DFSMStvs record management request task must be the same as the task that opened the ACB or at the same hierarchical level as the record management request.Issue VSAM RLS and DFSMStvs record management requests in AMODE 24 or AMODE 31. Issue OPEN, CLOSE, IDAQUIES, and record management requests in task mode, non-cross-memory mode, and primary ASC mode. A functional recovery routine (FRR) must not be in effect.

DFSMStvs does not support callers who are running in service request block (SRB) mode.

Unless privately managed contexts are used, the application must issue all record management, commit, and backout requests pertaining to a given unit of recovery under the same task control block (TCB). This is because a unit of recovery is associated with a context and a context is associated with a TCB. Any requests issued under a different TCB would be handled under the context associated with that TCB and would, therefore, belong to a different unit of recovery. The only exception to this is the case in which a resource manager is using privately managed contexts and switching them between TCBs.

A work manager, which takes work requests and parcels them out to tasks, might create privately managed contexts. These contexts and the units of recovery associated with them can be moved around, unlike the default contexts that every TCB in the system has. So, if the work manager knows that a piece of work it is about to submit belongs to a particular unit of recovery, the work manager can take that unit of recovery's privately managed context and attach it to the TCB before giving that TCB the work to do.