Leo III Reminiscences Part 2

Program Suites

The programs for a particular customer were arranged in a 'suite'. This usually consisted of an input program, a sort, the main processing program, another sort, and then a print.

Input

For a payroll suite, this would contain data like hours worked that week per employee, etc. The input data was punched onto paper tape by a Data-Prep group. This was a team of about 40 (all female, never saw a male DP). Each set of data was actually punched twice. The first time it was punched onto yellow tape, then the yellow tape was fed into a verifying machine while it was punched a second time onto white tape. The verifier would compare what was being punched with what was on the yellow tape, and stop if there was a discrepancy so the DP could fix the discrepancy. These DP girls were amazing - they could carry on full conversations while punching and not miss a beat. As a fresh faced 18 year old, it was quite intimidating walking into the room to collect the paper tapes, and have all the conversations stop so they could check you out.

Sorting

The tapes from the DP group were read and the data written to a mag tape, using the first program in the suite. This mag tape was then used as the input tape to a sort program, that sorted the data into the right order for processing (duh). The standard sort program (07004 if I remember rightly) had an input tape, an output tape, and two work tapes. The data was read from the input tapes onto the work tapes, and then the work tapes were successively read/written and rewound while the data on them was progressively sorted into order. Usually it would take several read/write/rewind passes before the sorted data could be written to the output tape. More intensive sort jobs could be done using program 07006, which used 3 work tapes. Sort programs were what were running when you see the old computers in movies. They were quite impressive to watch, as all the tape decks would be in action, sorting the data between them.

Main Processing

This program read the tape produced by the sort program, and did all the calculations and number crunching on the data. On a typical payroll suite, this would do all the pay and tax calculations for each employee. The calculated data was written to an output tape that was then sorted again by another trip through the 07004 sort program.

Printing

The output tape from the sort was then read by the print program (06060) and printed onto either continuous plain paper, or continuous special stationary (like paychecks). The printers were 120 0r 160 column drum printers. To start with there used to be carbon inserts for 2 or 3 part printing, but later they introduced new-fangled carbonless paper. As operators, we would have to take the boxes of printed paper and 'decollate and burst' them. This involved a complicated an temperamental machine that would feed the continuous paper through, and simultaneously remove the carbon and split the paper where it was perforated into individual pages. I never managed to get away without getting covered in carbon ink from sorting out paper wrecks.

That's probably enough information for anyone to take in one sitting. For anyone still reading - thanks for indulging me :-)

Leo III Reminiscences Part 1

Operators Console

The console had a typewriter that the system used to communicate to the operators. It was used for output only, the operators used a bank of switches to issue commands to the system. There were 3 groups of 4 toggle switches, each group representing a hexadecimal (or more precisely an EBCDIC) number, and a spring-loaded 'Stack' switch that you pressed to execute the command entered on the 12 toggle switches. So a command would be something like entering 4-0-2 on the 12 keys, and then press the Stack key to execute it.

Commands

The 4-0-2 command was used to run a program (they were called programs rather than 'apps'). You would load a tape containing the program code on a mag tape deck, load a paper tape with the program name, serial number, and run number into a tape reader, and then execute the command. This would load the program from mag tape and run it.

Strictly speaking, the middle zero in the 4-0-2 command was a 'route' number. Each set of peripherals were on a separate channel, with each device having a rotary switch that you could set to an address 'route' within that channel. The nearest tape reader to the console was usually set to zero, hence the default 4-0-2.

A 1-0-3 command (I think) was used to load a 'Release Tape Index' (RTI). The RTI was a list of mag tape numbers that were OK to write on. Each tape had a serial number, and a corresponding card in a card index. The card was manually updated with details of what data was written on the tape. When the data was no longer needed, the tape was 'released', the tape number punched onto a paper tape in batches of 12 at a time, and then read into the system using the 1-0-3 command. When you loaded a mag tape, the system would read the serial number on the first few blocks, and would check it against the list of tape numbers from the RTI you had loaded. It would not write on a tape without its number being on the RTI.

A 3-0-1 command would do a core-dump to a mag tape. This was later printed (remember there were no monitors back then) and used by programmers to debug errors.

There was also a command for changing the priority of a program compared to other programs that were running, so you could get the best timesharing performance. I can't remember the command number for that though.

Ah nostalgia...

When I left school in 1968, my first job was as a computer operator on the Leo III at Hartree House. 22 microseconds to read a memory location (this was 3/1 - the first Leo III built, later models had a 13 microsecond read time). Four banks of core memory, 8 tape decks, 2 paper tape readers, 2 card readers, 3 printers, too early for disk storage. Programs were written in Intercode (basically assembler code) or CLEO (Clear Language for Expressing Orders). The system ran 24x7 doing bureau work, payroll runs, etc, for customers. Able to timeshare up to 4 apps at once, memory permitting.

I still remember some of the commands we used to toggle on the console keys, but can't remember what I open the fridge for. Go figure...

@Joey

Ah, those 50 wire ribbon cables, LUN number DIP switches, and SCSI terminators. Those were the days.....

Article title should read....

Guesses by journalists about Apple cloud strategy change with the weather

@S2S

Ahhh, the old "I can't think of a use for, or can't afford a tablet, so that means they're useless and nobody in the rest of the world needs one" logic.

Based on your own argument that only idiots buy tablets, you would seem to be a prime candidate for one.

Some places you need a gun

As a non-gun-owning ex-Pat Brit who now lives in the US, and not a fan of widespread gun ownership, I have to concede that there are parts of the US where having a gun makes sense. Montana is one of those places. The wildlife in those parts will eat you if they get the chance. You can't fight a bear/cougar/pack of wolves without some kind of firearm and expect to survive. Even in the suburbs it's not unknown for hungry bears and cougars to raid the garbage bins in your back garden, or break into your car to get groceries. As much as I don't like general gun ownership, if I moved to Montana I'd be down the local RS or gun store buying weapons for myself and my family and booking us into a firearms training class.

Don't forget the oceans

Apparently as the oceans warm up, the water can't hold on to as much CO2 (much the same way as cold fizzy drinks hold on to more gas than warm fizzy drinks). So as the oceans warm they will release more CO2 into the atmosphere, which leads to temperature increase, which leads to the ocean getting warmer and giving up more CO2, etc.....

Good timing...

Killing the bug just before the pwn2own contest

Tough hill to climb

This means the first release will be almost 2 years later than iPad, and one year later than Honeycomb, both of which have a huge lead on apps. And by then RIM and HP should have shipped their first tablets. Should be interesting to watch.

Trojans are not viruses

There isn't an OS on the planet that is secure from Trojans. As long as you can trick a user into authorizing a piece of malware, then you're off to the races. UNIX and Linux systems will want a root password to run anything that infects system files, if you enter the password then you're gullible or stupid. Viruses will infect without user authorization. Unix and Linux systems have never really been troubled by viruses because of the need for root passwords to do any damage, and later versions of Windows are also trouble free providing they're kept patched. Trojans are a problem for everyone.

So what OS are the zombie bots running?

Anyone care to hazard a guess what percentage are running WIndows, Linux, and OS X?