Securing the OMEGAMON for CICS (3270)

The OMEGAMON for CICS component provides an OMEGAMON for CICS (3270) interface security facility. This section covers implementing security for OMEGAMON for CICS (3270).

To prevent unauthorized use of commands, the OMEGAMON for CICS (3270) is shipped with the internal security feature as the default. For an added level of security, however, you can set up an interface between OMEGAMON for CICS (3270) and an external security package, for example, RACF®, CA-ACF2, or CA-TOP SECRET.

These are the ways to implement OMEGAMON for CICS (3270) security:

External security for logon and internal security for commands
External security for logon and external security for commands
External security for logon and both internal security and external security for commands (using internal security with the locking feature)

Note: Passphrase support for the OMEGAMON 3270 Classic interface was introduced with APAR OA57133 (PTF UA98944). When passphrase support is enabled, OMEGAMON implements the OMEGAMON 3270 Classic interface external security without the use of security exits. For more information, see OMEGAMON 3270 Classic interface security and How to: Configure passphrase and MFA support in the OMEGAMON 3270 Classic interface.

Whether you use internal security, external security, or a combination of the two, you can customize the OMEGAMON for CICS (3270) security table to the needs of your installation.

This section describes the customization procedure and uses the following terms:

Control Statements: Locate and edit the KCIJPSEC job. The RTE_X_SECURITY_EXIT_LIB parameter in the LPAR configuration profile is pointing to the location. The default is RKANSAMU. The needed control statements are found in the KCIJPSEC job. Edit this job and change the defaults for internal security or to specify external security. For more information about this job, see How to: Use KOBSUPDT security exits with PARMGEN in the OMEGAMON shared documentation.

Update Program: When you have edited the control statements and pressed F3, you are presented with the JCL that starts the KOBSUPDT program, which updates the OMEGAMON for CICS (3270) security table.

Exit Routine

At initialization, OMEGAMON for CICS (3270) accesses the user security exit routine, which provides the interface to the external security package. The name of this routine must be specified by the user.

The following samples are provided:

KOCARACF and KOCBRACF for RACF
KOCAACF2 for CA-ACF2
KOCATOPS for CA-TOPSECRET.

When OMEGAMON for CICS (3270) is initialized, it determines whether an exit routine has been installed for an external security package.

If the exit routine exists, it gets control for those commands that have been marked for external security and determines authorization through the external security package.

If external security allows the command, OMEGAMON for CICS (3270) does not check internal security.

If external security is not used for the command, internal security takes effect. The OMEGAMON for CICS (3270) is shipped with certain authorized commands which require an internal security password for execution.

Note: In this section, the term authorized means allowed to access; it does not refer to APF authorization.

Using internal security for commands

All OMEGAMON for CICS (3270) commands (major, minor, immediate, and INFO-line) have a security level of 0, 1, 2, or 3. Level 3 provides the highest degree of protection. A setting of 0 means that any user can run the command.

To activate internal security, you must run the KCIJPSEC JCL job.

Important: Until you run the KCIJPSEC JCL job, OMEGAMON for CICS (3270) commands are protected only by the default command table security.

All authorized commands are shipped with a default security level of 3, and all others with a level of 0. You can change the security level of any OMEGAMON for CICS (3270) command to suit the needs of your installation. Updating the security table describes how to do this.

Each security level can have its own password. The level 3 password accesses all levels; the level 2 password accesses levels 2 and 1; the level 1 password accesses only the lowest level. Level 0 commands run without a password.

If you enter a command that requires higher authority than yours, OMEGAMON for CICS (3270) responds with this message:

OB0921 Security check failed (Internal)

To gain access to the authorized commands, use the /PWD command in this way:

Type /PWD on the INFO-line. When you press Enter, OMEGAMON for CICS (3270) responds with this password prompt:
```
_ <=== Please enter password
```
Type your password on the INFO-line. The password does not display as you type it.
Press Enter. If the PASSWORD ACCEPTED message is displayed, press Enter again. You will then have access to all authorized commands associated with that password, as well as the less command levels.
If you are using OMEGAMON for CICS (3270) with an external security package, you can prevent the use of the /PWD command. See Using the locking feature for more information.
Type the /PWD command on the INFO-line and press Enter. The password prompt is displayed.
Do not enter a password; just press Enter; you will see the following text:
```
_________________ Password level reset
```
Access to authorized commands is restricted until the password is entered again.

Using the locking feature

The locking feature is a form of external security designed to prevent users from changing their internal security level with the /PWD command. Their level of authority is set once and only at logon; it can be fixed to one of four levels (level 0, 1, 2, or 3).

Consider the following when using the locking feature:

Although the locking feature is implemented in the external security exit routine, it is designed to lock the user's internal security level. Therefore, it affects only those commands marked as EXTERNAL=NO.
You must define a user security level in CA-ACF2, RACF, or CA-TOP SECRET as an INITIALn resource, where n is a number from 0–3, and assign corresponding values to commands in the security update program (using the LEVEL keyword of the COMMAND control statement).
The locking feature only disables the /PWD command for supplying internal passwords. You can still use the /PWD command to logon again to a new external user ID.
Users assigned INITIAL authority (no value of 0 to 3 attached) are allowed to change their internal security level by using the /PWD command.
The locking feature starts checking INITIALn resources at the highest level. If you define INITIAL3 and INITIAL2, the user is locked to level 3.

RACF routine

To validate a user, the user exit routine checks on the RACF resource class that is defined by the ICHERCDE macro.

The resources that allow OMEGAMON for CICS (3270) startup include INITIAL, INITIAL0, INITIAL1, INITIAL2, and INITIAL3, as shown in the following example:

<Allows /PWD to work> 
   RDEFINE cccccccc INITIAL UACC(READ) 

   <Defines security level 0 as unaccessible>
   RDEFINE cccccccc INITIAL0 UACC(NONE) 

   <Defines security level 1 as unaccessible>
   RDEFINE cccccccc INITIAL1 UACC(NONE) 

   <Defines security level 2 as unaccessible>
   RDEFINE cccccccc INITIAL2 UACC(NONE) 

   <Defines security level 3 as unaccessible>
   RDEFINE cccccccc INITIAL3 UACC(NONE) 

   <Locks USER02 to level 2 power> 
   PERMIT INITIAL2 CLASS(classnme) ID(USER02) ACC(READ)

The variable classnme is the resource class name you defined in Modifying RACF rules.

CA-ACF2 routine

The user exit routine checks the CA-ACF2 resource class to validate a user.

The resources that allow OMEGAMON for CICS (3270) startup include INITIAL, INITIAL0, INITIAL1, INITIAL2, and INITIAL3. To allow users to change their authorization level with the /PWD command, use INITIAL. Here are sample definitions:

