Comp.Sys.Prime FAQ PRIME COMPUTER FAQ Last Updated28th by wuzhenguang


									  Comp.Sys.Prime FAQ


Last Updated: 28th August 1999

This FAQ is compiled by Richard Clarke (

Further Prime resources can be found at: (USENET)

The information presented here has been assembled from many
contributions and is included in good faith but use it at your own risk.

Thanks to everyone who contributed.



# Q) 1.1 How does my xx50 CPU compare to the others? <#L1_1>
# Q) 1.2 What is my Prime worth? <#L1_2>
# Q) 1.3 What can I use my 300MB disk drive for? <#L1_3>
# Q) 1.4 Why was Master Clear under a shield when Power was not? <#L1_4>
# Q) 1.5 What type of machines did the Specials group produce? <#L1_5>
# Q) 1.6 Does anyone have the CBL6124 pinout? <#L1_6>
# Q) 1.7 Wasn't there a Prime Supercomputer once? <#L1_7>
# Q) 1.8 What are the two phone plugs (T1 & T2) on the PT200 terminal?
# Q) 1.9 What is an EXL? <#L1_9>
# Q) 1.10 Wasn't there a Prime PC once? <#L1_10> S) 2.0 PRIME SOFTWARE
# Q) 2.1 What is/happened to Primos? <#L2_1>
# Q) 2.2 What were the features of the various Primos releases? <#L2_2>
# Q) 2.3 Why the strange PDEV numbers, such as 460, 21460, and 100461?
# Q) 2.4 What was the first revision of Primos which passed C2? <#L2_4>
# Q) 2.5 Why is CMDNC0 called that? <#L2_5>
# Q) 2.6 How do I emulate Unix "set-uid"? <#L2_6>
# Q) 2.7 What is/happened to Primix? <#L2_7>
# Q) 2.8 What do the files in the DIRECV directory do? <#L2_8>
# Q) 2.9 What's a V-mode .SAVE file? <#L2_9>
# Q) 2.10 What is a terminfo/termcap entry for a Prime PT200/PT250
terminal? <#L2_10>
# Q) 2.11 What CAD packages ran on Prime? <#L2_11>
# Q) 2.12 I heard that Primos had been ported to the ....., what
# Q) 2.13 I've got a Rev X MAGSAV tape, can I read it with Rev Y?
# Q) 2.14 I've got a MAGSAV tape, but no Prime... help! <#L2_14>
# Q) 2.15 Anyone know about the HERO monitoring package? <#L2_15>
# Q) 2.16 Problems stopping/restarting printers <#L2_16>
# Q) 2.17 Prime ASCII <--> Unix ASCII conversion problems <#L2_17>
# Q) 2.18 R-mode, S-mode, etc: What were they? <#L2_18>
# Q) 2.19 What's an EPF? <#L2_19>
# Q) 2.20 Any way to transfer files off a Prime? <#L2_20>
# Q) 2.21 SCCS Anyone? <#L2_21>
# Q) 2.22 PKZIP or GZIP for Prime? <#L2_22>
# Q) 2.23 "Watch" programs, etc. <#L2_23>
# Q) 2.24 Issues involved porting to Primos <#L2_24>
# Q) 2.25 What drives does Primos support? <#L2_25>
# Q) 2.26 How can I print to/from Unix, Novell, VMS or NT using a Prime?
# Q) 2.27 Prime Information <#L2_27>
# Q) 2.28 I miss ED, what can I do? <#L2_28>
# Q) 2.29 Is there an LPR for the Prime? <#L2_29>
# Q) 2.30 What is Primeway? <#L2_30>
# Q) 2.31 Does Primos handle Year 2000 correctly? <#L2_31>
# Q) 2.32 What do I do with my CPL programs if I move to Unix? <#L2_32>
# Q) 2.33 Porting INFORMATION to relational databases <#L2_33>
# Q) 2.34 16 node limit on Prime Gateways <#L2_34> S) 3.0 THE INDEX
# Q) 3.1 What the h*ll is DEREMER? It doesn't seem to do anything at all!
# Q) 3.2 What does the MAKE_BINARY program do? <#L3_2>
# Q) 3.3 What is the difference between SPL and NEW_SPL? <#L3_3>
# Q) 3.4 What does BUILD do? <#L3_4> S) 4.0 THE PRIME COMPANY
# Q) 4.1 How did Prime start? <#L4_1>
# Q) 4.2 What happened to Prime Computer, Inc? <#L4_2>
# Q) 4.3 Who were all the people on the front of the Prime manuals?
# Q) 4.4 What was the history of Prime? <#L4_4>
# Q) 4.5 Why did Prime never get its act together on the Unix front?
# Q) 4.6 Anyone have the Prime yearly financial figures? <#L4_6>
# Q) 4.7 What were Prime offering in 1972? <#L4_7> S) 5.0 THE PRIME
# Q) 5.1 Nominations: "Most interesting use for a working Prime system"
# Q) 5.2 Humourous anecdotes about Prime <#L5_2>
# Q) 5.3 Nominations: "Most anal behaviour by a systems administrator"
# Q) 6.1 Where can I get support? <#L6_1>

        Q) 1.1 How does my xx50 CPU compare to the others?

Year Model MIPS Relative Performance Index [RPI]
---------------------------------------------------------- 1972 200 .1
1973 100 .1 300 .25 1976 400 .5 1977 500 .6 350 .5 1979 450 .5 550-II .7
.6 650 .6 750 1.0 .9 1980 150 .5 250 .5 1981 850 2 1982 2250 .5 .35
Rabbit 1983 9950 2 1984 2550 .7 9650 .9 2650 .9 9750 1.5 1985 9955 3 2.4
9655 1 1 2655 1 1 1986 2350 .7 .55 2450 1 .9 9755 2 1.8 9955-II 4 3.3
Penguin 1987 2455 1.2 Remora 2755 1.2 1.15 Shark 6350 8 4.8 Leopard 6550
16 Panther 1988 4050 1.5 1.4 4150 2 1.8 2850 1.5 2950 2 4450 4 3.3 6150
6.5 3.9 1990 6450 10 6650 20 1992 5310 Vertical Slow Bobcat 5320
Horizontal Slow Bobcat 5330 5 Vertical Bobcat 5340 5 Horizontal Bobcat
5370 8 Stallion Dual-CPU Systems Some machines had two CPUs. As far as
this editor knows no Prime ever released had >2 CPUs although a field
analyst once told me that Primos had been tested on a four-CPU
configuration. The twin CPU machines are: 850 (2x750) 6550 (2x6350) 6650
(2x6450) 5370 (2x5340) In the MIPS column for these machines above, I
have just doubled the base machine MIPS rating, which I am sure will
turn some purists' hair white! The two CPUs in the 850 were arranged in
a master-slave configuration (I know because our college had two)
whereas the CPUs in the 6550 were equal peers. The 5370 dual CPU was a
single board. Facts & Figures The 300 was about .25 MIPS. It had
primitive virtual memory, with a 256KW physical address space, 64KW
virtual address space, separate 128-entry page map for each user, 4
Content Addressable Memory registers for the most recent page map
entries, 512 word pages. To enter virtual memory mode, one loaded the
page map register (PMAR) with the page map address and used the EPMJ
(Enter Paging Mode and Jump) or EVMJ (Enter Virtual Mode and Jump)
instructions. (Memory sizes were always expressed in words at the time,
since the addressing was to the 16-bit word.) Some P300s had a Writeable
Control Store (WCS) option which allowed users to develop custom
microcode. A typical "loaded" P300 configuration: a 16K word (32K byte)
RAM board, 256K fixed-head disk for paging and 3 M cartridge drive
(1.5MB fixed platter and 1.5MB removable cartridge.) The Prime colors
for the 300 were yellow and black. (This was the 1970s!) The cabinet was
taller than later models and the control panel was a flat unit that
snapped onto the front of the cabinet. They also had a small cabinet
(similar to a PDP-8e) for the 100 and 200 that used the same control
panel. Then they introduced the orange and beige "bump plate" design
that carried into the 50 series. The 400, 350, 550-I, original 450, 150,
and 250 are all essentially the same machine! By ungrounding a few
signals, and changing the firmware, any of these could be made into any
other of the CPU's. These machines are about .5 mip. The 500 added
floating point hardware (as opposed to firmware floating point, and the
decimal instruction set in hardware) to the mix, and gave considerably
better floating point and COBOL performance. The 650 was a remodeled
500, both are about .6 mip. The 550-II is a 650 with an 8k cache instead
of a 2k cache, and about .7mip. The 2250 was based upon the 550, and is
also about .5 mip. The I1000 was a P400, the I450 was a microcode
enhanced 550 for Information. I am informed that the "Information
Enhanced" CPUs only had a couple of extra instructions, and whether they
were actually used is doubtful. The 750 was a true 1 MIPS engine. The
850 was a pair of 750s. The 2550,and 2350 are exactly the same CPU set,
both are about .7mip. However they had significant improvments in Cobol
and I/O over the 550-II. The 2350 served up to 16 users, supported up to
8MB Memory, and and up to 240MB disk storage [gasp!]. It required only
one-quarter the floor space of the Prime 2655 system. The 2650, and 9650
were essentially the same machine, and about .9mip. The 9655, 2655 and
2450 are exactly the same machine, and about 1 mip. They had a two-stage
instruction execution pipeline, advanced gate array processor design,
and utilized an advanced Schottky implementation of TTL logic. The 9655
accommodated 10 input/output controllers, up to 8 MB main memory, and up
to 128 terminals. The 2655 had 16Kb cache memory, up to 8MB main memory
and supported up to 64 terminals. The 2450 served up to 24 users, and
supported 8MB memory and 240MB of disk storage. The 2755 and 2455 are
enhanced version and support 16mb memory at about 1.2 mip. The 9950 and
9755 are in fact the same machine, and about 2MIP. Featured: 16Kb cache
memory, up to 16 MB MOS memory. Supported up to 192 terminals and 255
simultaneous processes. ECL circuitry, burst-mode input/output and
five-stage synchronous pipeline architecture. The 9750 is about 1.5 MIP
The 9955 is about 3 mip The 9955-II and the 4450 are the same machine,
about 4 mip. The 6150 is about 6.5 mip The 6350 is about 8 mip 4050 and
2850 are the same machine, about 1.5 Mip. 4150 and 2950 are the same
machine, about 2 mip The 6450 was the fastest engine ever released. It
was rated officially at 17.2 dhrystone MIPS, but was probably around 10.
The 6650 was the fastest Prime ever released. It had a pair of 6450
cpu's, and while CV rated it at about 26MIP, the relative performance
and hardware data suggested that each engine was really only about
10mip. The last 50-series machine ever was the 5370, which had a pair of
5340 like engines, each of which was about 4 MIP. Unlike other dual
processor machines which essentially had 2 identical CPU board sets, the
5370 dual CPU is contained on one board. It does not have the on-board
memory connectors that the 5340 has. Other 53xx machines were either
slow versions of the 5340 and/or cabinets turned sideways to reduce
floor space. The problem was when the 5000 family was announced, each of
the 5340 engines was supposed to be about 8mip. The failure to deliver
the promised performance on the 5300 and 5500 series processors was the
final nail in the coffin. CV was already far far behind in the
performance race, most of the big customers were forced to leave because
Prime/CV simply could not deliver the raw horsepower that was needed.
The 55xx machines were the "Garfield" machines. (The whole project was
known as the "Toons" project - everything was named after cartoon
characters.) This was the CPU project in the works at the time the
50-series business unit was shut down. It was never completed. The great
MIPS debate You may notice that the MIPS figures given above do not
tally with marketing literature. These numbers are based upon two
sources. The Field service manuals for many of these systems have fairly
detailed writeups on average instruction timings. For a 6350 the average
instruction timing was about 122ns, which translates to just over 8 MIP.
The 4450 has a substantially different rating than the 9955-II because
Prime went from using Whetstones to Dhrystones in between. If you check
the relative performance Index (RPI) from Prime Marketing notices 701,
you can get the picture pretty accurately. They later use a different
index, MUI, which gives better numbers,however, the relationship between
the two is pretty well fixed. 1 MUI turns out to be about .5 RPI. If the
750 is a 1 MIPS engine, and the 6350 is really an 11 MIPS engine, how
come the Relative performance numbers show a ratio of about 5.5 instead
of 11? The 4150 is supposed to be about 4.2 mips, however its RPI
numbers are the same as the 9755 that measures a real 2 MIPS. The 4450
is claimed to be 5.8mip, the 9955M2 is claimed to be 5 mip, they are in
fact the same board set (and have identical Relative performances). The
2755 is quoted in the literature as a 1.6 MIPS engine, however its
performance is only slightly better than the 1 MIPS engine, and if you
measure the raw arithmetic performance (which we used to do to calculate
Processing Data Rate (PDR), which is the measurement the Department of
Commerce used to use for export control), the 750 was measurably faster
than the 2755 (about 10% faster in fact). Interestingly enough, the PDR
on the 6350 is almost exactly 8 times the PDR on a 750. I submit that
since all of these machines have essentially the same instruction set
and run exactly the same applications, that the relative performance
relationships are probably a good indication of true relative
instruction rates.

        Q) 1.2 What is my Prime worth?

The short answer is: "Not a lot!". This is the case even if you have one
of the last Prime CPUs such as the 5370 or 6650. Check out our "rough
guide to Prime pricing": 2250 - same as a 3KW electric fire - $50 9955 -
same as a good heavy boat anchor - $250 Seriously though, and painful as
it is for a Prime hacker to admit, most Primes can be purchased for
little more than the cost of removing them from their current owner, and
then only to serve as a source of spares for an existing installation.
This is because maintenance is horrendously expensive, but the
investment made in software may require these "legacy" systems to be
kept running for the foreseeable future. Prime hackers keen to preserve
memorabilia in their garages and spare rooms should be aware that Primos
itself is actually licensed to a company or other body, not a CPU. The
license is non-transferrable. So technically, having loaded your 4150 or
whatever onto the back of a pickup, you would need to contact CV and pay
a license fee before you could power it up. I believe a company called
Storage Computer supplies disk upgrades (in the form of RAID arrays) for

        Q) 1.3 What can I use my 300MB disk drive for?

* Spin art. Open the top while the disk is spinning and slowly pour one
cup of coffee on it. Do NOT call Field Support for a replacement. *
Drying your socks. * Gum wrapper collector. Power unit down and check
the floor filter.
        Q) 1.4 Why was Master Clear under a shield when Power was not?

Huh? I have a P200 front panel around here somewhere that doesn't have a
shield on either button (actually, they are switches, not buttons).
Buttons didn't come into use until the first VCPs were released for the
first real 50-series machines (750, 550, 650). It was for safety
reasons, so you could hit power off in a hurry.

        Q) 1.5 What type of machines did the Specials group produce?

One interesting system was the T3300. This was based on either a 2655 or
2550 processor and was notable for meeting the US Defense Department's
"Tempest" standard. "Tempest" is a US Military standard on radiation
leakage. (Electromagnetic radiation) Prime sold a bunch of systems to an
unnamed US Government agency that were hardened to Tempest standards.
The test program would take material as it arrived on ASYNC lines and
save or print messages that contained keywords. The sample keyword list
included "Nixon" and "Vietnam". All of the above was unclassified. At
least one of these machines met a known fate. When the Iranian
"students" took over the US Embassy they took what they called a "US Spy
Computer" out into the courtyard and executed it. From the news footage,
it was clear that this was one of the Tempest Primes. If you look at the
file CPUID$.INS.PL1, you'll notice there are three 9955's: 9955, 9955-T
(Tigger) and 9955-II. The 9955-T was a modified 9955 which supported
32MB RAM and was made for Premier Systems, Inc.

        Q) 1.6 Does anyone have the CBL6124 pinout?

1) 2 and 3 crossed 2) 4 and 5 tied together on each end 3) 7 to 7 4) 8
on DB-9 to 8 and 20 on DB-25 5) 9 on DB-9 to 6 on DB-20 Many machines
will run with just 2,3,7.

        Q) 1.7 Wasn't there a Prime Supercomputer once?

There were two different product lines here (or three?). The EXL series
was a 386 tower box that sat on the floor. The box OEMed from Sequent
was a tightly coupled network (hypercube?) of 386s. That product was
discontinued not because of market size, but because of competition from
Sequent. The MXCL was a mini-super OEMed from Cydrome. Dick Green used
to refer to these as mini-Cray's or Crayettes. We sold maybe one of
these boxes before we gave up on that one. Just goes to show that Prime
doesn't Cray.
        Q) 1.8 What are the two phone plugs (T1 & T2) on the PT200

The PT200 Service Manual simply refers to them as "NOT USED". A partner
in my office examined the board and it appears that they connect to the
graphics option. There does not appear to be any end-user purpose. There
is a little plastic "notch" in the bottom part of the case, to the right
and above all the connectors, where the (very thick) PC board cable goes

        Q) 1.9 What is an EXL 7330?

The 7330 was based on the MIPS RC3230. It is a RISC based architecture.
The 7330 was a 25mhz cpu, the 7333 (RC3330) was 33mhz. I believe you
could expand the memory up to 128mb using 4mb simms. The CPU board had
an on-board SCSI and ethernet controller. I believe it also included an
ISA expansion slot for a serial i/o controller. The OS was a MIPS
proprietary Unix and I believe it was called RiscOS. The unit came
standard with either a Seagate ST4766N or ST41230N (673mb or 1gb). I
know that there were drivers included for smaller drives but I don't
think there were many bigger drives that could be run on it. It also
came standard with a 150mb QIC tape drive, and there was an optional
Exabyte 2.3gb 8mm.

        Q) 1.10 Wasn't there a Prime PC once?

Prime bought the design for the Prime PC from a failed startup. The
startup had completed and debugged the design, then went under. Despite
the nearly complete state of the PC, it still took Prime a year before
they got it out. Being a previous generation PC (8086?), it was
effectively stillborn. Prime had previously lined up a JMA with Apple
Computer, which John Scully actually pre-announced at a MacWorld. Prime
might perhaps have even purchased Apple in the early days, but all this
was abandoned for this wonder of engineering (the Prime PC). Pity.

        Q) 2.1 What is/happened to Primos?

