   $ TAIL [/number] [/?] [/S] [/F] [/T secs] input_file(s) [output_file]

where:
   [] denotes optional parameters.
   /? - prints a help screen.
   /number - indicates the number in decimal of records to output.
   /S - forces TAIL to use the "safe" way.
   /F - monitors the input file and outputs records as they show up.
   /T secs - sets the monitor update rate in seconds (forces a /F).

The /F option sets a display rate of 5 seconds. The /T option will force a
/F and sets the display rate to the number of seconds specified. Type
<return>  or some other terminator character on the terminal to advance to
the next  file if wildcards are used on input and the /F option is selected.
If  monitoring batch .LOG files, you will probably want to correlate the
monitor  rate with the batch log's SET OUTPUT_RATE parameter (normally 1
minute).

You can use "-" in place of "/" to delimit options.

The defaults applied to the input file spec are "SYS$DISK:[].LOG" and the
output file defaults to SYS$OUTPUT. The input file may contain wildcards,
however, if you use wildcards on the input filename AND supply an output
file name, only the first file in the wildcard list will be put into the
specified output file. The rest will be output to SYS$OUTPUT.

The /S can be used to force TAIL to read the file(s) from the beginning
rather than from the end. You would use /S if, for some reason, TAIL screws
up trying to figure out the record structure on variable  length files but
for some reason doesn't notice.

Design goal:

Make a TAIL utility that can very quickly pickup the last n records of a
batch log file (which tend to be tens of thousands of blocks long for some
of our jobs).

How it works (more or less): For fixed length records, TAIL just seeks to
the desired record and dumps the file from there. For stream record formats,
it reads from the end of the file and counts backwards the appropriate
number of terminators, then seeks to that point and dumps the file from
there. For variable and VFC record formats, it has two modes. The default
mode is for it to seek to the end of the file and read backwards trying to
determine record boundaries based upon some reasoning. This will usually
work if the records are relatively short and there are few (preferrably  no)
control characters in it. TAIL trys to figure out if it is getting screwed
up, and sometimes it may, and will fall back to the "safer" mode if so. It
may not notice, however, so you can force it to use the "safer" mode with
the /S option. The "safer" mode is where it reads the file from the
beginning, recording the record file address (rfa) of each record as it goes
(modulo the number of desired lines). When it reaches the end of file, it
backs up through the rfa table the desired number of lines, seeks to that
point and dumps the file from there. It always uses the "safer" mode on
input files less than 128 blocks in size. In the "safer" mode, it doesn't
use RMS $GET calls for each record. Instead it reads up to 127 blocks of the
file at a time then decodes the record structure within that 64K of data.
This results in a substantially faster access to the end of the file than
would normally be  available with successive $GET calls. Monitor mode starts
the same way, however, once the record structure has been determined it does
successive $GET calls  to obtain the records added to the end of the input
file. Due to a "feature" of RMS, the input file has to be closed and
reopened in order to gain access to data added to the end of an already
opened file. Although this undoubtly adds overhead to the system (closing
and opening the file every few seconds) TAIL maintains the rfa of the last
record read, so it can seek to that record to get quick access to the "new"
records at the new end of the file.

BUGS:

Nothing major has cropped up since the image was released in 4/90. Since
this  release has so many new features, it has at least an equal number of
areas of  potential bugdom. Beware. Besides these new features, there
remains the old tried an true (but yet to happen to me) small possibility
that it could seek to a point in a variable length file that RMS doesn't
like (only while it is NOT using the "safer" mode). This doesn't seem likely
because I believe that RMS should like whatever record structure TAIL
decodes even if it is not the correct one. Should TAIL seek to a point in
the file that RMS doesn't like, however, one of several things might occur.
Probably RMS will return an "invalid record format" error. There is a slim
chance that RMS might bugcheck which would not be a nice thing to have
happen to you and if your SYSGEN option BUGCHECKFATAL=1, your system would
crash. If BUGCHECKFATAL=0, your process would be deleted. I suggest you keep
BUGCHECKFATAL=0 and use some care if TAIL'ing binary files (or chicken out
and always use /S on binary files).

Does not treat: <dir>file, only: [dir]file.

This program is getting to damn big and I can't remember how the hell it
works.


