Linda, I used angle brackets () in the text whenever a key word/phrase is used for the first time. If it helps the article, these can be printed in bold face or other highlighting technique. A Walk Through RSX: Data Structures Operating systems are simply large programs. Like all programs, the code operates on supplied data to produce results. The better you understand how RSX works, the better you will be able to use the 'RSX program' to solve your problems. You can flip through the RSX sources and learn the algorithms but there is little overview material on the various executive data structures. This month's article looks at the purpose each RSX data structure and how the different structures are interconnected. One source of information on data structure format details is the RSX-11M/M-Plus Crash Dump Reference Manual. Appendix B and C list RSX system macros which supply the symbolic offsets and symbols for RSX-11M and RSX-11M-Plus executive data structures. Also, the Guide to Writing an I/O Driver Manual is good source for both overview and detailed information regarding device related data structures. Digital has published some other material which is very useful in studying RSX data structures. Unfortunately, the material are not wide available. In 1978, Digital published a two volume RSX-11M Logic Manual. The manuals offered a gold mine of insights into RSX system internals. Unfortunately, the manual set was never updated beyond RSX-11M V3.1. While overall concepts apply, the specific material is dated. The most current information on RSX system internals is available through Digital Educational Service's course on RSX-11M Operating System Internals. The first workbook volume on data structures and lists is excellent reference material. Unfortunately, the material is unavailable for direct purchase. A final source of information is your system itself. Almost all of the structures discussed in this article are present in your system. Crash dump analysis is one good method of freezing a system and looking at the structures at your leisure. In particularly, section 3.1.4 of the Crash Dump Reference Manual documents the various variables in the system common modules LOWCR and SYSCM. Many of these variables are the list and queue headers for the structures mentioned below. Tasks ----- In a previous article "The Mathematics of RSX" (September 85), RSX resources were classified into three types: CPU, memory, and devices. Most RSX executive data structures also fall into the same three classes. RSX schedules the PDP-11 CPU by task. A task is a executable program entity. Tasks are defined by two main data structures, the () and . Before a program can be run by RSX, a TCB must be created by installing the task image file. One field in the TCB points to the start of the task image file on disk. Other fields define the total program size when the task is loaded into memory and the initial size to read from disk when the program is started. With this information, RSX can activate a task very fast. The loader can input an entire task with a single disk read. No other directory or file I/O is needed. Other fields in the TCB become important after a task has been activated. The task priority, state, attributes, and local event flags are all kept in the TCB. Task control blocks are linked into two intertwined lists: the ) and the (). All TCB's are chained together in a single list to form the STD. The STD defines all potential programs. The STD is the list which is displayed using the MCR TASK command. The current active tasks are linked through another offset in the TCB. The ATL list is scanned by RSX when it searches for a task to schedule. The MCR ACT /ALL command list tasks in this list. TCB's are also found in other queues using the utility link word at offset 0. TCB's waiting for memory form a partition wait queue. After memory is allocated, the TCB's are passed to the task loader. Other data structures use various TCB fields as their list headers. The is a list of messages sent by other tasks. The first message in this list is input by the receive data (RCVD$) directive. A similar list is the . When a task spawns another task, an ( is created and linked to the new task TCB. When the child task exits, the OCB passes exit status back to the parent task. The final structure linked to TCB's is the (). The RSX AST mechanism was discussed in this column in the May, 1985 issue. Some special tasks use the Send/Receive Data Queue for alternate purposes. For instances, I/O packets are queued to ACP's using this list and TCB's are linked to the task loader. This is why such tasks cannot receive normal send messages. The is the other major RSX executive data structure used to define tasks. The task header holds the active task context. As such, there is no task header when the task is inactive. The task header is created when the task is initially loaded. Task headers checkpoint along with task images so the header is only in memory when the task is loaded. The task header is logically split into four components: a fixed part, the logical unit table, the window table, and the saved context. The fixed part defines the starting task address and current state information. The logical unit table maps logical units 1,2,...n to physical devices. The window table defines how the task virtual address space is mapped to physical memory. When the task is not executing, the contents of the general purpose and floating-point registers is stored in the saved context area. Memory ------ The () is the data structure used to describe memory allocation. RSX divides physical memory into partitions. A PCB specifies the name, type, starting address, and size of each partition. The PCB chain, starting at list header $PARHD, is ordered by increasing memory address. The first releases of RSX used very rigid partition boundaries. Memory was split into main partitions. Each main partition could be split into seven non-overlapping subpartitions. Tasks could run in each subpartition. A single task could be executed from the main partition, but any tasks in subpartitions would be checkpointed. RSX-11M V2.0 offered a new type of partition. The system partition generalized the concept of subpartitions. The operating system would dynamically create subpartitions in a system partition as needed to load task images. The partition size would match the task image requirements. RSX-11M-Plus V1.0 extended the concept to include data regions as well as tasks. A main partition PCB uses offset P.SUB as the listhead for all of its subpartition PCB's. The subpartitions are again ordered by increasing memory address. No structure defines free memory space. Rather, free memory is whatever space is between the end of one partition and the start of the next partition in the subpartition chain. Main and subpartition PCB's are also used to track the system checkpoint files. Whenever a new checkpoint file is created by the ACS command, a main partition PCB is created and linked to the list defined by $CFLPT. The checkpoint file block size becomes the partition size. Any checkpointed task shows up as a subpartition entry of the main PCB entry. Regions in memory can be used simultaneously by several tasks. For instance, a common data partition can share data between ten tasks. Partition access is defined by . The attachment descriptor links a task to a partition. Each attachment descriptor is in two lists. Offset A.PCBL links to the next descriptor associated with the partition PCB. Offset A.TCBL similarly links the descriptors used by a single task. Because task headers exist only when the task is in memory, the task header pointer is found in the PCB associated with the task. Typically, RSX references only the task header of the current active task. Therefore, whenever a task context switch is made, location $HEADR is updated to point to the new task's header. Devices ------- Most RSX executive data structures are related to devices and I/O. Seventeen structures are involved with devices or I/O requests. Additional structures may be required for specific devices. RSX-11M uses a set of three structures (five on RSX-11M-Plus) to define a device: DCB, UCB, and SCB. There is one () for each device type. For example, a system with one RM05 and three RP06 disk drives has one DCB for the RM05 and another for all RP06's. One field in the DCB names the device. Another set of fields classifies the 31 different RSX I/O function codes. The () is the key device data structure. The UCB defines a single device unit. In the example above, the RP06 DCB would point to the first of three contiguous UCB's. All RSX I/O is directed to a UCB. The logical unit table in the task header has a two-word entry for each logical unit number. The first word is the UCB address of the assigned device. The UCB is the only RSX structure which varies in length. While all UCB's pointed to by a single DCB must be the same length, there is no standard UCB length. Each device driver may define additional fields at the end of the UCB as needed. The total UCB length is kept in the DCB. A standard practice for RSX-11M-Plus systems is to define UCB extensions in secondary pool in order to minimize the impact on primary pool. The () is the last structure used by RSX-11M to define a device. The SCB contains information about the device controller. The RSX-11M I/O mechanism is designed to allow one outstanding I/O request for each device controller in the system. The SCB contains the I/O page address of the controller, the list head for outstanding I/O to devices connected to the controller, and information about the current I/O request. If the three RP06 drivers mentioned above are on a single controller, each UCB points to the same SCB. Any QIO's to the three disk drives are processed though the same I/O queue. If a second controller was used for one disk drive, a second SCB would be created. RSX-11M-Plus splits the SCB into two structures. The holds information releated to the hardware controller while the SCB is still used for the I/O queue and current packet fields. RSX-11M-Plus also defines a () which is used to name device controllers and provide a linkage to the corresponding DCB and KRB structures. The CTB and KRB structures give RSX-11M-Plus a better degree of granuality in naming devices and device controllers. In the RSX-11M scheme, a multiplexing device such as a DZ11 would have a separate SCB for each terminal line even though only one actual controller is present. The CTB and KRB structures provide a direct mapping for hardware controllers independent of any parallel I/O streams defined by SCB's. Initial versions of RSX linked all device drivers directly into the executive. The device vectors were directly mapped to the device interrupt service routine. Support for loadable device drivers required a new data structure to act as a (). An ITB is a block of code in pool which map the device driver using kernel APR5 and transfers control to the device driver. ITB's are created by either LOA or VMR when the device driver is loaded. The PDP-11/70 and PDP-11/44 CPU'S need a special data structure to handle the 18-bit Unibus address lines on a 22-bit machine. These CPU's use a hardware Unibus mapping register to split the 128KW Unibus address space into 32 4KW segments. Some of the UMR registers are permanently allocated by RSX to map the executive and terminal driver. The other UMR's are allocated on demand using the . The () maps a logical device name to a physical device UCB. The system chains all LCB's into a single list. Terminal specific assignments come first, followed by global assignments. When a task is installed or a logical unit assigned with the ALUN$ directive, the LCB list is scanned for the desired device. If found. the UCB address in the LCB entry is used as the device assignment for the logical unit table. An is an RSX I/O request. The RSX executive creates an I/O packet for each QIO directive and copies the I/O parameters into the packet. The I/O packet is then queued to the appropriate device SCB I/O queue. Extensive work has been done over the years to make QIO processing as fast as possible. One enhancement, for example, was to preallocate the I/O packet to eliminate pool allocation overhead. I/O packets are always 36 bytes long. RSX keeps a special list of free 36 byte packets. Whenever a 36 byte pool buffer is deallocated, the executive checks to see if the packet buffer list has reached its free limit. If not, the pool buffer is added to the preallocated list. Any pool allocation whose size is 36 bytes will come from the preallocated list. Note, send/recieve packets and PCB's are also 36 bytes long. Disk, tapes, and files have special data structures. The () is created when a disk or ANSI magtape is mounted. While the format of disk and magtape VCB's differ, the structures serve the same purpose. Each holds the volume label and attributes. The VCB's also hold the protection masks used to control access to the volume. The () is also a part of disk and magtape protection. Unless a device is mounted public, a user must have a MVL entry created by MOU in order to access files on the media. Whenever an file is opened for the first time, a () is created. The FCB's for a specific disk are chained together and linked back to the VCB. Whenever possible, the file system task (F11ACP) tries to allocate FCB's from its private pool. System pool is only used when the F11ACP pool is filled. If four tasks open the same file, only one FCB is created. However, F11ACP allocates each task a unique . The window block address is stored in the second word of the logical unit table (the device UCB is stored in the first word). The window block maps virtual block numbers to physical disk blocks. The window block also controls file access. The RSX executive uses a bit map in the window block to determine if open file can be read, written, and/or extended. For special files which were opened for shared read/write access, a is kept for each window. The lock block list is a set of blocks which are exclusively owned by the logical unit. The RSX executive will not allow any other logical unit, even in the same task, to read or write a block which has a locked block entry. Disk shadowing support in RSX-11M-Plus uses two executive structures, the and . A UMB defines a disk shadow set. It contains the current shadow status, catch-up fence, and pointers to the primary and shadow disk UCB's. The ML node contains the secondary I/O packet. The final structure related to devices and I/O is the (). Whenever a device driver encounters a controller error, it calls the executive to create a EMB packet which is passed on to the error logging task. Other Structures ----- ---------- There are some structures which do not fit into the classes of CPU, memory, or devices. The is a list of events which are to occur sometime in the future. Clock queue entries include task scheduling requests, mark time requests, and internal timer events. The later are used whenever executive or driver code needs to poll, for instance the terminal driver checking DZ11 modem control signals. The is a simple list of group global event flags. Each list entry corresponds to particular group number. Whenever the terminal driver receives a character for a unattached line with no outstanding read, it starts a . When the complete line is input, the terminal driver queues the buffer to the MCR task for further processing. If a is defined for the terminal, MCR will send the command line on to the chosen command line interpreter. RSX-11M-Plus keeps a variety of accounting data in secondary pool. Different structures keep track of tasks, users, devices, and the system. Chapter 17 of the RSX-11M/M-Plus System Management Guide documents how accounting works. You do not need a bit-by-bit knowledge of RSX data structures to program RSX. But the structures form the data base RSX uses to make its decisions. If you are aware of the existance and purpose of the various structures, you can begin tracking system problems down to their sources.