| A created file, e.g. "output" in your example is carved out of our
heap.. The heap, when in diagnostic mode (TEST command) is 8MBs. This
same heap is used for DMA buffers, stacks and other data structures,
etc. Even for console overlays..
If your goal is to capture TEST command output, and this appears to be
the case, you should know that TEST accepts a -Q qualifier for quiet
mode. In this mode, you'll get a small amount of output at the beginning
of TEST execution and then *zero* output thereafter unless an error is
encountered (includes both write/read/compare type errors as well as
unexpected interrupt/exception type errors).
Finally, much of the error output goes into a FIFO console event log
by default. Said info can be displayed via "CAT EL". Unfortunately,
unexpected exception and interrupt dumps do not go to EL (would take
much more typing to explain why this is the case)..
In summary, I would recommend not redirecting STDOUT to a file.
Rather, I would recommend using TEST -Q. And if you're interested in
capturing large amounts of console output, I'd use a serial connection
with logging enabled (e.g. VMS' set host/dte/log=output.log tta1).
|
| Not really. The way TEST was architected/written, it does not allow for
all output to be re-directed to a file (RAM-based file, floppy, memory,
EEROM, etc.) Some is re-directed, but not all.
I would say your only two reasonable alternatives are:
P00>>>test -q # cat el for certain error types, if lots of
# errors and scrolling off screen
or
P00>>>test # with serial connection and logging enabled
# via your host terminal connection
I agree with you that, ideally, one would be able to redirect all TEST
output to a file that could be reviewed later. This would solve the
case where a given site may not be able to use set host/dte/log type
logging for whatever reason.
|