Primos was Prime's operating system. It is an indication of the state of
the computer market in the 1970s and 1980s that a major selling point
for Primos was its upward compatibility. A program written to run under
a certain release of Primos was guaranteed to run on all subsequent
releases and all subsequent processors (subject to sufficient resources
being available). Users now expect this as a matter of course, but it
was not always taken for granted. Primos excelled in certain areas but
was curiously lacking in others. For example, I don't think I've ever
seen another software product whose revision number got as far as 24 but
which still occasionally required you to type numbers in octal. On the
other hand, its networking (X.25 and Ring) in 1977 were very advanced,
but they seemed reluctant to advertise this point. Primos evolved from
the very first Prime operating system, known as DOS. A Prime founder
comments: "The first version of DOS was written by one of the seven
founders of Prime, Bill Poduska, over a memorial day weekend in 1968: it
took a month or so to debug because I had to keep rewinding the paper
tape Fortran compiler by hand (also rearranging base sector relocation
areas by hand)) at the NASA Electronic Research Center in Cambridge,
Mass (now the DOT Transportation Systems Center). Bill wrote it because
he realized that we would never be able to develop a time sharing system
(our objective) if we had to keep rewinding paper tape. Jan Carlson and
I did much subsequent development of DOS. The Fortran compiler
originated at CCC (Computer Controls Corporation, bought by Honeywell)
then CCD, but was extensively improved by a contractor to us (who wrote
the original for CCC) whose name escapes me. Much other CCC software was
adopted, adapted as well, but no CCD operating system software. They
didn't have any. "The machine we were using was a DDP-516 with
additional paging hardware also designed by JWP. This hardware was used
by the time-shared version of the original DOS, called TSDOS, which
simply (more or less) replaced all of DOS's internal data structures by
4 element arrays, allowing 4 simultaneous users. TSDOS was first used
internally at Prime to relieve extreme pressure on machine availability
in the software development group. Bernie Stumpf did most of the early
adaptation. "By the time Prime started up (1972) all this software and
later replacements for things like the debugger (original by Jim
Hamilton, written during a summer internship) were government property
and in the public domain. Prime adapted them beginning the summer of 72
when I started working there part-time (as a grad student) along with
Joe Brownstein as Prime's first two programmers. Joe adapted the
real-time operating system (OLERT or Samtran, maybe? I don't know where
it came from). As far as I know, both operating systems were available
to customers with the first machines shipped. Prime had incorporated
paging hardware into the Prime 300 as a superior memory mapping scheme
without specific plans to make a time-sharing system product. The
founders were originally pursuing the low-end market(PDP-8, -11 and DG
Nova). (Whereas CCC once outsold DEC before Honeywell ran it into the
ground.) "The only people I believed were using RTOS in the UK were
Monotype in Redhill in about 1978. I worked on Primes from Rev 11 (the
second with VM as far as I recall) from 1976 onwards using the first
P400 sold in the UK and our documentation included RTOS. I don't think
there was much development post 1980. It looked a lot like Honeywell
OLERT/4, and as far as I could tell, was runtime compatible. (We had a
Honeywell in the Chem Eng department at Imperial, and the opcodes were
identical to the P200). "Around Rev. 6, PRIMOS 2 was called DOS. PRIMOS
2 ran on the Prime 200, a non-virtual machine. PRIMOS 3 was called DOSVM
and ran on the Prime 300, the first virtual-memory minicomputer. DOS
also ran on the 300, and was used to boot DOSVM. The 300 ran S-mode and
R-mode instructions (16S, 32S, 32R, 64R), along with a few extras to
deal with the virtual memory. The virtual memory was a different,
simpler scheme than that used in later systems. I recall that addresses
were 16 bits, with 64K of addressability, but the VM allowed multiple
64K address spaces. "When the Prime 400 came out, the name PRIMOS
appeared, and the OS that ran on the Prime 400 got the name PRIMOS 4.
The 400 had the V-mode instruction set, along with the S-mode and R-mode
instructions. It had the segmented virtual memory architecture with
protection rings of the 50-Series. The 500 followed, and I-mode was
added, but not really used by anything. PRIMOS 5 ran on the 500, but it
was basically the same thing as PRIMOS 4, and when the 300 was dropped
from the product line, the names PRIMOS 2 (or PRIMOS II) and PRIMOS (for
the VM OS) were adopted." Primos 2 actually lived on until about the Rev
19.4 time frame to serve as a bootstrap loader for Primos itself. It was
obsoleted by the completely new boot in Rev 20.0, although portions
remained in the utilities COPY_DISK, PHYSAV, etc. Primos was initially
written in Fortran-IV (FTN) and PMA (assembler). At Rev.16 a new
language called PL/P (a subset of PL/1) started to be used. Around the
Rev.18/19 timeframe, a similar language, SPL was also introduced.
Although most of the kernel was FTN, PMA and PL/P, much of the external
utilities (like NETLINK) were written in SPL. Around 1987 the official
language within Prime Engineering became Modula-2. Modula-2 ceased to be
the "official" systems programming language after the second or third
RIF (Reduction in Force = Redundancy) inside of Prime Engineering, as
the compiler was never as good as SPL, even with some of its extensions
(like INLINE procedures!) that SPL never had. Some SPL began to enter
the Primos code around Rev.21 or Rev.22. In fact, I think it was
mandated at Rev.22. This required a more careful coding style, since SPL
(usually written that way, not SP/L) had some different defaults from
PLP. In particular, it defaulted fixed bin to fixed bin(31), not fixed
bin(15). This was good for hours of fun debugging OS errors. Modula-2
was not widely used in the Primos kernel, since the compiler writers who
worked on it were reassigned around mid-1988. Various tools to replace
the nice features of Modula-2 (such as strong type checking on procedure
calls) were promised for SPL but never delivered (big surprise there).
Modula-2 was used for the Machine-Dependent-Synchronization and
Machine-Independent- Synchronization components of the kernel and
actually worked out pretty well (I did some of that, and the type
checking detected some problems that would have been a bitch to find at
runtime). Until revision 19.0, released in 1982, the only security
available was in the form of passworded directories. Each directory had
an owner and non-owner password. The owner defaulted to XXXXXX, the
non-owner defaulted to blanks. Login User IDs were the same as top-level
directory names; as long as you got a correct top-level directory name
and owner password, you were in. Every Prime had directories called FAM,
DOS and SYSTEM. Small wonder that "The Cracker", Bill Landreth,
following his arrest by the FBI, stated that Primes were the easiest
machines to break into. At revision 19.0 Prime introduced a _superb_
security system based on access control lists (ACLs) and broke the
connection between login ID and directory names. Security at Rev.19 was
passive; in other words, it was there by default, you had to actually
disable it, rather than the previous situation where you had to enable
it. Prime ACLs were extremely powerful and easy to use; I doubt there's
ever been a better system invented. (Except on Multics, perhaps?) Primos
had lots of other excellent features, including long file names and
hierarchical directory structures. It had a very good command language,
CPL, which although not as powerful as Unix shell scripts (because
Primos lacked I/O redirection), was certainly easier to use. Like any
interpreted language, CPL was somewhat slow in execution, but that
didn't stop companies which didn't have full-time programmers writing
massive systems in it. From about Rev.17, Primos had command
abbreviations. These allowed users to define their own abbreviations for
common commands. Mind you, the confusion this could cause was startling!
An advantage over csh aliases was that you could have abbrevs expand in
the command-only, argument-only or both fields. You could also reorder
the arguments. At this point or slightly earlier Brad Hampson wrote the
condition mechanism. It was modelled on the condition mechanism from
Multics. Hence the joke in the (internal) X.QUIP (Primos version of
"fortune") database:- Error: Condition "BRAD_HAMPSO$" raised at
6002(0)/0. It was possible to intercept the standard command processor
(std$cp) and write your own. Prime did this itself with the
"Edit_Cmd_Line" (ECL) program. This allowed you to call down previous
commands for editing (like DOSKEY on PCs). Try typing STAT HDWR This is
one of the undocumented Primos commands. (Wonder why?) Another is:
ORIGIN -SET which changes your origin to be the current directory. Prime
knew that it is psychologically helpful for new users if you allow them
to customise their environment in some way. The RDY command allowed
users to change the standard, boring, "OK," prompt to "He's Dead, Jim
!", and the "ER!" prompt (displayed when a positive status code was
returned by a program) to "^G^G You've goofed, Bozo!". I evolved a
theory known as the "Five-Stage Evolution of the Prime User". Stage 1 -
Modifying the prompts as above, and using the ABBREV facility to change
the names of all the Primos commands Stage 2 - Writing your own
elaborate mailing/message system using SMSG$ (as the MESSAGE command was
invariably withdrawn by the SA) Stage 3 - Putting the prompts and
commands back to normal, deleting the SMSG$ MESSAGE program and writing
a better one using the undocumented CPS$xxx gates and a user-written
command processor to share with friends. Stage 4 - Discovery of the
undocumented R$CALL interface, writing programs using it which execute
calls like LDISK$, CPUID$ and GMETR$ to find out just _what_ was going
on at remote sites! Stage 5 - Modifying the kernel, libraries and
modifying Primos on the fly via the VCP (aka, the Bernie Stumpf method).
R$CALL was one of the best ways to crash PRIMOS as it happened,
especially when one started using the IPC$ remote set! You could cause
slaves to not want to logout after they had finished (you couldn't kill
them at the console either), so not only did the remote host get
cluttered, the local one would too, and this had a knock-on effect that
the local one would jam slaves too. Eventually, after users had used
MESS -ON enough the system ground to a halt. Oh yes, I think R$CALL was
undocumented for a reason ... :-) It sure should have been. It was a
really terrible interface, because instead of passing the arguments for
the remote functions as vectors, it passed them individually. This
required R$CALL to take something like 50 arguments, which makes for a
painfully large stack frame. Devices Primos did not handle devices in
the same way as most other OS's. Devices are usually treated exactly the
same way as files. Under Primos, however, although you could assign,
say, the magtape unit MT0, your program could not open a file "MT0:" and
write to the tape through it. Instead it had to call the routine T$MT().
Serial I/O was done via T$AMLC() (although you had to assign the line
with ASSIGN AMLC xx - even when the ICS replaced the AMLC). The plotter
was written to via T$GPPI(). At Rev.21, the requirement to obtain C2
security classification meant that the previous "free for all" whereby
anyone could assign any device had to stop. This was done using a clever
hack called "Device ACLs". A directory called DEVICES* contained fifty
or so empty subdirectories, the name of each corresponding to a device
name (MT0 etc.). When a user attempted to assign a device Primos just
checked that they had access to the corresponding device directory -
people could therefore be easily locked out with ACLs. There was a
device called PBHIST for performance monitoring. It would monitor the
location of the current program counter and allow the construction of a
histogram for performance analysis (to find out where the system was
spending its time). Class Wars A curious anomaly in Primos which remains
to this day concerns the way in which user privileges are doled out.
Initially the only privileged user was the system console (user 1). This
was a permanently logged in (as SYSTEM) terminal from which actions like
adding disks and shutting down the system could be performed. (In
Rev20.2 there was an undocumented CONFIG directive, PRMENG 140000, which
gave the system administrator the right to add and shutdown disks.)
Interestingly, User 1 had other responsibilities. A routine called
MINABT (I believe) interrupted once per minute and caused the console to
do various tasks including flushing disk buffers, and logging out users
who had exceeded their maximum inactivity time. The former task was
moved into BUFFER_SERVER at Rev.22. Before the LOGIN_SERVER (at 20.2),
user 1 was also responsible for wiring down the stacks of logged-out
processes when someone typed a character at their terminal (say, for
logging in, or using one of the other logged-out commands). Boy, was
that ever a kludge. When Primes moved out of air-conditioned rooms and
into offices in 1982 with the advent of the 2250 ("Rabbit"), a keyswitch
was hastily added to disable user 1. At Rev.19 the ACL system introduced
the concept of a "System Administrator". This user, which did not have
to be SYSTEM, had access to the SAD (System Administration Directory)
where all the user IDs, project IDs and passwords were stored (in the
file SAD>UVF, if you must know, and yes, there are loads of decrypters
around. I have run one purely in the interests of research and I found
the stupidity of users' choice of passwords to be truly mind-blowing!
This would make an excellent topic for a thesis) At Rev.21 a product
called DSM (Distributed System Management) was released. This added lots
of commands which reported the status of the various Primes in a network
(list users, list files open by a process, list serial buffer settings,
etc., etc.). These facilities could be restricted to users and groups of
users using the unbelievably complicated CONFIG_DSM command. So DSM
added another category of "privilege". In summary: * To use EDIT_PROFILE
and add new users you had to be the system administrator. (To be
strictly accurate, whereas the SysAdmin would have ALL rights on SAD,
_anyone_ who had ALL rights there was treated as SysAdmin by
EDIT_PROFILE . Sounds a security problem, but if someone had all rights
they could screw things up without EDIT_PROFILE anyway.) * To find out
who was logged on the machine next door you had to be authorised to do
so by DSM. * If you wanted to log out a user with a different user ID or
stop and restart a print spooler, you had to walk over to the system
console to do it. [Or you modifed Primos so that SysAdmin was privileged
too and then wrote a little program to call LOGO$$ with the relevant
keys.... I never could understand why Prime held on to the belief that
systems were looked after by Operators who sat at the console, rather
than by administrators who could be anywhere (including at home...).] *
There was no way to let a user run a program which enabled them to
access anything they could not access as a normal user. See "How do I
emulate Unix Set-Uid?" Primos never did gain a single method of granting
user privileges. DSM did bring in a facility called RESUS (REmote System
USer) [originally called DSMRESUS] which allowed any terminal to become
the system console, provided the user was authorised to do this by the
DSM configuration. While this was in progress the real system console
was disabled and all console messages (users logging in, etc., were
redirected to the RESUS user) There was a tool developed within Prime
Engineering that allowed various configured users to submit a command to
be executed on the system console from their user terminal. It had a
configurable administrator who could control who could use this tool. Of
course if the system console was doing something else besides sitting
idle at a command level prompt when the request was issued, it had a few
problems (like getting locked up). But this tool did precede RESUS, and
had the benefit of not requiring that RESUS be enabled on the console in
order to work. This editor also wrote such a program, which employed
both the technique of replacing the standard command processor (like ECL
and its predecessor, BOOTLEG) and the previously mentioned CPS$
(Cross-Process Signalling) gates. At one of the very last releases of
Primos, the spooler was modified (I believe) to allow nominated users to
stop and start spooler phantoms without being at the console. Primos
Modifications Prime were an extraordinarily helpful company. At least
until the late 1980s they were extremely free with their source code. A
former Prime employee comments, "I think the reason the code was widely
distributed was more historical accident. All of the source code for
GE600/Honeywell6000/Level 66 was widely distributed (and often heavily
modifed) I suggest you take a good look at where most of the Prime
people (and a lot of the customers ) came from and the origins of this
policy become pretty obvious. Also remember that the big sales pitch in
the early days was to 'intelligent end users'. I never saw an O/S I
didn't want to make changes to. It was a major selling point in late
1970's and early 1980's before the days of CAD/CAM and Information."
Another individual comments, "I worked in Prime R&D for 13 years and the
impression I had was that Prime released source code because it seemed
like a good idea at the time. Why *not* allow customers the option to
customize Primos? Many customers had unique needs and universities could
use Primos in their curricula. "Yes, it's true that Primos was developed
partly from code written for US government contracts, so perhaps there
was some requirement to make the code available in some cases. I don't
remember hearing that as a reason to release source code to everyone and
at no charge. "Later, Prime decided to charge for source code and seemed
to discourage customers from having it. I think by then, there was far
too much hacking going on making diagnosis of bugs in Primos more and
more difficult. ('Oh, that little change I made? No, that couldn't be
causing my crash!')" You could even go on a course to learn how to
modify the OS (at your own risk, of course!) I myself was the proud
author of a modification which detected when a remote user connected to
your site and displayed their PSS (X.25) address on the console. A
somewhat unfortunate side-effect of this mod was that the machine would
halt immediately prior to displaying the X.25 address. On a more
positive note, I did manage to modify the MINABT routine mentioned above
which prevented my terminal being logged out while ensuring a 10-minute
inactivity time for everyone else. I also wrote a gate which returned a
list of the files any user had open (useful for identifying what
phantoms were doing) (this was in the days before the DS$ gates) After
my experience with the X.25 bug I decided to leave the Ring-0 hacking to
the experts. In the UK these included Phil Crane and John Kavanagh (both
Thames Poly alumni like myself) and the incomparable David Brown.
Although I was not fortunate enough to meet him personally I heard many
stories of his legendary knowledge of Primos internals gained during his
time as (probably) the longest serving Prime UK staff member. When new
versions of Primos arrived in the UK, DJB and PJC would get to work on
fixing various problems; the modifications they made were the reason why
UK versions of Primos always ended in a letter (19.2.7m, etc.) The
letter indicated the UK revision level. What happened to Primos? In 1985
when Bill Gates bet the future of Microsoft on Windows 1.0, Primos had
just had more comprehensive networking added [at 19.3]. Configuration of
serial (AMLC, ICS) lines and buffers using decimal instead of octal, and
without requiring a reboot was still four years away [Rev 22]. (In case
this sounds too pro-MS, I'd like to point out in the interests of
balance that it was 1992 before Gates released a version of Windows -
3.1 - which actually validated parameters passed to Kernel routines. And
even now you can't logout an infinitely looping task) The rest is, as
they say, history. :-) Now, a company called Peritus Software Services,
Inc., staffed by many former Prime personnel and located in Billerica,
Mass., with Primos support in Westborough, Mass. (near Prime's old R&D
and manufacturing facilities in Framingham) currently fixes SPARS
(System Problem Action Requests) on behalf of CV. The latest release of
Primos (as at September 1995) is 24.0. The last version of Rev.23 was
23.4. The last version of Rev.22 was 22.1.5. (Rev.22 has not been
supported since Rev.24 was released) Peritus has a WWW page; point your
web browser at

        Q) 2.2 What were the features of the various Primos releases?

