Data set ENQueues and DEQueues in Jobs

We've got some discussion here about DSN ENQueueing and DEQueueing in batch 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 grant

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 befo

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 acco

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

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 co

Re: Data set ENQueues and DEQueues in Jobs

On Fri, 28 Jul 2006 10:42:03 +0200, Hunkeler Peter (KIUB 34) <[EMAIL PROTECTED]> wrote: >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 job

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 * "

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 i

Re: Data set ENQueues and DEQueues in Jobs

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 t

Re: Data set ENQueues and DEQueues in Jobs

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

Re: Data set ENQueues and DEQueues in Jobs

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,

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 t

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(spee

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 tim

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

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 befo

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 resol

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." Perhap

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

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

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

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

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 MV

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

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

Re: Data set ENQueues and DEQueues in Jobs

Gil, So you don't use SMS? > > I once unwittingly created uncatalogued instances on every > storage volume of several data set names because of this > behavior. > -- For IBM-MAIN subscribe / signoff / archive access instructio

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 o

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,

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 CORRE

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

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

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

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 o

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)

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 S

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

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 (II

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

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 E

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 kno

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

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

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. I

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

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 >

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

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 di

Re: Data set ENQueues and DEQueues in Jobs

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 mon

Re: Data set ENQueues and DEQueues in Jobs

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

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 mainta

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 mainta

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 > > resour

Re: Data set ENQueues and DEQueues in Jobs

At 16:34 +0300 on 08/01/2006, Binyamin Dissen wrote about 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 i

Re: Data set ENQueues and DEQueues in Jobs

At 14:09 -0600 on 08/01/2006, Paul Gilmartin wrote about Re: Data set ENQueues and DEQueues in Jobs: 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

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

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

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 upd

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=CHN

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

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

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 mu

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

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 (Se

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.

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

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 with

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.

Re: Data set ENQueues and DEQueues in Jobs

ional, 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 >

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 upd

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 wh

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 t

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. Act

Re: Data set ENQueues and DEQueues in Jobs

RET=NONE is the same as RET= parameter omitted. IBM Mainframe Discussion List 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

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 someth