Data General RDOS

RDOS
Developer	Data General
OS family	Data General
Working state	Discontinued
Source model	Closed source
Initial release	1972; 52 years ago
Latest release	RDOS 7.5 / 1986; 38 years ago
Platforms	NOVA, microNOVA, Eclipse
Kernel type	Monolithic
Default; user interface	CLI
License	restricted, per machine

RDOS (Real-time Disk Operating System) was a real-time operating system released in 1972^[1] for the popular Data General Nova and Eclipse minicomputers. RDOS was capable of multitasking, with the ability to run up to 32 what were called "tasks" (similar to the current term threads) simultaneously on each of two grounds (foreground and background) within a 64 KB memory space. Later versions of RDOS were compatible with Data General's 16-bit Eclipse minicomputer line.

A cut-down version of RDOS, without real-time background and foreground capability but still capable of running multiple threads and multi-user Data General Business Basic, was called Data General Diskette Operating System (DG-DOS or, now somewhat confusingly, simply DOS); another related operating system was RTOS, a Real-Time Operating System for diskless environments. RDOS on microNOVA-based "Micro Products" micro-minicomputers was sometimes called DG/RDOS.

RDOS was superseded in the early 1980s by Data General's AOS family of operating systems, including AOS/VS and MP/AOS (MP/OS on smaller systems).

Processing Model

RDOS was not designed to be a multi-user operating system or to support multiple applications running at one time. However, it did contain some provisions for multiprocessing. When the kernel booted up, it began by invoking a chosen application; by default, this was the Command Line Interpreter (CLI), although the system could be configured to start up a different application at boot time. (The separation of the user interface CLI from the operating system kernel, although typical of modern operating systems, was unusual at the time.) The CLI or other boot-time application constituted the top of a "stack" of application programs. Using the CLI, the user could invoke another application or utility. When this was done, the CLI was swapped out of memory and replaced by the invoked application, which then become level 1 on the stack. It was possible for an application to in turn swap itself out and invoke another application at level 2, and so on down to level 5. When an application exited, the next higher level application was "popped" off of the stack, loaded back into memory, and resumed at point where it left off.

The memory available to application programs was divided by RDOS and RTOS into two partitions, referred to as "background" and "foreground". On DG computers lacking memory management hardware, RDOS booted up with nothing in the foreground, and all applications ran in the background by default. A program could be made to run in the foreground using the CLI EXFG command or the system .EXFG call; however, on an unmapped system, the program had to have been previously linked to load into memory at an address above the top of the application running in the background. Before launching a program in the foreground, RDOS checked the memory break address of the background program and the start address of the foreground program, and it would refuse to load the program in the foreground if there was an overlap. It was not uncommon to have several versions of an application program, all with identical code but linked so as to load into memory at different foreground starting addresses, in order to accommodate different combinations of background and foreground applications. Additionally, the foreground application had no direct access to the system console; in order to interact with a user, it had to access the device files for the console or another terminal.

Systems with memory management did not have these programs. Each of the background and foreground partitions had its own system console, and both partitions started a CLI by default at boot time if so configured. RDOS arranged the memory mapping such that address space in both background and foreground started at address zero, so that it made no difference to a program if it ran in the background or foreground.

RDOS allowed programs to run multiple threads, which were referred to as "tasks". Tasks shared all context except for their accumulators, which were saved and restored by RDOS for each task. RDOS provided simple memory locking calls for managing critical sections. Tasks ran in strict priority order; at each change of context (triggered by a task making a system call, or a device interrupt), RDOS selected the highest priority ready task, without exception, as befitting a real-time operating system. Additionally, the foreground (if it was running) had priority over the background; a background task could run only when no foreground task was ready.

File System

