MQSeries Implementation Guide

NET24-XPNET™

Version 4.1, September 2021

Table of Contents
About this publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
What’s new in this publication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Product description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Message flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
System assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
General impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Message identifier and correlation identifier support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
MsgId and CorrelId support by station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
MsgId and CorrelId support by message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Expiry support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Alias queue support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Clusters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
REPLYTOQ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
FORMAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Setup instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Distribution tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Restoring files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Installing MQSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Accelerate the executable object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Installing EMS template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
MQSI environment setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Network configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
USERDATA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
DEVICE configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
LINE configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
STATION configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
TACL environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Startup PARAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Startup ASSIGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Startup sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Trace facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Setup examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
TACL macro startup file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Network configuration example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Network configuration example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Network configuration example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Notices
ACI Worldwide

Offices in principal cities throughout the world.

www.aciworldwide.com

Americas +1 402 390 7600

Asia Pacific +65 6334 4843

Europe, Middle East, Africa +44 (0) 1923 816393

© Copyright ACI Worldwide, Inc. 2021

All information contained in this documentation, as well as the software described in it, is confidential and proprietary
to ACI Worldwide, Inc., or one of its subsidiaries, is subject to a license agreement, and may be used or copied only
in accordance with the terms of such license. Except as permitted by such license, no part of this documentation
may be reproduced, stored in a retrieval system, or transmitted in any form or by electronic, mechanical, recording,
or any other means, without the prior written permission of ACI Worldwide, Inc., or one of its subsidiaries.

ACI, ACI Worldwide, the ACI logo, ACI Universal Payments, UP, the UP logo and all ACI product/solution names are
trademarks or registered trademarks of ACI Worldwide, Inc., or one of its subsidiaries, in the United States, other
countries or both. Other parties' trademarks referenced are the property of their respective owners.

1
About this publication
This is a guide describing how to install the NET24-XPNET MQSI product that is used in conjunction with IBM’s
MQSeries for HP NonStop product.

Audience
This guide is intended for use by those responsible for installing the NET24-XPNET MQSI product on HP NonStop
platforms.

What’s new in this publication

Here is what is new in the MQSeries Implementation Guide.

September 2021

No changes since previous release.

February 2020

No changes since previous release.

December 2017

Minor changes to support MQv8 are documented throughout.

2
System overview
Product description
MQSI is implemented under the NET24-XPNET Common Transport System.

The NET24-XPNET Common Transport System (CTS) is designed to provide a standardized message delivery
system between XPNET and a separate Interface process. The Interface process is responsible for communicating
with HP NonStop based data-communication components or HP NonStop based interfaces to external systems as
applicable. The CTS component delivered as part of the XPNET process, referred to as CTS/I (Common Transport
System/Internal), provides the logic to manage the logical endpoints (stations and lines) used to pass messages to
the Interface process. XPNET supplies a fault-tolerant platform for message queuing and a command, control, and
inquiry interface for management of logical endpoints.

The ACI developed Interface process runs as a separate process and uses a standard module to communicate with
the XPNET process and the bound-in CTS/I protocol. This standard module is known as CTS/E (Common Transport
System/External) and is delivered as part of the Interface process. The XPNET process configured with CTS
stations is not aware of which type of Interface process is running and treats all such CTS/E based Interface
processes in the same manner (according to customer configured station and line attributes).

Some EMS events generated by MQSI may include references to CTS/E.

The major components required for the MQSI interface are

1. the XPNET software,

2. an XPNET application,
3. the MQSI process, and
4. MQSeries for HP NonStop Kernel version 2 release 2.0.1, MQSeries for HP NonStop Kernel version 5 release 1,
or MQSeries for HP NonStop version 5 release 3.

The MQSI product is a single process started by a TACL RUN command. When the RUN command is executed it
must start the process as a named process. The MQSI process must be started by the HP NonStop user
MQM.MANAGER. Once MQSI is started, control of the process is accomplished through the STATION, LINE and
DEVICE objects within XPNET. The system administrator is responsible for configuring these objects before
attempting to run the MQSI process.

The configuration of the product can include several different types of configurations. The process is capable of
running as a single process with only one MQSeries connection, or as multiple processes each with multiple
MQSeries sessions. Performance requirements will determine the optimum configuration.

It should be noted that one logical connection is comprised of one XPNET LINE object that corresponds to two
MQSeries links. One MQSeries link is to a MQSeries remote queue and one to a MQSeries local queue. Remote
queues are used for sending messages to a remote host application. The local queue is used to receive messages
from a remote host application.

Once the XPNET system is started, the local MQSeries system is started, and the MQSI process is started, the
system operator can create a link between XPNET and MQSeries using ONCF commands. All control for starting
and stopping the XPNET connection is performed from within XPNET using ONCF commands. However, only
MQSeries controls the actual communications link between the HP NonStop system and the host system. All

3
channel and queue control is performed from within the MQSeries system.

The XPNET station and line objects can be started successfully using ONCF commands even if the communications
link is down. The starting of a XPNET line will cause a logical connection with the local and remote queues within the
local MQSeries system. It will not know of any communications link errors. This will only be communicated by
timeout errors when messages are sent.

Message flow

The preceding diagram shows an overview of all the components involved in a simple MQS system using the
CTS/E-mqs process as an interface on the HP NonStop platform. This section will give an overview of how a
message flows through the various components. Each step in the flow of the message is numbered in the diagram to
correspond to the steps listed below.

4
Step 1: There must be an application on the XPNET system that initiates a
message. The message is sent to XPNET where it will be routed to a
specific CTS STATION object.

Step 2: XPNET will invoke the CTS protocol handler and route the message to the
CTS/E-mqs process using the SEND_DATA message format.

Step 3: CTS/E-mqs will send the message to the HP NonStop MQS System Queue
Manager using the MQPUT API verb. It will use either the remote queue
associated with the station started by XPNET or the specified MQMD
ReplyToQ depending upon the configuration (see Clusters for details).

Step 4: If the message is destined for a remote queue manager, the local queue
manager stores the message on a transmission queue. The Message
Channel Agent is responsible for transmitting the message between queue
managers on a CHANNEL.

Step 5: When the Host MQS System Queue Manager receives the message, it will
route the message to the correct local queue. The host application will be
notified that a message has arrived and will read the message from its local
queue. It will then process the message.

