Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to PRIMOS.
Nothing was collected or created yet.
PRIMOS
View on Wikipediafrom Wikipedia
| PRIMOS | |
|---|---|
| Developer | Prime Computer |
| Written in | FORTRAN, Assembly language |
| OS family | Multics-like |
| Working state | Discontinued |
| Latest release | 24.0.0.R52 / July 3, 1997 |
| Available in | English |
| Supported platforms | Prime Computer |
| Kernel type | Monolithic |
| Default user interface | Text-based user interface |
| License | Proprietary commercial software |
PRIMOS is a discontinued operating system developed during the 1970s by Prime Computer for its minicomputer systems. It rapidly gained popularity and by the mid-1980s was a serious contender as a mainline minicomputer operating system.
With the advent of PCs and the decline of the minicomputer industry, Prime was forced out of the market in the early 1990s, and by the end of 2010 the trademarks for both PRIME[1] and PRIMOS[2] no longer existed.[3]
Prime had also offered a customizable real-time OS called RTOS.[4]
Internals
[edit]One feature of PRIMOS was that it, like UNIX, was largely written in a high level language[5] (with callable assembly language library functions available). At first, this language was FORTRAN IV,[6] which was an odd choice from a pure computer science standpoint: no pointers, no native string type, etc.[7][8] FORTRAN was, however, the language most known to engineers, and engineers were a big market for Prime in their early years.
The unusual choice of FORTRAN for the OS programming language had to do with the people who founded Prime. They had worked for Honeywell on a NASA project.[9] FORTRAN was the language they had used both at NASA and, for many of them, at MIT. This connection with Honeywell extended to the point that the original Prime computers were compatible with Honeywell Series 16 minicomputers.
Honeywell, at that time, was uninterested in minicomputers, so they left and founded Prime, "taking" the code with them.[10] They developed hardware optimized to run FORTRAN, including machine instructions that directly implemented FORTRAN's distinctive 3-way branch operation.
Since Prime's hardware did not perform byte addressing, there was no impetus to create a C compiler. Late models of the hardware were eventually modified to support I-mode, and programs compiled in C.
Later, at version 16, a version of PL/I, called PL/P, became the high level language of choice within PRIMOS, and the PL/P and, later Modula-2, languages were used in the Kernel. Furthermore, some new PRIMOS utilities were written in SP/L, which was similar to PL/P.
The source code to PRIMOS was available to customers[4][11] and, thanks to FORTRAN and PL/P, customers could reasonably modify PRIMOS as needed. For example, around 1990, the University of Salford in the UK, modified the PRIMOS running on its five 9955 systems so that undergraduates could no longer use the MESSAGE command, that wrapped the PRIMOS SMSG$() call, to send messages to other undergraduates, because online "chatting" using that command was becoming rife, tying up terminals from the limited pool available. Messaging using that command was akin to SMS text messaging today, except a maximum of 80 characters could be sent per message.
Very early versions of PRIMOS (revision 6) were originally called DOS (PRIMOS 2) and later DOSVM (PRIMOS 3), but starting with PRIMOS 4, on the P400 system, PRIMOS was the name that stuck.[5] There were many major releases of PRIMOS. The last official revision (24.0.0.R52) was released July 3, 1997. By this time, a company called Peritus (which employed a number of ex-Prime engineers) was maintaining PRIMOS.
From Revision 19, major portions of PRIMOS were written in the languages SPL and Modula-2, the usage of the Prime Macro Assembler _(PMA), FORTRAN IV and PL/P declined considerably around this time. Programs were guaranteed to run on all current Prime processors (subject to sufficient resources being available), as well as all subsequent Prime processors.
In the versions of PRIMOS ca. 1977 and later, the filesystem included a distinctive construct known as the Segment Directory. Unlike more traditional directories, the files anchored in a segment directory were located using an integer index, effectively reducing searches of the directory to a simple hash function. Segment Directories were used in their Keyed-Index/Direct Access (KI/DA) file access system and in later versions of the system loader.
Data access
[edit]Indexed data could be stored in a MIDAS file: Multi-Indexed Data Access System and be accessed via COBOL or FORTRAN. Among the third-party tools was a package named Queo,[12] which was more powerful than COBOL despite being less verbose.
The PRIMOS character set was basically ASCII but with the 8th bit inverted. The original 7-bit standard for ASCII left the 8th bit unspecified, but on the commonly available Teletype Model 33 ASR, the bit was customarily set to 1, and this became Prime's standard. This is vital to realize when transferring data from PRIMOS to almost any other system.
User tools
[edit]By the time of Prime Computer's demise, a list of languages supported by Primos included:[13]
- BASIC – Prime BASIC compiler
- BASICV – Virtual memory BASIC compiler
- COBOL – COBOL compiler
- F77 – Compiles FORTRAN 77 or FORTRAN IV code
- FTN – Compiles FORTRAN IV code
- NCOBOL – Non-shared (non-virtual) COBOL compiler
- PL1G – Compiles PL/1, subset G code
- PASCAL – University of Sheffield Pascal
- PMA – Assembles Prime Macro Assembler code
Also available, but relatively uncommon, were:
- DBASIC – Interpreted BASIC with double-precision arithmetic
- RPG – Compiles an RPG II program (non-virtual)
- SPL – Compiles an SPL program
- VRPG – Compiles an RPG II program (virtual)
Scripting
[edit]Late versions[14] of PRIMOS included a scripting language, CPL (Command Procedure Language).[15] This interpreted language, bearing similarities to Pascal, was both accessible to novice users and capable of powerful command line automation. ESRI used PRIMOS CPL as a basis for the platform-independent scripting languages AML (for ArcInfo) and SML (PC-ARC/INFO).
This was a step beyond what already was available via:
- COMI – Command input (.COMI filetype)
- COMO – Command output – similar to a batch log file, but also usable interactively
PHANTOMS vs JOBS
[edit]"Phantoms" were a form of unattended background processes that immediately began to run in the background when initiated by the PHANTOM command. "Conventional" batch jobs were initiated via the JOB command, including the ability to schedule them for a particular time.
Fault Tolerance
[edit]The PRIMOS operating system incorporated advanced fault tolerance features to ensure system reliability and data integrity. One notable feature was the MIRROR_ON command, which facilitated the creation of a pair of logically equivalent, identical partitions that were maintained in real-time. This command was instrumental in enhancing the system's resilience to hardware failures. When activated, the MIRROR_ON command initiated disk mirroring, duplicating all write operations to a primary disk onto a secondary disk. This redundancy allowed the system to seamlessly continue operations using the mirror partition in the event of a failure of the primary partition. Unlike RAID 1, which typically requires specific hardware support for disk mirroring, the MIRROR_ON command implemented this functionality at the software level, offering a flexible and cost-effective solution for data redundancy.[16]
Networking
[edit]Primes's main offerings, each covering a specific need, were:
- PRIMENET
- RINGNET
- RJE
PRIMENET
[edit]Prime's PRIMENET software was designed to enable "transparent access to any system in the network without burdening the user with extra commands."[17] With PRIMENET, a user on System A could access files on System B as if they were on System A,[18] or even log into another system using the RLOGIN (Remote Login) command.[19]
RINGNET
[edit]Released similar timing to PRIMENET,[20] [21] it enabled high-speed local area networking.[22]
RJE
[edit]2780/3790 emulation was included.[23]
Primix
[edit]In 1985, Prime's port of AT&T's UNIX System V, called Primix, became available with Primos Release 19.4.2 that was modified to include Unix functions. It co-existed with PRIMOS, allowing users to switch back and forth.[24]
See also
[edit]References
[edit]- ^ US Trademark No. 73123025
- ^ US Trademark No. 73122880
- ^ abandoned, expired,"cancelled""The Ultimate Fate of Prime, PRIMOS".
- ^ a b "Comp.Sys.Prime FAQ". www.malch.com.
- ^ a b "Primos Internal Structure O.S. Notes - Computing History". www.computinghistory.org.uk.
- ^ "Prime MAN2602 Primos Interactive User Guide". Prime Computer. June 1976.
- ^ "history - Why was Fortran never used to develop an Operating System?". Software Engineering Stack Exchange.
- ^ mentions that the Burroughs MCP operating system was written in ALGOL.
- ^ "Oral History of John William (Bill) Poduska" (PDF).
- ^ It was public domain, having been written with NASA funding.
- ^ free at the beginning, but subsequently Prime charged
- ^ from Computer Techniques, Inc. OLYPHANT, Pa."Prime Users Offered Queo-IV Package". Computerworld. Vol. XV, no. 35. 31 August 1981.
- ^ "INTRODUCTION TO THE PRIMOS OPERATING SYSTEM, Part V". Archived from the original on 30 March 2019. Retrieved 11 September 2018.
- ^ "CPL - Primos command language (Computer Language)". Retrieved 11 September 2018.
Prime's command shell language, introduced with PRIMOS 18.2 in 1981
- ^ "Command Procedure Language (CPL)" (PDF). Archived from the original (PDF) on 12 March 2020.
- ^ "Operator's Guide to System Commands" (PDF). bitsavers.trailing-edge.com.
- ^ ".:: Phrack Magazine ::". phrack.org.
- ^ "INTRODUCTION TO THE PRIMOS OPERATING SYSTEM, Part II".
- ^ "INTRODUCTION TO THE PRIMOS OPERATING SYSTEM, Part IV".
- ^ "7.2-Prime Computers".
- ^ "Computerworld". IDG Enterprise. 31 August 1981 – via Google Books.
- ^ Allison Smith, ed. (22 October 2013). CAD International Directory 1986. Butterworth & Co. p. 228. ISBN 978-1483161471.
- ^ Fahey, Michael (26 October 1987). "Planning for open systems takes Prime Importance". Network World. Vol. 4, no. 43. IDG Network World Inc. pp. 1, 33–35 – via Google Books.
- ^ Desmond, John (20 May 1985). "Prime adds Unix environment for 50 series users". Computerworld. Vol. XIX, no. 20. p. 7.
External links
[edit]- Sourcecode Rev 19
- Usenet post of Jim Wilcoxson about the Prime 50-series emulator he created, running PRIMOS 19.2 (7 April 2007)
- Prime Computer FAQ from comp.sys.prime Usenet group
- Documentation
- Software
PRIMOS
View on Grokipediafrom Grokipedia
PRIMOS is a proprietary, multi-user, multi-tasking operating system developed by Prime Computer, Inc., initially released in the late 1960s as an evolution of a simple disk operating system (DOS) and later refined through multiple revisions to support minicomputer systems used primarily in engineering, scientific, and business applications.[1][2]
Originating from a rudimentary DOS written by Prime co-founder Bill Poduska over a single weekend in 1968 for the company's first 32-bit computer based on the DDP-516 design, PRIMOS underwent significant enhancements starting with version 4 in the mid-1970s, renaming earlier iterations like DOS (PRIMOS 2) and DOSVM (PRIMOS 3).[1][2] By the 1980s, it supported the Prime 50 Series minicomputers, such as the Prime 2250 to 9950 models, with features optimized for interactive and batch processing in resource-constrained environments.[3] Key capabilities included sophisticated virtual memory management using segmentation and paging, allowing up to 32 MB program sizes and 16 MB physical memory, alongside hardware-enforced memory protection and support for up to 128 asynchronous terminals and 255 concurrent processes.[3] The system featured a multilevel hierarchical file structure with access control lists (ACLs) for security, dynamic storage allocation, and direct/sequential file access, enabling efficient handling of large-scale data up to over 10 GB.[3]
PRIMOS was programmed initially in FORTRAN IV, transitioning to higher-level languages like SPL and Modula-2 by Revision 19, with assembly language used sparingly for performance-critical libraries to ensure broad compatibility across Prime's processor architectures.[2] It incorporated a comprehensive command-line interface with an online HELP facility, advanced networking via PRIMENET for inter-system communication, and support for languages including COBOL 74, FORTRAN 77, PL/I, Pascal, and BASIC/VM, alongside database management systems like a CODASYL-compliant DBMS and MIDASPLUS.[3] Performance was bolstered by microcode-assisted features, such as process context switching in 9 microseconds and hardware ring protection for security, reflecting Prime's "software first" philosophy where hardware was tailored to OS needs.[3] Revisions continued into the 1990s. The final official release, Revision 24.0.0.R52, occurred on July 3, 1997, while PRIMOS was maintained by Peritus, a firm of former Prime engineers. Prime Computer was later acquired by Parametric Technology Corporation in 1998.[2][4] Despite its discontinuation, PRIMOS gained popularity for its reliability in fault-tolerant environments and remains notable in computing history for powering early CAD/CAE workstations and contributing to the minicomputer era's emphasis on engineering productivity.[2][3]
To run:
History
Development
Prime Computer, Inc. was founded in 1972 by William Poduska and a team of engineers who had previously worked on the Multics project at the Massachusetts Institute of Technology (MIT).[5] The company initially focused on developing 16-bit minicomputers, such as the Prime 200 series, to compete in the growing market dominated by systems like Digital Equipment Corporation's PDP-11.[6] These early machines targeted scientific and engineering applications, emphasizing high-performance computing for technical users.[5] The initial operating system for the Prime 200 series was a simple disk operating system known as DOS, later retroactively designated PRIMOS 2, designed for single-user interactive program development on 16-bit hardware.[7] This system supported basic features like fixed-head or removable media disks, teletype interfaces, and included an implementation of FORTRAN IV, which facilitated its early adoption in scientific and engineering fields where numerical computations were essential.[8] The FORTRAN IV compiler optimized performance on Prime hardware, enabling efficient execution of complex simulations and data analysis tasks.[8] By 1975, Prime transitioned to the full PRIMOS name with version 4, introduced alongside the P400 system, which marked a significant advancement through the addition of virtual memory and multi-user support.[7] This version implemented segmented virtual memory with protection rings and a V-mode instruction set, allowing multiple users to share resources securely.[7] Key milestones in early development included the Prime 350 series, which from onward supported up to 63 simultaneous users under PRIMOS, expanding its viability for time-sharing environments in research and industry.[9] PRIMOS reached its peak popularity in the mid-1980s, becoming a widely used operating system for minicomputer-based computing in technical sectors.[6]Versions
The PRIMOS operating system began with version 2 in 1972, serving as a basic disk operating system (DOS) for the Prime 200 and 300 series minicomputers. It supported single-user operations without virtual memory capabilities, focusing on fundamental input/output and program execution on these early 16-bit systems.[10][11] In 1974, PRIMOS 3, also known as DOSVM, introduced virtual memory support for the Prime 300 series, enabling more efficient memory management and multitasking on hardware with expanded addressing up to 64K words. This version marked a shift toward multi-programming environments while maintaining compatibility with prior hardware. By 1975, PRIMOS 4 formalized the system's naming and enhanced multi-programming on the Prime 400, incorporating S-mode and R-mode instructions for improved security and resource allocation. These early releases laid the foundation for PRIMOS's evolution from a simple DOS to a robust multi-user OS.[10][11] Significant advancements continued with PRIMOS 18.2 in 1981, which introduced the CPL (Command Procedure Language) scripting language, allowing users to automate tasks and extend system functionality. PRIMOS 19.4.2, released in 1985, integrated support for Primix, Prime's variant of AT&T's UNIX System V, enabling coexistence of PRIMOS and Unix environments on the same hardware for broader application compatibility.[10][2] Later revisions extended PRIMOS's lifespan amid hardware advancements, culminating in version 24.0.0.R52 on July 3, 1997, which included enhancements for 32-bit systems like the Prime 50-series, such as improved memory addressing and peripheral support. Following Prime Computer's acquisition of Computervision in 1988 and the discontinuation of its minicomputer production in 1992, as the company shifted focus to CAD/CAM under the Computervision name and amid the rise of personal computers in the 1990s, maintenance shifted to Peritus Corporation, a firm of former Prime engineers that provided patches and support for legacy systems.[2][12] PRIMOS employed a version numbering scheme where major revisions (e.g., 19 or 24) denoted significant architectural or feature changes, while minor versions (e.g., 19.4.2) and revision letters (e.g., R52) indicated incremental patches and hardware-specific adaptations.[10][2]Architecture
Kernel Structure
The PRIMOS kernel employs a monolithic design, integrating core functionalities such as process scheduling, input/output operations, and device drivers within a single address space operating in ring 0, which provides unrestricted access to system resources while ensuring isolation through hardware-enforced protection mechanisms.[13][14] This architecture facilitates efficient handling of multi-user time-sharing environments by maintaining all essential services in kernel mode, minimizing overhead from inter-component communication.[14] Initially developed primarily in FORTRAN IV for its performance in numerical computations and system-level tasks, the kernel incorporated some assembly code for low-level operations; subsequent revisions transitioned to Prime's proprietary PL/P high-level language for enhanced maintainability, with later versions from Revision 19 incorporating Modula-2 for improved modularity and SPL for specific modules.[2][13] Approximately 70% of the kernel code was written in PL/P, 15% in FORTRAN, 10% in Prime Macro Assembler (PMA), 4% in Modula-2, and 1% in SPL, reflecting an evolution toward higher-level abstractions while retaining performance-critical elements.[13] The kernel is tailored to Prime hardware, supporting the V-mode instruction set with 588 total instructions, including 84 privileged ones for virtual addressing and system control, alongside S-mode and R-mode for compatibility.[13] User programs interface with the kernel through callable gated procedures, invoked via PCL/PRTN instructions that enable secure ring-crossing from user ring 3 to kernel ring 0, ensuring controlled access to privileged operations.[13] Central to resource allocation is the Segment Directory, implemented via Segment Descriptor Tables (SDTs) and Segment Descriptor Words (SDWs), which manage segmented virtual memory by defining segment attributes, protection levels, and mappings accessed through Directory Table Address Registers (DTARs).[13] Interrupt handling supports multi-user time-sharing through hardware-vectored mechanisms: external interrupts are acknowledged by the CPU and routed to Segment 4 offsets, while clock interrupts at 1/10-second intervals trigger the Phantom Interrupt Code to manage timers and process scheduling via semaphores like CLKSEM.[14][13] Microcode in the Control Store Unit (CSU) processes hardware interrupts efficiently, with up to 14 dedicated interrupt processes alongside 255 user processes.[13][14] Security is embedded in the kernel from early versions, featuring strong access controls via hardware protection rings (0 and 3) and discretionary Access Control Lists (ACLs) that enforce permissions for users and groups on resources.[13] An auditing subsystem, including the AUDITOR server and PROBES for event logging, captures security-relevant activities such as file accesses and process attachments, storing data in 4K buffers for analysis; this contributed to PRIMOS achieving a C2 security evaluation rating for government use in Revision 21.0.1.DODC2A.[13] Unlike Unix, which relies on a fork/exec model for process creation, PRIMOS uses spawn mechanisms via the SPAWN$ gate procedure to instantiate new processes, each associated with a Process Control Block (PCB) for state management, enabling direct resource inheritance without duplicating the parent environment.[13] The kernel integrates file system access through dedicated calls, such as those for locating and buffering segments, though detailed storage mechanisms are handled separately.[14]File System and Data Access
The PRIMOS file system is structured as a hierarchical tree, with the Master File Directory (MFD) serving as the root that organizes entries for User File Directories (UFDs), segment directories, and files.[3] UFDs function as user-specific containers for files and subdirectories, supporting nesting up to 16 levels to facilitate organized storage and retrieval.[3] A key component is the Segment Directory, which differs from UFDs by maintaining a numbered array of pointers to file locations rather than named entries, enabling efficient indexing for sequential or random access without reliance on filenames.[15] Files within this structure are composed of fixed-length 512-byte segments chained via pointers, promoting rapid positioning and data handling suitable for database and large-scale applications.[16] Data access occurs through kernel-mediated primitives such as READ and WRITE calls, which utilize segment-based addressing via segment tables to manage operations without employing traditional inode mechanisms.[17] These calls allow direct manipulation of segments by number, ensuring controlled and secure interaction with storage. For data integrity, PRIMOS integrates backup and recovery utilities like DUMP for creating archives and RESTORE (or MAGRST for tapes) for retrieval, both supporting magnetic tape media to enable full or incremental system backups.[18] PRIMOS further enhances accessibility by providing transparent remote file operations across networked systems via PRIMENET, where standard commands treat distant storage as local extensions of the file system.[19]Memory Management
Demand-paged virtual memory was introduced in PRIMOS 3, marking a significant advancement over earlier versions by enabling efficient use of physical memory through segmentation rather than flat paging.[10] This system allowed processes to operate in a larger virtual address space than physically available, with pages loaded on demand from disk storage. Segmentation divided the virtual memory into logical units, facilitating modular code and data organization while supporting sharing among processes.[14] The memory model in early PRIMOS implementations, such as on the Prime 200 series, relied on 16-bit addressing, limiting physical memory to up to 256 KB. Later versions, including those on the Prime 50-series hardware, expanded to a 32-bit model, supporting up to 32 MB of virtual memory per user through a combination of segmentation and paging.[20] Segments served as the primary allocation unit, with variable lengths up to 128 KB, allowing flexible yet bounded memory usage.[3] Segment swapping to disk provided backing storage for virtual memory, where inactive segments were moved to swap space to free physical RAM for active processes. The kernel managed global swap space allocation, ensuring balanced resource distribution across the system while preventing exhaustion. Hardware support was integral, with Prime's V-mode enabling virtual addressing for user programs and R-mode handling real-mode operations for I/O devices, thus isolating privileged access and enhancing security.[21] Per-user quotas limited the number of segments, enforcing resource controls to maintain system stability under multi-user loads.[14] Performance optimizations included pre-loading of common utility segments into physical memory to reduce initial access latencies, particularly for frequently used system commands. PRIMOS lacked copy-on-write mechanisms but achieved efficient memory sharing through segment references, where multiple processes could access the same segment without duplication, minimizing overhead. This approach integrated briefly with the file system by treating executable files as mappable segments, allowing seamless transitions between persistent storage and runtime memory.[20]User Environment
Command-Line Tools
PRIMOS provided a text-based command-line interface accessible via asynchronous terminals, supporting multiple concurrent user sessions for interactive operation, with limits up to 128 terminals in later revisions.[3] Users initiated sessions with the LOGIN command, which prompted for a username and optional project identifier, establishing the initial system contact.[22] Sessions were terminated using the LOGOUT command, which could target a specific user or all active sessions.[22] Core file management utilities included the DIR command for listing directory contents with wildcard support, COPY for duplicating files or directories (with options like -DELETE and -REPLACE), MOVE (also known as RENAME or CNAM) for relocating or renaming objects, and DELETE for removing files or empty directories, all handling PRIMOS file formats such as EPF.[22] These commands formed the foundation of interactive file operations within the CLI. PRIMOS distinguished between internal commands, built into the command processor for efficiency (e.g., CD to change directories, ECHO to display text strings), and external commands, stored as executable files in directories like CMDNC0 (e.g., EDIT for text editing, SORT for data sorting).[22] Internal commands executed directly without loading separate programs, while external ones were invoked by filename and supported additional parameters. The primary editor was the line-oriented PRIME EDITOR, invoked via the EDIT command, which supported macro definitions and subcommands like Append, Change, and Insert for text manipulation; early versions lacked full-screen capabilities, relying on line-by-line input.[22] Users could define macros for repetitive tasks, enhancing productivity in program development and file editing. System monitoring tools included the WHO command to list active users (with options like -ALL_DISKS for comprehensive output) and PS (or LIST_PROCESS) to display process statuses, including user environments and resource usage.[22] The DATE command handled date and time display or setting (e.g., -FULL for detailed format, -USA for regional style), integrating TIME functionality for precise system clock management.[22] Language support encompassed command-line compilers and interpreters for several programming languages, invoked directly from the CLI to build and execute code. These included BASIC (interpretive mode via the BASIC command), COBOL (via CBL compiler with optimization options), FORTRAN (via FTN or F77 compilers supporting fixed-point arithmetic), PL/1 (via PL1 or PL1G for structured programming), and Pascal (via PASCAL compiler generating executable formats like EX).[22] Each produced output in PRIMOS-compatible formats, facilitating development within the interactive environment.Scripting
PRIMOS's scripting capabilities center on the Command Procedure Language (CPL), an interpreted shell-like language introduced as a standard feature with revision 18.2 in 1981 to enable task automation and command sequencing.[10][23] CPL allows users to create procedures that intermix PRIMOS commands with language directives for control flow, supporting variables (local and global, with type checking for types like character, decimal, and tree), loops (via &DO &WHILE, &DO &UNTIL, and &DO &TO constructs), and conditionals (&IF &THEN &ELSE statements).[24][23] Scripts are stored in files with the .CPL extension and executed interactively via the RESUME command, which accepts positional and optional arguments with defaults and performs type validation.[24] Error handling is managed through the &SEVERITY directive, which controls responses to runtime issues (e.g., halting, ignoring, or invoking custom routines), while subroutine calls are implemented with &ROUTINE definitions, &CALL invocations, and &RETURN statements, permitting recursion and modular code.[24][23] Input/output redirection supports operations like > for directing command output to files, and integration with system calls occurs by embedding PRIMOS commands directly within scripts for seamless execution.[23] Batch scripting for non-interactive runs is handled by submitting .CPL files via the JOB command, enabling unattended processing, while scheduling of scripts mimics CRON functionality through the AT command for timed execution.[24] Early CPL implementations lacked pipes for command chaining, a limitation that persisted in initial releases but saw partial Unix-like enhancements in later versions such as 19.0.[10][24] Representative examples include simple backup procedures, such as a script that copies directories with logging:&ROUTINE simple_backup
&ARGS source:tree dest:tree
COPY &source/* &dest
ECHO Backup completed > backup.log
&RETURN
&ROUTINE simple_backup
&ARGS source:tree dest:tree
COPY &source/* &dest
ECHO Backup completed > backup.log
&RETURN
RESUME simple_backup mydata: newbackup:. User authentication scripts might use conditionals to validate inputs against system files before granting access.[23][24]
Process Management
PRIMOS features a multi-programming kernel that supports time-sharing, allowing up to 255 concurrent user processes to execute on the system.[3] The scheduler employs round-robin time-slicing with configurable priorities ranging from 0 to 3 for user processes, while system processes receive higher priorities; time quanta vary by priority, such as 0.3 seconds for high-priority tasks and up to 2 seconds for low-priority ones.[14] This scheduling is managed by the SCHED backstop process, which oversees ready queues including HIPRIQ for high-priority, ELIGQ for eligible, and LOPRIQ for low-priority processes, ensuring efficient context switching via the hardware-assisted Process Exchange mechanism that operates in as little as 9 microseconds.[14][3] In multi-processor configurations, the scheduler optimizes load balancing across CPUs through this firmware support, distributing processes to maximize throughput without detailed affinity controls.[3] Processes in PRIMOS are categorized into two main types: interactive JOBS, which represent foreground user sessions tied to terminals, and PHANTOMS, which are detached background processes designed for non-interactive tasks such as daemons.[14] JOBS are typically user-driven and terminate upon logout or completion, whereas PHANTOMS persist independently of user sessions, surviving logouts to run persistently for services like the clock daemon or network manager (NETMAN).[14] New processes are created using the SPAWN command for standard JOBS, which launches interactive or compute-bound tasks, or the PHANTOM command (often via SPAWN PHANTOM) for background ones suitable for servers or long-running utilities like compilers in detached mode.[14][3] PRIMOS does not support true threads within processes; instead, each operates as a single execution unit managed by its Process Control Block (PCB) in wired Segment 4 memory.[14] Resource allocation for processes includes per-process limits on memory segments, with each user able to access up to 4096 segments defining a maximum of 512 MB virtual address space, enforced through dynamic allocation in the DTAR table.[14] The system computes a MAXSCH limit based on available megabytes to cap schedulable processes, preventing overload, while each PCB allocates 64 words for process state.[14] Processes can be terminated using the ABORT command, which sets abort flags in the PCB, or via signals such as LOGOUTS that force immediate cessation.[14] For monitoring, the PS command provides details on active processes, including status, priority, and resource usage, aiding administrators in overseeing system load.[3] These mechanisms collectively enable robust process lifecycle management, with PHANTOMS particularly valued for daemon-like roles in servers and background compilation, distinct from the interactive nature of JOBS.[14]Fault Tolerance
PRIMOS provides robust fault tolerance through software-based redundancy and automated recovery mechanisms designed to maintain data integrity and minimize downtime in the event of disk failures or system crashes. Central to these features is the MIRROR_ON utility, which implements disk mirroring at the software level without requiring specialized hardware. This command pairs a primary disk partition with a secondary one, duplicating all write operations to both for redundancy while distributing read operations across the pair to enhance performance. Mirroring can be disabled using MIRROR_OFF, and a catch-up copy process synchronizes any discrepancies between partitions during initialization or maintenance.[16] System recovery is facilitated by tools that support booting from alternate devices and automated diagnostics. The SYSTEM_RECOVER command orchestrates post-crash restoration, analyzing crash dumps and reinitializing the system, with options like -COLD_RESTART for hardware-specific reboots requiring updated microcode. BOOT_CREATE generates bootable tapes from critical files, enabling restoration via BOOT_RESTORE from alternate media if the primary boot device fails. FIX_DISK acts as a key diagnostic utility, scanning file systems for integrity issues, repairing bad spots, truncating corrupted files, and resetting allocation pointers after improper shutdowns; it supports fast and interactive modes for efficient recovery.[16] Error handling and logging mechanisms further bolster reliability by capturing and addressing faults proactively. PRIMOS employs event logging through commands like ADMIN_LOG for customizable system event records and N_LOG for configurable retention of logs up to 365 days, with DISPLAY_LOG allowing filtered review by time, severity, or type. Security-specific logging via PRINT_SECURITY_LOG and SECURITY_MONITOR supports auditing in C2-certified secure environments, ensuring comprehensive recovery analysis. Hardware faults, such as disk read errors, are trapped and linked to affected file objects using RECORD_TO_PATH, guiding targeted repairs. Checksum integrity is verified at the segment level, with CRA mismatch errors detected during operations and resolved through FIX_DISK to prevent data corruption. Dynamic bad spot handling, enabled via -DBS ON during disk formatting, remaps defective records on supported controllers for SMD and other disk types, promoting graceful degradation without full system interruption. Crash dumps to disk, activated by CDD -ACTIVATE_DISK, reduce recovery time by storing diagnostics directly on secondary volumes instead of tape.[16] These features collectively enable PRIMOS to achieve high reliability in multi-user environments, with FS_RECOVER automating file system repairs post-crash to minimize manual intervention. While process management handles individual error termination, system-level tools like these ensure broader data and operational continuity.[16]Networking
PRIMENET
PRIMENET is a proprietary networking protocol developed by Prime Computer for the PRIMOS operating system, enabling transparent resource sharing across multiple Prime systems as if resources were local. Introduced in January 1979 alongside the Prime Series 50 computers, it supports communication over various media, including high-speed ring networks, point-to-point links, and X.25 packet-switched public data networks (PDNs).[20] PRIMENET facilitates seamless access to remote files, devices, and services, extending PRIMOS's local file system capabilities to networked environments through commands like ADDISK for mounting remote disks.[19] Key features of PRIMENET include remote login via the LOGIN command or NETLINK utility, allowing users to connect to remote systems with up to 64 simultaneous sessions; file transfer through the File Transfer Service (FTS) using tools like FIR for queued operations with automatic retries (up to 144 attempts over 72 hours); and print spooling, where files can be directed to remote printers using options like -DEVICE LP.[19] These services operate over X.25 protocols, providing reliable virtual circuit connections for data exchange between Prime systems.[25] The protocol supports multiple access methods, including HDLC for X.25, ensuring compatibility with diverse network infrastructures.[25] Architecturally, PRIMENET employs a client-server model with dedicated server processes such as NETMAN for managing connections and FTSMAN for file transfers, layered according to the ISO OSI reference model. Gateways enable route-through communication, allowing nodes to connect indirectly via intermediate systems, and support interconnections with non-Prime equipment over PDNs. While configurations via RINGNET limit networks to up to 247 nodes at 8 Mbps, broader setups using X.25 can scale to larger clusters.[19][20] Security in PRIMENET relies on user authentication through login passwords and remote user IDs, with the SYSTEM user granted full access while others are restricted by privileges; validation occurs via shared user directories on remote systems. Data integrity is maintained using cyclic redundancy checks (CRC), and privacy is enforced through locks and PDN access controls, though full encryption was not standard in early implementations.[19][20] Integration with PRIMOS allows transparent mounting of remote User File Directories (UFDs), enabling standard commands for file and device operations without protocol-specific syntax. Performance is optimized through dedicated links like point-to-point synchronous connections and queued processing to handle high loads, with configurable packet and window sizes for efficient throughput.[19] Common use cases for PRIMENET include cluster computing environments for engineering simulations, where it supports load sharing across multiple processors, database queries and updates via fast-select calls, and distributed data processing in multi-system setups.[20]RINGNET
RINGNET was a token-ring based local area network (LAN) developed by Prime Computer, Inc. in the late 1970s for its PRIMOS-based systems, with initial announcements in January 1979.[26] It connected multiple Prime minicomputers in a high-speed, unidirectional ring topology using serial-synchronous twin-axial cable, enabling efficient resource sharing at a single site.[19] The network operated at speeds of 4 to 16 Mbps, supporting up to 250 nodes, each assigned a unique ID from 1 to 247, with distances between attachment points up to 250 meters and extendable via amplifiers or repeaters.[27][19] Hardware for RINGNET included custom Prime adapters such as the PRIMENET Node Controller (PNC) boards that plugged into the system's I/O bus, along with junction boxes featuring passive relays for node interfaces.[19] Fault tolerance was achieved through a dual-ring design, where power failures at a node allowed pass-through operation to maintain connectivity.[19] Integration with PRIMOS was seamless via dedicated drivers and the PNCDIM software module, providing transparent access to remote resources; this supported PRIMENET protocols layered atop RINGNET for inter-system communication.[19][28] Key features encompassed broadcast messaging and multicasting for distributed applications, low-latency token-passing protocol, and direct memory access (DMA) I/O for packet transfers up to 2 Kbytes, optimizing throughput for real-time workloads.[27][19] In its evolution, RINGNET saw upgrades to fiber-optic cabling in the Prime 50-series systems during the mid-1980s, improving distance and performance for larger installations.[19] Compatibility with Ethernet was enabled through gateways via route-through connections, facilitating hybrid environments.[19] The network found primary application in connecting Prime computer clusters for compute-intensive tasks, such as computer-aided design (CAD) and computer-aided engineering (CAE) workloads, where its high-speed, low-latency characteristics supported collaborative engineering environments.[19][27]RJE
Remote Job Entry (RJE) in PRIMOS provided a mechanism for submitting batch jobs from Prime minicomputers to remote mainframe systems, emulating protocols such as those of the IBM 2780 and 3780 terminals to ensure compatibility with IBM hosts. This emulation supported binary synchronous communication (BSC) networks, including HASP II workstations, allowing PRIMOS systems to function as remote batch terminals over dedicated or dial-up lines using half-duplex, point-to-point synchronous links. Additionally, asynchronous data links were supported for broader connectivity, enabling the transmission of job streams without requiring dedicated hardware stations.[29][30] The primary interface for RJE operations was the RJQ command, which queued job streams—including programs, data files, and JCL-like control cards—for transmission to remote hosts. Users could create files interactively in the PRIMOS environment and then submit them using syntax likeRJQ pathname [-TO] queuename [queue-suboptions], where suboptions include protocol specifications and priorities to manage execution order in the queuing system. The RJQ command handled queue management, supporting options such as -DISPLAY to view status, -LIST for queued jobs, and -DEFER hh:mm for scheduled transmission, with integration into PRIMOS's batch queuing subsystem that included multiple queues (e.g., normal-1 for standard jobs, background-2 for lower-priority tasks). This setup bridged minicomputers to larger mainframes in enterprise environments, facilitating hybrid computing setups where Prime systems offloaded compute-intensive batch processing.[31][3]
Output from completed remote jobs was managed and returned by the RJE subsystem to the local PRIMOS system for review or further processing, often via the print spooler or file access mechanisms. RJE was strictly text-based and batch-oriented, supporting no interactive sessions, which limited its use to non-real-time workloads like report generation or data processing. Historically, RJE enabled efficient resource sharing in multi-vendor environments during the 1970s and 1980s, but it was phased out in the 1990s as TCP/IP protocols dominated networking, rendering legacy BSC emulations obsolete.[31][32]