Prevent batch job from using too many tape UCBs with MIM

book

Article ID: 145095

calendar_today

Updated On:

Products

CA MIM Resource Sharing (MIM) CA MIM Tape Sharing (MIA)

Issue/Introduction

We have TSO users submitting testing batch jobs under their TSO USERID allocating hundreds of tape UCBs causing production batch to go into allocation recovery until our operation team can determine the problem job and then cancel it. This is causing delays in our batch window. 
What is needed: if a job that begins with N* and is attempting to allocate more than 25 ucbs concurrently, do not allow the job to run.

Can this be accomplished with MIA?

   

Environment

Release : 12.5

Component : MIA

Resolution

Job reserve will not guarantee that a job will use the reserved devices unless FORCE=YES is coded on the VARY command. However, it will ensure that no other job will use those devices. Here are some examples:

VARY dd00-dd18,JOB=N*,LOCAL


Job N1 runs and needs 27 devices. It will try to allocate 25 of the devices within the VARY range, but the remaining 2 devices will be choses from outside this range.

Any job that does not begin with N*, will never be able to allocate any of the 25 devices within this range.


Next example:

VARY dd00-dd18,JOB=(N*,FORCE=YES),LOCAL


Job N1 runs and needs 27 devices. MIM will remove all but 25 reserved devices from the list, but the job needs 27. The job will fail with a JCL error which is what we want.

Again, any job that does not begin with N*, will never be able to allocate any of the 25 devices within this range.


In order to prevent bottlenecks within this range, you can spread out the allocations. For example:


VARY dd00-dd18,JOB=(N1*,FORCE=YES),LOCAL

VARY dd19-dd31,JOB=(N2*,FORCE=YES),LOCAL

VARY dd32-dd4A,JOB=(N3*,FORCE=YES),LOCAL

Etc.


Remember that any job that begins with something other than N* will not be able to allocate any of these devices. So, you don't want to reserve too many.