Step 6: When the host application is ready to send a message to the HP NonStop
platform it will send the message to the Host MQS System Queue Manager.

Step 7: If the message is destined for a remote queue manager, the local queue
manager stores the message on a transmission queue. The Message
Channel Agent is responsible for transmitting the message between queue
managers on a CHANNEL.

Step 8: When the HP NonStop MQS System Queue Manager receives the
message, it will route the message to the appropriate local queue and notify
the MQSI process that a message has arrived. The MQSI process will read
the message from the local queue using the MQGET API verb.

Step 9: MQSI will respond to an outstanding RECEIVE_DATA request message

from XPNET. The reply will contain the message from the host application.

Step 10: XPNET routes the message to the appropriate destination based on the line
and station configuration within XPNET.

System assumptions
MQSI supports IBM’s MQSeries for HP NonStop Kernel Version 2 Release 2.0.1, Version 5 Release 1, Version 5
Release 3, and Version 8 Release 0.

5
MQSeries for HP NonStop Kernel Version 2 Release 2.0.1 requires release D30 or later.

MQSeries for HP NonStop Kernel Version 5 Release 1 requires D45 or later.

MQSeries for HP NonStop Server Version 5 Release 3 requires at least G06.25 with SPRs T8306G10ABG and
T8994G09AAL. On an Itanium based NS-series server, MQ Version 5 Release 3 requires at least H06.04 with SPRs
T8306H01ABJ, T8994H01AAM, T9050H02AQG, and T0288H02AAG. XPNET 3.1 on an Itanium based NS-series
server requires H06.06 which does include the G06 SPRs required by MQ 5.3.

MQSeries for HP NonStop Server Version 8 Release 0 requirements are listed below:

• MQ V8.0 APAR IT21862

• One of the following servers:
◦ NB-Series HPE Integrity NonStop Blade System (J-Series)
◦ NS7-Series HPE Integrity NonStop X (L-Series)
◦ NS3-Series HPE Integrity NonStop X (L-Series)
• Minimum Release Version Updates (RVUs):
◦ J06.20
◦ L16.05

MQSI has been written to support the full duplex mode of operation. It will also support half duplex mode in a limited
way. The half duplex mode is largely controlled by the flow of messages from XPNET. There is no message flow
checking within the MQSI process to ensure messages match. Half duplex as implemented here is only considered
from the standpoint of how XPNET processes the messages. It will, however, perform some queue management of
the local queue when a connection is first initiated. When a connection is initiated by a line or station START
command, the MQSI process will check the local queue for the connection. If there are any messages currently on
the local queue they will be moved to the dead letter queue associated with the station.

Before testing can begin using the MQSI process the system administrator must install, setup and start the local
version of MQSeries on the HP NonStop platform where MQSI is to be run.

It is the responsibility of the system administrator to provide the correct names to be used for the local, remote and
dead letter queues within the MQSeries system. These names are used in the setup of the XPNET configuration.
The system administrator must also provide the name of the local Queue Manager. It too, is used in the XPNET
configuration.

General impacts
This product will impact the installation and/or the configuration of the XPNET product. To install the MQSI process,
the customer will be required to modify the XPNET configuration before the product can be functional.

Message identifier and correlation identifier support

MQSI supports the use of the Message Identifier (MsgId) and Correlation Identifier (CorrelId) match options with the
GET and PUT API calls to MQSeries. The MsgId and CorrelId are 24 character fields that can be used to control
what messages are retrieved from a queue.

Message and Correlation Identifier support is optional and can be configured via the XPNET station USERDATA or

6
the XPNET device declaration. Configuring the XPNET station USERDATA to support the Message and Correlation
Identifier feature indicates match criteria is specified at the station level. Configuring the XPNET device declaration
to support the Message and Correlation Identifier feature indicates match criteria is specified at the message level.

MsgId and CorrelId support by station

Support at the station level indicates that MQSI will attempt to GET and PUT messages from/to an XPNET station’s
local/remote queue using a constant Message and/or Correlation Identifier. The Message and Correlation Identifiers
used to GET and PUT messages are specified using one of four attributes (MsgIdIn, MsgIdOut, CorrelIdIn and
CorrelIdOut). These four attributes are configured in station USERDATA. Because station USERDATA is limited to
63 characters, it is not possible to configure all fields with the maximum 24 characters. The current ACCESS and
DLQ attributes that are also configured in station USERDATA may further restrict the possible size of the Message
Identifier and Correlation Identifier attributes. The ACCESS and DLQ attributes are optional which frees up station
USERDATA for defining the MsgId and CorrelId attributes. The size of the identifier attributes will depend on the
number and size of USERDATA attributes defined within the 63-character limit.

If both MsgIdIn and CorrelIdIn are defined for a station, then only messages that match on both these attributes will
be retrieved for this station. If only one attribute is defined, then the match is made against that attribute. Not
specifying either attribute will allow all messages to be retrieved. The values defined by MsgIdOut and CorrelIdOut
are placed in the corresponding fields of the message descriptor when messages are PUT to the message queue.

Station USERDATA is not case sensitive and allows these attributes to be entered in lower or upper case. MQSI will
up shift all USERDATA to uppercase; however, no change is made to the displayed station USERDATA. NCPCOM
INFO on the USERDATA will show the information as originally entered, i.e. lower and/or upper case. For clarity, it is
suggested that all USERDATA be entered in uppercase.

The station USERDATA attributes are validated by MQSI when a station is started. An attribute error will cause the
station to go ABNORMAL and output several EMS events. EMS event 2105 contains a detail code that identifies
which attribute is in error. These detail codes are as follows:

• 3005 ACCESS invalid

• 3006 DLQ invalid
• 3008 MsgId In invalid
• 3009 MsgId Out invalid
• 3010 CorrelId In invalid
• 3011 CorrelId Out invalid

MsgId and CorrelId support by message

Support at the message level indicates that the Message Identifier and/or Correlation Identifier can be unique for
every message. The remote host application establishes the MsgId and CorrelId for each request. MQSI and XPNET
transport these values through to the XPNET application via message userdata. The XPNET application must return
the message userdata in its reply. MQSI will swap the MsgId and CorrelId if the MQMD Report Options field is zero
(MQRO_COPY_MSG_ID_TO_CORREL_ID). MQSI will transport the MsgId and CorrelId back to the remote host
application thus allowing the remote host application to use match criteria on the MQGET to match responses to
their original request.

