Barbara Nitz wrote:
First, as Ed pointed out, an SSRB will only be generated when the SRB has to
wait for something like a lock or get willingly suspended. The reason Tom has
only seen ssrbs in his dumps may well be that they're scheduled with the local
lock (or some other lock) held, and that isn't available when the srb is
supposed to get dispatched. In that case, without having executed a single
instruction, it gets suspended with an SSRB.
I repeat: There aren't necessarily SSRBs for *every* SRB. And as far as I know,
an SRB does not get automatically suspended just because the PER hardware
detects a hit.
Binyamin says that he cannot find the SRB anymore. Here's my guess what happened:
[analysis snipped]
SRBs were never intended to be "heavy duty" work units. Compared to what
most developers are used to with TCBs, their flexibility,
recoverability, resiliency and overall capabilities are sorely lacking
-- as is the quality of point-in-time and trace diagnostic information
captured for/about them.
IBM's decision to allow only enclave SRBs to run on zIIPs is the primary
reason so many developers are working with SRBs lately. In some very
important ways, our "bullet proof" platform is regressing. The more SRB
mode code that is written, the more fragile z/OS becomes. And, based on
what (little) I know about development plans at other software
companies, things will only get worse from here ...
On the bright side, people developing brand new SRB-mode infrastructures
get lots of hands-on practice with taking SADUMPs and IPLing their
systems. What fun! :-)
--
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