RDOS supported a file system which was fairly sophisticated for its day, and contained some features of interest not found in modern operating systems. The file system supported both removable and non-removable disks (removable hard disks were more common at the time than they are today). It supported somewhat of a directory tree structure, although limited compared to modern operating systems. It allowed file names of a maximum of ten characters in length, with a two-character name extension that was often used to identify the type or purpose of the file. Case was not significant; all file names were stored in upper case. (Many user I/O devices of the time were not capable of producing lower-case letters.) A file name beginning with a '$' was a special file that provided access to an I/O device; these were "imaginary" files created by RDOS and they appeared to exist in all partitions and directories. Filenames were stored in the directory using a hashing method that could find a given filename quickly.

The structure of the directory tree consisted of a primary partition, a possible secondary partition, and a possible subdirectory. A primary partition was an entire disk; there was no higher-level tree structure that combined all of the disk devices under a single root. The name of each primary partition was determined by RDOS according to the device controller and unit number, and the device driver used to manage the device. Within a primary partition it was possible to create secondary partitions and subdirectories, and within a secondary partition it was possible to create subdirectories. Secondary partitions pre-allocated space (so an important project/user, allocated a secondary partition, could continue if space in the primary partition became exhausted by other uses/users). Individual files could exists at any of these levels. Nesting of secondary partitions or subdirectories was not allowed.

Two special files, named SYS.DR and MAP.DR, contained all of the information needed to manage each partition. The SYS.DR file was similar in concept to the inode table used in Unix filesystems; it was divided into fixed-sized data structures, each of which contained the essential information about a file, such as its name, size, location on the disk, time stamps, and attributes (permissions). The MAP.DR consisted of a bit map which identified which disk blocks were free to be allocated to a file. Each disk block (512 bytes) had one corresponding bit in the bit map, which was set to 1 if the block was allocated, and 0 if free. Under most circumstances, anytime the file system needed a disk block to allocate, it read through the map until it found the first free block, and used that block. This was not conducive to preventing fragmentation, and RDOS users developed various strategies for combating fragmentation; DG eventually released a utility which performed de-fragmentation in an offline mode. RDOS built the SYS.DR and MAP.DR files whenever the user formatted a disk; the SYS.DR file always began at a known fixed location so that the boot loader could easily find it.

Secondary partitions were fixed in size, and were walled off, in a sense, from the primary partition that they resided on. A secondary partition had its own SYS.DR and MAP.DR, meaning that it had its own pool of disk blocks to be allocated to files inside the partition; these blocks were unavailable to the enclosing primary partition. Subdirectories, in contrast, had their own SYS.DR but shared the MAP.DR, and therefore the pool of allocatable blocks, with the enclosing partition.

File Organization

An unusual feature of the RDOS file system was that it allowed the programmer to choose, when creating a file, how RDOS was to organize the disk blocks that would make up the file. There were three types of file organization available:

In serial file organization, each disk block allocated to the file contained 510 bytes of data. The remaining two bytes were reserved for a "block pointer", which was a data word that could be used to find the next or previous disk block allocated to the file. The block pointer consisted of the exclusive-or of the disk block number of the next block, and the number of the previous block. Because of the identity A xor B xor A = B, when reading through the sequential file, if one had the number of the previous block, this could be used to extract from the block pointer the number of the next block, and vice versa.