To implement Message Identifier and Correlation Identifier support at the message level, the XPNET station device
declaration must be altered to support the use of HDR within the INPUTFORMAT and OUTPUTFORMAT attributes.

7
 ALTER DEVICE D1A^MQS, INPUTFORMAT HDR ^ TXT
ALTER DEVICE D1A^MQS, OUTPUTFORMAT HDR TXT

If the device declaration INPUTFORMAT contains HDR, MQSI will retrieve the next message from its local queue
(no match criteria is specified - all messages will be retrieved). MQSI will extract the Message Descriptor (MQMD)
structure from the message and transmit the structure to the XPNET application via the XPNET message user data.

If the device declaration OUTPUTFORMAT contains HDR, MQSI will use the MQMD within the XPNET message
user data to establish the MQMD for the response to the remote host application. The remote host application or the
XPNET application can control whether the MsgId and CorrelId are swapped prior to the MQSI MQPUT. If the
MQMD Report Options established by the remote host application or updated by the XPNET application is not zero,
MQSI will move the MsgId and CorrelId within the XPNET message userdata to their respective fields within the
MQMD formatted for the MQPUT call. If the MQMD Report Options field established by the remote host application
or updated by the XPNET application is zero (MQRO_COPY_MSG_ID_TO_CORREL_ID), MQSI will swap the
MsgId and CorrelId before moving them to the MQMD formatted for the MQPUT API verb. This is configurable and
specific to the site’s remote host application and how that application is implementing MQGET match criteria.

The message that MQSI forwards to CTS/I will be modified to include an XPNET message header if the station’s
INPUTFORMAT indicates the use of the message header (HDR). The XPNET message will contain an additional
328 bytes of user data area. The structure for the additional user data area is as follows:

Field Length Value

User data token eye catcher 2 "MQ"

User data token length 2

User data token data 324

The CTS user data token, eye catcher "CT", will also be present within the message user data area, and thus the
XPNET application must locate the MQSI user data token via the "MQ" eye catcher to locate the MQSI specific data.

Expiry support
MQSI supports the expiry functionality. Expired messages are deemed such via the use of the MQSeries Message
Descriptor structure Expiry field or the XPNET message header MSG^TIMELIMIT field.

This functionality requires that the XPNET message header be passed to and from the station. This is accomplished
via the XPNET device declaration INPUTFORMAT and OUTPUTFORMAT attributes. The device INPUTFORMAT
attribute must be “HDR ^ TXT” for the MQ station and the OUTPUTFORMAT must be “HDR TXT”.

The MQMD Expiry is a period of time, expressed in tenths of seconds, which indicates how long a message can wait
to be pulled from the queue before it becomes eligible to be discarded. The MQSeries queue manager will discard a
message if the Expiry has elapsed only when an MQGET call occurs that would have resulted in the message being
returned. Thus there may be messages on a queue that have passed their expiry time. These messages count
towards the number of messages on the queue. The transaction originator may set the MQMD Report field with one
of the MQRO_EXPIRATION_* attributes. By implementing one of these attributes MQSeries will generate a report of
discarded messages. If this option is not activated the MQSeries queue manager will discard the expired message

8
without notification, for example, no events.

MSG^TIMELIMIT can be set by the XPNET application to indicate the interval of time in which the message must be
delivered to its destination or be returned to its source. MSG^TIMELIMIT is set by the application as a number of
ticks (0.01-second intervals). XPNET converts MSG^TIMELIMIT from a number of ticks to an actual time by
updating it with the sum of MSG^TIMELIMIT and MSG^TIME. If the message is not delivered to its destination by
this time, XPNET will return the message with a message failure 104 if the destination is a station or a message
failure 204 if the destination is a process.

This enhancement uses both the MQMD Expiry field and the MSG^TIMELIMIT within the XPNET message header.
A hierarchy has been established to denote which value will be used:

1. If the MQMD established by the transaction originator indicates an amount of time in the Expiry field, MQSI will
use that value as the MQMD Expiry.
2. If the MQMD Expiry field established by the transaction originator is less than or equal to 0 (-1 indicates an
indefinite wait), MSG^TIMELIMIT will be retrieved. If MSG^TIMELIMIT is greater than zero, MQSI will compare
MSG^TIMELIMIT with the current time. MQSI will place this difference in the MQMD Expiry field in tenths of a
second.
3. If there is not a positive value in the MQMD Expiry field established by the transaction originator and the XPNET
message header MSG^TIMELIMIT is not set, MQSI will set the MQMD Expiry field to the default value (wait
indefinitely).

Alias queue support

MQSI supports an alias queue type as the local queue if the XPNET line DUPLEX is configured for FULL DUPLEX.

If the XPNET line DUPLEX is configured as HALFLCL an alias queue type cannot be used as the local queue. If
HALFLCL DUPLEX is configured MQSI initiates an MQINQ API call using the MQIA_CURRENT_Q_DEPTH selector
to retrieve the queue depth. Any messages on the local queue when the HALFLCL DUPLEX station is started will be
moved to the dead-letter-queue. MQSeries does not support the MQIA_CURRENT_Q_DEPTH selector for the alias
queue type and thus will return code 2068 from the MQINQ API call. The HALFLCL DUPLEX XPNET station will
transition to an ABNORMAL state in this case.

Clusters
MQSI supports the use of Clusters which were introduced in Version 5 Release 1 of IBM’s MQSeries for HP
NonStop Kernel. Please note the following excerpt from IBM’s MQSeries Queue Manager Clusters Manual:

“As with distributed queuing, an application uses the MQPUT call to put a message on a cluster queue at any queue
manager. An application uses the MQGET call to retrieve messages from a cluster queue on the local queue
manager.”

A local queue must be defined for each queue manager to complete MQGET API calls. For example, assuming the
following XPNET configuration,

XPNET LINE LAPPL = QMGR1

XPNET STATION LADDR = RECV.QUE1

9
Queue manager QMGR1 must have the queue RECV.QUE1 locally defined.

REPLYTOQ
MQSI supports the use of the Message Descriptor ReplyToQ. The STRTMQSI REPLYTOQ parameter will be used
to determine whether the ACI MQSeries Interface will PUT a message in the queue specified by the MQMD
ReplyToQ field or to the queue defined within the XPNET station RADDR attribute. The support of the MQMD
ReplyToQ is controlled by the STRTMQSI REPLYTOQ parameter in conjunction with the XPNET device
INPUTFORMAT and OUTPUTFORMAT attribute settings.

