MVSFORUMS.com

[abhisun]

Hello Folks,

One of my production job abended because it could not open a VSAM dataset. That dataset was in use by some other production job at that point of time.

Now I want to know which job was using that dataset ? Is there a way to find out which job(s) accessed a VSAM dataset in past ?

PS- reg. current usage, I know that we can find the name of the job(s) using TSO WHOHAS or TSODSN command.

Thanks!

[kolusu]

abhisun,


Check your system log and you should be able to find the job who had the vsam dataset.

Another way round is you know the run time of your job. so if this is a scheduled environment then check the jobs which ran around the same time and see if they are accessing the same file.

If you have ca-7 then there is an option to list the dataset contentions

Hope this helps...

Cheers

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[abhisun]

Thanks a lot Kolusu!

I already tried #2 option but no luck! and am still looking for that CA-7 option.

Can you please let me know how to access the system logs ?

Thanks again for your help!

[kolusu]

Abhisun,

You can access your syslog from SDSF .

[abhisun]

Thanks Kolusu ! great piece of information

unfortunately I do not have access to see LOGs.

[zoobink]

All VSAM accesses should be logged in SMF records.
Record Type 62 (3E) -- VSAM Component or Cluster Opened

[souvik_225]

Abhisun,

You said that "One of my production job abended because it could not open a VSAM dataset. That dataset was in use by some other production job at that point of time. " ... if you look into the joblog of ur abended production job , I am sure you will get to see a contention error message(in my shop it shows the User id or Production/Test JOb name with which it was having contention).

Also it is good practise to use the LISTCAT option in a step previous to running your update Job , as such the job will go into hold and not abend( I am assuming that second Job was updating the same VSAM file, otherwise the second job would have automatically gone into a wait state)
_________________
Thanks and Regards,
Souvik Upadhyay

[zoobink]

[souvik_225]

Hi zoobink,
Say we have a job A running at step 10 which is updating the VSAM file ABC.KSDS.VSAM .

Now say we have job B starting where we have step 10 , which has :
//step10 EXEC PGM=IDCAMS
//SYSIN DD *
LISTCAT LEVEL(ABC.KSDS.VSAM) ALL
//SYSPRINT DD SYSOUT=*

and step 20 has a program which will also be updating the same VSAM file.

Now isn't it that step10 of Job B will go into hold and hence stop the execution of step 20 of job B??? Please correct me if I am wrong , as this is what there is in my production jobs ...
_________________
Thanks and Regards,
Souvik Upadhyay

[zoobink]

No,

The LISCAT command only retrieves information from the CATALOG and VVDS.

It doesn't perform any RESERVE or ENQ.

The two programs can and should be written so that ENQ and DEQ functions are handled within the two programs to avoid corruption, but the LISTCAT has no effect.

[Maton_Man]

As identified, allocating your VSAM file with DISP=OLD will cause your job to wait until the VSAM file is available (if it is held by another job or user).

If if you could use LISTCAT (which you can't), logically it would only enqueue the dataset for as long as it took to do the LISTCAT which wouldn't prevent others from enqueueing it in the meantime. Since LISTCAT doesn't enqueue anyway you are wasting your time.

To find out who has the file you need to try what has already been suggested, either yourself or through one of your system programmers, ie:

* SDSF Log
* SMF records

If you really get desperate you could even use RACF to alert you every time the file is accessed - that is of course if you own the file to begin with.

Out of interest, are you a JES2 or JES3 site?
_________________
My opinions are exactly that.