Thanks for raising the point that the enqueue is caused by the initiator and not DFDSS, I will check into this. To answer your question about the CICS file. Yes, the enqueue is released. The dsn is copied and deleted and redefined.
Thanks again. -------------------------------------------- On Tue, 5/9/17, retired mainframer <[email protected]> wrote: Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY To: [email protected] Received: Tuesday, May 9, 2017, 1:27 PM Since the JCL has a reference to the DSN after the DFDSS step, the enqueue that is causing your conflict is held by the initiator, not by DFDSS. The section I quoted has additional text that describes how DFDSS uses the initiator's enqueue. You need to look at that to determine how it affects your job. When you close the file in CICS, is the enqueue released? If so, the SHARE option is irrelevant since no one else is accessing the dataset. Unless OAM is VSAM under the covers (like PDSE and ZFS), the quoted text states that is does apply. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 9:29 AM > To: [email protected] > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > > The job does reference the dsn after it is enabled on CICS. > > Since the dsn is OAM the SHARE parm does appy. Right? > > -------------------------------------------- > On Tue, 5/9/17, retired mainframer <[email protected]> wrote: > > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > To: [email protected] > Received: Tuesday, May 9, 2017, 10:19 AM > > > -----Original > Message----- > > From: IBM Mainframe > Discussion List [mailto:[email protected]] > On > > Behalf Of willie bunter > > Sent: Tuesday, May 09, 2017 6:01 AM > > To: [email protected] > > Subject: DFDSS QUESTION :SHARE PARM WHEN > DOING COPY > > > > Good > Day To All, > > > > Could > someone clarify the explanation and my understanding about > the SHARE parm when > > using COPY. > Following is the explanation in the doc: > > > > SHARE specifies that > DFSMSdss is to share the data sets to be copied for read > > access with other programs. > > SHARE and FULL are mutually exclusive; you > cannot specify these keywords > > > together. > > Do not specify DELETE if you > specify SHARE. You must have exclusive control > > over data sets that are to be deleted; > SHARE does not require such exclusive > > > control. > > Note: Unlike the RESTORE > command, the COPY command honors the SHARE > > keyword for VSAM data sets. However, the > SHARE keyword is only honored for > > VSAM > data sets that were defined with share options other than > (1,3) or (1,4). > > Specifying the SHARE > keyword does not cause DFSMSdss to honor the share > > options that are defined for VSAM data > sets. For VSAM data sets that are defined > > with share options other than (1,3) or > (1,4), specifying the SHARE keyword allows > > other programs to obtain read access. It > does not, however, allow write access to > > the data sets while they are being copied. > For VSAM data sets that are defined > > > with share options (1,3) or (1,4), neither read access nor > write access by other > > programs is > allowed while the data set is being copied. > > > > If my understanding > is correct the SHARE parm applis to VSAM dsns which are > defined > > with share options (2,3) . > However the dsn in question is that it is an OAM file. > Would the > > SHARE apply to OAM dsns as > well? > > The paragraph that > talks about VSAM datasets I emphasizing the difference > between COPY and RESTORE. Since your dataset is not VSAM, > the paragraph does not apply. Note the following quote > from the Data Set Serialization section of the > manual" > > " The > SHARE option has unique properties when applied to the > following commands: > * For the RESTORE > command, SHARE applies to non-VSAM data sets only. > * For the DUMP and COPY commands, SHARE > applies to non-VSAM data sets and VSAM data sets that are > defined with share options other than (1,3) and > (1,4)." > > > Before > the COPY is executed the file is closed on CICS. However > after the COPY step > > has executed of the > dsn (no warnings or errors received) the job abends at the > following > > step which tries to enable > the file on CICS because the dsn is not released from the > job until > > it completes. The job has 6 > steps. > > My question is > shouldn''t the dsn be released after the COPY step > is has completed or does > > dsn is > released at the end ot the job? Could someone please clear > this up for me? > > Does the > DSN appear anywhere else in the JCL for the job? Did a > previous step in the job reference the DSN during > execution? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
