  PRIME COMPUTER FAQ 
  ------------------

$PIC 750.bmp
  
  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 <fcntl.h>
>   #include <sgtty.h>
>   #include <stdio.h>
>   #include <string.h>
>   
>   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<nbuf) {
>         cbuf[r]&=0x7f;
>         switch(cbuf[r]) {
>         case 0x0a: wrbuf[w]=0; printf("%s\n",wrbuf); w=0; break;
>         case 0x0d: break;
>         case 0x0c: wrbuf[w]=0; printf("%s%c\n",wrbuf,(char)12); break;
>         default: wrbuf[w++]=cbuf[r];  break;
>         }
>         r++;
>       }
>       fflush(stdout);
>     }
>   }
>   
>   2. WRITER.C
>   -----------
>   
>   #include <fcntl.h>
>   #include <sgtty.h>
>   #include <stdio.h>
>   #include <string.h>
>   
>   #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 <printer>.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<II> = KEY
>                     ELSE OUTREC<II> = RECORD<FIELDMAT(II)<2>>
>               END ELSE
>                  @ID = KEY
>                  @RECORD = RECORD
>                  OUTREC<II> = ITYPE( FIELDMAT(II))
>               END
>   * Apply OCONV conversion for output
>               IF FIELDMAT(II)<3> THEN
>                  CALL !OCONVS( RESULT, OUTREC<II>, FIELDMAT(II)<3>)
>                  OUTREC<II> = RESULT
>               END
>               IF QUOTED THEN
>                  IF FIELDMAT(II)<3>[1,2] NE "MD" THEN
>                     IF FIELDMAT(II)<6> NE "M" THEN
>                        OUTREC<II> = '"':OUTREC<II>:'"'
>                     END ELSE
>                        FOR JJ = 1 TO DCOUNT( OUTREC<II>, @VM)
>                           OUTREC<II,JJ> = '"':OUTREC<II,JJ>:'"'
>                        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<FIELDPOS> = 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
>