REV 24 At the time of writing - March 19, 1997 - this editor has been
informed that an ISV in the US who recently ordered "The Latest Release"
of Primos received Rev 24.0.0.R51. The corresponding UPINFO file
indicates that 24.0.0.R51 was released on March 18, 1996. So it looks
like there haven't been any Primos enhancements/bug fixes for a year
now. 24.0.0.R51 [March 18, 1996] - Enhancement to the RDY command to
give the ability to make the command processor display the commands
generated when wildcarding, treewalking or iterating. 24.0 [February 18,
1994] - Store unix compatible passwords in CONFIG_USERS to aid migration
:-( - Much better CPL (4-6 times faster, more memory available) - CMPF
enhancements - Multiple sort options in LD - Enhanced Spooler REV 23
23.4 [March 26, 1993] - Support 512MB Memory on 5310, 5320, 5330 and
5340 - FIX_DISK without shutting down partition - New MATCH utility
(like grep) - More options to CONFIG_USERS - Ability to customise 'User
ID?' prompts - Spooler enhancements - Supports 1GB & 2GB SCSI drives -
DRB enhancements 23.0 - Registered EPFs. In a nutshell, they're
executable images that are loaded into memory at coldstart time. Mammoth
applications whose startup times are measured in milleniums (compilers)
realize the appearance of better performance. - EDIT_PROFILE enhancement
including new password encryption - new CONFIG_USERS utility -
NAME_SERVICE functionality for a common file system - Enhanced
Locate/Flush for better file system integrity - Large memory support to
improve coldstart time - Tunable scheduler - New default timeslices
based on CPU class - USAGE enhanced to monitor scheduler - Enhanced
MAGSAV/MAGRST known as DRB - Death of BRMS. Can no longer write tapes at
this release. - DSM enhancements, including user-written unsolicited
messages - Customisable SPOOL -LIST - New online HELP facility - Release
for T3.0 Translator family. REV 22 22.1.4 - First release for C++ 22.1 -
Release for T2.0 Translator family. - COBOL85 IPR (Independent Product
Release) - Robust Partitions (not requiring FIX_DISK after crash) -
Increased number of NLBUFs and Virtual Circuits - Introduction of
enhanced MagSav/MagRst (DRB) - Users productivity greatly enhanced by
new inter-user messaging utility, TALK. :-) 22.0 - The ability to
dispense with AMLBUF directives for setting serial line buffer sizes.
This can now be done using the LAB and CAB commands. - Many new Primos
gates documented including ISC$ (inter server communications) and
synchronisers - TCP/IP connectivity (which was really unstable until
22.1.4 and only moderately unstable thereafter) REV 21 21.0 [June 1988]
- Release of Distributed Systems Management (DSM) which allowed several
Primes around a network to be administered centrally. Famous for logging
in a half dozen phantoms and taking a couple of minutes to list the
users on the machine in the next room ! - Primos passed C2 security
classification from the US Department of Defense (DoD) [21.0.1DODC2A] -
Disk Mirroring - EDIT_CMD_LINE to save users retyping commands - Device
ACLs - Release of T1.0 Translator family. REV 20 20.2 [Late 1987] -
Shows user line in octal AND decimal when doing STATUS USERS. -
Seriously I believe that although this rev. didn't add much user-visible
functionality, internally all the DSM gates (DS$xxx) made their first
appearance to the delight of hackers everywhere. 20.0 [Early 1987] - New
disk format. Hashed directories to speed access. - New more flexible
BOOT facilities. - One of the most buggy releases of Primos ever :-) REV
19 19.4 [Mid 1986] - EPFs and BIND released at last. They'd been around
since 18.3 19.3 [1985] - Replacement of NETCFG with new, more
complicated CONFIG_NET to support significant enhancements to PrimeNet.
- Introduction of ill-starred Backup/Recovery Management Service (BRMS).
19.2 - The first release I ever used. Must be famous for more than
this... 19.1 - ? 19.0 [1982] - Introduction of Access Control Lists
(ACLs). In one hit, Primos went from being the least secure system in
the world (apart from DOS) to the most secure. Primos ACLs easier to use
than VMS ACLs (which appeared later, in VMS V4) - EDIT_PROFILE and user
profiles containing project and group names. Finally introduced a
Prime-supplied login program. - FIX_DISK (replaced FIXRAT) - New command
line processor incorporating wildcards, treewalking, iteration, and file
name generation. - Disk quotas - COPY, LD, DELETE, PROTECT, RWLOCK
replaced FUTIL, etc. - New disk format with improved badspot handling
(required to use quota and ACLs on directories). REV 1-18 : ANCIENT
HISTORY ! 18.3 - Pre-release of EPFs Beginning of standardized compilers
with a common back end. Maybe the CBL compiler appeared here. Also a
better CPL than was released at 18.2 18.2 - Early CPL - Somewhere in
here the SAD arrived 18.0 - First release of SPL and PASCAL 17.0 -
Condition mechanism (On-Units). - First release of PL1G and F77 16.0 -
PL/P started to be used 15.0 - Last release supporting Primos III 13.0 -
So bad it didn't survive its initial release 11.0 - First release with V
mode support in it. - Included SEG for the first time as a temporary
link/loader. A new linker was intended to replace it in the following
Rev. This program, BIND, finally turned up in 19.4
          Q) 2.3 Why the strange PDEV numbers, such as 460, 21460, and

Because you can't fit
into six bytes.

          Q) 2.4 What was the first revision of Primos which passed C2?

The revision level of Primos that passed C2 was 21.0.1DODC2A dated June
24, 1988

          Q) 2.5 Why is CMDNC0 called that?

Most people think it's "Command Non-Chargeable Logical Device 0".
However I have other information from an extremely reliable source
(i.e., one the first Prime systems programmers). Apparently in the early
days they had different versions of the same command which suited
different modes the processor was running in. Therefore they had
multiple command directories each containing the same commands targeted
at different CPU modes, with the directory name reflecting the mode of
the programs within. CMDNC0 was one of these directories, and the name
just "stuck".

          Q) 2.6 How do I emulate Unix "set-uid"?

In other words: How do I write a program which can update a database but
not allow the user to play with the database outside my program? You
have hit on a problem which has confronted Primos developers since time
immemorial. The root of the problem is that there is _no_ way to mark an
executable image (EPF) "privileged" so that when the program is running,
a directory or file can be accessed which is normally "ACLed out" to the
user when he/she is sitting at the command prompt. For example: if you
have a directory containing mail, for user A to run a program which
appends to user B's mail file, user A must be able to do the same at the
command line. There are two ways round this. One is to use password
directories with the password embedded in the program. You have to be
careful to encrypt the password and it's always vulnerable to discovery.
The second way is to use a server. In our example, you fire up a server
called "MAIL_SERVER" and set the ACL on "MAILDIR" to MAIL_SERVER:ALL
$REST:NONE. Your mail program then writes mail indirectly by invoking
the MAIL_SERVER. In the old days people talked to servers using the
PRIMENET X$xxxx gates in VNETLB. Later came the ISC$ routines. However
this method is still vulnerable to some clever person finding out how to
invoke the server and sending it unauthorised messages, although this is
far less likely than a password being discovered. To start a process
under a specified user ID (instead of an ID inherited from the spawner
like with PHNTM$) you need to use the SPAWN$() gate. As far as I know
this gate remains undocumented to this day. If you look at the source to
SPAWN$(), you'll see how PHNTM$() et al are merely entrypoints within it.

        Q) 2.7 What is/happened to Primix?

Primix is an application program which ran under Primos releases 19.4
and above. It gives the user a "Unix-like" front-end to Primos. Its main
problem was that one user under Primix placed the same load on the
system as twenty normal users. The other problem was that the program
itself was completely pointless. Why emulate a front-end widely regarded
as the most unfriendly ever devised? If you wanted to run Unix apps,
just buy a Unix workstation. However Prime were desperately trying to
hang on to their (proprietary) market share, and wanted to give people a
way to run their Unix apps on a Prime platform. What they didn't
realise, or ignored, was that people weren't moving to workstations
because they liked Unix or Unix apps, but because the proprietary
manufacturers - Prime, DEC, Bull, Sperry, DG, Honeywell, NCR, etc., were
skinning them alive financially. The real problem with Primix was that
it almost never had adequate staffing. The original product (1.0) was a
triple threat: it was slow, buggy, and lacking in features. Schedule
pressure caused it to go out way before it was ready, and it was
woefully understaffed. At 2.0, the bugs were much reduced and many
features were added. The 2.0 version was a good deal faster (I did some
of the Primos modifications for this, particularly on the fork$ path).
Primos also had "owner" access added to the ACLs, so that Unix "owner"
rights could be implemented properly, and some other features were
added. There were about six people doing Primix full-time as of 3.0,
with a few others (like me) doing stuff on the side. However, at this
point, Prime management decided to cut the project way back. (This was
typical of Prime -- if a project showed a good chance of success, it had
to be shot immediately. Modula-2 is another example that comes to mind.)
Thus, it never really had a chance to succeed. Some problems, like
byte-oriented file access, were never addressed, though there was no
reason that Primos couldn't have been modified fairly easily to do this.
The requirement for emulation guaranteed that Primix would be slower
than Unix (and 50 Series machines were never very good C engines anyway
[NULL != 0]). However, Primix did very well on system call tests, even
with emulation, due to Primos's wonderfully fast system call mechanisms
(gates are wonderful).

        Q) 2.8 What do the files in the DIRECV directory do?

They are to do with "Static Mode Shared Libraries" R3POFH has been
around since at least rev 15. It is the Ring 3 Pointer Fault Handler. It
is designed to be called for static mode shared libraries to snap
dynamic links at runtime. HASHER.FTN is the FORTRAN program which reads
a list of shared library entrypoints as input, and produces a hash table
for R3POFH to search (HTAB.INS.PMA) of the entrypoints. (Most of the
stuff in DIRECV is related to static mode shared libraries.) The program
MAIN.PMA is used to "install" shared libraries into the static mode
library table in PRIMOS. The R3POFH entry is put into a table
corresponding to the shared library "number" used at install time
(either pre-allocated for most Prime supported shared libraries, or the
first unused entry used for user libraries).

        Q) 2.9 What's a V-Mode .SAVE file?

