Until early in 1984, the PNX1.5 system was the only one available to PERQ users. It had a very slow compilation system and although useable had many deficiencies for serious work. The PNX2.0 system (see Section 36.5) was a major improvement and should have greatly improved the system for SERC users when it became available early in 1984. However, the lack of hardware upgrades meant that these benefits were only seen by a small fraction of SERC users during 1984.
Even so, by mid-year, the user reaction to PNX2.0 was, in general, favourable. The FORTRAN compilation speed was greatly improved and a significant increase in single precision floating point performance was seen if the system had 16K WCS. The PASCAL compiler was generally well received although there were debugging problems as the standard sdb debugger could only be used in a limited way.
The window manager was better with faster graphics and the SPY editor was available. On the hardware side, the GPIB driver gave much improved performance.
PNX2.0 was the first version of PNX to have a genuine virtual memory system. The system still had significant drawbacks. The page size was too large (8 Kbytes for code and 128 Kbytes for data) which meant that large programs making random accesses to data performed badly. The code and data areas were rigidly separated. Thus AI programs which typically construct code in data areas and then execute that code could not work effectively. It was not possible to fork processes larger than 128 Kbytes. This prevented incremental compilation, again used extensively by the AI community.
Thus, although PNX2.0 was a significant advance, it was not the end of the road.
The discussions concerning the 16K WCS upgrades were coupled with the provision of a decent virtual memory system available on the PERQ1 systems as well as PERQ2. ICL were not committed to any PNX release past PNX2.0 on PERQ1s.
A number of meetings at various levels with ICL during 1984 resulted in an agreement that the SERC and Computer Board sites would have an operating system release past PNX2.0 which provided many of the facilities in the future PNX4 and PNX5 releases which were currently only targeted at PERQ2s. These included the key requirements of a better virtual memory system and availability of the optimising FORTRAN compiler being developed at ERCC. This release of the operating system was later given the name PNX SR (Special Release).
The Virtual Memory System would support true demand paging for both code and data (but not the stack region) using a 4K page size allowing a maximum program size of 0.25 Gigabytes. Various enhancements to the software were also provided in this release, including some software that ICL were attempting to charge SERC for.
In addition, the ability to change data into code would be provided as would support for fork operations on data sets greater than l28K. Enhancements to GKS originally destined only for PERQ2 would also be available on PERQ1.
These changes made a significant difference to the lifetime of PERQ1s which would have been virtually obsolete immediately without this. It is one example where the central control and having a Common Base policy gave SERC the clout to get ICL to change a marketing decision and one which would cost ICL a significant amount of money as the work was to be subcontracted to Spider Systems.
At this time, ICL confirmed that it was not possible for PERQ1s with 1 Mbyte of memory and 16K WCS also to have an ethernet connection. The power supply unit on the PERQ1 could not cope with the total load. As a result, ICL also offered to replace PERQ1s that were not very old by PERQ2s at a cost of £10K. With the list price of a PERQ2 being nearly £23K this was an attractive offer that was only taken up by SERC in the SE area and then only to a limited extent.
There was one final constraint on this whole deal and that was that PERQ2 should stay in the SERC Common Base. Luckily, before the need to make a decision was made, SUSSG had confirmed this!
PNX3 was very similar to PNX2 but supported the landscape screen and the five and a quarter inch Micropolis discs. It also had the better bad block handling made available under PNX2.2, a maintenance release.
The next major release of PNX was PNX4 which included the following facilities:
The original date for this was early in 1985 but the field release did not arrive at RAL until March.
The next release, PNX5, included the new virtual memory management system, Multibus support (and hence large discs and tape), streamer tapes, colour system, 24 bit addressed cpu and 4 Mbyte memory support. This appeared later in 1985.
Both these releases were for PERQ2. The PNX SR release for the PERQ1s was of a similar level to PNX5 less those facilities, such as Ethernet support, unavailable on a PERQ1.
The general view is that PNX5 is a reasonable version of UNIX both in functionality and performance. It took well over two years to achieve it from the initial PNX release and it should have arrived quicker. Part of the problem was convincing ICL of the need. There was also considerable waste of effort, as far as this product was concerned, in the continuing need to support the user population that had built up around the earlier POS system and the manpower used in working with Three Rivers on a fully distributed operating system to replace PNX.
Looking at other suppliers, the only company with a fully distributed system is Apollo with their DOMAIN system and this is not based on UNIX. Companies such as SUN have resorted to providing only some of the functionality (for example, SUN's Network File System). Long term, it is clear that extra functionality needs to be introduced into UNIX to allow it to be a fully distributed operating system. It has weaknesses in a number of areas especially security and these will have to be addressed. ICL's basic philosophy for the future will not be proved wrong. However, the major problem was the time it took to convince ICL that a virtual memory system for the PERQ was an essential requirement. (Amazing when the world's first virtual memory system, the Atlas computer, was a joint venture between Manchester University and that part of Ferranti which later became part of ICL!) Until Colin Prosser's arrival at ICL, there was little indication that they understood the gravity of the problem.
By late 1985, the great advances in speed were beginning to show. For example, a very large compilation on a 1 Mbyte PERQ2 had the following compile times:
PNX4 75 mins PNX5 field trial 1 17 mins PNX5 field trial 2 4 mins
