''C'' - character count wrong in previous data block received ''X'' - checksum wrong in previous data block received ''B'' - data too long for input buffer in previous block received |
|
d)If the block is acceptable and has block type ''N'', it is a negative acknowledgement. Resend the original block as many times as is specified in the NPT or return to the application with an indication of the error.
e)If the block is acceptable and has block type ''D'' it is the response. Go to the next step.
f)If the initiating system detects an error in the data block from the responding system, it has the option of retransmitting the original data block. The decision of whether to retransmit the original block is application-specific. It depends on the type of message and the ability of the receiving system to detect duplicate messages.
Connect Retry Count - the number of times to try to connect to a destination.
Connect Pause - the amount of time to wait between connect attempts.
Receive Timeout - the amount of time to wait for a response data block.
Send Retry Count - the number of times to resend a data block after receive errors.
American National Standards Institute
1430 Broadway
New York, NY 10018
(212) 642-4900
Figure B-1.
SOH |
(Start of Heading)SOH delimits the start of a message heading. If the heading is subdivided into multiple transmission blocks, SOH delimits the start of each block that continues transmission of the heading. |
STX |
(Start of Text)STX precedes a sequence of characters that is to be treated as an entity and entirely transmitted through to the ultimate destination. Such a sequence is referred to as "text." If a heading precedes the text, STX delimits the end of the message heading. If the text is subdivided into transmission blocks, STX delimits the start of each block that continues transmission of the text. |
ETX |
(End of Text)ETX delimits the end of a message text. In multi-block messages, ETX indicates the last block of the message. |
ETB |
(End of Block) |
ETB delimits the end of a block that is not the last block of a message. |
|
EOT |
(End of Transmission)EOT indicates the conclusion of a transmission that contained one or more message texts and any associated headings. |
EOT cancels any previous master/slave assignment. |
|
EOT must never have a prefix. |
|
EOT is sent by a master station after the completion of the message transfer phase in order to effect a normal termination of the transmission. (End current master/slave transmission relationship.) |
|
EOT is sent by a master station prior to the completion of the message transfer phase in order to effect a sending station abort function. (Sent between blocks of a multi-block message.) EOT is sent by a slave station in place of ACK/NAK in order to effect a termination interrupt function. It serves to NAK the current block and causes the current master/slave relationship to be ended. |
|
ENQ |
(Enquiry)ENQ is used to request master status. ENQ is used to solicit a response from a remote station. ENQ may be used to obtain identification of the remote station. ENQ is the last character of a polling or selection supervisory sequence. ENQ is used by the master station in block abort procedures. |
NAK |
(Negative Acknowledgement)NAK is transmitted as a negative response to the sender. NAK is used during the establishment phase to indicate that the station is not ready to receive. During message transfer, NAK indicates that the last message or transmission block wasnot accepted, but the station is ready to receive. |
ACKN |
(Acknowledgment N) |
Figure B-2.
Description |
The sending station in the process of sending a block, but before the end of the block,decides to end the block in an unusual manner such that the receiving station will discard the block. Such a procedure is called a block abort. |
Application |
Block abort may be used by a sending station when, in the process of sending data, there occurs an indication that the data being sent may not be valid. |
Block abort may be used in the message transfer state to cause a temporary text delay after receipt of the previous acknowledgement if the sending station is not capable of transmitting the text of the next transmission block before the predetermined time-out period. The reasons for such a delay might be the unavailability of buffer space or that the speed of the input device is considerably slower than the transmission speed and a full block has not yet been read from the media. |
|
Procedures |
Block abort is accomplished by the sending station''s ending the block (at any time) with the ENQ. The sending station then halts transmission and waits for a reply. The receiving station detects that the block was ended with ENQ rather than with a normal ending character (ETB or ETX), discards that portion of the block that had been received and sends a NAK response to the sending station and remains in the receive condition. Following receipt of the NAK response, the sending station will normally reinitiate the transmission with the same or a new block. In the case of a NAK response that is not received, the sending station will time out (expiration of Timer A - see section on Timers). The sending station reinitiates transmission with the same block or it may choose to initiate an appropriate termination or recovery procedure. The specific choice of operation will generally be a function of the system discipline being employed. |
Description |
The sending station, in the process of sending several blocks per message text, decides to terminate transmission prematurely at the end of a block and after receipt of the proper acknowledgement reply. Such a procedure is called a sending station abort. |
Application |
Sending station abort procedures may be used by a sending station when, in the process of sending multiple blocks per message text, it determines that it should prematurely terminate transmission to the particular receiving station. Such a determination might be made if the sending process did not receive the remaining blocks in time from the higher level, needed to send a higher priority message, or was temporarily unable to continue transmission, etc. Sending station abort procedures may be used following block abort procedures to accomplish a transmission abort condition; that is, the sending station prematurely terminates the transmission within a transmission block. |
Procedures |
Sending station abort procedures are accomplished by the sending station completing the transmission of a block, for example, ETB, ENQ. Then upon receipt of the proper acknowledgement reply (ACK, NAK, etc.) or a Timer-A time-out, the sending station transmits EOT to terminate the transmission to the receiving station. The receiving station detects this sending station abort procedure by recognizing receipt of EOT following ETB, or ENQ instead of ETX |
Description |
The receiving station, after receipt of a message or transmission block, causes the sending station to cease transmission. Such a procedure is called a termination interrupt. |
Application |
Termination interrupt may be used by the receiving station to cause the transmission to be interrupted because it is not in a condition to receive. Cause for such inability to receive could include a hardware malfunction, loss of an additional network connection, etc. |
Procedures |
Termination interrupt procedures are accomplished by the receiving station''s transmitting EOT in lieu of one of its normal responses. This response indicates a negative acknowledgement of the last transmission and the conclusion of a transmission. |
Description |
A receiving station may request the sending station to terminate the transmission in progress prematurely in order to facilitate a reversal in the direction of data transfer. Such a procedure is called reverse interrupt. |
Application |
Reverse interrupt procedures may be used by a receiving station to interrupt its receiving of a message stream so that it may transmit a priority message or messages to the original sending station. |
Procedures |
Reverse interrup Reverce interrupt procedures may be used by a receiving station only after reception of a block with a valid BCC. Reverse interrupt procedures are accomplished by the receiving station''s transmitting a RINT sequence in lieu of the normal affirmative acknowledgement. This reply is interpreted as an affirmative reply to the last transmission, and it signals a request by the receiving station that the sending station terminate the transmission sequence in progress as soon as the sending station is in such status that it can receive a message without destroying or losing information that may have previously been stored in buffers. The RINT sequence may not be repeated by the receiving station to successive transmission blocks without transmitting intervening affirmative acknowledgements (ACKN). Upon receipt of RINT, the sending station should terminate the transmission by transmitting EOT after it has completed transmitting all data that would prevent it from receiving a message. The number of transmission blocks to be transmitted prior to termination is variable and dependent upon station design. The receipt of RINT as a response to a sending station''s ENQ should be treated as a repeated (duplicate) response if the last valid response received was ACKN. The sending station should continue by transmitting the next block, or EOT. If the last valid response was RINT, the sending station must assume that the last transmitted block was garbled. The sending station should retransmit the previous block. |
<SB>dddd<EB><CR> |
|
<SB> = |
Start Block character (1 byte)ASCII <VT>, i.e., <0x0B>. This should not be confused with the ASCII characters SOH or STX. |
dddd = |
Data (variable number of bytes) This is the HL7 data content of the block. The data can contain any displayable ASCII characters and the carriage return character, <CR>. |
<EB> = |
End Block character (1 byte)ASCII <FS>, i.e., <0x1C>. This should not be confused with the ASCII characters ETX or EOT. |
<CR> = |
Carriage Return (1 byte)The ASCII carriage return character, i.e., <0x0D>. |
Saved ESN |
Expected Sequence Number State |
> = 1 |
> = 1 (valid sequence number) |
- 1 |
NONE |
SEQUENCE NUMBER PROCESSING BY RECEIVING SYSTEM SQ#Sequence Number ESNExpected Sequence Number ESN StateExpected Sequence Number State |
|||||||||
Is this a type of message that requires SQ#s? |
|||||||||
NO |
YES |
||||||||
Process according to that type and ignore sequence numbers. Do not change either the ESN State or the ESN. Example: If this message is a network management message from receiving system, ignore sequence numbers altogether. |
Incoming is an integer SQ# > = -1? |
||||||||
NO |
YES |
||||||||
Send an MSA with an AR. Example: The right message, but the wrong sequence number format. |
Continue ? |
||||||||
What is the ESN State (Expected Sequence Number State)? |
|||||||||
ESN State >= 1 An Expected Sequence Number exists or is defined. |
ESN State = NONE An Expected Sequence Number does not exist or is not defined. |
||||||||
Incoming SQ# = -1? |
Incoming SQ# = -1? |
||||||||
YES |
NO |
NO |
YES |
||||||
Set the following: ? ESN = -1 ? ESN State = NONE |
Incoming SQ# = 0? |
Incoming SQ# = 0? |
Set the following: ? ESN = -1 ? ESN State = NONE |
||||||
Send MSA with AA |
YES |
NO |
NO |
YES |
Send MSA with AA |
||||
Set the following: ? ESN = Existing ESN ? ESN State = "ESN >= 1" |
SQ# must be >= 1 Set the following: ESN = Existing ESN ESN State = "ESN >= 1" |
Incoming SQ# >= 1? |
Set the following: ? ESN = -1 ? ESN State = NONE |
||||||
Send MSA with AA |
Refer to the Message with Sequence Number Chart. |
NO |
YES |
Send MSA with AA |
|||||
error |
Set the following: ? ESN = Incoming SQ# ? ESN State >= 1 This must be a full message and the assumption is that its been preceded by a SQ# control message of 0 or -1. Thus, this is a "start of sequencing, actual message, and the receiving system is synchronized to this incoming SQ# as its ESN (and ESN State is "ESN >= 1"). No further SQ# checking, but do regular application processing on this message. |
||||||||
Send MSA with AA or AE accordingly |
This chart is a continuation from the Sequence Number Processing Chart on the previous page. It details the Sequence Number Process when there is an ESN and the ESN state = "ESN >= 1." MESSAGE WITH SEQUENCE NUMBER |
|||
Sending system |
|||
sends a message with a sequence number (SQ#)? |
|||
Receiving System tracks Expected Sequence Number (ESN) and ESN state |
|||
compares SQ# with ESN? |
|||
SQ# = ESN |
SQ# ? ESN |
||
Sends MSA with AA or AE acknowledgment code, and contains the SQ# = ESN. |
Sends MSA with AR acknowledgment code, an error message, the Expected Sequence Number (ESN), and the message sequence number (SQ#) received. |
||
Sending system ? |
|||
SQ# = ESN |
SQ# +1 = ESN |
SQ# > ESN |
Other Errors |
Increments SQ# by 1. |
Assumes the previous acknowledgment is lost. The message sent is a duplication. Increments SQ# by 1. |
1) ADT tries to recover by starting at the ESN in the MSA. --or-- 2) Freezes the link. |
Freezes the link. |
Processes the next message. |
Processes the next message. |
1) Sends messages from log beginning with ESN in MSA. --or-- 2) Waits for operator intervention. |
Waits for operator intervention. |
Current State of Receiving System: Expected Sequence Number = NONE |
||
Incoming Message Seq. Num |
Expected Seq. Num Field of MSA |
Next State of Receiving System |
-1 |
-1 |
None |
0 |
-1 |
None |
>= 1 |
Same as incoming |
Same as Incoming +1 |
Current State of Receiving System: Expected Sequence Number >= 1 |
||
Incoming Message Seq. Num |
Expected Seq. Num Field of MSA |
Next State of Receiving System |
-1 |
-1 |
None |
0 |
Expected Seq. Num |
Expected Seq. Num |
>= 1 |
Same as incoming |
Same as incoming +1 |
do/* call until successful or too many retries */
{ status = call(network address);
if ( status == OK )/* break out of loop if successful */
break;
retries = retries - 1;
sleep for configurable # of seconds (1 sec?) ;
} while ( retries >= 0 );
if ( status != OK )/* return if calls failed */
return(status);
while messages to send to this destination
{ status = send(next message);/* send the message */
if ( status != OK )
goto disconnect;
status = receive(reply);/* get the reply */
if ( status != OK )
goto disconnect;
application code to process reply
}
disconnect:
disconnect();/* disconnect if error or done */
return(status);
for ( ; ; )/* do forever */
{ do/* wait for listen to complete successfully */
{status = listen(port);}
while ( status != OK );
for ( ; ; )/* loop until disconnected */
{ status = receive(message);
if ( status == OK )
{ application_code(message,reply);
send(reply);
}
else if ( status == DISCONNECTED )
break;/* break out of inner loop */
else ERROR/* some other error */
}
disconnect();/* disconnect if error or done */
}