--- Steven McPhelan <[EMAIL PROTECTED]> wrote: > 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.
Right. > > 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. I wouldn't doubt it. I've seen input transforms do all kinds of "interesting" things. > > Your other suggestion requires code that is M implementation > specific. So be it, then. If it is necessary to provide a Kernel utility to read from a file and trap th end of file error, then maybe we need one. > 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. Moving forward, we can at least provide the infrastructure to do IO properly. As for old code, we have two choices: we can either accept the status quo or fix code that is known to cause problems. It's happened before: Eliminating $NEXT from the data dictionaries is something ele that had to be done. If any existing code still uses $NEXT, it is non-compliant. Similarly, the SAC says: 2.11.5 READ commands should not be used in the data dictionary. 2.11.6 WRITE commands should not be used in data dictionaries (except for VA FileMan generated ID nodes). The call to EN^DDIOL should be used. Maybe this needs to be made explicit, but I take this to apply to any and all code reachable through code embedded in a DD. > Just because the problem occurred within > a > Fileman input transform, you have no assurance that the READ command > is > within the domain of Fileman. That's true. The input transforms, cross-references, etc. are components of the application. >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. > Whether it is done through the core language or a standard library, IO is something that very much needs to be addressed in a revised standard (or report). === Gregory Woodhouse <[EMAIL PROTECTED]> "All truth passes through three stages: First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident." --Arthur Schopenhauer ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
