An Exposition on Sav in Rsx-11m-plus V2.0

Summary

This document, authored by Paul J. Bezeredi for Digital Equipment Corporation, provides a detailed technical exposition of the SAV utility within the RSX-11M-PLUS V2.0 operating system.

Purpose and Function: The primary intent of the SAV utility is to copy the current state of a running system from main memory back into the system image file on the disk. This allows modifications made since the system was booted (such as task installations or patches) to become permanent, eliminating the need to reapply these changes upon every reboot. It also enables system images to be made hardware-bootable and allows disks to be compressed without destroying the system's integrity.

Operational Concepts:

• Two-Phase Process: SAV operates in two phases. Phase one writes main memory to the system image file, and phase two restores the saved context to the CPU.
• System Image Bootstrap: A critical component is the "system image bootstrap," which reads the system image file into main memory. SAV manages special drivers for different disk hardware to facilitate this process.
• Pointer Management: A significant portion of the document details how SAV converts absolute disk pointers (Logical Block Numbers) into relative or "invariant" pointers (using File IDs) when saving, and converts them back when the system is restored. This ensures the system remains functional even if disk files are moved during compression.
• Strict Pre-conditions: The document lists numerous "quiescence" requirements that must be met before a system can be saved. If the system is not "quiet" (e.g., active tasks, open files, mounted volumes, or non-LB: installed tasks), SAV will terminate with an error to prevent potential system corruption.

Technical Architecture:

• Memory Resident Overlays: Due to size constraints, SAV is implemented as a memory-resident overlaid program.
• Special Drivers: These are specialized modules used to read/write system images. They must adhere to strict size and stack-usage constraints because they often operate within very limited memory environments (e.g., the hardware boot block).
• Restoration Process: The document provides a step-by-step breakdown of how the restored system re-initializes itself, including mapping registers, sizing memory, redirecting pseudo-devices, reinstalling tasks, and eventually initiating the startup command file and the pool monitor task.