| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| 084c000 on MS HIS after MQS restart |
« View previous topic :: View next topic » |
| Author |
Message
|
| garthb |
 Posted: Tue Oct 30, 2007 7:10 pm Post subject: 084c000 on MS HIS after MQS restart |
 |
|
Newbie
Joined: 30 Oct 2007
Posts: 2
|
| Hi, I am new to MQS. We have just installed it on a MS Host Integration Server (ex SNA server) windows box communicating with a z/OS MQS. We have it working correctly in that we can get the channels in both directions working, but when we stop and restart MQS on the windows box, incoming requests get a 084c000 code. The TPNAME is still registered, its almost as if the 'glue' between HIS and MQS is not being re-established after the MQS restart. A reboot of the box fixes this. What other action do I need to take after restarting MQS to re-establish the connection between HIS and MQS? (preferably not a restart of HIS, as this would be dusruptive to other non MQ SAN processes) |
|
| Back to top |
|
 |
| rtsujimoto |
| Posted: Wed Oct 31, 2007 8:53 am Post subject: |
|
|
Centurion
Joined: 16 Jun 2004
Posts: 119
Location: Lake Success, NY
|
Below is RTA000152989, from IBMLink:
Source..........: PDDBR PDDBR
Last updated....: 19980603
Abstract........: CSQX203E MSGCSQX203E CSQX203 RC18 RC 18 RC10 RC0A LU62 084C
USERS: ALL USERS with MQSeries
PROBLEM SUMMARY:
He is trying to start a lu6.2 channel from MQ r120 to
another MQ r120 and getting msgCSQX203e ...ERROR IN COMMUNICATIONS
CONFIGURATION rc18. The problem may be caused if one of the
transmission parameters (MODENAME or TPNAME or PARTNER_LU) in the
side information is incorrect, or there is no side information for
the symbolic destination name specified as the connection name.
Ctrace showed the ALLOCATE was going out. Vtam returned
sense code 084C000. APPC returns a rc 10 x'A' to the application.
Not sure WHY MQ displays this as rc 18.
RC 10: TP_not_available_no_retry
This particular return code should only be given when the partner lu
rejects the connecting request. In other words, VTAM/APPC must have
passed the request to the partner lu, but the communication manager
on the workstation rejects it with the tp_not_ available_no_retry. We
need to find out whether the partner tp name provided is correct and
if so, whether that tp has been installed on the workstation
properly.
SOLUTION:
Found that APPCSI dataset was corrupted. Helped cust rebuild the
sideinfo which contains over 100 entries. After few test runs, found
out there were more missing entries. After the sideadd was performed,
then all seem to work fine. |
|
| Back to top |
|
|
| garthb |
| Posted: Wed Oct 31, 2007 12:02 pm Post subject: |
|
|
Newbie
Joined: 30 Oct 2007
Posts: 2
|
| Thanks for locating that, I dont believe that it applies in this case, the issue being experienced is on a windows box, the TPNAME being passed to us is correct, it worked prior to the MQS restart, and again worked after a reboot. Its almost as if I need to restart some part of SNA server to reregister the TPNAME. |
|
| 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
|
|
|
|
