IBM Mainframe Forum

Hi, When I have two batch jobs (with IDCAMS REPRO commands) run concurrently, either one will certainly get VSAM open error 168 --> "file opened by other ACB", which I admit it is normal. But with a little hope I wonder if any slight chance that I can have some fancy way to avoid such errors (e.g by using VSAM shareoptions !?)

Are they source or target files, or a mixture?

Sorrry, i should have say it clearly
What i meant is the target file, and i prefer not to use disp as Old in JCL to around the problem

What are the current VSAM SHAREOPTIONS?

And to make sure we understand correctly, you have two jobs that you want to run simultaneously on a single LPAR that both need to write to the VSAM KSDS? Do the jobs write data to the entire file, to only some selected key ranges, or do you not have any idea?

Well, I think you could do it. However, I think the chance of your having meaningful or reproduceable results are nil.

What business requirement are you trying to satisfy? We may have some better suggestions than what you think is an answer for you.

Hi Robert, the shareoption(2,3) is being used for the output file. This situation is I have two jobs that I want to run simultaneously on a single LPAR that both need to add new records into to the VSAM KSDS . The command is simply "repro infile(??) outfile(??)".

Hi Billy, The requirement for me is that I have a KSDS which contains in-house data, and from time to time there will a number of TSO users to insert new records in the KSDS. Originally we think about asking users to use REPRO instead of any COBOL / Easytrieve pgm in order to minimize the development effort.

It is possible to change the SHAREOPTIONS to allow multiple programs to write to the output KSDS file at the same time. HOWEVER, you will NOT be able to use IDCAMS if you make such a change. You also need to consult your site support group since they may have site options set that would complicate the task. You will need to change the SHAREOPTIONS and implement programmatic ENQUEUE and DEQUEUE logic to lock the KSDS for adding records -- which may require writing a new program to perform this function. While it is possible to have two programs writing to the same KSDS at the same time, without using ENQUEUE / DEQUEUE logic you have a very high chance of corrupting the VSAM data set and making it completely unusable.

Thanks Robert....

And why not just have two input files for your repro and the one output, or sort the two files creating on output file that runs with repro against the ksds?