Tony, One major difference is that PC routines have to have an owning address space, whereas an SVC only needs an entry is PARMLIB and a small common storage resident module.
Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: 25 April 2011 18:07 To: [email protected] Subject: Re: Mixing Auth and Non-Auth Modules On 25 April 2011 07:48, Peter Relson <[email protected]> wrote: > One point about SVCs vs PC's: unless you go fairly far out of your way, a > PC routine will not confer additional key/state authorization to its > invoker. An SVC routine easily can do that by manipulating control block > fields. This conferrence leads directly to many of (or is itself) the > system integrity issue(s) related to a "magic SVC". I'm not convinced... I think the idea of the scary "magic SVC" is just something that's survived from decades past. They exist, of course, and I'm not minimizing the danger, but I don't see that it's much harder to code a "magic PC" routine to manipulate control block fields in an equally unsafe way. > Ed Jaffe mentioned SVC screening Yes. And some of us have asked for PC screening for years. > Curious: Does anyone use SVC screening for its documented intended > purpose: to define those SVCs that a particular task is allowed to issue > (and conversely those that it is not allowed to issue)? Hmmm... IIRC SVC screening was introduced in the late 1970s in support of VSPC (does anyone remember this product that was going to replace TSO as an end-user general purpose time sharing system, leaving expensive-to-run TSO only for sysprogs and the like? Anything to avoid users moving to CMS...) If SVC screening was intended only for disallowing certain SVCs, surely it would have a simple table of 256 yes/no bits. (Well, plus a couple more for ESR, perhaps, but still just a permissions table.) But instead, it has not just a table, but the ability to get control and do arbitrary things when a disallowed SVC is issued. So I'm not sure it was so simple as defining which SVCs a task can use. Surely VSPC did not just fail all disallowed SVCs, but converted some of them into different implementations to allow hosting of e.g. TSO apps in its non-TSO environment. We have used screening to deal with the case of a vendor product that in some cases issues TGET in a non-TSO environment. Unfortunately TGET returns RC=0 in such a case, and if the product assumes this means the (non existent) user has just hit enter, and re-issues the TGET... Well - it's not good for CPU consumption. We just change the RC to 8 (user has hit ATTN), and all is well. Whether this is what screening was intended for, I'm not sure, but I believe it's widely used for this kind of thing. I have encountered SVC screening in use by other vendors in production environments to modify GETMAIN and WTO arguments, among other things. Tony H. ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
