Peter, I can only speak for the products I've developed and how we implemented command security. Also, I might add that years ago I found a spreadsheet someone had at SHARE that listed each OPERCMDS entities. That could be used as a foundation to know which commands are verified.
If an OEM product uses the SSI (as we do with CA Tape Encryption) our subsystem is responsible for picking off the command and performing what action is required (we don't leave a WTOR for communications). Once the command has been found in the SSI, we perform a RACROUTE to see if the user (using that term in the most general sense) has access to the command. If a customer defined an OPERCMDS entity BES.DISPLAY UACC(NONE) and does not have the supporting code in place (in this case the CA Tape Encryption SAF Interface) then the entity is never verified. Again, I didn't mean to go start such a debate over my response yesterday. I just wanted to make sure the original poster reviewed their product's documentation. Regards, Gary You see me confused. Either I'm missing some recent change or, I have never understood how comand processing really works and am just about to discover this... This is my understanding (leaving out sysplex routing to drop that level of complexity): - SVC 34 (MGCR, MGCRE) is the programming interface to issue commands. It verifies the arguments and sends the command onto its journey through the system. No command authorization processing done yet. - The commands are presented to the SSI command listener routines (SSI function 10) in subsystem sequence, on after the other. - Finally the command is queued to the MVS command handler. SSI processing: - Each subsytem interested in commands sees each and every command (unless MGCEFAST has been set). - When a subsystem detects on if its commands, it marks it as "processed" (and of course, does whatever needs to be done to process the command). - When a subsystem sees a command marked "processed" it ignores the command. MVS command handler: - When the MVS command handler sees a command marked "processed" it ignores it. Otherwise it tries to interpret it as an MVS command (one of those commands described in the "MVS System Commands" manual). If this is correct, then neither SVC34 nor the MVS command handler can do authorization checking for subsystem commands. Each subsystem is responsible to do its own authorization checking (if at all). Again if this is correct, MGCEFAST can never be set for a "non-MVS" command, i.e. a command recognized by a SSI command listener, since it is "suppressing SSI" (BTW, I haven't found where MGCEFAST is documented.) Happy to learn where I'm wrong and how it really works. -- Peter Hunkeler CREDIT SUISSE ---------------------------------------------------------------------- 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
