IMS Version 8 Implementation Guide A Technical Overview of the New Features

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 x’01’ 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