The Extended Terminal Option (ETO)

The IMS Extended Terminal Option (ETO) allows you to dynamically add VTAM terminals and users to your IMS: they do not need to be predefined during system definition. ETO is a separately priced feature of the IMS Transaction Manager (TM) and provides additional features such as output security, automatic logoff, and automatic signoff.

By using ETO, you can achieve each of the following goals:

• Improved system availability by reducing the scheduled down time that is associated with adding or deleting VTAM terminals.

• Faster system availability to users, because they can establish an IMS session from any VTAM terminal in the network.

• Improved IMS security by relating output messages to users, rather than to terminals.

• Reduced number of macros required to define the terminal network. This reduces system definition time and storage requirements.

• Reduced checkpoint and restart time. For ETO terminals and user structures, resources are not allocated until they are actually required; similarly, when they are no longer required, they are deleted.

• Reduced number of skilled system programmer resources that are required for maintaining static terminal definitions.

Related Reading: For more information about ETO, see IMS Version 9: Administration Guide: Transaction Manager.

ETO Terminology

The following sections describe the terms that have ETO-specific meanings. These meanings are important for understanding ETO.

Terminals

A terminal is a physical VTAM logical unit (LU) that establishes a session with IMS. A physical terminal is represented using a control block.

When a terminal is not built by ETO but is defined at system definition, it is called a static terminal. A static terminal can be a VTAM node. When messages are sent to a static terminal they are queued to a logical terminal (LTERM) message queue, where they await retrieval by the recipient.

When a terminal is not defined at system definition and ETO builds a terminal, that terminal is called a dynamic terminal, or an ETO terminal. For dynamic terminals, the logical terminal (LTERM) is known as a dynamic user message queue, and the LTERM associates the messages with the user, rather than with the physical terminal. Associating messages with the users provides more security for these users, because they can access their messages only when they sign on using their unique user ID. In addition, all users in the network can access their messages from any physical terminal, instead of being restricted to using a particular physical terminal.

Dynamic User

A dynamic user is a user who signs on to a dynamic terminal and who has a unique identification (user ID) that IMS uses for delivering messages. The user is usually associated with a person but can also be associated with another entity, such as a printer.

Terminal Structure

A terminal structure is a control block that represents a specific terminal that is known to IMS. A terminal structure is created when the individual terminal logs on to IMS and is deleted when the terminal logs off with no remaining associated activity.

User Structure

A user structure is a set of control blocks, including a user block and one or more LTERM blocks. The message queues are associated with the dynamic user, as opposed to the physical terminal, and they are queued to the user ID. Usually, a user structure represents a person who uses IMS.

The dynamic user structure connects to the physical terminal only when the user signs on. This provides a secure environment, because different users accessing the same terminal cannot receive each other's messages.

IMS creates a user structure when either of the following events takes place:

• A dynamic user signs on to IMS.

• Output messages that are destined for a dynamic user are sent to the user, but the user has not signed on to IMS.

The user structure name is usually the same as the user ID. A user structure can also represent a logical destination, such as a printer. In this case, the user structure name can be the same as or different from the LTERM name that your installation uses in its application programs and its exit routines. For example, you can assign the same name to a user structure for a printer that you assign to its LTERM destination node name. However, output is then queued according to the terminal, and not to the user.

Figure 19-3 illustrates:

Figure 19-3. Static Resources: Node and Static Terminals

• A physical terminal (Node LU1)

• Two logical terminals (LTERM LT1A and LTERM LT1B) that are defined as being associated with Node LU1

• The message queues that are associated with logical terminals LTERM LT1A and LTERM LT1B

• The traditional, static system definition for LU1, LTERM LT1A, and LTERM LT1B

Figure 19-4 illustrates:

Figure 19-4. ETO Dynamic Resources: User and Dynamic Terminals

• A physical terminal (Node LU1)

• A dynamic user (US1)

• Two dynamic logical terminals (LTERM US1 and LTERM US2) that are dynamically associated with user US1

• The dynamically built user message queues that are associated with logical terminals LTERM US1 and LTERM US2

• The dynamic definition (descriptor) that IMS builds for LU1, US1, LTERM US1, and LTERM US2

Descriptors

A descriptor provides information to IMS when IMS builds a dynamic resource for a logon or a signon. IMS stores the descriptors in two IMS.PROCLIB members, DFSDSCMx and DFSDSCTy. For more information about these PROCLIB members, see IMS Version 9: Installation Volume 2: System Definition and Tailoring.

IMS uses four types of descriptors:

• Logon descriptors

• User descriptors

• MSC descriptors

• MFS device descriptors

Logon Descriptors

A logon descriptor is a skeleton that IMS uses to build an ETO dynamic terminal. It provides information regarding a terminal's physical characteristics. IMS uses logon descriptors in conjunction with exit routines to create terminal structures.

IMS uses three types of logon descriptors:

Generic

A generic logon descriptor provides characteristics for all terminals of a particular type. For example, all SCS printers might share a single generic descriptor. Similarly, all 3270 terminals might share a generic logon descriptor.

Group

A group logon descriptor provides characteristics for a collection of terminals, each of which has compatible hardware characteristics and is defined to IMS in the same manner. The characteristics of these terminals are usually identical, but they can differ. IMS uses the group logon descriptor to derive their characteristics.

Specific

A specific logon descriptor provides characteristics for a single terminal, and these characteristics apply only to that terminal. The specific descriptor name matches the name of the terminal that it describes.

Recommendation:

Although you might need to use specific logon descriptors during the actual migration to ETO, use generic logon descriptors or group logon descriptors after you have migrated to ETO; these types of descriptors ease network administration.