If the STRTMQSI REPLYTOQ param is OFF, MQSI will put the message on the queue specified by the XPNET
station RADDR attribute. This will require a single MQPUT API call. This functionality is how MQSI worked prior to
the addition of the REPLYTOQ param.

By setting the STRTMQSI REPLYTOQ parameter ON please note that you will incur performance degradation for
the ACI MQSeries Interface. MQSI could be required to complete up to three API calls for every PUT message as
opposed to the one API call when the parameter is turned OFF. If the STRTMQSI REPLYTOQ parameter is ON,
MQSI will compare the MQMD ReplyToQ field to the remote queue currently open. If the two are equivalent, a
MQPUT will be done to the queue. If the two are not equivalent, MQSI will MQCLOSE the current remote queue,
MQOPEN the MQMD ReplyToQ, and MQPUT the message on the queue specified by the MQMD ReplyToQ. Note
there are three API calls versus one API call with this configuration and this is the cause for the performance
degradation.

The STRTMQSI REPLYTOQ parameter default is OFF.

FORMAT
MQSI has been enhanced within version REL3_VER1_MQSI07_20100212 to load the Message Descriptor Format
field on the MQPUT API call to the remote queue. There are two mechanisms in which the customer can specify
what Message Descriptor Format to use on the MQPUT.

A new parameter, FORMAT, has been added to the STRTMQSI file. If the FORMAT STRTMQSI parameter is
populated, its value will be used by all stations running under the MQSI process started by the respective
STRTMQSI file.

The Message Descriptor Format field may also be set within the XPNET station USERDATA field. The format for this
field is as follows:

“-FM={format value}”

The {format value} added in the XPNET station USERDATA field will only be used by that station. If a specific
Message Descriptor Format is required for a station, the XPNET station USERDATA field must be populated with the
“-FM=” token.

The hierarchy implemented for the Message Descriptor Format field is to use the XPNET station USERDATA “-FM-“
token value as the first option. If the XPNET station USERDATA “-FM=” value is not populated, MQSI will use the
STRTMQSI FORMAT parameter. If the XPNET station USERDATA “-FM=” value is not populated, and likewise the
STRTMQSI FORMAT is not populated, the IBM Message Descriptor Format default value of MQFMT_NONE,
blanks, will be used.

10
Valid values for the Message Descriptor Format field for both the STRTMQSI FORMAT parameter and the station
USERDATA field are as follows:

"MQADMIN "
"MQCHCOM "
"MQCICS "
"MQCMD1 "
"MQCMD2 "
"MQDEAD "
"MQHDIST "
"MQEVENT "
"MQIMS "
"MQIMSVS "
"MQHMDE "
"MQPCF "
"MQHREF "
"MQHRF "
"MQHRF2 "
"MQSTR "
"MQTRIG "
"MQHWIH "
"MQXMIT "

11
Setup instructions
The procedure required to setup and run a single station configuration through a single MQSI process is very simple.
However, due to the flexibility of the MQSI process and the MQSeries product the user can create an extremely
complicated MQSeries system. It is important to plan the configuration required for communicating with a host
system using MQSeries. A systems administrator will accomplish a large part of this.

It is important to consider some of the performance issues during the planning phase. The MQSI process is a multi-
threaded program. The process can handle multiple communication links at the same time. When related to the
XPNET configuration, there can be many lines connected to a single MQSI process.

The maximum number of concurrent sessions on one MQSI process is 256, but the performance requirements may
dictate fewer connections if all sessions are used concurrently. Therefore, the user should be careful not to overload
a single MQSI process. The user should always consider how to balance the load based on the amount of expected
traffic on each MQSeries channel.

If performance begins to deteriorate it is possible to run multiple copies of the MQSI process using unique PPD
names. The same installation steps apply to one or more MQSI processes. The load can be spread out over several
MQSI processes running in different CPU’s if required. There are also ways of balancing the load with the MQSeries
product.

Distribution tape
Restoring files
If the MQSI files have been received with other XPNET files, skip this step and proceed with the next step once the
XPNET subvolume has been restored. If the MQSI files have been received unaccompanied by any other XPNET
code, restore them to the XPNET subvolume (using RESTORE or UNPAK appropriately). An example of the
RESTORE command is shown below.

RESTORE /OUT $S.#MQSI/ $TAPE, ($*.*.*), VERIFY,

LISTALL, TAPEDATE, MYID, VOL $TEST.XPNET, AUDITED

The following files should have been restored:

• MQSIAXCL - TACL routine to accelerate the MQSI object

• MQSIB - Bind file to bind ACI’s interim object file with IBM’s MQSeries library
• MQSIBC - Obey file to initiate the binding of ACI’s interim object with IBM’s MQSeries library.
• MQSIEC - C output for MQSI DDLs
• MQSIEDDL - DDL source for MQSI DDLs
• MQSIETAL - TAL output for MQSI DDLs
• MQSIETCL - TACL output for MQSI DDLs
• MQSIO - Interim object file for MQSeries Interface
• MQSITPLO - EMS template object for MQSI events

12
 • MQSITPLS - EMS template source for MQSI events
• OCAMQSI - TACL routine to accelerate the MQSI object using the Object Code Accelerator (OCA) system utility
• STRTMQSI - TACL MACRO to start MQSI

Installing MQSI
An interim MQSIO object is provided. The customer is responsible for completing a bind step that will create the
MQSI executable that the user will run and interface with IBM’s MQSeries product. IBM’s support for multiple
releases and fix levels of the MQSeries library file mandates that the customer complete the final bind step to bind
ACI’s software with the IBM MQSeries library.

The XPNET.MQSIO interim object file that is provided by ACI needs to be bound with IBM’s MQSeries library file,
MQMLIBC for MQSeries 2.2.0.1, MQMLIB for MQSeries 5.1, or MQMTNS for MQSeries 5.3 or 8.0 to create an
executable object.

This is accomplished by completing the following steps:

1. Edit XPNET.MQSIB file.

