I believe the Binder uses ISPF-style enqueues to allow OPEN for output with SHR access without any problems. When needing updates with SHR and utilities that do not support ISPF-style enqueues, our approach has been to change the job step to invoke a front-end program that gets the required "SPFEDIT" enqueue, invokes the utility, and when the utility returns control drop the enqueue. That way the job may wait, but only for the time when someone else actually has the dataset enqueued for "open for output". JC Ewing
On 12/02/2009 09:42 AM, Don Leahy wrote: > Good point. Our process is "working by coincidence". > > Time to took for a better approach. Thanks. > > On Wed, Dec 2, 2009 at 05:23, Big Iron <billlalo...@rocketmail.com> wrote: > >> I think that using a later copy step "works" because the time window >> involved is shorter and so collisions, two programs having the same PDS >> open for output with DISP=SHR, would be less likely but could still occur. >> I >> have seen that abend happen for link-edit steps. >> >> Using DISP=OLD will solve this problem since the job would no longer >> be updating a dataset allocated with DISP=SHR. Note that the elapsed >> time for the jobs will increase because the allocation will be held from >> the start of the job until the end of the step that allocates the dataset >> with DISP=OLD. >> >> Bill >> >> On Tue, 1 Dec 2009 12:04:48 -0700, Frank Swarbrick >> <frank.swarbr...@efirstbank.com> wrote: >> >>> A later step in the same job? Does this solve the issue because the copy >> uses different serialization than the actual creating of the DBRM member? >>> >>> I'll give it a shot. Thanks, >>> Frank >>> -- >>> >>> Frank Swarbrick >>> Applications Architect - Mainframe Applications Development >>> FirstBank Data Corporation - Lakewood, CO USA >>> P: 303-235-1403 >>> >>> >>> On 12/1/2009 at 11:58 AM, in message >>> <6133ad1f0912011058g272d6fc0m912af04571979...@mail.gmail.com>, Don Leahy >>> <don.le...@leacom.ca> wrote: >>>> This is a perennial problem. >>>> >>>> Our local solution was to allocate DBRMLIB to a temporary data set. >>>> >>>> //DBRMLIB DD DSN=&DBRMLB(&MR),DISP=(,PASS), >>>> // UNIT=SYSDA,SPACE=(TRK,(15,5,5)), >>>> // DCB=(RECFM=FB,LRECL=80,BLKSIZE=6160) >>>> >>>> A later step copies the DBRM to a permanent library. >>>> >>>> On Tue, Dec 1, 2009 at 13:25, Frank Swarbrick >>>> <frank.swarbr...@efirstbank.com> wrote: >>>>> For our conversion from VSE to z/OS we have a "mass compile" process >> that >>>> runs many compiles at the same time. This has been fine up until when >> we >>>> added "DB2 compiles" in to the mix. Now we are getting things like the >>>> following for every second or third compile: >>>>> 11.02.22 JOB05118 IEC143I >>>> >> 213-30,IFG0194D,EXAM02,COB,DBRMLIB,9220,DB2001,SYS3.DSN910.DBRMLIB.DATA(EXAM >>>> 02) >>>>> >>>>> "30 >>>>> An attempt was made to open a partitioned data set (PDS) for >>>> OUTPUT,DISP=SHR. The PDS is already open in this condition, and a DCB is >>>> already open for output to the data set. The data set might be on the >> same >>>> system or on another system that is sharing the volume. Access was not >>>> serialized before the attempt to open the data set." >>>>> >>>>> I am guessing that "job 2" is trying to add a member to >>>> SYS3.DSN910.DBRMLIB.DATA at the same time that "job 1" is trying to do >> the >>>> same thing (though a different member). >>>>> >>>>> Obviously one solution is to single thread the compiles. But I'd >> rather not >>>> if I don't have to. Any other solutions? If I changed to DISP=OLD >> would >>>> this eliminate the issue by making job 2 wait until job 1 is done with >> the >>>> PDS? >>>>> >>>>> Why does the link-edit step seem to not have a similar issue? Is it >> just >>>> that the link-edit step completes so quickly that only one job has the >> PDS >>>> open at one time? Or does the link-edit (binder; whatever) have some >> special >>>> stuff that allows it do deal with this situation? >>>>> >>>>> Thanks, >>>>> Frank >>>>> -- >>>>> >>>>> Frank Swarbrick >>>>> Applications Architect - Mainframe Applications Development >>>>> FirstBank Data Corporation - Lakewood, CO USA >>>>> P: 303-235-1403 > -- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
