The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...

the hash code in the proper DEC, and reallocating the space in the GAT provided the space
has not been reused by some other file.
Two other lesser used SuperVisor Call requests are @LOAD and @RUN. It's more important to
explain their use rather than illustrate their use. Most programs are stand-alone
programs. They are totally self contained in terms of the program code. When programs get
large or when programs must access large amounts of data in memory, it may be necessary
to segment the program into two or more sub-programs. Depending on the functions
performed by the program, this segmentation can take two forms. Where the functions can
be divided into separately chained processes (such as a language compiler that can
separate parsing from code generation), one sub-process can RUN the other sub-process.
Where the functions of the program must be divided up and controlled by a supervising
sub-program, the available memory can be divided into a resident sub-program region and
an overlay sub-program region - similar to the overlay structure of the operating system.
Thus the supervisor will LOAD each overlay as required and transfer control into the
loaded sub-program.
When an executing program needs to either @RUN or @LOAD another program, there is one
point that is most important to understand. Although the @RUN and @LOAD functions utilize
the system file buffer, they require a user File Control Block. Also, either request will
return to the calling program if an error is detected in the loading of the program file.
Therefore, it is essential that the program being loaded must not overwrite either the
FCB used to access it nor the error handling routines following the @LOAD or @RUN linkage
requests! To ignore this situation is to invite disaster to come knocking at your door.
6.3 ACCESSING DISK FILES
The concept of accessing disk files conveys the idea of transferring data to and from the
disk file. Before the file can be accessed, it must be opened as discussed in the
preceding section. Once a file has been opened, any of a number of file access SuperVisor
Call requests can be made depending on the specific nature of the desired function.
It may be useful to understand exactly how the operating system's file access routines
react in order to satisfy our request. Let us say, for example, that we want to read the
100th record of the BULKLOAD/DAT file. The 100th record has a record number of 99 since
records are numbered starting from record 0. We establish the linkage to accomplish this
as follows:
LD DE,FCB1 ;Point to the opened FCB
LD BC,99 ;Specify the record number
LD A,@POSN ;Identify the positioning SVC
RST 40 ;Invoke the SVC function
JP NZ,IOERR ;Transfer on error
LD HL,UREC1 ;Point to our record buffer
LD A,@READ ;Identify the SVC request
RST 40 ;Invoke the SVC
JP NZ,IOERR ;Transfer on an error return
The first part of the linkage positions the FCB so that the next I/O operation will deal
with record number 99 - the 100th record. After a successful positioning, the record will
be read into the record buffer. This is a very brief explanation. Let's examine in
detail, the sequence of steps actually executed by the file positioning routine, @POSN.
First, since the file's LRL is less than 256, the 100th record must be deblocked from the
sector containing the record (or sectors if by chance the 100th record spans two
sectors). By multiplying the record number (99) by the logical record length (80), the
value 7920 is obtained. This represents the first byte of the record in OFFSET position
240 of relative sector number 30.
6-9