Planning for both static and dynamic terminals

Static and dynamic terminals can coexist in the same IMS. However, if users move between static and dynamic terminals, there are situations you need to plan for.

If users move between static and dynamic terminals, plan for the following situations:
  • IMS maintains separate queues for static and dynamic terminals. A static terminal has one or more LTERMs associated with it, as controlled by the IMS system definition (or the /ASSIGN command to move an LTERM to a different terminal). Some users become accustomed to having their output queue follow them from ETO terminal to ETO terminal. Static terminals do not provide this feature. Users need to be able to differentiate between static and dynamic terminals, or confusion can result.
  • Given one static terminal and one dynamic terminal, separate IMS conversations can exist at the same time. The dynamic terminal conversation belongs with the user structure and follows the user from terminal to terminal. 1 The static conversation belongs to the static terminal and can only be released to a static terminal. This situation is user friendly and predictable only when the user is certain of the terminal type (static or dynamic).
Normally, the terminal operator is able to determine whether a terminal is static or dynamic by checking the security information that is provided at the end of the DFS3650 (SESSION STATUS) message:
OUTPUT SECURITY AVAILABLE
Indicates that the terminal is dynamic, and output is associated with the signon ID.
NO OUTPUT SECURITY AVAILABLE
Indicates that the terminal is either statically defined or that ETO created it by using one of two methods:
  • Using a node user descriptor
  • Using the Signon exit routine to assign the node name to the user structure
In either case, the output is associated with the terminal, rather than with the user.
Exception: Message DFS3650 might be suppressed if you use the NOTERM option.
Note: You can secure transaction outputs for statically defined VTAM terminals by specifying the STATICOUTSEC parameter in the DFSDCxxx member of the IMS PROCLIB data set. In this case, outputs are associated with sign-on IDs. If the current user ID does not match the sign-on user ID, the output is discarded.
Recommendation: To ease migration and limit possible confusion, convert to dynamic ETO terminals by using logical groupings within your organization, such as departments or floors.
1 This assumes that the Signon exit routine (DFSSGNX0) sets the same user name each time, as is usually the case.