Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
ACC Programmer's Reference Guide > Chapter 2 ZCOM Message Handling

Multiplexing

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

The multiplexing feature of ZCOM allows more than one logical terminal to be mapped to a single physical terminal. This mechanism is implemented in ZCOM by allowing messages to and from a terminal ZLU to be intercepted by a program (which is able to alter the data content, e.g., adding or removing headers) and then forwarded on to the destination physical terminal or its receiver program.

Some fields in the logical terminal table and in the physical terminal table are mentioned in the following descriptions; more information on these fields can be found in the logical terminal table and the physical terminal table information in the section on Tables and Data Structures.

The outbound and the inbound multiplexing are separate, so although in most situations the multiplexing program will perform both functions, it is possible to perform only inbound multiplexing or only outbound multiplexing in any program.

The ltflag field of the logical terminal table (zltt_type) contains two flag bits ZCOM_LTFLAG_OMX and ZCOM_LTFLAG_IMX, which indicate whether messages to or from the logical terminal respectively, are to be handled by a multiplexing program. These bits are set by TTGEN according to the device type.

When more than one logical terminal is mapped to a single physical terminal, the ltgzlk field (<zltt_type>.ltgzlk) linkage forms a circular list of terminals in the same multiplexed group (i.e., mapped to the same physical terminal). The ltqzlk field contains the ZLU number (16-bit) of the next terminal in the group. For a non-multiplexing terminal, this field contains the ZLU number of the current terminal (i.e., pointing back to itself, a special case for circular list).

Outbound Multiplexing

The multiplexing program uses the zread call to determine the origin of the message, after which, the program would normally attach a protocol header and forward the message to the destination physical terminal. MZAUXL in the message header (see the chapter on Tables and Data Structures) can be used to save the originating source node and ZLU on the outbound message. The MZSRCE field in the message header is then overridden with the multiplexing program's primary ZLU, hence status and response messages may be routed to the multiplexing program instead of the sender. Routine zsend writes to the physical terminal (with bit ZCOM_ZSEND_NOMX set in the mode parameter). Routine zsend with user header (mode bit ZCOM_ZSEND_MHD) must also be used.

The responses to the outbound messages are received by the multiplexing program as type 6 (ZCOM_MSTYPE_RSLT) messages (request code ZCOM_MRQCODE_WRITE [2]). The multiplexing program has to strip the protocol header which it had previously added and forward the response to the ZLU number saved in MSPARE (using zsend with bits ZCOM_ZSEND_MHD and ZCOM_ZSEND_NOMX both set).

Figure 2-3 Outbound Multiplexing

Outbound Multiplexing

If the ZCOM_LTFLAG_OMX bit is set in the LTFLAG word of the logical terminal table, then a logical terminal is enabled for outbound multiplexing. This means that any message sent (by zsend) to this terminal ZLU will be formatted as normal (type 4, ZCOM_MSTYPE_LPLT, message with request descriptor block), but instead of being queued to the physical terminal transmit queue, it will be queued to the program ZLU defined by LTZMXP. These fields must have been defined to the system for each terminal by a prior zset_rcvr call (mode 2, ZcOUTB_MLTPLX) by the outbound multiplexing program during its initialization.

The zcntl call works in a similar way to zsend. For example, an enable of a multiplexed logical terminal ZLU will queue an enable request (type 4, ZCOM_MSTYPE_LPLT, request code 7, ZCOM_MRQCODE_ENB) to the outbound multiplexing program's input queue. These messages would normally be used to maintain the flags for the logical terminal in LTSTAT. They may also generate a control command to the physical terminal from the multiplexing program.

Inbound Multiplexing

If the ZCOM_LTFLAG_IMX bit is set in the LTFLAG word of the logical terminal table, then the logical terminal is enabled for inbound multiplexing. This means that when an application program selects the terminal for input (using zset_rcvr default mode 0), zset_rcvr will insert the application program's ZLU into LTZRVR (rather than PTZRVR for a terminal without inbound multiplexing).

It is up to the inbound multiplexing program to define itself to the ZCOM subsystem as the receiver for messages from the physical terminal using the zset_rcvr (mode 1, ZcINB_MLTPLX) call. This sets PTZRVR in the physical terminal table.

The inbound multiplexing program has the task of receiving all messages from the physical terminal. It determines the origin of the logical terminal from which the messages were sent. Then it processes any of the control messages and forwards the data portion of any data messages to the application receiver.

Figure 2-4 Inbound Multiplexing

Inbound Multiplexing

Thus, to process an inbound message with multiplexing:

  • zread (the message type will be type 1, ZCOM_MSTYPE_MSLT - a message from a terminal ZLU).

  • The source ZLU is obtained from PTZLU. PTZLU gives the ZLU of one of the ZLUs in a multiplexed group.

  • Decode the protocol header to extract the logical terminal address. Use the ltfind routine to scan the multiplexed group to find a match of the logical terminal address with LTADDR.

  • Build a ZCOM message header where the source ZLU is the ZLU found by ltfind, and the destination ZLU is taken from LTZRVR of the logical terminal able.

  • Use zsend (with bit ZCOM_ZSEND_MHD set) to send the message and the ZCOM header to LTZRVR.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2000 Hewlett-Packard Development Company, L.P.