User Descriptors

A user descriptor is a skeleton from which IMS builds a user structure. A user descriptor can provide user options and queue names.

MSC Descriptors

IMS uses an MSC descriptor to create a remote LTERM, which is an LTERM that does not exist on the local IMS. The physical terminal definition (either static or dynamic) for the remote LTERM is in the remote IMS.

Each MSC descriptor for a remote LTERM is loaded during IMS initialization and tells IMS which MSC link to use for output destined for that remote LTERM.

MFS Device Descriptors

An MFS device descriptor allows you to add new device characteristics for MFS formatting without requiring an IMS system definition. The MFS Device Characteristics Table utility (DFSUTB00) uses MFS device descriptors to update default formats in the MFS library.

IMS also uses MFS device descriptors to update the MFS device characteristics table. IMS loads this table only during initialization; therefore, updates are not effective until the next IMS initialization.

How Structures are Created and Used

Structures are created in the following situations:

• Logon

• Signon

• Output is queued to your LTERM

• /ASSIGN command is used to assign an LTERM to a non-existent user

• /ASSIGN command is used to assign a non-existent LTERM to a user

• /CHANGE USER user AUTOLOGON command is directed to a non-existent user

In all cases, IMS searches for an existing terminal or user structure before creating a new one.

IMS creates and deletes user structures in the following sequence:

1. When you establish a session between IMS and an undefined terminal, IMS selects a logon descriptor.

2. Using the information in the logon descriptor, the customization defaults, and VTAM information, IMS builds an IMS terminal control block (called a VTAM terminal control block or VTCB) that describes the new terminal.

3. When you sign on, if a user structure does not exist, IMS builds one, using information from a user descriptor that it selects, and then connects this user structure to the terminal structure.

4. IMS deletes terminal structures or user structures when they are no longer needed to maintain sessions. User structures are typically deleted when you sign off, if no special status needs to be maintained and if no messages remain queued. IMS deletes terminal structures when no terminal status exists (such as trace mode), no user is signed on, and the terminal is idle.

   If you are using the Resource Manager and a resource structure, IMS normally maintains status in the resource structure instead of the local control blocks. Therefore, IMS deletes the resource structures.

This sequence applies only to terminal logon and logoff and to user signon and signoff. When asynchronous output is queued to a user, IMS creates the user structure, as needed.

Related Reading: For more information about the Resource Manager, see "Resource Manager" on page 498 or IMS Version 9: Common Service Layer Guide and Reference. For more information about how IMS manages terminal and user structures, see IMS Version 9: Administration Guide: Transaction Manager.

Descriptors and Exit Routines

Using descriptors and exit routines, you can assign characteristics to dynamic terminals and assign user structures to be associated with those dynamic terminals.

A descriptor provides the basic information for the dynamic terminal. An exit routine completes or changes this information. Two methods of using descriptors and exit routines are:

• You can use many descriptors and code little or no processing logic in exit routines.

• You can use few descriptors and code exit routines to perform much of the processing.

How Descriptors Are Created and Used

All descriptors are created during IMS initialization, prior to IMS startup. You must specify that you want ETO support and ensure that the ETO initialization exit routine (DFSINTX0) does not disable ETO support.

During IMS initialization, IMS reads and validates all ETO descriptors. IMS initialization then continues, and the descriptors remain in storage for the duration of IMS execution. Any changes you make to descriptors become effective after the next initialization of IMS.

IMS uses descriptors to create both terminal and user structures. IMS rebuilds structures during an IMS restart, if appropriate. For example, if messages are queued for a structure and IMS shuts down, the structures are rebuilt when IMS restarts. IMS rebuilds these structures to be the same as they were before the IMS restart. IMS does not use the descriptors or exit routines to rebuild these structures. Therefore, any changes you make to descriptors are only reflected in new structures that are built after IMS restart, and the changes are not reflected in structures that are rebuilt during IMS restart.

Example USERA signs on using descriptor DESCA, which specifies an auto signoff time of 20 minutes (ASOT=20). USERA starts an IMS conversation, and then IMS abnormally terminates. The system programmer changes DESCA to ASOT=10. After the IMS restart, USERB signs on using DESCA. USERA's structure was rebuilt during the IMS restart. USERA still has a value of 20 minutes for the auto signoff time (ASOT=20), and USERB has a value of 10 minutes for the auto signoff time (ASOT=10).

Summary of ETO Implementation

Figure 19-5 on page 345 shows an overall view of an ETO implementation. The steps that follow correspond to the highlighted numbers in Figure 19-5.

Figure 19-5. Summary of ETO Implementation

1.	The system-defined descriptors that are built during system definition are stored in IMS.PROCLIB as member DFSDSCMx.
2.	Your user-defined descriptors that are written to override the system definition defaults are stored in IMS.PROCLIB as member DFSDSCTy. MFS descriptors that are processed by the MFS Device Characteristics Table utility (DFSUTB00) are stored in the device characteristics table.
3.	Logon, user, and MSC descriptors are loaded at IMS initialization using the input from IMS.PROCLIB.
4.	The Logon and Logoff exit routines are called during logon and logoff.
5.	The Signon and Signoff exit routines are called during signon and signoff.
6.	Output is delivered to the destination specified in the Output Creation exit routine, unless the user is created during signon.
7.	If IMS is unable to determine where output should be delivered, the messages are added to the dead-letter queue. Messages might not be delivered because: The user name is not a valid user ID. The user signon is rejected. A physical-to-logical relationship does not exist between the device and the LTERM.
8.	RACF (or an equivalent product) manages security in the ETO environment.