Chapter 14. Sysplex terminal management 183
򐂰
Transaction codes:
Static transactions defined in the IMS system generation
CPI-C transactions defined in the TP_PROFILE
Dynamic transactions defined by the Output Creation Exit (DFSINSX0)
򐂰 Logical terminal names (LTERMs):
Static LTERMs defined in the IMSGEN
Dynamic LTERMs created in an ETO environment
򐂰 Logical link names (MSNAMEs):
Defined by the MSNAME macro in the IMS system generation
򐂰 APPC descriptor names:
Defined in IMS.PROCLIB member DFS62DTx. Although messages are not queued by
APPC descriptor name, this name is used to determine, from the descriptor definition,
what the message destination is.
Summary of IMS resources managed by STM
The above resources are managed by the sysplex terminal management function of IMS
using the resource structure as a repository for resource-related information. Resources and
the resource structure on page 195 describes these resources in a little more detail,
including when they are created and deleted and how they are used.
14.4 STM terms and concepts
Sysplex terminal management introduces some new terms and concepts that need to be
understood before discussing the functionality.
14.4.1 Resource type consistency
Resource type consistency is based on the concept of an IMS message destination as
described in , Message destinations on page 182. For purposes of resource type
consistency, a message destination is any named resource which may also be the name of a
queue of messages for that resource. For example, in a shared queues environment,
transactions are queued off the (serial) Transaction Ready Queue in the shared queue
structure. Messages destined for logical terminals are queued off the LTERM Ready Queue.
Output messages destined for MSC remote destinations are queued off the Remote Ready
Queue. When a message arrives in IMS, or an application program issues a CHNG or ISRT
call to a TP-PCB, IMS must analyze the name in the message (call FINDDEST) to determine
how to queue the message.
Message destinations have a name type of x01 as shown in Figure 14-6 and include:
򐂰 Transaction codes
򐂰 LTERM names
򐂰 MSNAMEs
򐂰 APPC descriptor names
Other resource types are not checked for consistency since they are not used for message
queuing. For example, it is perfectly alright to have the same name for a NODE, a USER, an
LTERM, and a USERID.
In an IMSplex, each IMS system has its own system definition, although certainly a single
system definition can be shared by all IMSs. When this is done, we say these IMSs are
184 IMS Version 8 Implementation Guide
cloned, and the message destinations are obviously consistent. However, since it is not a
requirement, and since each IMS might have its own system definition, it is important that,
when resources are defined to these separate IMSs, resources of the same type are defined
consistently. For example, it would be problematical if IMS1 defined a resource named
PRSNL as a transaction, and IMS2 defined a resource named PRSNL as an LTERM. Since
both transaction codes and LTERM names are message destinations, IMS1 would queue a
message with destination PRSNL on the Transaction Ready Queue, and IMS2 would queue it
on the LTERM Ready Queue. Very confusing.
In a list structure (such as the resource structure) which has been allocated with user
managed list entry IDs (LEIDs), no two entries can have the same LEID - they must be unique
within the structure. When IMS wants the RM to create an entry on the structure, it provides a
LEID consisting of the
name type + resource name
. This may also be referred to as the
resource ID
. In the above example, IMS1 would create a transaction entry with an LEID of
01PRSNL. If IMS2 later tried to create an entry for an LTERM named PRSNL, it would also
provide a LEID of 01PRSNL. Since this LEID already exists in the structure, and since it must
be unique, IMS2 would not be allowed to create a LTERM named PRSNL, and the logon
would fail.
Figure 14-3 shows an example of the same resource name being defined by IMS1 as a
transaction and IMS2 as an LTERM.
Figure 14-3 Resource Type Consistency
There is a difference here between statically defined terminals and dynamic ETO terminals.
With a static terminal, the static NODE users (SNUs) and LTERMs are created and activated
at logon time. If any one of the LTERMs defined for a static NODE is not consistent, then the
logon is rejected. Since the SNU name is the same as the NODE name, if the NODE is valid,
so is the SNU.
IMS1 IMS2
TERMINAL NAME=PERS2
NAME PRSNL
01PRSNL Data
LOGON
TRANQ
LTERMQ
TRAN
LTERM
CF
01PRSNL
01PRSNL
APPLCTN ...
TRANSACT PRSNL

Get IMS Version 8 Implementation Guide A Technical Overview of the New Features now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.