◦ If the user is running MQSeries 5.3 or newer they must verify the MQMTNS location and update the
volume/subvolume as appropriate and change MQMLIB to MQMTNS.
◦ If the user is running MQSeries 5.1 the user must verify the MQMLIB location and update the
volume/subvolume as appropriate.
◦ If the user is running MQSeries 2.2.0.1 the user must verify the MQMLIBC location and update the
volume/subvolume as appropriate and change MQMLIB to MQMLIBC.

NOTE The default will be to bind ACI’s interim object with IBM’s MQSeries 5.1 library.

2. Obey XPNET.MQSIBC to build the final XPNET.MQSI object.

The STRTMQSI file referenced in the TACL macro startup file section will point to the XPNET.MQSI object.

Accelerate the executable object

For optimal performance it is recommended that the MQSI object file be accelerated. Run the MQSIAXCL TACL
routine to accelerate the MQSI object for NonStop Himalaya K-series or S-series systems:

TACL> MQSIAXCL

Run the OCAMQSI TACL routine to accelerate the MQSI object for NonStop Integrity NS-series systems (requires
the OCABUILD TACL routing to also be present on the XPNET subvolume):

• TACL> OCAMQSI

Run the OCAMQSI TACL routine to accelerate the MQSI object for NonStop Integrity NS-series systems (requires
the OCABUILD TACL routing to also be present on the XPNET subvolume):

13
 • TACL> OCAMQSI

Run the OXAMQSI TACL routine to accelerate the MQSI object for NonStop X systems (requires the OXABUILD
TACL routing to also be present on the XPNET subvolume):

• TACL> OXAMQSI

Installing EMS template

The MQSI template file needs to be added to the EMS system so that all EMS messages generated by these
products will display correctly within EMS. Using a HP NSK edit utility add the EMS template by modifying
$<vol>.SCRIBE.TMPLIN. With the editor add the following line:

FILE $<volume>.XPNET.MQSITPLO

Next, run TMPLMAKE and GOINST as described in the NET24-XPNET Event Management Manual.

MQSI environment setup

It is the responsibility of the system administrator to setup the MQSeries environment. In doing so the system
administrator must establish the definition of the transaction’s path. Once the configuration is established the system
administrator must provide the following information:

• The Queue Manager name for each MQSeries system to be accessed.

• Local queue names for each logical link to the host system within each MQSeries system.
• Remote queue names for each logical link to the host system within each MQSeries system.
• The dead letter queue name to be used for each station within each MQSeries system if the link is to run in half
duplex mode.

Network configuration
USERDATA configuration
The station USERDATA section is used to provide protocol specific configuration information. If USERDATA is not
setup at the station level, default values are provided to the MQSI process.

There are seven attributes in the USERDATA section that are used by the MQSI process. They are the access
method, the dead letter queue name, the input and output message identifier, the input and output correlation
identifier, and the output format.

SET STATION USERDATA "-A<method> -D=<queue name> -MI=<msgid in>

-MO=<msgid out> -CI=<correlid in> -CO=<correlid out> -FM=<format out>" LENGTH 63
CHARACTERS

Where:

14
Method
“-A” or “ACCESS”
Method defines the type of access that should be used when connecting to the local queue. Allowed values are "-
" or “EXCLUSIVE” for Exclusive and "+" or “SHARED” for Shared. Default is "-A-" (Exclusive).

queue name
“-D” or “DLQ”
Specifies the MQSeries queue name of the dead letter queue. This name is required when operating in half
duplex mode. When the flow control is full duplex the literal value of "N/A" must be specified. Default is "N/A".

msgid in
Optional 1 – 24 character message identifier used with MQGET match options.

msgid out
Optional 1 – 24 character message identifier used with MQPUT.

correlid in
Optional 1 – 24 character correlation identifier used with the MQGET match options.

correlid out
Optional 1 – 24 character correlation identifier used with MQPUT.

format out
Optional 1-8 character format to be used with MQPUT.

The "method" attribute will usually be set to EXCLUSIVE. This indicates that the local queue to be accessed by the
MQSI process on behalf of a given line belongs to that specific line exclusively. If SHARED is used then other lines
will be allowed to connect to and access the same local queue. That places the responsibility of message routing on
the XPNET application.

Examples:

SET STATION USERDATA "ACCESS EXCLUSIVE DLQ N/A"

SET STATION USERDATA "-A- -D=N/A"
SET STATION USERDATA "ACCESS SHARED DLQ DEAD.LETTER.QUEUE"
SET STATION USERDATA "-A+ -D=DEAD.LETTER.QUEUE"
SET STATION USERDATA "-A+ -MI=111 –MO=222 –CI=MQ111 –CO=MQ222"
SET STATION USERDATA "-MI=111 –CI=MQ111"
SET STATION USERDATA "–MO=222 –CO=MQ222"
SET STATION USERDATA "-A+ -MI=111 -CI=MQ111 –CO=MQ222"
SET STATION USERDATA "ACCESS SHARED –MO=222 –CO=MQ222"
SET STATION USERDATA "–CO=MQ222 –FM=MQSTR"

DEVICE configuration
The example in the following box should be valid for most installations if the site does not wish to implement the
MsgId and CorrelId Support at the message level.

15
 RESET DEVICE
SET DEVICE RECVLEN 4096
SET DEVICE XMITLEN 4096
SET DEVICE INPUTFORMAT TXT
SET DEVICE OUTPUTFORMAT TXT
SET DEVICE POLLFORMAT “ ”
SET DEVICE SELECTFORMAT “ ”
SET DEVICE TYPE 0
ADD DEVICE <d1a^mqs01>, UNDER SYSNAME \<node>, UNDER NODE <p1a^gate>

The example in the following box should be valid for most installations if the site wishes to implement the MsgId and
CorrelId Support at the message level.

RESET DEVICE
SET DEVICE RECVLEN 4096
SET DEVICE XMITLEN 4096
SET DEVICE INPUTFORMAT HDR ^ TXT
SET DEVICE OUTPUTFORMAT HDR TXT
SET DEVICE POLLFORMAT “ ”
SET DEVICE SELECTFORMAT “ ”
SET DEVICE TYPE 0
ADD DEVICE <d1a^mqs01>, UNDER SYSNAME \<node>, UNDER NODE <p1a^gate>

LINE configuration
For each logical session to be established between XPNET and the host system there must be a line entry in the
Network. Each entry will use the format defined in the box below.

RESET LINE
SET LINE PORT <MQSI ppd name>.#sta01
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL <queue manager name>
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE <l1a^mqs01>, UNDER SYSNAME \<node>, UNDER NODE <p1a^gate>

