HealthQuest Inbound Problem

This topic has 4 replies, 3 voices, and was last updated 19 years, 3 months ago by William Rowley.

Creator

Topic
August 30, 2005 at 5:07 pm #48010
William Rowley
Participant
We recently migrated our McKesson HealthQuest application from a mainframe running VSE to a mainframe running Z/OS. We also changed the protocol between Cloverleaf and HealthQuest from SNA to TCP/IP.

Prior to the migration the HealthQuest system and the CICS region that hosted it would be brought down at midnight for end of day processing. This broke the connection from Cloverleaf to HealthQuest and Cloverleaf would try to connect until successful. Life was good….

Since the migration the CICS region is no longer brought down but the HealthQuest function SYST is used to close files and – sorta – stop the interfaces. What we see happening now is that the Cloverleaf connection to the HealthQuest HUBI transaction stays up but after sending a message to HUBI, Cloverleaf never receives the ACK message. I have validated that the ACK does not come to Cloverleaf by running an IPTRACE. Our workaround for now is to stop and start the thread which resets the Await Reply flag and re-sends the message.

Has anyone else had this problem?

Thanks,
Creator

Topic

Viewing 3 reply threads

Author

Replies
- August 30, 2005 at 8:06 pm #57287
  Charlie Bursell
  Participant
  Way to go Bill. Wish more people would go away from SNA. The life cycle cost of an SNA interface is many orders of magnitude than that of a TCP/IP interface. Simply because yu have more poeple that know TCP/IP
  
  Have you set the Await Replies flag to time out after a while? That will clear the flag and resend the message without shutting down.
  
  It looks to me like the mainframe is not dropping the connection but stopping the application on their side. I think you can see that if you put a sniffer on it.
  
  Good luck with it.
- August 30, 2005 at 9:00 pm #57288
  William Rowley
  Participant
  The mainframe folks don’t want us to time out on the Await Reply because then they would potentially have multiple copies of the message (and the resulting application errors that they would have to address). They are receiving the message but since their files are closed they delay sending the ACK until the files are open again. We also have a firewall between us and I’m fairly certain that the firewall is timing out the connection and preventing the ACK from getting back to Cloverleaf once they send it.
  
  Thanks for the suggestion though.
- August 31, 2005 at 10:50 am #57289
  Stephan Head
  Participant
  I don’t understand what files would be closed by SYST that would cause this unless the function is closing the SIS* files, which it shouldn’t be doing. Closing the queue files wouldn’t cause the ACK problem, as the records would just back up in the queue files instead of temporary storage.
  
  May I suggest a couple of things. One, try setting the HealthQuest thread associated with HUBI to “bounce” just after SYST has been initiated and two, speak to Cliff Warren at McKesson about what files are closing during SYST.
- August 31, 2005 at 5:57 pm #57290
  William Rowley
  Participant
  We have been working with Cliff Warren and the SIS (actually the SIV*) files were being closed by SYST. That has been changed in the test environment and it cleared up the problem there. The transaction volume in test isn’t high enough to give me the full blown “warm and fuzzies” but I do look forward to the change being applied in production tonight.
  
  I am holding off on scheduling a “bounce” or putting in alerts that cycle the thread until I’m sure that the mainframe side has exhausted all their options.
  
  I certainly appreciate the suggestions – thanks!
Author

Replies

Viewing 3 reply threads

The forum ‘Cloverleaf’ is closed to new topics and replies.