| Author |
Message
|
| pakelika187 |
 Posted: Thu Apr 22, 2010 8:51 am Post subject: MQ RC = 2018 Hconn error |
 |
|
Newbie
Joined: 22 Apr 2010
Posts: 5
|
We created a batch program which worked fine but now we are trying to transition that same program to be triggered using CICS. The program does the following:
program 1 - mqconn/mqopen (queue 04)/mqopen (queue 05)/mqget (queue 04)/ call program 2
program 2 - process data (new call) call program 3
program 3 - mqput (queue 05) (using passed connection data, such as the HCONN variable) / return to program 1
program 1 - mqclose (queue 04)/mqclose (queue 05)/mqdisc
When the program gets triggered it is able to read and process the message but it is not able to do a put to the new queue 05 due to a reason code 2018 (MQRC_HCONN_ERROR).
Is this 2018 an issue with the connection handles being passed and not being able to do so from a CICS? Or is there something else being missed?
I have attempted to do the following:
program 1 - mqconn/mqopen (queue 04)/mqget (queue 04)/mqclose (queue 04)/mqdisc/ call to program 2
program 2 - /process data /call to program 3
program 3 - /mqconn/mqopen (queue 05)/ mqput (queue 05) /mqclose (queue 05)/mqdisc
But not only did this cause a loop of system dumps but also doesnt seem logical to open/close and only retrieve one message at a time. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Apr 22, 2010 9:27 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
So, you now have a cics app that issues an mqconn call?
MQCONN calls within a cics app are ignored. It is the mq-cics adapter that issues the mqconn call.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 22, 2010 9:28 am Post subject: Re: MQ RC = 2018 Hconn error |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pakelika187 wrote: |
| Is this 2018 an issue with the connection handles being passed and not being able to do so from a CICS? Or is there something else being missed? |
Yes - that won't work on CICS and is not good practice on other platforms (where it may not work - wherever it's running now seems to have fluked it).
| pakelika187 wrote: |
I have attempted to do the following:
program 1 - mqconn/mqopen (queue 04)/mqget (queue 04)/mqclose (queue 04)/mqdisc/ call to program 2
program 2 - /process data /call to program 3
program 3 - /mqconn/mqopen (queue 05)/ mqput (queue 05) /mqclose (queue 05)/mqdisc
But not only did this cause a loop of system dumps but also doesnt seem logical to open/close and only retrieve one message at a time. |
No, it's neither logical nor efficient
One question is why do you connect & disconnect between messages? Why not have the descedent programs hold their own connection handles between calls?
I also have to ask why you're not using intermediate queues to decouple the programs or if these programs are a single UOW why were they designed like this??? If you were reading records from a file you wouldn't pass file handles round like this.
What exactly is the design imperative here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 9:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Read in the APR and APG about scope of connection handle.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| pakelika187 |
| Posted: Thu Apr 22, 2010 10:09 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2010
Posts: 5
|
I was under the assumption that in order for the new program that was called to connect to the queue manager that the cics program needed to be disconnected. I was also under the impression that the mqconn could just be left in a cics program with no issues.
Why i created these programs like this..... due to the middle program (program 2) that is called is a supplied software that I am attempting to only alter a bit (such as removing the ability/need to read a file and change that to read a message). So incase of a change to the supplied software it would be easy to make those same changes to the homebrewed software.
Being a complete newbie I am also a bit confused if/how cobol is able to pass some data (1mb) to be processed and have the output data (1mb) returned to the calling (cics) program. The cics program would then combine the original message with the new output data (2mb) and put that to the new queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 22, 2010 10:16 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pakelika187 wrote: |
| I was under the assumption that in order for the new program that was called to connect to the queue manager that the cics program needed to be disconnected. I was also under the impression that the mqconn could just be left in a cics program with no issues. |
Don't assume - read the product documentation. That's doesn't work in CICS, and shouldn't be attempted in other situations. Each application (or thread) should have it's own connection
| pakelika187 wrote: |
| Why i created these programs like this..... due to the middle program (program 2) that is called is a supplied software that I am attempting to only alter a bit (such as removing the ability/need to read a file and change that to read a message). So incase of a change to the supplied software it would be easy to make those same changes to the homebrewed software. |
Clearly I don't know the details, but there has to be an easier way. I'd go with intermediate queues myself as a first guess.
| pakelika187 wrote: |
| Being a complete newbie I am also a bit confused if/how cobol is able to pass some data (1mb) to be processed and have the output data (1mb) returned to the calling (cics) program. The cics program would then combine the original message with the new output data (2mb) and put that to the new queue. |
See my comment above.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pakelika187 |
| Posted: Thu Apr 22, 2010 10:22 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2010
Posts: 5
|
Being I have just started with MQ could you describe or make a quick example of what you mean by intermediate queues I can then run said option pass the others?
Basically what needs to be done is one queue must trigger the program to get the message and process it through supplied software (numerous calls and database transactions) and then the original message and the new output need to be combined and put to a new queue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 10:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
You seem to be attempting a multi-legged application.
An example might be a banking app for someone applying for credit. One requst (for credit) message is placed in a RequestQueue, and the app waits for replies on a single reply-to-queue.
The consuming app gets the message, determines that several separate processes are needed (employment verification, credit history, loan collateral asset valuation), and puts a message for each separate process in a separate queue (one queue for employment verification, etc.).
Each of these messages is processed by a separate app; and each puts a reply message in an intermediate ResultsQueue. A results app accumulates the separate intermediate replies, and puts a message to the reply-to-queue the requesting app creates.
This all looks better in graphic form; but what you have is separate asynchronous processes responding to a single initiating application message.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| pakelika187 |
| Posted: Thu Apr 22, 2010 11:23 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2010
Posts: 5
|
I do have concerns with developing our system like that. We are basically asked to make very little changes on our system (IBM) being that we are supplied with a 98% of the software and infrastructure specifications. With the other 2 % being the movement from IBM to Unisys and back to IBM to continue processing. I did come across some information that made me think....
I attempted to use just the supplied software that gets triggered and recieved the same RC = 2018. This then made me think it wasnt quite the passing but perhaps the way the mqput program is compiled.
So question... even though the mqput program is not the calling program that gets triggered and has CICS exec statements in them, should this program still be compiled as if it is a CICS MQ program with the CSQCSTUB? |
|
| Back to top |
|
|
| pakelika187 |
| Posted: Thu Apr 22, 2010 11:28 am Post subject: |
|
|
Newbie
Joined: 22 Apr 2010
Posts: 5
|
| Quote: |
| So question... even though the mqput program is not the calling program that gets triggered and has CICS exec statements in them, should this program still be compiled as if it is a CICS MQ program with the CSQCSTUB? |
Sorry the MQPUT program does NOT have any CICS exec statements. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 11:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
An application issuing mq calls from within a cics environment must be linked with csqcstub.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 12:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
I have attempted to do the following:
program 1 - mqconn/mqopen (queue 04)/mqget (queue 04)/mqclose (queue 04)/mqdisc/ call to program 2
program 2 - /process data /call to program 3
program 3 - /mqconn/mqopen (queue 05)/ mqput (queue 05) /mqclose (queue 05)/mqdisc |
Why have you created 3 programs to accomplish this?
Why can't you do this in one program?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Apr 22, 2010 12:22 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I was under the assumption that in order for the new program that was called to connect to the queue manager that the cics program needed to be disconnected. I was also under the impression that the mqconn could just be left in a cics program with no issues. |
Your assumptions are incorrect. You need to read the relevant sections of the APR and APG, that deal with MQCONN, MQDISC, CICS-MQ application coding.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
