Also keep in mind that z/OS provides elegant controls as to which address space can use a specific PC routine.
For example, your server could supply a System LX PC routine that performs some sort of SAF check on the caller before it performs the AXSET and ETCON to allow the address space to issue other non-System LX PC routines. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] http://www.rs.com/portfolio/mxi_g2 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: 24 January 2007 12:36 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SVCs In a message dated 1/24/2007 11:12:03 A.M. Central Standard Time, [EMAIL PROTECTED] writes: >So... SVCs are for dopes. PeeCees rool! Another reason not to write your own SVC routine is that some form of validity checking must be done by the SVC routine to ensure that all parameters passed to it are valid, including information about who invoked it, from where, and in what environment. Many vendors wrote user SVCs decades ago as a means for their products to switch states, and a technique used frequently by lazy programmers to pass a parameter was to put the parameter in a register just before the SVC instruction. This form of parameter passing is a very bad idea, it became widely known that it was a bad idea, and yet some vendors continued to do it. It is bad because an unauthorized user can probably look at the executable code in the SVC routine, disassemble it, and figure out what to put in what register so that the SVC will work for him. Parameter validation is still necessary with PC, but it is harder now for hackers to find the executable code that they can then disassemble. Bill Fairchild ---------------------------------------------------------------------- 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
