The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...
The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...
The Programmer's Guide to TRSDOS Version 6 - Tim Mann's Home ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Next, it would be very useful if the disk file I/O buffer already contained relative<br />
sec<strong>to</strong>r number 30. <strong>The</strong> Next Record Number (NRN) is the relative sec<strong>to</strong>r number. However,<br />
before we can make use of the NRN, we have <strong>to</strong> make sure that the buffer currently<br />
contains the sec<strong>to</strong>r identified by the NRN. To determine this, @POSN first checks the<br />
"buffer current" flag. If the buffer contains the sec<strong>to</strong>r identified by the NRN, @POSN<br />
then checks if the NRN and the sec<strong>to</strong>r number needed <strong>to</strong> satisfy the position of record 99<br />
are in agreement. If the file buffer currently holds the needed sec<strong>to</strong>r, it immediately<br />
transfers <strong>to</strong> a routine which checks on end-of-file conditions and returns <strong>to</strong> the caller.<br />
If the buffer does not contain the needed sec<strong>to</strong>r, then the NRN must be changed <strong>to</strong> the<br />
relative sec<strong>to</strong>r needed. But first the system must check <strong>to</strong> see if it has <strong>to</strong> write the<br />
buffer contents back <strong>to</strong> the disk file. This determination is based on whether the buffer<br />
is current and contains changed data which has not yet been written <strong>to</strong> disk (perhaps the<br />
result of a previous record written that did not span two disk sec<strong>to</strong>rs and thus did not<br />
require any physical writing).<br />
When the @READ request is passed <strong>to</strong> the system, again the system must first check if the<br />
disk file I/O buffer contains any data which is updated but not yet written <strong>to</strong> disk. <strong>The</strong><br />
@READ routine does not know that an @POSN request immediately preceded it. <strong>The</strong>n, since<br />
the LRL is less than 256, the @READ routine passes a series of character read requests<br />
for as many characters as that identified by the LRL. Each character is placed in<strong>to</strong> a<br />
consecutive location of the user record buffer, which in this case is UREC1. <strong>The</strong><br />
character read requests are virtually identical <strong>to</strong> those requested by an @GET SuperVisor<br />
Call request as both are performed by the same routines. Finally, the system adjusts the<br />
Next Record Number and OFFSET pointers so that the next @READ references the next<br />
consecutive record.<br />
We now have <strong>to</strong> look at what happens when a character read is requested. First, the system<br />
checks <strong>to</strong> see if the end of the file has been reached so it can return the "End of file<br />
encountered" error code. Next, it checks <strong>to</strong> see if the byte is contained in the current<br />
disk file buffer (i.e. if the buffer is current). If the buffer is not current, the<br />
sec<strong>to</strong>r identified by the NRN must be read from disk. Before the system even wants <strong>to</strong><br />
calculate what sec<strong>to</strong>r that represents, it has <strong>to</strong> ensure that the requesting user has READ<br />
permission <strong>to</strong> the file. This it can do by examining the access level s<strong>to</strong>red in the FCB.<br />
When it concludes that proper access is available, it proceeds <strong>to</strong> calculate the logical<br />
cylinder and sec<strong>to</strong>r that the file's NRN relative sec<strong>to</strong>r represents. If you thought the<br />
process was complex up <strong>to</strong> this point, hang on <strong>to</strong> your hat! <strong>The</strong> relative sec<strong>to</strong>r (remember<br />
number 30?) is converted <strong>to</strong> a relative granule number and relative sec<strong>to</strong>r offset in that<br />
granule. In this case, we will assume that the file is s<strong>to</strong>red on a 5-1/4" floppy disk ette<br />
formatted in double density with six sec<strong>to</strong>rs per granule. <strong>The</strong> system obtains the sec<strong>to</strong>rs<br />
per granule data from the Drive Control Table (DCT) for the drive containing the file.<br />
This means that the relative granule needed is granule number 5 (30 divided by 6). Since<br />
the remainder of the calculation is zero, the relative sec<strong>to</strong>r offset in that granule is<br />
number 0 which is the first sec<strong>to</strong>r of the granule.<br />
<strong>The</strong> system then examines the EXTENT fields of the FCB <strong>to</strong> determine what extent contains<br />
data covering relative granule number 5. To do this, the system uses the cumulative<br />
granule figures contained in the EXTENT fields. After determining that the granule is in<br />
one of the existing extents, the system can calculate the needed cylinder and relative<br />
sec<strong>to</strong>r in that cylinder by the following process. A few numbers may help this<br />
explanation. Say the file has two extents. <strong>The</strong> first extent contains three granules<br />
(numbered 0-2), while the second extent contains twelve granules (numbered 3-14) and<br />
starts on the third granule of cylinder 25. Figure 6-3 illustrates part of the second<br />
extent by cylinder and granule. First subtract off the number of granules contained in<br />
all extents previous <strong>to</strong> the desired extent and add the result <strong>to</strong> the starting granule<br />
number of the extent (5-3+2=4). Next, divide that result by the number of granules per<br />
cylinder derived from DCT information and keep the remainder (4/3=1 remainder 1). <strong>The</strong><br />
6-10