Mike explained the problem again. The problem is not with READing from the null device, it has to do with what does the application do if it gets a <null> value from the READ. Fileman and other applications display a message a prompt again. Since M answers the READ command, one cannot check for $T either since it would indicate that the READ command did not time-out.
In this case, I believe someone else determined (or guessed) that the READ may be coming from the processing of an input transform and not from a cross reference. This would make much more sense. But it does not alleviate the problem with an infinite loop of reading from the null device.
Your other suggestion requires code that is M implementation specific. Since the problem is with the M READ command, I do not know how you would address this for all of VistA. The number of READ commnands in all VistA applications is tremendous. Just because the problem occurred within a Fileman input transform, you have no assurance that the READ command is within the domain of Fileman. I do not believe that the MDC addressed in final form what the standard behavior of a M system should be in response to a READ from the null device. I do not know if it was even discussed.