The following values must remain as shown above:

• CMETHOD - Set to ALLOCATE

• CINIT - Set to IMMEDIATE
• SENDCONFIRM - Set to REQUEST
• EXPDATA - Set to DISCARD
• FMM - Set to ALL

16
 • ATIMER - Set to 0 (Ignored by MQSI)

The PROTOCOL attribute defines to XPNET that the CTS protocol will be used for this line object. It must be stated
as shown above in the example.

The queue manager name in the LAPPL attribute is the Queue Manager name assigned by the system
administrator. The length of this attribute cannot be longer than 48 characters.

The PORT attribute associates the line to the ppd name of the MQSI process to be accessed by this line object. If
more than one line is to be assigned to the same MQSI process the second qualifier of the ppd name must be
unique between all lines accessing the same MQSI process.

STATION configuration
For each logical session to be established between XPNET and the host system there must be a station entry in the
Network. Each entry will use the format defined in the box below.

RESET STATION
SET STATION LINENAME \<node>.<p1a^gate>.<l1a^mqs01>
SET STATION DEVICE <d1a^mqs01>
SET STATION DESTINATION < destination name>
SET STATION LADDR <local queue name>
SET STATION RADDR <remote queue name>
SET STATION USERDATA "ACCESS EXCLUSIVE DLQ N/A" LENGTH 63 CHARACTERS
ADD STATION <s1a^mqs01>, UNDER SYSNAME \<node>, UNDER NODE <p1a^gate>

Where:

local queue name

Specifies the name of the local MQSeries queue to access when waiting for a message to arrive from the host
system.

remote queue name

Specifies the name of the remote queue to access when sending messages to the host.

destination name
Specifies where a message is to be routed when an input message is received by this station.

The system administrator must take note when naming the local queue name and the remote queue name. The
MQSeries system will allow a queue name to be 48 characters in length.

When a different set of values are needed for the USERDATA attribute for a specific station, the user can enter a
new set of values using the SET STATION USERDATA syntax. Refer to the USERDATA configuration section for
additional information.

TACL environment
The MQSI process must be run from a TACL prompt by MQM.MANAGER. Before the process is started there must
be several param, assign and define commands executed. All of these commands together define to the MQSI
process the environment variables it needs to know about before it starts. The best way to enter these commands is

17
through a TACL MACRO file. The STRTMQSI file is a TACL macro provided as an example.

Startup PARAM
The MQSI process uses the following PARAM settings during initialization. These settings are specific to MQSI
routines.

PARAM BACKUPTYPE
Defines the backup type (NONE or WARM). The default is NONE.

PARAM BACKUPCPU
Defines the backup CPU if BACKUPTYPE is not NONE. The default is assigned by the CTS/E, primary CPU
exclusive OR’d with 1.

PARAM MAXBUFLEN
Used to determine the size of buffer that is allocated for $RECEIVE processing. The default is 4095 bytes.

PARAM CHKSUBTYPE
Specifies the subtype that is checked on open messages. This must be set to 0.

PARAM TMF-FLG
Defines whether MQSI will maintain the TM/MP transaction. TMF-FLG set to ON indicates MQSI will maintain the
TM/MP transaction. TMF-FLG set to OFF indicates the MQ-Series queue manager will maintain the TM/MP
transaction. The default is OFF.

PARAM CONVERT
Defines whether MQSI will include the MQGMO_CONVERT option on the MQGET call. CONVERT set to ON will
result in MQSI instructing the IBM MQSeries queue manager to convert the message to conform to the MQMD
CodedCharSetId and MQMD Encoding values before the data is copied to the MQGET buffer. CONVERT set to
OFF will result in no conversion taking place.

PARAM REPLYTOQ
Defines whether MQSI will change the MQMD ReplyToQ value. If REPLYTOQ is ON and the DEVICE
INPUTFORMAT and DEVICE OUTPUTFORMAT include the HDR option, MQSI will PUT the message to the
MQMD ReplyToQ queue. If REPLYTOQ is OFF or the DEVICE INPUTFORMAT and OUTPUTFORMAT do not
include the HDR option, MQSI will set the MQMD ReplyToQ to the STATION LADDR before completing the
MQPUT.

PARAM FORMAT
This parameter defines whether MQSI will change the MQMD Format value on MQPUT API calls to the remote
queue. The customer can uncomment the desired PARAM FORMAT line within the STRTMQSI file. If a MQMF
Format value is not defined at the XPNET station USERDATA level via the “-FM=” token, the STRTMQSI PARAM
FORMAT value will be used for all stations running under the MQSI started by this STRTMQSI file. If the
STRTMQSI FORMAT parameter is not established the IBM Message Descriptor Format default value of
MQFMT_NONE, blanks, will be used.

The following PARAM settings are required by the MQSeries environment and are specified in the sample
STRTMQSI TACL macro. Other environment variables may be required for a specific user’s environment. Consult
the TACL environment variables section of the MQSeries for HP NonStop Kernel System Management Guide for a
detailed list and description of possible environment variables.

18
 • PARAM MQDEFAULTPREFIX <$volume>
• PARAM SAVE-ENVIRONMENT ON
• PARAM MQEMSEVENTS 127

The following PARAM settings are required by Version 5 Release 3, or newer, of MQSeries for HP Nonstop Server
and are specified in the sample STRTMQSI TACL macro:

• PARAM MQNSKVARPATH <var/mqm directory location>

• PARAM MQNSKOPTPATH <opt/mqm directory location>

The following PARAM setting is required by Version 8 Release 0, or newer, of MQSeries for HP Nonstop Server and
are specified in the sample STRTMQSI TACL macro:

• PARAM MQPATHTNS <base wmq directory location>

Startup ASSIGN
The MQSI process uses the following ASSIGN settings during initialization. These settings are specific to the MQSI
routines.

ASSIGN PRILOG
Used to determine the primary event log file name passed to the EMS utility. The default is $0.

ASSIGN ALTLOG
Used to determine the alternate event log file name passed to the EMS utility. There is no default. If an assign is
not specified, an alternate log destination will not be used.

19
Startup sequence
The following steps describe the startup sequence for the MQSI process.

