Move Faster and Wait Less: Dataset Contention Services with ThruPut Manager
Dataset contention is virtually impossible to avoid. With many developers touching myriad batch programs, systems people of all types requesting files and batch streams being time-shifted due to business needs or system problems, the likelihood of more than one user requesting a file is extremely high. That’s why you have to have an automated way to manage it: so that work continues to be processed in the priority order you wish.
Wouldn’t it be great to have a way to automatically nag a user to give up a dataset you need for production started tasks or batch? Compuware ThruPut Manager offers NAGging Services as part of the Dataset Contention Services (DCS) component that can be installed on top of TM.
It comes with default values to control the number of times a TSO user is nagged and how often. These vary depending on whether the dataset is needed for a started task (more critical) or a batch job.
For started tasks, TM will NAG 99 times every minute. For batch jobs, users get three nags, five minutes apart. But you can modify the NAGging: how often, what the message says and the time interval. And you can define which users are NAGged, define which are excluded and set the frequency and time by group. Below is the default message users receive.
DTM708I PLEASE FREE DATASET dataset-name time
DTM7109I THIS DATASET IS REQUIRED BY jobnumber jobname
Using the job language of TM, JAL, you can redefine the text with a DCS_NAGDEF statement. If you wish to change the frequency of NAGging to 99 times every 2 minutes for all users, use the following JAL:
IF … /*IDENTIFY THE JOB*/
DCS NAG $DEFAULT USERID(*) REPEAT 99,2)
The options are wide. Check out the DCS Systems Programming Guide for more examples.
Though a very cool option, NAGging is only one of the many functions available through DCS. Through DCS, TM will manage all instances of dataset contention by automating the holding and releasing of jobs, using a concept of dataset service level. This empowers you to decide which jobs get priority when the dataset becomes available.
There are a number of additional facilities which you can enable such as customized ALERTing and dataset reservation, which ensures job success by ENQing on the real dataset name during job initiation. If there is a conflict, the job can be requeued. Use JAL and DAL to customize your implementation. You can even add JECL to allow users to implement some customization of their own. However, you decide upfront how much control to give them, a little or a lot, specified by job name.
In short, if you feel the need for speed, keep dataset contention from slowing down your system and add DCS to your Thruput Manager implementation.
Latest posts by Denise Kalm (see all)
- The DevOps Balancing Act of Measurement and Reward - October 9, 2018
- The Evolving Responsibility of Mainframe Application Testing in DevOps - September 6, 2018
- Solving the Next Biggest Threat to Corporate Stability: Data Privacy - August 2, 2018