Does IEBCOPY use the same enqueue strategy as the Binder? On Wed, Dec 2, 2009 at 14:29, Joel C. Ewing <jcew...@acm.org> wrote: > 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 >
---------------------------------------------------------------------- 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
