First - a note to Philippe - check the current SVC screening documentation -
there are situations where the table should be 1280 bytes long.

I wasn't going to say anything, however since Ed Jaffe and Jim Thomas have
disagreed with Peter on one subject, I will present an argument on this
subject.

Although one has to be careful on what you do in an SVC screening routine,
there are legitimate reasons to intercept an SVC.  One is to modify the
parameters passed to the SVC.  One example is to replace DD names on an OPEN
SVC issued by code that you do not have control over (for example, a non-IBM
TP monitor that allows execution of COBOL programs), where it is impossible
to plug your own DCB exit.

Before SVC screening, the only method was to swap your own FLIH - which
creates its own wasp's nest.

Roll your own FLIH or bend the documented SVC screening function?  I vote
for the latter.

Oh, and when I wrote one 12 years ago, I got some very nice assistance from
Level 2 in writing this routine.

Later,
Ray



-- 
M. Ray Mullins 
Roseville, CA, USA 
http://www.catherdersoftware.com/
http://www.mrmullins.big-bear-city.ca.us/ 
http://www.the-bus-stops-here.org/ 

German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. 

--ilvi 


> -----Original Message-----
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter Relson
> Sent: Saturday 26 August 2006 12:41
> To: [email protected]
> Subject: Re: SVC Screening and TCBUSER
> 
> >I'm writing a SVC screening program to monitor some SVCs.
> 
> Just to mention, since no one else seems to have: this is an 
> abuse of SVC screening. Perhaps not a big abuse, but one nevertheless.
> "Subsystem SVC screening allows a system routine to define 
> those SVCs that a specific task can validly issue."
> 
> You just better make sure that 100% of the environment  for 
> the SVC target routine is set up when you give control to 
> that routine, and that you did nothing that the system might 
> rely on not having happened. I'm being vague here because 
> there is no documentation available or intended to tell you 
> what the 100% is and what (if anything) you must not do.
> 

----------------------------------------------------------------------
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

Reply via email to