Before BIND came along most runfiles had to be large unwieldy segment
directories if you wanted to use V-Mode. If you could cope with R-mode
you could use the archaic loader program LOAD to generate a .SAVE file.
However most useful system subroutines were not accessible from R-mode.
The way round this was to create a V-mode .SAVE file with the following
script: SEG -LOAD SP MI /* Allow PROC & DATA in the same segment co abs
4000 /* Throw all COMMON into same poor segment 4000 S/LO MYPROG 0 4000
4000 /* Use next available location for PROC & DATA D/LI /* Ditto for
libs SA /* Not needed since REturn does a SAve RE SH myprog. /* FileID
used to generate myprog.4000 delete /* Delete temp file Q copy
myprog.4000 -dl

        Q) 2.10 What is a terminfo/termcap entry for a Prime PT200/PT250

# # P: PRIME # pst100|pst-100|pt200|pt-200|pt250|pt-250|Prime PT 200,

        Q) 2.11 What CAD packages ran on Prime?

The Prime 300, 400 and early 50 Series machines provided an excellent
development platform for Fortran IV applications requiring high
performance floating point arithmetic. Hence, Prime systems were chosen
by many CAD/CAM software companies (especially in the United Kingdom).
These included CAD Centre, Compeda, Cambridge Interactive Systems (CIS),
GMW and many others. In the early 1980's Prime acquired exclusive
marketing rights to the Medusa product from CIS. However, this
arrangement was restricted to North America and, for several years Prime
was very frustrated that they could not sell Medusa in Europe etc. A
team was sent from Prime Park to the UK to buy CIS. Unfortunately, due
to a minor glitch in communications, the team returned as proud owners
of Compeda (another CAD software house which had been owned by the UK
Government). That gave Prime one or two extra products including the
Plant Design Management System (PDMS), Sammie (an interesting ergonomics
program but a commercial flop) and a few other lemons. Then
ComputerVision acquired CIS and Prime acquired ComputerVision. Then
Calma. Somewhere in the middle of all this, Prime acquired a PC CAD
company (competitor to AutoCAD). They also bought a version of the
source code to Medusa. However, they bought the wrong version (4.00
instead of 4.01, I think) and spent the next year or two fixing all the
bugs that CIS had already fixed in 4.01. Following the acquisition of
ComputerVision by Prime I recall the management roadshow which was
organised to inform all of the employees about the merger. When they
invited questions one manager stood up and said: "I have worked for CIS,
ComputerVision and Prime. I have a Pension Plan with each of them.
Please could you explain how my Pension rights will be consolidated."
This was followed by a very, very, very long silence.

        Q) 2.12 I heard that Primos had been ported to the ....., what

PRIMOS was never ported to anything. The major stumbling block was that
the Re-Targetable Code Generator project never produced code for other
than 50-series hardware. And who would want to port all that PL/I code
with Prime specific extensions? There is a LOT of 50-series specifics
built into PRIMOS. Especially at the Ring-0 level. There was a very
short lived project called the P-shell that was supposed to provide a
"PRIMOS-like" command line environment to the UNIX users, but that never
came close to being release-able. Correction: it appeared on the MXCL-5
Mini-Supercomputer. As I see it there are four options: * Port Primos
itself. However, as you'd expect from an OS, most of Primos internally
is concerned directly with 50-series hardware. * Port the libraries,
i.e., allow a Prime program to which you had the source to run by
writing a DOS version of the various system libraries. However this
would imply that the Prime compilers [with Prime extensions] were also
available on PC. * Write a "Prime Emulator" [they already exist for
PDP-8s and -11s] which will actually execute a .RUN file on a PC. Anyone
care to try this during their lunch breaks? :-) * Write a 4DOS-like
Primos shell for DOS (or even Windows) Come to think of it, a lot of
people write command line interfaces to Windows, why should the command
lines be DOS? Probably easiest to do a Prime Emulator, although the Byte
Sex is opposite and the Segmentation is different and the ring
validation stuff and the I/O will be an absolute pain. The unofficial
estimate was 100 person years at the time it was suggested to management
to do the first of the above. An earlier attempt at moving part of
Primos to a Motorola based system took about 10 person years.

        Q) 2.13 I've got a Rev X MAGSAV tape, can I read it with Rev Y?

The simple answer is: just try it! Primos was always having new file
attributes (date/time saved, date/time backed up, date/time modified,
etc.) added to it, and also different types of file (CAM, RBF, etc.)
This meant that the format of the information MAGSAV wrote to the tape
had to change. To help people, Prime added options like: -REV19, which
allowed Rev 20 MAGSAV to create a tape which Rev 19 MAGRST could read.
In keeping with the principle of upward compatibility, Rev 23 MAGRST
should be able to read tapes created with all previous versions of

        Q) 2.14 I've got a MAGSAV tape, but no Prime... help!

If you are a Unix or DEC MIPS user, you may like to know that VMark
software's Universe package has a MAGSAV tape reader program. See also
question 6.1

        Q) 2.15 Anyone know about the HERO monitoring package?

I was a Senior Systems Engineer in the Milwaukee, Wisconsin
branch(Chicago region). I had an opportunity to work with the HERO
monitoring utility(getting it usable for sale), although no customer
ever really implemented it in our area. Keep in mind these are
recollections from about six or seven years ago, but are accurate to the
best of my recollection. HERO was a combination hardware/software
package for automated alerting/management of system events that occurred
at the console(or I suppose a terminal if you were PEEKING on it). As I
recall, the hardware component of HERO was an ISA card to be installed
in a PC that basically consisted of some number(four???) of relay
outputs that you could attach to a buzzer, light, bell, etc. if a
particular system event occurred. The software component basically acted
as a screen capture/scripting tool that watched for certain character
strings to appear on the monitored port(usually the console port) and
either automatically performed a command/response or activated one of
the relay ports to signal the alarm(based on the users scripting rules).
I believe I was also able to get the utility to page me when a specific
event occurred, although I can't remember how I did it. I believe the
HERO utility was created by a Systems Engineer or Analyst somewhere out
west or in the midwest. Iowa or Washington come to my mind, although I
cannot really recollect.

        Q) 2.16 Problems stopping/restarting printers

I am having problem with stopping a print job and then starting it back
up on our Prime. The result of the existing setup causes the me to have
to bring the Prime to the CP1> prompt and reboot (talk about dreadful)
Anyway, this is how I am currently stopping and pausing a print job. Can
anyone tell me if I am doing this wrong. TIA... This only occurs while
the job is in the middle of printing. Stopping: SPOOL -CAN xxx Pausing:
PROP -SUS xxx PRIMOS: 21.2.0.R68 All of our printers are serial, and I
use ICS lines. It only hung the spooler, but I (not being the sys.
admin, but being the db admin) was only left instructions on how to
bring the entire system down and not how to bring one line down. BTW:
When I type "PROP PR0 -STOP" and it is hung, it tells me that a request
is currently outstand and continues to hang. If there is any easy way to
bring just that printer down, that would be a great start. I assume that
it would start with "lo -55" or something like that. Answer: If your
system allows it, I.E, you are a SPOOL_ADMINISTRATOR$ group member, you
can use the "-NOW" option with PROP to force the printer to stop. PROP
xxx -STOP -NOW This usually works for me whenever I have a hung printer
on an Async (ICS) line. We use several remote printers over dedicated
terminal servers and they hang somewhat frequently. Using the -NOW
option to stop the printer, I am able to control individual prop
environments rather than having to stop all the printers and doing a
PROP -COLDSTART to clear everything. In my case, since it's usually the
Xoff/Xon control that is hung, I have to wait several minutes before the
printer's despooler logs off. (Mostly due to the 2 minute grace period
Primos gives hung processes before finally cleaning up after them) There
are several situations you can check to avoid having to do a complete
system shutdown when trying to reset printers.. The first is using the
-NOW option as stated above. Monitor the environments with PROP -STATUS,
and when you see that the one you are trying to stop is no longer
listed, it is safe to force-logout the phantom process associated with
that spool environment. If you find that a spool environment is listed
in PROP -STATUS, but there is no associated phantom process, you need to
stop ALL of the printers, and when everything is logged off, use the
PROP -COLDSTART command to reset the information. Then you can restart
all of the printers and they should work okay. If the phantom is still
running, but the printer isn't listed in the -STATUS display, then
force-logout the phantom, and when it is finally removed, you should be
able to restart the printer. The -COLDSTART option should NEVER be used
until all of the offending phantoms have been logged off. The -COLDSTART
option simply resets the environment information that Primos keeps in
the SPOOL segment in memory. It does not control any of the phantom
processes. In fact, using the -COLDSTART on a "live" environment will
cause the system to lose track of the phantom altogether, which means
you have to force-logout the process before anything can be done to the
other environments. The short of it is... There should be no need to
shut down the system to fix the printers. Primos should automatically
reset any ICS lines once the phantom assigning it has logged out. (At
least this holds true at Rev22.1.x..) :)

        Q) 2.17 Prime ASCII <--> Unix ASCII conversion problems

Our Prime 9955 running Primos ver 22.1.2v is no longer being maintained,
and is dying. I need to transfer some large directories with many
subdirectories and many files in each to another computer. The tape
drive is no longer working. ftp won't go recursively through
subdirectories, and a tar program on the prime makes tar files that I
can't read on the other computers (various Unix machines). I've tried
masking the high bit (since the Prime sets that bit in each ascii
character), and then I can read the files inside the tar file using vi,
but haven't been able to untar it either with or without the high bit. I
also tried ftping the tar file both as binary and as ascii (hoping the
latter would translate everything). There's a gzip, but it won't do
directories? I've spent a day doing a depth first traversal of the
directory structure, creating corresponding subdirectories on the unix
machine and ftping, but have hardly made a dent in the large number of
files. This problem must have come up somewhere else, and I'd be
grateful for advice, since all my course materials are on the Prime, and
the disks are dying! Thanks. Answer: Is it safe to assume that you mean
that you CAN unTar the file, but cannot interpret the information inside
it? (Reference to high bit masking) What you want/need is a program that
Prime included in their NFS_ installation called PTOU (Prime-to-Unix),
which will convert the individual files from Hi-bit to normal-bit ascii.
The following bourne script is used by us to convert entire directories
from Primos-ASCII to Unix-ASCII once they are transferred using Tar
files. --- #!/bin/sh # Script to treewalk a branch and convert all files
from Prime to Unix ascii. # Written by Joy deVries and Todd Siskin, NY
District, USGS. # for name in $\{1\}* ; do if [ -f $name ] ; then case
$name in *.run) echo "Skipping Pr1me EPF file: $name" rm $name ;; *.bin)
echo "Skipping object file: $name" rm $name ;; *.seg) echo "Skipping
segment directory: $name" rm $name ;; *) echo "Converting file: $name"
ptou $name > $name.ok rm $name mv $name.ok $name ;; esac fi if [ -d
$name ] ; then echo "Entering directory: $name" cd $name
/public/bin/ cd .. echo "Returning to: `pwd`" fi done

        Q) 2.18 R-mode, S-mode, etc: What were they?

Briefly Deep in the heart of the last Prime processors were Honeywell
5xx and 7xx instruction sets, aka R-mode and S-mode. R-mode and S-mode
were Relative and Sectored addressing-mode 16-bit instructions sets with
a single register for doing arithmetic. V-mode was a 32-bit
virtual-address instruction set with base registers, but still only a
single arithmetic register. The base registers enabled access to
segments of 128K bytes. I-mode was a 32-bit virtual-address extension
set with 8 general registers. The addressing unit for R-, S-, V-, and
I-modes was 16 bit half words. IX-mode was I-mode extended for C-style
byte addressing. There was an aborted X-mode effort that would have
featured a large number of large segments X : IX as 386 : 286. In More
Detail The original Prime computers were compatible with Honeywell (now
Groupe Bull) Series 16 minicomputers. These machines had 2 addressing
modes that allowed 16k word and 32k word addressing. The second mode was
known at Honeywell as extended addressing. A memory reference
instruction could directly address a location in the current 512 word
sector or in the 1st 512 word sector (the Sector 0). The assembler,
FORTRAN Compiler, and linker made this limitation transparent to the
programmer by translating an out of sector reference to an indirect
reference through a link inserted in the base sector. The only problems
came when you ran out of sector 0 space. The difference between normal
and extended addressing was the format of memory locations used as
indirect links. In normal mode the link could specify both indexing and
further indirection. The added address space in extended mode took away
the second level of indexing. When Prime started, these addressing modes
were named 16S (16K word space, Sectored addressing) and 32S (32K word
space, Sectored addressing). Prime also implemented two additional modes
that were the primary ones used on the Prime 100/200/300 machines. These
replaced current sector addressing with relative to instruction
addressing. This tended to require many fewer sector zero links, and the
# of sector zero links required would not change greatly with small code
changes. In addition, the largest negative displacement were used as an
escape to allow multiword instructions which could directly address the
complete address space. The two relative modes were 32R (32K address
space, relative addressing) and 64R (64K address space, Relative
addressing). The 64R mode gave up multilevel indirect addressing, and
32S and 32R modes gave up multiple indexing (though it was probably
never very useful, after all, how many times do you want to continue to
index a reference by the SAME index value while indirecting as well
...). The Prime 400/500 introduced the V and I modes. V mode was a
direct extension to 64R. It made the segmented address space available
to applications. Programs written in S and R modes could only access the
current segment when run on these CPUs. V mode had the segmentation base
registers, a high level procedure call, ring protection, and provisions
for bit specific memory addressing, but it was still basically a single
accumulator architecture. In V mode, the old sector zero format was
translated as LB references for negative offsets and SB for positive
offsets. This was why the LB was generally set to point ahead of a
procedure's linkage area. The I mode replaced the single accumulator
architecture with a general purpose register set. The procedure call
mechanism allowed changing between V and I modes so that caller and
callee did not have to know or plan for each others modes. IX mode
actually addressed a much broader issue. A new product was under way
called X-Mode (which would have supported C very well). IX mode was an
attempt to gain some of its functionality at a lower cost. IX mode was
designed to support the C language better and also to improve FORTRAN 77
runtime performance. The F77 compiler had extensive support for
recognizing loops which accessed arrays and would use IX mode rather
than reloading the XB register whenever a different common block was
accessed. IX mode was an extension of I mode that allowed the general
registers to be used as base registers. The only format allowed was
base+index (i.e. R0%+nnn). R0 could be used as a base register (it
cannot be used as an index register in I or IX mode.) IX mode is not
present on all machines, it was invented while the 9950 was being
developed. Earlier machines (e.g. 750, 550-II) do not have it. The main
point of the I-mode eXtensions was the General Register Relative
addressing. The ablility for the compilers to use a General Register
(GR) as a Base Register (BR). Useful since one loadable scratch base
register was shown to be woefully inefficient. Much time was spent
reloading it (often just swapping between the same two or three values).
A study was done and it was discovered that 2 (and 3) base registers was
a much better number to have. But since the XB addressing was so much a
part of the instruction set (and had to remain for legacy code and to
support the V mode architecture), the GRR extensions were born. Now any
of the 7 general registers (R0 is not really a general register, it
can't be indexed) can be used as a base register when necessary. F77 was
the primary benificiary of this addressing mode, and the C I-mode
compiler also made heavy use of it as well. You could still force the
F77 to generate "old" 32I mode code by using -32I, and the new support
was controlled via -32IX. Cross segment addressing on Primes, was to be
polite, crude. You actually had to calculate a 12 bit segment address,
and a 16 bit offset, and needed to indirect through memory to reference
a segment not pointed to by one of the base registers. The process of
calculating this was messy, and then you had to store in memory so you
could indirect through it. IX made made it possible to do this
indirection via one of the general purpose registers, saving both the
store and the load operation. The promised performance improvement from
IX mode however never materialized for most users. If you did not have
segment spanning arrays, IX mode offered no improvement at all over I
mode. At least in theory I mode should have been faster than V-mode, it
rarely made much difference however. IX mode also added instructions for
the C language. (Some of them had other uses as well) LIP - Load
indirect pointer (used instead of EAR addr,*) AIP - Add indirect pointer
LCC - Load C character SCC - Store C character TCNP - Test C null
pointer ACP - Add C pointer The C pointer instructions used bit 4 of the
register to select the even or the odd byte. There were plans for even
more support for the C language in the form of additional instructions
for microcoded implementations of strcpy() and other library functions.
There was also a "flat" mode that allowed data items to cross segment
boundaries. A couple of machines were retrofitted with these features
but this was never sold to customers. "C pointers" in IX mode were a
little bit of a hack. In both V and I modes, indirect pointers were
usually two halfwords long (halfword = 16 bits). Bit 4 in word 1
indicated if a third word was present, which contained a bit offset. The
idea of a bit offset was probably something implemented for future
expansion back when programming in PL/1 with lots of bit strings looked
to be a trend. The bit offset would have allowed new instructions with
bit addressability to be added later. This was all designed circa 1976
(or earlier). By the 80s, it became apparent that the only use for the
third word was string instructions that just needed to know a byte
offset. You don't need a whole word for that, just an odd/even byte
flag. So in IX mode, bit 4 in word 1 indicates if the pointer is to an
even byte address (left byte of 16 bit halfword), or odd byte address
(right byte of 16 bit halfword). It worked and things did run faster,
particularly in C. The general register architecture offered some other
advantages. It is very hard to optimize code if you don't have any
registers. A good part of optimization is register management (i.e.
keeping useful data in registers). The V mode machine had a single 32/64
bit accumulator, 2 index registers, and one floating point accumulator.
There were also some unpleasant idiosyncracies in the V-mode machine. An
index register load/store operation could not be indexed itself! This
was kind of unpleasant for the compiler writers. The I mode machine had
8 general purpose registers that could be index or integer accumulators,
and 2 floating point accumulators. As a general register design, you
could index virtually any instruction with any register. So does that
mean you got different registers in different modes? The general answer
to your question is no. The registers from the various modes all map on
top of each other. I think A/B in R mode becomes A in V mode, and GR0 in
I mode. In addition, in P300 nomenclature, the first few memory
locations are in fact registers. Handling them was referred to as
address trapping, and even they map. I don't remember all the mappings,
but the FP accumulator in S/R and V modes corresponded the FP0 in I
mode. You did have to be a little bit careful, since the behavior of
some of the registers was different in various mode. For instance a/b in
S and R mode is a 31 bit accumulator (the MSB in the B register was not
used in 32 bit operations, and in fact the shift operations went around
it if you were doing a 32 bit shift that involved both registers. The
use of the pointers and lengths in the Zclass instructions would in fact
trash several of the general registers where they mapped.

        Q) 2.19 What's an EPF?

1. Dynamic vs. Static The difference between SEG programs and EPF
programs was a question of "static" vs. "dynamic" allocated structures,
memory, and addressing. You loaded a program with seg in a particular
segment. If two programs wanted to use seg 4000, you were out of luck if
you wanted to run them simultaneously. An EPF loaded with BIND picked
what segment to run in at run time. You could run anything together
simultaneously (almost) if you had enough memory and segments. For the
purist, the difference was also that SEG was a linker and loader, as you
used SEG to execute the program as well. BIND was just a linker; Primos
loaded the .RUN file itself. 2. Command Environment You could suspend
(CTRL/P) an EPF, run something else (even another copy of the same EPF),
then resume it. This had to do with pushing and popping command levels
(STD$CP). You could suspend a SEG program, but if you ran another SEG
program, you almost always could not resume the original SEG program
because the second had trashed the first. 3. Shared vs. Non-Shared EPFs
automatically were shared. If two users invoked the same EPF, the
procedure code was automatically shared, again, using arbitrary segment
numbers for each user. SEG programs could be shared, but only if you
went through a few gyrations to do this at load time, hand-picked the
segment numbers, and executed the proper commands at the console. 4.
Paging from EPF vs. Paging Disk EPFs paged their code in from the EPF
file. SEG programs effectively copied their code to the paging disk. And
as a fallout of #3, all epfs were paged from the same file, further
reducing resource use. Performance Improvement As EPFs were demand-paged
from the file system, this meant that a large program did not have to be
copied completely into memory before it was run. As a result, EPF tended
to start execution faster than other programs. It was possible to
dramatically improve performance of an application by putting
seldom-used code by itself away from the other parts of the program when
linking with BIND. If it was never referenced, it would never be read
from the file system. BIND was also a much faster linker than SEG.
Problems with EPFs One problem users had with EPFs was code that did not
initialize static variables before use. SEG effectively zeroed out all
memory before it was used so everything was initialized to zero. EPFs
did not do this by default because the linkage areas from different
programs were combined into the same segments to save resources. BIND
had a command "IDATA" that could be used to initialize the linkage area
to zero (or anything else) if desired. If an EPF took a condition (e.g.,
POINTER_FAULT$) and "bombed out" it would _remain_ mapped in memory. The
unwitting user edits and compiles a new version of their program, which
is saved as "FOO.RUN". The previous, in-memory version being saved as
"FOO.RP0" or similar. (Great when doing software installs and the
software is in use). However when they type "R FOO" they still get the
old, in-memory copy. So it seems no matter what they do, they get the
same bug. I've seen many novice programmers tear their hair out over
this one. The solution is to follow a program crash by doing "C ALL; RLS
-ALL". Most Prime hackers still do this by habit, regardless of the OS,
so ingrained did the habit become.

        Q) 2.20 Any way to transfer files off a Prime?

There is a way to transfer _text_ files from a standalone Prime to a
Unix box (obviously if you are networked you can use FTP) Firstly
connect the two machines together via the serial ports. Now, rather than
writing a PLP or FTN file transfer program using T$AMLC(), you can use
the Primos print spooler instead. On the Prime you'll need to make the
line assignable: SET_ASYNC -LINE 99 -PRO TRAN -ASGN YES On the Unix box
check there's no getty process running on the line (let's say it was
/dev/tty00) ps -t00 Now create a Prime printer environment file in
-TM 0 HDR 1 (Assumes the longest file is 2000 lines) Start the spooler
PROP UNIX -START On the Unix box you'll need to enter and compile two
short C programs 1. READER.C ----------- #define COMBUFFERSIZE 1000
#include #include #include #include main(argc, argv) int argc; char
**argv; \{ int fd; char portname[100]; struct sgttyb arg; /*** Change
serial device in next line ***/ sprintf(portname, "/dev/tty00"); if ((fd
= open(portname, O_RDWR)) == -1) \{ printf("can't open device %s\n",
portname); exit(1); \} ioctl(fd, TIOCGETP, &arg); arg.sg_ispeed = B9600;
arg.sg_ospeed = B9600; arg.sg_flags &= ~ECHO; arg.sg_flags |= RAW;
ioctl(fd, TIOCSETP, &arg); process(fd); close(fd); \} process(fd) int
fd; \{ char cbuf[COMBUFFERSIZE]; char wrbuf[COMBUFFERSIZE]; int nbuf;
int r,w; w=0; for(;;) \{ nbuf=read(fd, cbuf, COMBUFFERSIZE); r=0;
while(r #include #include #include #define MAX_LINEBUF 128 #define DIR
"/tmp/" /* Change to required directory */ main(argc, argv) int argc;
char **argv; \{ char filename[128]; char line[MAX_LINEBUF]; FILE *fp;
enum \{ idle, nofileyet, noFFyet, receiving \} status; int Stop; int i;
fp=0; status=idle; for(;;) \{ Stop=0; if
(fgets(line,MAX_LINEBUF-1,stdin)!=(char*)0) \{ if(strlen(line)>0) \{
switch(status) \{ case idle: status=nofileyet; break; case nofileyet:
if(strncmp(line,"Pathname:",9)==0) \{ i=strlen(line)-1;
while((line[i]!='>')&&(line[i]!=':')) \{
if((line[i]>='A')&&(line[i]<='Z')) \{ line[i]|=0x20; \} i--; \}
if(line[i]=='>') \{ sprintf(filename, "%s%s", DIR, line+i+1); \} else \{
sprintf(filename,"%sJunk", DIR); \} for(i=strlen(filename)-1;i>0;i--) \{
if((filename[i]!='\n')&&(filename[i]!=' '))break; filename[i]=0; \}
if((fp=fopen(filename,"w"))==(FILE*) 0) \{ printf("can't open '%s'\n",
filename); fflush(stdout); \} else \{ status=noFFyet; printf("receiving
'%s'\n", filename); fflush(stdout); \} \} break; case noFFyet:
if(line[0]==0x0c) status=receiving; break; case receiving:
if(line[0]==0x0c) \{ Stop=1; \} else \{ fprintf(fp,"%s",line); \} break;
\} \} \} if(Stop) \{ if(fp) \{ fclose(fp); printf("Just received file
%s\n", filename); fflush(stdout); \} fp=0; status=idle; \} \} \} Now,
just compile the two Unix programs: cc reader.c -o reader cc writer.c -o
writer And run them, together reader | writer To send a file from the
Prime, just do SPOOL FILENAME -ATT UNIX And it will end up in
/tmp/filename on the Unix box. You can use wildcards, the writer program
extracts the file name from the "Pathname" on the spooler header page.
        Q) 2.21 SCCS Anyone?

What tool did Prime use internally to control their software revisions?
I find it hard enough controlling the work of a handful of C++
developers on PCs, the task of co-ordinating development in the UK, US
and Australia must have been immense! Yet I never saw any ads for an
SCCS-type product for Prime... "It was entirely dependent on the group.
Generally, entire copies of the source tree were kept for each version.
Careful hand management was done to keep these in sync. It was very
primitive." Emacs Group "We had an RCS port, which started seeing some
usage. There were a couple of attempts to create a new source control
systems on an ad hoc basis (anyone remember psychotic?). RCS came close
but was never productized. "The last project I was working on was to be
a fancy multi-system configuration manager which would work with
multiple source and object pools and provide directory like views. But
that was primarily aimed at UNIX, although we hoped to make it work on
PRIMOS as well." INFORMATION group, Australia: "Source control for PI in
Australia was managed by a program called 'sc' written by Dave Bell. He
came from a Unix background so it had all the features of sccs and then
some. I think he gave it to the FSF or something as the 'diff' part of
it was truly unique - using a technique that the DNA people developed to
efficiently compare huge runs of DNA sequence." The PRIMOS group speaks:
"The PRIMOS group used an internal source control system written in CPL
that managed the integration of source code changes. It was extremely
slow, but maintained deltas of all changes to modules, kept track of
which engineers "owned" which modules (at each revision), and kept all
information about which modules were associated with a given change in a
form so that you could go back and see exactly who made a change, who
code-reviewed the change, and which modules were affected. "When doing
development we typically took a copy of the "checkpoint" directory,
which was a complete set of PRIMOS source code, and developed the
changes outside of source control. When the project was completed, the
changes were merged back in. Getting ownership of all the necessary
modules and performing the merge was what took most of the time
(although we did have automatic merge tools). "I have used other source
control systems since then, and they have all been easier to use in the
sense that they allowed you to make a set of changes faster. However,
they all lacked the ability to group a set of changes together for the
purpose of going back at a later date and seeing what was changed. In
general you end up changing each source file separately. I was also
surprised by the lack of a "code reviewer" requirement. Systems like
RCS, CVS, and Clearcase let you check in whatever changes you want
without anyone else putting their name on the line to say that they
looked at what you did." "By far the best system I have used is Atria
Clearcase. It is slower than normal file system access but it has great
functionality." "Other groups in the U.S. typically did not use source
control, mostly because most of the other products did not have a lot of
people working on them. I'm not sure what was done in the UK and
Australia. "Putting together all the pieces of software for a release
was a monumental task. It required lots of people, lots and lots of
meetings, and lots and lots and lots of testing." Willen Lake R&D,
Milton Keynes, England: "At Willen Lake the R&D group used an internally
developed tool called CMAN and I thought it was brilliant. I still do. I
have yet to see anything else as good as CMAN and I have used a few
others including ClearCase. If the author of CMAN can hear me then
listen to this: 'port CMAN to Unix and you will be able to retire
early!'. "CMAN had the ability to group a set of changes together for
the purpose of going back at a later date and seeing what was changed,
and is the only tool I know that allows you to do it easily (you can do
it in ClearCase after a fashion). CMAN used to call it 'tasks'."
Editor's Note - CMAN has been ported to Unix. Contact Clive Backham
( He writes: "Well, I am one of the authors. We
did what you suggested a few years back (ie. re-implemented CMAN on
Unix, what's more making a number of improvements on the way). It was
called UniCycle, and we lost money. Unfortunately, I still have to work
for a living. It was successfully ported to Interactive, SCO, Sun and
Encore (Uncle Ken's outfit). If anyone wants to buy the source to
UniCycle, I'm sure we can come to some agreement. "I think I can look at
it objectively after all this time. UniCycle (nee CMAN) took an unusual
approach to configuration management. Its aim was to actively assist the
support engineer in getting his day-to-day work done, while handling the
source control issues in the background. It had things like impact
analysis, task management, propagation of fixes to other revs, etc. This
was its great strength. Another bit I was very proud of was the fact
that you never needed to write makefiles or build scripts: it could work
out how to build systems automatically. Its major weaknesses were: (i)
it was a closed (albeit extensible) environment, which meant that you
couldn't use your favourite tools such as grep, strings, etc (no big
deal on Primos, which had precious few useful tools anyway, but
obviously a fatal mistake on Unix); (ii) it only had a curses interface
(we never had the resources to do a Motif front end)."

        Q) 2.22 PKZIP or GZIP for Prime?

Was there ever a version/hack of a compression utility like PKZIP or
ARCE or some unix compression utility for use on primos? I once ported
Gnu GZIP to Prime/PRIMOS. I also submitted my changes to the Gzip author
and I think he integrated then into the normal distribution... I also
ported Gnu TAR and some other utilities (GREP, UNCOMPRESS) at the same
time. Anyway, you should be able to get my port(s) via ftp from: Look in the subdirectory "run" for
binaries (compiled on a rev 22 machine I think), or if you have a C
compiler - then look in the "gnu" subdir for the sources (includes CPL
files for compiling them). If gzip gives you the error: Error: condition
"LINKAGE_FAULT$" raised at 4702(3)/22434. Entry name "G$MEMSET" not
found while attempting to resolve dynamic link from procedure "lm_init"
. ER! You need LIBRARIES*>ANSI_CC_LIBRARY.RUN installed on your system.
This should have been supplied with the Translator package. G$MEMSET is
an entrypoint in that library. If you do not have this library, you may
need to contact ComputerVision to get it. I don't know if it's part of
the basic OS package. We don't have CC on our system, but we do have the
library. Go figure. :) Computronics sells a PKZIP compatible product for
the 50 series (and for Unix). It uses the same command line syntax and
options as PKZIP for DOS and supports all of the same file formats as
PKZIP 2.04g. Long filenames are supported, self extracting files, and
many other features allowing Primes to interchange files with Unix,
Windows NT, and other systems, as well as DOS. For more details,
Computronics is at 630/941-7767 or

        Q) 2.23 "Watch" programs, etc.

Does anyone remember a program called "watch" which could be used to see
exactly what a particular user was doing? There are a couple of versions
of a program named PEEK out there that provide that functionality. John
Stanley wrote one, Computronics marketed (still market?) one, and I
wrote one years ago. What version of PRIMOS are you running?
Computronics had versions for just about every release. Mine became
obsolete with rev 22 and dynamically allocated ring buffers. Haven't
heard from John in years, so don't know status of his.

        Q) 2.24 Issues involved porting to Primos

My impression of software on Prime 50-series systems (primarily from
experience with Oracle) is that it only ran well if developed
specifically on the platform. Things developed elsewhere never seemed to
port well. Is this impression correct? If so why - was it connected to
the segmented architecture? And my day was going so well until you had
to resurrect the spectre of Oracle on Prime..... :-( SYNCSORT Syncsort
actually ran pretty well, despite a voracious appetite for memory. I
remember a conversation with Syncsort support folks on behalf of a Major
Power Company in Denver, persuading them that such greed was impolite,
and others on the system needed resources as well. And, to change the
subject completely, let me be the first (for a long time) in this
newsgroup to mention Primeway. There. SAS My memories of porting SAS to
Primos were that there were several problems: 1. Segments! Wrapping from
the top of a segment to the bottom of the segment without any
notification whatsoever was unpleasant, to put it mildly. (At one point,
after we'd been shrieking at Prime about this, I was told that there
were companies who used this "feature" to make segments into ring
buffers, so, of course, it couldn't be changed.) There are lots of
reasons why segments "wrap". Most of it has to do with 32 bit addresses
and 16 bit index registers! This is the most efficient instruction
stream that the compilers (V and I mode) would use by default. You had
to compile your programs with -BIG in order to get the effects of a
linear address space, and then all of your indexes were done with 32-bit
pointer arithmetic. Not as efficient, but probably what you wanted. The
"ring buffer" feature was probably just one example. The real answer had
to do with the history of the architectures: S and R modes were only 16,
32, or 64 K byte address spaces. V mode defined the segmentation and
only kept the 16 bit index registers defining "wrap". I mode could have
defined 32 index registers, but didn't. IX mode supports GRR, and I
think this was the first architecture to allow 32 bit indexing. You
can't just change the machine architecture on a "whim". Most of PRIMOS
would have stopped working. There was a LOT of system code that depended
on segment wrap. 2. 48-bit pointers. Our coding standards required
programmers not to assume that a pointer and a long took up the same
amount of space, but they did it anyway. Yeup. C programmers. They learn
bad habits, and then can't seem to unlearn them. They also think that if
the machine isn't byte addressable, that the C language will protect
them from it. WRONG! C programmers who think that C is a high level
language seem to be the most prone to fall into the "assembly language
traps" that other programmers don't. Actually, 48 bit pointers was where
Prime considered expanding the address space. Either an expanded segment
number, or an extended segment offset could have been put into the 12
unused bits in the 48 pit pointers. Imagine what THAT would have done to
code looking at the E bit in the pointer assuming that its presence only
indicated a bit-offset instead of extended segment or offset values. Of
course having variably sized segments would have been nice. Might even
have taken better advantage of the STLBs and pagemaps and such. 3. Float
doubles and floating point precision. Two byte exponents might allow you
to enumerate all the atoms in the universe, but losing the 8 last bits
of precision wasn't desirable. Also, the layout of the float doubles
made some SAS operations (we allow users to store float doubles on disk
in less than eight bytes) complicated at best. Huh, float doubles have
twice the precision of float singles (47 vs 23 bits of mantissa). You
were expecting more? I suppose you're thinking about DECs floating point
values. They even had an extra bit of precision because floating point
values were always normalized, and then the didn't bother to store the
first mantissa bit (which was always 1 if it was normalizedm right?)
What about QUAD floating point? 128 bits holding 95 bits of precision
and a 16 bit exponent. That's more than IEEE gave you in their extended
precision (which I think is 80 bits). 4. I/O device separation. We have
large chunks of file I/O code which had to handle writing to tapes or
disk files or terminals. (No, I don't like T$MT.) I can't argue with you
there! I still can't figure out why a consistent I/O device interface
was so hard to do right! And that naming convention in the IOCS library:
Doesn't everyone know that I$AA12 is the command stream input device,
and I$AA01 was only for terminal input? 5. Flaky compilers (especially
PL1/G and the early spins of the C compiler -- CI was pretty good), and
the amount of time that it took to get bugs fixed in those compilers. We
did our best. PL1G, F77, and C all suffered in the beginning because the
contractors who provided the compilers all produced code that ran rather
than code that performed! It took years to fix that, and most customers
STILL aren't running the best compilers (T3.2). Prime bought most of its
performance gains in the compilers (C is the notable exception here)
through global and peephole optimization techniques. CI did it through a
better code generator. It was also part of the driving force behind
releasing 32-IX mode (GRR was the other force for F77 as well). CI also
benefitted from some specific C stuff being put into IX mode, like C
pointers (32 bit pointers with the extension bit being used as a byte
offset). 6. SEG, static segments, and shared segments. For us, BIND was
a great improvement, especially the ability to dynamically link EPFs. To
most of the rest of the world, if you wanted your (large) program to
perform, you HAD to use SEG, and know HOW to use it. BIND simplified
many things for the general programmer, but not many learned how to use
registered EPFs well enough to replace their old shared programs, and
people seemed to complain endlessly about long library search rules, and
mapped but unused EPFs taking up memory space. EMPIRE The segmented
architecture was only part of the problem. More to the forefront was the
16-bit I/O and memory address achitecture. When I ported empire to the
50-series a while ago, I ended up riddling the code with: #ifdef
__50SERIES__ #endif mostly to handle the memory addressing problems
associated with the 50 series. Extra i++ everwhere because of the holes
being added to structures to align characters. The C library is VERY
complicated handling 8 bit I/O on top of a 16 bit I/O system. NL on the
Prime is either a LF or a LF followed by a NULL character (16 bit pad).
A lot of these problems were hidden in the C library, but if the user
tried to port code which assumed things, it usually didn't work. That
was Oracle's problem. Their code assumed every system they would run on
was a "normal" byte-addressable system with 8 bit I/O.

        Q) 2.25 What drives does Primos support?

This table was cribbed from the 23.4 README file The FIX_DISK command
and the -DISK_TYPE options of the MAKE command both accept these new
drives. The following is a list of acceptable disk types for these
commands: Disk Type Description CMD Cartridge module device SMD 80MB or
300MB removable SMD 68MB 68MB fixed media 158MB 158MB fixed media 160MB
160MB fixed media 600MB 600MB fixed media SMD MODEL_4475 300MB fixed
media SMD MODEL_4711 60MB fixed media MODEL_4714 84MB fixed media
MODEL_4715 120MB fixed media MODEL_4719 258MB fixed media MODEL_4721
328MB fixed media SCSI MODEL_4729 673MB fixed media MODEL_4730 213MB
fixed media SCSI MODEL_4731 421MB fixed media MODEL_4732 1.34GB fixed
media SCSI MODEL_4734 1.0GB fixed media SCSI MODEL_4735 496MB fixed
media SMD MODEL_4736 2.0GB fixed media SCSI MODEL_4845 770MB fixed media
SMD MODEL_4860 817MB fixed media SMD

        Q) 2.26 How can I print to/from Unix, Novell, VMS or NT using a

I have a Prime 5370 running primos rev24.00 and TCP/IP rev 3 and a
network of fifty PCs all with WFW3.11 and TCP/IP as well. I want to be
able to spool from the Prime to a network printer. I have found LPR
clients for the network, but can't find lpd daemon for the Prime, anyone
have any ideas of an inexpensive way to do this. Computronics sells a
product called LPR that allows the standard rev 22 or later Prime
spooler to print to any LPD compatible printer. This operation is
transparent to the user and one despooler can service more than one
printer. The LPR software also supports Unix like "lpr" and "lpq"
commands. The "lpq" command can be used to display the queue status of
queues on other systems from a user that is on the Prime system. LPD
also allows any system that supports the LPD protocol to print to
printers on the Prime. No special spooler is required on the Prime. Even
non-standard spoolers such as third party spoolers or Rev 19 style
spoolers can be used to print from other systems on to the Prime. For
more details, Computronics is at
        Q) 2.27 Prime Information

Prime Information - PI - was a very successful database product which
ran on 50 series. In 1986, in the City of London office, when Info 7.0
had just came out, we were beseiged by software houses with financial
applications written in Information -Ed. The origins of Prime
Information came from the desire to offer a growth path to Microdata
users. Microdata had the Pick system on its 16 bit systems and
established a vertical market dealer organization. It was very late in
developing a 32bit system, and the dealers became very frustrated. A
company was formed to develop a compatible implementation on Prime 32
bit systems, with firmware support (e.g., I450) provided by Prime for
higher performance. Prime bought out the company in the mid 80's. PI was
licenced in (like Medusa). And, like Medusa, the initial deal didn't
cover Europe. It went like gangbusters in the US and Australia and when
Prime secured European marketing rights, the first two launches in the
UK were really bad flops. It went nowhere until the third launch in
around 1985. Then it really took off. PI has its routes in the Pick
system developed by Dick Pick. It kinda got pushed aside by all the hype
over the relational model and SQL. But, it had some real strengths.
Prime's implemention was really excellent. It tied into Primenet and was
the only implementation of Pick to support X.25. We really stressed this
at the (third) product launch. There was a big conference at the Penta
Hotel (or whatever that ugly hotel next to London Heathrow is called
these days). The theme was: Pick networks ........ Pick Prime
Information. Terrible pun but, I still love it :-) At the tradeshow we
had a dial-up Primenet link into the Corporate network and we'd remote
login to systems in Prime Park and Australia. It blew peoples socks off.
We had to show them the date/time on the remote ssystems before they'd
believe it was for real. Was PI licenced from Dick Pick corp? No. It was
a clone thing. I remember we had to be very careful about the
positioning. We couldn't claim that Prime Information was Pick. We had
to say "Pick-like". However, I think that Prime may have done a deal
with Dick Pick some years later. The Pick story is a long saga of
licencing deals, disputes and acquisitions. What about portability?
Whilst Prime was still in existance we ported Information to UNIX and
called it PI/Open. This was/is available on the major UNIX platforms
(IBM, DG, Digital, HP, etc). Our aim in this development was to get as
closed as possible to 100% compatibility between source AND BINARY code
from Information. E.g. You could take the binary code of an Info/BASIC
program and execute it on PI/open without any problems. We came pretty
close to achieving this. With the demise of PRIME, VMARK Software
purchased PI/Open along with a number of the engineers working on it.
VMARK still markets PI/open. As of release 8, UniVerse (VMARK's original
'Pick like' system) was enhanced in a number of ways to make it more
compatible with PI/open, and hence Information. So Information code
should be portable with not too much change to UniVerse. And not
forgetting the opposition... there are other 'pick style' vendors who
can support Information code with varying degrees of porting required.

        Q) 2.28 I miss ED, what can I do?
Take a look at Greg Field's Web Page. Greg works for CV service in
Australia, and my guess is he may have worked for Prime at some time.

        Q) 2.29 Is there an LPR for the Prime?

If Prime means Primos, and you have tcp/ip you can do this: In the .env
file put this line in instead of the async line TCP/IP -ADDRESS -PORT yyyy is the printer's IP addr,
yyyy is the port number. If you don't know try 515 (lp) or 9100 (hp) or
maybee 23 (telnet) I have tested it with TCP/IP Version 2.4.r26 and a HP
LaserJet 4M with a jetdirect netcard. I don't use it in production
because Primos' TCP/IP cannot deal with it, when the printer is in use.

        Q) 2.30 What is Primeway?

Primeway was an interesting beast. It was a transaction processing
system composed of two parts - the Development Environment, which
integrated source code management (COBOL), Forms development (using FED)
and database access (DBMS and soon after, PRISAM), and allowed multiple
developers to work on what were called 'configurations' - essentially an
application - and the Business Environment, which managed the runtime
side, multiplexing a large number of users into a much smaller number of
'work processes' (phantoms) which handled terminal interaction (all
block mode), and transaction management. It was really very
sophisticated for its time - rumoured to have more lines of code than
Primos - and a complete flop in the marketplace. If it found its way
into 12 customers' hands, I'd be surprised. It was a hard sell - Prime
sales folks in those days were used to being able to sell iron as fast
as it could be made, and to go into a prospective customer with a
monster like Primeway was an unwelcome change of pace. Those who did use
it (at least for a while) were Prime's own Customer Service Center in
Natick, where I worked for a while. Prime also ran part of its business
on it as well, but I don't remember what. The US Army was probably the
biggest customer, and the one I spent the most time looking after, as
the resident expert - they built a *huge* system to do all their
recruiting on, with the intent to deploy it to all the recruiting
offices around the US. Distributed-almost-client-server-stuff, in 1985!
I'm not sure how much of it ever got rolled out - they were setting up
the regions when I left Prime in 1989. Later versions of Primeway had
Oracle support, along with Priforma, a JYACC-based forms tool, but by
then it was way too late.

        Q) 2.31 Does Primos handle Year 2000 correctly?

Year 2000 has been a critical issue for a number of sites. Below is a
variety of Prime Year 2000 information. This same information is
available in HTML format if you visit our web site, and follow the Prime Year 2000 link. PRIMOS and
Year 2000 Computronics has had many calls the past several months from
Prime 50 series users, asking about PRIMOS compat- ibility and the year
2000. We have completed a detailed study of this matter, and have a lot
of news... The Issue: The big question: "Will PRIMOS work properly with
dates after 31 December 1999"? The answer: With your current revision of
PRIMOS, as it stands, no. But there's a solution! The good news:
Computronics has put together a "Year 2000 tool kit" of utilities and
patches that will enable a wide variety of PRIMOS revisions to work
properly in the year 2000 time period. We have been studying this matter
for months and have found the issues and come up with ways to work
around them. So you _won't_ need to pull the plug on the Prime when the
date rolls over to 2000. More on this later... What will happen if you
do nothing at all? Two sets of problems come up. First of all, most
versions of PRIMOS will roll the date over from 31 December 1999 to 01
January 2000 properly. Some older versions roll over to a date of
"01/01/00", which is right, but some utilities display this date wrong,
perhaps as a date like "January 1, 19100". But this is not true in all
utilities nor in as many places in more recent versions of PRIMOS. Such
problems vary a great deal by revision. Then a number of things start to
break. The spooler prints incorrect dates, as do various other
utilities. DSM stops working. The second issue, which can be even more
serious, is that the VCP clock information is not sent properly to the
system when booting, and virtually all version of PRIMOS will take a VCP
date of "01/01/00" and set the date in PRIMOS itself to "01/02/28". This
will happen again on each reboot. So even with a properly set VCP clock,
the PRIMOS date will be wrong. Solutions: Now for the big question. What
do you do about these problems? One option is to upgrade to a later
version of PRIMOS. ComputerVision Services has announced two special
patch releases of PRIMOS for revision 23.4 and 24.0. Many Prime users
have contacted Computronics and expressed concern with this option. For
people not on CVSI maintenance, upgrade price may be a question. But for
all users, there are always concerns about the impact of a PRIMOS
upgrade. Some sites are on older revisions, such as 22.1 or 23.2 because
of variety of reasons: Perhaps they are running applications that were
never migrated or tested at later releases of PRIMOS. In some cases, the
applications or other subsystems were written by companies that are out
of business or individuals that are no longer available. Some sites have
smaller systems and don't want to run a later version of PRIMOS due to
the performance impact on their system. In add- ition to these reasons,
some sites that are already on release 23.4 or 24.0 do not have the
resources to deal with a PRIMOS change; the people who "knew the Prime"
just aren't around any more. (Or if they are still around, their memory
isn't what it used to be ;-) So, what is the alternative? Computronics
is pleased to announce the "Year 2000 Toolkit for Prime Systems". This
is a set of libraries and patches that will resolve or work around the
problems that have been found in various revisions of PRIMOS. These
patches will solve the bulk of the problems, including serious ones such
as the VCP clock problem mentioned above. It does this by actually
patching your current version of PRIMOS, so you are not upgrading
PRIMOS! Fixes are even available for older programs, such as the
pre-revision 21 spooler! Application Issues: What things are not fixed?
YOUR APPLICATIONS! If you have not resolved applications issues, this
toolkit is NOT going to help you. You will need to make sure that all of
your applications utilize a four digit year, or that they do date
comparisons properly if you will be using two digit years. That is, if
you are going to continue to use a two digit year, your applications
will need to be designed so that they know that 12/31/99 is less than
01/01/00. The Computronics toolkit can help with testing your
applications! The toolkit includes a mode that you can set for selected
users to enable them to execute programs with a different date than the
system date. Thus from that user's point of view the date is now a new
date that you specify. For your testing purposes, keep in mind that
there are a number of considerations in doing this on a production
system, as you will have other programs using the correct date, and so
potentially you will have mixed dates in files. Thus the testing can
itself cause problems in some applications; just make sure you are using
test files and copies of databases before undergoing such tests. (This
is a concern for anyone performing year 2000 testing, on any system).
What is Supported by the Toolkit?: What PRIMOS revisions are supported
by the Year 2000 Toolkit? Revision 20.2, 21.0, 22.1, 23.2, 23.3, 23.4
and 24.0, as well as the various "dot" releases. You tell Computronics
your exact version number and a they will ship you a toolkit tailored
for that exact version. There are _no_ plans to support very old
revisions such as revision 19 or 20.0; such changes are feasible, but we
do not think there is enough demand to warrant the additional work. Will
_everything_ be fixed? Again, you will need to deal with application
issues. Also, the toolkit is designed to fix the bigger problems, and
not every possible issue, particularly at older versions of PRIMOS. The
problems that are not addressed will be of a cosmetic nature, in the way
some utilities display dates. They will not be issues that impact the
system in a serious way. Can I try the Toolkit? Sure! You don't have to
take Computronics word that it works. Computronics will offer a single
30 day trial to any prospective customer. The 30 days begins when you
install the toolkit. This will enable you to give it a test drive in
advance of the magic 1 January 2000 date so that you can see how it
works for yourself! And remember, no hardware changes, no new PRIMOS
revisions to install, no "Hardware Audit" to be done! Price and
Warranty: What will the toolkit cost? Pricing varies, in a range of
US$1500 to US$5000 for a single system license. This price will depend
on the cpu model that you are using, and the revision of PRIMOS that you
are running. The licensing is "tied" to a specific cpu, but multiple cpu
discounts are available. Please contact Computronics with your CPU model
and PRIMOS revision. All prices will be in the range shown above. Is
there a warranty? Computronics warrants that the Year 2000 Toolkit will
fix the PRIMOS related date issues, and also Computronics will work with
you to resolve anything that might have been missed. But Computronics
can't guarantee that every last problem in every last routine has been
fixed. And so the warranty for the Toolkit is limited to Computronics
fixing any problems with the Toolkit or you will get your money back. No
consequential damages and all of that stuff; you know the fine print...
And, once again, YOU will need to look at any year 2000 impacts in your
applications. Other Products: What about related products? Computronics
is ready to work with you to discuss other issues. Certain commonly used
products have already been evaluated for year 2000 issues. One of these
products is Prime/Information. PI will _not_ work properly after the
year 2000. In fact, the DATE() function returns a negative number for
the internal date that corresponds to 1 January 1900. The DATE command
displays the year as 1900, as does the TIMEDATE() function. There is
good news for users of Prime/Information, however. The Vmark (now known
as Ardent) Corporation that maintains Prime/Information has produced
patches for most commonly used versions of Prime/Information, including
these special releases: 8.4.r4, 8.1.4.r12, 8.0.r26, and 7.0.4.r3. What
about users of Henco's INFO database? Again, there is good news.
Computronics has run a series of tests on a system running the Year 2000
Toolkit and the Henco INFO programs ran just fine, treating all years as
four digits and handling a year of 2000 properly. What about other
programs and products? Computronics is not in a position to test every
piece of software out there, and certainly not your applications. But
consulting services are available to run tests with you, to run tests on
Computronics' system, or just to work with you as this critical year
2000 time approaches. What about Computronics Products?: Who is
Computronics? Well, one of the most popular software products ever
written for Prime 50-series systems is PEEK, written, sold and
maintained by Computronics. Another popular product is LPR, to enable
the Prime to use TCP/IP based printing to Unix or NT hosts. LPD to
enable the Prime to _be_ an LPD compliant print server. Zip for PRIMOS
to enable Prime 50-series systems to create and work with pkzip
compatible archives. And there are other products including Log-Time for
system resource accounting, Usage Accounting, Network, the HP Laserjet
printer driver, various FORMS drivers. Since 1993 Computronics has
developed many Unix products, such as Peek for Unix and ZIP for Unix.
All Computronics utilities mentioned in this section are year 2000
compliant. If you are under maintenance for these products, new year
2000 compatible releases are avail- able for these products at no
charge. If you are not under maintenance, appropriate releases will be
available at special prices. Call Computronics for details. As so many
of the Prime users have new personnel that may not be real familiar with
the software on their systems, below is a list of all Computronics
product names so that you can determine if you are running any of these
products: PEEK, AMLC Status, CPL To Shell Convertor, Log-Time, Login
Security Trail, Network, Password Expiration, PrintMaster, Remote Print
Handler, SoftWire, Status Line Message, Usage Accounting, ZIP, Printer
Drivers for HP Laserjet and others, LPR, LPD, SNA, DPTX, and FORMS
terminal drivers... If you believe you may be running any of these
products, contact the people at Computronics for details about Year 2000
versions of the products. How to Get The Toolkit: Contact Computronics
for information on the "Year 2000 Toolkit for Prime Systems". You should
know your PRIMOS revision and CPU model before calling. Use the commands
"status system" and "status hdwr" to get these items of information.
Computronics is at 4N165 Wood Dale Road, Addison, Illinois 60101.
Telephone: 630/941-7767. Fax: 630/941-7714. Email:
Web page:

        Q) 2.32 What do I do with my CPL programs if I move to Unix?

Computronics sells a CPL converter that will take your CPL programs and
turn them into Unix shell scripts. Some manual changes may be needed,
but 95% of what is in a CPL is translated and there is no need for any
run-time library or Prime emulation software on the Unix side. For more
details, Computronics is at 630/941-7767 or

        Q) 2.33 Porting INFORMATION to relational databases

What with the Year 2000 problem and the increasing age of installed
Prime kit, a lot of people are looking at migrating their INFORMATION
applications on to other platforms. After all, when you look at it, the
old hardware is practically worthless but in contrast the value locked
up in the data and applications residing on it may be almost
incalculable. A useful port of call may be VMark systems who I believe
own the rights to the INFORMATION product and its descendants.
( INFORMATION is a Pick-like database system. It is not
relational. This means you can have things like multiple-valued fields.
Because it is not relational it may require some work to map an
INFORMATION database onto a relational database such as Access, MS SQL
Server or Oracle. The good news is, however, that as far as I know, if
you have an INFORMATION-based application running on your Prime, you
also have access to the development environment and can write your own
INFO/BASIC programs to assist in dumping out the data. Here are a few
examples to get you started. FILEDUMP.IBAS - Just dumps the entire file.
Because it sorts it by key it has been known to fall over on a very big
file, but you can just comment out the sort line. * FILEDUMP - Dumps a
file in ASCII for archiving
* This routine is passed a filename on the command line (it assumes the
* last element is the filename to process). It then reads the VOC entry
* for the data and dictionary files, and strips the last element off. *
This is then used as the record key for a record in the type 1 file *
DUMPFILE. The data or dict file is selected by id, each record read * in
turn, and the contents dumped into the DUMPFILE record as a line * with
the format "key" "item-mark" "data". * These can then be written to CD
for recovery if/when we ever need the * data again. ARGS = CONVERT( " ",
DICTFILE END END RETURN END SORT1.IBAS - does the sort mentioned above.
* sort1 sorts a dynamic array by the requested delimiter
point sorting 0 or 1 * Convert dynamic array into matrix DIMENSION
ascend/descent, justify, and start interval AD = SORTTYPE[1,1] LR =
SORTTYPE[2,1] INTERVAL = INT(FIELDCOUNT*0.5) * Now to business - the
outer LOOP continues until the swap interval * has been through 1 to
become zero. The inner FOR 'bubbles' each entry * up as far as it will
INT(INTERVAL*0.5) REPEAT * Now rebuild dynamic array and return *
MATBUILD ARRAY FROM MATRIX USING DELIM ;* Doesn't work - infobasic bug
RETURN ******************************** * This simply compares the
current entry with the entry INTERVAL before. * If it is in the correct
order, or the current entry is too close to the * top it returns.
Otherwise it swaps the two entries, and loops to see if * it can move
the current entry even higher. SWAP: LOOP COMPVAR = SWAPVAR - INTERVAL
COMPVAR REPEAT END TEXDUMP.IBAS - a rather more sophisticated file dump
routine, driven by the command line. It's got the syntax in it at the
bottom. * TEXDUMP - dumps fields from a file in ascii
DECLARATION * Command parsing code. Pretty self-explanatory. See SYNTAX:
for command syntax SENTENCE = CONVERT( ' ', @FM, TRIM( @SENTENCE))
"No arguments to command" ; GOSUB SYNTAX: REMOVE SOURCEFILE FROM
TARGETFILE THEN IF REM EQ 0 THEN MESS = 'Target must include a record
OPEN "", "&HOLD&" TO TARGETFILE ELSE MESS = "Unable to open &HOLD&" ;
* If no optional arguments then go and select everything GOSUB
command to select required records COMMAND = 'SELECT ':SOURCEFILE LOOP
'SELECT.LIST' * read pre-existing select list REMOVE KEYWORD FROM
SENTENCE SETTING REM CASE 1 * no selection therefore select everything
AND REM NE 0 THEN * get list of field-names to save IF KEYWORD EQ
DELIM1 = "" ; DELIM2 = "" IF KEYWORD EQ 'DELIM' THEN * choose field and
value delimiters else default to prime standard IF REM EQ 0 THEN MESS =
MESS = 'Too many arguments to DELIM' ; GOSUB SYNTAX: END IF DELIM1 THEN
@FM:@VM, ",,", DICTLIST) ELSE OUTPUT = "" LOOP * loop through each
ELSE STOP 'Record ':KEY:' disappeared while processing' * and each field
Apply OCONV conversion for output IF FIELDMAT(II)<3> THEN CALL !OCONVS(
TARGETREC RETURN ******************************** * this is a slightly
odd routine with two entry-points ALL.FIELDS: * select dictionary
DICT2LIST ELSE STOP 'No fields found in Dictionary' * and build list
2 THEN DICTLIST = "@ID" : @FM : DICTLIST FIELDS: * now validate
DICT, FIELD ELSE STOP 'Field ':FIELD:' not found on dictionary' END
RETURN ******************************** * called if command has a syntax
error SYNTAX: PRINT MESS ; PRINT PRINT "TEXDUMP file TO [file] record"
PRINT "[SELECTING select options]" PRINT "[SELECT.LIST]" PRINT "[HEADER]" PRINT "[SAVING] [fields to save]"
PRINT "[QUOTED]" PRINT "[DELIM field_separator [value_separator]]" STOP

        Q) 2.34 16 node limit on Prime Gateways

Re. using GATEWAYS in TCP/IP>HOSTS.TXT file to limit who can access a
machine: how do you get over what seems to me a restriction of 16
entries when using TCP/IPTHU! We are using version 2.4.R39-22.0 Well, 16
is the restriction. There is no way to raise it with the TCP/IP 2.4
series that I've ever heard of. But, the good news is that you can
almost always get around it by using a class B address as a gateway or
by specifying a wildcard gateway. A wildcard will enable a mode where
any unknown IP address gets passed through to a specific gateway. Works
fine for situations like this.

        Q) 3.1 What the h*ll is DEREMER? It doesn't seem to do anything
        at all!

Basically, "DEREMER" is/was Prime's YACC. The history of "DEREMER" is:
Frank Deremer did a PhD Thesis (circa 1970) on automatic parser
generators for the front-ends of compilers. A Harvard University
student, Robert Schwartz, wrote a parser generator based on Frank
Deremer's work. Later, when Robert got a job at Prime computer sometime
in 1977/78 he brought his Harvard student project with him to Prime and
called it "DEREMER". Those of us in the Prime Translator Group used
"DEREMER" to build the COBOL-85 front-end, among other things such as
RPG (!). At a compiler seminar once at BBN, Frank Deremer heard about
this and, as the featured speaker, said that he was proud that people at
Prime "DEREME" their compilers, thus changing the noun "DEREMER" into a
verb, "DEREME" which means "processing a grammar through DEREMER".
Officially DEREMER is an LALR(1) parser generator, but I think that
about 5 years after DEREMER was written, Frank Deremer proved that his
paper was actually about an ALMOST LALR(1) parser generator. It works
well enough for what Prime used it for (though some of the COBOL
grammars are NOT for those who beleive that parsers should be generated
without warnings or conflicts!)

        Q) 3.2 What does the MAKE_BINARY program do?