Step 1
Ensure the MQSeries system is up and running. The MQSeries startup procedure is defined in the MQSeries for
Tandem NSK Version 2 Release 2.0.1 System Management Guide (GC33-1893-01), the MQSeries for Compaq
NSK Version 5.1 System Administration Guide (SC34-5886-00), or WebSphere MQ for HP NonStop Server 5.3
System Administration Guide (SC34-6625-00). After the channels and queue managers are started successfully
there will be a valid communication link between the HP NonStop and the host.

Step 2
Start the MQSI process. This is accomplished by obeying the TACL obey file (refer to TACL macro startup file).
All MQSI processes that will be accessed by a XPNET LINE object should be started at this time.

Step 3
Start the XPNET lines and stations. This is accomplished by executing a XPNET START command for each
station associated to MQSeries. Check the LINE/STATION status. If any of the lines/stations are not ready the
operator should check the EMS log for errors.

If all three of the startup steps are accomplished without errors, the MQSI interface is available. The user can then
start any applications that send and receive messages across these MQSI lines and stations.

20
Trace facility
Individual lines can be traced as messages are received by the MQSI process. Each time a message is received the
process will dump a set of environment variables to the EMS log. These variables will define what action just
occurred among other pertinent bits of information such as error codes and reason code.

To start a line trace the user can type the following command from a NCPCOM prompt:

TRACE LINE <line name>, ON

Once the MQSI process receives the command to start tracing it will begin to dump trace information to the EMS log.
The trace facility can be disabled at any time by executing the following command:

TRACE LINE <line name>, OFF

