response to each file-related query determines how and where each
system file is accessed and positioned. REFRESH queries are
des-cribed in Section 3.4.3.3. The next section provides detailed
infor-mation on each of the system files.
Initialization Options
3.4.2 System Files
The system manager must know the purpose of each system file (Table 3-3) to use REFRESH properly. This section contains more detailed information on each of the system files noting the opera-tions performed by REFRESH.
3.4.2.1 BADB.SYS ~ Bad Block File
The bad block file permanently allocates bad disk segments and makes them unavailable for use by system and user files. The bad block file is required on all disks (except swapping disks) used under RSTS/E. The file length can be zero if there are no known bad blocks.
BADB.SYS is created during the pattern checks performed by the DSKINT option. A bad block is defined as a disk segment to which data can be written but the same data cannot be retrieved. Disks are usually not guaranteed to be error free. Hence, i t is important to perform the pattern tests when the disk is initialized. If bad blocks are found, the clusters (equal to the pack cluster size) containing the bad blocks are allocated to the bad block file. REFRESH only prints a list of bad blocks: the capability for adding blocks to the bad block file has not yet been implemented.
Initialization Options
3.4.2.2 RSTS.CIL - Core Image Library
The RSTS.CIL file contains the initialization code, monitor code, BASIC-PLUS compiler and Run Time System, overlay code, error messages, and usually the stand-alone program ROLLIN. This file exists only on the system disk. The CIL is loaded during system generation by
either the DOS/BATCH program CILUS or the stand-alone program SYSLOD.
When the system disk is initialized using DSKINT the CIL is preserved and mapped into the RSTS.CIL file.
The RSTS.CIL file cannot be moved by REFRESH and will always be located on the lower physical portion of the system disk. DSKINT creates the RSTS.CIL file at its minimum required size in the range of 250-350 disk segments of 256 words each. The size of the CIL de-pends on the monitor and BASIC-PLUS options included. As stated earlier, the size of the RSTS.CIL file can be increased by REFRESH to allow replacement of the CIL at a later time without disturbing the existing file structure on the system disk. The system manager per-forms new system generations as the installation requirements change.
Hence, the CIL file should be made large enough to cover any foresee-able additions to the system. At the time of the initial system generation, increasing the size of RSTS.CIL by 20 to 40 segments over the required size allows for replacement by a substantially larger monitor. If the contiguous file space immediately following the RSTS.CIL file is allocated to user files under normal time sharing, then i t may not be possible to increase the size of the CIL at a later time.
Initialization Options
3.4.2.3 SATT.SYS - Storage Allocation Table
The storage allocation table is a bit map used to keep track of disk space. Each bit in the map represents one disk cluster of_n
t --2!iiIiiiao
256-word segments where n is the pack cluster size. A one bit
repre-. ' "" i:! fl. n .~ J W .."".
sents an allocated (in use) cluster and a zero bit represents a free cluster. The SATT.SYS file is required on all disks (except swapping disks) and is created by DSKINT. The disk space mapped by the
SATT.SYS file on each disk includes only the actual space on that disk. The size of the file varies depending on disk size and the pack cluster size. The maximum size is 10 segments for all disk devices currently supported under RSTS/E.
REFRESH will permit repositioning of the SATT.SYS file on a moving head system disk. This capability is primarily used when no swapping disk exists and the swap files and other system files must also be located on the moving head device. Grouping all system files near the center of the disk tends to reduce average seek time for the moving heads.
Initialization Options
3.4.2.4 SWAPn.SYS - SWAP Files
During normal timesharing operations, user job images are fre-quently moved (swapped) to disk in order that other jobs can be
loaded into memory and executed. The REFRESH option is used to create the required swap areas or swap files according to installation re-quirements. Under RSTS/E there are four possible swap files called
SWAP~.SYS, SWAPl.SYS, SWAP2.SYS, and SWAP3.SYS. These system files may be located on the system disk, on auxiliary swapping disks, or on combinations of the system and swapping disks. Guidelines for creating an efficient swapping structure and the RSTS/E swap algorithm are described below. The material presented here should be fully understood before REFRESH is used to create the swap files.
SWAP~.SYS is the only required swap file. However, other swap files may be needed depending on the hardware configuration and the installation requirements. The sizes of existing swap files
limit the values of JOBMAX and SWPMAX which can be specified when using the DEFAULT and START initialization options. JOBMAX is the maximum number of jobs which can be run simultaneously. JOBMAX must always be less than, or equal to the maximum number of jobs configured during system generation. SWPMAX may be set to any number between 8
1
and 28 .'K) words. For the purpose of calculating the size of swap files, ~ provision is made for limiting certain jobs or even certain numbers of jobs to less than the system wide SWPMAX. Thus if any job is allowed to expand to 16K, the amount of swap space reserved for all jobs must be 16K each.
Each of the swap files holds an integral number of user job images determined by the size of the file and the desired SWPMAX.
The following equations describe the relations between size of the swap files, SWPMAX, and JOBMAX.
JOBS for SWAPn.SYS Size of SWAPn.SYS in segments (truncated) (Desired SWPMAX(K)
*
4)~
If more than one swap file is created, the total number of jobs which can be run simultaneously is equal to the sum of jobs accommo-dated by each swap file.
Initialization Options
The RSTS/E monitor uses four swap bit maps (one for each of the four possible swap files) to control allocation of swap space. Each bit map contains 4 words or 64 bits and each bit represents a swap
"slot" of size SWPMAX. In the bit maps, a zero bit represents an allocated slot and a one bit represents a free slot. Bit ~ (out of 64) in each map is always ~ (allocated). Thus each swap file and its corresponding map can handle the theoretical maximum of 63 jobs, or up to 63 jobs could be spread over 1 to 4 swap files (see Figure 3-2).
Swap slots are dynamically allocated when a job is swapped out to disk. The bit map is scanned forward for actively running jobs.
Hence, if SWAP~.SYS is located on the fastest swapping device, active jobs will be swapped to the fastest medium. If a job is inactive, the bit map scan is reversed. Hence, inactive jobs will be swapped to the higher numbered swap files.
This mechanism is used for several reasons. First, to handle multi-unit swap structures such as multiple RS03 and/or RS04 fixed head disks. RS03s and RS04s are addressed by unit in the same way that RP03 or RK05 drives are referenced by unit. A data transfer may not continue across a physical unit boundary. The RF1I and Rell fixed head disks are addressed as one unit regardless of the number of
platters. For these devices, a data transfer may continue across platter boundaries. Secondly, this method allows systems which only occasionally run many jobs, to operate with less fast swapping space.
Jobs which would overflow swapping space on the swapping disk(s) are simply swapped into a file on the system disk.
To demonstrate proper and efficient use of the swap files, several systems are considered. The first system requires only a single swap file to satisfy system requirements. The second case is when two swap files are used. The third is a large system that must use three swap files.
For the first example, consider a system that runs 15 jobs with the maximum size of 16K words. The required swap space in disk seg-ments is calculated as
SWAP SIZE
=
JOBMAX*
SWPMAX (in K)*
4 (SEGMENTS PER K)Initialization Options
I ... t---l 6 BIT S
- - - - t ..~1
~ SWAP~.SYS
BIT MAP 2
4 Up to 63 swap slots 6 in each file.
10 SWAP1.SYS BIT MAP 12
1 4