|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
AMQSPUT0 works fine, but AMQSPUT4 sample code get 2018 |
« View previous topic :: View next topic » |
Author |
Message
|
tetra |
Posted: Sat Jul 30, 2011 12:59 am Post subject: AMQSPUT0 works fine, but AMQSPUT4 sample code get 2018 |
|
|
Newbie
Joined: 29 Jul 2011 Posts: 4
|
Hi guys,
I also have problem with RC2018 (2018, X'7E2') Connection handle not valid. My environment is OS/400 (5724H72) WebSphere MQ for i5/OS installed on 2 machine (v5r2 and v6r1). They are connected to each other. I can send and get message through the local and remote queue between the 2 machine, vice versa, using the sample program AMQSPUT0 and AMQSGET4 from library QMQM.
When I try to use application to send message in machine v5r2, the MQCONN and MQOPEN can be run successfully. Unfortunately, using the same application running in machine v6r1, the MQCONN to the queue manager is successful, but the MQOPEN returns the reason code 2018. The same reason for any queue, local or remote.
So I try to use another sample code AMQSPUT4 from lib QMQMSAMP. It turns to reason code 2018 for the MQOPEN. The value of HConn using for the MQOPEN is 2, resulted from MQCONN. FYI, I compile the rpg caller program using ACTGRP(*CALLER). Is this has the relevancy with the scope of the conn handle? May the configuration of the queue is wrong?
Here's the spool file of using the AMQSPUT4
File . . . . . : QSYSPRT
Sample AMQ3PUT4 start
Target queue is ABL.LQ
Target queue manager is ABL.QUEUE.MANAGER
MQOPEN ended with reason code 0000002018
Unable to open queue for output
MQPUT ended with reason code 0000002018
MQPUT ended with reason code 0000002018
MQPUT ended with reason code 0000002018
Sample AMQ3PUT4 end
Any comments would be very helpful. Thank you.  |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Jul 30, 2011 7:17 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Looking at the reasons for a 2018 and assuming that the connection sharing stuff etc has been taken care of, have you considered this:
Quote: |
The conversion program is not defined as OPENAPI, when the MQXCNVC call is invoked by running a character conversion exit program with CICS® TS 3.2 or higher. When the conversion process runs, the TCB is switched to the Quasi Reentrant (QR) TCB, making the connection incorrect. |
Which of the following steps did you do?
Quote: |
Programmer response
Ensure that a successful MQCONN or MQCONNX call is performed for the queue manager, and that an MQDISC call has not already been performed for it. Ensure that the handle is being used within its valid scope (see the description of MQCONN in the STARTENTCITcit bibid="csq03"ENDENTCIT).
* On z/OS®, also check that the application has been linked with the correct stub; this is CSQCSTUB for CICS applications, CSQBSTUB for batch applications, and CSQQSTUB for IMS™ applications. Also, the stub used must not belong to a release of the queue manager that is more recent than the release on which the application is to run.
Change the conversion program definition to API(OPENAPI), to prevent the TCB switching to the QR TCB. The MQGET then completes normally because the conversion routine runs on the L8 TCB. |
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
tetra |
Posted: Mon Aug 01, 2011 8:32 pm Post subject: |
|
|
Newbie
Joined: 29 Jul 2011 Posts: 4
|
Thank you for the reply fjb_saper,
The conversion program is not defined as OPENAPI, when the MQXCNVC call is invoked by running a character conversion exit program with CICS® TS 3.2 or higher. When the conversion process runs, the TCB is switched to the Quasi Reentrant (QR) TCB, making the connection incorrect. -> is this also valid for AS/400 environment? Should I make any conversion program? Shouldn't it just be configured in the sender channel with attribute CVTMSG *YES?
Ensure that a successful MQCONN or MQCONNX call is performed for the queue manager, and that an MQDISC call has not already been performed for it. -> OK, Checked
Ensure that the handle is being used within its valid scope -> CMIIW, for AS.400 the scope is the job calling the program. Yes, it's not being passed from any prog / proc.
On z/OS®, also check that the application has been linked with the correct stub; this is CSQCSTUB for CICS applications, CSQBSTUB for batch applications, and CSQQSTUB for IMS™ applications. Also, the stub used must not belong to a release of the queue manager that is more recent than the release on which the application is to run. -> not do it.
Change the conversion program definition to API(OPENAPI), to prevent the TCB switching to the QR TCB. The MQGET then completes normally because the conversion routine runs on the L8 TCB. -> I have no conversion program. Assume that I have to make conversion prog, where should I put it? Anyway, it's for the MQGET, is it?
Sorry for the late reply, it's newbie here, need to read a lot to understand  |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Aug 02, 2011 5:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
From your postings it looks very much like you need to get the help from an experienced SYSPROG on AS400, who will know which parts of the zOS instructions will still be relevant. Don't be shy, go ask for help!  _________________ MQ & Broker admin |
|
Back to top |
|
 |
tetra |
Posted: Tue Aug 02, 2011 5:41 pm Post subject: |
|
|
Newbie
Joined: 29 Jul 2011 Posts: 4
|
Thank you for the advice  |
|
Back to top |
|
 |
tetra |
Posted: Wed Aug 03, 2011 8:07 pm Post subject: [SOLVED] AMQSPUT0 works fine, but AMQSPUT4 sample code get |
|
|
Newbie
Joined: 29 Jul 2011 Posts: 4
|
Quote: |
WebSphere MQ for i5/OS, V7.0 supports the following compilers, which are all
part of the IBM WebSphere Studio Development Suite for System i, part number
5722WDS:
v IBM Integrated Language Environment® C for iSeries®
v IBM Integrated Language Environment C++ for iSeries
v IBM Integrated Language Environment COBOL for iSeries
v IBM Integrated Language Environment RPG for iSeries |
Just find out that the compiler in AS400 v6r1 is 5761WDS. So, I compile the AM3PUT4 sample program in v5r2, who has the 5722WDS compiler.
Restore the object into v6r1 machine, then it works fine.. Hope this will be useful for other  |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|