How to force users to logoff who are holding important files

[gmainak]

Hi All,

I'm new to REXX and CLIST environment however I can use JCL, VSAM and other mainframe utilities to some extent. I have a typical problem where multiple users work on the same set of VSAM files. However it's strictly forbidden to open files in I/O mode other than if not utterly required during batch window. I'm finding certain users are doing this repetitively even after multiple warnings. And due to their lack of concentration, batch jobs are failing with unavailability of resources regularly.

I want to know is there a REXX code available which can be run through a JCL at the beginning of the batch and force log-off all the users who are currently holding a important file. I have the list of all users in the system as well as the list of all the important files.

Please help. Thanks in advance for the assistance.
Gmainak

[Maxime B]

Wouldn't it be a better practice to allow only update access to the dataset to critical batch job and give only read access to users?

[steve-myers]

...I want to know is there a REXX code available which can be run through a JCL at the beginning of the batch and force log-off all the users who are currently holding a important file. I have the list of all users in the system as well as the list of all the important files.

Please help. Thanks in advance for the assistance.
Gmainak

No. The system assigns control of all datasets specified in JCL to the job before the first step executes, so your code would be executed too late. Note that if the job cannot get control of the datasets the job will wait until other users (which may be other batch jobs, not TSO users) release the datasets; the job is not automatically canceled. The other issue is your ID may not be authorized to cancel these users, so the idea might not work in any event.

[gmainak]

No. The system assigns control of all datasets specified in JCL to the job before the first step executes, so your code would be executed too late. Note that if the job cannot get control of the datasets the job will wait until other users (which may be other batch jobs, not TSO users) release the datasets; the job is not automatically canceled. The other issue is your ID may not be authorized to cancel these users, so the idea might not work in any event.

Actually during batch many of these critical datasets get delete/defined during processing. Hence the job fails during delete step because the intended file had been in use with resource contention error. Also regarding the access, our ids do have access to purge all of those user ids as during these situation we do purge them manually and rerun the job.

[steve-myers]

Put the dataset names you are reallocating into your JCL, like this:

Code: Select all

//A       EXEC PGM=IDCAMS
//SYSPRINT DD  SYSOUT=*
//SYSIN    DD  *
  DELETE aaa CLUSTER
  DEFINE CLUSTER(NAME(aaa) ...
//HOLDEM  EXEC PGM=IEFBR14
//AAA      DD  DISP=OLD,VOL=REF=SYS1.SVCLIB,
//             DSN=aaa

Put the IEFBR14 step as the last step in the job. The AAA DD statement ensures that your job controls the dataset name for the duration of the job; it will not interfere with the DELETE and DEFINE commands in the IDCAMS step, and the other allocation parameters ensure there won't be a problem if the dataset does not exist when the IEFBR14 step executes. The SYS1.SVCLIB dataset is required to IPL the system, but is not used after the IPL, so it should always be in the catalog.

The Rexx experts that monitor this board might be able to come up with a solution, but this solution is more reliable.

[gmainak]

Put the IEFBR14 step as the last step in the job. The AAA DD statement ensures that your job controls the dataset name for the duration of the job; it will not interfere with the DELETE and DEFINE commands in the IDCAMS step, and the other allocation parameters ensure there won't be a problem if the dataset does not exist when the IEFBR14 step executes. The SYS1.SVCLIB dataset is required to IPL the system, but is not used after the IPL, so it should always be in the catalog.

Thank you Steve for a nice solution. However this way we are getting more and more dependent on the operator. We are implementing this solution as a interim measures. I'll continue my search for a more robust solution though.. Thanks again

[dick scherrer]

Hello,

If this is only an intrim workaround, you might consider making a copy of the data for these users and not let them read the "real" file(s).