There will be others that will provide a more indepth explanation.

However, to serialize a dataset DISP=OLD needs to be used.  Otherwise you can 
have multiple users/jobs updating/reading concurrently with the SHR Disposition.

If your process uses ISPF Services, then it is less likely because ISPF does 
the enq.

Not knowing specifically the program that is reading this dataset, I am not 
sure what else might be going on or if MIM/GRS might be helpful.

If you have a product like THRUPUT Manager, it can help in isolating file usage 
through resources.  If you have a scheduling product like CA_ESP you can also 
create the dataset as a resource and serialize it.

I am guessing that your process is 
Lots of jobs are submitted from various groups that will update your 
IMS.DBA.JCLLIB dataset.  Then at some point, you might be closing off the 
updates so you can run your production batch.  Is that close to your process?
If so, then I might look to setting up an ISPF process that lets the DBAs 
indicate which dataset and member needs to be update (the FROM function).  It 
builds a job or table that is then read say once an hour to do the actual 
update to IMS.DBA.JCLLIB.  That way you could reduce the number of random jobs 
running to a consistant run proces.  But that is just a thought.

Lizette




>
>At month end a job of ours that nornally runs a few minutes took several 
>hours by lpar saturation.  Our job reads a JCL PDS used by the DBAs.  They 
>complained because their job and subsequent jobs were held up by hours. 
>And once their job ran it took an hour instead of a minute (no 
>exaggeration!).
>
>We have been asked to change our job which would require changing it on at 
>least 6 plexes.
>
>Our solution is for them to change their job.
>
>They are using a construct that has the followed DD
>
>//OUTPUT DD DISP=OLD, DSN=IMS.DBA.JCLLIB(MEMBER)
>
>The question I have is:  Is the DISP=OLD needed or does the QSAM interface 
>to BPAM handle collisions?
>
>I vaguely remember that the MIM product had a feature added to it to 
>handle member collisions in the middle to late 1980's by Ed Legowski so 
>collisions were an issue back then.  (EDIF maybe????)
>
>So what is current state of the art?  We are 1.10 with 1.11 rolling out 
>this year (it's on 5-10 lpars already).
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to