MAKE_BINARY is the successor to GENERATE_BINARY_LIBRARY, which is the
successor to EDB. It creates .BIN files suitable for the LIB directory.
It is also used to create so called "DYNT-Libraries", .BIN files which
contain no code, only dynamic link directives to resolve various names
in the loader/linkers.
        Q) 3.3 What is the difference between SPL and NEW_SPL?

At one time SPL was changing so fast (bug fixes AND enhanced
optimizations) that engineering claimed that they had no time to
evaluate its effect on products developed with the "not the latest
version" of SPL. The people building the master disk software decreed
that all products will be built with the previous release's version of
SPL, and that the new one being submitted would be available during the
build process as NEW_SPL. It was only to be used by those products which
depended upon its new features or critical bug fixes. I think the split
started sometime in the 19.4, 20.2, or 21.0 time frame, and was
eradicated when SPL was added as a member of the "T-Family" at
T2.0-22.1. (Talk about being short lived!)

        Q) 3.4 What does INDEX>BUILD do?

I wrote BUILD because we didn't have UNIX make and I was getting very
frustrated with the EMACS project. It was too big to just always
recompile, yet hand recompilation often led to trouble. So I wrote
BUILD. I couldn't call it MAKE since that was taken :) BUILD was
reasonably flexible and used search paths for finding sources and
derived objects. It had some ability to work with RCS archives (we were
going to productize RCS back then). It didn't implement several UNIX
make constructs. Macros (only variables), and multiway targets (or at
least I don't think I did this). Sometime after I did this the PRIMOS
group started using it. Then it started being pretty popular. After I
stopped working on PRIME's EMACS, the person who took over EMACS decided
BUILD was too complex a tool and went back to CPL scripts. I needn't
tell you my opinion on that course. I kept up BUILD until I left in '89.

        Q) 4.1 How did Prime start?

