Solve File Status 93.

[Kishan Mathew]

Hello,

One of the Jobs in production got abended with VSAM open error. The File Status code was 93. When I looked for it further, I found that, that's it's because the resource was unavailable. My question is: Can we find out now that if there was any other job which was using this VSAM? If yes, how can we do that?

[Kishan Mathew]

Also, in case the file was not closed correctly by a given Job then can there be a way to close it properly? This came as part of the discussion.

[Robert Sample]

File status 93 means, by definition, that some other address space was using your data set. So, asking

Can we find out now that if there was any other job which was using this VSAM?

is a rhetorical question -- yes, some other job (or TSO user or started task) was using that VSAM. Can you find out now which address space was using it? No, that can only be done while the conflict is ongoing and requires using console commands to do so.

Also, in case the file was not closed correctly by a given Job then can there be a way to close it properly?

This is NOT your issue but the answer is yes, an IDCAMS VERIFY will check a VSAM data set and ensure it is properly closed. If a VSAM data set was not properly closed, the next access to it will generate a file status 97 (assuming a COBOL program, of course) but the 97 is not an error code and should be treated like a 00.

[Kishan Mathew]

This is confusing. So if this has happened once we can not really solve until it happens again and we start verifying it then at that time? Is that a correct assumption?

[Robert Sample]

You have completely misunderstood what you've been told.

First, if you want to know which job / TSO user / started task has the VSAM data set, you need to issue a console command while the contention is going on. The only other way to determine this would be to analyze the SMF records, which may require processing millions of records and also requires a very deep understanding of the SMF data.

Second, an IDCAMS VERIFY can be run at any time with little impact. Many sites add a step to their production jobs to do a VERIFY to prevent the 97 file status codes; this step is usually placed just before the step that uses the data set.

Third, there is a very simple solution to your problem -- for every job that accesses the VSAM data set, ensure the DD statement has DISP=OLD on it. This will prevent any contention problems since no other jobs / TSO users / started tasks will be able to access the data set while your job is using it. This solution may not be possible in all cases -- some applications are designed such that multiple jobs / TSO users / started tasks must simultaneously use the data set -- and may require significant application design changes.

[Kishan Mathew]

Thanks Robert.

IDCAMS VERIFY is what we used indeed.