Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

This file describes the features present in our implementation of SAIL
but not being described in the SAIL manual.  Most of these features are
not in the manual because they are specific to TOPS-10

			SFD's

Any routine that accepts a file spec will allow SFD's as part of the
directory.  Note that CVFIL has a problem in this regard, as it tries
to return the PPN in a reference integer parameter.  If the file spec
includes SFD's, there is no obvious place to put them.  I have taken
the quick and dirty route of returning a pointer to the path block in
place of a PPN.  This strategy is reasonable because the monitor will
accept such a pointer in any context where it wants a PPN.  Because
old programs may be expecting a real PPN, I do set !SKIP! in this
case.  However I set it to +1 for SFD's, and -1 for a real error.  Thus
new programs can be written to accept SFD's.

The project and programmer numbers can be omitted, as with PIP.
Thus [,,FOO] is the SFD FOO in your area.  [,] is your area. But
[] is 0, i.e. your default path.

			Batch jobs

SAIL knows whether your job is a batch job or not.  (It looks at a
GETTAB bit set up by the batch job controller.)  This is desirable
because of SAIL's error handling.  It normally goes into an interactive
error handler that asks the user what to do.  This is obviously 
undesirable in a batch job, because the error handler is liable to read
characters intended as input or commands.  Thus the interactive error
handler is not called for batch jobs.  In the compiler, SAIL assumes 
a line feed response to the error handler.  I.e. the compilation
continues.  This allows you to see the maximum number of errors.  In a
user program, SAIL aborts the program on the first error.

			USETI and USETO

There has been a problem previously with using USETI and USETO in
buffered I/O modes.  The problem is that the corresponding monitor
calls do not clear your I/O buffers.  Thus you can do a USETI, but you
won't see any data from the new block until you exhaust the data in
you current buffer ring.  (Of course there is no easy way to know how
much data you would have to skip over.)  Similarly, after a USETO,
nothing will go out to the block you specified until the current block
is filled.  Under the new version of SAIL, USETI and USETO both clear
the buffer ring.  USETI clears the input ring.  USETI and USETO both
force out anything in the output ring that hasn't gone out yet, if
any.  Thus the next SAIL I/O call will use the block you specified.
Do USETI before input and USETO before output.

Note that at Stanford the monitor clears the buffers as described
above.  Thus this change is mostly simulating what would happen at
Stanford.  However there output is only forced by a USETO.  Thus
I am not sure how one would switch from output to input at Stanford.
Here one would simply do USETI to the desired block, but at Stanford
that will not work.

USETI -1 is a special case.  It gets
you to the end of the file under TOPS-10.  (At Stanford another method
must be used for this.)  If the normal buffer clearing were done,
USETI -1 would set your EOF variable.  Since it is normally used as
a prelude to output, you do not want EOF set, probably.  Thus USETI -1,
as a special case, does not clear the buffer ring.

Mag tape positioning commands (MTAPE) have a problem with buffers
that is exactly the same as the problem solved by the USETI and USETO
patches.  Nothing has been done about this, however.  Should you be
in the middle of reading a tape and do a rewind, the next read would
get the next buffer in the ring, rather than the first thing on the
tape.  This can apparently be solved by closing and reopening the
device, however, so it did not seem to be worth troubling about.
(That would not work for USETI and USETO because closing the disk
also loses the file one is working with.)

			Buffering problems fixed

It was discovered that SAIL gave a different interpretation to the
byte count in the routines intended for ASCII files (INPUT, OUT,
NUMIN, etc.) and those intended for binary files (WORDIN, ARRYIN,
INOUT, etc.).  This meant that one could not mix those routines.
E.g. one could not use both INPUT and WORDIN for the same file.
Trying to do so resulted in losing characters from the file.  This
problem has been fixed, so it is now OK to use WORDIN with ASCII
files.  It will return the next character from the file, as an
integer.  Be warned that under TOPS-20 WORDIN will always return
the next 36 bits, even for ASCII files, so use of WORDIN to get
a character will make your program incompatible with TOPS-20 SAIL.
(There is another function under TOPS-20 to return the next
character, however, so the incompatibility is not serious.)

			Non-blocking I/O

The PSI routines supplied in SAI:SAIPSI should allow you to handle
non-blocking I/O in cooperation with the PSI system.  The only
problem was that you couldn't tell when an I/O operation had been
prematurely terminated due to no input being available.  The
runtimes would think they had set EOF, but input failures in
non-blocking I/O don't set any error bits.  Thus the runtimes
carefully set EOF to zero!  I have fixed the
runtimes to guarantee that EOF will be non-zero when an I/O
function takes the error return.  If all of the error bits are
zero (bits 760000), I set bit 010000, which previously the runtimes
always cleared.  Thus bit 010000 will always be set for a non-blocking
failure.  Probably this will be the only case when it is set, though
physical end of tape may also do it.  Note that it is perfectly
possible for EOF to be set in this way and for you to still have
valid data.  All it means is that the operation was terminated
prematurely (before your count was exhausted) because an input
failure occurred.  You should save how much you got and try to
get the rest when the next input available interrupt comes along.

			TMPIN and TMPOUT

TMPIN now deletes nulls and line numbers from the tempcore file being
read.  TMPOUT has been fixed so it no longer randomly sets bit 35 in
the words outputted.

			/A

Our default value of /A is /20A.  This gives you the linkage
appropriate for F10 for FORTRAN PROCEDURES.  This was done since
F10 is our default FORTRAN compiler.  To reverse this, specify
/0A in a REQUIRE COMPILER!SWITCHES statement.

Users should consider setting /26A.  In addition to F10 linkage,
this causes KI-10 instructions to be used for converting between
integer and real numbers.  However it causes rounding to be used,
while the default is trucation (FLOOR).

			COMPIL

A number of changes have been made to COMPIL to improve the ease of
using SAIL and BAIL.  Descriptions of the individual changes follow.

/BAIL

You may use the switch /BAIL:nn  It will pass /nnB to the compiler in
the appropriate place.  It will also cause COMPIL to look for a .SM1
file rather than a .REL file.  Thus your program will be recompiled if
it had not originally been compiled with BAIL.  If you use /BAIL alone,
i.e. without an argument, /BAIL:17 will be assumed.

DEBUG

The DEBUG command now uses BAIL as its debugger by default.  You need
not have any declarations or calls for BAIL in your program.  My
magic linkage will automatically put a call to BAIL in your program
before the first executable instruction.  When you get in this BAIL
breakpoint you can then set any other breakpoints you want.  That
breakpoint that I set up is immediately removed, by the way.  DEBUG
forces /BAIL:17, which in turn forces recompilation if your program
had not originally been compiled with /BAIL.  To debug with DDT,
specify DEBUG/DDT. Note that the linkage to BAIL used by DEBUG causes
the descriptors to be loaded for all SAIL runtimes.  Thus it
simulates the 20 bit in the /B switch.  However, these descriptors
are loaded only when the DEBUG command is used, whereas /20b would
have them in your core image even during normal executions.  Thus our
implementation saves some core.

/Y

Using /Y will cause your program to be loaded with the SAIL sharable
high segment (SAISG8).  Note that /Y must appear before or after the
first program name in the command.  Any later and it will not work.
/Y may be used with DEBUG as well as LOAD and EXECUTE.  (It has no
effect for COMPILE, of course.)