Given all that has been said here, I would suggest that you approach it this way -
1. Determine what is your allowable/acceptable margin for error (i.e. Walt's points about possible program control, etc, etc). 2. How "intrusive" can the service be? Is it acceptable to "open" the dataset to check, etc. (By the way, Wayne pointed out that open was the "easiest" way to do what you want, not necessarily the least intrusive). 3. If you have decided to go/stick with doing "proxy checks" (for want of a better term), then build and test the core module that performs these checks and make sure it delivers the results you are seeking. The point here is to, for the time being at least, forget about the coms mechanism, until you have something that provides the required service. 4. Once you have a service that works, then decide on the communications mechanism. If you aren't comfortable with a user SVC or PC routine, perhaps some form of networking (sockets?) mechanism better suites your needs and comfort level. > > <snip> > > > Now my routine needs to be called from programs not running > > under TSO. The problem is that IKJEFTSR only runs within a > > TSO environment. <> Suggestions from the IBM Main list were to > > create a SVC or PC or use BPX1FRK/BPX1EXM. > > Those are your only legal choices. It is no accident that is > is hard to get control in an authorized condition. Maintaining > integrity is more important than making the facilities easy to > use. Unfortunately, the APF authorized AC(1) job step program is > a blunt instrument and all of the officially blessed mechanisms > for call-level authorization are complex to set up and designed > to be relatively long lived, amortizing their set up costs over > many interactions. > > There is as yet no formal mechanism for transient requirements > like yours. One proposal evaluated by z/OS Design is to use the > security manager to augment authorization checks. In efffect, to > provide security mediated control over certain functions that > currently require APF or higher authorization. I don't know if > that plan went anywhere, but one of the designers will probably > tell us. > > In any case since that option doesn't exist yet it won't do you > any good right now. Beyond that you should consider the objections > raised by Ed Jaffe and Walt Farrell. It is surprisingly difficult > to know specifically what SAF question to ask in order to get the > right answer in the context of your caller. If you are trying to > decide whether or not to allow access to a dataset, you may as > well avoid the trouble and just use recovery to cover up the S913 > abend. > > CC > > ---------------------------------------------------------------------- > 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