<Allows /PWD to work for USER01>  
   ACFNRULE KEY(INITIAL) TYPE(cls) ADD(UID(****************USER01) ALLO 

   <Locks USER02 to security level 0 commands>  
   ACFNRULE KEY(INITIAL0) TYPE(cls) ADD(UID(****************USER02) ALLO

   <Locks USER03 to security level 1 commands> 
   ACFNRULE KEY(INITIAL1) TYPE(cls) ADD(UID(****************USER03) ALLO 

   <Locks USER04 to security level 2 commands>
    ACFNRULE KEY(INITIAL2) TYPE(cls) ADD(UID(****************USER04) ALLO

   <Locks USER05 to security level 3 commands>
   ACFNRULE KEY(INITIAL3) TYPE(cls) ADD(UID(****************USER05) ALLO

The variable cls is the generalized resource class name you defined in Modifying CA-TOP SECRET rules.

The UID operand is installation-specific in format and content. For information about UID, contact your security administrator.

CA–TOP SECRET routine

Use the INITIAL n resource to define a internal security level if you are using CA–TOP SECRET.

Using external security

OMEGAMON for CICS (3270) supports external security for all modes of operation. For information on the implementation, see Using internal security for commands.

External security is supported for both logon and command use. When using external security, you can logon to OMEGAMON for CICS (3270) only if they are allowed to access the INITIAL resource name. A resource name of INITIAL0, INITIAL1, INITIAL2, or INITIAL3 might be used to allow logon to OMEGAMON for CICS and set the internal security level to 0, 1, 2, or 3, respectively.

When you issue a command, OMEGAMON for CICS (3270) performs an external security check if the following conditions are met:

The user exit module name is specified in the security table.
An external security exit routine is located and loaded.
External security is specified for the issued command in the security table (using the COMMAND control statement with the keyword setting EXTERNAL=YES ).
For VTAM®, ISPF, or TSO modes, the library that contains the KOBVTAM load module is APF-authorized.
If any commands are specified for external security checking and an exit routine is not found, OMEGAMON for CICS (3270) recognizes a possible security exposure and disables those commands with an internal security level of 0 for the session. Those commands with a level of 1, 2, or 3 are allowed to run after you enter the internal password, as described in Using internal security for commands.

Logging on using external security

This section explains special considerations for logging on to OMEGAMON for CICS (3270)using external security.

VTAM, TSO, or ISPF mode logon panels

When you logon through VTAM, OMEGAMON for CICS (3270) presents a logon panel for the OMEGAMON® VTAM application program, KOBVTAM. The VTAM logon panel also is displayed for ISPF and TSO modes, because OMEGAMON for CICS (3270) uses the VTAM application program for these modes as well. The copyright panel you normally see at logon time has additional fields for USERID, PASSWORD, GROUP, and NEW PASSWORD.

These are the advantages of using the KOBVTAM logon panel:

The exit routine can cause OMEGAMON for CICS (3270) to stop an unauthorized logon.
The exit routine makes all security checks based on the user's logon ID and not on the OMEGAMON for CICS (3270) address space's authority.

If you are in an active VTAM session and you want to alter the external security level of authorization, you can use the relogon feature discussed in Accessing security from an active session.

Dedicated mode logon

Security in dedicated mode differs from the other modes because, at startup time, there is no user ID or password associated with the session. Therefore, the only security available by default is internal security. You must enter the /PWD command, using the re logon feature discussed in the following section in order to access external security.

Accessing security from an active session

The re logon feature is a function of the /PWD command that enables you to enter your user ID and password for the external security package from an active OMEGAMON for CICS (3270) session. It is the facility used in dedicated mode to log on to external security. In VTAM mode, it enables you to alter the security level without having to bring down a current VTAM session.

Type in the /PWD INFO-line command and your user ID as in this example:

/PWD user01_____OCINIT00;
DED CICSPROD; V300./C SYSA; 05/19/06; 1

Press Enter and type in your external security password at the prompt.

Note these points regarding the re logon feature:

Do not mark the /PWD command as EXTERNAL=YES in the security table because, in dedicated mode, you must use /PWD to log on to external security.
You can determine in your user exit what the default action will be when the user ID or logon password supplied is not valid. For example, you can specify the disabling of all OMEGAMON for CICS (3270) commands marked as EXTERNAL=YES, or you can specify that the session reverts to the previous user ID. The available options are explained in the sample exit routines.
If you use the re logon feature and your password has expired, you cannot enter a new one using the /PWD command.

Implementing external security

To implement external security, follow these steps:

Modify the rules in the external security package to interface with OMEGAMON for CICS (3270). See Modifying RACF rules, Modifying CA-ACF2 rules or Modifying CA-TOP SECRET rules.
Customize the sample exit routine provided in &rhilev.&rte.RKANSAMU according to the procedure in Using OMEGAMON for CICS (3270) security exit routines. See Optional external security features for a description of the options you can use.
Modify and update the security table to specify the commands to be verified by RACF, CA-ACF2, or CA-TOP SECRET and the name of the module that contains the exit routine. (No default setting is supplied for the module name.) Follow the steps in Updating the security table.

Modifying RACF rules

This section explains the necessary steps for modifying the RACF rules to interface with OMEGAMON for CICS (3270).

To modify the RACF rules to interface with OMEGAMON for CICS (3270), follow these steps:

Update the resource class description table to define a class name (for example, OC;TIVOLI) using the ICHERCDE macro call. (Use the same name when you define the resource class in the security exit routine.) Code the ICHERCDE macro in the following manner:
```
ICHERCDE CLASS=classnme,
         ID=nnn,
         MAXLNTH=24,
         FIRST=ALPHANUM, 
         OTHER=ANY,  
         POSIT=nnn, 
         DFTUACC=NONE
```
Values for classnme and nnn are determined by your installation. Additional operands for this macro might also be required at your installation.
Activate the newly defined resource class.
Define a resource profile for logging on to OMEGAMON for CICS (3270). Use the TSO RDEFINE command with a resource of INITIAL. Here is an example of a definition that allows all users to sign onto OMEGAMON for CICS (3270) and use the /PWD command for internal security (that is, it allows access only to those commands marked EXTERNAL=NO):
```
RDEFINE classnme INITIAL UACC(READ)
```
This definition is the minimum required for logon.
Define resource profiles for the commands you want to protect using external security (EXTERNAL=YES commands). If you want to restrict the use of the /PWD command, see Using the locking feature.
1. Use the TSO RDEFINE command and specify the OMEGAMON for CICS (3270) command as the resource. Be certain to specify that only specific users can run the command by setting UACC(NONE).
2. Use the PERMIT command to define those users who can access the resource (run the command). Give them READ access.
  The following example shows how to authorize a user to run the PEEK command with RACF:
```
             RDEFINE classnme PEEK UACC(NONE)
             PERMIT PEEK CLASS(classnme) ID(USER01) ACCESS(READ)
```
  Note: If the command you want to secure begins with a slash (/) or period (.), the RACF rule you define must start with a dollar sign ($) instead of the slash (/), or an at sign (@) instead of the period (.). For example, the command /LOGOUT requires a rule for $LOGOUT.
The class name in KOCARACF or KOCBRACF (default is OMCANDLE) is defined on this instruction:
```
MVC   U#CHCLSD,=CL8'OMCANDLE'    RESOURCE CLASS NAME 
```
If you change it in the KOCARACF or KOCBRACF module, be sure to also use that name for classnme.
Include macro libraries in the assembly of the security exit routine. Use SYS1.MACLIB and SYS1.AMODGEN as the macro libraries for RACF. In addition, you must include the thilev.TKANMAC macro library.

TSO/ISPF APF authorization requirements

APF authorization is required for TSO and ISPF modes to initialize with RACF. If this is not done, then a S282-10 abend code occurs.

Modifying CA-ACF2 rules

To modify the CA-ACF2 rules to interface with OMEGAMON for CICS (3270), follow these steps:

If you are running OMEGAMON for CICS (3270) in dedicated or VTAM mode, define the name of the OMEGAMON for CICS (3270) started task to CA-ACF2.
The started task name you use to run OMEGAMON for CICS (3270) in VTAM mode can have the MUSASSattribute assigned. This allows CA-ACF2 to verify the individual user authorization rather than using the OMEGAMON for CICS (3270) address space ID. If STC(NO) is specified, you must run the OMEGAMON for CICS (3270) in batch with a job name that has the MUSASS attribute.
After you install the exit, you must set up a resource class for CA-ACF2 to enable OMEGAMON for CICS (3270) to make the security checks. Define a generalized resource class name, for example OMS. This name will be three characters long for generalized resources, but will be prefixed with the letter R within the security exit. (Use the same name when you define the resource class in the security exit routine.)
The class name in KOCAACF2 (default is ROMS) is defined on this instruction:
```
A#ACFCLS DC    CL4'ROMS'           CHANGE CLASS IF NEEDED 
```
Define a CA-ACF2 rule for the INITIAL resource to allow VTAM users to log on to OMEGAMON for CICS (3270), as in the following example:
```
ACFNRULE KEY(INITIAL) TYPE(OMS) ADD(UID(****************uid)ALLOW)
```
The OMS must match the resource class name that you defined. The uid is a user ID or user ID mask. If you want to restrict the use of the /PWD command, see Using the locking feature.
Use the CA-ACF2 rule compiler to define resource rules for the command you want to protect. Specify the command with the KEY operand.
The following example shows how to authorize a user to run the PEEK command with CA-ACF2. See your security administrator for information on the format of the string.

Note: If the command you want to secure begins with a slash (/) or period (.), the CA-ACF2 rule you define must start with a dollar sign ($) instead of the slash (/), or an "at" sign (@) instead of the period (.). For example, the command /LOGOUT requires a rule for $LOGOUT.
Include the CA-ACF2 macro library in the assembly of the routine. In addition, you must include the thilev.TKANMAC macro library.

Modifying CA-TOP SECRET rules

The following section explains the procedure for modifying the CA-TOP SECRET rules to interface with OMEGAMON for CICS (3270).

To modify CA-TOP SECRET rules use these steps:

Define the OMEGAMON for CICS (3270) address space as a started task in the CA-TOP SECRET STC record, along with the related main facility ID:
```
 TSS ADD(STC) PROC(cccccccc) ACID(MAIN FACILITY ACID)
```
Where cccccccc is the started task name you specified for OMEGAMON for CICS (3270) in PARMGEN.

Define the OMEGAMON for CICS (3270) a facility to CA-TOP SECRET in the facility matrix table:

FACILITY(USER3=NAME=cccccccc) 
FACILITY(cccccccc=MODE=FAIL,ACTIVE.SHRPRF) 
FACILITY(cccccccc=PGM=KOB,NOASUBM,NOABEND,NOXDEF) 
FACILITY(cccccccc=ID=3,MULTIUSER,RES,WARNPW,SIGN(M)) 
FACILITY(cccccccc=NOINSTDATA,NORNDPW,AUTHINIT,NOPROMPT,NOAUDIT) 
FACILITY(cccccccc=NOTSOC,NOMRO,LOG(INIT,SMF,MSG,SEC9))

Where cccccccc is the started task name you specified for OMEGAMON for CICS (3270) in PARMGEN.

Define the OMEGAMON for CICS (3270) facility:
```
TSS ADD(ACID) FACILITY(cccccccc)
```
Where cccccccc is the started task name you specified for OMEGAMON for CICS (3270) in PARMGEN.
Define a Resource Descriptor Table entry:
```
TSS ADD(RDT) RESCLASS(OCCANDLE) RESCODE(XX)
```
The RESCODE is a hexadecimal value of 01–3F. The class name in KOCATOPS (default is OCCANDLE) is defined on this instruction:
```
 MVC   U#CHCLSD,=CL8'OCCANDLE' ALTERNATE RES/CLASS NAME 
```
If you change it in the KOCATOPS module, be sure to also use that name for RESCLASS.

To permit access to the OMEGAMON for CICS (3270) command level, enter the following command:

TSS PERMIT(userid) OCCANDLE (INITIAL0) 
TSS PERMIT(userid) OCCANDLE (INITIAL1) 
TSS PERMIT(userid) OCCANDLE (INITIAL2) 
TSS PERMIT(userid) OCCANDLE (INITIAL3) 
TSS PERMIT(userid) OCCANDLE (‘INITIAL ‘)

Enter the following to enable CA-TOP SECRET to validate commands:
```
TSS PERMIT(userid) OCCANDLE(XXXX)
```
Where xxxx is an OMEGAMON for CICS (3270) command that has been defined with EXTERNAL=YES in the OMEGAMON for CICS (3270) command table.

If you use CA-TOP SECRET to define an initial access to OMEGAMON for CICS (3270), you can specify EXTERNAL=NO in the control statements.
You must also specify the CA-TOP SECRET KOCATOPS interface module to enable the CA-TOP SECRET interface. Use the TSS PERMIT command to define those users who can access the resource by running the OMEGAMON command.
The following example shows how to authorize a user to run the PEEK command with CA-TOP SECRET:
```
TSS PERMIT(userid) OCCANDLE(PEEK)
```

Note: If the command you want to secure begins with a slash (/) or period (.), the CA-TOP SECRET rule you define must start with a dollar sign ($) instead of the slash (/), or an at sign (@) instead of the period (.). For example, the command /LOGOUT requires a rule for $LOGOUT.

Using OMEGAMON for CICS (3270) security exit routines

The exit routine provides an interface between OMEGAMON for CICS (3270) and the security product. You can specify any unique name for your routine, but that name must also be specified in the control statements that update the security table. The exit routine can be shared between systems.

The KOCARACF, KOCBRACF, KOCAACF2, and KOCATOPS are members of the &rhilev.&rte.RKANSAMU data set that contain models of RACF, CA-ACF2, and CA-TOP SECRET routines. Many installations use these members without modification, but because security procedures are installation-dependent, they have been documented with comments to enable you to modify them. They are supplied as examples only.

Verify that the resource class you define in the exit routine has the same name as the resource class you defined when modifying RACF, CA-ACF2, or CA-TOP SECRET rules. The &rhilev.&rte.RKANSAMU data set contains members, KOCJACF2, KOCJRACF, and KOCJTOPS, which supply sample JCL to help you assemble and link-edit your routine.

You can use the same exit routine to define security for multiple OMEGAMON for CICS (3270) images. Use the same name on the MODULE= statement for each OMEGAMON for CICS (3270). You can use the value of the B#DDPRFX field in the $BIA data area as part of a resource name to be used for the OMEGAMON for CICS (3270) currently in use.

Use the KOCBRACF sample to create resource names that include the CICS® Jobname.

If you have a security system other than RACF, CA-ACF2, or CA-TOP SECRET, you can still implement a security interface using these models. Use the sample RACF, CA-ACF2, or CA-TOP SECRET exits as guides to see what information is passed to the exit routine and what information is returned to OMEGAMON for CICS (3270).

Using OMEGAMON for CICS (3270) calling conventions

OMEGAMON for CICS (3270) uses the $UCHECK control block to pass information to the exit routine. The exit routine also uses $UCHECK to pass information back to OMEGAMON for CICS (3270). The $UCHECK control block is mapped by the $UCHECK macro. The macro is defined in the KOBGMAC member of thilev.TKANMAC library.

The U#CHPIA field in the $UCHECK control block points to the address of a 16-byte control block. The KOCPIA macro, defined in the thilev.TKANMAC library, maps this control block and gives you the CICS job name the user requested at logon. OMEGAMON for CICS (3270) maintains the control block for the entire life of the session and gives the installation a 512-byte work area for its own use.

Note: The $UCHECK work area is limited to 512 bytes. If your installation requires a larger work area, GETMAIN the additional storage required and place the pointer to this GETMAIN area in $UCHECK. An attempt to enlarge this work area beyond its 512-byte limit in any other way causes an overlay of essential OMEGAMON for CICS (3270) control blocks, and results are unpredictable. If you modify the RACF RACROUTE macro, you must GETMAIN at least 512 bytes for use as the WORKA work area.

The user exit module is called by OMEGAMON for CICS (3270) using the following conventions:

Table 1. The naming conventions for the user exit module called by OMEGAMON for CICS (3270)
Name	Description
Register 1	Address of parameter list.
Register 13	Address of a standard save area.
Register 14	Return address.
Register 15	Entry point address (in).
Register 15	Return code (out).

The Parameter list contains Word 1 – Address of control block.

Reviewing OMEGAMON for CICS (3270) calling flow

The following procedure describes the flow for calls from OMEGAMON for CICS (3270) to your user security exit routine at initialization, during command verification, and at termination:

At initialization, when OMEGAMON for CICS (3270) passes control to your user exit routine, the initialization call is indicated by an I in the U#CHTYP field. This indicates thatOMEGAMON for CICS (3270) requires a logon validation.
1. If the user ID field length is non zero, the user ID and password information are available.
2. If additional information or some form of retry is required, the routine can request a reshow of the screen, and reset any field lengths to indicate that no data is present (user ID, password, group, or new password).
  To perform a reshow in VTAM mode:
- Set a message into the U#CHMSG field (120 bytes maximum length)
- Set the U@CHRSHO bit in U#CHRESP
- Return to the caller.
  The message appears under the panel. Appropriate fields are filled in (original user ID and password), unless overridden (length = 0).
  1. When validation is complete, a return code of 0 from the user exit indicates that the user can be allowed to log on. Any other return code will cause the session to be aborted.
  2. Upon successful logon acceptance, the validation routine might perform resource validation and optionally assign a command security level (0, 1, 2, or 3) to the user. The default setting is 0. Place the appropriate number into the U#CHAUT4 field. To force the user to use only this level, also set the U@CH1LOK bit in U#CHAUT1.
During command verification, OMEGAMON for CICS places a C in the U#CHTYP field. At this point, the user authorization is verified. The decision to allow or not allow a command on the first encounter cannot be changed on subsequent attempts by the same user unless security is reset with the /PWD command. However, on each attempt, the user exit is notified, an audit record might be written, and a customized error message might be issued.
These might be the return codes:

RC = 0

Indicates that the command is allowed (RACF and CA-ACF2).

RC = 4

Indicates that the command is unknown to RACF (RACF only). OMEGAMON for CICS (3270) allows the command to run. See Modifying RACF rules for instructions to define a command to RACF.

RC = 8

Indicates that the command is known to the security package and access is denied (RACF and CA-ACF2).
At re-logon, OMEGAMON for CICS (3270) places an R in the U#CHTYP field to indicate a logon validation. The processing is the same as at initialization time, except that users cannot enter a new password or group because OMEGAMON for CICS (3270) does not display a logon panel.
At termination, OMEGAMON for CICS (3270) passes a T to the user's exit routine. You can then do any termination cleanup required, such as freeing user control blocks and FREEMAINing any GETMAINed areas.