This topic discusses the initial implementation of DCS and the steps to take after it is running successfully in your installation.

Introduction

The DCS Component provides you with all the facilities necessary to exercise complete control in the automation of the data set contention resolution process.

DCS capabilities can be categorized into two related but distinct categories:

• Automation.
• Control.

To get the benefits of DCS automation you do not have to resort to any customization. We advise you to initially implement the DCS Component the “easy way”. Later on, you can start exercising control by fine-tuning the product to reflect your particular installation needs. This topic describes the behavior of DCS when it is allowed to do “its own thing”.

Automating Dataset Contention Resolution

A straight implementation of DCS, without providing any installation “guidance”, gives you superior automation.

In fact, if you leave DCS alone to do “its own thing”, it eliminates all the problems described in the next section as “system noise”. This is possible because DCS assumes control of the process to determine whether or not all the data sets are available for a job.

A Self- Employed DCS

DCS allows the system to do all the hard work in determining the data sets needed, the last step in the job that references them, and the type of control to request for each data set.

Once the system has completed that task, DCS takes over. It makes the request to ENQ/DEQ services on behalf of the initiator. This request is made as early as possible in the job initiation process. It is done before IEFUJI is invoked.

If the data sets are available, then DCS gets out of the way so work can proceed in the usual manner, but with the assurance that all data sets have already been secured. By thetime IEFUJI is executed, the potential for the job being requeued no longer exists.

If the data sets are not available, DCS produces a terse message indicating that job initiation cannot proceed because of data set contention. The job is then quietly requeued and placed in a special TM HOLD for jobs experiencing data set contention. All the SMF exits, SMF records, requeuing messages, etc., are eliminated.

As you would expect, DCS monitors the availability of data sets to determine when the job should be released. When the data set, or data sets, become available, DCS proceeds to release the job from its DCS HOLD. This technique totally eliminates the potential conflict with a JES2 HOLD that might have been issued while the job was waiting for data sets.

So a DCS operating under its own rules gives complete automation of the data set conflict resolution and also eliminates all “system noise”:

• It eliminates all superfluous messages. No clutter.
• It prevents IEFUJI from executing. Your job schedulers or in-house software do not have to undo, at job termination, whatever IEFUJI may have done at job initiation.
• Jobs are placed in a special data set contention HOLD, completely eliminating mix-ups with JES2 HOLD.

DCS also gives notification to TSO users that are holding data sets needed by jobs or started tasks. This is referred to as “Nagging”.

DCS Nagging

Without any installation guidance, DCS takes it upon itself to Nag TSO data set holders. The NAG is a two line message with the following format:

DTM7108I PLEASE FREE DATASET dataset-name time
DTM7109I THIS DATASET IS REQUIRED BY jobnumber jobnameThe holder is notified 3 times 5 minutes apart if a batch job needs the data set.

Installation Summary

For DCS to fully automate the data set contention process, you do not have to do anything beyond your product installation.

DCS will operate under the following defaults:

• Automatic requeuing of jobs in DCS HOLD when contention occurs.
• Automatic releasing of jobs when data sets become available.
• STANDBY as the data set service level.
• 3 Nagging Messages to TSO users, 5 minutes apart when batch jobs need a data set.
• ¸¸99 Nagging messages to TSO users, 1 minute apart when started tasks need a data set.
• Automatic freeing of data sets when the TSO holder of the data set is the job submitter. This only takes place if the data set is allocated but not in use.

What To Do Next

Once you have DCS taking care of your data set contention management “in its own way,” you might want to learn more by making use of its reporting capabilities to see which situations can be improved. The next sections present a brief discussion of the reporting facilities available, followed by a description of how to implement your own DCS rules.

DCS Reporting

From the reports (or simply because you already know) you might find a number of situations that require attention. To DCS, unless otherwise instructed, “all jobs are equal.” From your position of knowledge, you know that “some jobs are more equal than others,” therefore, they should be getting preferential treatment. You might also find that some data sets are causing contention because they are being requested for exclusive control by some jobs for which you know SHR will do. It is also possible that some TSO users are holding data sets when they should not. You probably can think of many other situations that need remedy.

So how can you remedy these situations? You would like DCS to be a bit less independent and become more accommodating to your specific needs. You want to convert DCS from being self-employed to being your faithful servant. Here is where DCS truly excels.

DCS can be instructed to handle data set contention situations in a way which precisely reflect your needs, no matter how detailed and specific they are.

DCS collects all the necessary information to be able to produce, upon request, two types of reports:

• One report gives you information on jobs that were delayed. It shows how many times the job was delayed, the number of minutes that the job was delayed waiting for data sets, and the data sets that were involved.
• The other report gives you information on data sets that cause contention problems. The number of minutes that the data set was in contention are shown, together with the jobs affected and the holders of the data set.

The two reports together provide you with a complete picture of the problem: the jobs that were affected, the data sets that were involved, and the holders of the data sets.

Activating the reporting system should probably be your next task after you have DCS running. This is covered in The Dataset Contention Reporting System.

Implementing Your Own DCS Rules

After you have determined what actions you would like DCS to take when data set contention occurs, you can code DAL to implement your rules. See the DAL/JAL space and the DAL Reference space for details of how to code DAL.

DAL source statements must be converted into a format that ThruPut Manager can use. The Language Processor is supplied for this purpose.

Your DAL source statements are the input to the Language Processor, and the output is DAL internal text, suitable for use by ThruPut Manager. For complete details about the JCL and usage of the Language Processor, see the DAL/JAL User Guide.

The sequence required to implement DAL is:

• Write DAL statements defining your installation’s rules.
• Run the Language Processor to verify your DAL source statements, and convert them into the internal text required by ThruPut Manager.
• Add the statement DAL LOAD to the TMSS initialization statements. This indicates that there are installation rules and where they can be found (DAL internal text).

Note: To load a new DAL does not require that you start TMSS again. The DAL REFRESH command is provided to allow you to refresh DAL dynamically.

If your DAL does not work as intended, you can use the DAL trace facility to help you debug the problem. DAL tracing can be turned on at startup by using the DAL TRACE initialization statement, or after startup by using the DAL TRACE operator command.

You can find more information about loading and tracing DAL in the manual DAL/JAL User Guide.

The topic that follow describe the facilities that make DCS a “precision tool” to suit your installation requirements.

Facilities Summary