IBM Mainframe Discussion List <[email protected]> wrote on 09/17/2012 04:42:20 PM:
> My SRB executing on pr 02 did the following in that order: > > PC entered POST to post an ecb a task was waiting on > then immediately on return, updated a count field in a data area, > decrementing it by one. > > SPLAT...0C4. > > Trace table showed the PC for the POST, then the SSRV with a timestamp. > Nothing more on pr 02 till the 0C4. > On Pr 00, my waiting task gets dispatched by the ecb post. It then > posts 2 other tasks to do some work. Both of them get dispatched. > the 2nd task to get dispatched deleted the data area the SRB wanted to > update, to decrement a count. > > finally, my SRB has the entries for the program check. > > Evidently, lpar processing steals processors and MVS has no knowledge of > it. > > When I wrote the code, I made the mistake of figuring that an SRB would > be dispatched before a task. That looks to be the case if the SRB is > waiting to run. But, the only thing I can figure is > that pr/sm stole it, so the SRB didn't get interrupted, and placed on > any kind of a waiting to dispatch queue. LPAR with shared processors has worked that way since 1989 (and VM, since long before that). If LPAR/VM redispatches your Logical Processor on a different Physical Processor, you may be able to observe that via the rightmost column of the formatted SYSTRACE (under IPCS only). If your Logical Processor gets redispatched on the same Physical Processor, then the time between subsequent trace entries is often the only way to infer an LPAR/VM dispatching effect. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
