Comp.Sys.Prime FAQ
PRIME COMPUTER FAQ
Last Updated: 28th August 1999
This FAQ is compiled by Richard Clarke (rich_clarke@hotmail.com)
Further Prime resources can be found at:
http://www.malch.com
comp.sys.prime (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.
CONTENTS
S) 1.0 PRIME HARDWARE
Q) 1.1 How does my xx50 CPU compare to the others?
Q) 1.2 What is my Prime worth?
Q) 1.3 What can I use my 300MB disk drive for?
Q) 1.4 Why was Master Clear under a shield when Power was not?
Q) 1.5 What type of machines did the Specials group produce?
Q) 1.6 Does anyone have the CBL6124 pinout?
Q) 1.7 Wasn't there a Prime Supercomputer once?
Q) 1.8 What are the two phone plugs (T1 & T2) on the PT200 terminal?
Q) 1.9 What is an EXL?
Q) 1.10 Wasn't there a Prime PC once?
S) 2.0 PRIME SOFTWARE
Q) 2.1 What is/happened to Primos?
Q) 2.2 What were the features of the various Primos releases?
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?
Q) 2.5 Why is CMDNC0 called that?
Q) 2.6 How do I emulate Unix "set-uid"?
Q) 2.7 What is/happened to Primix?
Q) 2.8 What do the files in the DIRECV directory do?
Q) 2.9 What's a V-mode .SAVE file?
Q) 2.10 What is a terminfo/termcap entry for a Prime PT200/PT250 terminal?
Q) 2.11 What CAD packages ran on Prime?
Q) 2.12 I heard that Primos had been ported to the ....., what happened?
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!
Q) 2.15 Anyone know about the HERO monitoring package?
Q) 2.16 Problems stopping/restarting printers
Q) 2.17 Prime ASCII <--> Unix ASCII conversion problems
Q) 2.18 R-mode, S-mode, etc: What were they?
Q) 2.19 What's an EPF?
Q) 2.20 Any way to transfer files off a Prime?
Q) 2.21 SCCS Anyone?
Q) 2.22 PKZIP or GZIP for Prime?
Q) 2.23 "Watch" programs, etc.
Q) 2.24 Issues involved porting to Primos
Q) 2.25 What drives does Primos support?
Q) 2.26 How can I print to/from Unix, Novell, VMS or NT using a Prime?
Q) 2.27 Prime Information
Q) 2.28 I miss ED, what can I do?
Q) 2.29 Is there an LPR for the Prime?
Q) 2.30 What is Primeway?
Q) 2.31 Does Primos handle Year 2000 correctly?
Q) 2.32 What do I do with my CPL programs if I move to Unix?
Q) 2.33 Porting INFORMATION to relational databases
Q) 2.34 16 node limit on Prime Gateways
S) 3.0 THE INDEX SOFTWARE
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?
Q) 3.3 What is the difference between SPL and NEW_SPL?
Q) 3.4 What does BUILD do?
S) 4.0 THE PRIME COMPANY
Q) 4.1 How did Prime start?
Q) 4.2 What happened to Prime Computer, Inc?
Q) 4.3 Who were all the people on the front of the Prime manuals?
Q) 4.4 What was the history of Prime?
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?
Q) 4.7 What were Prime offering in 1972?
S) 5.0 THE PRIME TRIVIA CHALLENGE
Q) 5.1 Nominations: "Most interesting use for a working Prime system"
Q) 5.2 Humourous anecdotes about Prime
Q) 5.3 Nominations: "Most anal behaviour by a systems administrator"
S) 6.0 MISCELLANEOUS
Q) 6.1 Where can I get support?
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 Primes...
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 terminal?
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 through.
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
http://www.peritus.com
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 100461?
Because you can't fit
/iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@3,0
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 =.save -dl
Q) 2.10 What is a terminfo/termcap entry for a Prime PT200/PT250 terminal?
#
# P: PRIME
#
pst100|pst-100|pt200|pt-200|pt250|pt-250|Prime PT 200,
:bs:am:cl=\E?:cd=\E[J:ce=\E[m\E[K\E[0t:ch=\E[%i%dG:cm=\E[%i%d;%dH:co#80:\
:ks=\E[>13h:ke=\E[>13l:ti=\E[>13h\E[>11l\E[1N:te=\E[>13l\E[>11h\E[2N\E?:\
:dc=\E[P:dl=\E[M:do=\E[B:ei=:ho=\E$B:ic=\E[@:im=:li#24:up=\E[A:\
:kb=^H:kd=\E[B:kh=\E$A:kl=\E[D:kn=8:kr=\E[C:ku=\E[A:\
:k1=\E0!:k2=\E0":k3=\E0#:k4=\E0$:k5=\E0%:k6=\E0&:k7=\E0':k8=\E0(:\
:l1=F1:l2=F2:l3=F3:l4=F4:l5=F5:l6=F6:l7=F7:l8=F8:vs=\E?\E[24;1H:\
:se=\E[m:so=\E[2;7m:ue=\E[m:us=\E[4m:nd=\E[C:\
:vb=\E$E\200\200\200\200\200\200\200\200\200\200\200\200\200\200\E$P:
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 happened?
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 MAGSAV.
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/primetounix.sh
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 SPOOL* (call it
UNIX.ENV):
ASYNC -LINE 99 -PRO TRAN -XOFF -SPEED 9600
LOG -ON
ATTRIBUTE UNIX -MANDATORY
FORMAT -BM 0 -LM 0 -LENGTH 2000 -RM 0 -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 (cbackham@uk.mdis.com). 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:
ftp.lysator.liu.se:pub/primos/
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
computron.com.
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 Prime?
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 info@computron.com.
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.
http://interociter.cv.com
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 xxx.xxx.xxx.xxx -PORT yyyy
xxx.xxx.xxx.xxx 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, http://www.computron.com 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: info@computron.com.
Web page: http://www.computron.com
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
info@computron.com.
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. (www.vmark.com)
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
************************************************************************
SUBROUTINE FILEDUMP
************************************************************************
* 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( " ", @VM, TRIM( @SENTENCE))
FILENAME = ARGS<1, DCOUNT(ARGS, @VM)>
OPEN "", "VOC" TO VOC ELSE STOP "Unable to open the VOC file"
READ VOCENTRY FROM VOC, FILENAME ELSE STOP "Unable to find ":FILENAME:" in VOC"
OPEN "", "DUMPFILE" TO DUMPFILE ELSE STOP "Unable to open DUMPFILE"
IF VOCENTRY<2> THEN
ENTRYNAME = CONVERT( "/", @VM, VOCENTRY<2> )
ENTRYNAME = ENTRYNAME<1, DCOUNT( ENTRYNAME, @VM)>
READV JUNK FROM DUMPFILE, ENTRYNAME, 0 THEN DELETE DUMPFILE, ENTRYNAME
OPEN "", FILENAME TO DATAFILE THEN
SELECT DATAFILE
READLIST KEYS THEN CONVERT @IM:@FM TO @VM:@VM IN KEYS
CALL *SORT1( KEYS, @VM, "")
OPENSEQ "DUMPFILE", ENTRYNAME TO SEQFILE ELSE
LOOP
REMOVE KEY FROM KEYS SETTING MER
READ DATAREC FROM DATAFILE, KEY THEN WRITESEQ KEY :@IM: DATAREC TO SEQFILE ELSE JUNK = 0
WHILE MER REPEAT
CLOSESEQ SEQFILE
END
CLOSE DATAFILE
END
END
IF VOCENTRY<3> THEN
ENTRYNAME = CONVERT( "/", @VM, VOCENTRY<3> )
ENTRYNAME = ENTRYNAME<1, DCOUNT( ENTRYNAME, @VM)>
READV JUNK FROM DUMPFILE, ENTRYNAME, 0 THEN DELETE DUMPFILE, ENTRYNAME
OPEN "DICT", FILENAME TO DICTFILE THEN
SELECT DICTFILE
READLIST KEYS THEN CONVERT @IM:@FM TO @VM:@VM IN KEYS
CALL *SORT1( KEYS, @VM, "")
OPENSEQ "DUMPFILE", ENTRYNAME TO SEQFILE ELSE
LOOP
REMOVE KEY FROM KEYS SETTING MER
READ DATAREC FROM DICTFILE, KEY THEN WRITESEQ KEY :@IM: DATAREC TO SEQFILE ELSE JUNK = 0
WHILE MER REPEAT
CLOSESEQ SEQFILE
END
CLOSE DICTFILE
END
END
RETURN
END
SORT1.IBAS - does the sort mentioned above.
* sort1 sorts a dynamic array by the requested delimiter
************************************************************************
SUBROUTINE SORT1 (ARRAY, DELIM, SORTTYPE)
************************************************************************
FIELDCOUNT = DCOUNT(ARRAY, DELIM)
IF FIELDCOUNT LT 2 THEN RETURN ;* No point sorting 0 or 1
* Convert dynamic array into matrix
DIMENSION MATRIX(FIELDCOUNT)
MATPARSE MATRIX FROM ARRAY, DELIM
* Set up 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 go by calling SWAP
LOOP UNTIL INTERVAL EQ 0
FOR BUBBLE = INTERVAL+1 TO FIELDCOUNT
SWAPVAR = BUBBLE
GOSUB SWAP:
NEXT
INTERVAL = INT(INTERVAL*0.5)
REPEAT
* Now rebuild dynamic array and return
* MATBUILD ARRAY FROM MATRIX USING DELIM ;* Doesn't work - infobasic bug
MATBUILD ARRAY FROM MATRIX USING @IM
CONVERT @IM TO DELIM IN ARRAY
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
IF COMPVAR LT 1 THEN RETURN
IF LR EQ 'R'
THEN COMPVALUE = COMPARE( MATRIX(SWAPVAR), MATRIX( COMPVAR), "R")
ELSE COMPVALUE = COMPARE( MATRIX(SWAPVAR), MATRIX( COMPVAR), "L")
IF AD EQ "D" THEN COMPVALUE = 0 - COMPVALUE
IF COMPVALUE GE 0 THEN RETURN
TEMP = MATRIX(COMPVAR)
MATRIX(COMPVAR) = MATRIX(SWAPVAR)
MATRIX(SWAPVAR) = TEMP
SWAPVAR = 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
************************************************************************
SUBROUTINE TEXDUMP
************************************************************************
DIMENSION FIELDMAT(1) ;* DUMMY DECLARATION
RESULT = 0 ;* DUMMY DECLARATION
* Command parsing code. Pretty self-explanatory. See SYNTAX: for command syntax
SENTENCE = CONVERT( ' ', @FM, TRIM( @SENTENCE))
REMOVE JUNK FROM SENTENCE SETTING REM ;* command
IF REM EQ 0 THEN MESS = "No arguments to command" ; GOSUB SYNTAX:
REMOVE SOURCEFILE FROM SENTENCE SETTING REM
IF REM EQ 0 THEN GOSUB SYNTAX:
OPEN "", SOURCEFILE TO SOURCE
ELSE MESS = 'Unable to open ':SOURCEFILE ; GOSUB SYNTAX:
OPEN "DICT", SOURCEFILE TO DICT
ELSE MESS = 'Unable to open DICT ':SOURCEFILE ; GOSUB SYNTAX:
REMOVE JUNK FROM SENTENCE SETTING REM
IF REM EQ 0 THEN GOSUB SYNTAX:
IF JUNK NE 'TO' THEN MESS = 'Missing keyword TO' ; GOSUB SYNTAX:
REMOVE TARGET FROM SENTENCE SETTING REM
OPEN "", TARGET TO TARGETFILE THEN
IF REM EQ 0 THEN MESS = 'Target must include a record key' ; GOSUB SYNTAX:
REMOVE TARGETREC FROM SENTENCE SETTING REM
END ELSE
OPEN "", "&HOLD&" TO TARGETFILE ELSE MESS = "Unable to open &HOLD&" ; GOSUB SYNTAX:
TARGETREC = TARGET
TARGET = "&HOLD&"
END
IF REM EQ 0 THEN
* If no optional arguments then go and select everything
GOSUB ALL.FIELDS:
SELECT SOURCE
KEYWORD = "" ;* AVOID UNDECLARED VARIABLE ERROR
END ELSE
* else look at the arguments
REMOVE KEYWORD FROM SENTENCE SETTING REM
BEGIN CASE
CASE KEYWORD EQ 'SELECTING'
* build up 'select' command to select required records
COMMAND = 'SELECT ':SOURCEFILE
LOOP
REMOVE KEYWORD FROM SENTENCE SETTING REM
UNTIL KEYWORD MATCHES "HEADER" :@VM: 'SAVING' :@VM: 'QUOTED' :@VM: 'DELIM' OR REM EQ 0
COMMAND := ' ' : KEYWORD
REPEAT
IF REM EQ 0 THEN
COMMAND := ' ' : KEYWORD
GOSUB ALL.FIELDS:
END
COMMAND := ' COUNT.SUP'
EXECUTE COMMAND
CASE KEYWORD EQ 'SELECT.LIST'
* read pre-existing select list
REMOVE KEYWORD FROM SENTENCE SETTING REM
EXECUTE 'GET.LIST ':KEYWORD
REMOVE KEYWORD FROM SENTENCE SETTING REM
CASE 1
* no selection therefore select everything
SELECT SOURCE
END CASE
END
READLIST KEYLIST
THEN CONVERT @IM TO @FM IN KEYLIST
ELSE MESS = 'No records selected' ; GOSUB SYNTAX:
IF KEYWORD EQ 'SELECTING' THEN REMOVE KEYWORD FROM SENTENCE SETTING REM
IF KEYWORD EQ "HEADER" THEN
PRINT.HEADER = 1
REMOVE KEYWORD FROM SENTENCE SETTING REM
END ELSE PRINT.HEADER = 0
IF KEYWORD NE 'QUOTED' AND KEYWORD NE 'DELIM' AND REM NE 0 THEN
* get list of field-names to save
IF KEYWORD EQ "SAVING"
THEN DICTLIST = ""
ELSE DICTLIST = KEYWORD
LOOP
REMOVE KEYWORD FROM SENTENCE SETTING REM
UNTIL KEYWORD EQ 'QUOTED' OR KEYWORD EQ 'DELIM' OR REM EQ 0
DICTLIST<-1> = KEYWORD
REPEAT
IF REM EQ 0 THEN DICTLIST<-1> = KEYWORD
GOSUB FIELDS:
END
IF KEYWORD EQ 'QUOTED' THEN
QUOTED = 1
REMOVE KEYWORD FROM SENTENCE SETTING REM
END ELSE QUOTED = ""
DELIM1 = "" ; DELIM2 = ""
IF KEYWORD EQ 'DELIM' THEN
* choose field and value delimiters else default to prime standard
IF REM EQ 0 THEN MESS = 'No delimiter supplied' ; GOSUB SYNTAX:
REMOVE DELIM1 FROM SENTENCE SETTING REM
REMOVE DELIM2 FROM SENTENCE SETTING REM
IF REM NE 0 THEN MESS = 'Too many arguments to DELIM' ; GOSUB SYNTAX:
END
IF DELIM1 THEN DELIM1 = DELIM1[1,1] ELSE DELIM1 = '~'
IF DELIM2 THEN DELIM2 = DELIM2[1,1] ELSE DELIM2 = '\}'
IF PRINT.HEADER
THEN OUTPUT = CONVERT( @FM:@VM, ",,", DICTLIST)
ELSE OUTPUT = ""
LOOP
* loop through each record
REMOVE KEY FROM KEYLIST SETTING REM
READ RECORD FROM SOURCE, KEY
ELSE STOP 'Record ':KEY:' disappeared while processing'
* and each field
OUTREC = ""
FOR II = 1 TO FIELDCOUNT
IF FIELDMAT(II)<1>[1,1] EQ 'D' THEN
IF FIELDMAT(II)<2> EQ 0
THEN OUTREC = KEY
ELSE OUTREC = RECORD>
END ELSE
@ID = KEY
@RECORD = RECORD
OUTREC = ITYPE( FIELDMAT(II))
END
* Apply OCONV conversion for output
IF FIELDMAT(II)<3> THEN
CALL !OCONVS( RESULT, OUTREC, FIELDMAT(II)<3>)
OUTREC = RESULT
END
IF QUOTED THEN
IF FIELDMAT(II)<3>[1,2] NE "MD" THEN
IF FIELDMAT(II)<6> NE "M" THEN
OUTREC = '"':OUTREC:'"'
END ELSE
FOR JJ = 1 TO DCOUNT( OUTREC, @VM)
OUTREC = '"':OUTREC:'"'
NEXT
END
END
END
NEXT
CONVERT @FM:@VM TO DELIM1:DELIM2 IN OUTREC
OUTPUT<-1> = OUTREC
WHILE REM REPEAT
WRITE OUTPUT TO TARGETFILE, TARGETREC
RETURN
********************************
* this is a slightly odd routine with two entry-points
ALL.FIELDS:
* select dictionary
DICTLIST = ""
SELECT DICT
READLIST DICT2LIST
THEN CONVERT @IM TO @FM IN DICT2LIST
ELSE STOP 'No fields found in Dictionary'
* and build list from dictionary
LOOP
REMOVE KEY FROM DICT2LIST SETTING DICTREM
READV FIELDPOS FROM DICT, KEY, 2 THEN
IF NUM(FIELDPOS) AND FIELDPOS GT 0 THEN DICTLIST = KEY
END
WHILE DICTREM REPEAT
READV FIELDPOS FROM DICT, "@ID", 2 THEN DICTLIST = "@ID" : @FM : DICTLIST
FIELDS:
* now validate dictionary list
FIELDCOUNT = 0
DIMENSION FIELDMAT( DCOUNT( DICTLIST, @FM))
DICTLIST = DICTLIST
LOOP
REMOVE FIELD FROM DICTLIST SETTING DICTREM
IF FIELD THEN
FIELDCOUNT += 1
READ FIELDMAT( FIELDCOUNT) FROM DICT, FIELD
ELSE STOP 'Field ':FIELD:' not found on dictionary'
END
WHILE DICTREM REPEAT
IF FIELDCOUNT EQ 0 THEN STOP "No fields selected"
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 select.list.name]"
PRINT "[HEADER]"
PRINT "[SAVING] [fields to save]"
PRINT "[QUOTED]"
PRINT "[DELIM field_separator [value_separator]]"
STOP
END
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 front?
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 system"
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 administrator"
* 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 "foodil"
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
www.cvsi.com
PERITUS
Peritus Software Services maintain and bug fix Primos.
See: http://www.peritus.com
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: info@firstsol.com
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: sales@stg.com
http://www.stg.com/magrst
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....
http://rampages.onramp.net/~bview/
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)
multivalue.net (Web)
worprocessing.com (Web)
pcverse.com (Web)
info@multivalue.net (email)
wordmark@netcom.com (email)
Jeff Weidler, WordMark Liberty (weidler@ibm.net)
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: info@computron.com
Voice: (630)941-7767
Fax: (630)941-7714
Web: http://www.computron.com
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: http://www.pulsarsystems.com
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: pennant@netcom.ca
Web: http://www.netcom.ca/~pennant
Contact: Mario Damiano (email: mjdamiano@aol.com)
or
Gianni De Santis (email: giannidesa@aol.com)
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
isc@isca.de
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