HLCSTCP1 can't handle disconnects on GT.M
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenVista/GT.M Integration |
Fix Released
|
High
|
Unassigned |
Bug Description
Typically, an HL7 interface may connect to OpenVista, send some messages, then disconnect after a timeout when no more messages need to be sent. A new connection is established later, when there are more messages to send. The code in HLCSTCP1 can't handle the disconnect when running on GT.M -- it logs an error to the error trap, then sets the interface to an ERROR state, effectively shutting down the interface.
LGTM^%ZISTCP doesn't set IOERROR="TRAP" in the OPEN command, so $ECODE is not set when the disconnect occurs. (In fact, IOERROR="TRAP" was explicitly commented out in the FOIA code, but there isn't a comment that says why.) When the disconnect occurs, ERROR^HLCSTCP1 is called to handle it because of our $DEVICE check in READBLK^HLCSTCP1, but because $ECODE is not set (because IOERROR="TRAP" is not set), the logic that screens out disconnects doesn't get triggered, so it defaults to logging an error in the error trap and shutting down the interface. Even if IOERROR="TRAP" were set, it's unclear whether $$EC^%ZOSV would properly parse GT.M's $ECODE values.
Our solution is to check $DEVICE again in ERROR^HLCSTCP1, and if it contains "Connection reset by peer", and if we're not in the middle of processing a message, just go back to listening.
Related branches
- jeff.apple: Approve
-
Diff: 31 lines (+8/-2)1 file modifiedmumps/HLCSTCP1.m (+8/-2)
Changed in openvista-gtm-integration: | |
importance: | Undecided → High |
status: | New → Fix Committed |
Changed in openvista-gtm-integration: | |
milestone: | none → 0.8.9 |
Changed in openvista-gtm-integration: | |
status: | Fix Committed → Fix Released |