AW: Re: Exclusive ENQ on a TSO logon procedure
>As as aside on this, as I understand it, this only applies to data sets >allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM >(see below), the DSNs listed do have, and keep, the normal allocation (SHR >as I recall when JES2 does the DYNALLOC). This is true but the description of SCHEDxx explicitly mentions that JES2 is honouring the DSI/NODSI setting when doing its dynalloc. >Also, if I remember correctly, when you specify NODSI, what actually >happens is that the data set _is_ enqueued when you do the START command, >but soon after (during the processing of the PPT entry?) the initiator will >release the ENQ. That is, if you have an STC defined with NODSI, but >something else has a DSN in the JCL "tied up" with a DISP=OLD type >allocation, then the START command will still get A "waiting on data sets" >message and will not be started until the DSN is available. Again true, but I did not mention it because (in normal situations) JES2's ENQs would have been released before any other job or TSO user can be started. Of course, if you ABEND JES2 and restart is, the situation is different. And it also does not help with $ADD PROC. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
On Tue, Jul 19, 2016 at 6:50 AM, Peter Hunkeler wrote: > > >If a user logs on, it is JES2 that reads the logonproc from PROCLIB, > which it already has allocated (as you >mentioned). Kind of a chicken and > egg problem: how can a user logon without having read the logonproc? > >Kees. > > > >Oh yeah..You are right.. . That explains why User C was able to log on . > Thank you Kees ... > > > JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold > an ENQ on the data sets it has allocated. > As as aside on this, as I understand it, this only applies to data sets allocated via JCL. That is, if you allocate a PROCLIB inside the JES2PARM (see below), the DSNs listed do have, and keep, the normal allocation (SHR as I recall when JES2 does the DYNALLOC). Example portion of JES2PARM: PROCLIB(PROC02) DD(1)=(DSN=SYS4.MDOFPROC), DD(2)=(DSN=SYS1.PROCLIB), DD(3)=(DSN=SYS2.PROCLIB), DD(4)=(DSN=SYS1.LI.PROCLIB) Also, if I remember correctly, when you specify NODSI, what actually happens is that the data set _is_ enqueued when you do the START command, but soon after (during the processing of the PPT entry?) the initiator will release the ENQ. That is, if you have an STC defined with NODSI, but something else has a DSN in the JCL "tied up" with a DISP=OLD type allocation, then the START command will still get A "waiting on data sets" message and will not be started until the DSN is available. > > > -- > Peter Hunkeler > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- "Worry was nothing more than paying interest on a loan that a man may never borrow" From: "Quest for the White Wind" by Alan Black Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Exclusive ENQ on a TSO logon procedure
>If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it >already has allocated (as you >mentioned). Kind of a chicken and egg problem: >how can a user logon without having read the logonproc? >Kees. > >Oh yeah..You are right.. . That explains why User C was able to log on . Thank >you Kees ... JES2 is usually defined with NODSI in the PPT (SCHEDxx) and does not hold an ENQ on the data sets it has allocated. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. Oh yeah..You are right.. . That explains why User C was able to log on . Thank you Kees ... Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
If a user logs on, it is JES2 that reads the logonproc from PROCLIB, which it already has allocated (as you mentioned). Kind of a chicken and egg problem: how can a user logon without having read the logonproc? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Steyn Sent: 19 July, 2016 11:25 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Exclusive ENQ on a TSO logon procedure There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Well ... Let me put the scenario a bit more clear a) User A goes and edits the logon procedure in ISPF and doesn't come out of edit mode . b) User B submits a Job with SYS1.PROCLIB containing the logon proc with DISP=OLD Then the job waits for an exclusive access for SYS1.PROCLIB which never gets satisfied as the proclib is already allocated with DISP=SHR by many things including JES2 - This is normal Now , my understanding is - At this point , if a USER C tries to logon to the system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to as GRS has another Exclusive ENQ request waiting from the job submitted by User B . Shouldn't that be honored before allowing others to access the proclib irrespective of DISP=SHR ? TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Well ... Let me put the scenario a bit more clear a) User A goes and edits the logon procedure in ISPF and doesn't come out of edit mode . b) User B submits a Job with SYS1.PROCLIB containing the logon proc with DISP=OLD Then the job waits for an exclusive access for SYS1.PROCLIB which never gets satisfied as the proclib is already allocated with DISP=SHR by many things including JES2 - This is normal Now , my understanding is - At this point , if a USER C tries to logon to the system using the same logon procedure in SYS1.PROCLIB , he shouldn't be able to as GRS has another Exclusive ENQ request waiting from the job submitted by User B . Shouldn't that be honored before allowing others to access the proclib irrespective of DISP=SHR ? TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Exclusive ENQ on a TSO logon procedure
There is a big difference between a job allocating a proclib with DISP=OLD and a user editing a logonproc with ISPF. The job with DISP=OLD blocks the entire proclib. ISPF issues an ENQ with DISP=SHR on the proclib and issues its own ENQ on the member with DISP=OLD. This way the library is available for other task with DISP=SHR, but the member (logonproc) is exclusively in use by the ISPF user. This works this way for decades already. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Roger Steyn Sent: 19 July, 2016 10:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Exclusive ENQ on a TSO logon procedure Greetings , Can somebody tell me what if a proclib containing a TSO logon procedure has got a DISP=OLD in a user submitted JCL or if somebody opens a logon procedure in ISPF edit mode and keep it that way for few hours. Will the rest of the users be able to log on using the same logon procedure while the ENQ is on ? Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold anybody from logging on using the same logon procedure while there is an exclusive ENQ . Does anyone know if this is a new feature in z/os 2.1 ? I am aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the job which had a DISP=OLD in my system had only one step and it was hanging because someone had opened the logon proc in edit mode and forgot to come out of the session . TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Exclusive ENQ on a TSO logon procedure
Greetings , Can somebody tell me what if a proclib containing a TSO logon procedure has got a DISP=OLD in a user submitted JCL or if somebody opens a logon procedure in ISPF edit mode and keep it that way for few hours. Will the rest of the users be able to log on using the same logon procedure while the ENQ is on ? Well , this is on z/os 2.1 and i was surprised to see the enq doesn't hold anybody from logging on using the same logon procedure while there is an exclusive ENQ . Does anyone know if this is a new feature in z/os 2.1 ? I am aware of the dynamic ENQ downgrade within a JCL having multiple steps . But the job which had a DISP=OLD in my system had only one step and it was hanging because someone had opened the logon proc in edit mode and forgot to come out of the session . TIA Roger Steyn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
