>Is it your statement that the only "supported" use of this routine is to fail >the SVC call, not to do alternate processing?
Yes, more or less, that is my statement. The routine may do anything it wants that is related to failing the SVC call. >has anyone ever submitted requirements to formalize the way >it really gets used? Thereby securing against future changes that might >break the unsupported feature? Not to my knowledge. And, yes, submitting such a requirement would be a good thing to do. There's not much we even could do to break the "feature". And I'm sure we would not intend to do so. But having it recognized and documented is always good. In my mind, any SVC front-ending discussion (whether screening or via SVCUPDTE) should center on "why do you need to front-end the SVC". I suspect that in a lot of cases it is because the SVC processing does not provide a suitable exit. Would not it be better for the system to provide exits rather than have you front-end SVC's? The same is true for PC's. I suspect that much of the answer lies with practicality and time-of-availability -- the SVC mechanisms are available now and who knows how long it would take to get what you need in terms of exits. A key question is: once the SVC Screening routine has gotten control, how does it then make sure that the "real" SVC routine gets control both in the right environment (locks included) and also with all the right data (potentially all 16 64-bit GRs and ARs at the time of the SVC issuance, with the PSW of the issuer)? Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- 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
