gtps4m1jSystem Generation

Message Router Support

As a result of users coding the SIP MSGRT and MSGRTA macros, which define the message router support, program segments are produced by SIP. These program segments are collectively referred to as the RCAT Initialization Table (RCIT).

The RCIT defines:

The non-propagable bit in the RCIT is set to 1 by the SKRCIT internal system generation macro.

The initialization of the previously mentioned router records, except for SSUT which is created at restart time for MDBF users by the IPL program, is performed at generation time by SIP from information provided by the user.

If all the applications defined via SIP reside in a single non-loosely coupled TPF processor then these macros alone will generate the proper level of message router support. If, however, the generated TPF system requires loosely coupled support, or any of the applications reside in a different processor complex, then the ACF support is also required for SNA support, and OSTG must be run to define the required Functional Management Message Router (FMMR) entry and path for interprocessor communications. This includes loosely coupled systems that have no other need for SNA support, since the FMMR entry in the SNA Resource Vector Table (RVT) is used to control the interprocessor communications between the processors within the loosely coupled complex. Refer to Message Router Support in an ACF Network for additional information.

Message Router Application Attributes

The MSGRTA macro, in addition to defining an application and its residency in an host, also allows the user to define unique attributes for the application itself. A major difference between applications is the line protocol used. SNA, or new applications, can use the SNA resource identifier (RID) to identify a SNA logical unit (LU), or can use a LNIATA to identify terminals. Non-SNA, or old applications, use a terminal address such as a LNIATA to identify terminals. The message router does provide the ability for 3270/SDLC terminals to enter old applications via a pseudo-LNIATA (PLIT). All of the attribute keywords are not mandatory with defaults provided. The defaults are for SNA application programs.

The keywords/attributes are:

  1. RES=YES defines reservation type of application such as PARS (see UI/Reservation Package (PARS)).
  2. SIGN=YES specifies that there is a user written/controlled sign-on procedure (see Log Processor). When a terminal operator logs into this application, a response will be sent requiring sign-on.
  3. SIMFM=YES specifies that 3270 terminals may be used with an application that only has been coded to accept input from ALC terminals. The input is reformatted by the system from 3270 to 4505 format before being presented to the application. The system also reformats output messages from this application to 3270 format.
  4. ASNA and TERMRCD specify the type of terminal record and whether or not it is to be actually passed to the application program.
  5. MRECV specifies for SNA applications whether or not SNA system message recovery is to be performed for the application. The application is associated with message recovery support or specified on SNAKEY in CTK2.
  6. RCPL specifies the size of the routing control parameter list. SNA logical units may use the extended RCPL.
  7. ALTBUF=YES specifies the use of the alternate buffer size by the specified application for 3270/SDLC logical units.

Message Router Support in an ACF Network

In an ACF network, all messages destined for an application resident in another processor will be forwarded to that processor via the FMMR. The FMMR is defined via the offline OSTG program (see SNA Table Generation).

In a loosely coupled complex, messages flow on the IPC path.

NEF users of the message router are treated and generated like ALC users. The terminals supported by NEF (ALC terminals) will use an LNIATA when they log into applications.

Message Router Support for the High Performance Option Feature

Loosely coupled users of the HPO feature must generate the message router, taking into consideration that they are using ACF support. All local applications are defined as existing in all processors in the LC complex. The system applications (for example, SMPx) exist uniquely in each processor of the complex and are identified by their appended TPF processor ID. To implement this, the APROC keyword of the MSGRTA macro is coded with the * character. The actual TPF processor ID comes from the IDs specified on the SYSID keyword of the CONFIG macro.

MDBF users must indicate the subsystem and subsystem user with which the application being defined by the MSGRTA macro is to be associated. This is done via the USER keyword parameter of the MSGRTA macro, and it must match the name associated with one of the coded SSDEF macros.

In addition, at least 1 application in each subsystem must be defined as an SMP-like application via the SMP= keyword (see Communications Source Message Router and System Message Processor). This is the application that will receive the commands for that subsystem. For the BSS, the message router automatically provides the SMPx application.

Message Router Implementation Guidelines

The following items should be considered: