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.)