MSO Console Installation

Installation Steps

In order to activate the MSO Console, the following steps must be performed:

1. Install a VTAM applid for the console. This is described in Installing MSO. Assign a VTAM APPLID to MSO. The Console requires a separate LU2-capable applid, distinct from the one used for VTAM access to MSO. Both applids may be defined in the same VTAM major node definition, as shown in the sample in Installing MSO.
2. Create a console configuration file, using the sample in MSO.DATA(SSCHCNFG) as a template. The local_lu_name record must be updated to reflect the VTAM applid that the console is to use. No other records in the sample should be changed. It is particularly important to ensure the lower-case keywords in the file are not accidentally changed to upper case.
3. Allocate ddname FOCCONS in the MSO JCL; it should point at the console configuration file. If communication traces are needed, in the event of problems activating console communications, then ddname STDOUT must be allocated as well.
4. If you will be using a VTAM session manager with the MSO Console, refer to Testing and Logging on to MSO.
5. Decide whether you will be using internal security, where all authorizations are specified in the MSO configuration file, or external security, where all authorizations are specified in an external security system, such as RACF. MSO Console security is described in detail in Security. If internal security is to be used, specify

CONSEC = INTERNAL

in the MSO Configuration file, and specify the CONSOPER, CONSDTL, and CONSUSER records as appropriate.

If external security is to be used, specify

CONSEC = EXTERNAL

in the MSO Configuration file, and specify the CONSCLASS, CONSENTO, CONSENTD, and CONSENTL records if the defaults are inappropriate for your site, as described in Security. You must also supply the appropriate access rules in your security system in order to enable access to MSO Console. If external security is used, MSO must be running with EXTSEC = YES specified in the MSO configuration file.

The above configuration file records are described in detail in The MSO Configuration File.

6. If MSO is running APF-authorized, and the MSO configuration file does not contain the SMFNUM record, add the following record to it:

SMFNUM = 0

This allows the display of storage, CPU, and I/O details in the Display Users panel.

7. If desired, tailor command authorizations in the SSCONSEC table.

Security

The MSO Console provides both authorization levels of security and control of access to the MSO Console.

Authorization Levels

The MSO Console provides three levels of security: operator, detail, and logon.

• Operator authority allows a user to issue MSO operator commands, which affect the region's operation. This includes actual MSO operator commands, as well as operator-style commands from the panels.

• Detail authority allows a user to see details on other users, such as their current FOCEXEC, the current screen contents, and which files are allocated to the user.

• Logon authority allows a user to log on to the console. Logon authority enables a user to see I/O and CPU statistics, and to see which userids and services are active. Users with logon authority always have detail and operator authority over users who are logged on to MSO with the same userid as their own.

The actual association of a given function with a given level of authority may be tailored by customizing SSCONSEC, as described below.

Access Control

Internal security is controlled by listing the userids that have access to the console in the MSO configuration file. Wildcards may be used to simplify administration. The CONSOPER, CONSDTL, and CONSUSER records are used for internal security, and are described in The MSO Configuration File.

Note: With internal security, CONSUSER is automatically implied when either CONSOPER or CONSDTL is specified for a userid.

External security is controlled by validating access to the MSO Console through SAF. By default, a resource class of "FACILITY" is used, and the following resource names (also known as entities) are used:

The resource class and/or resource names may be changed by specifying the CONSCLASS, CONSENTO, CONSENTD, and CONSENTL records in the MSO configuration file, if the defaults are not adequate.

When a user attempts to log on to the MSO Console with external security, three calls are made to SAF to validate access: READ access to the LOGON rule, READ access to the DETAIL rule, and READ access to the OPERATOR rule. A user must have LOGON access in order to use the MSO Console.

Following is an example of RACF rules that might be used if the default class and resource names are in effect:

RDEFINE facility ibi.console.logon uacc(read)

RDEFINE facility ibi.console.detail uacc(none)

RDEFINE facility ibi.console.operator uacc(none)

PERMIT ibi.console.operator class(facility) acc(read) id(sys user1)

PERMIT ibi.console.detail class(facility) acc(read) id(sys user2)

Tailoring Console Authority

The MSO Console divides functions into different classes: Operator, Detail, and User. It also allows certain commands to be executed against a subtask when the userid associated with the subtask is the same as the userid of the MSO Console operator. If desired, you may change the classes to which functions are assigned. These classes are then assigned to users through the MSO configuration file.

The table SSCONSEC contains the association between functions and their classes. Source code for SSCONSEC is found in MSO.DATA(SSCONSEC). As shipped, the table contains the following:

To change these associations, edit SSCONSEC as appropriate, and then assemble and link-edit it.