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 > #include > #include > #include > > main(argc, argv) > int argc; > char **argv; > { > int fd; > char portname[100]; > struct sgttyb arg; > > /*** Change serial device in next line ***/ > sprintf(portname, "/dev/tty00"); > if ((fd = open(portname, O_RDWR)) == -1) { > printf("can't open device %s\n", portname); > exit(1); > } > > ioctl(fd, TIOCGETP, &arg); > > arg.sg_ispeed = B9600; > arg.sg_ospeed = B9600; > arg.sg_flags &= ~ECHO; > arg.sg_flags |= RAW; > ioctl(fd, TIOCSETP, &arg); > > process(fd); > > close(fd); > } > > process(fd) > int fd; > { > char cbuf[COMBUFFERSIZE]; > char wrbuf[COMBUFFERSIZE]; > int nbuf; > int r,w; > > w=0; > for(;;) { > nbuf=read(fd, cbuf, COMBUFFERSIZE); > r=0; > while(r 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 > #include > #include > #include > > #define MAX_LINEBUF 128 > #define DIR "/tmp/" /* Change to required directory */ > > main(argc, argv) > int argc; > char **argv; > { > char filename[128]; > char line[MAX_LINEBUF]; > FILE *fp; > enum { idle, nofileyet, noFFyet, receiving } status; > int Stop; > int i; > > fp=0; > status=idle; > for(;;) { > Stop=0; > if (fgets(line,MAX_LINEBUF-1,stdin)!=(char*)0) { > if(strlen(line)>0) { > switch(status) { > case idle: > status=nofileyet; > break; > case nofileyet: > if(strncmp(line,"Pathname:",9)==0) { > i=strlen(line)-1; > while((line[i]!='>')&&(line[i]!=':')) { > if((line[i]>='A')&&(line[i]<='Z')) { > line[i]|=0x20; > } > i--; > } > if(line[i]=='>') { > sprintf(filename, "%s%s", DIR, line+i+1); > } > else { > sprintf(filename,"%sJunk", DIR); > } > for(i=strlen(filename)-1;i>0;i--) { > if((filename[i]!='\n')&&(filename[i]!=' '))break; > filename[i]=0; > } > > if((fp=fopen(filename,"w"))==(FILE*) 0) { > printf("can't open '%s'\n", filename); > fflush(stdout); > } > else { > status=noFFyet; > printf("receiving '%s'\n", filename); > fflush(stdout); > } > } > break; > case noFFyet: > if(line[0]==0x0c) status=receiving; > break; > case receiving: > if(line[0]==0x0c) { > Stop=1; > } > else { > fprintf(fp,"%s",line); > } > break; > } > } > } > if(Stop) { > if(fp) { > fclose(fp); > printf("Just received file %s\n", filename); > fflush(stdout); > } > fp=0; > status=idle; > } > } > } > Now, just compile the two Unix programs: > > cc reader.c -o reader > cc writer.c -o writer > > And run them, together > > reader | writer > > To send a file from the Prime, just do > > SPOOL FILENAME -ATT UNIX > And it will end up in /tmp/filename on the Unix box. You can use wildcards, the writer program extracts the file name from the "Pathname" on the spooler header page. Q) 2.21 SCCS Anyone? What tool did Prime use internally to control their software revisions? I find it hard enough controlling the work of a handful of C++ developers on PCs, the task of co-ordinating development in the UK, US and Australia must have been immense! Yet I never saw any ads for an SCCS-type product for Prime... "It was entirely dependent on the group. Generally, entire copies of the source tree were kept for each version. Careful hand management was done to keep these in sync. It was very primitive." Emacs Group "We had an RCS port, which started seeing some usage. There were a couple of attempts to create a new source control systems on an ad hoc basis (anyone remember psychotic?). RCS came close but was never productized. "The last project I was working on was to be a fancy multi-system configuration manager which would work with multiple source and object pools and provide directory like views. But that was primarily aimed at UNIX, although we hoped to make it work on PRIMOS as well." INFORMATION group, Australia: "Source control for PI in Australia was managed by a program called 'sc' written by Dave Bell. He came from a Unix background so it had all the features of sccs and then some. I think he gave it to the FSF or something as the 'diff' part of it was truly unique - using a technique that the DNA people developed to efficiently compare huge runs of DNA sequence." The PRIMOS group speaks: "The PRIMOS group used an internal source control system written in CPL that managed the integration of source code changes. It was extremely slow, but maintained deltas of all changes to modules, kept track of which engineers "owned" which modules (at each revision), and kept all information about which modules were associated with a given change in a form so that you could go back and see exactly who made a change, who code-reviewed the change, and which modules were affected. "When doing development we typically took a copy of the "checkpoint" directory, which was a complete set of PRIMOS source code, and developed the changes outside of source control. When the project was completed, the changes were merged back in. Getting ownership of all the necessary modules and performing the merge was what took most of the time (although we did have automatic merge tools). "I have used other source control systems since then, and they have all been easier to use in the sense that they allowed you to make a set of changes faster. However, they all lacked the ability to group a set of changes together for the purpose of going back at a later date and seeing what was changed. In general you end up changing each source file separately. I was also surprised by the lack of a "code reviewer" requirement. Systems like RCS, CVS, and Clearcase let you check in whatever changes you want without anyone else putting their name on the line to say that they looked at what you did." "By far the best system I have used is Atria Clearcase. It is slower than normal file system access but it has great functionality." "Other groups in the U.S. typically did not use source control, mostly because most of the other products did not have a lot of people working on them. I'm not sure what was done in the UK and Australia. "Putting together all the pieces of software for a release was a monumental task. It required lots of people, lots and lots of meetings, and lots and lots and lots of testing." Willen Lake R&D, Milton Keynes, England: "At Willen Lake the R&D group used an internally developed tool called CMAN and I thought it was brilliant. I still do. I have yet to see anything else as good as CMAN and I have used a few others including ClearCase. If the author of CMAN can hear me then listen to this: 'port CMAN to Unix and you will be able to retire early!'. "CMAN had the ability to group a set of changes together for the purpose of going back at a later date and seeing what was changed, and is the only tool I know that allows you to do it easily (you can do it in ClearCase after a fashion). CMAN used to call it 'tasks'." Editor's Note - CMAN has been ported to Unix. Contact Clive Backham (cbackham@uk.mdis.com). He writes: "Well, I am one of the authors. We did what you suggested a few years back (ie. re-implemented CMAN on Unix, what's more making a number of improvements on the way). It was called UniCycle, and we lost money. Unfortunately, I still have to work for a living. It was successfully ported to Interactive, SCO, Sun and Encore (Uncle Ken's outfit). If anyone wants to buy the source to UniCycle, I'm sure we can come to some agreement. "I think I can look at it objectively after all this time. UniCycle (nee CMAN) took an unusual approach to configuration management. Its aim was to actively assist the support engineer in getting his day-to-day work done, while handling the source control issues in the background. It had things like impact analysis, task management, propagation of fixes to other revs, etc. This was its great strength. Another bit I was very proud of was the fact that you never needed to write makefiles or build scripts: it could work out how to build systems automatically. Its major weaknesses were: (i) it was a closed (albeit extensible) environment, which meant that you couldn't use your favourite tools such as grep, strings, etc (no big deal on Primos, which had precious few useful tools anyway, but obviously a fatal mistake on Unix); (ii) it only had a curses interface (we never had the resources to do a Motif front end)." Q) 2.22 PKZIP or GZIP for Prime? Was there ever a version/hack of a compression utility like PKZIP or ARCE or some unix compression utility for use on primos? I once ported Gnu GZIP to Prime/PRIMOS. I also submitted my changes to the Gzip author and I think he integrated then into the normal distribution... I also ported Gnu TAR and some other utilities (GREP, UNCOMPRESS) at the same time. Anyway, you should be able to get my port(s) via ftp from: ftp.lysator.liu.se:pub/primos/ Look in the subdirectory "run" for binaries (compiled on a rev 22 machine I think), or if you have a C compiler - then look in the "gnu" subdir for the sources (includes CPL files for compiling them). If gzip gives you the error: > Error: condition "LINKAGE_FAULT$" raised at 4702(3)/22434. > Entry name "G$MEMSET" not found while attempting to resolve > dynamic link from procedure "lm_init" . > ER! > You need LIBRARIES*>ANSI_CC_LIBRARY.RUN installed on your system. This should have been supplied with the Translator package. G$MEMSET is an entrypoint in that library. If you do not have this library, you may need to contact ComputerVision to get it. I don't know if it's part of the basic OS package. We don't have CC on our system, but we do have the library. Go figure. :) Computronics sells a PKZIP compatible product for the 50 series (and for Unix). It uses the same command line syntax and options as PKZIP for DOS and supports all of the same file formats as PKZIP 2.04g. Long filenames are supported, self extracting files, and many other features allowing Primes to interchange files with Unix, Windows NT, and other systems, as well as DOS. For more details, Computronics is at 630/941-7767 or computron.com. Q) 2.23 "Watch" programs, etc. Does anyone remember a program called "watch" which could be used to see exactly what a particular user was doing? There are a couple of versions of a program named PEEK out there that provide that functionality. John Stanley wrote one, Computronics marketed (still market?) one, and I wrote one years ago. What version of PRIMOS are you running? Computronics had versions for just about every release. Mine became obsolete with rev 22 and dynamically allocated ring buffers. Haven't heard from John in years, so don't know status of his. Q) 2.24 Issues involved porting to Primos My impression of software on Prime 50-series systems (primarily from experience with Oracle) is that it only ran well if developed specifically on the platform. Things developed elsewhere never seemed to port well. Is this impression correct? If so why - was it connected to the segmented architecture? And my day was going so well until you had to resurrect the spectre of Oracle on Prime..... :-( SYNCSORT Syncsort actually ran pretty well, despite a voracious appetite for memory. I remember a conversation with Syncsort support folks on behalf of a Major Power Company in Denver, persuading them that such greed was impolite, and others on the system needed resources as well. And, to change the subject completely, let me be the first (for a long time) in this newsgroup to mention Primeway. There. SAS My memories of porting SAS to Primos were that there were several problems: 1. Segments! Wrapping from the top of a segment to the bottom of the segment without any notification whatsoever was unpleasant, to put it mildly. (At one point, after we'd been shrieking at Prime about this, I was told that there were companies who used this "feature" to make segments into ring buffers, so, of course, it couldn't be changed.) There are lots of reasons why segments "wrap". Most of it has to do with 32 bit addresses and 16 bit index registers! This is the most efficient instruction stream that the compilers (V and I mode) would use by default. You had to compile your programs with -BIG in order to get the effects of a linear address space, and then all of your indexes were done with 32-bit pointer arithmetic. Not as efficient, but probably what you wanted. The "ring buffer" feature was probably just one example. The real answer had to do with the history of the architectures: S and R modes were only 16, 32, or 64 K byte address spaces. V mode defined the segmentation and only kept the 16 bit index registers defining "wrap". I mode could have defined 32 index registers, but didn't. IX mode supports GRR, and I think this was the first architecture to allow 32 bit indexing. You can't just change the machine architecture on a "whim". Most of PRIMOS would have stopped working. There was a LOT of system code that depended on segment wrap. 2. 48-bit pointers. Our coding standards required programmers not to assume that a pointer and a long took up the same amount of space, but they did it anyway. Yeup. C programmers. They learn bad habits, and then can't seem to unlearn them. They also think that if the machine isn't byte addressable, that the C language will protect them from it. WRONG! C programmers who think that C is a high level language seem to be the most prone to fall into the "assembly language traps" that other programmers don't. Actually, 48 bit pointers was where Prime considered expanding the address space. Either an expanded segment number, or an extended segment offset could have been put into the 12 unused bits in the 48 pit pointers. Imagine what THAT would have done to code looking at the E bit in the pointer assuming that its presence only indicated a bit-offset instead of extended segment or offset values. Of course having variably sized segments would have been nice. Might even have taken better advantage of the STLBs and pagemaps and such. 3. Float doubles and floating point precision. Two byte exponents might allow you to enumerate all the atoms in the universe, but losing the 8 last bits of precision wasn't desirable. Also, the layout of the float doubles made some SAS operations (we allow users to store float doubles on disk in less than eight bytes) complicated at best. Huh, float doubles have twice the precision of float singles (47 vs 23 bits of mantissa). You were expecting more? I suppose you're thinking about DECs floating point values. They even had an extra bit of precision because floating point values were always normalized, and then the didn't bother to store the first mantissa bit (which was always 1 if it was normalizedm right?) What about QUAD floating point? 128 bits holding 95 bits of precision and a 16 bit exponent. That's more than IEEE gave you in their extended precision (which I think is 80 bits). 4. I/O device separation. We have large chunks of file I/O code which had to handle writing to tapes or disk files or terminals. (No, I don't like T$MT.) I can't argue with you there! I still can't figure out why a consistent I/O device interface was so hard to do right! And that naming convention in the IOCS library: Doesn't everyone know that I$AA12 is the command stream input device, and I$AA01 was only for terminal input? 5. Flaky compilers (especially PL1/G and the early spins of the C compiler -- CI was pretty good), and the amount of time that it took to get bugs fixed in those compilers. We did our best. PL1G, F77, and C all suffered in the beginning because the contractors who provided the compilers all produced code that ran rather than code that performed! It took years to fix that, and most customers STILL aren't running the best compilers (T3.2). Prime bought most of its performance gains in the compilers (C is the notable exception here) through global and peephole optimization techniques. CI did it through a better code generator. It was also part of the driving force behind releasing 32-IX mode (GRR was the other force for F77 as well). CI also benefitted from some specific C stuff being put into IX mode, like C pointers (32 bit pointers with the extension bit being used as a byte offset). 6. SEG, static segments, and shared segments. For us, BIND was a great improvement, especially the ability to dynamically link EPFs. To most of the rest of the world, if you wanted your (large) program to perform, you HAD to use SEG, and know HOW to use it. BIND simplified many things for the general programmer, but not many learned how to use registered EPFs well enough to replace their old shared programs, and people seemed to complain endlessly about long library search rules, and mapped but unused EPFs taking up memory space. EMPIRE The segmented architecture was only part of the problem. More to the forefront was the 16-bit I/O and memory address achitecture. When I ported empire to the 50-series a while ago, I ended up riddling the code with: #ifdef __50SERIES__ #endif mostly to handle the memory addressing problems associated with the 50 series. Extra i++ everwhere because of the holes being added to structures to align characters. The C library is VERY complicated handling 8 bit I/O on top of a 16 bit I/O system. NL on the Prime is either a LF or a LF followed by a NULL character (16 bit pad). A lot of these problems were hidden in the C library, but if the user tried to port code which assumed things, it usually didn't work. That was Oracle's problem. Their code assumed every system they would run on was a "normal" byte-addressable system with 8 bit I/O. Q) 2.25 What drives does Primos support? This table was cribbed from the 23.4 README file > > The FIX_DISK command and the -DISK_TYPE options of the MAKE command > both accept these new drives. The following is a list of acceptable > disk types for these commands: > > Disk Type Description > > CMD Cartridge module device > SMD 80MB or 300MB removable SMD > 68MB 68MB fixed media > 158MB 158MB fixed media > 160MB 160MB fixed media > 600MB 600MB fixed media SMD > MODEL_4475 300MB fixed media SMD > MODEL_4711 60MB fixed media > MODEL_4714 84MB fixed media > MODEL_4715 120MB fixed media > MODEL_4719 258MB fixed media > MODEL_4721 328MB fixed media SCSI > MODEL_4729 673MB fixed media > MODEL_4730 213MB fixed media SCSI > MODEL_4731 421MB fixed media > MODEL_4732 1.34GB fixed media SCSI > MODEL_4734 1.0GB fixed media SCSI > MODEL_4735 496MB fixed media SMD > MODEL_4736 2.0GB fixed media SCSI > MODEL_4845 770MB fixed media SMD > MODEL_4860 817MB fixed media SMD > Q) 2.26 How can I print to/from Unix, Novell, VMS or NT using a Prime? I have a Prime 5370 running primos rev24.00 and TCP/IP rev 3 and a network of fifty PCs all with WFW3.11 and TCP/IP as well. I want to be able to spool from the Prime to a network printer. I have found LPR clients for the network, but can't find lpd daemon for the Prime, anyone have any ideas of an inexpensive way to do this. Computronics sells a product called LPR that allows the standard rev 22 or later Prime spooler to print to any LPD compatible printer. This operation is transparent to the user and one despooler can service more than one printer. The LPR software also supports Unix like "lpr" and "lpq" commands. The "lpq" command can be used to display the queue status of queues on other systems from a user that is on the Prime system. LPD also allows any system that supports the LPD protocol to print to printers on the Prime. No special spooler is required on the Prime. Even non-standard spoolers such as third party spoolers or Rev 19 style spoolers can be used to print from other systems on to the Prime. For more details, Computronics is at info@computron.com. Q) 2.27 Prime Information Prime Information - PI - was a very successful database product which ran on 50 series. In 1986, in the City of London office, when Info 7.0 had just came out, we were beseiged by software houses with financial applications written in Information -Ed. The origins of Prime Information came from the desire to offer a growth path to Microdata users. Microdata had the Pick system on its 16 bit systems and established a vertical market dealer organization. It was very late in developing a 32bit system, and the dealers became very frustrated. A company was formed to develop a compatible implementation on Prime 32 bit systems, with firmware support (e.g., I450) provided by Prime for higher performance. Prime bought out the company in the mid 80's. PI was licenced in (like Medusa). And, like Medusa, the initial deal didn't cover Europe. It went like gangbusters in the US and Australia and when Prime secured European marketing rights, the first two launches in the UK were really bad flops. It went nowhere until the third launch in around 1985. Then it really took off. PI has its routes in the Pick system developed by Dick Pick. It kinda got pushed aside by all the hype over the relational model and SQL. But, it had some real strengths. Prime's implemention was really excellent. It tied into Primenet and was the only implementation of Pick to support X.25. We really stressed this at the (third) product launch. There was a big conference at the Penta Hotel (or whatever that ugly hotel next to London Heathrow is called these days). The theme was: Pick networks ........ Pick Prime Information. Terrible pun but, I still love it :-) At the tradeshow we had a dial-up Primenet link into the Corporate network and we'd remote login to systems in Prime Park and Australia. It blew peoples socks off. We had to show them the date/time on the remote ssystems before they'd believe it was for real. Was PI licenced from Dick Pick corp? No. It was a clone thing. I remember we had to be very careful about the positioning. We couldn't claim that Prime Information was Pick. We had to say "Pick-like". However, I think that Prime may have done a deal with Dick Pick some years later. The Pick story is a long saga of licencing deals, disputes and acquisitions. What about portability? Whilst Prime was still in existance we ported Information to UNIX and called it PI/Open. This was/is available on the major UNIX platforms (IBM, DG, Digital, HP, etc). Our aim in this development was to get as closed as possible to 100% compatibility between source AND BINARY code from Information. E.g. You could take the binary code of an Info/BASIC program and execute it on PI/open without any problems. We came pretty close to achieving this. With the demise of PRIME, VMARK Software purchased PI/Open along with a number of the engineers working on it. VMARK still markets PI/open. As of release 8, UniVerse (VMARK's original 'Pick like' system) was enhanced in a number of ways to make it more compatible with PI/open, and hence Information. So Information code should be portable with not too much change to UniVerse. And not forgetting the opposition... there are other 'pick style' vendors who can support Information code with varying degrees of porting required. Q) 2.28 I miss ED, what can I do? Take a look at Greg Field's Web Page. Greg works for CV service in Australia, and my guess is he may have worked for Prime at some time. > > http://interociter.cv.com > Q) 2.29 Is there an LPR for the Prime? If Prime means Primos, and you have tcp/ip you can do this: In the .env file put this line in instead of the async line > > TCP/IP -ADDRESS xxx.xxx.xxx.xxx -PORT yyyy > xxx.xxx.xxx.xxx is the printer's IP addr, yyyy is the port number. If you don't know try 515 (lp) or 9100 (hp) or maybee 23 (telnet) I have tested it with TCP/IP Version 2.4.r26 and a HP LaserJet 4M with a jetdirect netcard. I don't use it in production because Primos' TCP/IP cannot deal with it, when the printer is in use. Q) 2.30 What is Primeway? Primeway was an interesting beast. It was a transaction processing system composed of two parts - the Development Environment, which integrated source code management (COBOL), Forms development (using FED) and database access (DBMS and soon after, PRISAM), and allowed multiple developers to work on what were called 'configurations' - essentially an application - and the Business Environment, which managed the runtime side, multiplexing a large number of users into a much smaller number of 'work processes' (phantoms) which handled terminal interaction (all block mode), and transaction management. It was really very sophisticated for its time - rumoured to have more lines of code than Primos - and a complete flop in the marketplace. If it found its way into 12 customers' hands, I'd be surprised. It was a hard sell - Prime sales folks in those days were used to being able to sell iron as fast as it could be made, and to go into a prospective customer with a monster like Primeway was an unwelcome change of pace. Those who did use it (at least for a while) were Prime's own Customer Service Center in Natick, where I worked for a while. Prime also ran part of its business on it as well, but I don't remember what. The US Army was probably the biggest customer, and the one I spent the most time looking after, as the resident expert - they built a *huge* system to do all their recruiting on, with the intent to deploy it to all the recruiting offices around the US. Distributed-almost-client-server-stuff, in 1985! I'm not sure how much of it ever got rolled out - they were setting up the regions when I left Prime in 1989. Later versions of Primeway had Oracle support, along with Priforma, a JYACC-based forms tool, but by then it was way too late. Q) 2.31 Does Primos handle Year 2000 correctly? Year 2000 has been a critical issue for a number of sites. Below is a variety of Prime Year 2000 information. This same information is available in HTML format if you visit our web site, http://www.computron.com and follow the Prime Year 2000 link. PRIMOS and Year 2000 Computronics has had many calls the past several months from Prime 50 series users, asking about PRIMOS compat- ibility and the year 2000. We have completed a detailed study of this matter, and have a lot of news... The Issue: The big question: "Will PRIMOS work properly with dates after 31 December 1999"? The answer: With your current revision of PRIMOS, as it stands, no. But there's a solution! The good news: Computronics has put together a "Year 2000 tool kit" of utilities and patches that will enable a wide variety of PRIMOS revisions to work properly in the year 2000 time period. We have been studying this matter for months and have found the issues and come up with ways to work around them. So you _won't_ need to pull the plug on the Prime when the date rolls over to 2000. More on this later... What will happen if you do nothing at all? Two sets of problems come up. First of all, most versions of PRIMOS will roll the date over from 31 December 1999 to 01 January 2000 properly. Some older versions roll over to a date of "01/01/00", which is right, but some utilities display this date wrong, perhaps as a date like "January 1, 19100". But this is not true in all utilities nor in as many places in more recent versions of PRIMOS. Such problems vary a great deal by revision. Then a number of things start to break. The spooler prints incorrect dates, as do various other utilities. DSM stops working. The second issue, which can be even more serious, is that the VCP clock information is not sent properly to the system when booting, and virtually all version of PRIMOS will take a VCP date of "01/01/00" and set the date in PRIMOS itself to "01/02/28". This will happen again on each reboot. So even with a properly set VCP clock, the PRIMOS date will be wrong. Solutions: Now for the big question. What do you do about these problems? One option is to upgrade to a later version of PRIMOS. ComputerVision Services has announced two special patch releases of PRIMOS for revision 23.4 and 24.0. Many Prime users have contacted Computronics and expressed concern with this option. For people not on CVSI maintenance, upgrade price may be a question. But for all users, there are always concerns about the impact of a PRIMOS upgrade. Some sites are on older revisions, such as 22.1 or 23.2 because of variety of reasons: Perhaps they are running applications that were never migrated or tested at later releases of PRIMOS. In some cases, the applications or other subsystems were written by companies that are out of business or individuals that are no longer available. Some sites have smaller systems and don't want to run a later version of PRIMOS due to the performance impact on their system. In add- ition to these reasons, some sites that are already on release 23.4 or 24.0 do not have the resources to deal with a PRIMOS change; the people who "knew the Prime" just aren't around any more. (Or if they are still around, their memory isn't what it used to be ;-) So, what is the alternative? Computronics is pleased to announce the "Year 2000 Toolkit for Prime Systems". This is a set of libraries and patches that will resolve or work around the problems that have been found in various revisions of PRIMOS. These patches will solve the bulk of the problems, including serious ones such as the VCP clock problem mentioned above. It does this by actually patching your current version of PRIMOS, so you are not upgrading PRIMOS! Fixes are even available for older programs, such as the pre-revision 21 spooler! Application Issues: What things are not fixed? YOUR APPLICATIONS! If you have not resolved applications issues, this toolkit is NOT going to help you. You will need to make sure that all of your applications utilize a four digit year, or that they do date comparisons properly if you will be using two digit years. That is, if you are going to continue to use a two digit year, your applications will need to be designed so that they know that 12/31/99 is less than 01/01/00. The Computronics toolkit can help with testing your applications! The toolkit includes a mode that you can set for selected users to enable them to execute programs with a different date than the system date. Thus from that user's point of view the date is now a new date that you specify. For your testing purposes, keep in mind that there are a number of considerations in doing this on a production system, as you will have other programs using the correct date, and so potentially you will have mixed dates in files. Thus the testing can itself cause problems in some applications; just make sure you are using test files and copies of databases before undergoing such tests. (This is a concern for anyone performing year 2000 testing, on any system). What is Supported by the Toolkit?: What PRIMOS revisions are supported by the Year 2000 Toolkit? Revision 20.2, 21.0, 22.1, 23.2, 23.3, 23.4 and 24.0, as well as the various "dot" releases. You tell Computronics your exact version number and a they will ship you a toolkit tailored for that exact version. There are _no_ plans to support very old revisions such as revision 19 or 20.0; such changes are feasible, but we do not think there is enough demand to warrant the additional work. Will _everything_ be fixed? Again, you will need to deal with application issues. Also, the toolkit is designed to fix the bigger problems, and not every possible issue, particularly at older versions of PRIMOS. The problems that are not addressed will be of a cosmetic nature, in the way some utilities display dates. They will not be issues that impact the system in a serious way. Can I try the Toolkit? Sure! You don't have to take Computronics word that it works. Computronics will offer a single 30 day trial to any prospective customer. The 30 days begins when you install the toolkit. This will enable you to give it a test drive in advance of the magic 1 January 2000 date so that you can see how it works for yourself! And remember, no hardware changes, no new PRIMOS revisions to install, no "Hardware Audit" to be done! Price and Warranty: What will the toolkit cost? Pricing varies, in a range of US$1500 to US$5000 for a single system license. This price will depend on the cpu model that you are using, and the revision of PRIMOS that you are running. The licensing is "tied" to a specific cpu, but multiple cpu discounts are available. Please contact Computronics with your CPU model and PRIMOS revision. All prices will be in the range shown above. Is there a warranty? Computronics warrants that the Year 2000 Toolkit will fix the PRIMOS related date issues, and also Computronics will work with you to resolve anything that might have been missed. But Computronics can't guarantee that every last problem in every last routine has been fixed. And so the warranty for the Toolkit is limited to Computronics fixing any problems with the Toolkit or you will get your money back. No consequential damages and all of that stuff; you know the fine print... And, once again, YOU will need to look at any year 2000 impacts in your applications. Other Products: What about related products? Computronics is ready to work with you to discuss other issues. Certain commonly used products have already been evaluated for year 2000 issues. One of these products is Prime/Information. PI will _not_ work properly after the year 2000. In fact, the DATE() function returns a negative number for the internal date that corresponds to 1 January 1900. The DATE command displays the year as 1900, as does the TIMEDATE() function. There is good news for users of Prime/Information, however. The Vmark (now known as Ardent) Corporation that maintains Prime/Information has produced patches for most commonly used versions of Prime/Information, including these special releases: 8.4.r4, 8.1.4.r12, 8.0.r26, and 7.0.4.r3. What about users of Henco's INFO database? Again, there is good news. Computronics has run a series of tests on a system running the Year 2000 Toolkit and the Henco INFO programs ran just fine, treating all years as four digits and handling a year of 2000 properly. What about other programs and products? Computronics is not in a position to test every piece of software out there, and certainly not your applications. But consulting services are available to run tests with you, to run tests on Computronics' system, or just to work with you as this critical year 2000 time approaches. What about Computronics Products?: Who is Computronics? Well, one of the most popular software products ever written for Prime 50-series systems is PEEK, written, sold and maintained by Computronics. Another popular product is LPR, to enable the Prime to use TCP/IP based printing to Unix or NT hosts. LPD to enable the Prime to _be_ an LPD compliant print server. Zip for PRIMOS to enable Prime 50-series systems to create and work with pkzip compatible archives. And there are other products including Log-Time for system resource accounting, Usage Accounting, Network, the HP Laserjet printer driver, various FORMS drivers. Since 1993 Computronics has developed many Unix products, such as Peek for Unix and ZIP for Unix. All Computronics utilities mentioned in this section are year 2000 compliant. If you are under maintenance for these products, new year 2000 compatible releases are avail- able for these products at no charge. If you are not under maintenance, appropriate releases will be available at special prices. Call Computronics for details. As so many of the Prime users have new personnel that may not be real familiar with the software on their systems, below is a list of all Computronics product names so that you can determine if you are running any of these products: PEEK, AMLC Status, CPL To Shell Convertor, Log-Time, Login Security Trail, Network, Password Expiration, PrintMaster, Remote Print Handler, SoftWire, Status Line Message, Usage Accounting, ZIP, Printer Drivers for HP Laserjet and others, LPR, LPD, SNA, DPTX, and FORMS terminal drivers... If you believe you may be running any of these products, contact the people at Computronics for details about Year 2000 versions of the products. How to Get The Toolkit: Contact Computronics for information on the "Year 2000 Toolkit for Prime Systems". You should know your PRIMOS revision and CPU model before calling. Use the commands "status system" and "status hdwr" to get these items of information. Computronics is at 4N165 Wood Dale Road, Addison, Illinois 60101. Telephone: 630/941-7767. Fax: 630/941-7714. Email: info@computron.com. Web page: http://www.computron.com Q) 2.32 What do I do with my CPL programs if I move to Unix? Computronics sells a CPL converter that will take your CPL programs and turn them into Unix shell scripts. Some manual changes may be needed, but 95% of what is in a CPL is translated and there is no need for any run-time library or Prime emulation software on the Unix side. For more details, Computronics is at 630/941-7767 or info@computron.com. Q) 2.33 Porting INFORMATION to relational databases What with the Year 2000 problem and the increasing age of installed Prime kit, a lot of people are looking at migrating their INFORMATION applications on to other platforms. After all, when you look at it, the old hardware is practically worthless but in contrast the value locked up in the data and applications residing on it may be almost incalculable. A useful port of call may be VMark systems who I believe own the rights to the INFORMATION product and its descendants. (www.vmark.com) INFORMATION is a Pick-like database system. It is not relational. This means you can have things like multiple-valued fields. Because it is not relational it may require some work to map an INFORMATION database onto a relational database such as Access, MS SQL Server or Oracle. The good news is, however, that as far as I know, if you have an INFORMATION-based application running on your Prime, you also have access to the development environment and can write your own INFO/BASIC programs to assist in dumping out the data. Here are a few examples to get you started. FILEDUMP.IBAS - Just dumps the entire file. Because it sorts it by key it has been known to fall over on a very big file, but you can just comment out the sort line. > * FILEDUMP - Dumps a file in ASCII for archiving > ************************************************************************ > > SUBROUTINE FILEDUMP > > ************************************************************************ > > * This routine is passed a filename on the command line (it assumes the > * last element is the filename to process). It then reads the VOC entry > * for the data and dictionary files, and strips the last element off. > * This is then used as the record key for a record in the type 1 file > * DUMPFILE. The data or dict file is selected by id, each record read > * in turn, and the contents dumped into the DUMPFILE record as a line > * with the format "key" "item-mark" "data". > * These can then be written to CD for recovery if/when we ever need the > * data again. > > ARGS = CONVERT( " ", @VM, TRIM( @SENTENCE)) > FILENAME = ARGS<1, DCOUNT(ARGS, @VM)> > > OPEN "", "VOC" TO VOC ELSE STOP "Unable to open the VOC file" > > READ VOCENTRY FROM VOC, FILENAME ELSE STOP "Unable to find ":FILENAME:" in VOC" > > OPEN "", "DUMPFILE" TO DUMPFILE ELSE STOP "Unable to open DUMPFILE" > > IF VOCENTRY<2> THEN > ENTRYNAME = CONVERT( "/", @VM, VOCENTRY<2> ) > ENTRYNAME = ENTRYNAME<1, DCOUNT( ENTRYNAME, @VM)> > READV JUNK FROM DUMPFILE, ENTRYNAME, 0 THEN DELETE DUMPFILE, ENTRYNAME > OPEN "", FILENAME TO DATAFILE THEN > SELECT DATAFILE > READLIST KEYS THEN CONVERT @IM:@FM TO @VM:@VM IN KEYS > CALL *SORT1( KEYS, @VM, "") > > OPENSEQ "DUMPFILE", ENTRYNAME TO SEQFILE ELSE > LOOP > REMOVE KEY FROM KEYS SETTING MER > READ DATAREC FROM DATAFILE, KEY THEN WRITESEQ KEY :@IM: DATAREC TO SEQFILE ELSE JUNK = 0 > WHILE MER REPEAT > CLOSESEQ SEQFILE > END > > CLOSE DATAFILE > END > END > > IF VOCENTRY<3> THEN > ENTRYNAME = CONVERT( "/", @VM, VOCENTRY<3> ) > ENTRYNAME = ENTRYNAME<1, DCOUNT( ENTRYNAME, @VM)> > READV JUNK FROM DUMPFILE, ENTRYNAME, 0 THEN DELETE DUMPFILE, ENTRYNAME > OPEN "DICT", FILENAME TO DICTFILE THEN > SELECT DICTFILE > READLIST KEYS THEN CONVERT @IM:@FM TO @VM:@VM IN KEYS > CALL *SORT1( KEYS, @VM, "") > > OPENSEQ "DUMPFILE", ENTRYNAME TO SEQFILE ELSE > LOOP > REMOVE KEY FROM KEYS SETTING MER > READ DATAREC FROM DICTFILE, KEY THEN WRITESEQ KEY :@IM: DATAREC TO SEQFILE ELSE JUNK = 0 > WHILE MER REPEAT > CLOSESEQ SEQFILE > END > > CLOSE DICTFILE > END > END > > RETURN > END > > SORT1.IBAS - does the sort mentioned above. > > * sort1 sorts a dynamic array by the requested delimiter > ************************************************************************ > > SUBROUTINE SORT1 (ARRAY, DELIM, SORTTYPE) > > ************************************************************************ > > > FIELDCOUNT = DCOUNT(ARRAY, DELIM) > IF FIELDCOUNT LT 2 THEN RETURN ;* No point sorting 0 or 1 > > * Convert dynamic array into matrix > DIMENSION MATRIX(FIELDCOUNT) > MATPARSE MATRIX FROM ARRAY, DELIM > > * Set up ascend/descent, justify, and start interval > AD = SORTTYPE[1,1] > LR = SORTTYPE[2,1] > INTERVAL = INT(FIELDCOUNT*0.5) > > * Now to business - the outer LOOP continues until the swap interval > * has been through 1 to become zero. The inner FOR 'bubbles' each entry > * up as far as it will go by calling SWAP > LOOP UNTIL INTERVAL EQ 0 > FOR BUBBLE = INTERVAL+1 TO FIELDCOUNT > SWAPVAR = BUBBLE > GOSUB SWAP: > NEXT > INTERVAL = INT(INTERVAL*0.5) > REPEAT > > * Now rebuild dynamic array and return > * MATBUILD ARRAY FROM MATRIX USING DELIM ;* Doesn't work - infobasic bug > MATBUILD ARRAY FROM MATRIX USING @IM > CONVERT @IM TO DELIM IN ARRAY > RETURN > > ******************************** > * This simply compares the current entry with the entry INTERVAL before. > * If it is in the correct order, or the current entry is too close to the > * top it returns. Otherwise it swaps the two entries, and loops to see if > * it can move the current entry even higher. > SWAP: > LOOP > COMPVAR = SWAPVAR - INTERVAL > IF COMPVAR LT 1 THEN RETURN > > IF LR EQ 'R' > THEN COMPVALUE = COMPARE( MATRIX(SWAPVAR), MATRIX( COMPVAR), "R") > ELSE COMPVALUE = COMPARE( MATRIX(SWAPVAR), MATRIX( COMPVAR), "L") > IF AD EQ "D" THEN COMPVALUE = 0 - COMPVALUE > > IF COMPVALUE GE 0 THEN RETURN > > TEMP = MATRIX(COMPVAR) > MATRIX(COMPVAR) = MATRIX(SWAPVAR) > MATRIX(SWAPVAR) = TEMP > SWAPVAR = COMPVAR > > REPEAT > END > > TEXDUMP.IBAS - a rather more sophisticated file dump routine, driven by the command line. It's got the syntax in it at the bottom. > > > * TEXDUMP - dumps fields from a file in ascii > ************************************************************************ > > SUBROUTINE TEXDUMP > > ************************************************************************ > > DIMENSION FIELDMAT(1) ;* DUMMY DECLARATION > RESULT = 0 ;* DUMMY DECLARATION > > * Command parsing code. Pretty self-explanatory. See SYNTAX: for command syntax > SENTENCE = CONVERT( ' ', @FM, TRIM( @SENTENCE)) > > REMOVE JUNK FROM SENTENCE SETTING REM ;* command > IF REM EQ 0 THEN MESS = "No arguments to command" ; GOSUB SYNTAX: > > REMOVE SOURCEFILE FROM SENTENCE SETTING REM > IF REM EQ 0 THEN GOSUB SYNTAX: > OPEN "", SOURCEFILE TO SOURCE > ELSE MESS = 'Unable to open ':SOURCEFILE ; GOSUB SYNTAX: > OPEN "DICT", SOURCEFILE TO DICT > ELSE MESS = 'Unable to open DICT ':SOURCEFILE ; GOSUB SYNTAX: > > REMOVE JUNK FROM SENTENCE SETTING REM > IF REM EQ 0 THEN GOSUB SYNTAX: > IF JUNK NE 'TO' THEN MESS = 'Missing keyword TO' ; GOSUB SYNTAX: > > REMOVE TARGET FROM SENTENCE SETTING REM > OPEN "", TARGET TO TARGETFILE THEN > IF REM EQ 0 THEN MESS = 'Target must include a record key' ; GOSUB SYNTAX: > REMOVE TARGETREC FROM SENTENCE SETTING REM > END ELSE > OPEN "", "&HOLD&" TO TARGETFILE ELSE MESS = "Unable to open &HOLD&" ; GOSUB SYNTAX: > TARGETREC = TARGET > TARGET = "&HOLD&" > END > > IF REM EQ 0 THEN > * If no optional arguments then go and select everything > GOSUB ALL.FIELDS: > SELECT SOURCE > KEYWORD = "" ;* AVOID UNDECLARED VARIABLE ERROR > END ELSE > > * else look at the arguments > REMOVE KEYWORD FROM SENTENCE SETTING REM > > BEGIN CASE > CASE KEYWORD EQ 'SELECTING' > * build up 'select' command to select required records > COMMAND = 'SELECT ':SOURCEFILE > LOOP > REMOVE KEYWORD FROM SENTENCE SETTING REM > UNTIL KEYWORD MATCHES "HEADER" :@VM: 'SAVING' :@VM: 'QUOTED' :@VM: 'DELIM' OR REM EQ 0 > COMMAND := ' ' : KEYWORD > REPEAT > IF REM EQ 0 THEN > COMMAND := ' ' : KEYWORD > GOSUB ALL.FIELDS: > END > COMMAND := ' COUNT.SUP' > EXECUTE COMMAND > CASE KEYWORD EQ 'SELECT.LIST' > * read pre-existing select list > REMOVE KEYWORD FROM SENTENCE SETTING REM > EXECUTE 'GET.LIST ':KEYWORD > REMOVE KEYWORD FROM SENTENCE SETTING REM > CASE 1 > * no selection therefore select everything > SELECT SOURCE > END CASE > END > > READLIST KEYLIST > THEN CONVERT @IM TO @FM IN KEYLIST > ELSE MESS = 'No records selected' ; GOSUB SYNTAX: > > IF KEYWORD EQ 'SELECTING' THEN REMOVE KEYWORD FROM SENTENCE SETTING REM > > IF KEYWORD EQ "HEADER" THEN > PRINT.HEADER = 1 > REMOVE KEYWORD FROM SENTENCE SETTING REM > END ELSE PRINT.HEADER = 0 > > IF KEYWORD NE 'QUOTED' AND KEYWORD NE 'DELIM' AND REM NE 0 THEN > * get list of field-names to save > IF KEYWORD EQ "SAVING" > THEN DICTLIST = "" > ELSE DICTLIST = KEYWORD > LOOP > REMOVE KEYWORD FROM SENTENCE SETTING REM > UNTIL KEYWORD EQ 'QUOTED' OR KEYWORD EQ 'DELIM' OR REM EQ 0 > DICTLIST<-1> = KEYWORD > REPEAT > IF REM EQ 0 THEN DICTLIST<-1> = KEYWORD > GOSUB FIELDS: > END > > IF KEYWORD EQ 'QUOTED' THEN > QUOTED = 1 > REMOVE KEYWORD FROM SENTENCE SETTING REM > END ELSE QUOTED = "" > > DELIM1 = "" ; DELIM2 = "" > > IF KEYWORD EQ 'DELIM' THEN > * choose field and value delimiters else default to prime standard > IF REM EQ 0 THEN MESS = 'No delimiter supplied' ; GOSUB SYNTAX: > REMOVE DELIM1 FROM SENTENCE SETTING REM > REMOVE DELIM2 FROM SENTENCE SETTING REM > IF REM NE 0 THEN MESS = 'Too many arguments to DELIM' ; GOSUB SYNTAX: > END > IF DELIM1 THEN DELIM1 = DELIM1[1,1] ELSE DELIM1 = '~' > IF DELIM2 THEN DELIM2 = DELIM2[1,1] ELSE DELIM2 = '}' > > IF PRINT.HEADER > THEN OUTPUT = CONVERT( @FM:@VM, ",,", DICTLIST) > ELSE OUTPUT = "" > > LOOP > > * loop through each record > REMOVE KEY FROM KEYLIST SETTING REM > READ RECORD FROM SOURCE, KEY > ELSE STOP 'Record ':KEY:' disappeared while processing' > > * and each field > OUTREC = "" > FOR II = 1 TO FIELDCOUNT > IF FIELDMAT(II)<1>[1,1] EQ 'D' THEN > IF FIELDMAT(II)<2> EQ 0 > THEN OUTREC = KEY > ELSE OUTREC = RECORD> > END ELSE > @ID = KEY > @RECORD = RECORD > OUTREC = ITYPE( FIELDMAT(II)) > END > * Apply OCONV conversion for output > IF FIELDMAT(II)<3> THEN > CALL !OCONVS( RESULT, OUTREC, FIELDMAT(II)<3>) > OUTREC = RESULT > END > IF QUOTED THEN > IF FIELDMAT(II)<3>[1,2] NE "MD" THEN > IF FIELDMAT(II)<6> NE "M" THEN > OUTREC = '"':OUTREC:'"' > END ELSE > FOR JJ = 1 TO DCOUNT( OUTREC, @VM) > OUTREC = '"':OUTREC:'"' > NEXT > END > END > END > NEXT > > CONVERT @FM:@VM TO DELIM1:DELIM2 IN OUTREC > OUTPUT<-1> = OUTREC > > WHILE REM REPEAT > > WRITE OUTPUT TO TARGETFILE, TARGETREC > RETURN > > ******************************** > * this is a slightly odd routine with two entry-points > ALL.FIELDS: > > * select dictionary > DICTLIST = "" > SELECT DICT > READLIST DICT2LIST > THEN CONVERT @IM TO @FM IN DICT2LIST > ELSE STOP 'No fields found in Dictionary' > > * and build list from dictionary > LOOP > REMOVE KEY FROM DICT2LIST SETTING DICTREM > READV FIELDPOS FROM DICT, KEY, 2 THEN > IF NUM(FIELDPOS) AND FIELDPOS GT 0 THEN DICTLIST = KEY > END > WHILE DICTREM REPEAT > READV FIELDPOS FROM DICT, "@ID", 2 THEN DICTLIST = "@ID" : @FM : DICTLIST > > FIELDS: > > * now validate dictionary list > FIELDCOUNT = 0 > DIMENSION FIELDMAT( DCOUNT( DICTLIST, @FM)) > DICTLIST = DICTLIST > LOOP > REMOVE FIELD FROM DICTLIST SETTING DICTREM > IF FIELD THEN > FIELDCOUNT += 1 > READ FIELDMAT( FIELDCOUNT) FROM DICT, FIELD > ELSE STOP 'Field ':FIELD:' not found on dictionary' > END > WHILE DICTREM REPEAT > IF FIELDCOUNT EQ 0 THEN STOP "No fields selected" > RETURN > > ******************************** > * called if command has a syntax error > SYNTAX: > > PRINT MESS ; PRINT > > PRINT "TEXDUMP file TO [file] record" > PRINT "[SELECTING select options]" > PRINT "[SELECT.LIST select.list.name]" > PRINT "[HEADER]" > PRINT "[SAVING] [fields to save]" > PRINT "[QUOTED]" > PRINT "[DELIM field_separator [value_separator]]" > STOP > END > > Q) 2.34 16 node limit on Prime Gateways Re. using GATEWAYS in TCP/IP>HOSTS.TXT file to limit who can access a machine: how do you get over what seems to me a restriction of 16 entries when using TCP/IPTHU! We are using version 2.4.R39-22.0 Well, 16 is the restriction. There is no way to raise it with the TCP/IP 2.4 series that I've ever heard of. But, the good news is that you can almost always get around it by using a class B address as a gateway or by specifying a wildcard gateway. A wildcard will enable a mode where any unknown IP address gets passed through to a specific gateway. Works fine for situations like this. Q) 3.1 What the h*ll is DEREMER? It doesn't seem to do anything at all! Basically, "DEREMER" is/was Prime's YACC. The history of "DEREMER" is: Frank Deremer did a PhD Thesis (circa 1970) on automatic parser generators for the front-ends of compilers. A Harvard University student, Robert Schwartz, wrote a parser generator based on Frank Deremer's work. Later, when Robert got a job at Prime computer sometime in 1977/78 he brought his Harvard student project with him to Prime and called it "DEREMER". Those of us in the Prime Translator Group used "DEREMER" to build the COBOL-85 front-end, among other things such as RPG (!). At a compiler seminar once at BBN, Frank Deremer heard about this and, as the featured speaker, said that he was proud that people at Prime "DEREME" their compilers, thus changing the noun "DEREMER" into a verb, "DEREME" which means "processing a grammar through DEREMER". Officially DEREMER is an LALR(1) parser generator, but I think that about 5 years after DEREMER was written, Frank Deremer proved that his paper was actually about an ALMOST LALR(1) parser generator. It works well enough for what Prime used it for (though some of the COBOL grammars are NOT for those who beleive that parsers should be generated without warnings or conflicts!) Q) 3.2 What does the MAKE_BINARY program do? MAKE_BINARY is the successor to GENERATE_BINARY_LIBRARY, which is the successor to EDB. It creates .BIN files suitable for the LIB directory. It is also used to create so called "DYNT-Libraries", .BIN files which contain no code, only dynamic link directives to resolve various names in the loader/linkers. Q) 3.3 What is the difference between SPL and NEW_SPL? At one time SPL was changing so fast (bug fixes AND enhanced optimizations) that engineering claimed that they had no time to evaluate its effect on products developed with the "not the latest version" of SPL. The people building the master disk software decreed that all products will be built with the previous release's version of SPL, and that the new one being submitted would be available during the build process as NEW_SPL. It was only to be used by those products which depended upon its new features or critical bug fixes. I think the split started sometime in the 19.4, 20.2, or 21.0 time frame, and was eradicated when SPL was added as a member of the "T-Family" at T2.0-22.1. (Talk about being short lived!) Q) 3.4 What does INDEX>BUILD do? I wrote BUILD because we didn't have UNIX make and I was getting very frustrated with the EMACS project. It was too big to just always recompile, yet hand recompilation often led to trouble. So I wrote BUILD. I couldn't call it MAKE since that was taken :) BUILD was reasonably flexible and used search paths for finding sources and derived objects. It had some ability to work with RCS archives (we were going to productize RCS back then). It didn't implement several UNIX make constructs. Macros (only variables), and multiway targets (or at least I don't think I did this). Sometime after I did this the PRIMOS group started using it. Then it started being pretty popular. After I stopped working on PRIME's EMACS, the person who took over EMACS decided BUILD was too complex a tool and went back to CPL scripts. I needn't tell you my opinion on that course. I kept up BUILD until I left in '89. Q) 4.1 How did Prime start? Prime was started on February 4th, 1972 by seven founders: > Robert Baron (President) > Sidney Halligan (VP Sales) > James Campbell (Director of Marketing) > Joseph Cashen (VP Hardware Engineering) > Robert Burkeweitz (VP Manufacturing) > William Poduska (VP Software Engineering) > John Carter (Director of Human Resources) > The company started with the motto "Software First". David Udin (a part-time employee while in graduate school) and Joe Brownstein were the first programmers hired. Bill Poduska's ideas about what to put into the computers they were designing (paging hardware, heavy use of microcoding) more or less determined the technical direction of the company and enabled its success (while it was successful). Otherwise Prime would have been just another minicomputer company and folded a lot earlier than it did. Prime produced a machine called the Prime 200 which was compatible with the Honeywell 316 and 516 range which had just been dropped but for which there was still a demand. Later on they brought out the Prime 100, a stripped-down 200 without processor or memory parity and no option for processor microverify or floating point. Many of these systems, which were generally only used for dedicated realtime activities, still survive as controller engines in printing systems made by Morgenthaller and Linotype, as well as in the guise of Tape Controllers in Storage Technology products. National Geographic Magazine used them extensively. The Prime 300 was next and was dropped in early 1979. The Prime 400 must have been one of the most successful machines of its day, but it was with the introduction of the "VAX-killer" Prime 750 (1 MIP!) in 1979 that fortune first began to smile on Prime. Fortune 500, to be precise. The following year, 1980, Prime stock was the No.1 performing stock on the NYSE. Mr. Poduska later went on to found Apollo Computer Corp. Users will know that commands like "LD" and "BIND" found their way into the Apollo operating systems. Q) 4.2 What happened to Prime Computer, Inc? In 1988 Prime realised that the game was up. Customers were defecting to workstations in droves. Prime were trying to sell big mainframes which cost a fortune to run and charging ridiculous amounts for software such as compilers, etc. What was happening was that hardware - which had been the focus of computing up to the mid 1980s - was becoming a cheap commodity. It was only in the area of applications software where money could be made. Enter Computervision (CV). This company started around the late 60's producing Computer Aided Design (CAD) software systems. In the absence of any standard hardware platform CV badged Data General minis which ran under CGOS (ComputerVision Graphical Operating System). However they always made their money from their software applications. When the Unix workstations first appeared in the mid 80's CV rapidly migrated its products to these platforms and dropped the mainframes. Prime puchased CV in late 1988/early 1989 for around $300M. In early '89, roughly March, a heavily leveraged, hostile take-over bid was launched by BASIC4. It was feared that Prime would be taken over and dismantled for profit. In June '89 the senior management (Tony Craig was the 'hired-gun' CEO) of Prime was looking at how to fend off the hostile take-over. This resulted in finding the 'white knight' to take Prime private and out of harm's way. New York venture capitalist, JH Whitney, arranged the financing and buyout. The end result was Prime being purchased by DR Holdings, Inc., the shell company set up by JH Whitney, for the princely sum of $1.2 Billion, give or take a few hundred million. This privatization happened around September or October of 1989. The first round of big layoffs was in November. At the time, the CPU Group was running two large developments. The first "Pink Flamingo", an ECL, heavily pipelined redesign of the Intel 80486, targetted to run at 200MHz and roughly 180 Mips. The second, "Garfield", was a CMOS-based 50 Series CPU with a brand-new pipeline and micro-architecture. Flamingo died that November and everyone, from the Director down, was terminated. Later, these people were "interviewed" for continued employment on Garfield. It was at this time that the Bobcat (5340?) and Stallion (5540?) projects were being wrapped up. Bobcat was Prime's first forray into CMOS gate-array's and was a "copy" of the Leopard/Cougar ECL-based CPU's, 6250/6450/6650's. Stallion was a dual-Bobcat. Shortly after the buyout, Dec'89/Jan'90, a project was spun up to design a new multi-processor memory sub-system, able to support from 2 to 16 processors. This project was called Wile E. Coyote. The first phase of this program was to utilize the Bobcat CPU for design debug purposes and interim product-line filling, i.e. a "dual-Coyote" would have been functionally equivalent to a Stallion, but able to be expanded to a 4-way or 8-way system. This memory sub-system was to also be used for the new Garfield processor, which was purely a CPU design, not a system design. Due to declining revenues, shrinking budgets and time, it was decided to cancel the Bobcat-based Coyote product plans and re-target Coyote to be solely for the Garfield CPU. This was also largely influenced by the spawning of a new project to develop a brand-new, multi-processor machine to run Unix. This occured in June/July 1990 and the project was code-named Overlord. It was also considered to be the "hot-project" since it would get Prime out from under having to OEM its Unix-based Pyramid and MIPs systems. This new system was to be completed in "9 to 14 months" according to our new CEO, Jack Shields. Anyway, engineers were moved onto Overlord and focus shifted away from Garfield and Coyote. Another new project was spun up to design a brand-new IO sub-system for Garfield, code-name Odie, and these three projects were combined into a complete system-level project called Toons. (Since all three were named after cartoon characters) Just over a year later, mid-1991, the Overlord project was cancelled by Prime's senior management, some of the reasons being that the MIPs R4000 CPU had slipped nearly a year and Prime were unable to successfully license a Unix implementation, so were porting their own. Some of these people were RIF'd, others re-joined the Toons project, while other's continued working on the Overlord R4000 chip-set as contractors for LSI Logic/Groupe Bull. Needless to say, focus was returned to the Toons project as the savior of the company. Throughout the end of 1991, it became readily apparent that the project was far behind schedule for a multitude of reasons: * Lack of staff * Poor morale * Management not accepting the engineer's assessment of schedules * etc, etc In January of 1992 a new man was brought in to run the CPU organization as the VP of engineering. This person was Peter Weyman and he breathed new life and vitality into the whole organization. Schedules were re-evaluated in an honest fashion and processes/methodologies put in place to ensure the schedules were met. The Toons project was moving along quite nicely as summer approached, but as usual, the company was continuing to fail, revenues were declining at a much steeper rate than anticipated and it was becoming clear that it might not be possible to fund the Toons project through it's completion. It was for this reason that the "local" senior management, the VP of Engineering and the like, decided that it might make sense to spin off the 50 Series engineering organization for profit. It was reasoned that the loyal base of 50 Series customers really wanted and required the Toons product, therefore if Prime could continue working without the shadow of a $1 billion of debt, Prime could be successful. Financing and purchasers were being actively sought in late July 1992 when the axe finally fell, it was July 22, to be exact. On this day, workers were informed that the Board of Directors had decided to cease 50 Series operations and take the remainder of the company public, once again under the name of Computervision. This was a Wednesday and we were all told to take the rest of the week off, since there was no need for us to be there any longer. The following week we received termination packages and were required to be gone by that Friday, July 31st, 1992. Regarding the Toons project: * By July of 1992, Prime had already taken orders for 20 or 30 Toons systems, even though they weren't going to realistically ship to a customer until at least January or February of 1993. These orders were shown on the "Field of Dreams" in the hallway, along with the motto, "If you build it, they will come". * Prime had operational prototypes of the entire Toons system running in the lab when it was cancelled. * After the meeting to announce the closing of Prime, engineers returned to the lab and continued working on booting Primos on the Toons system. They were successful. * Prime were in the process of releasing the "full-speed" 'production' versions of the chips that made up the Garfield CPU at the time operations ceased. * The last director of the CPU Group, Mark Laird, continues to hold a yearly Prime re-union at his home, the 4th of which was on Sept 9th, 1995 One of the things that did Prime in, was its failure to keep up with the customers. The need for perfomance in this business goes up about 30% per year. On that basis, by the late 1980's Prime was seriously behind the industry. The seriousness of the problem become clear when the 5000 series came out. The low end machines were promised to the customers as 8 Mip, they didn't even come close. The high end machine (the 5330/5340) was promised as 11 Mip, it is perhaps 5 mip. The Toons engine was supposed to be 13 mip, and while it does run, it is nowhere near the 13 MIPS level required. The life cycle for most systems and controllers in this industry by the late 1980's was down to 2 years. Prime was selling machines that had been repackaged 3 times, and were 6 and 7 years old. In the final 3 years Prime built new hardware: there were 2 new controllers, the Lan Host Controller, and the Swordfish. The record of the R&D operation in producing new products after about 1983 is disaster heaped upon catastrophe. This shows up in one other way. By 1992, Prime was so far behind in CPU technology that not a single system PRIME sold was subject to export controls anymore. The performance was below the threshold for controls. In the end, Prime was just a company which failed to keep up with the technology. At 20 years old, it was probably one of the longest-lived computer businesses. Had the Prime name survived, the company itself would now be changed out of all recognition, probably badging Pentiums as "Business Servers". No matter _how_ good the hardware, people just won't pay top dollar for it any more. Even though a Prime may beat a PC architecturally, by contrast the software, service and support on the Intel platform is cheap. Not only that, but the applications which sell well today are based on GUI technology. Good or bad, whatever your opinion of the Prime engines and Primos operating system, they just ceased being competitive. Q) 4.3 Who were all the people on the front of the Prime manuals? There were several different versions of covers on Prime manuals featuring pictures. At first, the pictures were all of people from in-house (Prime) in the late 70's, but later evolved to stock photos, I'm sure from some catalog of pictures that used models. Fortunately, I think that the descriptions below are unique enough that you can tell if the one to which I am referring is the one you are looking at. Note that some covers flipped the pictures. The person may be looking left on one cover and looking right on another cover. * Bald gentleman in white shirt, tie, suit jacket: Ken Fisher, president of Prime. (There are actually two different photos of Ken - one with him seated in a high back chair, looking into the camera and another with him sorta sitting on a desk, looking to the side). Ken Fisher was the president who took Prime from a company that was barely making it to a roaring success, doubling both sales and the stock price four or five times in the latter half of the 70's and very early 80's. * Frizzy haired guy in plaid shirt with circuit board in background: Dave Lounsberry. Dave was working on magtape controllers at that time, though he later went on to be a manager in the video products group. * Two guys looking at something, with Prime front switch panel in foreground. One guy has a turtleneck, glasses, and beard; the other guy has a mustache, glasses, and red sweater: Eric Pierson and Mark Nobile. Eric worked on Midas in the late 70's. At the time this picture was taken, they were both working on Powerplus. * Chinese woman with black frizzy hair and red dress: Grace Na, a very much liked writer from Tech Pubs. * Guy with messy desk looking at the code listing he is flipping through: Dave Treff. Treff worked on the FTN compiler, improving the optimizer in the late 70's and early 80's. * Woman with glasses, pulled back hair, holding a magtape, standing in front of Prime computer in background: Patricia Powers. Patricia was a field analyst from New York who later came to work in the Data Management Group in Engineering. * Bald guy with glasses and beard in white shirt and tie looking off to side (at a terminal out of the picture): Tony Lewis, senior writer in Tech Pubs. * Woman seated in chair with elbows on chair arms, fingers pressed together in air in front of her: Ev Tate. Ev was a senior comms engineer. * Woman and man seated, facing camera. Woman in blue knit dress, man in white shirt that has a blue patterned top: Laura and Bryan Douros, one of several couples both working at Prime. Laura was a writer in Tech Pubs. Brian was a hardware engineer in the CPU Group. (This picture appeared on one of Prime's pocket guides, but I don't know if it was ever used on full size manual cover.) * Guy in dark blue shirt, wire rim glasses, full head of hair but no facial hair, arms crossed above waist level, turned to side but looking into camera: Mark Johnson, microcoder and CPU engineer extraordinaire. * Guy standing with dark hair, beard, no glasses, holding coffee mug in one hand, looking down at listing he is flipping listing with other hand, old cpu with "bump out" panel in back ground: Bob Beckwith, CPU/microcode engineer. * Woman in white sweatshirt, seated, looking to side, hand on head: Randi Klein, DBMS group engineer. * Man in white striped shirt, tie, frizzy hair, frizzy beard, tinted glasses: Max Goudy (?) I know this was a Tech Pubs person, but I probably have the name wrong. He may have been the group manager. Favorite faces were Harry Bingyou (Sales in San Francisco), the guy with the oriental look and the mustache. The lady sitting next to a Terminet 30 and with the Pertec tape in the background was the regional database specialist in San Diego. The guy standing next to the lady in the pink dress in front of a P400 with a model 33 TTY is Stuart somebody. He ran the education center in Los Angeles. Pat Sansonetti is the balding guy with the beard and glasses. He did most of the Primenet stuff. The tall bald guy in the office was Ken Fisher. The grey haired shorter guy in front of the P400 with floppies (8 inch) and the Pertec was Bob Clausen, VP of Sales. Q) 4.4 What was the history of Prime? > This is cribbed from "The Pocket Prime" > > 1972: Company founded > First product was the 200 computer > 1973: Prime U.K. opens > 100 and 300 systems announced > 1974: Prime Germany opens > First public Stock offering at $7 per share; adjusted for subsequent > stock splits, equivalent to $0.52 per share > 1976: Prime France opens > International sales account for more than 40% of revenue > 400 computer announced > 1977: Prime Scandinavia opens > 500 system announced > 1978: Prime listed on New York Stock Exchange > Puerto Rico plant opens > 1979: Prime Benelux opens > 50 Series product line announced: 450, 550, 650, and 750 systems > Prime INFORMATION systems announced > PRIMENET software announced > RINGNET local area network announced > 1980: Prime opens new corporate headquarters in Natick, Massachusetts > Prime Italy opens > Prime Canada opens > Prime Australia opens > Ireland plant opens > 150 and 250 systems announced > 1981: Prime enters CAD marketplace with announcement of exclusive worldwide > marketing rights (with the exception of Western Europe) to > MEDUSA software > 850 computer announced > 1982: Prime Switzerland opens > 2250 system announced > 1983: Prime Hong Kong opens > Prime joins the Fortune 500, ranking 489 > Revenue exceeds $500,000,000 > Prime aquires exclusive worldwide rights to market Ford Motor Company's > Product Design Graphics System (PDGS) software > 9950 system announced > 1984: Joint ownership of MEDUSA is purchased, allowing Prime to market > worldwide its version called PRIME MEDUSA > Prime aquires worldwide marketing rights to Graphical Numerical Control > (GNC) > SAMMIE is introduced > Prime Japan is acquired > Prime Singapore opens > Prime ranks 451 on Fortune 500 > 2550, 9650, 9750 systems announced > Value Added Resellar (VAR) program announced > Prime Technology Centers open in Natick and Stevenage > 1985: Prime ranks 400 on the Fortune 500 > 9955, 9655, 2655 systems announced > PT200 terminal announced > Prime/SNA software announced > Prime Technology Center opens in Detroit > Prime INFORMATION CONNECTION announced > PERFORMER workstation is announced > FM+ is announced > Prime announces OEM program and signs agreements with Eastman Kodak and > 3M Company > Beijing, China representative office opens > Value Added Distributor (VAD) program announced > 1986: Prime announces new corporate identity program > Prime ranks 366 on Fortune 500 > 2350, 2450, 9755, and 9955-II systems announced > Prime ORACLE announced > PRIMELINK announced > 1987: Prime offers $375,000,000 in Convertable Subordinated Debentures > Prime makes tender offer for Computervision Corp. > Prime acquires Versacad Corp. > 2455, 2755, 6350, and 6550 systems announced > PRIME EXL 316 superminicomputer announced > PXCL 5500 workstation announced > Prime ranks 337 in Fortune 500 > Prime communication software - LAN300, NTS, WSI300, PRIMENET support of > CCITT and PRIME/SNA API announced > First sale of PDGS made to leading Japanese tool and die supplier to > international auto industry > Graphics created by PXCL 5500 workstation featured on "Star Trek" > television episode > 1988: Prime and Computervision merge > 4050, 4150, 4450, and 6150 superminicomputers announced > Prime INFORMATION EXL announced > Prime restructures into two sales and marketing divisions > Prime EXL 320 and 325 announced > PrimeDESIGN and PrimeCONTROL software announced > Prime ranks 334 on Fortune 500 list > Prime co-sponsors "NOVA", the longest running science series on > commercial public television > > 1992: July 22 - Prime board decide to cease 50 Series operations. > Q) 4.5 Why did Prime never get its act together on the Unix front? As an ex-primate now working in that area, I feel that Prime's messing around in the Unix market and never handling it right was a major contributor to its failure. Until it was far too late to do anything realistic about it, the primary attitude towards UNIX was a devout wish that it would all "go away". Those advocating an early entry into the UNIX busines were stymied by the prevailing attitude "Prime sells 50 Series PRIMOS systems". UNIX projects could be funded if they didn't impact the 50 series. By the time the powers that be decided they couldn't ignore UNIX any longer, it was a question of "too little, too late". Prime made the fatal mistake of not realizing that if someone is going to obsolete your products, it had better be you. Several attitudes, as well as famous quotes, contributed: 1. "If we don't sell it, then it isn't our market." --Famous explanation from Prime Marketing why they wouldn't accept new products from Prime Engineering requiring them to market in new areas. 2. "We going to buy this product because we need it now." --Famous line from Prime Marketing why they were going to buy a software product [of poor quality] from an outside vendor they previously rejected from Engineering just a year or two previously. (happened more than once.) 3. "We don't want to cut into our existing product sales." --Famous line as to why not to develop several products. 4. "It would make money, but not [fast] enough." --Why various internal projects were cancelled late in the company's lifespan during and after the buyout/takeover. An interesting comment related to #3: I read an article somewhere that said there were several generations of computers: mainframes, mini's, workstations, PC's. It was claimed that no company ever spanned one of these generations for fear of cutting into their own sales. The article was correct for its time (+5 years ago), though I think a lot of companies have now wised up and are trying... From the "front lines".... I was hired at Prime in '88 to build their short-lived MAP product for Generous Motors. After that little fiasco, they let me loose on the Unix side of the house. It was, to say the least, frustrating. My background has always been in the "heterogenous" environment. I was a standard bearer for several of these approaches -- TCP/IP, OSI, Unix -- before it became fashionable, and usually caught hell for it. *smirk* What I saw was that Prime never really had a good focus or handle on what it meant to be an Open Systems company. I spent alot of time talking to senior management at Prime Park about open systems issues, and, I think, gained the rep of being the "local fanatic".... and probably a bit of an ass... *smirk* At any rate, rate not being a factor here, there's the background of my perspective... Prime was, at its core, a "proprietary" company. And it was *damn* good for its time and what it did. However, the downfall of most proprietary companies is NIH -- the "Not Invented Here" syndrome. It's my take that the whole reason Prime even got involved in Unix was that the sales/marketing force were hearing this word "Unix" from their customers and saw it as a "checkoff" item. At least that's how it appeared to be treated, when the Puzzle Palace's efforts were viewed from the field. Early on, Prime played, as all the "props" did with "porting" Unix to its proprietary architecture and platform. There was a stab at it with Primix. Primix failed miserably because it was, like DEC's Eunice, an OS on an OS. It was not native to the hardware but ran *on top* of Primos. You can, of course, see all the fun and problems that entailed. There was, for a time, an attempt by PP Engineering to create a Unix port that would run directly on the hardware. It was codenamed "Maori", because the Program Manager had just returned from a trip to New Zealand and the port would run in Native mode. I don't recall the project ever getting "done" enough for us to know whether compliance was going to be a problem. The contractor, ISC, did have a kernel working pretty well before the project was canceled for all the usual reasons. Along about this time, the new buzzwords "Open Systems" started floating around some of the larger customers (at least in our area) -- Ford, USAI, Marketing Force... and the natives on both sides of the customer-vendor fence were getting nervous. PP's execs knew they had to do something, so they started playing with the idea of a "dual rail" strategy. The idea was to have two families of platforms, one Primos and one Unix. This would appease the die-hard Primos customers while tickling the fancy of the customers caught up in the "revolution". One of the first efforts in this direction was the development of the EXL300 series (codenamed the Magnum, if memory serves, because it was supposed to be a "PI" (Prime Information) platform for Unix). Once again, this was the typical NIH approach -- create your OWN machine. I actually liked the little suckers. They were damn well designed from a maintenance standpoint and actually pretty reliable (my current unanswered NMI Exit problem notwithstanding). Anyway, as you know, around about this time, the mips wars started heating up... it became a case of "who has the hottest box today". And that was almost literally the problem. The little EXLs just couldn't compete with the MC68010/68020 stuff from Sun, the VAXen architechtures, the Sequent Symmetry approach, etc. The next logical choice, therefore, was OEM. Find someone's box and put the Prime label on it. Although that approach allows you to get a good platform, there are a lot of problems in terms of marketing relationships (are *you* selling against the guy you're buying from?), application ports (where the heck does PI fit into this? how about Medusa?), and a plethora of other concerns. Prime played around with this idea for a while, going through several vendors like Sequent, Pyramid, Sun (thanks to CV), and finally MIPSco. Unfortunately, it was a combined case of "too little too late" and "split focus". When it came down to brass tacks during the LeBow affair, Prime needed to consolidate and they retrenched to their old standby, their proprietary ways, and hunkered down to sell Primos. That was really the last nail in the coffin. So, to make a long story short (I know, I know, too late), Prime never had a real commitment, for a lot of reasons, some of which I've touched on, to get into the Unix market. They viewed it initially as something they needed to have in a back-pocket in case a customer asked. And when the fit hit the shan, they were caught with their drawers down. As you allude to, all the bouncing around between OEM vendors didn't help the matter. For a while there it felt like "partner of the week" (anyone remember the MXL, of which only one, if I recall, was sold?). Customers, especially the big ones like Ford, didn't like this lack of focus or commitment. And Prime lost. Reading back, it sounds like I've some bitterness. Not really. Although there were those of us screaming at Prime to wake up and smell the coffee (Mike Urich, Skeet Stribling, Renee Mente, come to mind) and we never seemed to be paid much attention, my days at Prime are some of my fondest memories. It was a really great place to work, for me. Ah well, enough nostalgia. I've no doubt muddled some things above, the mist of my long-dead brain cells making me forget or misremember, and I'm sure my primate-fiends... er... friends... will correct me. BUt that's what I remember from those heady days. Q) 4.6 Anyone have the Prime yearly financial figures? There were in the annual reports up until the leveraged buyout. I don't think the company turns a profit until about 1976, it then does quite well up until the late 1980's, however a careful review of the finances revealed some very serious problems. The per centage of revenue that was derived from service kept going up. The last year before the buyout, I think service was half of sales. What that really meant was the installed base was getting very old, since unlike some of their competitors, the only component in service revenue for Prime was contract maintenance. If that averaged about 12% per year of the selling price, what does it tell you about the rate of sales when service is 50% of sales revenue? It means in an industry with a product life of about 2 years, yours are 4 years old. Not good... Q) 4.7 What were Prime offering in 1972? > > PR1ME200 > PRICELIST > Effective Date October 1, 1972 > > > PRIME 200 Fully Supported Systems > > PRIME 200 fully supported systems are end-user oriented. As such, > they include a hardware/software package as well as the following > full service items: > - System integration and test at the factory. > - Installation at site. Both hardware and software. > - On site demonstration of system operating parameters. > - 6 Months warranty on hardware and software. > - Systems reference manual containing system specific oper- > ating instructions, user information, and maintenance procedures. > > Type Number: 8000 > Prerequisite: None > Price: $38,000 > > Description: High Speed Disk Operating System featuring DOS -200 for single > user interactive program development and execution via highly > reliable and fast fixed head disk mass storage. Complete > FORTRAN capability. Supports PRIME's translators, editors, > loaders, and utilities. System includes compact packaging in a 72" > cabinet, power distribution, cooling, and internal cabling. > Requires a single power source of 60 Hz, II 7 VAC. System con- > figuration contains: > - PRIME 200 Central Processor Unit with 8 channel programma- > ble DMA", 64 level vectored priority interrupt system, asyn- > chronous serial communications interface, full programmers > console. > - 16K Words of MOS memory with battery backup for standby > power. > - Hardware Multiply and Divide. > - Double Precision Arithmetic. > - Automatic Program Load from teletype, paper tape reader, > and disk. > - Power Monitor, Power Failure Interrupt, and Automatic > Restart Protection. > - Teletype Model 33 ASR and Controller. > - Paper Tape Reader, 200 cps, and Controller. > - Paper Tape Punch, 75 cps, and Controller. > - Real Time Clock. > - Fixed Head Disk, 256K words, and Controller. > - Microdiagnostics. > > > > Type Number: 8010 > Prerequisite: None > Price: $35,000 > > Description: Removable Media Disk Operating System featuring DOS-200 for > single-user interactive program development and execution via > highly flexible and convenient disk cartridge type moving head disk > subsystem. Complete FORTRAN capability. Supports PRIME's > translators, editors, loaders, and utilities. System includes com- > pact packaging in a 72" cabinet, power distribution, cooling and > internal cabling. Requires a single power source of 60 Hz, 117 VAC. > System Configuration contains: > - PRIME 200 Central Processor Unit with 8 channel programmable DMA, 64 > level vectored priority interrupt system, asynchronous serial > communications interface, full programmers console. > - 16K Words of MOS memory with battery backup for standby power. > - Automatic Program Load from disk. > - Power Monitor, Power Failure interrupt, and Automatic Restart > Protection. > - Teletype Model 33 ASR and Controller. > - Paper Tape Reader, 200 cps, and Controller. > - Paper Tape Punch, 75 cps, and Controller. > - Real Time Clock. > - Moving Head Disk, 1.5M words, and Controller. > > > > > All prices subject to change without notice and are subject to Prime > Computer, Inc. standard terms and conditions. > > Prime Computer, Inc., > 17 Strathmore Road, Natick, Mass. > (617) 655-6999. > > Prime sales offices: Boston (617) 237-4565, New York (212) > 896-6262, Washington D.C. (703) 533-934,3, Philadelphia > (215) 688-0396, Jacksonville (904) 396-5253, Chicago (312) > 887-1845, Dayton (513) 435-1343, Detroit (313) 356-4840, > Tulsa (918) 663-0518, Palo Alto (415) 968-6003, Los Angeles > (213) 881-8433. > > Authorized representatives: Phoenix (602) 957-91 10, Albuquerque (505) > 255-2330, Denver (303) 771-0140, Seattle (206) 454-9332. > > > For a price comparison, consider that in 1972: > > A Ford Thunderbird cost about $11,000. > A five bed room home 2100 sq. ft cost $42,000. > That house today would sell for $250,000. > Q) 5.1 Nominations: "Most interesting use for a working Prime system" Some former Primates write: * My most memorable application was a P400 running a magnetic confinement nuclear fusion experiment at the Los Alamos National laboratories. Talk about a nasty EMI environment. Everything was fiber optic, and that was in the late 1970's. The whole installation was inside a shielded room. It had a great deal of real time instrumentation, CAMAC I believe. In any event I think it was decommissioned in that late 1980's. That part of Los Alamos went the VAX route. Some of the A/D converters were running at 8 million samples per second even in 1979! Prime had very good hardware for real time, but they choose not to use it for that. * Back when I was a Primos engineer, I became involved with some customer having problems with the plotter support in Primos. It probably was a special. Apparently, the plotter was used for biorhythms, which along with other stellar predictions, was the entire business of the company. They even upgraded their processor at one point, I think, to support their growing load. * Back in 1978-1979, I built a "tactical nuclear wargaming system" on a Prime 300 -- all in R-mode assembly for God's sake -- in Germany for a NATO application. The thing drove a large 3-color overhead screen which was quite new in those days and it all ran on power from an army generator in the snow and mud of Germany. * In late 1984 I worked for Prime (while a student). Our secretary gave me a call from the US Navy. They wanted to know how much G-force a 2250 could take a still survive. (We didn't know.) When asked why they cared, they told me that their intent was to parachute them out of planes to provide computing when needed in battlefield situations or remote locations. Q) 5.2 Humorous Anecdotes About Prime A former Primate writes: I noticed your plea for humourous anecdotes about Prime. While I have a number of funny stories about co-workers, I can think of only one that relates to Prime as a whole. Sometime during the late 1980's, those On High at Prime decided to honor a retiring employee who had served as janitor at the Prime Park facility. This person had also been employed by the Carling Brewing Company as a janitor in the same building, prior to its being acquired and renovated by Prime. If memory serves correctly, he'd spent perhaps 20 years at the brewery/Prime Park. In honoring the person, Prime crafted a small plaque that was placed next to the outdoor fountain and waterfall located between Building 15C (tower) and Lake Cochituate. The fountain had recently been restored and painted, and the plaque declared the fountain was dedicated to this individual for his several years of service. Located near the plaque was a 2X4 plank on which an empty fusebox and throw switch were mounted. None of the invited press (local newspaper) or attending local political dignitaries were informed that the fusebox was not connected. In true Prime marketing fashion, a facilities employee was stationed behind one of the Building 15C pillars with 2-way radio in hand, waiting for Joe (he wanted to be called "Joe", not "Mister Henson") to read the proclamation. A second facilities person was stationed in the Building 15A basement with another 2-way radio. Joe declares the fountain blessed and asks the retiring employee to throw the switch. Hidden facilities employee is heard saying "NOW" into his 2-way. Second facilities employee, 500 feet away, throws the real switch for the fountain power. Fountain, after a brief delay, comes to life. Dignitaries applaud and cameras flash. Everyone goes back to work. Facilities employee is seen yanking the fusebox and switch out of the dirt and tossing it into a truck. Local geese find a new spot to cool their collective heels. All involved in this treacherous plot have been sworn to secrecy and are now employed elsewhere. The fountain, if it has survived, now belongs to Boston Scientific Company. The fusebox resides at the Natick landfill. Bomb Squad ---------- One London FSE accidentally bought all the traffic round Lambeth bridge to a halt, and had a Government building evacuated ... PR1MATES may have seen in one of the newsletters that FSE's were to start having PR1ME written all over their toolkits. This was this FSE's fault. She'd parked in our basement, and after pulling a long, tiring, afternoon replacing some kit, got in the car and drove off. Leaving her tool kit in the basement ... of course, when the security guards did their rounds they discovered a large, locked, unmarked brief-case. The building was evacuated, as the TUC building next door, and the Tory HQ over the road. The roads round the area were shut too. Of course, everywhere was re-opened when the nice little remote controlled robot shot the lock off, and they discovered it full of tools and PR1ME Field Service guides. Q) 5.3 Nominations: "Most anal behaviour by a systems administrator" * Thames Polytechnic, London, England, where they: > - Refused to give out any system manuals > - Controlled how much login & CPU time allowed (6 hrs/week for > Computer Science students?) > - Instituted a per-user logged out quota which was less than > the Primos logged in quota. When you logged out any excess > files were deleted without warning (unless you typed FINISH > as opposed to LOGOUT) > - Revoked the MESSAGE command (thereby creating the Thames Poly Hacker > Society rite-of-passage, namely to write one's own message program > using SMSG$) > - Had a program which scanned directories looking for any programs > containing Primos subroutine calls > - Had a program which monitored terminal sessions (ESPY) > - Had only UR rights to the top-level directories > - Banned people from writing "front-ends" to Primos to give > themselves their own environment. To be fair, however, > it should be noted that some of these programs grew > in complexity to the stage where they rivalled Primos itself. > In mitigation, however, it should be noted that by doing the above, TP created a generation of fanatical Prime hackers. * Loughborough University, England: Disallowed creation of subdirectories * Miscellaneous examples of "madministration": Renaming "futil" to "foodil" Q) 6.1 Where can I get support? In this section I would like to include details of third party vendors of software, services and support. Vendors: if you have offerings of interest to the Prime user community, please let me know, and receive a free plug! > > *** UNITED STATES *** > > CVSI > > The Official Source of Support - CVSI (Service International) > This is a spin-off company, and is not part of CV despite the name > > 100 Crosby Drive > Bedford, MA 01730-1480 > 617-275-2600 > www.cvsi.com > > PERITUS > > Peritus Software Services maintain and bug fix Primos. > See: http://www.peritus.com > Their web page doesn't have anything about Prime on it though. > > FIRST SOLUTIONS > > 1st Solutions, Inc. is the primary channel for sales of 50 Series > hardware in the US and Canada for Computervision Corporation. We can > provide users with licensed hardware and software at a very reasonable > cost. We have the ability to help Prime users maximize their 50 Series > investment through upgrading or downgrading, and we have developed a > multi-host RAID 7 solution that can run on your Prime and your other > cpu platforms simultaneously. > > We also sell general purpose terminals and printers, that work not > only on your Prime but on many other types of computers. Frequently, > we have what we call "junk"--you might say, "hey, this is a pretty > good deal". > > 1st Solutions, Inc. > 11460 N. Cave Creek Rd. > Phoenix AZ 85020 > Phone: 602-997-0997 > Send Email to: info@firstsol.com > > SOFTWARE TECHNOLOGIES GROUP > > Software Technologies Group, Inc. - The developers of MAGRST for Unix > 1127 S. Mannheim Road > Suite 313 > Westchester, IL 60154 USA > > (708) 547-0110 > FAX (708) 547-0784 > > email: sales@stg.com > > http://www.stg.com/magrst > > BLUFFVIEW > > BluffView - Prime 50 Series Computers & Peripherals > Used Prime 50 Series Computers & Peripherals. > 6000, 4000, 9000, 2000 Series Processors. > 5310, 5320, 5340, 5370 Systems. > Primos Licensing Available.... > http://rampages.onramp.net/~bview/ > > WORDMARK > > WordMark (creators of Primeword) is alive and well in > the UNIX market and focuses in the MultiValue (Universe/Unidata/Pick) > industry. We have converted many Primes account to Unix and now, NT. > WordMark (including Primeword) is currently supported on Primes as well > as just about every type of UNIX platform. We service many existing > Prime installations as well. > > WordMark offers other Prime and UNIX products including Email for Prime > and UNIX platforms (intranet) with Internet access from ASCII (dumb) > terminals as well as ISP services. > > The latest product offering is Liberty ODBC Drivers and a Prime > INFORMATION port is scheduled for April this year. This is a very > unique offering for Prime users to be able to connect Windows > applications such as Word, Excel and Access (clients) to Prime > INFORMATION. Any ODBC compliant Windows application can be connected. > > Our contact information is: > > WordMark Liberty > 101 Park Center Plaza, Suite 1111 > San Jose, CA 95113 > > 408-975-1100 > 800-835-2400 (sales) > 408-975-1111 (fax) > multivalue.net (Web) > worprocessing.com (Web) > pcverse.com (Web) > info@multivalue.net (email) > wordmark@netcom.com (email) > > Jeff Weidler, WordMark Liberty (weidler@ibm.net) > > DALLASTONE > > Dallastone, Inc. > 2 Cote Lane > Bedford, NH 03110 > 603-647-8168 > FAX 603-624-2466 > > Has been selling developing SCSI based solutions for the Prime market > for the eleven years. ComputerVision installation and on site maint is > available if needed. Current products include: > > Primos/DOS > PCF and PCFX -- hardware and software to share floppy and hard disk > drives between a pc (or pc network) and a Prime Computer. Data > can be exchanged at disk speeds. > > Primos > 7 to 14 gb 8mm tape subsystems > 4 to 8 gb 4mm tape subsystems > sequential and random jukeboxes for above > hard disk subsytems using state of the art SCSI drives (up to 2.5 gb > capacity. Optical disk subsystems and jukeboxes. > > Unix > Backup and Near Online Tape software and hardware for most platforms. > Tape libraries up to 2 teribyes and larger > > Barry Dacks, CDP > Product Manager > 904-448-0337 > > COMPUTRONICS > > Computronics > 4N165 Wood Dale Road > Addison IL 60101 USA > Email: info@computron.com > Voice: (630)941-7767 > Fax: (630)941-7714 > Web: http://www.computron.com > > Contact: Randy Styka > > They sell a PEEK screen watching utility, PKZIP for Prime, > LPD product to allow Primes to print on other systems and > vice versa and a CPL to Shell Script converter. > > PULSAR > > Pulsar Systems, Inc. > > Web: http://www.pulsarsystems.com > > A company specialising in porting Prime applications to Unix > > *** CANADA *** > > Pennant Computer Solutions Limited > 115 Woodstream Blvd., Suite 17 > Woodbridge, Ontario > L4L 8K5 CANADA > > Tel: 905-851-2271 > Fax: 905-851-2272 > email: pennant@netcom.ca > Web: http://www.netcom.ca/~pennant > > Contact: Mario Damiano (email: mjdamiano@aol.com) > or > Gianni De Santis (email: giannidesa@aol.com) > > Pennant Computer Solutions Ltd. established in 1991, currently > maintaining almost all Prime sites in Canada. > Provides equipment sales, add-ons, upgrades, and service as well > as migration consulting services. > > > *** GERMANY *** > > ISC-GbR > Hinterhufe 110 > D-42929 Wermelskirchen > > Voice: (+49) 2196-7212-0 > Fax : (+49) 2196-7212-16 > isc@isca.de > > Contact: Mr. Martin Held > > > ISC-GbR, is the first Address for Prime 50 Series in central Europe. > > We supply complete 50 Series Equipment, Peripherals, add-ons, Upgrades > and Maintenance as well. > > We also supply Systems and Replacements from HP, IBM, SGI, SUN > and CalComp. > > *** UNITED KINGDOM *** > > Andy Milner > Milner & Rees > 4 Starling Close > Pinner > Middlesex > HA5 3PH > Voice - 0181 868 2800 > Fax - 0181 866 7182 > > Products include: > > * MAGRST for UNIX will allow you to transfer your INFORMATION systems > to UNIX and then upload then into universe, unidata etc > > Products are for sale on end user licence basis >