Prime was started on February 4th, 1972 by seven founders: Robert Baron
(President) Sidney Halligan (VP Sales) James Campbell (Director of
Marketing) Joseph Cashen (VP Hardware Engineering) Robert Burkeweitz (VP
Manufacturing) William Poduska (VP Software Engineering) John Carter
(Director of Human Resources) The company started with the motto
"Software First". David Udin (a part-time employee while in graduate
school) and Joe Brownstein were the first programmers hired. Bill
Poduska's ideas about what to put into the computers they were designing
(paging hardware, heavy use of microcoding) more or less determined the
technical direction of the company and enabled its success (while it was
successful). Otherwise Prime would have been just another minicomputer
company and folded a lot earlier than it did. Prime produced a machine
called the Prime 200 which was compatible with the Honeywell 316 and 516
range which had just been dropped but for which there was still a
demand. Later on they brought out the Prime 100, a stripped-down 200
without processor or memory parity and no option for processor
microverify or floating point. Many of these systems, which were
generally only used for dedicated realtime activities, still survive as
controller engines in printing systems made by Morgenthaller and
Linotype, as well as in the guise of Tape Controllers in Storage
Technology products. National Geographic Magazine used them extensively.
The Prime 300 was next and was dropped in early 1979. The Prime 400 must
have been one of the most successful machines of its day, but it was
with the introduction of the "VAX-killer" Prime 750 (1 MIP!) in 1979
that fortune first began to smile on Prime. Fortune 500, to be precise.
The following year, 1980, Prime stock was the No.1 performing stock on
the NYSE. Mr. Poduska later went on to found Apollo Computer Corp. Users
will know that commands like "LD" and "BIND" found their way into the
Apollo operating systems.

        Q) 4.2 What happened to Prime Computer, Inc?

