>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.
Gary, I'm not so much interested in the "which" than in the "how".
What you said about your "own" subsystem commands somehow confirms
my undestanding. But I still do not see how MGCEFAST can be useful
to anything than pure "MVS commands", provided my understanding
as posted is still correct.
If MGCEFAST is set by sysplex command routing, and if the bit says
"don't broadcast on the SSI", then how could a subsystem catch
its command on the remote system? And, how can it suppress
command authorization checking, when the mechanism is subsystem
specific?
Ok, I think I'll have to include sysplex processing and see if
I got this right (this is pure curiosity):
A command entered into the system through SVC 34 can be:
a) a native MVS command (this includes the ROUTE command)
b) a command beginning with a registered command prefix
c) a command beginning with a *non*-registered command prefix
SVC 34 sends the command to the commiunications task which in turn
tries to get the command processed by whomever as follows
1) Each command is presented to command exits, if any are installed.
- If any exit indicates the command was processed, that's it, no
further processing is done.
2) If the command starts with a registered prefix, then it is routed
to the target system (if not already here). On the target system,
the command is issued again (SVC 34) and begins its journey again
at 1) above.
3) If the command passes the exit(s) without being processed, it is
presented to the subsystem command routines listening on the SSI.
- If the command begins with *non-registered* prefix *and* ...
... the target subsystem is active, its routine will catch the
command, process it and indicate this upon return. Processing
ends here, i.e. not further broadcasting occurs.
... the target subsystem is not active, the command remains
unprocessed, next SSI routine will see it.
- If the command begins with a *registered* prefix *and* ...
... the target subsystem is active, its routine will catch and
process the command. Processing then ends here.
... the target subsystem is not active, the CPF should have been
deleted (in which case we don't end up here) or has been
directed to another system (in which case we again won't end
up here).
- If the command has not been processed by a subsystem it "falls
through" SSI broadcast processing and is send to "MVS" (see 4).
4) If it is a ROUTE command, the ROUTE command processor strips off
the ROUTE and sends the command to the target system(s) where it
is reissued by SVC 34 and starts its journey at 1) above on each
target system.
5) If it is not a ROUTE command, the MVS command processor analyzes
the command and, if valid, processes it. These are the commands
described in the "MVS System Commands" manual plus some additional
non-MVS commands like "Z NET...", "D NET..." which VTAM managed
to incorporate into the "MVS Command Processor".
6) Message IEE305I xxxxxxxx COMMAND INVALID is issued if the MVS
command processor did not recognize it.
Where does MGCEFAST fit into the picture?
Anyone dare to say I'm wrong ;-) I *hope* you do, and tell me where
I'm wrong. Better yet, tell me the truth.
--
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
