| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Visual Basic 6 program does not terminate after reading Q's |
« View previous topic :: View next topic » |
| Author |
Message
|
| PeteTheVan |
 Posted: Tue Aug 18, 2009 6:41 am Post subject: Visual Basic 6 program does not terminate after reading Q's |
 |
|
Newbie
Joined: 18 Aug 2009
Posts: 3
|
Hi all, I am using VB6 under (local) Windows XP & (remote) Server 2003 and using MQCONN / MQ_SETDEFAULTS API's etc. (I am not using VB.NET).
I am simply connecting to a queue manager, opening a queue, reading down the queue processing messages until I hit the "STOP" message. I then close the queue and finally disconnect (using MQDISC).
I then use the VB command "END" to terminate the program. The program has no user interface form and therefore appears in "Task Manager/Processes" rather than "TM/Applications"
Here's the problem: If I run this program in a) the VB IDE, b) as an EXE pointing to a local queue or c) as an EXE pointing to the remote queue, it's all fine. The process appears in TM under user "myuser" and then drops out when it's done (ie no longer in list).
However, if I put this onto the target Server 2003 machine that's got the MQ Server on it, it runs just fine and processes the queue. It appears in TM under the user "myuser" and then once it's finished the CPU drops to 0% and the user changes to MUSR_MQADMIN and remains in the list of processes. It does not terminate.
I know it's finished processing and reached the END statement as I have logged the various flow points in the program.
If I deliberately change the queue name to a illegal queue then the program runs and terminates correctly down its error route - I am still using END here. It seems as if it's only after using MQGET that causes the problem.
Any ideas? |
|
| Back to top |
|
 |
| gbaddeley |
| Posted: Tue Aug 18, 2009 3:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Does DIS CONN show that the process is still connected to MQ ? If its using a client channel, does DIS CHS show its still active? Try running MQ trace to see where the process got up to before hanging.
_________________
Glenn |
|
| Back to top |
|
|
| PeteTheVan |
| Posted: Wed Aug 19, 2009 1:50 am Post subject: |
|
|
Newbie
Joined: 18 Aug 2009
Posts: 3
|
Hi Glenn, thanks for the swift reply. First off, we're using MQ 5.3 so DISPLAY CONN isn't available.
I'm (obviously) new to this and found DISPLAY in RUNMQSC. I tried most combinations of DISPLAY and found that DISP QUEUE (myqueue) gave me the most information - specifically IPPROCS and OPPROCS. Each had (0) as values. Research tells me this means that there's no process attached to the queue therefore my program isn't connected at this point. DISP QSTATUS gave me the same info.
I'm going to turn on trace using "STRMQRTC -t all -t detail -e" later today when I'm allowed...
I'll post back when I've got some sensible data.
Pete |
|
| Back to top |
|
|
| PeteTheVan |
| Posted: Wed Aug 19, 2009 3:27 am Post subject: |
|
|
Newbie
Joined: 18 Aug 2009
Posts: 3
|
Excellent(!). I turned trace on, ran the program and it ran just fine, terminating normally. The trace file shows normal program operation. I can see the MQGETs, MQCLOSE & MQDISC just fine.
The only difference was that originally the queue had several copies of the source data records - the source process sends these messages every night and at that time I hadn't run the program to suck them out. Each set is/was terminated with a message "ENDOT". The program stops once it gets this message (or CompCode <> 0). Therefore one run of the program processing one set of records.
So the question now is, what's the difference between leaving the Q empty and leaving it with some records in it?
I suspect that my problem now simply "goes away" because the Q will always be emptied in the production environment, but I would still like to know what's going on.  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 19, 2009 4:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So if you don't have DIS CONN, then you're not running a newer version of MQ.
And you're not running a newer version of Microsoft programming either. You shouldn't be using VB6, you should be using VB.NET.
And you shouldn't, likely, be running whatever version of MQ you are running on MS Server 2003. It's almost certainly not supported.
So when running unsupported things in unsupported environments, you should expect unexpected results.
All that said, the behavior you are seeing of the application failing to stop when there are messages on the queue are almost certainly the result of the application logic rather than the environment. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Aug 19, 2009 5:58 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| PeteTheVan wrote: |
Hi Glenn, thanks for the swift reply. First off, we're using MQ 5.3 so DISPLAY CONN isn't available.
Pete |
It was a pleasure to help. Please upgrade to a supported version of MQ.
| Quote: |
| I tried most combinations of DISPLAY and found that DISP QUEUE (myqueue) gave me the most information - specifically IPPROCS and OPPROCS. Each had (0) as values. Research tells me this means that there's no process attached to the queue therefore my program isn't connected at this point. |
Not true. IPPROCS(0) and OPPROCS(0) means than nothing has the queue object OPEN. It doesn't say anything about programs that might be CONNECTED to the queue manager.
_________________
Glenn |
|
| 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
|
|
|
|