In 1988 Prime realised that the game was up. Customers were defecting to
workstations in droves. Prime were trying to sell big mainframes which
cost a fortune to run and charging ridiculous amounts for software such
as compilers, etc. What was happening was that hardware - which had been
the focus of computing up to the mid 1980s - was becoming a cheap
commodity. It was only in the area of applications software where money
could be made. Enter Computervision (CV). This company started around
the late 60's producing Computer Aided Design (CAD) software systems. In
the absence of any standard hardware platform CV badged Data General
minis which ran under CGOS (ComputerVision Graphical Operating System).
However they always made their money from their software applications.
When the Unix workstations first appeared in the mid 80's CV rapidly
migrated its products to these platforms and dropped the mainframes.
Prime puchased CV in late 1988/early 1989 for around $300M. In early
'89, roughly March, a heavily leveraged, hostile take-over bid was
launched by BASIC4. It was feared that Prime would be taken over and
dismantled for profit. In June '89 the senior management (Tony Craig was
the 'hired-gun' CEO) of Prime was looking at how to fend off the hostile
take-over. This resulted in finding the 'white knight' to take Prime
private and out of harm's way. New York venture capitalist, JH Whitney,
arranged the financing and buyout. The end result was Prime being
purchased by DR Holdings, Inc., the shell company set up by JH Whitney,
for the princely sum of $1.2 Billion, give or take a few hundred
million. This privatization happened around September or October of
1989. The first round of big layoffs was in November. At the time, the
CPU Group was running two large developments. The first "Pink Flamingo",
an ECL, heavily pipelined redesign of the Intel 80486, targetted to run
at 200MHz and roughly 180 Mips. The second, "Garfield", was a CMOS-based
50 Series CPU with a brand-new pipeline and micro-architecture. Flamingo
died that November and everyone, from the Director down, was terminated.
Later, these people were "interviewed" for continued employment on
Garfield. It was at this time that the Bobcat (5340?) and Stallion
(5540?) projects were being wrapped up. Bobcat was Prime's first forray
into CMOS gate-array's and was a "copy" of the Leopard/Cougar ECL-based
CPU's, 6250/6450/6650's. Stallion was a dual-Bobcat. Shortly after the
buyout, Dec'89/Jan'90, a project was spun up to design a new
multi-processor memory sub-system, able to support from 2 to 16
processors. This project was called Wile E. Coyote. The first phase of
this program was to utilize the Bobcat CPU for design debug purposes and
interim product-line filling, i.e. a "dual-Coyote" would have been
functionally equivalent to a Stallion, but able to be expanded to a
4-way or 8-way system. This memory sub-system was to also be used for
the new Garfield processor, which was purely a CPU design, not a system
design. Due to declining revenues, shrinking budgets and time, it was
decided to cancel the Bobcat-based Coyote product plans and re-target
Coyote to be solely for the Garfield CPU. This was also largely
influenced by the spawning of a new project to develop a brand-new,
multi-processor machine to run Unix. This occured in June/July 1990 and
the project was code-named Overlord. It was also considered to be the
"hot-project" since it would get Prime out from under having to OEM its
Unix-based Pyramid and MIPs systems. This new system was to be completed
in "9 to 14 months" according to our new CEO, Jack Shields. Anyway,
engineers were moved onto Overlord and focus shifted away from Garfield
and Coyote. Another new project was spun up to design a brand-new IO
sub-system for Garfield, code-name Odie, and these three projects were
combined into a complete system-level project called Toons. (Since all
three were named after cartoon characters) Just over a year later,
mid-1991, the Overlord project was cancelled by Prime's senior
management, some of the reasons being that the MIPs R4000 CPU had
slipped nearly a year and Prime were unable to successfully license a
Unix implementation, so were porting their own. Some of these people
were RIF'd, others re-joined the Toons project, while other's continued
working on the Overlord R4000 chip-set as contractors for LSI
Logic/Groupe Bull. Needless to say, focus was returned to the Toons
project as the savior of the company. Throughout the end of 1991, it
became readily apparent that the project was far behind schedule for a
multitude of reasons: * Lack of staff * Poor morale * Management not
accepting the engineer's assessment of schedules * etc, etc In January
of 1992 a new man was brought in to run the CPU organization as the VP
of engineering. This person was Peter Weyman and he breathed new life
and vitality into the whole organization. Schedules were re-evaluated in
an honest fashion and processes/methodologies put in place to ensure the
schedules were met. The Toons project was moving along quite nicely as
summer approached, but as usual, the company was continuing to fail,
revenues were declining at a much steeper rate than anticipated and it
was becoming clear that it might not be possible to fund the Toons
project through it's completion. It was for this reason that the "local"
senior management, the VP of Engineering and the like, decided that it
might make sense to spin off the 50 Series engineering organization for
profit. It was reasoned that the loyal base of 50 Series customers
really wanted and required the Toons product, therefore if Prime could
continue working without the shadow of a $1 billion of debt, Prime could
be successful. Financing and purchasers were being actively sought in
late July 1992 when the axe finally fell, it was July 22, to be exact.
On this day, workers were informed that the Board of Directors had
decided to cease 50 Series operations and take the remainder of the
company public, once again under the name of Computervision. This was a
Wednesday and we were all told to take the rest of the week off, since
there was no need for us to be there any longer. The following week we
received termination packages and were required to be gone by that
Friday, July 31st, 1992. Regarding the Toons project: * By July of 1992,
Prime had already taken orders for 20 or 30 Toons systems, even though
they weren't going to realistically ship to a customer until at least
January or February of 1993. These orders were shown on the "Field of
Dreams" in the hallway, along with the motto, "If you build it, they
will come". * Prime had operational prototypes of the entire Toons
system running in the lab when it was cancelled. * After the meeting to
announce the closing of Prime, engineers returned to the lab and
continued working on booting Primos on the Toons system. They were
successful. * Prime were in the process of releasing the "full-speed"
'production' versions of the chips that made up the Garfield CPU at the
time operations ceased. * The last director of the CPU Group, Mark
Laird, continues to hold a yearly Prime re-union at his home, the 4th of
which was on Sept 9th, 1995 One of the things that did Prime in, was its
failure to keep up with the customers. The need for perfomance in this
business goes up about 30% per year. On that basis, by the late 1980's
Prime was seriously behind the industry. The seriousness of the problem
become clear when the 5000 series came out. The low end machines were
promised to the customers as 8 Mip, they didn't even come close. The
high end machine (the 5330/5340) was promised as 11 Mip, it is perhaps 5
mip. The Toons engine was supposed to be 13 mip, and while it does run,
it is nowhere near the 13 MIPS level required. The life cycle for most
systems and controllers in this industry by the late 1980's was down to
2 years. Prime was selling machines that had been repackaged 3 times,
and were 6 and 7 years old. In the final 3 years Prime built new
hardware: there were 2 new controllers, the Lan Host Controller, and the
Swordfish. The record of the R&D operation in producing new products
after about 1983 is disaster heaped upon catastrophe. This shows up in
one other way. By 1992, Prime was so far behind in CPU technology that
not a single system PRIME sold was subject to export controls anymore.
The performance was below the threshold for controls. In the end, Prime
was just a company which failed to keep up with the technology. At 20
years old, it was probably one of the longest-lived computer businesses.
Had the Prime name survived, the company itself would now be changed out
of all recognition, probably badging Pentiums as "Business Servers". No
matter _how_ good the hardware, people just won't pay top dollar for it
any more. Even though a Prime may beat a PC architecturally, by contrast
the software, service and support on the Intel platform is cheap. Not
only that, but the applications which sell well today are based on GUI
technology. Good or bad, whatever your opinion of the Prime engines and
Primos operating system, they just ceased being competitive.

        Q) 4.3 Who were all the people on the front of the Prime manuals?

There were several different versions of covers on Prime manuals
featuring pictures. At first, the pictures were all of people from
in-house (Prime) in the late 70's, but later evolved to stock photos,
I'm sure from some catalog of pictures that used models. Fortunately, I
think that the descriptions below are unique enough that you can tell if
the one to which I am referring is the one you are looking at. Note that
some covers flipped the pictures. The person may be looking left on one
cover and looking right on another cover. * Bald gentleman in white
shirt, tie, suit jacket: Ken Fisher, president of Prime. (There are
actually two different photos of Ken - one with him seated in a high
back chair, looking into the camera and another with him sorta sitting
on a desk, looking to the side). Ken Fisher was the president who took
Prime from a company that was barely making it to a roaring success,
doubling both sales and the stock price four or five times in the latter
half of the 70's and very early 80's. * Frizzy haired guy in plaid shirt
with circuit board in background: Dave Lounsberry. Dave was working on
magtape controllers at that time, though he later went on to be a
manager in the video products group. * Two guys looking at something,
with Prime front switch panel in foreground. One guy has a turtleneck,
glasses, and beard; the other guy has a mustache, glasses, and red
sweater: Eric Pierson and Mark Nobile. Eric worked on Midas in the late
70's. At the time this picture was taken, they were both working on
Powerplus. * Chinese woman with black frizzy hair and red dress: Grace
Na, a very much liked writer from Tech Pubs. * Guy with messy desk
looking at the code listing he is flipping through: Dave Treff. Treff
worked on the FTN compiler, improving the optimizer in the late 70's and
early 80's. * Woman with glasses, pulled back hair, holding a magtape,
standing in front of Prime computer in background: Patricia Powers.
Patricia was a field analyst from New York who later came to work in the
Data Management Group in Engineering. * Bald guy with glasses and beard
in white shirt and tie looking off to side (at a terminal out of the
picture): Tony Lewis, senior writer in Tech Pubs. * Woman seated in
chair with elbows on chair arms, fingers pressed together in air in
front of her: Ev Tate. Ev was a senior comms engineer. * Woman and man
seated, facing camera. Woman in blue knit dress, man in white shirt that
has a blue patterned top: Laura and Bryan Douros, one of several couples
both working at Prime. Laura was a writer in Tech Pubs. Brian was a
hardware engineer in the CPU Group. (This picture appeared on one of
Prime's pocket guides, but I don't know if it was ever used on full size
manual cover.) * Guy in dark blue shirt, wire rim glasses, full head of
hair but no facial hair, arms crossed above waist level, turned to side
but looking into camera: Mark Johnson, microcoder and CPU engineer
extraordinaire. * Guy standing with dark hair, beard, no glasses,
holding coffee mug in one hand, looking down at listing he is flipping
listing with other hand, old cpu with "bump out" panel in back ground:
Bob Beckwith, CPU/microcode engineer. * Woman in white sweatshirt,
seated, looking to side, hand on head: Randi Klein, DBMS group engineer.
* Man in white striped shirt, tie, frizzy hair, frizzy beard, tinted
glasses: Max Goudy (?) I know this was a Tech Pubs person, but I
probably have the name wrong. He may have been the group manager.
Favorite faces were Harry Bingyou (Sales in San Francisco), the guy with
the oriental look and the mustache. The lady sitting next to a Terminet
30 and with the Pertec tape in the background was the regional database
specialist in San Diego. The guy standing next to the lady in the pink
dress in front of a P400 with a model 33 TTY is Stuart somebody. He ran
the education center in Los Angeles. Pat Sansonetti is the balding guy
with the beard and glasses. He did most of the Primenet stuff. The tall
bald guy in the office was Ken Fisher. The grey haired shorter guy in
front of the P400 with floppies (8 inch) and the Pertec was Bob Clausen,
VP of Sales.
        Q) 4.4 What was the history of Prime?

This is cribbed from "The Pocket Prime" 1972: Company founded First
product was the 200 computer 1973: Prime U.K. opens 100 and 300 systems
announced 1974: Prime Germany opens First public Stock offering at $7
per share; adjusted for subsequent stock splits, equivalent to $0.52 per
share 1976: Prime France opens International sales account for more than
40% of revenue 400 computer announced 1977: Prime Scandinavia opens 500
system announced 1978: Prime listed on New York Stock Exchange Puerto
Rico plant opens 1979: Prime Benelux opens 50 Series product line
announced: 450, 550, 650, and 750 systems Prime INFORMATION systems
announced PRIMENET software announced RINGNET local area network
announced 1980: Prime opens new corporate headquarters in Natick,
Massachusetts Prime Italy opens Prime Canada opens Prime Australia opens
Ireland plant opens 150 and 250 systems announced 1981: Prime enters CAD
marketplace with announcement of exclusive worldwide marketing rights
(with the exception of Western Europe) to MEDUSA software 850 computer
announced 1982: Prime Switzerland opens 2250 system announced 1983:
Prime Hong Kong opens Prime joins the Fortune 500, ranking 489 Revenue
exceeds $500,000,000 Prime aquires exclusive worldwide rights to market
Ford Motor Company's Product Design Graphics System (PDGS) software 9950
system announced 1984: Joint ownership of MEDUSA is purchased, allowing
Prime to market worldwide its version called PRIME MEDUSA Prime aquires
worldwide marketing rights to Graphical Numerical Control (GNC) SAMMIE
is introduced Prime Japan is acquired Prime Singapore opens Prime ranks
451 on Fortune 500 2550, 9650, 9750 systems announced Value Added
Resellar (VAR) program announced Prime Technology Centers open in Natick
and Stevenage 1985: Prime ranks 400 on the Fortune 500 9955, 9655, 2655
systems announced PT200 terminal announced Prime/SNA software announced
Prime Technology Center opens in Detroit Prime INFORMATION CONNECTION
announced PERFORMER workstation is announced FM+ is announced Prime
announces OEM program and signs agreements with Eastman Kodak and 3M
Company Beijing, China representative office opens Value Added
Distributor (VAD) program announced 1986: Prime announces new corporate
identity program Prime ranks 366 on Fortune 500 2350, 2450, 9755, and
9955-II systems announced Prime ORACLE announced PRIMELINK announced
1987: Prime offers $375,000,000 in Convertable Subordinated Debentures
Prime makes tender offer for Computervision Corp. Prime acquires
Versacad Corp. 2455, 2755, 6350, and 6550 systems announced PRIME EXL
316 superminicomputer announced PXCL 5500 workstation announced Prime
ranks 337 in Fortune 500 Prime communication software - LAN300, NTS,
WSI300, PRIMENET support of CCITT and PRIME/SNA API announced First sale
of PDGS made to leading Japanese tool and die supplier to international
auto industry Graphics created by PXCL 5500 workstation featured on
"Star Trek" television episode 1988: Prime and Computervision merge
4050, 4150, 4450, and 6150 superminicomputers announced Prime
INFORMATION EXL announced Prime restructures into two sales and
marketing divisions Prime EXL 320 and 325 announced PrimeDESIGN and
PrimeCONTROL software announced Prime ranks 334 on Fortune 500 list
Prime co-sponsors "NOVA", the longest running science series on
commercial public television 1992: July 22 - Prime board decide to cease
50 Series operations.
         Q) 4.5 Why did Prime never get its act together on the Unix

