Data General RDOS

For the regional district, see Regional District of Okanagan-Similkameen. For the resident operating system on some Cromenco S-100 cards, see Cromemco RDOS.
RDOS
Developer Data General
OS family Data General
Working state Discontinued
Source model Closed source
Initial release 1972 (1972)
Latest release RDOS 7.5 / 1986 (1986)
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:

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.

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:

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:

References

  1. ↑ OS History - Data General Archived February 20, 2009, at the Wayback Machine.

Sources

This article is issued from Wikipedia - version of the 11/13/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.