So perhaps a combination of the two is in order. Write to a temporary PDS during the translate and then use DISP=OLD on the copy from the temp PDS in to the actual PDS.
Yet another frustating issue in going to z/OS. Oy. Thanks for the ideas. Frank On 12/2/2009 at 3:23 AM, in message <listserv%[email protected]>, Big Iron <[email protected]> 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 > <[email protected]> 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 >><[email protected]>, Don Leahy >><[email protected]> 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 >>> <[email protected]> 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 [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. ---------------------------------------------------------------------- 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
