| Author |
Message
|
| cian |
 Posted: Thu Feb 26, 2004 10:08 am Post subject: zOS s6c6 abend |
 |
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
hi all,
i have RTFM (but there is a lot of them so i may have missed the obvious!) so i would appreciate it if any experts out there can guide me.
i am running a simple started task which does the following:
1)MQCONN
2)MQOPEN on the qmgr
3)MQINQ on the qmgr object
4)MQSEND (as many as 500 times)
5)MQCLOS
6)MQDISC
the MQCLOS call fails with a reason code:
MQRC_CONNECTION_BROKEN (2009, X'7D9') Connection to queue manager lost.
when i terminate the proc via the console i get a s6C6 abend with code 00F30905.
If i remove step 4) i get the same results.
If i remove steps 4), 5) & 6) i still get the s6C6 but with a code of 00F0901
what expecially mystifies me is that the reson code from the MQCLOS suggests that my hCon has gotten corrupted, but it appears to work fine for all the MQSEND calls if i include them.
i'm running zOS 1.4 & MQ Series V5R3 .
i hope this is all as a result of my idiocy and will happily suffer the ridicule of this esteemed forum if someone out there can help.
brgds
cian |
|
| Back to top |
|
 |
| offshore |
| Posted: Thu Feb 26, 2004 12:36 pm Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
cian,
Is the MQ Series subsystem terminating?
I've had this <I think it was 6C6 anyways>, but the BSDS or PAGEDS got corrupted.
As far as an application causing it....never seen that happen yet. Most everything I've read says the MQ Series subsystem abends.
One more thing...does message CSQV086E appear on the console?
HTH |
|
| Back to top |
|
|
| cian |
| Posted: Fri Feb 27, 2004 1:38 am Post subject: |
|
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
thks HTH.
no. the MQ subsystem remains up and active. It is my started task that falls over on the s6c6.
IEF402I RISREPTO FAILED IN ADDRESS SPACE 03DF 574
SYSTEM ABEND S6C6 - REASON CODE F30905
$HASP310 RISREPTO TERMINATED AT END OF MEMORY
(risrepto is my started task). i can continue to talk to the queue manager after this failure. the 00F30905 explanation in the Messages & Codes is a bit ambiguous but seems to imply that it is the application task that gets killed, which is what i see.
i don't get the CSQV086E message either.
i think the MQCLOS returning MQRC_CONNECTION_BROKEN (2009, X'7D9') is the real issue and the s6c6 is just a secondary symptom.
for further information i have another application on the far side of the queue which works fine, although it essentially is doing the same set of MQ calls. the only difference i can see between this application and the failing one is that the failing one is running from an APF authorised library. i see no reference to this in the manuals so i don't imagine this is relevant, but ...?
brgds,
cian |
|
| Back to top |
|
|
| cian |
| Posted: Fri Feb 27, 2004 1:45 am Post subject: |
|
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
also,
i've just reread my initial post and noticed that i omitted between steps 3 & 4 an MQOPEN & MQINQ on the actual queue.
brgds,
cian |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Feb 27, 2004 2:01 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
You need to raise a problem with the IBM support centre for a problem like this. It way well require analysis of the dumps that should have been produced by the Abend and other messages on the system log.
The reason codes on your dump imply your job is going through Address space memory termination but that is probably due to you cancelling it from the console.
Why do you need to cancel it, doesn't it fall through to normal end after the Close and Disc calls?
The obvious thing to check is that the HCONN on close really is the same as that used on the other calls
When you say MQSEND I assume you mean MQPUT.
Abends 5C6 and 6C6 are generic abends that MQ produces in a variety of situations. It is only valid to compare the causes of two 6C6 abends if the have the same reason code associated with them.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| cian |
| Posted: Fri Feb 27, 2004 3:11 am Post subject: |
|
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
thks bob,
the application is part of a bigger which will wait for work to do. in this case, to simplify analysis i have generally not submitted the jobs which would cause the MQPUTs to be done (sorry about the MQSEND) and so the application just sits there until i /p it from the console.
what i see if i do submit the job that causes the MQPUTs to be done is that all messages are correctly transmitted to the queue.
then i do a /p on the started task to bring it all down, which is when i get the MQCLOSE failure with the 7D9 reason code. the job subsequently dies on the s6c6. so, you're saying that this mechanism of bringing doen the application may cause the s6c6? that's something i can certainly look into.
btw, i NOP'd the MQCLOSE & MQDISC calls and the job carried on to a s6c6 but this time with an 00F30901 code. but perhaps this is all a detour caused by the fact that it is not valid to do a /p on the whole applciation.
but my real interest is in looking at the x7D9 return from the MQCLOSE. the manual implies that the HCONN is corrupted at some point between the MQOPEN & MQCLOSE.
so i put in some diagnostics to capture the 1st 100bytes of what HCONN points at just after the MQOPEN and then i forced an s0C1 as soon as the close fails. comparing these areas in the dump they are identical for x60 bytes which seems ok to me, but then again i don't know how long this area should be? can i see a DSECT somewhere?
brgds,
cian |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Fri Feb 27, 2004 4:00 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Do your Close and Disc work if placed immediately after the Puts without waiting for the application to be shut down from the console?
Does your application involve subtasking? I am thinking that possibly your job step TCB is terminating, causing MQ to clean up connections before your application task has completed closing queues.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| cian |
| Posted: Fri Feb 27, 2004 5:33 am Post subject: |
|
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
i haven't tried that yet, but i did put a close immediately after the open and it worked fine. i expect the close and disc after the put will work too.
the application does involve subtatsks but we've satisfied ourselves that the open and close are being issued from the same task in the same key in the same state etc. we will recheck all this again.
brgds,
cian |
|
| Back to top |
|
|
| cian |
| Posted: Wed Mar 03, 2004 3:06 am Post subject: |
|
|
Newbie
Joined: 26 Feb 2004
Posts: 6
Location: Cill Mhantáin
|
hi all,
we found our problem. the cross memory setup had changed as part of the cleanup done after the /p before we got around to the MQCLOSE & MQDISC. we reordered the cleanup and the 7D9 return code went away, and with it the s6c6 abend.
thks to bob and hth for the input.
brgds,
cian |
|
| Back to top |
|
|
|
|
