Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 01/08/2007 at 08:35 AM, Paul Gilmartin [EMAIL PROTECTED] said: Can it do this even for DISP=NEW? I suspect not, but I'll let one of the JES3 gurus address that question. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Shmuel Metz (Seymour J.) said: Date: Sun, 7 Jan 2007 12:10:57 -0500 (I don't talk about main device secheduling in JES3, which only handles devices, not DSN ENQs). MDS serializes data sets; unlike the Initiator, it takes volume serial numbers into account. Can it do this even for DISP=NEW? Does it commit to specific volumes even before Initiation? My colleague claimes that he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be seriallzed. I'm sure that he was told that. The ISV was wrong. Perhaps the ISV was thinking of DYNALLOC with S99WTDSN. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/28/2006 at 10:42 AM, Hunkeler Peter (KIUB 34) [EMAIL PROTECTED] said: Is is my understanding and experience that the initiator will ENQ on all data sets referenced in the JCL (all steps) at job initiation time. The job will not start even the first step before all ENQs have been granted. So a job might be WAITING FOR DATASETS even if the one not yet available is only referenced in step nn (nn 1). At step end, the initiator will DEQ any DSNs that are no longer needed, i.e. those which are not referenced on a DD in any later step. Correct. It is also my understanding that this is initiator business and therefore works the same way in either JES2 or JES3 environments. Yes. (I don't talk about main device secheduling in JES3, which only handles devices, not DSN ENQs). MDS serializes data sets; unlike the Initiator, it takes volume serial numbers into account. My colleague claimes that he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be seriallzed. I'm sure that he was told that. The ISV was wrong. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/02/2006 at 06:27 PM, Paul Gilmartin [EMAIL PROTECTED] said: Are you sure that a single volume can't be known by two different names? It's possible for a single volume to be known by two different names, but that involves some real carelessness. It's not something that happens simply because of an installation's poor choice of naming conventions. Can one system dismount and rename a volume while it remains mounted on another system, then remount it by the new name while the other system still knows it by the old name? Yes. Don't do it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
- snip - Are you sure that a single volume can't be known by two different names? Consider: surely it's possible to rename a volume (the verb clip comes to mind). Can one system dismount and rename a volume while it remains mounted on another system, then remount it by the new name while the other system still knows it by the old name? - snip - Oh yes. Just replace dismount and remount with vary offline and vary online respectively. Zaromil -- 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
Re: Data set ENQueues and DEQueues in Jobs
On 2 Aug 2006 18:46:04 -0700, in bit.listserv.ibm-main you wrote: At 12:22 -0400 on 08/01/2006, Wayne Driscoll wrote about Re: Data set ENQueues and DEQueues in Jobs: I could see how a downgrade would be useful. For instance: I have a resource shared. Now I need to update the resource, so I perform an S-E. Now, I want to allow others to see the update, but I don't want to allow an exclusive user to lock me out of the resource, so a E-S change would allow this to happen. Even more importantly, as I've noted in prior messages in this thread, the capability to do a E-S downgrade would fix the current Design Flaw in the Initiator where if you follow a Job Step that has DISP=OLD/MOD for a Dataset with DISP=SHR Job Steps, these subsequent Job Steps keep the exclusive ENQ until the Job is over (or there are no more steps using the dataset). Support for E-S downgrade would allow other jobs to take off once the last DISP=OLD/MOD step is done and the first DISP=SHR step starts. I was under the impression that the initiator was able to downgrade from NEW/OLD/MOD to SHR between steps. -- 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
Re: Data set ENQueues and DEQueues in Jobs
If there are others with a SHARED ENQ, attempting a RET=CHNG will either put you into a wait (possibly triggering a deadly embrace if you hold another SHR or EXC ENQ that some other task wants to go to EXC status on) or return a failure RC and require you to recover by attempting it again. Actually, RET=CHNG will always return with a return code (0 or other). The RET= parm implies this. The only way to wait is an ENQ with no RET=, which obviously will not do the CHNG. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: Data set ENQueues and DEQueues in Jobs
RET=NONE is the same as RET= parameter omitted. IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 08/03/2006 02:20:20 PM: If there are others with a SHARED ENQ, attempting a RET=CHNG will either put you into a wait (possibly triggering a deadly embrace if you hold another SHR or EXC ENQ that some other task wants to go to EXC status on) or return a failure RC and require you to recover by attempting it again. Actually, RET=CHNG will always return with a return code (0 or other). The RET= parm implies this. The only way to wait is an ENQ with no RET=, which obviously will not do the CHNG. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. 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
Re: Data set ENQueues and DEQueues in Jobs
On 8/1/2006 4:09 PM, [EMAIL PROTECTED] wrote: In a recent note, Walt Farrell said: On 8/1/2006 10:10 AM, Edward Jaffe wrote: No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ on the same resource and modifying it. To maintain the integrity of the resource, you use RET=CHNG to upgrade from shared to exclusive without losing control. If you were required to DEQ and then re-ENQ to perform the upgrade, you would lose control of the resource between the time you inspected it and the time you had the necessary serialization to update it. In the worst case scenario, someone else could change (or even delete) the resource in-between!! Of course, if anyone else also has the resource with a shared ENQ, your RET=CHNG will fail, and at that point you have no choice but to DEQ and try again from the beginning (presumably starting with EXC that time around). What do you gain by performing the DEQ? The EXCL ENQ will immediately fail and continue to fail until all other jobs DEQ the resource. Isn't it as good or better simply to re-issue the RET=CHNG until it works, or use the WAIT option if you have the authority. Re-issuing the RET=CHNG is not guaranteed to ever work. You might find, based on the vagaries of exactly when your program gets CPU time, that the resource is always ENQed SHR by someone else when you try to do your RET=CHNG. DEQing and re-ENQing will succeed, possibly with an automatic WAIT. I'm not sure what WAIT option you're referring to, when using RET=CHNG. Walt Farrell, CISSP z/OS Security Design, IBM -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 01:47 AM, Robert A. Rosenberg [EMAIL PROTECTED] said: You trimmed my quote back too far. I acknowledged in my statement that the root cause of the need to not include the VOLSER in the RNAME is that the ENQ is being done prior to the allocation of the dataset being managed by the ENQ That's only the tip of the iceberg. Regardless of when you do the ENQ there are issues that must be dealt if you are to avoid a deadlock. So long as you do not know which version of a dataset you are going to use, The problem does not go away if you know which version. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 06:44 AM, Paul Gilmartin [EMAIL PROTECTED] said: View this from the perspective of the initiator: RET=CHNG is available, yet the initiator never exploits it -- it can't by design objective. You're overlooking DYNALLOC. Likewise, if RET=CHNG were not available, you could equally well simply DEQ and re-ENQ with EXCL scope. That wouldn't have the same effect and would be, in general, disastrous. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 07:59 AM, Paul Gilmartin [EMAIL PROTECTED] said: You understood my intent. And I briefly considered the UCB address, but passed over it because I don't know that it's guaranteed to be canonical across multiple systems. The UCB address is pretty much guarantied to not be canonical, and the device address is not guarantied to be canonical. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 11:01 AM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: Device numbers are canonical across systems. Alas, no. But I would argue that it is sound practice to keep them consistent. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 11:17 AM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: But there must be something canonical across systems that is unique to the device for a cross-system ENQ involving devices to work. The volume serial number. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 08/01/2006 at 11:17 AM, (IBM Mainframe Discussion List) [EMAIL PROTECTED] said: But there must be something canonical across systems that is unique to the device for a cross-system ENQ involving devices to work. In a message dated 8/2/2006 10:33:54 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: The volume serial number. Alas, no. But I would argue that it is sound practice to keep them unique within the entire DASD farm. Since device numbers are not necessarily canonical across systems, in a truly pathological case you could have volser W on device number X on system Y, and volser W on device number X on system Z, yet the two volsers labelled W are different volumes because the two devices numbered X are different devices. There is information in the Configuration Data Record which is unique to the device. Bill Fairchild -- 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
Re: Data set ENQueues and DEQueues in Jobs
Shmuel Metz (Seymour J.) wrote: But there must be something canonical across systems that is unique to the device for a cross-system ENQ involving devices to work. The volume serial number. When duplicates volsers exist, you get prompted at IPL time to indicate which device should remain offline. There's nothing stopping an operator from responding differently as different systems are IPLed. Even without an IPL, you can vary one device offline and then vary another one online with the same volser. Two different physical devices. Same volser. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Wed, 2 Aug 2006 08:51:55 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: ... When duplicates volsers exist, you get prompted at IPL time to indicate which device should remain offline. There's nothing stopping an operator from responding differently as different systems are IPLed. Even without an IPL, you can vary one device offline and then vary another one online with the same volser. Two different physical devices. Same volser. ... Ok, that will give 2 different devices with the same volser, but you won't get 2 different volsers for the same device. In the case of ENQ/DEQ you won't an ENQued device accessable by another name. I *think* that was the context of the statement, but I may be wrong. Pat O'Keefe -- 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
Re: Data set ENQueues and DEQueues in Jobs
Patrick O'Keefe wrote: Ok, that will give 2 different devices with the same volser, but you won't get 2 different volsers for the same device. In the case of ENQ/DEQ you won't an ENQued device accessable by another name. I *think* that was the context of the statement, but I may be wrong. While it isn't possible to have two different volsers for the same *physical* device, you can /easily/ have two different volsers for the same device number (which is all MVS knows)! Suppose you have a DASD subsystem attached as '80xx' on system A. You could attach that same subsystem as '90xx'on system B! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Edward Jaffe said: Date: Wed, 2 Aug 2006 12:58:12 -0700 Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU From: Edward Jaffe [EMAIL PROTECTED] Organization: Phoenix Software International, Inc. Subject: Re: Data set ENQueues and DEQueues in Jobs In-Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Patrick O'Keefe wrote: Ok, that will give 2 different devices with the same volser, but you won't get 2 different volsers for the same device. In the case of ENQ/DEQ you won't an ENQued device accessable by another name. I *think* that was the context of the statement, but I may be wrong. While it isn't possible to have two different volsers for the same *physical* device, you can /easily/ have two different volsers for the same device number (which is all MVS knows)! Suppose you have a DASD subsystem attached as '80xx' on system A. You could attach that same subsystem as '90xx'on system B! When two different entities are known by the same name, there's no integrity hazard; merely an unnecessary restriction of availability because of a superfluous ENQ, as happens today when a systems programmer wants to build a copy of SYS1.LINKLIB for testing (and then delete it). If one entity is known by two different names, there is an integrity hazard, because two systems may obtain EXCL ENQ of it by the different names and unwittingly update it concurrently. Are you sure that a single volume can't be known by two different names? Consider: surely it's possible to rename a volume (the verb clip comes to mind). Can one system dismount and rename a volume while it remains mounted on another system, then remount it by the new name while the other system still knows it by the old name? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 12:22 -0400 on 08/01/2006, Wayne Driscoll wrote about Re: Data set ENQueues and DEQueues in Jobs: I could see how a downgrade would be useful. For instance: I have a resource shared. Now I need to update the resource, so I perform an S-E. Now, I want to allow others to see the update, but I don't want to allow an exclusive user to lock me out of the resource, so a E-S change would allow this to happen. Even more importantly, as I've noted in prior messages in this thread, the capability to do a E-S downgrade would fix the current Design Flaw in the Initiator where if you follow a Job Step that has DISP=OLD/MOD for a Dataset with DISP=SHR Job Steps, these subsequent Job Steps keep the exclusive ENQ until the Job is over (or there are no more steps using the dataset). Support for E-S downgrade would allow other jobs to take off once the last DISP=OLD/MOD step is done and the first DISP=SHR step starts. -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 18:40 -0400 on 07/30/2006, Bruce Black wrote about Re: Data set ENQueues and DEQueues in Jobs: I have the impression that the initiator is also smart enough to issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if subsequent steps have the DSN as DISP=SHR after the last step that has it as DISP=OLD (ie: Exclusive). Sorry, ENQ RET=CHNG only changes a SHR ENQ to EXCL, not the other waqy My error. I remembered that the ENQ had the ability to change the ENQ type but forgot that it was from SHARED to EXCLUSIVE (which is not as useful as from EXCLUSIVE to SHARED - if there is some purpose in allowing S-E, it should be in addition to not in lieu of E-S). In fact, I can not think of any situation where you'd want to be able to gain EXCLUSIVE access after having SHARED Access while (as I noted) having EXCLUSIVE access and switching to SHARED (so others can have SHARED access before you terminate and totally give up the ENQ) seems more useful (such as being able to have DISP=SHR access in a Job Stream where only Initial Steps needs to have DISP=OLD). Right now, once you gain DISP=OLD in a Job Step, you keep it in subsequent DISP=SHR steps due to the bad design of ENQ that refuses to allow you to relax your ENQ while still maintaining it. -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 00:37 -0600 on 07/31/2006, Paul Gilmartin wrote about Re: Data set ENQueues and DEQueues in Jobs: And thereby hangs a long and knotted tale of how TSO ALLOCATE will sometimes create a data set with only a SHR ENQ on the DSNAME; fail to catalog it because of a duplicate catalog entry, then fail to delete it because it can't obtain an EXCL ENQ because another job has a SHR ENQ on the same DSNAME. That is because it does not do the allocate via a Protecting QNAME that uses a RNAME of DSN+VOLSER (you do a two QNAME ENQ [the protecting one and the brain-dead SYSDSN] will fail if you can not get BOTH ENQs) -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 12:20 -0300 on 07/31/2006, Shmuel Metz (Seymour J.) wrote about Re: Data set ENQueues and DEQueues in Jobs: Part of the problem with this type of incorrect conflict is that the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN (the RNAME) as the identifier of the Dataset not the CORRECT DSN with VOLSER. Which volser? You would have to be very careful to avoid a deadly embrace. You trimmed my quote back too far. I acknowledged in my statement that the root cause of the need to not include the VOLSER in the RNAME is that the ENQ is being done prior to the allocation of the dataset being managed by the ENQ (some times before the dataset even exists such as in the case of a DISP=NEW). So long as you do not know which version of a dataset you are going to use, you can not include the VOLSER in the RNAME (as I noted this restriction DOES NOT apply to ISPF or other SVC99 usage since at that point in time you DO know the dataset's VOLSER and thus can use it for non-SYSDSN private QNAMEs such as ISPF's SYSEDIT[?]). -- 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
Re: Data set ENQueues and DEQueues in Jobs
Robert A. Rosenberg wrote: My error. I remembered that the ENQ had the ability to change the ENQ type but forgot that it was from SHARED to EXCLUSIVE (which is not as useful as from EXCLUSIVE to SHARED - if there is some purpose in allowing S-E, it should be in addition to not in lieu of E-S). In fact, I can not think of any situation where you'd want to be able to gain EXCLUSIVE access after having SHARED Access ... Huh? You have this completely reveresed in your mind. Upgrading your ENQ from shared to exclusive is the common case and is a *required* function in order to maintain the integrity of the data. Going the other way would be far less common ... so uncommon, in fact, that OS/MVT/MVS never bothered to create a service for it! There's just no need. If you want to downgrade from exclusive to shared, you simply DEQ and re-ENQ with shared scope. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Edward Jaffe said: Date: Mon, 31 Jul 2006 23:48:57 -0700 Robert A. Rosenberg wrote: My error. I remembered that the ENQ had the ability to change the ENQ type but forgot that it was from SHARED to EXCLUSIVE (which is not as useful as from EXCLUSIVE to SHARED - if there is some purpose in allowing S-E, it should be in addition to not in lieu of E-S). In fact, I can not think of any situation where you'd want to be able to gain EXCLUSIVE access after having SHARED Access ... Huh? You have this completely reveresed in your mind. Upgrading your ENQ from shared to exclusive is the common case and is a *required* function in order to maintain the integrity of the data. Going the other way would be far less common ... so uncommon, in fact, that OS/MVT/MVS never bothered to create a service for it! There's just no need. If you want You're misperceiving familiarity as utility or even necessity; I agree with Robert. View this from the perspective of the initiator: RET=CHNG is available, yet the initiator never exploits it -- it can't by design objective. In the obvious case when an earlier job step specifies DISP=SHR and a later step specifies DISP=OLD, the initiator doesn't initially do a SHR ENQ, and prior to the later step RET=CHNG. To do so would introduce the high likelihood of a deadlock, if the initiator specified WAIT, or an ABEND/JCL error, if the initiator eschewed WAIT. Contrariwise, if RET=DOWNGRADE to change EXCL to SHR were available, the initiator could readily (SMOP) exploit it so that a data set created with DISP=NEW in an early step could be accessed both by the creating job in a later step, and concurrently by other jobs. to downgrade from exclusive to shared, you simply DEQ and re-ENQ with shared scope. Likewise, if RET=CHNG were not available, you could equally well simply DEQ and re-ENQ with EXCL scope. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Mon, 31 Jul 2006 23:48:57 -0700 Edward Jaffe [EMAIL PROTECTED] wrote: :Huh? You have this completely reveresed in your mind. Upgrading your ENQ :from shared to exclusive is the common case and is a *required* function :in order to maintain the integrity of the data. Going the other way :would be far less common ... so uncommon, in fact, that OS/MVT/MVS never :bothered to create a service for it! There's just no need. If you want :to downgrade from exclusive to shared, you simply DEQ and re-ENQ with :shared scope. Which loses control if there are ten SHR waiters followed by an EXC waiter. I can see the case for EXC-SHR, and it should always be successful. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/31/2006 at 04:59 PM, Paul Gilmartin [EMAIL PROTECTED] said: Some months ago in these pages I proposed the rudiments of a scheme of obtaining a SHR ENQ on each DEB when a data set is opened, and an EXCL ENQ on the DEB of any extent to be freed. Mark Thomen (IIRC) countered with examples of system code that manipulate extents without ever creating DEBs. It wouldn't work anyway, because even if the other task did do an OPEN it would have a different DEB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Mon, 31 Jul 2006 21:19:04 -0300 Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: :In [EMAIL PROTECTED], on 07/31/2006 : at 04:59 PM, Paul Gilmartin [EMAIL PROTECTED] said: :Some months ago in these pages I proposed the rudiments of a scheme :of obtaining a SHR ENQ on each DEB when a data set is opened, and an :EXCL ENQ on the DEB of any extent to be freed. Mark Thomen (IIRC) :countered with examples of system code that manipulate extents :without ever creating DEBs. :It wouldn't work anyway, because even if the other task did do an OPEN :it would have a different DEB. I believe that he means the DEB information, i.e., the UCB addr/volser + the starting extent. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Shmuel Metz (Seymour J.) said: Date: Mon, 31 Jul 2006 21:19:04 -0300 In [EMAIL PROTECTED], on 07/31/2006 at 04:59 PM, Paul Gilmartin [EMAIL PROTECTED] said: Some months ago in these pages I proposed the rudiments of a scheme of obtaining a SHR ENQ on each DEB when a data set is opened, and an EXCL ENQ on the DEB of any extent to be freed. Mark Thomen (IIRC) countered with examples of system code that manipulate extents without ever creating DEBs. It wouldn't work anyway, because even if the other task did do an OPEN it would have a different DEB. Not the address of the DEB, of course, but its content: volume and TTR -- whatever is canonical over the affected scope. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Binyamin Dissen said: Date: Tue, 1 Aug 2006 16:52:44 +0300 I believe that he means the DEB information, i.e., the UCB addr/volser + the starting extent. You understood my intent. And I briefly considered the UCB address, but passed over it because I don't know that it's guaranteed to be canonical across multiple systems. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
Paul Gilmartin wrote: Likewise, if RET=CHNG were not available, you could equally well simply DEQ and re-ENQ with EXCL scope. No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ on the same resource and modifying it. To maintain the integrity of the resource, you use RET=CHNG to upgrade from shared to exclusive without losing control. If you were required to DEQ and then re-ENQ to perform the upgrade, you would lose control of the resource between the time you inspected it and the time you had the necessary serialization to update it. In the worst case scenario, someone else could change (or even delete) the resource in-between!! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Data set ENQueues and DEQueues in Jobs
In fact, I can not think of any situation where you'd want to be able to gain EXCLUSIVE access after having SHARED Access If the JCL has DISP=SHR but the application needs exclusive control, RET=CHNG will do it. We use this in FDR. Our SYSDSN ENQs are always exclusive, but if the user has the dataset in a DD with SHR, we use RET=CHNG to change it. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a message dated 8/1/2006 8:53:00 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I believe that he means the DEB information, i.e., the UCB addr/volser + the starting extent. The DEB contains the address of the UCB, but the address of the UCB is not canonical across systems. Instead of saying the UCB addr, I believe you mean the device number contained within the UCB pointed to by the DEB. The 2-byte field that used to be called device address, or channel/unit address, was changed with S/370-XA, and since ca. 1982 has been called the device number. Device numbers are canonical across systems. At least that was the response I got when I asked IBM-MAIN if they were many months ago. If the ENQ does not go across systems, then you could use the address of the UCB, but only if the UCB is guaranteed not to move around, which happens sometimes these days with dynamic devices. Use non-varying info within the UCB that is unique to the device, and non-varying info that describes unique info within the device, such as the extent. Bill Fairchild -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Tue, 1 Aug 2006 07:59:42 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: And I briefly considered the UCB address, but passed over it because I don't know that it's guaranteed to be canonical across multiple systems. It's not. I'm not even sure about on a single system when there are PAVs. In any case, as has been discussed here several times, it is too late to change it now. Too many programs would have to be changed all at once. Tom Marchant -- 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
Re: Data set ENQueues and DEQueues in Jobs
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: Tuesday, August 01, 2006 10:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data set ENQueues and DEQueues in Jobs snip Device numbers are canonical across systems. At least that was the response I got when I asked IBM-MAIN if they were many months ago. snip Bill Fairchild Hum, are you sure that device numbers are canonical across systems? Granted, it is wise to make it so. But I know how to generate a different device number for a given physical device in two different LPARs. It is especially easy to change the two high-order numbers. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Tue, 1 Aug 2006 11:01:04 EDT, IBM Mainframe Discussion List [EMAIL PROTECTED] wrote: In a message dated 8/1/2006 8:53:00 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: I believe that he means the DEB information, i.e., the UCB addr/volser + the starting extent. The DEB contains the address of the UCB, but the address of the UCB is not canonical across systems. Instead of saying the UCB addr, I believe you mean the device number contained within the UCB pointed to by the DEB. The 2-byte field that used to be called device address, or channel/unit address, was changed with S/370-XA, and since ca. 1982 has been called the device number. Device numbers are canonical across systems. Nothing in the system will stop me from creating an I/O configuration that has a shared device at on different systems with different device numbers. It's not my preference, but it is perfectly permissable. Tom Marchant -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a message dated 8/1/2006 10:09:19 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: Hum, are you sure that device numbers are canonical across systems? Granted, it is wise to make it so. But I know how to generate a different device number for a given physical device in two different LPARs. It is especially easy to change the two high-order numbers. No, I am not sure. That is why I couched my comment with my caveat (At least that was the response I got when I asked IBM-MAIN if they were many months ago.). But there must be something canonical across systems that is unique to the device for a cross-system ENQ involving devices to work. Certainly it cannot be the address of a UCB. I asked an IBM IOS internals person a year ago, and he said it is possible to have different device numbers on different LPARs that reach the same physical device. I asked an IBM control unit person and he said it is not possible, but I think he was talking about the one-byte channel connection address within the control unit and did not understand terminology describing things outside of the control unit, such as processor architecture. Then I asked IBM-MAIN, and everyone who responded said the numbers are canonical and must be the same. Please email me offline so I can find out how to generate different device numbers for the same device for an experiment. Bill Fairchild -- 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
Re: Data set ENQueues and DEQueues in Jobs
I could see how a downgrade would be useful. For instance: I have a resource shared. Now I need to update the resource, so I perform an S-E. Now, I want to allow others to see the update, but I don't want to allow an exclusive user to lock me out of the resource, so a E-S change would allow this to happen. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, August 01, 2006 1:49 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data set ENQueues and DEQueues in Jobs Robert A. Rosenberg wrote: My error. I remembered that the ENQ had the ability to change the ENQ type but forgot that it was from SHARED to EXCLUSIVE (which is not as useful as from EXCLUSIVE to SHARED - if there is some purpose in allowing S-E, it should be in addition to not in lieu of E-S). In fact, I can not think of any situation where you'd want to be able to gain EXCLUSIVE access after having SHARED Access ... Huh? You have this completely reveresed in your mind. Upgrading your ENQ from shared to exclusive is the common case and is a *required* function in order to maintain the integrity of the data. Going the other way would be far less common ... so uncommon, in fact, that OS/MVT/MVS never bothered to create a service for it! There's just no need. If you want to downgrade from exclusive to shared, you simply DEQ and re-ENQ with shared scope. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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 -- 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
Re: Data set ENQueues and DEQueues in Jobs
On 8/1/2006 10:10 AM, Edward Jaffe wrote: Paul Gilmartin wrote: Likewise, if RET=CHNG were not available, you could equally well simply DEQ and re-ENQ with EXCL scope. No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ on the same resource and modifying it. To maintain the integrity of the resource, you use RET=CHNG to upgrade from shared to exclusive without losing control. If you were required to DEQ and then re-ENQ to perform the upgrade, you would lose control of the resource between the time you inspected it and the time you had the necessary serialization to update it. In the worst case scenario, someone else could change (or even delete) the resource in-between!! -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Walt Farrell said: Date: Tue, 1 Aug 2006 15:49:35 -0400 On 8/1/2006 10:10 AM, Edward Jaffe wrote: No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ on the same resource and modifying it. To maintain the integrity of the resource, you use RET=CHNG to upgrade from shared to exclusive without losing control. If you were required to DEQ and then re-ENQ to perform the upgrade, you would lose control of the resource between the time you inspected it and the time you had the necessary serialization to update it. In the worst case scenario, someone else could change (or even delete) the resource in-between!! Of course, if anyone else also has the resource with a shared ENQ, your RET=CHNG will fail, and at that point you have no choice but to DEQ and try again from the beginning (presumably starting with EXC that time around). What do you gain by performing the DEQ? The EXCL ENQ will immediately fail and continue to fail until all other jobs DEQ the resource. Isn't it as good or better simply to re-issue the RET=CHNG until it works, or use the WAIT option if you have the authority. But, yes, I was using rhetoric to make the same point Binyamin made more explicitly: doing a DEQ; ENQ is subject to the same hazard of interruption by other jobs whether one uses the sequence to downgrade or upgrade an ENQ. If it's unacceptable for upgrading, it's likewise unacceptable for downgrading. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 07:09 -0700 on 08/01/2006, Edward Jaffe wrote about Re: Data set ENQueues and DEQueues in Jobs: Paul Gilmartin wrote: Likewise, if RET=CHNG were not available, you could equally well simply DEQ and re-ENQ with EXCL scope. No. Holding a shared ENQ prevents others from acquiring an exclusive ENQ on the same resource and modifying it. To maintain the integrity of the resource, you use RET=CHNG to upgrade from shared to exclusive without losing control. If you were required to DEQ and then re-ENQ to perform the upgrade, you would lose control of the resource between the time you inspected it and the time you had the necessary serialization to update it. In the worst case scenario, someone else could change (or even delete) the resource in-between!! If there are others with a SHARED ENQ, attempting a RET=CHNG will either put you into a wait (possibly triggering a deadly embrace if you hold another SHR or EXC ENQ that some other task wants to go to EXC status on) or return a failure RC and require you to recover by attempting it again. It is MUCH better to get the EXC initially and later drop back to SHR (assuming that once you have done the code that needs the EXC you can live with just read access) but IBM has not provided this useful capability. -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 15:49 -0400 on 08/01/2006, Walt Farrell wrote about Re: Data set ENQueues and DEQueues in Jobs: Of course, if anyone else also has the resource with a shared ENQ, your RET=CHNG will fail, and at that point you have no choice but to DEQ and try again from the beginning (presumably starting with EXC that time around). Why is there no E-S downgrade capability? It would make life much easier and, for example, allow the Initiator to support a DISP=OLD to DISP=SHR change at Step Change instead of its current requirement to treat a DISP=SHR as DISP=OLD just because a prior step had DISP=OLD/NEW/MOD (thus postponing DISP=SHR access by other Jobs/Users until the last step accessing the dataset is done). -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Bruce Black said: Date: Sun, 30 Jul 2006 18:40:49 -0400 Sorry, ENQ RET=CHNG only changes a SHR ENQ to EXCL, not the other waqy And thereby hangs a long and knotted tale of how TSO ALLOCATE will sometimes create a data set with only a SHR ENQ on the DSNAME; fail to catalog it because of a duplicate catalog entry, then fail to delete it because it can't obtain an EXCL ENQ because another job has a SHR ENQ on the same DSNAME. I once unwittingly created uncatalogued instances on every storage volume of several data set names because of this behavior. It's a disappointment, for the above reason as well as others, that IBM has not seen fit to provide an option to downgrade an ENQ. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Ron and Jenny Hawkins said: Date: Mon, 31 Jul 2006 19:47:21 +0800 So you don't use SMS? Partly. We use SMS, but not all our prefixes and volumes are SMS controlled. Are yours? I once unwittingly created uncatalogued instances on every storage volume of several data set names because of this behavior. I should have said every _eligible_ storage volume. And this was long ago, perhaps even before SMS. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
Gil, Partly. We use SMS, but not all our prefixes and volumes are SMS controlled. Are yours? In the last shop where I was a Storage Administrator - yes, every prefix is tested specifically or under a mask; and the last shop I did an SMS conversion - yes. That is except for SYSRES, MCAT, Paging, and a handful of sandpit volumes. Everything mounted as PRIVATE. SMS is your friend... :) I should have said every _eligible_ storage volume. And this was long ago, perhaps even before SMS. It can still happen. I do it on our Lab systems all the time :( Ron -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/30/2006 at 09:44 AM, Robert A. Rosenberg [EMAIL PROTECTED] said: Part of the problem with this type of incorrect conflict is that the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN (the RNAME) as the identifier of the Dataset not the CORRECT DSN with VOLSER. Which volser? You would have to be very careful to avoid a deadly embrace. This goes back to the OS360 (PCP/MFT/MVT) days when the concept of having two CPUs sharing their ENQ/DEQ Queue was not imagined. OS/360 supported shared DASD. OS/360 had an MP option and ASP supported loosely coupled processors. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note [EMAIL PROTECTED] said: Date: Mon, 31 Jul 2006 12:20:31 -0300 Part of the problem with this type of incorrect conflict is that the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN (the RNAME) as the identifier of the Dataset not the CORRECT DSN with VOLSER. Which volser? You would have to be very careful to avoid a deadly embrace. Some months ago in these pages I proposed the rudiments of a scheme of obtaining a SHR ENQ on each DEB when a data set is opened, and an EXCL ENQ on the DEB of any extent to be freed. Mark Thomen (IIRC) countered with examples of system code that manipulate extents without ever creating DEBs. The consensus of the list was that my idea was refuted and the topic closed. Apparently it has resurfaced. But no one has considered the rescue of the idea -- that any code which manipulates extents ought to be repaired either to create DEBs or at least to issue the ENQs that would be required. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 13:14 -0600 on 07/28/2006, Paul Gilmartin wrote about Re: Data set ENQueues and DEQueues in Jobs: A JES3 partisan once told me, as I whined about a job spewing ENQ messages into SYSLOG while another job held an ENQUE for the same DSN on a different volume, That wouldn't happen with JES3. Perhaps he merely meant that JES3 would hold the second job from initiation until all resources it needed were immediately available. Part of the problem with this type of incorrect conflict is that the SYSDSN Queue (the QNAME used for the ENQ/DEQ) regards the DSN (the RNAME) as the identifier of the Dataset not the CORRECT DSN with VOLSER. This goes back to the OS360 (PCP/MFT/MVT) days when the concept of having two CPUs sharing their ENQ/DEQ Queue was not imagined. Since you do not know what VOLSER the DSN you are ENQing on will be on until you actually allocate it at Step Initiation time, there is no way to fix this problem (such as having another QNAME that uses a RNAME that contains the VOLSER along with the DSN). In fact, ISPF which should know better (since it allocates at dynamically and thus KNOWS at allocate time which VOLSER to use [either due to looking at the catalog or accepting this info from the User]) still does its private ENQ on a DSN only RNAME and thus can refuse to access a DSN on VOL2 when another ISPF User has a VOL1 resident Dataset with the same name in use. -- 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
Re: Data set ENQueues and DEQueues in Jobs
At 09:06 -0700 on 07/28/2006, Edward Jaffe wrote about Re: Data set ENQueues and DEQueues in Jobs: Staller, Allan wrote: I am not familiar enough w/JES3 to make a useful comment. The initiator (IEFIIC) is not a JES program! It does what it does without regard to the type of job entry subsystem in use. As stated previously by others, the data set ENQs are acquired at job initiation time. They're released at the end of the last step that references them. I have the impression that the initiator is also smart enough to issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if subsequent steps have the DSN as DISP=SHR after the last step that has it as DISP=OLD (ie: Exclusive). IOW: The holding of DISP=SHR Jobs due a DISP=OLD job will get removed with the Blocking Job only needs a DISP=SHR ENQ not when it no longer needs the dataset (ie: When the ENQ is released as is referenced above). -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Robert A. Rosenberg said: Date: Sun, 30 Jul 2006 09:59:30 -0400 I have the impression that the initiator is also smart enough to issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if I was unaware of such a facility. In fact: Title: z/OS V1R7.0 MVS Assembler Services Reference ABE-HSP Document Number: SA22-7606-07 91.1.8 z/OS V1R7.0 MVS Assembler Services Reference ABE-HSP 91.1.8 Parameters ,RET=CHNG The status of the resource specified is changed from shared to exclusive control. When RET=CHNG is specified, the exclusive|shared (E|S) parameter is overidden. This parameter ensures that the request will be exclusive regardless of the other parameter. Perhaps initiator can do something ordinary programmers can't. I haven't checked the Authorized volme. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
I have the impression that the initiator is also smart enough to issue a ENQ TYPE=CHNG (to switch from ENQ=EXC to ENQ=SHR) if subsequent steps have the DSN as DISP=SHR after the last step that has it as DISP=OLD (ie: Exclusive). Sorry, ENQ RET=CHNG only changes a SHR ENQ to EXCL, not the other waqy -- Bruce Black Senior Software Developer Innovation Data Processing -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Friday 28 July 2006 23:47, Steve Myers wrote: At step end, the initiator will DEQ any DSNs that are no longer needed, i.e. those which are not referenced on a DD in any later step. This change was fairly recent. Originally, the data set ENQ lasted for the life of the job. I do not recall when the data set ENQ was released when the last step that referenced the data set in JCL terminated. I don't think it was fairly recent. In fact, I'm quite sure MVS has behaved like this since the beginning, over 30 years ago. The allocation routines keep a table in SWA called the DSNAME Table (DSNT) which contains an entry for each dsname in the job along with the 1-byte number of the last step that references it. At the end of each step, the table is scanned for matching step numbers and DEQs are issued accordingly. The SVA of the DSNT is in field SCTADSTB. The IEFDSNT macro describes the DSNT. The RECALL module in file 183 of the CBT tape scans the DSNT. I don't recall if DYNALLOC creates entries in the DSNT. My guess is that it doesn't, but I don't really know. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[EMAIL PROTECTED] -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Friday 28 July 2006 04:42, Hunkeler Peter, KIUB 34 wrote: ... he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be serialized. The jobs would then execute in parallel until they come to that specific step. ... This is a legend. The Initiator ENQs data sets at JOB Init time based on the most restrictive use (SHR vs NEW/MOD/OLD) of each data set in the job. The initiator won't change the ENQ scope, but DYNALLOC can upgrade a data set ENQ from Shared to Exclusive. You can issue an ALLOCATE command in the middle of a job to change a data set ENQ from Shared to Exclusive, but if it fails because the data set is allocated somewhere else, all you get is a non-zero return code. I wrote a program called SHR2OLD eons ago to bump data set ENQ from SHR to OLD in the middle of a job and wait if there's a conflict until the other job frees the data set. It had to be used judiciously, as it was a great way to get jobs in a deadly embrace. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[EMAIL PROTECTED] -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Fri, 28 Jul 2006 10:42:03 +0200, Hunkeler Peter (KIUB 34) [EMAIL PROTECTED] wrote: snip My colleague claimes that he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be seriallzed. The jobs would then execute in parallel until they come to that specific step. They also said that this will not work in a JES3 environment because JES3 behaves as I described above. This contradicts my understanding (and experience). Can anybody enlighten me if this has changed in either JES2 or JES3, and if so when this change happended. I seem to remember as far back as MVS/XA that the job-level-ENQ behaviour is how it works. Am I wrong? The first MVS I worked on was SP 1.3 + JES2 and it worked the way it does now. Perhaps an older-timer can tell you how it was before that. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Data set ENQueues and DEQueues in Jobs
I've worked on MFT, MVT, and VS1, MVS, OS/390, and Z/OS and it seems like it's been that way since the planet cooled. Of course, old age and time have caused some data to be lost due to decaying storage media... Daniel McLaughlin ZOS Systems Programmer Crawford Company PH: 770 621 3256 * Everything comes to him who hustles while he waits. ? Thomas A. Edison -- 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
Re: Data set ENQueues and DEQueues in Jobs
Is is my understanding and experience that the initiator will ENQ on all data sets referenced in the JCL (all steps) at job initiation time. The job will not start even the first step before all ENQs have been granted. So a job might be WAITING FOR DATASETS even if the one not yet available is only referenced in step nn (nn 1). At step end, the initiator will DEQ any DSNs that are no longer needed, i.e. those which are not referenced on a DD in any later step. It is also my understanding that this is initiator business and therefore works the same way in either JES2 or JES3 environments. (I don't talk about main device secheduling in JES3, which only handles devices, not DSN ENQs). Peter, you are 100% correct. I seem to recall that in the old days, before OCO, there were USERMODs that changed this. Heck, I think I wrote one myself for SVS. But these have never been standard IBM operation. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: Data set ENQueues and DEQueues in Jobs
snip My colleague claimes that he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be seriallzed. The jobs would then execute in parallel until they come to that specific step. They also said that this will not work in a JES3 environment because JES3 behaves as I described above. This contradicts my understanding (and experience). /snip This is indeed true. However, it is not the initiatior that does the enqueues it is allocation. The step will not proceed until all enqueues are granted. Yes two jobs can be serialzed on a single resource(dataset) by coding disp=old/mod On one or both of the jobs. However, the 1st one wins. Given JOBA and JOBB, there is no guarantee that JOBA will always be the first to obtain the enqueue. This can be extened to any number of jobs. The jobs will execute using the serialized resource in the order the reached the point of serialization. Again, there are no guarantees that the jobs will process in JOBA, JOBB, JOBC, Order. I am not familiar enough w/JES3 to make a useful comment. -- 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
Re: Data set ENQueues and DEQueues in Jobs
We had a usermod that changed all shared ENQs to exclusive when a dataset was opened for update. It might even have been on the CBT mods tape. Jon L. Veilleux [EMAIL PROTECTED] (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Friday, July 28, 2006 10:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Data set ENQueues and DEQueues in Jobs Is is my understanding and experience that the initiator will ENQ on all data sets referenced in the JCL (all steps) at job initiation time. The job will not start even the first step before all ENQs have been granted. So a job might be WAITING FOR DATASETS even if the one not yet available is only referenced in step nn (nn 1). At step end, the initiator will DEQ any DSNs that are no longer needed, i.e. those which are not referenced on a DD in any later step. It is also my understanding that this is initiator business and therefore works the same way in either JES2 or JES3 environments. (I don't talk about main device secheduling in JES3, which only handles devices, not DSN ENQs). Peter, you are 100% correct. I seem to recall that in the old days, before OCO, there were USERMODs that changed this. Heck, I think I wrote one myself for SVS. But these have never been standard IBM operation. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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 - This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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
Re: Data set ENQueues and DEQueues in Jobs
On Fri, 28 Jul 2006 09:39:15 -0500, Staller, Allan [EMAIL PROTECTED] wrote: This is indeed true. However, it is not the initiatior that does the enqueues it is allocation. Right. Recently verified this in the longest PMR (amount of written text, traces, etc.) I ever was invovled in. Also the longest SLIP I've ever seen that finally found the bug: SMS controlled TEMP dsns not getting ENQed when DSNTYPE(LIBRARY) is used in IGDSMSxx to set the default PDS to PDSE (see APAR OA17001). OA13825 was acutally already opened / closed FIN for a different reported problem on z/OS 1.7, but I ran into this secondary problem when I migrated an LPAR to z/OS 1.6 so a new APAR was created. Here is display of the SLIP I had to set just for grins. D SLIP=SJF1 IEE735I 17.03.27 SLIP DISPLAY 785 ID=SJF1,PER-IF,ENABLED ACTION=TRACE,SET BY CONS ZELDENM,PRCNTLIM=10,00 LPAMOD=IEFSJCNL,001C,001C DATA=0,CURRENT.1R??,EQ,E2D1C1C3 TRDATA=STD,REGS,CURRENT.1R??,+4F,1R??+1C?,+29F,1R??+1C?+4?,+FF, 1R??+1C?+14?,+FF,1R??+1C?+24?,+FF,1R??+1C?+34?,+FF, 1R??+1C?+44?,+FF,1R??+1C?+54?,+FF,1R??+1C?+64?,+FF, 1R??+1C?+74?,+FF,1R??+1C?+84?,+FF,1R??+1C?+94?,+FF, 1R??+1C?+A4?,+FF,1R??+1C?+B4?,+FF,1R??+1C?+C4?,+FF, 1R??+1C?+D4?,+FF,1R??+1C?+E4?,+FF,1R??+1C?+F4?,+FF, 1R??+1C?+104?,+FF,1R??+1C?+114?,+FF,1R??+1C?+124?,+FF, 1R??+1C?+134?,+FF,1R??+1C?+144?,+FF,1R??+1C?+154?,+FF, 1R??+1C?+164?,+FF,1R??+1C?+174?,+FF,1R??+1C?+184?,+FF, 1R??+1C?+194?,+FF,1R??+1C?+1A4?,+FF,1R??+1C?+1B4?,+FF, 1R??+1C?+1C4?,+FF,1R??+1C?+1D4?,+FF,1R??+1C?+1E4?,+FF, 1R??+1C?+1F4?,+FF,1R??+1C?+204?,+FF,1R??+1C?+214?,+FF, 1R??+1C?+224?,+FF,1R??+1C?+234?,+FF,1R??+1C?+244?,+FF, 1R??+1C?+254?,+FF,1R??+1C?+264?,+FF,1R??+1C?+274?,+FF, 1R??+1C?+284?,+FF,1R??+1C?+294?,+FF,13R?+44?,+9F,13R?+10?, +9F,13R?+14?,+9F,13R?+18?,+9F,13R?+1C?,+9F,13R?+20?,+9F, 13R?+24?,+9F,13R?+28?,+9F,13R?+2C?,+9F,13R?+30?,+9F, 13R?+34?,+9F,13R?+38?,+9F,13R?+3C?,+9F,13R?+40?,+9F -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a message dated 7/28/2006 9:41:40 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I am not familiar enough w/JES3 to make a useful comment JES3 introduced /*NET many moons ago that will serialize jobs in the NET. Seems like they fixed it about the same time they broke SMB(speed matching buffer) on 3880's. 'We didn't know...' -- 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
Re: Data set ENQueues and DEQueues in Jobs
Staller, Allan wrote: I am not familiar enough w/JES3 to make a useful comment. The initiator (IEFIIC) is not a JES program! It does what it does without regard to the type of job entry subsystem in use. As stated previously by others, the data set ENQs are acquired at job initiation time. They're released at the end of the last step that references them. It has worked this way for as long as I have been in the business. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/28/2006 at 07:57 AM, Mark Zelden [EMAIL PROTECTED] said: The first MVS I worked on was SP 1.3 + JES2 and it worked the way it does now. Perhaps an older-timer can tell you how it was before that. The Initiator has waited for the dataset ENQ all the way back to OS/360. JES2 does not change that behavior. The only thing that ASP and JES3 changed was when the jobs actually hit the Initiator, not in what happened afterward. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/28/2006 at 10:42 AM, Hunkeler Peter (KIUB 34) [EMAIL PROTECTED] said: Is is my understanding and experience that the initiator will ENQ on all data sets referenced in the JCL (all steps) at job initiation time. The job will not start even the first step before all ENQs have been granted. So a job might be WAITING FOR DATASETS even if the one not yet available is only referenced in step nn (nn 1). At step end, the initiator will DEQ any DSNs that are no longer needed, i.e. those which are not referenced on a DD in any later step. It is also my understanding that this is initiator business and therefore works the same way in either JES2 or JES3 environments. (I don't talk about main device secheduling in JES3, which only handles devices, not DSN ENQs). Correct. My colleague claimes that he once was told by an ISV that in a JES2 environment two jobs can be serialized on a certain step by coding a DISP=OLD/MOD DD for a data set in the step to be seriallzed. It is certainly plausible that an ISV would have a representative who was not didn't understand how MVS works but also didn't understand that he didn't understand. The jobs would then execute in parallel until they come to that specific step. They also said that this will not work in a JES3 environment because JES3 behaves as I described above. This contradicts my understanding (and experience). You've never experienced an ISV that misinformed its customers, or a colleague that misquoted an ISV? Can anybody enlighten me if this has changed in either JES2 or JES3, and if so when this change happended. The ISV is either wrong or misquoted. I seem to remember as far back as MVS/XA that the job-level-ENQ behaviour is how it works. Am I wrong? No, and the behavior goes back, unchanged, to OS/360. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
In a recent note, Bruce Black said: Date: Fri, 28 Jul 2006 10:56:40 -0400 I should have mentioned one exception: GDGs. the initiator acquires an ENQ on the GDG base name at job initiation, SHR or EXCL but the full name of the absolute generation (the .GV00) is not resolved until step initiation, at which point the genertaion is ENQed. Normally this works fine, but if some program has ENQed a generation without ENQing the base name, it can get a ENQ failures at step initiation. This used to cause a JCL error but some years ago IBM implemented the SDSN_WAIT option in the ALLOCxx member of PARMLIB to allow you to specify what to do. JCL Error or deadlock? You pays your money and you gets your choice. Possibly another -- ALIASes. I believe I observed that if one job identifies a data set by an ALIAS and another job by the RELATED name, the two jobs run concurrently until the step containing the DD statement for the ALIAS. At this point, the initiator resolves the ALIAS and detects the ENQ conflict, and the job fails with a (JCL?) error. I don't know whether SDSN_WAIT affects this. AFAICT, IDCAMS neither issues nor respects any ENQ on the ALIAS. I believe I was able to delete an ALIAS and create a new one with a different RELATED data set name while another batch job had it ENQued. A JES3 partisan once told me, as I whined about a job spewing ENQ messages into SYSLOG while another job held an ENQUE for the same DSN on a different volume, That wouldn't happen with JES3. Perhaps he merely meant that JES3 would hold the second job from initiation until all resources it needed were immediately available. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: Data set ENQueues and DEQueues in Jobs
In [EMAIL PROTECTED], on 07/28/2006 at 01:14 PM, Paul Gilmartin [EMAIL PROTECTED] said: A JES3 partisan once told me, as I whined about a job spewing ENQ messages into SYSLOG while another job held an ENQUE for the same DSN on a different volume, That wouldn't happen with JES3. Perhaps he merely meant that JES3 would hold the second job from initiation until all resources it needed were immediately available. Yes. Google for MDS and JES3. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: Data set ENQueues and DEQueues in Jobs
Shmuel Metz (Seymour J.) wrote: In [EMAIL PROTECTED], on 07/28/2006 at 01:14 PM, Paul Gilmartin [EMAIL PROTECTED] said: A JES3 partisan once told me, as I whined about a job spewing ENQ messages into SYSLOG while another job held an ENQUE for the same DSN on a different volume, That wouldn't happen with JES3. Perhaps he merely meant that JES3 would hold the second job from initiation until all resources it needed were immediately available. Yes. Google for MDS and JES3. Or begin reading here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IAT2A640/4.1.3 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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
