TCP IP Bind Error

[rtgordon]

I am trying to replicate the US system in different mainframe (VSE) LPARs (each have a different IP address). I am getting TCP/IP bind errors on the mainframe (the listener transaction MQTL is failing), and I can't bind on the NT platform either.

Everything appears to be in order. I know it could be one in a million things, and I know most of you don't use VSE... but for the few that may have consulted with it. Anything come to mind as to what might be getting overlooked or configured incorrectly?

Thanks,
gordon

 

[petehanbury]

Please check that both machines are listening on the same default port setting of 1414

Check that the command server and channel initiater and listener are all functioning correctly

 

[rtgordon]

Let me try to be a little more specific. On NT, I have two qmgrs that comminicate with two qmgrs on the mainframe through ports 1414 and 1415. We are attempting to implement this setup in another LPAR to enable messaging with our European system. I built the qmgr in europe added sending and receiving channels on both sides, remote qdefs, local queues, transmission queues, etc.

When I attempt to start the outboubound channel in NT, the channel sits in a binding state, spitting out messages to the log. When I try to initialize the system on the mainframe, I get a TCP/IP Bind Error. That is where I am stuck and have been stuck for a while :-(

gordon

 

[petehanbury]

This may be a silly answer Ray,

I have come across a similar problem at Candle before. The problem was occuring because the listeners were both listening on 1414 instead of one on 1414 AND ONE ON 1415.

This may seem simple but your problem seems identical to that situation and we could not believe it when it was somthing simple like the listener not being set to listen on 1415 :\

 

[rtgordon]

No, I don't think that is it. I even went as far as configuring another listener to listen to port 1417 on both sides, and it still is giving me a bind error. There is something minute that I am missing or maybe it's just a problem with VSE. I am still trying, though.

Thanks,
gordon

 

[pmeekin]

Hi.

Still struggling with VSE I see ;-)

Grasping at straws really but...

- what TCP error codes do you get in the logs?
- Are you saying the VSE sender can't find the NT listener as well as the NT Sender and VSE listener?
- Can you ping each system from the other?
- Is there any VSE authorisation required to use sockets?
- Do you have the right size crank handle for your VSE LPAR? (Sorry ;-) )

As I say, I'm grasping at straws here but I'd say the TCP error codes would be helful.
Cheers,
Paul

 

[rtgordon]

Paul,
Thanks again for your replies. Actually, we figured out (with the help of Commerce Quest) what the problem was. It is a little VSE quirk. If you use TCP/IP for VSE, the TCP/IP phase library has to be added to the CICS JCL before the SCEEBASE library. So, it was out of my control at that point. As I do not have access to any of the startup JCL, etc. I think that this was also an issue in earlier versions of MQSeries for the more mainstream mainframe OS's.

Apparently the SCEEBASE has a "dummy" TCP/IP phase stub that will cause honkage if it gets loaded first.

Anyways, you will be happy to know that I have successfully put an message to a queue using MQ Base Java and an MS Active Server Page.

Thanks,
gordon

 

[pmeekin]

Congratulations - I guess there really is life in the old girl yet

Yes, I recall a similar issue with MQ on MVS in the old days. Ahhh yes, the good old days when JCL separated the men from the boys, SNA was the lingua franca instead of this TCP/IP rubbish, runmqsc line mode commands were a way of life ... well, I guess some things stay the same.

See you around,
Paul