| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| getting occassional 2012 with DB2 COBOL stored procedure |
« View previous topic :: View next topic » |
| Author |
Message
|
| smuktineni |
 Posted: Mon Jan 17, 2005 1:20 pm Post subject: getting occassional 2012 with DB2 COBOL stored procedure |
 |
|
Apprentice
Joined: 28 Aug 2003
Posts: 33
Location: Omaha
|
Hi all,
We have a DB2 COBOL stored procedure which connects to MQ 5.3, both on OS/390. The procedure has been working good for about 2 years and now we are seeing 2012 errors occasionally. We observed that the procedure works again if we bind it or sometimes compile the JCL and Bind or sometimes DROP and Bind the procedure!
There is no sequence as to why it breaks and a Bind works and we can't recreate the situation.
FYI... our procedures are running in DB2 WLM-managed Stored Procedure address space and we are using the library CSQBSTUB.
It appears as though that when the procedure is failing, it’s trying to use the RRS MQ Adapter  .
I am a novice in COBOL. Any idea why this is happening and how can we prevent it??
Thanks in advance.
Satish  |
|
| Back to top |
|
 |
| tillywern |
| Posted: Fri Jan 21, 2005 8:53 am Post subject: |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
$mqrc 2012
2012 0x000007dc MQRC_ENVIRONMENT_ERROR
From the Messages and Codes:
2012 MQRC_ENVIRONMENT_ERROR X'7DC' Call not valid in environment.
The call is not valid for the current environment.
* On MVS/ESA, the MQCMIT and MQBACK calls (and also their alternatives CSQBBACK and CSQBCMIT) cannot be issued in the CICS or IMS environment.
* On OS/2, UNIX platforms, and Windows NT, one of the following applies:
o The application is linked to the wrong libraries (threaded or nonthreaded).
o An MQBEGIN, MQCMIT, or MQBACK call was issued, but an external unit-of-work manager is in use or the queue manager does not support units of work.
o The MQBEGIN call was issued in an MQ client environment.
* On OS/400, this reason code does not occur.
Corrective action: Remove the call from the application.
On MVS/ESA, for a CICS or IMS application, issue the appropriate CICS or IMS call instead.
My input:
There are a couple of thing that could be going on and I am no expert in CICS but might be able to provide some insite.
1. On mainframes DB2 and MQ are in different subsystems. There might be an intermittent issue with access between them.
2. If XA or somethign equivelant is enabled there may be an issue with the transaction being started or stopped.
I believe that I saw similar issues with DataStage when their MQ patches were not added correctly. This might be why the problems are resolved with a DB2 bind.
Sorry I can't be of more assistance. |
|
| Back to top |
|
|
| smuktineni |
| Posted: Fri Jan 21, 2005 8:44 pm Post subject: |
|
|
Apprentice
Joined: 28 Aug 2003
Posts: 33
Location: Omaha
|
Thanks for your insight. We are assuming that the connection time required to connect to the MQ adapter by the stored procedure was not sufficient enough and the procedure was terminating before the MQ connection could be established. So the ASU time limit for the procedure was increased to 3 CPU cycles for test purposes. It was set to 0.3 cpu cycles earlier. After increasing the time limit, we are not seeing the issue any more. The procedure is under observence and this trick seems to be a permanent solution.
I didn't give the exact description for ASU time, but thats something related to the number of CPU cycles/time alloted for the procedure execution during runtime.
Will update the post if required.
Thanks
Satish |
|
| 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
|
|
|
|
