Counting five-barred gates

I was an early user of the Commodore ‘PET’ computer at work in the early 1970’s when I worked as ‘Admissions Officer’ at the Oxford Polytechnic. You can see a YouTube video of one working if you are interested. There’s also a long and very interesting discussion in which an early adopter in 1977 explains how he programmed it to make his garage chain business more efficient.

The ‘PET’ (stands for ‘Personal Electronic Transactor’) was a fully self-contained unit (here’s a picture) released in 1977. We had the first model available.

It had the famous ‘chiclet’ keyboard which was quite hard to use. Some of the keys had ‘playing card’ symbols on them:

I had taken a short Fortran 68 course as a member of staff and had got some idea of the rudiments of programming so I decided to see what could be done using the Commodore BASIC interpreter on the machine.

One of my tasks, a dull one with some drudgery, was to keep a daily tally of applications for different courses and degrees. There was no UCCA or UCAS then. Polytechnics received applications unmoderated and directly from applicants in all parts of the world. To keep track, we counted them daily and created a large ‘five bar gate‘ grid on a very large sheet of paper ruled into squares. This seemed an ideal candidate for automation. So I wrote a fairly simple Commodore BASIC program to accumulate daily numbers into arrays so that we could add the new items each day. We took the precaution of maintaining the manual ‘five bar gate’ analysis as well in case anything went wrong. For several months it went well. The C60 cassette tape containing the data was read into memory each day, the programme duly started and all in all it relieved the clerical monotony somewhat. We could also pretend (with some justification perhaps) that it represented ‘important pioneering work’ in automating the office using modern technology.

One day, it just failed to load the program and all the data was lost. I can remember the very deep sinking feeling as I tried everything I could think of to revive it – but it was no good. It transpired that the C60 tape we were using had stretched (I should have known about this already given my previous experience with the Kalle Infotec Word Processor) and was no longer useful in loading up our precious data. There was no mechanism for backup or keeping a second copy.

It was great fun while it lasted anyway. I still have fond memories of it.

Lessons Learned: Don’t rely on one C60 tape for data storage – especially when you already know it can’t be relied on….

Reporting to LEAs

One of my more tiresome jobs as Admissions Officer at Oxford Polytechnic was to make termly returns to Local Authorities on the progress of students. Their Student Grants (no loans in 1975) continued to be paid only if a satisfactory report was received each term. There were dozens of of awarding authorities and they all sent us separate lists of students. The thousands of students on their various lists were randomly distributed between classes. Each authority had a slightly different type and format of list. Reconciling these from classes back to LEA lists in the timescale available was almost a fulltime job and quite beyond the limited resources we had available.

So I contacted the Oxfordshire County Council who provided me with a computer tape with all the students registered at the Poly and the LEAs they came from. It also included which course they were registered on. From this I made decks of 80 column punched cards, each bearing the student name and course and sorted into course groups.

These elastic band bound decks went to the course tutors together with a very soft pencil and an instruction to carefully mark the cards for the satisfactory students with a tick and the unsatisfactory ones with a cross.

Then it was a simple matter to bundle them into sets and read them back into the computer and prepare neat printed lists – now re-sorted by LEA – to send back to them.

But it turns out that this was not popular. Many of the LEAs complained that we hadn’t ticked their lists and simply sent them our ‘substitute’ (which was very complete of course) which meant that they had to do all the ticking themselves. I got my manager to write back to them explaining that we had met the spirit of the requirement and that we had not enough staff or resources to wade through all their lists by hand.

Lesson learned: A seemingly intractable problem is easily solved with a very simple tool but you need to be confident in the solution – and have a very good manager who can see the point.

Sorting out the keys

When I was a junior administrator at Oxford Polytechnic in 1974, the Head Porter was a deeply unhappy man whose life was made unhappier by students. A particular grief was the annual allocation of lockers and keys. There were several hundred lockers, each with a unique key. The keys were numbered and so were the lockers, but the numbers on the lockers were different from the embossed numbers on the keys which had been bought as a job lot. He had a list of the lockers and the keys for them, but when a key was returned (which they often were) he had to scan all the lists of lockers in turn to find out which key would fit it.

So I took the list of keys and list of lockers and had a computing student write me a sort program which produced two printed lookup lists for the porter’s office – keys to lockers – and lockers to keys. Thereafter the Head Porter was blissfully happy and bought me and the student beer now and then.

Lesson learned: A seemingly intractable problem is easily solved with a very simple tool if you know what tools are available and can find a computing student.