Using an MVS system console as a CICS terminal

If you intend to use an MVS system console as a CICS® terminal, you might need authorization to use the MVS MODIFY command by using the OPERCMDS resource class.

You can specify automatic preset security on the console's CICS terminal definition so that the console user obtains the correct level of authority without explicitly performing a CICS sign-on (which exposes the password).

If preset security is not defined, console users must sign on to get authority different from the default user. In this case, the password or password phrase can generally be seen on the console and system log. However, if CICS is defined as an MVS subsystem in a JES2 system, you can use the HIDEPASSWORD=YES option of the DFHSSIxx member in SYS1.PARMLIB, which enables CICS to intercept the command and overwrite the password or password phrase with asterisks. For more information about defining CICS as an MVS subsystem, see Defining CICS as an MVS subsystem.

You can use the CESL or CESN commands to sign on to CICS from a console. With CESL, you can use either a standard password or a password phrase as authorization. CESL treats any password over 8 characters as a password phrase. CESN does not support the use of password phrases. The format of the CESL and CESN sign-on commands, when entered from a console, is as follows:

MODIFY jobname,command_name [USERID=userid][,PS=password]
       [,NEWPS=newpassword][,GROUPID=groupid]
       [,LANGUAGE=language-code]

If a passphrase contains mixed-case characters, blanks, or both, the value of the PS parameter must be enclosed in single quotation marks, for example:

F JATP3250,CESL USERID=JAT232,PS='MOND July 17th'

The maximum length of the MODIFY command is 126 characters, including F taskname; the maximum length of a passphrase is 91 characters when it is specified in this way:

F JATP3250,CESL USERID=JAT284,PS='This is a valid long passphrase of 
length 91 chars for CESL JAT testing 9XYZ@,#,.12345678!i'

For more information, see Guidance for issuing console commands in z/OS.

With CESL, the PS (password) and NEWPS (new password) parameters must match; they must be either both password phrases or both standard passwords. You cannot authorize a new password phrase that uses a password and you cannot authorize a new password by using a password phrase. The PS and NEWPS parameters can contain spaces or punctuation characters, including single quotation marks, but each of these characters must be enclosed in two single quotation marks.

If any of the data entered on the command is invalid, or if the password or password phrase is missing or expired, CICS terminates the sign-on attempt.

You can authorize TSO users to use the TSO CONSOLE command. (For more information on this command, see z/OS TSO/E System Programming Command Reference.) These users must be defined to CICS as consoles, by using the CONSNAME option of the DEFINE TERMINAL command, or be supported by autoinstall for consoles. For more information, see Autoinstalling MVS consoles.

When the PS parameter is omitted from the CESL or CESN command, RACF® can produce a security violation message, ICH408I. CESL and CESN cannot distinguish a user who is defined with OIDCARD, NOPASSWORD from a user who is defined with a PASSWORD authenticator who intentionally omits the password. To establish whether to prompt for a password or to reject the sign-on (a user who is defined with OIDCARD cannot sign on at a console), the sign-on must be attempted. If the sign-on fails, message ICH408I is issued, and CICS interprets the return code from RACF to determine whether the PASSWORD or OIDCARD authenticator is required.

Users can sign on using CESL or CESN, or you might prefer to use preset security (the normal preset security for CICS terminals, or automatic preset security for consoles). When the TSO user uses the CONSOLE command, that user's user ID, by default, becomes a console name. However, you can change the console name to something else by using the CONSNAME(name) option on the TSO CONSOLE command. This console name can then be used as a CICS terminal if there is a corresponding TERMINAL definition with the CONSNAME option in CICS (or if you autoinstall a terminal definition). If another name is specified, that name is the one CICS uses to communicate with the console. For example, it is possible for one TSO user to use a name that is the same as another TSO user's ID.

Furthermore, if the CONSOLE command is used to allow TSO operators to sign on to CICS with the CESL or CESN transaction, their passwords might be exposed on the TSO screen and in the MVS system log. You can prevent these potential exposures by defining the terminal as having preset security. It is advisable to use automated preset security for several reasons:

TSO users do not have to sign on, which avoids exposing their IDs and passwords on the log.
You do not have to define a relationship in a CICS definition between a console name and a user. A relationship might change frequently or become invalid.
You can define one autoinstall model that covers most of your console definitions and gives each user the correct level of preset security.

To define automatic preset security, specify USERID(*EVERY) to ensure that the correct user ID is signed on for every command, or USERID(*FIRST) to sign on the console by using the user ID that first issues an MVS MODIFY command to CICS, and retain this for subsequent commands.

Choose USERID(*FIRST) if use of a console is restricted to one or more users who have similar security characteristics to CICS using RACF, and you don't use the user ID as an identifier in applications.
Use USERID(*EVERY) if you need to ensure that each input request is tested to be sure that the console user has the correct security level. You should be aware that checking the user ID imposes an overhead on MODIFY, and changing the preset user ID imposes another overhead, which is equivalent to the console user signing on using CESL or CESN.