> Gregory, Gary G wrote: >> That is true but if the application is NOT passing the UTOKEN or using >> the macro that requires the commands be defined in OPERCMDS then that >> won't work. > > I'm not sure I follow you here... > > Most of the time, passing UTOKEN is unnecessary. For example, MGCRE > issued from a TSO session does not need to pass UTOKEN. It's only in > more exotic situations, e.g., multiuser address spaces, where the > differentiation is required. Some products, like (E)JES, always pass a > UTOKEN because they want to differentiate between commands explicitly > entered by the user and those generated by the product to affect a > resource protected by other means. This is an above-and-beyond feature > of mature, robust products and is by no means a requirement to make > OPERCMDS work. > > OTOH, "using the macro that requires the commands be defined in > OPERCMDS" is not optional. That macro, called MGCRE, is the mechanism by > which programs enter commands into the system. And, the program doesn't > do anything special to cause its commands to be validated against > OPERCMDS resources. CMDAUTH is issued by the system automatically > unless, as I stated earlier, MGCEFAST is set by the MGCRE issuer. >
Ed. Looks like MGCEFAST will bypass command authority checking in the OPERCMDS class and also bypass the CONSOLE AUTH(xxxxxx) settings in the CONSOLxx parmlib member and the AUTH(xxxx) setting in the user's OPERPARM segment plus bypass command exits and SSI--whatever that means. Seems like MGCEFAST is kind of like RACF truested where authority exits are bypassed and 99% of authority checks are passed just for issuing commands from MGCRE. MGCEFAST = Bypass SSI, command exits, and CMDAUTH. George Fogg >> I was only suggesting they refer to the documentation to >> see if commands are defined in other resource classes. The CMDAUTH >> macro requires that all entities be defined in OPERCMDS. >> > > This might be the root source of confusion for this discussion. When > someone says "MVS commands", I think of commands documented in the "MVS > System Commands" book, i.e. those that can be issued from an MCS > console. Such commands are subject to checking against resources in the > OPERCMDS class. > > Obviously, other commands, not defined in "MVS System Commands", would > be subject to whatever security checking is appropriate for the command > and the product that defines it. I think this may be the point you're > trying to make. If so, I agree with that aspect of your statement. > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 310-338-0400 x318 > [EMAIL PROTECTED] > http://www.phoenixsoftware.com/ > > ---------------------------------------------------------------------- > 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