As an ex-primate now working in that area, I feel that Prime's messing
around in the Unix market and never handling it right was a major
contributor to its failure. Until it was far too late to do anything
realistic about it, the primary attitude towards UNIX was a devout wish
that it would all "go away". Those advocating an early entry into the
UNIX busines were stymied by the prevailing attitude "Prime sells 50
Series PRIMOS systems". UNIX projects could be funded if they didn't
impact the 50 series. By the time the powers that be decided they
couldn't ignore UNIX any longer, it was a question of "too little, too
late". Prime made the fatal mistake of not realizing that if someone is
going to obsolete your products, it had better be you. Several
attitudes, as well as famous quotes, contributed: 1. "If we don't sell
it, then it isn't our market." --Famous explanation from Prime Marketing
why they wouldn't accept new products from Prime Engineering requiring
them to market in new areas. 2. "We going to buy this product because we
need it now." --Famous line from Prime Marketing why they were going to
buy a software product [of poor quality] from an outside vendor they
previously rejected from Engineering just a year or two previously.
(happened more than once.) 3. "We don't want to cut into our existing
product sales." --Famous line as to why not to develop several products.
4. "It would make money, but not [fast] enough." --Why various internal
projects were cancelled late in the company's lifespan during and after
the buyout/takeover. An interesting comment related to #3: I read an
article somewhere that said there were several generations of computers:
mainframes, mini's, workstations, PC's. It was claimed that no company
ever spanned one of these generations for fear of cutting into their own
sales. The article was correct for its time (+5 years ago), though I
think a lot of companies have now wised up and are trying... From the
"front lines".... I was hired at Prime in '88 to build their short-lived
MAP product for Generous Motors. After that little fiasco, they let me
loose on the Unix side of the house. It was, to say the least,
frustrating. My background has always been in the "heterogenous"
environment. I was a standard bearer for several of these approaches --
TCP/IP, OSI, Unix -- before it became fashionable, and usually caught
hell for it. *smirk* What I saw was that Prime never really had a good
focus or handle on what it meant to be an Open Systems company. I spent
alot of time talking to senior management at Prime Park about open
systems issues, and, I think, gained the rep of being the "local
fanatic".... and probably a bit of an ass... *smirk* At any rate, rate
not being a factor here, there's the background of my perspective...
Prime was, at its core, a "proprietary" company. And it was *damn* good
for its time and what it did. However, the downfall of most proprietary
companies is NIH -- the "Not Invented Here" syndrome. It's my take that
the whole reason Prime even got involved in Unix was that the
sales/marketing force were hearing this word "Unix" from their customers
and saw it as a "checkoff" item. At least that's how it appeared to be
treated, when the Puzzle Palace's efforts were viewed from the field.
Early on, Prime played, as all the "props" did with "porting" Unix to
its proprietary architecture and platform. There was a stab at it with
Primix. Primix failed miserably because it was, like DEC's Eunice, an OS
on an OS. It was not native to the hardware but ran *on top* of Primos.
You can, of course, see all the fun and problems that entailed. There
was, for a time, an attempt by PP Engineering to create a Unix port that
would run directly on the hardware. It was codenamed "Maori", because
the Program Manager had just returned from a trip to New Zealand and the
port would run in Native mode. I don't recall the project ever getting
"done" enough for us to know whether compliance was going to be a
problem. The contractor, ISC, did have a kernel working pretty well
before the project was canceled for all the usual reasons. Along about
this time, the new buzzwords "Open Systems" started floating around some
of the larger customers (at least in our area) -- Ford, USAI, Marketing
Force... and the natives on both sides of the customer-vendor fence were
getting nervous. PP's execs knew they had to do something, so they
started playing with the idea of a "dual rail" strategy. The idea was to
have two families of platforms, one Primos and one Unix. This would
appease the die-hard Primos customers while tickling the fancy of the
customers caught up in the "revolution". One of the first efforts in
this direction was the development of the EXL300 series (codenamed the
Magnum, if memory serves, because it was supposed to be a "PI" (Prime
Information) platform for Unix). Once again, this was the typical NIH
approach -- create your OWN machine. I actually liked the little
suckers. They were damn well designed from a maintenance standpoint and
actually pretty reliable (my current unanswered NMI Exit problem
notwithstanding). Anyway, as you know, around about this time, the mips
wars started heating up... it became a case of "who has the hottest box
today". And that was almost literally the problem. The little EXLs just
couldn't compete with the MC68010/68020 stuff from Sun, the VAXen
architechtures, the Sequent Symmetry approach, etc. The next logical
choice, therefore, was OEM. Find someone's box and put the Prime label
on it. Although that approach allows you to get a good platform, there
are a lot of problems in terms of marketing relationships (are *you*
selling against the guy you're buying from?), application ports (where
the heck does PI fit into this? how about Medusa?), and a plethora of
other concerns. Prime played around with this idea for a while, going
through several vendors like Sequent, Pyramid, Sun (thanks to CV), and
finally MIPSco. Unfortunately, it was a combined case of "too little too
late" and "split focus". When it came down to brass tacks during the
LeBow affair, Prime needed to consolidate and they retrenched to their
old standby, their proprietary ways, and hunkered down to sell Primos.
That was really the last nail in the coffin. So, to make a long story
short (I know, I know, too late), Prime never had a real commitment, for
a lot of reasons, some of which I've touched on, to get into the Unix
market. They viewed it initially as something they needed to have in a
back-pocket in case a customer asked. And when the fit hit the shan,
they were caught with their drawers down. As you allude to, all the
bouncing around between OEM vendors didn't help the matter. For a while
there it felt like "partner of the week" (anyone remember the MXL, of
which only one, if I recall, was sold?). Customers, especially the big
ones like Ford, didn't like this lack of focus or commitment. And Prime
lost. Reading back, it sounds like I've some bitterness. Not really.
Although there were those of us screaming at Prime to wake up and smell
the coffee (Mike Urich, Skeet Stribling, Renee Mente, come to mind) and
we never seemed to be paid much attention, my days at Prime are some of
my fondest memories. It was a really great place to work, for me. Ah
well, enough nostalgia. I've no doubt muddled some things above, the
mist of my long-dead brain cells making me forget or misremember, and
I'm sure my primate-fiends... er... friends... will correct me. BUt
that's what I remember from those heady days.

        Q) 4.6 Anyone have the Prime yearly financial figures?

There were in the annual reports up until the leveraged buyout. I don't
think the company turns a profit until about 1976, it then does quite
well up until the late 1980's, however a careful review of the finances
revealed some very serious problems. The per centage of revenue that was
derived from service kept going up. The last year before the buyout, I
think service was half of sales. What that really meant was the
installed base was getting very old, since unlike some of their
competitors, the only component in service revenue for Prime was
contract maintenance. If that averaged about 12% per year of the selling
price, what does it tell you about the rate of sales when service is 50%
of sales revenue? It means in an industry with a product life of about 2
years, yours are 4 years old. Not good...

        Q) 4.7 What were Prime offering in 1972?

PR1ME200 PRICELIST Effective Date October 1, 1972 PRIME 200 Fully
Supported Systems PRIME 200 fully supported systems are end-user
oriented. As such, they include a hardware/software package as well as
the following full service items: - System integration and test at the
factory. - Installation at site. Both hardware and software. - On site
demonstration of system operating parameters. - 6 Months warranty on
hardware and software. - Systems reference manual containing system
specific oper- ating instructions, user information, and maintenance
procedures. Type Number: 8000 Prerequisite: None Price: $38,000
Description: High Speed Disk Operating System featuring DOS -200 for
single user interactive program development and execution via highly
reliable and fast fixed head disk mass storage. Complete FORTRAN
capability. Supports PRIME's translators, editors, loaders, and
utilities. System includes compact packaging in a 72" cabinet, power
distribution, cooling, and internal cabling. Requires a single power
source of 60 Hz, II 7 VAC. System con- figuration contains: - PRIME 200
Central Processor Unit with 8 channel programma- ble DMA", 64 level
vectored priority interrupt system, asyn- chronous serial communications
interface, full programmers console. - 16K Words of MOS memory with
battery backup for standby power. - Hardware Multiply and Divide. -
Double Precision Arithmetic. - Automatic Program Load from teletype,
paper tape reader, and disk. - Power Monitor, Power Failure Interrupt,
and Automatic Restart Protection. - Teletype Model 33 ASR and
Controller. - Paper Tape Reader, 200 cps, and Controller. - Paper Tape
Punch, 75 cps, and Controller. - Real Time Clock. - Fixed Head Disk,
256K words, and Controller. - Microdiagnostics. Type Number: 8010
Prerequisite: None Price: $35,000 Description: Removable Media Disk
Operating System featuring DOS-200 for single-user interactive program
development and execution via highly flexible and convenient disk
cartridge type moving head disk subsystem. Complete FORTRAN capability.
Supports PRIME's translators, editors, loaders, and utilities. System
includes com- pact packaging in a 72" cabinet, power distribution,
cooling and internal cabling. Requires a single power source of 60 Hz,
117 VAC. System Configuration contains: - PRIME 200 Central Processor
Unit with 8 channel programmable DMA, 64 level vectored priority
interrupt system, asynchronous serial communications interface, full
programmers console. - 16K Words of MOS memory with battery backup for
standby power. - Automatic Program Load from disk. - Power Monitor,
Power Failure interrupt, and Automatic Restart Protection. - Teletype
Model 33 ASR and Controller. - Paper Tape Reader, 200 cps, and
Controller. - Paper Tape Punch, 75 cps, and Controller. - Real Time
Clock. - Moving Head Disk, 1.5M words, and Controller. All prices
subject to change without notice and are subject to Prime Computer, Inc.
standard terms and conditions. Prime Computer, Inc., 17 Strathmore Road,
Natick, Mass. (617) 655-6999. Prime sales offices: Boston (617)
237-4565, New York (212) 896-6262, Washington D.C. (703) 533-934,3,
Philadelphia (215) 688-0396, Jacksonville (904) 396-5253, Chicago (312)
887-1845, Dayton (513) 435-1343, Detroit (313) 356-4840, Tulsa (918)
663-0518, Palo Alto (415) 968-6003, Los Angeles (213) 881-8433.
Authorized representatives: Phoenix (602) 957-91 10, Albuquerque (505)
255-2330, Denver (303) 771-0140, Seattle (206) 454-9332. For a price
comparison, consider that in 1972: A Ford Thunderbird cost about
$11,000. A five bed room home 2100 sq. ft cost $42,000. That house today
would sell for $250,000.

        Q) 5.1 Nominations: "Most interesting use for a working Prime

Some former Primates write: * My most memorable application was a P400
running a magnetic confinement nuclear fusion experiment at the Los
Alamos National laboratories. Talk about a nasty EMI environment.
Everything was fiber optic, and that was in the late 1970's. The whole
installation was inside a shielded room. It had a great deal of real
time instrumentation, CAMAC I believe. In any event I think it was
decommissioned in that late 1980's. That part of Los Alamos went the VAX
route. Some of the A/D converters were running at 8 million samples per
second even in 1979! Prime had very good hardware for real time, but
they choose not to use it for that. * Back when I was a Primos engineer,
I became involved with some customer having problems with the plotter
support in Primos. It probably was a special. Apparently, the plotter
was used for biorhythms, which along with other stellar predictions, was
the entire business of the company. They even upgraded their processor
at one point, I think, to support their growing load. * Back in
1978-1979, I built a "tactical nuclear wargaming system" on a Prime 300
-- all in R-mode assembly for God's sake -- in Germany for a NATO
application. The thing drove a large 3-color overhead screen which was
quite new in those days and it all ran on power from an army generator
in the snow and mud of Germany. * In late 1984 I worked for Prime (while
a student). Our secretary gave me a call from the US Navy. They wanted
to know how much G-force a 2250 could take a still survive. (We didn't
know.) When asked why they cared, they told me that their intent was to
parachute them out of planes to provide computing when needed in
battlefield situations or remote locations.

        Q) 5.2 Humorous Anecdotes About Prime

A former Primate writes: I noticed your plea for humourous anecdotes
about Prime. While I have a number of funny stories about co-workers, I
can think of only one that relates to Prime as a whole. Sometime during
the late 1980's, those On High at Prime decided to honor a retiring
employee who had served as janitor at the Prime Park facility. This
person had also been employed by the Carling Brewing Company as a
janitor in the same building, prior to its being acquired and renovated
by Prime. If memory serves correctly, he'd spent perhaps 20 years at the
brewery/Prime Park. In honoring the person, Prime crafted a small plaque
that was placed next to the outdoor fountain and waterfall located
between Building 15C (tower) and Lake Cochituate. The fountain had
recently been restored and painted, and the plaque declared the fountain
was dedicated to this individual for his several years of service.
Located near the plaque was a 2X4 plank on which an empty fusebox and
throw switch were mounted. None of the invited press (local newspaper)
or attending local political dignitaries were informed that the fusebox
was not connected. In true Prime marketing fashion, a facilities
employee was stationed behind one of the Building 15C pillars with 2-way
radio in hand, waiting for Joe (he wanted to be called "Joe", not
"Mister Henson") to read the proclamation. A second facilities person
was stationed in the Building 15A basement with another 2-way radio. Joe
declares the fountain blessed and asks the retiring employee to throw
the switch. Hidden facilities employee is heard saying "NOW" into his
2-way. Second facilities employee, 500 feet away, throws the real switch
for the fountain power. Fountain, after a brief delay, comes to life.
Dignitaries applaud and cameras flash. Everyone goes back to work.
Facilities employee is seen yanking the fusebox and switch out of the
dirt and tossing it into a truck. Local geese find a new spot to cool
their collective heels. All involved in this treacherous plot have been
sworn to secrecy and are now employed elsewhere. The fountain, if it has
survived, now belongs to Boston Scientific Company. The fusebox resides
at the Natick landfill. Bomb Squad One London FSE accidentally bought
all the traffic round Lambeth bridge to a halt, and had a Government
building evacuated ... PR1MATES may have seen in one of the newsletters
that FSE's were to start having PR1ME written all over their toolkits.
This was this FSE's fault. She'd parked in our basement, and after
pulling a long, tiring, afternoon replacing some kit, got in the car and
drove off. Leaving her tool kit in the basement ... of course, when the
security guards did their rounds they discovered a large, locked,
unmarked brief-case. The building was evacuated, as the TUC building
next door, and the Tory HQ over the road. The roads round the area were
shut too. Of course, everywhere was re-opened when the nice little
remote controlled robot shot the lock off, and they discovered it full
of tools and PR1ME Field Service guides.
        Q) 5.3 Nominations: "Most anal behaviour by a systems

* Thames Polytechnic, London, England, where they: - Refused to give out
any system manuals - Controlled how much login & CPU time allowed (6
hrs/week for Computer Science students?) - Instituted a per-user logged
out quota which was less than the Primos logged in quota. When you
logged out any excess files were deleted without warning (unless you
typed FINISH as opposed to LOGOUT) - Revoked the MESSAGE command
(thereby creating the Thames Poly Hacker Society rite-of-passage, namely
to write one's own message program using SMSG$) - Had a program which
scanned directories looking for any programs containing Primos
subroutine calls - Had a program which monitored terminal sessions
(ESPY) - Had only UR rights to the top-level directories - Banned people
from writing "front-ends" to Primos to give themselves their own
environment. To be fair, however, it should be noted that some of these
programs grew in complexity to the stage where they rivalled Primos
itself. In mitigation, however, it should be noted that by doing the
above, TP created a generation of fanatical Prime hackers. *
Loughborough University, England: Disallowed creation of subdirectories
* Miscellaneous examples of "madministration": Renaming "futil" to

        Q) 6.1 Where can I get support?

In this section I would like to include details of third party vendors
of software, services and support. Vendors: if you have offerings of
interest to the Prime user community, please let me know, and receive a
free plug! *** UNITED STATES *** CVSI The Official Source of Support -
CVSI (Service International) This is a spin-off company, and is not part
of CV despite the name 100 Crosby Drive Bedford, MA 01730-1480
617-275-2600 PERITUS Peritus Software Services maintain and
bug fix Primos. See: Their web page doesn't have
anything about Prime on it though. FIRST SOLUTIONS 1st Solutions, Inc.
is the primary channel for sales of 50 Series hardware in the US and
Canada for Computervision Corporation. We can provide users with
licensed hardware and software at a very reasonable cost. We have the
ability to help Prime users maximize their 50 Series investment through
upgrading or downgrading, and we have developed a multi-host RAID 7
solution that can run on your Prime and your other cpu platforms
simultaneously. We also sell general purpose terminals and printers,
that work not only on your Prime but on many other types of computers.
Frequently, we have what we call "junk"--you might say, "hey, this is a
pretty good deal". 1st Solutions, Inc. 11460 N. Cave Creek Rd. Phoenix
AZ 85020 Phone: 602-997-0997 Send Email to: SOFTWARE
TECHNOLOGIES GROUP Software Technologies Group, Inc. - The developers of
MAGRST for Unix 1127 S. Mannheim Road Suite 313 Westchester, IL 60154
USA (708) 547-0110 FAX (708) 547-0784 email: BLUFFVIEW BluffView - Prime 50 Series
Computers & Peripherals Used Prime 50 Series Computers & Peripherals.
6000, 4000, 9000, 2000 Series Processors. 5310, 5320, 5340, 5370
Systems. Primos Licensing Available.... WORDMARK WordMark (creators of
Primeword) is alive and well in the UNIX market and focuses in the
MultiValue (Universe/Unidata/Pick) industry. We have converted many
Primes account to Unix and now, NT. WordMark (including Primeword) is
currently supported on Primes as well as just about every type of UNIX
platform. We service many existing Prime installations as well. WordMark
offers other Prime and UNIX products including Email for Prime and UNIX
platforms (intranet) with Internet access from ASCII (dumb) terminals as
well as ISP services. The latest product offering is Liberty ODBC
Drivers and a Prime INFORMATION port is scheduled for April this year.
This is a very unique offering for Prime users to be able to connect
Windows applications such as Word, Excel and Access (clients) to Prime
INFORMATION. Any ODBC compliant Windows application can be connected.
Our contact information is: WordMark Liberty 101 Park Center Plaza,
Suite 1111 San Jose, CA 95113 408-975-1100 800-835-2400 (sales)
408-975-1111 (fax) (Web) (Web) (Web) (email)
(email) Jeff Weidler, WordMark Liberty ( DALLASTONE
Dallastone, Inc. 2 Cote Lane Bedford, NH 03110 603-647-8168 FAX
603-624-2466 Has been selling developing SCSI based solutions for the
Prime market for the eleven years. ComputerVision installation and on
site maint is available if needed. Current products include: Primos/DOS
PCF and PCFX -- hardware and software to share floppy and hard disk
drives between a pc (or pc network) and a Prime Computer. Data can be
exchanged at disk speeds. Primos 7 to 14 gb 8mm tape subsystems 4 to 8
gb 4mm tape subsystems sequential and random jukeboxes for above hard
disk subsytems using state of the art SCSI drives (up to 2.5 gb
capacity. Optical disk subsystems and jukeboxes. Unix Backup and Near
Online Tape software and hardware for most platforms. Tape libraries up
to 2 teribyes and larger Barry Dacks, CDP Product Manager 904-448-0337
COMPUTRONICS Computronics 4N165 Wood Dale Road Addison IL 60101 USA
Email: Voice: (630)941-7767 Fax: (630)941-7714 Web: Contact: Randy Styka They sell a PEEK screen
watching utility, PKZIP for Prime, LPD product to allow Primes to print
on other systems and vice versa and a CPL to Shell Script converter.
PULSAR Pulsar Systems, Inc. Web: A company
specialising in porting Prime applications to Unix *** CANADA ***
Pennant Computer Solutions Limited 115 Woodstream Blvd., Suite 17
Woodbridge, Ontario L4L 8K5 CANADA Tel: 905-851-2271 Fax: 905-851-2272
email: Web: Contact:
Mario Damiano (email: or Gianni De Santis (email: Pennant Computer Solutions Ltd. established in 1991,
currently maintaining almost all Prime sites in Canada. Provides
equipment sales, add-ons, upgrades, and service as well as migration
consulting services. *** GERMANY *** ISC-GbR Hinterhufe 110 D-42929
Wermelskirchen Voice: (+49) 2196-7212-0 Fax : (+49) 2196-7212-16 Contact: Mr. Martin Held ISC-GbR, is the first Address for
Prime 50 Series in central Europe. We supply complete 50 Series
Equipment, Peripherals, add-ons, Upgrades and Maintenance as well. We
also supply Systems and Replacements from HP, IBM, SGI, SUN and CalComp.
*** UNITED KINGDOM *** Andy Milner Milner & Rees 4 Starling Close Pinner
Middlesex HA5 3PH Voice - 0181 868 2800 Fax - 0181 866 7182 Products
include: * MAGRST for UNIX will allow you to transfer your INFORMATION
systems to UNIX and then upload then into universe, unidata etc Products
are for sale on end user licence basis

To top