Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
I should have clarified it. The dsn is copied and in the following step it is deleted. Sorry. On Wed, 5/10/17, retired mainframer <retired-mainfra...@q.com> wrote: Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY To: IBM-MAIN@LISTSERV.UA.EDU Received: Wednesday, May 10, 2017, 8:41 AM You cannot code SHARE and DELETE on the same COPY command. If the dataset is deleted after the copy step, then obviously DFDSS has released its enqueue and is no longer a factor in the situation you described. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, May 10, 2017 5:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > > 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. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
You cannot code SHARE and DELETE on the same COPY command. If the dataset is deleted after the copy step, then obviously DFDSS has released its enqueue and is no longer a factor in the situation you described. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Wednesday, May 10, 2017 5:26 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > > 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. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
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 <retired-mainfra...@q.com> wrote: Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY To: IBM-MAIN@LISTSERV.UA.EDU 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 9:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <retired-mainfra...@q.com> wrote: > > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Tuesday, May 9, 2017, 10:19 AM > > > -Original > Message- > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Tuesday, May 09, 2017 6:01 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 > &g
Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 9:29 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 <retired-mainfra...@q.com> wrote: > > Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY > To: IBM-MAIN@LISTSERV.UA.EDU > Received: Tuesday, May 9, 2017, 10:19 AM > > > -Original > Message- > > From: IBM Mainframe > Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > > Behalf Of willie bunter > > Sent: Tuesday, May 09, 2017 6:01 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 <retired-mainfra...@q.com> wrote: Subject: Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY To: IBM-MAIN@LISTSERV.UA.EDU Received: Tuesday, May 9, 2017, 10:19 AM > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 6:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFDSS QUESTION :SHARE PARM WHEN DOING COPY
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of willie bunter > Sent: Tuesday, May 09, 2017 6:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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? 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
