Internals
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/1, 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
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.
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
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
"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
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]
