I would have thought this is exactly what the (RACF) Facility class is intended for. I assume that TSS has an equivalent feature, where you can code esoteric resources to be checked by a SAF call. Move the call to the facility class and you won't have to worry about changes in the underlying OS
Jerry Whitteridge Design Engineer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Haynes, Stan > Sent: Thursday, June 23, 2011 9:40 AM > To: [email protected] > Subject: Re: Obtaining System Information from a COBOL program > > I feel like I should expand on my query. > > We use CA-TSS as our security server. All datasets are protected. In > this case, the appl owners *need* to do a sec check to control the > type of access. In their own words: > "an application makes a call to our business team (app). We then > grant access via their HLQ, server packet name and access level - > allowing us some degree of control over the calling config design > ... Some of our servers are amalgamated, others are more specific". > > And there's also interest in logging the jobid of the caller of this > program (STCnumber if CICS, otherwise the batch jobid). > > Sysprogs here believe this security check can be removed in favor of > more traditional security permissions but that would require our > DBAs to do things differently. > > Right now the appl is calling a 24-bit assembler program for the > TIOT/DSN lookup, and one look at the code revealed they're not using > DSECT definitions enough. The appl folks are COBOL people, and as > such want to ditch the assembler program in favor of a COBOL routine > they found on the net. > > While the odds of seeing the TIOT (and other system-management > control blocks) change are slim, they're not nil either. An > application program that uses static mapping of control blocks (in > COBOL to boot!) could find itself in a broken state because of new > z/OS maint introducing a control block change, and then our ability > to deploy and maintain z/OS can be undermined. If the appl is > broken, what's the fix ? Appl programming change or software > rollback ? Sysprogs don't want to be held hostage by the appl > programmers. > > So I'm hearing "assembler code using established APIs like GETDSAB". > Comments, anyone ? > > > Stan > mailto:[email protected] > (613) 941-8091 > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Chris Craddock > Sent: June 23, 2011 11:25 AM > To: [email protected] > Subject: Re: Obtaining System Information from a COBOL program > > On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn > <[email protected]> wrote: > > > > > >I question Walt's statement above in one case and one case only. > The quote > > >below is from the z/OS V1R11 manual Using Data Sets SC26-74410- > 09: > > > > > ><quote> > > >...snipped (by Walt)... > > > > > >Note: VSAM OPEN routines bypass RACF security checking if the > program > > >issuing OPEN is in supervisor state or protection key 0." > > > > > ></quote> > > > > > >I call your attention to the last paragraph. I have been hoping > that IBM > > >will find a way to eliminate this restriction so I won't have to > do my own > > >RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in > > supervisor > > >state or key zero. > > > > > >I would imagine that not very many COBOL programs run in > supervisor state > > or > > >key zero, but Walt Farrell put on his security hat (his words) so > I > > thought > > >it might be proper to continue his line of thought. > > <http://bama.ua.edu/archives/ibm-main.html> > > > > You can be fairly certain that *no* COBOL programs run in sup state > and/or > key zero because LE does not officially support it and not at all > without > performing unnatural acts. That's not to say you can't conspire to > get that > to happen, but it would be most unwise to try. > > > > -- > This email might be from the > artist formerly known as CC > (or not) You be the judge. > > -------------------------------------------------------------------- > -- > 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 "Email Firewall" made the following annotations. ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ============================================================================== ---------------------------------------------------------------------- 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
