When I tested some programs on VM/CMS and assigned INPUT and OUTPUT to the CMS console using FILEDEF INPUT TERM etc., I observed that I could not establish a real user dialog using WRITELN and READ due to different reasons.
I wrote a small test program similar to the following, which simply wrote a line, asked for input, wrote another line, asked again and so on.
|
But: the program asked for input, before the first WRITELN appeared. I found out after some research, that this is due to a RESET (INPUT) call which is introduced implicitly by the compiler at the beginning of the main procedure, and RESET is defined by the Pascal language definition to make the first file element available (that is: INPUT -> points to the first char in the file). And that again means that it reads an input buffer (from the console, of course), and it does this at the time of the RESET, that is: at the beginning of the main program, before the first WRITELN occurs.
It was very soon clear to me, that this implicit RESET has to be eliminated, but I first had no idea, how to do it. The compiler and many other programs will rely on it, and the language definition, too, says that it has to work that way. I recalled that Pascal VS had special calls TERMIN (INPUT) and TERMIN (OUTPUT), which had to be applied to terminal files; maybe those calls eliminated the compiler generated RESET (or: Pascal VS didn't do any implicit RESET at all).
To test what will happen if I eliminate this RESET I simply shifted it to a later position in the P-Code file (extension PRR on CMS) and then translated this modified P-Code file to object code.
I then observed that anyway a READ request occurred before the WRITELN. Indeed there was a second problem: because all output I/O was done using locate mode, the real output of a text line was deferred until the first WRITE of the next line. That is: not the WRITELN triggered the console output, but the first WRITE of the next line (which is in my example program obviously the next WRITELN).
So after some thinking I decided that it would be the best to transform all the writes to OUTPUT to move mode instead of locate mode; but that was a major task, because the output routines were not prepared to do it this way.
I omit all the technical details and pitfalls; it needed many days to get this working. Now the mode (move or locate) is controlled by a flag which is part of the FILDEF macro - on a per-file base - so if it should be needed to switch the mode back to locate, this is very easy task. And: not only the file OUTPUT is processed in move mode, but every output file, including the non-standard user textfiles (which were added in 1982 by McGill, another significant improvement over 1979 Stanford).
When I had successfully switched all output files to move mode and still patched my example program (by moving the RESET to a later point), all worked well and the example program worked as expected.