Peter,

Since it appears that the majority of the usage of SVC screening is other
than intended... has anyone ever submitted requirements to formalize the way
it really gets used?  Thereby securing against future changes that might
break the unsupported feature?

Rob Schramm

On Tue, Apr 26, 2011 at 8:21 AM, Binyamin Dissen <bdis...@dissensoftware.com
> wrote:

> On Tue, 26 Apr 2011 07:59:27 -0400 Peter Relson <rel...@us.ibm.com> wrote:
>
> :>>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)?
>
> :>I intentionally phrased the question the way I did, although no one
> :>answered it in that spirit. The answer, based solely on the posts
> :>so far, appears to be "no".
>
> SVC screening allows one to specify which SVCs will go to the coded routine
> instead of the standard SVC.
>
> :>There are a lot of other entertaining, interesting, probably useful,
> :>but nevertheless wholly unsupported, uses that have been found for
> :>SVC screening.
>
> Is it your statement that the only "supported" use of this routine is to
> fail
> the SVC call, not to do alternate processing?
>
> :>I do mean to provoke thought; I do not mean to cause alarm. As long as
> :>the SVC screening routine does everything right, so that the user
> :>gets what the user should get in all cases, I don't have overly much
> :>problem with this misuse. But very often that is not the case, including
> :>functional problems or even system integrity problems, related to
> :>examining the user parameters or due to making the SVC appear that it
> :>had not come from the user who actually issued it.
>
> :>Note that users who use SVCUPDTE to front-end SVCs often inject
> :>similar problems.
>
> Or supervisor state PC routines. Etc. Supervisor state routines callable by
> problem state have to validate everything.
>
> --
> Binyamin Dissen <bdis...@dissensoftware.com>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Rob Schramm
Senior Systems Engineer

w: 513.305.6224

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to