MQSeries for Compaq OpenVMS Alpha uses the DECnet SNA APPC/LU 6.2 Programming Interface. This interface requires access through DECnet to a suitably configured SNA Gateway, for example, the SNA Gateway-ST, or SNA Gateway-CT.
To enable WebSphere MQ to work with DECnet APPC/LU 6.2 you must complete your Gateway SNA configuration first. The Digital SNA configuration must be in agreement with the Host SNA configuration.
Notes:
To configure your SNA Gateway, set up the SNAGATEWAY_<node>_SNA.COM file,
where <node> is replaced with the node name of your DECnet SNA gateway.
Do this by responding to the configuration prompts in the Gateway installation procedure, or by directly editing the file.
The SNA Gateway installation procedure creates the file in the directory SYS$COMMON:[SNA$CSV].
The configuration information in this file is downloaded to the Gateway when you run the NCP LOAD NODE command.
Notes:
A sample SNA Gateway Configuration file follows:
$!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ $! Start of file: SYS$COMMON:[SNA$CSV]SNAGATEWAY_SNAGWY_SNA.COM $! DECnet SNA Gateway-ST SNA configuration file $! Created: 23-FEB-1996 19:10:43.68 by SNACST$CONFIGURE V1.2 $! Host node: CREAMP User$ CHO $!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ $ v = f$verify(1) $ RUN SYS$SYSTEM:SNANCP SET LINE SYN-0 - // Line definition DUPLEX FULL - PROTOCOL SDLC POINT - SIGNALLING NORMAL - CLOCK EXTERNAL - MODEM TYPE NORMAL - RECEIVE BUFFERS 34 - LOGGING INFORMATIONAL - BUFFER SIZE 265 SET CIRCUIT SDLC-0 - // Circuit definition LINE SYN-0 - DUPLEX FULL - RESPONSE MODE NORMAL - STATION ADDRESS C1 - LOGGING INFORMATIONAL - STATION ID 0714002A // XID SET PU SNA-0 CIRCUIT SDLC-0 - LU LIST 1-32 - SEGMENT SIZE 265 - // must equal MAXDATA on Host PU definition LOGGING WARNING SET CIRCUIT SDLC-0 STATE ON SET LINE SYN-0 STATE ON SET SERVER SNA-ACCESS - LOGGING WARNING - NOTE "Gateway Access Server" - STATE ON SET ACCESS NAME VTAMSDR PU SNA-0 LU 2 APPL MVSLU LOGON LU62SS SET ACCESS NAME VTAMRCVR PU SNA-0 LU 3 APPL MVSLU LOGON LU62SS $ EXIT $STATUS + (0 * 'f$verify(v)') $!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ $! End of file: SYS$COMMON:[SNA$CSV]SNAGATEWAY_SNAGWY_SNA.COM $!+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
You should set up a separate Access name for each WebSphere MQ channel. This ensures that the VMS system and the remote system agree on the LU used for the channel.
The access name is used only to communicate between the DECnet SNA APPC program and the Gateway. It has no network meaning.
Notes:
IYA8L007 LINE ADDRESS=(007,FULL),
ISTATUS=ACTIVE
IYA8P307 PU ADDR=C2,
ISTATUS=ACTIVE,
IRETRY=NO,
MAXDATA=521,
MAXOUT=7,
PASSLIM=7,
PUTYPE=2
IYA83071 LU LOCADDR=2,PACING=1,DLOGMOD=LU62CP1
IYA83072 LU LOCADDR=3
LU62SS MODEENT LOGMODE=LU62SS,
TYPE=0, ONLY TYPE RECOGNIZED
FMPROF=X'13', SNA
TSPROF=X'07', SNA
PRIPROT=X'B0', PRIMARY PROTOCOL
SECPROT=X'B0', SECONDARY PROTOCOL
COMPROT=X'50B1', COMMON PROTOCOL
SSNDPAC=X'00',
SRCVPAC=X'00',
RUSIZES=X'8989', RUSIZES IN-4096 OUT-4096
PSNDPAC=X'00',
PSERVIC=X'060200000000000000002C00',
The DECnet SNA Gateway Guide to IBM Parameters details the parameters expected by the Gateway.
WebSphere MQ obtains knowledge of the SNA resources by passing the Gateway Node name and the Access name to the channel program.
For sender and requester channel pairs specify the Gateway Node and Access Name in the CONNAME string in the channel definition.
The CONNAME also includes the TPNAME that is used by the SNA Allocate verb to invoke the remote program.
The format of the CONNAME is: CONNAME('GatewayNode.AccessName(TpName)').
For example: CONNAME('SNAGWY.VTAMSDR(MQSERIES)'), where SNAGWY is the Gateway node, VTAMSDR is the access name, and WebSphere MQ is the TPNAME.
Senders, requesters, and fully qualified servers can be explicitly run by performing a START CHANNEL command in runmqsc.
Senders and requesters on Compaq OpenVMS Alpha initiate a session by issuing an INIT-SELF to request a BIND from the host. In issuing the Allocate verb, the WebSphere MQ channel program takes the LU name and the Mode Name from the Access Name.
WebSphere MQ then allocates a conversation using the specified TPNAME.
For servers and receivers, specify the Gateway Node, Access Name, and TPNAME as command line parameters to the runmqlsr command.
Servers and receivers are started by running the runmqlsr command.
$ RUNMQLSR -m QMname -n TPname -g GatewayNode(AccessName)
You can include these commands in the WebSphere MQ startup file, SYS$STARTUP:MQS_STARTUP.
Receivers and servers issue the ACTIVATE_SESSION request to the Gateway in passive mode. In passive mode the channel program waits for a BIND from the remote system, which puts the LU into the active-listening state, waiting for a bind from the host.
You can check the LU status using SNANCP to make sure that you are in active-listening state on the correct LU. If a BIND from the host arrives specifying the LU that is in active-listening state, the session will be established. After establishing the session, the host attempts to allocate a conversation.
The TPNAME used by the host sender/requester channel must be the same name as that specified on the command line in order to establish the conversation.
To find the batch job number for the SNA listener process, type: $ show queue / all
To end the SNA Listener process type:
$ delete /entry=<jobnumber>
where <jobnumber> is the job number of the listener batch job.
*
* channel configuration for saturn.queue.manager for LU6.2
*
def ql('HOST_SENDER_TQ') usage(xmitq)
def chl('HOST.TO.VMS') chltype(rcvr) trptype(lu62) +
seqwrap(999999999)
def chl('VMS.TO.HOST') chltype(sdr) trptype(lu62) +
conname('SNAGWY.VTAMSDR(MQSERIES)') +
xmitq('HOST_SENDER_TQ') seqwrap(999999999)
In this example two channels, a sender and a receiver, have been set up.
On the remote system you need to configure the corresponding channels. Channels that talk to each other must have the same name.
The commands to start each channel are:
// Start sender channel to host system $ runmqchl -m "saturn.queue.manager" -c "VMS.TO.HOST" // Set up listener to lesten for incoming SNA requests. $ runmqlsr -m "saturn.queue.manager" -n "TPNAME" -g SNAGWY(VTAMRCVR)
SIDELETE DESTNAME(ID1) SIADD DESTNAME(ID1) MODENAME(LU62SS) TPNAME(MQSERIES) PARTNER_LU(IYA83072)
Error PUNOTAVA - PU has not been activated
This error indicates a lack of connectivity between the two machines. Make sure your line and circuit are set to state ON. Use SNATRACE at the circuit level to verify that the Compaq OpenVMS Alpha machine is polling. If no response is received for the poll, check that the PU on the host is enabled. If the line will not go to the ON STATE check your physical line. If the trace shows the host responding to the poll, but the PU still does not become active, check your setting of the STATION ID.
Failure to allocate conversation
This error is returned by a sender or requester to indicate that allocate failed. Run trace to verify that the session can be established. Verify that the Compaq OpenVMS Alpha machine sends the INIT-SELF (010681). If there is no response to the INIT-SELF make sure that the host WebSphere MQ channel is started. If the BIND from the host is rejected by the Compaq OpenVMS Alpha machine analyze the Digital bind response. Use the DECnet SNA Gateway Guide to IBM Parameters to see what is set incorrectly in the mode. If a session is established and the conversation allocate request is rejected verify that the TPNAMEs are configured the same on both systems.
For receivers and servers verify that a BIND is sent by the host. If not, enable the Host WebSphere MQ channel. If the BIND is rejected check the reason for rejection. Make sure that the Compaq OpenVMS Alpha listener LU is the LU with which the host is trying to establish a session.
WebSphere MQ connection failure
After establishing a conversation the two WebSphere MQ channels engage in a protocol to establish a WebSphere MQ channel connection. If this fails, the reason for failure should be indicated in the error logs on the two systems. Check both logs and correct the indicated problem. For example the connection fails if one system has a SEQWRAP value of 999999999 and the other 999999. In the SNATRACE you will see that the allocate succeeded and that MQ is trying to establish a channel connection. At this point the WebSphere MQ logs are the best aid in resolving problems.