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 > >>> > >>> > >>>>>> > >>> > > ---------------------------------------------------------------------- > 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
