This topic introduces you to the ALTER facility of DCS, which allows you to alter the first parameter of the DISP keyword, and DCS data set Reservation.

Introduction

With DCS, you can analyze the usage of the disposition parameter for each DD statement that is associated with a permanent data set. Depending on what you find, you can instruct DCS to take one of the following actions:

• Fail or warn the job.
• Alter the disposition for that DD statement.

Requests for DCS to alter the disposition are done at the DD statement level. All the relevant information about the job and the particular DD statement is available to you. As a result, you can provide specific rules for the ALTERation of the first parameter of the DISP keyword.

DCS also supports data set Reservation, which alleviates problems with ENQs for GDGs and data set aliases by changing the timing of the actual ENQ.

Implementation Summary

The ALTER facility is only available in DAL. To make use of this facility:

• Code the appropriate DAL statements.
• Create DAL internal text with the Language Processor.
• Implement the DAL.

The data set Reservation facility is activated with the DR keyword of the DCS SET statement as described in “TMSS Initialization Statements” in the Base Product: System Programming Guide. To use this facility:

• Code DR(YES) on the DCS SET initialization statement.
• If there are jobs for which you do not want data set Reservation, code JAL to detect these jobs and turn off data set Reservation support.

Dependencies

There are no dependencies to request ALTER services, other than activating the DAL you have coded with the ALTER rules.

data set Reservation support does not have any dependencies.

TMSS Initialization Statements

To activate the DAL for disposition alteration, a DAL LOAD statement is required.

To activate data set Reservation support, DR(YES) must be included on the DCS SET statement.

These statements are documented in Base Product: System Programming Guide “TMSS Initialization Statements.”

How to Request Disposition ALTERing

Requesting alteration of disposition is done with a DCS action statement in DAL. Normally you set up the rules for alteration using the logic capabilities available in DAL. For example, you might want to enforce that any reference to SYS1.MACLIB as SYSLIB have a disposition of SHR. The DAL statements would look like this:

...
IF ($DSNAME(SYS1.MACLIB) & $DDNAME(SYSLIB)) /*DETECT USAGE OF MACLIB */ DCS ALTER DISP1(SHR)
...The DCS ALTER request operates only on DD statements with a DD name of SYSLIB and a DSN of ‘SYS1.MACLIB’.

A more reasonable approach might be the following: in addition to the above statements, include logic to test for the disposition. If it is already SHR, do not do anything. If it is OLD, issue a warning message and ALTER the disposition:

Considerations for Disposition Altering

• The ALTER is only applicable to the first parameter for the DISP keyword. This parameter is known in the JCL manual as the data set’s status.
• The alteration is for the purpose of data set enqueueing.
• A DCS ALTER is associated with the DD statement being processed by DAL. It does not alter other DD statements referring to the same data set.
• If you want to change the disposition for all the occurrences of a data set in a job, you must do it for each DD statement.
• If the original specification of the DD statement is NEW, or MOD for a non-existing data set, the DCS ALTER statement does not take effect.
• The intended use is to ALTER OLD to SHARED so unnecessary serialization can be prevented. It can also be used to ALTER SHARED to OLD, if a particular situation calls for this change. For example, you might not want to allow tape data sets to be referenced as SHARED since it causes problems with volume contention.
• If you are “looking” for a JOBLIB DD statement, remember that it occurs before the first EXEC statement. Any descriptor associated with a step, such as program name or step name, will contain blanks.
• Only DD statements for permanent data sets cause DAL to be invoked.

Using Data set Reservation

Data sets referred to by aliases or relative GDG numbers can result in data set reservation failures at step allocation time, when the real data set name is resolved. This is because without data set Reservation, ENQs for the absolute data set name are not obtained until that point.

DCS can eliminate these failures by ENQing on the real data set name during job initiation. At that time, if there is a conflict the job can be requeued. For tape data sets, the data set Reservation ENQ is upgraded to “exclusive” if necessary, eliminating problems with volume contention.

All that is required to take advantage of DCS data set Reservation is to activate it as described above. To make a job exempt from data set Reservation, add JAL statements to detect the job and switch off the support:

DCS SET DR(NO)You can detect whether a DCS SET statement has been executed for a job with:

IF ($JXDCS_DR(YES))

...Note that when data set Reservation is active, a GDG base is not allowed to receive DCS SERVICE CLAIM. This ensures that the absolute data set name, associated with a relative generation data set, remains accurate.

Facilities Summary