| Author |
Message
|
| JTski |
 Posted: Wed Feb 04, 2004 10:31 am Post subject: Allowing MQ to run wide open |
 |
|
Novice
Joined: 04 Feb 2004
Posts: 14
|
As my status would indicate, newbie. But I have searched through the threads to try and find my answer but I have not.
I have a vb6 .exe, configured as a NT service on W2K server. I am attempting to access the queue manager on a vendor server (mqseries on linux). I call MQCONNXAny with the CORRECT parameters, I have run through that a million times to make sure I did not fat finger anything, and receive a 2058. I know for a fact by using another test tool I built that the queue manager name is correct but you can also get this error if the uid being passed to connect is wrong.
I insist that my credentials are being passed correctly and the vendor insists that they have it configured correct on their. Bottom line, can the vendor see on his server, via some sort of error log/log what user is trying to connect to their queue manager? Or is there a way I can spit out that info on my side right before I try and connect? |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Feb 04, 2004 11:59 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
do you have the source of the VB app?
with which mq library did you link the program?
it could be you linked with the server library and everything is setup correctly but your program simply tries to connect to the local qmgr which is not there, hence the 2058.
Michael |
|
| Back to top |
|
|
| JTski |
| Posted: Wed Feb 04, 2004 12:10 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2004
Posts: 14
|
| Thanks for the reply. I am using the client library. I have been told that the credentials being passed will be the credentials I have setup the service to run as. Keep in mind that this is a prod server that no one is ever really logged into. If you were to physically walk up to the terminal it would be at the CTRL+ALT+DEL screen. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 04, 2004 12:17 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I can only help if you give me as much details as possible...
I do not have a 'crystal ball'.
I know you are convinced everything is setup correctly, but do you get that error then?
Michael |
|
| Back to top |
|
|
| JTski |
| Posted: Wed Feb 04, 2004 1:09 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2004
Posts: 14
|
| Please excuse my wording. I was not being smart or short with you. I was being sincere. "Thanks for your reply" was not meant to be a smart comment. Sorry about that. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 04, 2004 2:00 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
no problem, I didn't take it that way!
I am only trying to help you in the best way I can and from experience I know an error can be made easily, especially when you looked at all the data a hundred times!!!
You think everything is OK, someone else may have one look and see the error...
Are you passing parameters to the program? did you perhaps switch the Queuename and QueueManager name?
Micael |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Feb 04, 2004 3:40 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Are you shure that the firewall folks have allowed your communication ?
Are you shure that you are using the right TCP/IP port ?
You could try using amqsgetc/amqsputc on and specify an unknown queue, this can be used to spot problems in the network. If you get 2085, 2035, 2059 there are hole in the firewall.
I use the technique myself.....
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| JTski |
| Posted: Wed Feb 04, 2004 4:31 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2004
Posts: 14
|
Hey guys. I got the vendor to run strmqtrc.exe on his linux server and capture trace data on the specific queue manager. He was able to see me come in, with all the correct credentials  , but for some reason the connect never happened. He was not able to give me any more info as of yet. I think I have cleared myself, or my program, I hope, of any issues. Do you guys have any suggestions? Is there some sort of granular settings that may have to be set? I'm hoping to have him send these trace files to IBM if we can't get this resolved. Any suggestions you guys may have would be great. |
|
| Back to top |
|
|
| JTski |
| Posted: Wed Feb 04, 2004 5:08 pm Post subject: |
|
|
Novice
Joined: 04 Feb 2004
Posts: 14
|
OK. I have done some more searching and want to provide some more info on my issue.
My program is an vb6.exe running as a service. The actual MQCONNXAny call is made out of a dll in a COM+ package. When the vendor ran his trace today he saw the path of calling app on my side, WINNT\ ...\...\dllhost.exe. Can this be a potential issue? What I mean is, i saw another thread on this site a few minutes ago where a guy was getting 2058 and his program was running in a COM+ package. He says he installed CSD04 and it fixed his issue. The thread was kind of skethchy so it didn't have much detail. I'm grabbing at straws here guys, I know.
Well, I just looked at my client version on my server, 5.2 CSD 5. So I guess I am covered. Maybe an issue on the vendors side with server software upgrades? |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Feb 04, 2004 8:43 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
so you actully get to the other side!
what is in the trace from the other end?
2058 = Qmgrname error
if nothing came back, I would expect 2059 = Qmgr not available.
Michael |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Feb 09, 2004 5:11 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
As per the above update, 2058 implies the name you passed is invalid as the qmgr on the destination machine, compared to 2059 if you cant connect. Are you providing a 48 char padded with spaces qmgr name? What about a null/empty qmgr name? I dont think its security/context related, as you would be seeing 2035's (although you might not have got that far yet...).
The path+exe name is not going to cause you problems. If you look in the trace on the linux side (format it!), then you will have either the runmqlsr, inetd or amqrmppa process doing an MQCONN on behalf of your application, and it should be getting the 2058 which is passed back to your app. Look at the qmgr name there, and is it what you expect? |
|
| Back to top |
|
|
|
|