21
Setup examples
TACL macro startup file
?TACL ROUTINE
#FRAME
#PUSH #INFORMAT
#SET #INFORMAT TACL
#PUSH ppd cpu object bcpu stdout
==== Set the name of STDOUT stream
#SET stdout $0
[#IF stdout/ PROCESSNAME/SYNTAX/]
[#IF NOT [#PROCESSEXISTS [stdout]]
|THEN|
#OUTPUT [stdout], STDOUT DOES NOT EXIST
#UNFRAME
#RETURN
]
[#IF [#ARGUMENT/VALUE ppd/ PROCESSNAME/SYNTAX/]]
[#IF [#PROCESSEXISTS [ppd]]
|THEN|
#OUTPUT ALREADY STARTED: [ppd]
#UNFRAME
#RETURN
]
[#IF [#ARGUMENT/VALUE cpu/ NUMBER END]]
[#IF NOT [#EMPTY [cpu]]
|THEN|
#SET cpu , cpu [cpu]
]
[#IF [#ARGUMENT/VALUE bcpu/ NUMBER END]]
CLEAR ALL
==== Set the name of the object file
#SET object $<vol>.xpnet.mqsi
==== Assign the backup type (NONE or WARM)
==== The default is NONE.
== param backuptype NONE
==== Assign the backup CPU, if backup type is not NONE.
==== The default is assigned by the CTS/E, primary CPU
==== exclusive OR'ed with 1.
The backup CPU may be
==== supplied as the third parameter on the invocation
==== of this macro, or hardcoded in the following
==== PARAM statement.
[#IF NOT [#EMPTYV bcpu]
|then|
param backupcpu [bcpu]
]
==== Assign the primary and alternate log files
==== The default is prilog $0, no alternate log
== assign prilog, $0
== assign altlog, $0
==== Specify the length of the I/O buffers.
The
==== default is:
== param maxbuflen 4095
==== Specify the subtype that is checked on open messeages.
==== Subtype 0 is required.

22
 param chksubtype 0
==== Determines whether TM/MP transaction should be started
==== and controlled by MQSI.
TMF ON indicates that MQSI
==== will control the TM/MP transaction.
TMF OFF indicates
==== that MQSeries will control the TM/MP transaction.
param TMF-FLG OFF
==== Determines whether the MQSeries interface should instruct
==== the queue manager to convert the message data on the MQGET
==== call.
If set ON the message will be converted to conform
==== to the CodeCharSetId and Encoding values specified in the
==== MQMD.
If set OFF no message conversion will occur.
Default
==== is OFF.
param CONVERT OFF
====
==== ******************Performance Impacts*********************
====
==== By turning the following flag ON please note that you will
==== incur a performance degradation for the ACI MQSeries Interface.
==== MQSI could be required to complete three API calls for every PUT
==== message as opposed to the one API call when the parameter is
==== turned OFF.
====
==== **********************************************************
====
==== REPLYTOQ param will be used to determine whether the ACI MQseries
==== Interface will PUT a message in the queue specified by the MQMD
==== ReplyToQ field or to the queue defined within the XPNET station
==== RADDR attribute.
====
==== If the param REPLYTOQ is OFF, MQSI will put the message on the
==== queue specified by the XPNET station RADDR attribute.
This will
==== require a single MQPUT API call.
This functionality is how MQSI
==== worked prior to the addition of the REPLYTOQ param.
====
==== If however the param REPLYTOQ is ON, MQSI will compare the MQMD
==== ReplyToQ field to the remote queue currently open.
If the two
==== are equivalent a MQPUT will be done to the queue.
If the two are
==== not equivalent, MQSI will MQCLOSE the current remote queue,
==== MQOPEN the MQMD ReplyToQ, and MQPUT the message on the queue
==== specified by the MQMD ReplyToQ.
Note there are three API calls
==== versus one API call with this configuration and this is the cause
==== of the performance degradation.
====
==== Default will be REPLYTOQ OFF.
====
param REPLYTOQ OFF
==== A FORMAT parameter has been added to the STRTMQSI file to enable
==== a mechanism to populate the Message Descriptor Format field to
==== the value required by the remote queue manager.
Uncomment the
==== desired FORMAT field below to activate the use of this feature.

23
 ====
==== param FORMAT "MQADMIN "
==== param FORMAT "MQCHCOM "
==== param FORMAT "MQCICS "
==== param FORMAT "MQCMD1 "
==== param FORMAT "MQCMD2 "
==== param FORMAT "MQDEAD "
==== param FORMAT "MQHDIST "
==== param FORMAT "MQEVENT "
==== param FORMAT "MQIMS "
==== param FORMAT "MQIMSVS "
==== param FORMAT "MQHMDE "
==== param FORMAT "MQPCF "
==== param FORMAT "MQHREF "
==== param FORMAT "MQHRF "
==== param FORMAT "MQHRF2 "
==== param FORMAT "MQSTR "
==== param FORMAT "MQTRIG "
==== param FORMAT "MQHWIH "
==== param FORMAT "MQXMIT "
==== To insure proper restart of the backup process, the IN, OUT and
==== STDERR files must be set to a valid static terminal or to a
==== terminal emulation process such as SUDOTERM or Tandem VHS.
==== There is no default for the ASSIGN STDERR below.
== assign STDERR, $SUDO
==== The following params are required by MQSeries for Tandem NSK.
param MQDEFAULTPREFIX $<vol>
param SAVE-ENVIRONMENT ON
param MQEMSEVENTS 127
==== The following params are required by MQSeries v5.3 or newer.
Once the
==== user has upgraded to MQ v5.3 or newer, the following params should be
==== uncommented and updated to reflect the appropriate VAR and OPT
==== directory.
Once the update is complete the user can obey
==== STRTMQSI.
== PARAM MQNSKVARPATH /usr/ibm/wmq/var/mqm
== PARAM MQNSKOPTPATH /usr/ibm/wmq/opt/mqm
==== The following param is required by MQSeries v8.0 or newer.
==== Once the user has upgraded to MQ v8.0 or newer, this param should be
==== uncommented and updated to reflect the appropriate MQ base directory.
== PARAM MQPATHTNS /usr/ibm/wmq
==== Run the process.
Priority should be between
==== the Tandem TCP/IP process and the XPNET process.
run [object] /name [ppd], nowait, out [stdout], pri 170 [cpu], highpin off, ter&
m $sudo/
#OUTPUT STARTED: [ppd]
#UNFRAME

Network configuration example 1

24
This example configuration depicts a scenario where there is one MQS channel and only one XPNET station
communicating over the single channel in full duplex mode. The diagram below shows that a single MQSI process is
started and there is one pair of MQS queues accessed.

Given the example shown in the previous figure the following Network settings would be used:

25
 RESET DEVICE
SET DEVICE RECVLEN 4096
SET DEVICE XMITLEN 4096
SET DEVICE INPUTFORMAT TXT
SET DEVICE OUTPUTFORMAT TXT
SET DEVICE POLLFORMAT “ ”
SET DEVICE SELECTFORMAT “ ”
SET DEVICE TYPE 0
ADD DEVICE D1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET LINE
SET LINE PORT $MQS01.#STA01
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL QMANAGER
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE L1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET STATION
SET STATION LINENAME \TEST.L1A^GATE.L1A^MQS01
SET STATION DEVICE D1S^MQS01
SET STATION DESTINATION P1A^MQSAPPL
SET STATION LADDR CFS_LOCAL_QUE01
SET STATION RADDR CFS_REMOTE_QUE01
ADD STATION S1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE

Network configuration example 2

26
This example configuration depicts a scenario where there is one MQS channel and two XPNET stations
communicating over the single channel in full duplex mode. The diagram below shows that a single MQSI process is
started and there is one pair of MQS queues established for each station.

Given the example shown in the previous figure the following Network Environment File settings would be used:

27
 RESET DEVICE
SET DEVICE RECVLEN 4096
SET DEVICE XMITLEN 4096
SET DEVICE INPUTFORMAT TXT
SET DEVICE OUTPUTFORMAT TXT
SET DEVICE POLLFORMAT “ ”
SET DEVICE SELECTFORMAT “ ”
SET DEVICE TYPE 0
ADD DEVICE D1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET LINE
SET LINE PORT $MQS01.#STA01
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL QMANAGER
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE L1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET LINE
SET LINE PORT $MQS01.#STA02
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL QMANAGER
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE L1A^MQS02, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET STATION
SET STATION LINENAME \TEST.P1A^GATE.L1A^MQS01
SET STATION DEVICE D1A^MQS01
SET STATION DESTINATION P1A^MQSAPPL^01
SET STATION LADDR CFS_LOCAL_QUE01
SET STATION RADDR CFS_REMOTE_QUE01
ADD STATION S1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET STATION
SET STATION LINENAME \TEST.P1A^GATE.L1A^MQS02
SET STATION DEVICE D1A^MQS01
SET STATION DESTINATION P1A^MQSAPPL^02
SET STATION LADDR CFS_LOCAL_QUE02
SET STATION RADDR CFS_REMOTE_QUE02
ADD STATION S1A^MQS02, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE

Network configuration example 3

This example configuration depicts a scenario where there is one MQS channel and two XPNET stations
communicating over the single channel in full duplex mode. The diagram below shows that two MQSI processes are
started and there is one pair of MQS queues established for each station.

28
Given the example shown in the previous figure the following Network Environment File settings would be used:

29
RESET DEVICE
SET DEVICE RECVLEN 4096
SET DEVICE XMITLEN 4096
SET DEVICE INPUTFORMAT TXT
SET DEVICE OUTPUTFORMAT TXT
SET DEVICE POLLFORMAT “ ”
SET DEVICE SELECTFORMAT “ ”
SET DEVICE TYPE 0
ADD DEVICE D1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET LINE
SET LINE PORT $MQS01.#STA01
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL QMANAGER
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE L1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET LINE
SET LINE PORT $MQS02.#STA02
SET LINE PROTOCOL CTS
SET LINE DUPLEX FULL
SET LINE LAPPL QMANAGER
SET LINE CMETHOD ALLOCATE
SET LINE SENDCONFIRM REQUEST
SET LINE FMM ALL
SET LINE EXPDATA DISCARD
SET LINE CINIT IMMEDIATE
SET LINE ATIMER 0
ADD LINE L1A^MQS02, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET STATION
SET STATION LINENAME \TEST.P1A^GATE.L1A^MQS01
SET STATION DEVICE D1A^MQS01
SET STATION DESTINATION P1A^MQSAPPL^01
SET STATION LADDR CFS_LOCAL_QUE01
SET STATION RADDR CFS_REMOTE_QUE01
ADD STATION S1A^MQS01, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE
RESET STATION
SET STATION LINENAME \TEST.P1A^GATE.L1A^MQS02
SET STATION DEVICE D1A^MQS01
SET STATION DESTINATION P1A^MQSAPPL^02
SET STATION LADDR CFS_LOCAL_QUE02
SET STATION RADDR CFS_REMOTE_QUE02
ADD STATION S1A^MQS02, UNDER SYSNAME \TEST, UNDER NODE P1A^GATE

30