Serial organization was the most efficient way to store small files, such as text and source code files, that only needed to be read or written in sequential fashion. RDOS allowed the file pointer to be moved to create the illusion of random access, but actually performing it required the operating system to read through all of the intervening blocks between the previous location and next location, which of course incurred a significant performance hit. Also, direct block I/O (in which the disk data was transferred directly to or from user memory, bypassing the operating system's buffering) was not permitted with a serial file, because RDOS needed to protect the word that contained the block pointer.

In random file organization, RDOS created an index block which contained block numbers of data blocks. At 16 bits per block number, the index block could contain the numbers of the first 255 data blocks in the file. The last word in the index block contained a block pointer, in the same style as with the serial organization, to additional index blocks. (There were no multiply-indirect blocks in the style of the Unix file system.) This organization enabled efficient random access; when the file pointer was moved, RDOS only needed to calculate the new location and then obtain the block number for the proper block from the current index block, or at worst, read through a few additional index blocks to get to the needed one. The tradeoff was that the minimum size of a random-organization file was two blocks: one index block and one data block. This was inefficient for small files which did not need to be accessed randomly; for such files serial organization was used instead.
In continguous file organization, RDOS allocated a group of physically contiguous disk blocks to the file. This provided the fastest I/O in all methods of access, because in all cases RDOS could go directly to the needed disk block, and large reads and writes could often be accomplished in a single disk transfer operation. The significant limitation was that the size of a contiguous file was fixed at the time of file creation; a contiguous file's size could not be changed. Further, there was the problem of actually finding a sufficiently long string of available contiguous blocks; sometimes creating a contiguous file of non-trivial size took several minutes, and sometimes it was not possible at all if the disk was badly fragmented.

Symbolic Links

Later versions of RDOS supported a symbolic link capability. The symbolic link was a pseudo-file in the file system that, when accessed, would cause another file to be accessed instead. The symbolic link contained no data except for the name of the file that the link pointed to, which in RDOS parlance was known as the "resolution file". The resolution file could be in another partition or directory. It could also itself be a symbolic link, in which case a further level of indirection would be performed; linking up to 10 levels deep was permitted. The accessing application would be unaware that it was accessing a file other than the one it opened, unless it used a specific system call to find out if it was accessing via a link. All file operations, when directed at a symbolic link, would cause the operation to be performed on the resolution file, except for two system calls that were specific to creating and deleting links. This included file deletion and creation. If a file delete call was directed at a link, it caused the resolution file to be deleted. Conversely, a link could point at a file name that did not actually exist, and if so, a file create call giving the name of the link would cause the resolution file to be created. Unlike the mechanism used by most Unix file systems, the path and file name of the resolution file were stored directly in the link's SYS.DR entry, so that links took up no disk space. Files could have their link access attributes set via the CLI CHLAT command, so their permissions could be different (for example Readonly, or no linking permitted at all) when accessed via a link.

File Protection and Attributes

The RDOS file system provided means for protecting files by setting attributes. Because RDOS, not being a multi-user system, had no notion of file ownership, attributes applied to all programs that accessed a file. The sense of the attribute bits was, in most cases, the opposite of that in Unix; if the bit was set, the operation was prohibited. Files were by default created with all attribute bits cleared, permitting all operations. The attribute bits, as identified by the letters used to identify them in a file listing, were:

'R': prohibited reading
'W': prohibited writing
'P': "permanent file"; prohibited renaming or deleting the file
'S': identified a "save" file, that is, one that contains an executable program.
'N': prohibited symbolic links from linking to this file
'A': attributed protected; prohibited any further changes to the file's attributes. (A file that had both P and A set became un-deletable, except by reformatting the disk.)
'I': Prohibited reading or writing by means other than direct block I/O. (This was removed from later versions of RDOS.)
'?' and '&': User-defined attributes, ignored by RDOS

Spooling

The drivers for most low-speed output devices, such as $PTR (the printer device) and $PTP (the "high speed" paper tape punch) had the capability to spool the output. System calls, which could be invoked by a program or by CLI commands, allowed spooling to be enabled or disabled on a device, and also allowed spooled-up data to be deleted. The spooler obtained buffer space for spooling output by "borrowing" disk blocks from the file system. It kept track of blocks being used for spooling in a memory queue. This created a problem if the system crashed while output was spooled; when it came back up, it retained no memory of the blocks that were being used for spooling, and so those blocks were now lost to the file system — they were marked as used in the MAP.DR, but not assigned to any file. DG provided a stand-alone utility to fix this and other file system errors.

RDOS CLI

The Command Line Interpreter supplied with RDOS and its variants would start up automatically on the primary console. It used a syntax consisting of a command name, followed by zero or more arguments separated by white space. Command options were known as "switches" in DG parlance, and consisted of a slash character ('/') immediately following the command name or argument, followed by a single upper case letter; if there was more than one switch, they were separated by slashes. (For example, the command to list all files in the current directory, in verbose format, was LIST/A/V.) Both the command name and the arguments could have switches, whose meaning was interpreted by the program executing the command. Command arguments could also be grouped into comma-separated lists, enclosed by either parentheses or square brackets. (This was mainly used by the linker, to specify object files to be grouped into libraries or overlays.) Certain commands were built into the CLI; any command name not recognized by the CLI was assumed to be the name of a program to execute. Wild-carding of file names was supported, in a manner similar to common Unix shells; a '*' stood for a single character, and a '@' stood for a string of zero or more characters.

Some of the main commands were:

APPEND — concatenate files.
BOOT — reboot the system, possibly from a different boot device.
CCONT
CDIR — create a subdirectory.
CHAIN
CHATR — change the attributes of a file.
CHLAT — change the attributes of a symbolic link. (Directing CHATR at a symbolic link would change the attributes of the resolution file.)
CLG — Compile, Load and Go. This was a utility that invoked the Fortran IV compiler on a given source file, followed by the linker, and then executed the resulting executable file, all in one step. For self-contained source files which did not requirecomplex compiler or linker options, this saved the user from having to type in the separate commands.
CPART — create a secondary partition. A command argument specified the size of the partition.
CRAND
CREATE — create a file.
DELETE — delete a file.
DIR — change current directory (a "directory" in this context could be a primary partition, secondary partition, or subdirectory).
DISK — output the amount of disk space remaining.
EDIT — invoked a TECO-style text editor. This was a very basic, line-oriented editor; in later versions of RDOS, DG replaced this with a much more sophisticated (but still line oriented) editor called Superedit.
FG — execute a program in the foreground, from the background.
FORT — Invoke the Fortran IV compiler.
FILCOM
GDIR — output the name of the current directory.
GFCS — output the size of the largest contiguous file or secondary partition that can be created on the primary paritition of the current directory, given the state of disk fragmentation at the moment.
GMEM — On a system with memory mapping, this outputs the current foreground and background memory allocations.
GSYS
INIT — This command serves two functions. With no switches, it acts as the equivalent of the Unix "mount" command; it brings a disk online and makes it ready to use. With the /A switch, it performs a high-level format of the disk, writing new SYS.DR and MAP.DR files and effectively erasing everything on the disk. This served as a trap for the unwary; many a fatigued user accidentally erased a disk by inadvertently adding the /A switch when all they meant to do was mount the disk.
LINK — create a symbolic link.
LIST — output lists of names and properties of files in a directory.
LOAD — invoke the linker (referred to as the "relocatable loader" in DG documentation).
LOG — start/stop console logging, or add comments to the log file.
MASM — invoke the macro assembler.
RELEASE — unmount a disk. This was required to flush all buffered file I/O and ensure a clean file system state prior to unloading a removable disk. Oddly, it also served as the means for shutting down the system. Releasing the master device (the disk that the system was booted from) caused all programs to be terminated and all buffered I/O to be flushed. It then printed the message "MASTER DEVICE RELEASED" at the system console and halted the CPU.
SMEM — On a system with memory mapping, this sets how much memory is allocated to the foreground and how much to the background.
SPDIS, SPENA — disable and enable spooling on a spooled device.
SPKILL — purge spooled-up data for a device.
TYPE — output the context of a text file.
UNLINK — remove a symbolic link.

References

^ OS History - Data General Archived February 20, 2009, at the Wayback Machine

Sources

archive.org/sysun.com - RDOS at The Online Software Museum at the Wayback Machine (archived December 3, 2005)

External links

[OShist-1] OS History - Data General Archived February 20, 2009, at the Wayback Machine

[1]