Using MQSeries with NonStop Tuxedo 6.5.3

mqsputcl, tmqsputcl, and mqsputserv
mqsputcl, tmqsputcl, and mqsputserv are basically the inverse of mqsgetcl, tmqsgetcl, and
mqsgetserv. So instead of retrieving a string off the MQSeries queue and downshifting and
returning it to the client, a string argument is taken, up shifted, and added to the MQSeries
queue. As with the "get" versions, "TPABORT-MQSPUTSERV" and
"TPABORT-MQSPUTCL" can be used to cause the server and client respectively to abort the
transaction, thus removing the newly added message from the queue.
To test the various paths do the following:
mqsputcl "msg #1"
mqsputcl tpabort-mqsputserv
mqsputcl tpabort-mqsputcl
amqsget SYSTEM.DEFAULT.LOCAL.QUEUE QMNAME
Running each mqsputcl causes the message to be up shifted, added to the queue,
and returned to the client to be written to stdout. Running amqsget then removes
and displays the messages.
Run the same test above, but this time use "tmqsputcl" instead of "mqsputcl". This
time only the first message will be returned by amqsget. The second and third test
cases cause the server and client respectively to abort the transaction so the
message is removed from the queue.
Conclusion
The primary purpose of this effort was to prove that the MQSeries and NonStop TUXEDO
libraries could co-exist in the same process. The simple programs provided prove the libraries
can work together. The samples shouldn’t be viewed as best coding practices, nor do they prove
every possible combination of MQSeries and NonStop TUXEDO works together. However, the
experience does tend to indicate that any failure based on using additional features of either
product is more likely an implementation issue than a product incompatibility. For example,
forgetting to have MQDEFAULTPREFIX set in the ENVFILE when a NonStop TUXEDO
server is booted, or not using the correct userid to start the client or server.