When your RS-232 device gets interrupted, how does it behave? How does it get reset to continue the communication? Can I reset it and stop the transfer (and potential loss) of data mid-command?
Regarding RS-232 flow control, there is software flow control (XON/XOFF) and hardware flow control (CTS/RTS). Lets take a look at both and what would happen if the communication is interrupted (possibly a result of the computer "going away", the controller application crashing or the serial cable is disconnected).
Software Flow Control (XON/XOFF). When software flow control is used the devices can stop communication by sending XOFF (CTRL-S) and start communication with XON (CTRL-Q). If the DMM is sending data to the Controller and the Controller's input buffer reaches near capacity (the threshold point is typically about 80%), the Controller will send XOFF to the DMM to halt its output. When the Controller has processed the data on its input buffer, it will send XON to resume communication. Conversely, if the DMM is receiving commands from the Controller and if the DMM can't keep up processing the commands, its input buffer will reach a threshold point and it will send XOFF back to the Controller and then once its input buffer reaches some low capacity point, it will send XON to the Controller to let it resume sending commands. Now in the event the communication from the DMM to the Controller is interrupted (eg during the FETCH? command), it is highly unlikely that the Controller would have sent an XOFF command. The instrument will just send the contents of the FETCH buffer even though it is not being received due to the interrupted connection. Over Serial communication, you can also execute a Device Clear Active State (DCAS) sequence by sending CTRL-C. That will reset the interface and allow communication again one it is possible instead of leaving the RS-232 device in an error state.
Hardware Flow Control (RTS/CTS). When hardware flow control is used, the RTS/CTS lines are used to hold off/start communication. The receiver (either the DMM or the controller) will set the CTS to space voltage (a voltage between +3 and +12VDC) when it is OK to send data to it and will set CTS to the mark voltage (a voltage between -3 and -12VDC) when it is not ready. The sender (again either the DMM or controller) will set the RTS to the space voltage (+3 to +12 VDC) when it is ready to send data. So again looking at an interrupted communication issue between the Controller and the DMM, the controller would have to set the CTS signal line to a negative voltage to stop the DMM from sending data. More than likely, if the controller "went away", the voltage on the CTS line would not float negative on the input of the DMM...so again, the DMM will continue sending the contents of the FETCH buffer. And just like software flow control, DCAS (CTRL-C) will reset the interface to allow continuation of data transmission once a good connection is re-established.
And just to be a little more clear about how hardware flow control (RTS/CTS) is used. The CTS/RTS wires are cross-coupled between the two devices, so RTS on one device is connected to CTS on the remote device and vice versa. Each device will use its RTS to indicate if it is ready to accept new data and read CTS to see if it is allowed to send data to the other device. As long as a device is ready to accept more data, it will keep the RTS line asserted. It will deassert RTS some time before its receive buffer is full.
Note: CTRL-C over serial or DCAS metacommand over GPIB will “reset” the remote interface and clear the input/output buffers. You might also send *CLS which clears the error queue and any error bits that may have been set. Please also note that CTRL-C does not work over telnet.