Thanks I am going to try the GTF trace Sent from my iPhone
> On May 3, 2016, at 9:02 AM, Blaicher, Christopher Y. <[email protected]> > wrote: > > Peter, > Obviously I didn't fully put on my thinking cap yesterday when I mentioned > the LOCAL LOCK. > > I was attempting to think of what might be causing the poster's perceived > condition of SRB #2 not appearing to run in the address space of the PAUSED > global SRB #1. > Your comment seems to be backing my understanding that once SRB #1 did the > PAUSE, SRB #2, or any other qualifying unit of work, was free to run in the > address space subject to normal dispatching rules. > > Michel, > You may want to run this situation on a test machine and start a GTF trace > and see what is happening from that. It should answer the question about if > the second SRB is being dispatched or not. > > Chris Blaicher > Technical Architect > Mainframe Development > Syncsort Incorporated > 50 Tice Boulevard, Woodcliff Lake, NJ 07677 > P: 201-930-8234 | M: 512-627-3803 > E: [email protected] > > www.syncsort.com > > > > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Peter Relson > Sent: Tuesday, May 3, 2016 7:51 AM > To: [email protected] > Subject: Re: SRB dispatching question > > I'll point out that the very fact that a global SRB paused very likely means > that you did not consider the SRB itself truly to be global. The system will > no longer treat it as such after the pause. > > Chris mentioned the local lock. I'm not sure why. You can't pause a work unit > that is holding the local lock. Obviously some other running work unit could > hold the local lock and thus prevent an SRB scheduled with LLOCK=YES from > beginning. > > In the scenario posed > SRB 1 scheduled to address space A pauses SRB 2 was scheduled to address > space A (from anywhere) SRB 2 will run, according to normal dispatch priority > rules. > > Peter Relson > z/OS Core Technology Design > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN > > ________________________________ > > > > ATTENTION: ----- > > The information contained in this message (including any files transmitted > with this message) may contain proprietary, trade secret or other > confidential and/or legally privileged information. Any pricing information > contained in this message or in any files transmitted with this message is > always confidential and cannot be shared with any third parties without prior > written approval from Syncsort. This message is intended to be read only by > the individual or entity to whom it is addressed or by their designee. If the > reader of this message is not the intended recipient, you are on notice that > any use, disclosure, copying or distribution of this message, in any form, is > strictly prohibited. If you have received this message in error, please > immediately notify the sender and/or Syncsort and destroy all copies of this > message in your possession, custody or control. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
