ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » MQDISC/COBOL problem

Post new topic  Reply to topic
 MQDISC/COBOL problem « View previous topic :: View next topic » 
Author Message
bigdavem
PostPosted: Mon Jul 28, 2003 10:44 pm    Post subject: MQDISC/COBOL problem Reply with quote

Acolyte

Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia

We've just upgraded from MQ 5.2 to MQ 5.3 and the following error has begun appearing in all our COBOL MQ programs:

Execution error : file '/apps/testa/bin/UBH146.gnt'
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)

The error occurs when we call MQDISC. A sample of the code is below:

Code:
05  mq-status-code          pic s9(9) binary.
05  mq-reason-code          pic s9(9) binary.
05  mq-qmgr                 pic x(48).
05  mq-hconn                pic s9(9) binary.
05  w-lk-qmgrname           pic x(48).

05  mqfn-mqdisc             pic x(8) value "MQDISC ".
05  mqco-none               pic s9(9) binary value 0.


********* Connect
move w-lk-qmgrname          to mq-qmgr.

call mqfn-mqconn using mq-qmgr
                       mq-hconn
                       mq-status-code
                       mq-reason-code
    on exception
        move "Call to =MQCONN= program failed"
                            to lkx001-error-message
        move lkx001-error-message
                            to w-unix-msg
        perform z9100-error
        perform z9200-unix-log
        exit section
end-call.

********* Disconnect
move mqco-none      to mq-status-code,
                       mq-reason-code.

call mqfn-mqdisc using mq-hconn
                       mq-status-code
                       mq-reason-code
    on exception
        move "Call to =MQDISC= program failed"
                            to lkx001-error-message
        move lkx001-error-message
                            to w-unix-msg
        perform z9100-error
        perform z9200-unix-log
        exit section
end-call. 


We're running AIX 5.1 and MicroFocus COBOL (not sure which version). None of the code has been changed - I know developers always say that, but it does seem to be affecting all of our COBOL programs and I guess they can't have changed all of them.....

Any ideas?
Back to top
View user's profile Send private message Send e-mail
bigdavem
PostPosted: Tue Sep 02, 2003 6:24 pm    Post subject: Reply with quote

Acolyte

Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia

For what it's worth, it appears this problem is due to a compatibility issue between MQSeries 5.3 and MicroFocus COBOL 4.1. The COBOL prerequisite for MQ5.3 is ServerExpress 2.0.10.
Back to top
View user's profile Send private message Send e-mail
bigdavem
PostPosted: Tue Sep 02, 2003 6:31 pm    Post subject: Reply with quote

Acolyte

Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia

Can anyone tell me if there are any side effects of just bypassing the MQDISC call when the program ends? I vaguely remember reading somewhere that there wasn't really much need to call MQDISC, but that it was good programming practice to do it. I'm just looking for a workaround to the problem above, since upgrading COBOL is a big job and MQ 5.2 goes out of support at the end of the year.....
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Wed Sep 03, 2003 3:16 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

What is in mq-reason-code after the MQDISC fails?

On CICS, the MQCONN call is optional, and so is the MQDISC. But if you use MQCONNX on CICS, then the MQDISC is required.

Technically you can choose to not MQDISC. You will get an implicit MQDISC when your program ends. Depending on how that program ends will determine the state of your uncommitted units of work. For example, if your programs ends abnormally, any units of work are backed out.

Not MQDISCing as a band aid solution is not the way I would go. It worries me that you might have orphaned connections kicking around. Who knows what will happen when they build up? Maybe nothing. Maybe something bad.


I suggest you study Chapter 7 od the App Programing Guide
http://publibfp.boulder.ibm.com/epubs/html/csqzal09/csqzal09tfrm.htm

and Chapters 31 and 33 of the App programing Reference
http://publibfp.boulder.ibm.com/epubs/html/csqzak09/csqzak09tfrm.htm

Better yet, find out the real source of the problem. Get IBM involved if no one else gives you an answer.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bigdavem
PostPosted: Wed Sep 03, 2003 3:39 pm    Post subject: Reply with quote

Acolyte

Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia

We got IBM in to help us. They traced the app and said that they could see it exiting the MQDISC code successfully, but the program crashed when control was passed back to the COBOL. There was no reason code, it was a genuine crash:

Execution error : file '/apps/testa/bin/UBH146.gnt'
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)

They also pointed out that MicroFocus COBOL 4.1 is not supported with MQ 5.3, so I installed the latest version of MicroFocus COBOL (Server Express v2.2) on a replica of the AIX box and the problem went away. So if anything it appears to be a COBOL problem, but MicroFocus won't fix it because COBOL 4.1 is out of support.

The obvious solution is to upgrade COBOL (and we plan to do that), but this is a huge task and is a year off at best. The next most obvious solution is to take MQ back to v5.2 (which works ok with COBOL 4.1), but since 5.2 goes out of support at the end of this year we'd rather avoid doing that if possible. So that leaves me looking for a workaround. Bypassing the MQDISC is the best I've come up with so far, but I agree that it's not a pleasant solution. I'm just not sure that there is a pleasant solution....
Back to top
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Wed Sep 03, 2003 4:21 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

This is purely my opinion, but if everything works at 5.2, and the only reason you are upgrading is just because 5.2 won't be supported, I would stay at 5.2.

Like I said before, who knows what will happen if you never MQDISC. Maybe regular reboots may make things safer and keep "things" from accumalating.

On the other hand, you do know that 5.2 of MQ works fine.

I think the lesser of 2 evils is to stay at 5.2.

What does IBM say about skipping your MQDISCs for a year?

Who's to say this is the only problem with 5.3 at the version of COBOL you are at? What if some combination of GET options that you have not used yet starts causing your MQGETs to crap out?
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bigdavem
PostPosted: Wed Sep 03, 2003 4:25 pm    Post subject: Reply with quote

Acolyte

Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia

Yeah, you're probably right. I just had dreams of having all our MQ everywhere nice and shiny and 5.3.....
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » MQDISC/COBOL problem
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.