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

does exist, @RENAME should return either an "Illegal access to protected file" error (if
you do not have RENAME permission) or an "Illegal file name" error due to the duplicate
name. The @RENAME method uses slightly less system overhead and thus will execute faster.
It also will not attempt to set the directory's "file open bit" thereby performing one
less directory write.
6.2.4 Closing Files
The reverse operation of opening a file, be it @INIT or @OPEN, is the CLOSE operation.
Remember that files opened with UPDATE or greater access must be closed in order to
update the directory entry record. The updating process will change the modification date
and set the MODification flag bit if any writing has occurred. The updating process also
alters the end-of-file information if a sequentially accessed file has been either
extended or shortened. Finally, the updating process resets the "file open bit". The
CLOSE operation uses the information that the system has been maintaining in the FCB .
Thus, you close a file simply by passing the FCB pointer to the SuperVisor Call as
follows:
LD DE,FCB1 ;Point to the open File Control Block
LD A,@CLOSE ;Identify the SVC
RST 40 ;Invoke the SVC
JP NZ,IOERR ;Transfer on a returned error
6.2.5 Miscellaneous File Control
Before we leave the topic of file control let's address some lesser used control
requests. First we have the removal of a file. The system's REMOVE library command can
delete a file from the disk when at DOS Ready or command level. You could also remove a
file by passing a "REMOVE filespec" command line to the system via the @CMNDR SuperVisor
Call request. If we consider the DOS command level to be the highest level, then the
lowest level is via assembly language SVCs. The SVC method of file removal requires that
the file first be opened. The reason for this requirement is based on the overlay
structure of the system. The file control routines are resident in system overlays rather
than in the memory resident portion of the system like the file access routines. It so
happens that the routines to open a file are in an overlay (SYS2) different from the
overlay containing the routines to remove a file (SYS10). Since the system has no
provision for system overlays to invoke functions in other overlays, your application
program "supervises" the two functions of opening and removal. This linkage is as
follows:
LD DE,FCB1 ;Point to the FCB holding the filespec
LD A,@OPEN ;Identify the SVC
RST 40 ;Invoke the SVC
JR Z,OPENOK ;Continue if no open error
CP 42 ;Check on "LRL open fault"
JR NZ,RMVERR ;Error if anything else
OPENOK LD A,@REMOV ;Identify the SVC
RST 40 ;Invoke the SVC
RMVERR JP NZ,IOERR ;Transfer on a returned error
Notice that we did not need to reference a disk file I/O buffer since no I/O was going to
be performed (why waste the three bytes for the instruction?). Also, since we are going
to ignore "LRL open fault" errors, there is no need to put an LRL value into register B.
When the system removes a file, it first deallocates the space taken up by the file by
resetting the appropriate bits in the Granule Allocation Table. In the deallocation
process, all of the file's extended directory entry (FXDE) records are zeroed and their
corresponding Directory Entry Code (DEC) positions freed for future use. Then the hash
code is removed from the file's primary directory entry (FPDE) record DEC position of the
Hash Index Table used by the file. Finally, the ACTIVE bit of the FPDE record is reset.
The rest of the information in the FPDE is left unaltered. It is thus possible to
"unremove" a file that had a maximum of four extents by activating its FPDE, restoring
6-8