A TSO/E user, could have the ability to start an MVS, MCS, Multiple Console Support operator control session from their TSO/E terminal session. Typically your security product must have specification defined to allow you to do this. In RACF, there are two facility class profiles involved, CONSOLE and OPERCMDS. Lead console facility class profile, allows you to cite an MCS CONSOLE session. This allows you to issue the TSO/E console command. RACF can maintain precise control over the commands you are authorized to issue via the OPERCMDS profile. A user may be authorized to issue only one command, a group of commands, or all operator commands. In this course, your lab user ID is authorized to issue MVS display commands. The TSO/E CONSPROF command sets up your CONSOLE profile. What is not strictly necessary to define a CONSOLE profile in order to issue MVS operator commands, it is recommended that you do so, especially in REXX Exec where you plan to capture and process the messages issued in response to these commands and do not wish them to be displayed on the CONSOLE screen. The profile defines whether or not solicited and unsolicited messages are to be displayed on the CONSOLE. Solicited messages are messages generated by the system in response to MVS commands that have been entered. Unsolicited messages, are system messages not in response to MVS commands. These could be messages sent to you by another user or messages generated automatically by the system as various system events occur. If messages are not to be displayed on the CONSOLE, they'll be stored in a message table. The number of solicited or unsolicited messages that may be stored can be defined by a profile. The TSO/E CONSOLE command allows you to activate or deactivate an MVS CONSOLE session, issue an MVS operator commands and set a CART value. This command, like CONSPROF, requires authorization to use. The CONSOLE commands must set a return code of 0. If it doesn't, then your MCS CONSOLE session was not properly started and your MVS operator command may not work properly. The GETMSG function is a TSO/E REXX function. It's implemented as part of TSO/E but is only usable inside a REXX Exec. It's also not available in all REXX implementations. This function allows us to capture messages that would otherwise be displayed on an operator CONSOLE, but are instead being stored in a message table because the CONSPROF command defined SOL display or UNSOL display with a value of no. The first argument to get message defines a stem, which is used to create compound variables with the messages. The variables will be called stem.1 and stem.2 and so forth, with each variable holding one line of message output, [inaudible] OUTTRAP function does for the TSO/E command output. Also, the variable stem 0 is created, holding the number of compound variables that were created, again, much like the OUTTRAP function. The second argument defines what type of messages are to be retrieved from the message table. So, SOL will only retrieve solicited messages, UNSOL only retrieves unsolicited messages. EITHER will retrieve both solicited and unsolicited messages. EITHER is the default. CART stands for Command and Response Token, is used to associate a value with one or more MVS commands and the messages issued in response to those commands. The CART allows the GETMSG function to retrieve messages in direct response to particular command by specifying the same CART value in the GETMSG function, as was associated with the command itself. The GETMSG function only recognizes the use of a CART if the type of message being retrieved is SOL. The CART value may be from 1-8 characters, or from 1-16 hexadecimal digits long. If you specify a value less than 8 characters or 16 hexadecimal digits, it is padded on the right with blanks. If no CART is established for a command, a default value of 16 hexadecimal zeros will be used. Here's how it's normally done in REXX. First, we set up a console profile, specifying this solicited messages are not to be displayed at the console. We need to do this, so we can retrieve these messages with the GETMSG function. We're also specifying that we can store up to 400 lines of message output in the message table in storage. Next, we activate an MCS CONSOLE session, so that we can issue operator commands. The address CONSOLE instruction is then issued so that we don't have to continually issue the TSO/E console command to do things. We're now in CONSOLE mode, and all host commands are now sent to the CONSOLE host command environment instead of going to TSO. The next thing we want to do, is to set a CART to be associated with the command we're about to execute and its responses. Now, we can issue the command itself. The output from the command is routed to the message table. If we want to execute another command, then we set a new CART and issue the next command. This can be repeated over and over for as many commands as we want to issue. There is one thing we need to be careful about, though. We're storing up to 400 solicited messages in the message table in memory. If that capacity is exceeded, then no more messages will be stored until the message capacity situation is resolved. The GETMSG function can then be issued, specifying the CART of the command whose responses are to be retrieved. A separate GETMSG should be issued to retrieve the output from each command that was issued. You can display or manipulate the messages that are captured in the compound variables in whatever way you want. When we're done and getting ready to terminate the Exec, we switch back to the TSO host command environment. We then issue the CONSOLE DEACTIVATE command to turn off the MCS CONSOLE session and to return to a regular TSO/E terminal session. We could have also issued the CONSOLE sub-command and deactivate before switching back to the TSO Environment. That's it. Finish whatever other processing you're excited to do and exit. Once you get the flow of control down, it's really not that hard.
