Posted by: Sasirekha R
cost savings, IBM, Lawsuit, Mainframe, Neon, SRB, zAAP, zIIP, zPrime
Understanding SRB the possible key of zPrime – more known for Neon vs. IBM Lawsuits
IBM mainframe specialty processors – zAAP and zIIP – cost significantly less compared to the General purpose processors and these “do not count” in software pricing calculations and ISV licensing costs. Third party tools are needed to make best use of this – as the system has to be tuned to use the right processors for the right load.
One such tool Neon zPrime has resulted in law-suits and has brought a whole stream of questions on the future of these specialty processors. More details on the lawsuits between Neon and IBM can be found at http://itknowledgeexchange.techtarget.com/mainframe-blog/neon-ibm-wrangle-over-trial-timeline-for-zprime-lawsuit/.
zPrime “facilitates” (and doesn’t guarantee) the movement from a general purpose processor (CP) to a specialty processor (zIIP or zAAP) potentially saving millions of dollars in software and hardware costs. The idea is to fully leverage the capacity of the specialty processors with significant loads moved away from the CPs.
What has made the issue interesting is that Zeon says that zPrime is a proprietary software solution governed by trade secrets and the details will not be publicly disclosed. Neon also claims that zPrime uses publicly documented exits and doesn’t modify IBM licensed internal code, zOS or other IBM software. No hooks to z/OS dispatcher, SMF, RLM or WLM either.
Though how zPrime works is not disclosed by Neon (and looks like not yet figured out by IBM – as the issue is still left open), some of the following points hint at SRB being the key:
- In MVS, the dispatchable units of work can be represented as Task Control Block (TCB) or Service Request Blocks (SRBs). zIIPs can only run applications that have been coded in SRB mode.
- zPrime product author Tony Lubrana has pointed out that it requires a lot of expertise and special authorization to run in SRB mode.
- One of the issues highlighted by Neon is that in z/OS v1.9 and below, TPUT SRB generated is not eligible for zIIP or zAAP processing.
Irrespective of where zPrime uses SRB or not, SRB is an interesting area with a lot of potential which has been regularly exploited by IBM products. For example CICS features like VTAM high Performance option, VSAM sub-tasking was achieved by executing parts of the work in parallel under an MVS Service Request Block concurrent with the CICS TCB.
Service Request Blocks (SRBs) routines are meant for providing specialized services. SRBs can be created only by units of work running in the supervisor state and key 0.
Scheduling a SRB is nothing but initiating the process. A program can schedule a SRM process using the SCHEDULE or IEAMSCHD macro. A program can initiate a SRB as a process in the same or different address space. An SRB in turn can schedule another SRB. An SRB routine can exit from its processing and to pass control to a task with minimal system overhead. The environment in which SRB routine runs and its ability to access address spaces and data spaces can be controlled by specifying appropriate parameters.
Being asynchronous in nature, these routines run independent of the scheduling program. Though SRBs advantage arises from its asynchronous nature, its processing can be synchronized with the scheduling program using WAIT / POST / SUSPEND / RESUME macros.
SRBs should not be a long-running program and usually represent very short pieces of work that complete much more quickly than TCB’s. Inline with this expectation, the system enforces the following restrictions on SRB:
- An SRB routine is generally not preempted by I/O interruptions once it is dispatched.
- To prevent them from going into a wait for any avoidable reason, system restricts SRBs from issuing SVCs (except abends). This implies that they cannot issue some of the system macros like ENQs and data management functions like opening datasets.
- An SRB cannot “own” storage areas. SRB routines can obtain, reference, use, and free storage areas, but the areas must be owned by a TCB. Any data that the requesting task and the service share must be placed in common storage.
- The Transfer Control (TCTL) macro requires that the SRB requesting the TCTL must not hold any locks and must be in primary ASC mode, where the home and primary address space is the same.
Detailed informatin on SRB available at http://www.cbttape.org/xephon/xephonm/mvs0401.pdf.
SRBs have been least exploited by organizations and understanding SRB better and trying to put it appropriate use can provide major benefits.