Early Computing at Rhodes
From ZaInternetHistory
| Table of contents |
Overview
Rhodes University was one of the first universities in South Africa to install a computer. This was an ICT 1301 computer, installed in November 1965. Mike Lawrie was the customer engineer for this computer, which in itself could be a longish story. One of the most important programs that this computer ever ran was one to calculate "Ray Tracing for Initial Values as Follows", which was the work for Pat Terry's M.Sc degree in Physics. This program used to run overnight, and on more than one occasion Pat was found in a sleeping bag on the floor of the computer room - but that's another story. One of the "fun" things run on the computer was a computer dating program for the Arts and Science Ball in September 1967, where the idea was that the computer would give you a shortlist of possible partners to invite to the Ball. There were a number of other fun-but-useful things done, like a number of very useful extensions to the MAC compiler, in particular adding a TEA statement so that the running program could be dumped to the drum store while everyone went off to have tea. This was of particular use in that Pat's long-running program could be interupted while short jobs were run, and then re-started again. The gist of this is that the Mike Lawrie and Pat Terry built up a very strong relationship over this particular computer, and had this not happened the Fidonet link might not have survived the "C:\JUNK" incident of November 1989.
Towards the end of 1969, the 1301 computer was replaced with an ICL 1901A. In July 1971, Mike Lawrie was appointed to the post of Computer Manager at Rhodes, and a few years later an ICL 1902T was installed to replace the 1901A. The 1902T ran the Maximop operating system that had been developed at Queen Mary College (http://www.qmc.ac.uk), London. The staff at Rhodes, in particular the systems programmer Martin Urry, rapidly became the South African experts on Maximop. The first terminals that were used were teletypes running at 110 bps, and they were very popular in spite of the slow speed and the noise, because they allowed interactive computing. Indeed, they were so popular that in 1975 the card reader and card punches were decommissioned, and all computing was done via the network.
Moo
Mike Lawrie is convinced that the efforts that were put into implementing the MOO game helped considerably to further cement relationships that took strain during the development of the Fidonet gateway, so the story is given below.
During the days of the teletypes, Pat Terry had returned to Rhodes with a Ph.D from Cambridge (http://www.cambridge.ac.uk) ("the" Cambridge in the UK), and had encountered a program called MOO. This was a player-against-the-computer game, but there was a wider issue in that each player's score was on a public league. It gave great status to be at the top of the MOO league. An article in Software Practice and Experience (SPE 1(2), 201-204, 1971, author's name was given as "Aleph0") showed by means of Information Theory that if the player could use all of the game response information perfectly, the long-run average score would be about 4.3 (ie 4.3 turns on average to reach the end of a game). An alternative way to get to the top of the league was to crack the storage location of the league table and put your name there. More exciting was to put a name like "gremlin" at the top of the league so that the maintainers of the program were left guessing as to who gremlin was as well as how this had been done. So, the challenge was thrown open by Pat Terry (main programmer of MOO) and the Mike Lawrie (main protector of the computer files) to all and sundry to crack MOO by any means whatsoever, but heaven help whoever was caught trying to crack any other part of the computer system.
Well, one student by the name of Sean Haffey went through a phase of being at the top of the MOO league for far too long with far too low a score. Pat Terry and Mike Lawrie spent considerable time together to find out how this had been achieved, because neither Sean Haffey nor anyone else could play so well so consistently. This cemented relationships between Pat and Mike, particularly when dealing with technical computer issues.
For the record, and perhaps Sean Haffey does not know this, in desperation we spent quite a bit of time scratching through the waste-paper bins of the terminal room looking for the abandoned teletype printouts that were from Sean Haffey's interactive sessions, and eventually found enough to give us a good lead as to how he was doing what he did, and thus we patched the security gap.
The game itself required the player to deduce a 4-digit number that the computer had generated at random for that particular game. The number could not start with a zero and had no repeated digits. The player typed in a 4-digit number (of whatever choice), and the computer responded with a count of the number of bulls (ie correct digits in the correct position) and the number of cows (correct digits but in the wrong position). This is a bit like the commercial game called Mastermind. One significant difference was that it had league table that was publicly readable, so anyone could see how well anyone else was doing.
The First of the Video Terminals
Teletypes gave way in due course to video terminals. ICL (http://www.icl.com)'s video terminals were wickedly expensive, used synchronous communications, and were not suited to the academic environment at Rhodes. (maybe this is unkind to say so, but there really was not a lot of money to go around). So, we went for cheaper async terminals. Some low-cost async video terminals were purchased from Newbury Labs in the UK, and speeds moved up to 300 bps and to 1200 bps. There were also three Tektronix T4010 graphic terminals.
There was a bit of a problem in that neither the staff at Rhodes nor ICL (http://www.icl.com) knew how to connect these video terminals to the ICL (http://www.icl.com) computer. Eventually, we at Rhodes worked out that this could be done with two wires, viz the ones that carried the transmit and receive signals, provided that we could get a good local earth at each end of the link, and provided that certain control signals were strapped. For the technically minded, on the RS-232 25-pin connectors we would strap pin 4 to 5 and strap together pins 6, 8 and 20. Pin 7 went to the local earth at each end of the connection, and pins 2 and 3 were connected to pins 3 and 2 resp of the remote connector. By whatever weird accident, we found that this would work error-free at 1200 bps over some 2 Km of Telkom (http://www.telkom.co.za/)'s copper local-leads, and Mike Lawrie (and in due course many others) used this to get interactive access from home. We put lightning suppressors between pins 2 and 7 and between 3 and 7, and put a 500 mA fuse in the circuit to protect the Telkom (http://www.telkom.co.za/) cable from blowing up during thunderstorms. Some years later, we used a 4-wire circuit driven by RS-422 line-drivers that we developed at Rhodes, and this would work at speeds of up to 38.4 Kbps, on the shorter circuits, without any errors. These were still in production in 1997.
In due course (??year?? 1978??) the 1902T was replaced with an ICL 1904A. By then the network had expanded, and the faster computer was needed. Maximop was still the operating system in use, and we made use of ICL (http://www.icl.com)'s George 2 and Queen Mary's College (http://www.qmc.ac.uk)'s Maxibatch.
The point about all of this is that in due course the technical computer staff at Rhodes were automatically provided with a connection to their homes, as was Mike Lawrie. Mind you, it was very difficult to get members of the Computer Steering Committee to agree that PCs should be provided as well, but in due course this happened. So, when the Cyber/Fidonet gateway was being developed and was being expanded, the computer staff who were doing the development could access these facilities from home, in the evenings. Given that time zones are such that the South African evenings are the normal working hours of most of the USA, we could communicate with our contacts in the USA at times that suited all of us (no job-type disruptions for us, and normal working hours for our friends in the USA). It was relatively easy to have several exchanges of email in an evening, and this boosted the productivity of the efforts that we put into developing this system.
There was a teleptype circuit to the ICL (http://www.icl.com) computer at the University of Fort Hare, where Maximop was also in use, but this was used only to connect a teleptype at one end to the ICL (http://www.icl.com) host at the other - there was no attempt to link the two computers directly.
The Cyber Computer
Rhodes University installed a Control Data Cyber model 825 computer in November 1981. This computer was a an excellent number-cruncher, and it had a very flexible Network Processing Unit that handled the data communications. The operating system on the Cyber was called NOS, which stood for Network Operating System. The simplest way to put jobs into the computer and to control them was via a VT100 or similar terminal.
The Cyber's storage unit was a word of 60 bits. This was ideally suited for scientific applications because floating point operations were very fast indeed. Compile times for Fortran programs were incredibly fast as well, a moderately-sized program would compile in a matter of seconds. The Cyber's 60-bit word was treated as 10 6-bit characters whenever it was necessary to process character strings. Because the Cyber was designed for scientific work, the programming language was Fortran, which at that time required only upper-case characters, so a 6-bit character set was very efficient. However, the full ascii 7-bit character set could be handled by the NPU, which was hard-coded to treat "ordinary" 6-bit characters as their 7-bit ascii upper-case equivalent, but if the character was a circumflex (ie "^"), then the following character was converted to a lower-case ascii 7-bit character. That was for characters leaving the Cyber via the NPU, and there was an equivalent conversion when ascii characters were received via the NPU and stored within the Cyber. A parity bit could be handled as well, and the full 8-bit character set could operate through the NPU in ascii or ebcdic coding. In all, the NPU was an extremely flexible and fast device, and could handle just about any communications protocol that was in use by any other mainframe manufacturer. It is significant that, unlike IBM with their SNA network and DEC (http://www.dec.co.za) with their DECNET network and other manufacturers with their own proprietary protocols etc, Control Data did not invent any proprietary communication protocols, but had packages for the Cyber's NPU that allowed it to handle such protocols.
So what, you well might ask. Well, for sure it made programming a mailing system on the Cyber a bit of a problem if you wanted to handle the full ascii character set. And that had to be done if one wanted to communicate with the rest of the world, because that was the lingua franca. We had quite a bit of work on our hands as a result, but all of this was completed long before we had even heard of Fidonet.
So much for the character set and protocols, there were other matters that had to be addressed. One of them was that the Cyber did not have a mailing system, so we had to write one if we wanted one. Much of the programming of the Rhodes mailing system on the Cyber was done in Cobol. Yes, that scientific oriented Cyber had an excellent Cobol compiler. Cobol was chosen as the programming language for the Rhodes mailing system because it was so easy to make use of the disk routines, particular the Direct Access routines. Handling ascii characters, though, was something else, and that gave us a headache. The main programming work on that mailing system was done by Hugh Murrell, in the early 1980's. Ian Dore and Eugene de Jager were involved in the changes that were necessary later on in order to interface with the Fidonet gateway.
The stand-alone mailing system had moderate use at Rhodes. Each registered user had a mailbox, some users made use of them sometimes. There was considerable email exchanged between the three of us in the Computing Centre, so if nothing else we could see the benefits of expanding this facility on to cover a much wider geographic region.
Why is any of this significant? Well, the full source code of the Cyber mailing system was at hand, as well as the total design, because it was developed as Mike Lawrie's design, and thus when it came to writing gateways to move mail in and out of the Cyber, it could be done relatively easily.
Attempt to Use Modems
There was a serious attempt to "legalise" the situation regarding the use of Telkom (http://www.telkom.co.za/)'s copper cabling that ran around Grahamstown (1989?). It somehow seemed to be wrong that we were not using modems, so we made a very serious attempt to rectify the situation. An order was placed with Dimension Data (http://www.didata.co.za/) for their LDM2000 limited distance modems that had been on demo at a Telkom (http://www.telkom.co.za/) conference in Cape Town. The order fortunately spelt out part of the specification that was on the glossy blurb, something along the lines of "These units shall operate at 9,600 bps or faster over a distance of 5 Km". Given that the Rhodes' homebrew devices ran with 100.00000% reliability at 19.2 Kbps from the Cyber to the Mike Lawrie's house (about 2 Km of wire), this circuit was chosen as the test-bed for these modems. In short, nothing worked on these LDM2000 modems. Telkom (http://www.telkom.co.za/) technicians were called in to check the line (there was nothing wrong with it), the LDM2000 design engineer flew in from Johannesburg to attempt to fix the modems, all to no avail. Well, not quite, a Telkom (http://www.telkom.co.za) technician did a "hot change" of a modem board in the modem rack (this is what the specs said could be done) and blew a 5 cm dirty black hole in one of the boards in the Cyber. The modems were returned to Dimension Data (http://www.didata.co.za/) in July 1989. Well, a year or so later we eventually got our money back from the vendor, but we'd learnt a lesson. Don't use modems unless you have to, rather drive the wires with your own devices because they work.
Theorem: Vendors of products and users of products are quite distinct, and the one does not understand the needs of the other.
Corollary: If you buy a product for a particular purpose, it will not work to its specification.
Plato
Rhodes University ran the Plato computer based education system on the Cyber. Rather, on one of the Cybers, the one called RUPLA. Three of these computers stood in the computer room, one for "normal" computing of research and administration (RURES), one for Plato (RUPLA), and one that was acquired from JCI as a spare that could be cannibalised in case the sanctions against South Africa got worse before they got better.
A number of institutions connected to this Plato system, as far afield as Cape Town and Johannesburg. This was quite tricky, and had to be done by means of communication across lengthy (600 mile) analog circuits that were not very reliable. The lessons gained in keeping these communication links working were extremely valuable when it came to working across an analog circuit to the USA. Some of these links used a private (ie non-Telkom) X.25 PAD at each end in order to multiplex a number of Plato terminals on one circuit - again, valuable X.25 experience was gained.
But there was another benefit that arose from Plato. Professor Fred Hoffstetter from the University of Delaware visited Rhodes University (year??--mid '80s??). One thing led to another, and Mike Lawrie was allowed a signon on one of the Udel computers (??1988??). Access to the Udel computer was via the exhorbitantly expensive and inefficient Telkom (http://www.telkom.co.za/) international X.25 service. The big plus was that Udel was on the Internet, and Mike Lawrie could thus send and receive email directly into the Internet. The value of this cannot be overstressed - when the Cyber/Fidonet gateway was being developed in 1988, it was relatively simple to check that email did or did not arrive correctly at an Internet site, and that it could be sent from an Internet site into the Cyber. It was also possible to download RFCs from the Internet via this link, albeit an expensive thing to do, so we could rapidly obtain the specifications that were needed. Getting these specifications electronically was very helpful indeed. The procedure to get them in paper form was horrendous. Firstly, non-existent funds had to be found in an impossibly-tight budget, then ordering from the USA was a long-winded process requiring clearance in advance for a foreign exchange payment, which in itself required the vendor to provide a pro-forma invoice in advance, and then when/if the order was ever fulfilled by the USA vendor (remember, sanctions were in place, some vendors refused to supply goods) it would arrive in South Africa and incur a hefty import clearance charge and import duty, never mind the lengthy delays of this last process.
For the record, the Mike Lawrie's signon at Udel was lawrie@vax.oit.udel.edu.