Memories from BCL employees
Miller Houston recalls...
I worked as a service technician for BCL’s Bristol Branch in the early 70’s. IBM Typewriter training was in Manchester and was led by Phil Wise. A guy called Fred from London was on my course. After a night out in Leeds he was henceforth called PCF (Poor Cold Fred) because he missed our return and spent the night on a bench in Leeds railway Station.
I was eventually moved to live in Miskin, near Cardiff to Support installations at Welsh Glass (Susie) & Reardon Smith (Multi-Susie) in Cardiff plus Triumph Business Products (Multi-Susie) in Merthyr Tydfil.
After about 2 years I was transferred, with my wife to BCL (Canada) in April 1974. There I supported Susie, Multi-Susie and M18. After the crash in June 1974 I provided support to these customers privately.
Hugo Moreau recalls...
I was a Molecular 18 systems programmer at SMO BCL in Brussels 1972-1974. Came to Brighton on a regular basis. Many years later I was "EDP Manager" at Dekeyser Thornton in Antwerp who ran the largest Molecular outside of the UK.
If I remember well, my first Molecular was a core memory machine, would you have a picture of some core memory somewhere? From my side, I can dig up some neatly handwritten machine language coding sheets for various subroutines.
Do I still remember the boot sequence, entered on the sticky switches every morning and every time the blasted mole would hang ?
5
213777...
Matthew Clark recalls...
My father, Gordon Clark, died prematurely in 1990 from cancer, and I don't know who gave you Susie. He started designing computers in the late 1950s. He and three friends set up a company called Systemation in Brighton in about 1963. They first developed a machine called Betsie, which was used by betting companies. They went on to produce computers called Sadie and Dotty. The company went public in, I think, 1969, and became Business Computers Limited (BCL) and they produced Susie. The next computer was Molecular 18, which was exhibited at an exhibition in London in 1974. Unfortunately, IBM had also developed a computer with a similar specification, but cheaper. Then there was the financial crash in 1974; then banks withdrew loans and BCL went bust. In the 1970s my father also designed a computer with a 'round' screen, like the Apple of about ten years ago. My mother and I plan to visit your exhibition in March.
Ian Dennis recalls....
I worked for BCL (in Bristol) straight after University (1971). I was hired by David Evans, who was the Bristol Branch Manager, who tasked me with writing a simple calculator for the Susie. When I had completed that, David kept asking for new features, until we had turned it into a full-featured invoice production program. During the 3 ½ years I was with BCL, I wrote all sorts of financial applications for the Susie and Multi-Susie – Sales Ledger, Purchase Ledger, General Ledger, and Payroll.
We even wrote an early EPS application which was (in those days) called “Raw Material Explosion”. Part recipes were held in a huge flat file and each manufactured product or subassembly would have a minimum quantity, a quantity on hand and a batch manufacture quantity. The program would start with the very first product on file (the one with the lowest product number) and see if there was enough quantity [quantity on hand > min quantity]. If not, the program would calculate the number of batches needed to make enough and use the recipe file to print a manufacturing/assembly order form, and down-date the quantities on hand of the component products stored elsewhere in the file. The application would then update the next product, and so on until it got to the end of the file. If at any time, the application had reduced the quantity on hand of a product with a product code lower than the one it was processing (for example, if you needed 5 of product 000024 to make a batch of product 000076, so the application reduced the quantity on hand for product 000024) then it would set a flag. At the end of the file, it would check to see if the flag was set and, if it was, it would start all over again at the start of the file. Sometimes the raw material explosion would take hours, even being run overnight.
I spent most of the first 2 years programming Susie and Multi-Susie, and debugging problems with existing Sadie applications. The Sadies had hard-wired programs where you specified which program instruction should be executed at which program step by tracing the copper strips representing instructions on one side of a programme board, and the copper strips representing steps on the other side of the board (and at 90 degrees from the first) and, when you got to the junction of one with the other, you drilled a fine hole through the board, pushed what looked like a paper clip through the hole, and soldered both ends onto the copper strips. When you changed a program step, you were supposed to un-solder the wire and pull it through, but many programmers and hardware engineers simply cut through the wire, leaving the ends showing … which made it almost impossible for someone else to de-bug the programme in the future because many boards would have locations with what seemed to be two or more programme instructions at the same programme step!
I remember when Britain officially went decimal. Susies and Sadies were able to handle both sterling (£sd) and decimal (typically $¢) by simply flipping a switch (an actual toggle switch inside the processor cabinet) to divert program flow from one board to another, and a different set of instructions. When d-day came along, they very simply handled £p by flipping the switch and keeping it flipped.
When the Molecular 18 (quickly nicknamed the Molly) came along, I went to the software factory in Portslade for a training session. As always, it was in winter (cheaper hotel rates) and I stayed at St Catherine’s Lodge, known to one and all as “The Nunnery”. A Greek girl, Toni Coudinaris, who was a programmer at the Birmingham office, was also on the training session. Most of the training consisted of understanding the input/output handling because it was at the time when one of the operators was actually entering something, or when something was printing out, that the computer had spare cycle time and could process another operators interrupts. At that time, the Molecular 18 was being sold as a multi-operator, single-function computer. For example, you could have 4 operators on it at the same time, but they’d all have to be running, say, payroll. When we got back to our individual branches, we started thinking about that limitation and realized we could remove it if we programmed the interrupts differently. We each developed (at great expense to BCL) very crude operating system kernels.
BCL sent one of the top programmers to each of the branches to pick our brains and return to Portslade to design a new operating system using a super kernel which included record queues with locking. The Molecular 18s were then sold with OS-I (single-function) or a much pricier OS-II (multi-function) and salesmen had to submit quotes to Portslade to determine which OS to include. Sometimes they got the equation hopelessly wrong – possibly one of the factors that took them towards receivership.
By this stage I was dating Toni – traveling up to Birmingham every other weekend, or she would come down to Bristol. After a few months, she informed me she was moving to Brussels to head up BCL’s programming operation there. For a female back in the 1970s, this was a great honor, so we said goodbye. Although I had done a lot of good work on the Molecular 18, I was being used as the Susie/Sadie expert in Bristol, rather than being allowed to program Molly and so, coupled with breaking up with Toni, I was somewhat disillusioned with BCL and so moved on.
30+ years later, I’ve held many software related jobs (QA Manager, Help Desk, Systems Analyst, Business Analyst, Project Manager, Account Manager, Trainer, etc), and migrated to USA. Currently, I am a Senior Applications Developer with Aerojet (an aerospace company and major contractor for NASA) and live happily in California with my wife and cats. But I have never forgotten my journey from academia into the real world and the help given to me by BCL and, in particular, by Di Evans.
Julie Cheeseman recalls...
I joined Business Computers at Portslade as a trainee programmer in August 1973.
Here are some rough notes of memories as they've been occurring to me.
Three week training course there learning how to program their Molecular 18. Good crowd of fellow trainees, did just about every broadsheet newspaper crossword between us each day.
Some must have also continued at Portslade, others went elsewhere? Can't remember specific names from then.
Worked on Payroll package I believe. Tax and National Insurance routines. Then diverted onto special project for a Vero sub-office in Paris who had been bought an upgrade by the parent company for their machine. 4K of extra storage, bringing the total to 12K. Archaic, even for the times. They wanted to expand their stock control file record size and have it moved into the new memory where it was kept in a fixed position. Only input hardware was a teletype, only output a printer and paper tape. Critical to get it right first time as else all would have to be typed in from scratch. Got a trip there with the project manager Robin, all went perfectly, had a few non-tourist meals with the workers. Made redundant in the first wave in March 1994 - last in, first out.
Heard that rest of people lost their jobs later that year. Might have been told story years later when fellow employee, Brian Smith, joined ICL in Bracknell. Other BCL memories rather vague, two very good technical guys were Steve and Terry?
Started work with Plessey at Poole June 1974, defence project on their own small computer, can't remember its name. August 1976 transferred to Plessey Addlestone working on CAA Radar project, never got to see system at West Drayton as mainly worked on modifications to system software on the PDP11. Not a happy project.
Joined ICL at Bracknell June 1977. Worked on DME for 2950, disc microcode mostly. December 1980 transferred to work on SNA project for System 25, mainly on user interfaces but also used small IBM mainframe in Bracknell's basement.
Kevin Murrell recalls...
At one point, and it probably happened every year, I was sent off to do the rounds of customers to update their payroll. No real issues, just turn up with the disk, copy the sectors down to their system. and all done. One job was to visit Jackdaw Tools and upgrade their payroll. I completed the job and they ran their tests. Some people rushing about, but eventually someone told me all was OK and to go home. I later learnt they had previously had some bespoke mods done to change the default printer queues for the payroll. Aparently, when they ran the payroll, all the payslips printed out on the trade counter! Someone at the office must have received a serious shouting at, but I was never blamed. I think I can thank Jerry Hedges for protecting me!
John Dunn recalls...
I worked for BCL from October, 1973 to June, 1974. Initially this was at the Gateshead branch on Tyneside where I worked on the Mark 1 which was programmed in machine code via the control panel switches. I was sent to Portslade, Brighton the manufacturing centre and where the system software was developed. I did a 2 week course for programming the Mark 2 machine. The Mark 2 had an assembler language. I was one of three programmers and a systems analyst / project manager working on a ship's management accounting system for Common Brothers In Newcastle upon Tyne. The team consisted of Alan Davidson, Peter Mooney, Paul Moorhead and myself. I left BCL to work for Common Brothers and developed the system for two years longer. Common Brothers were taken over at some point in the early eighties by a Norwegian Ship Owner.
Steven Kay recalls...
I worked for Computer Field Maintenance in Manchester from 1973 to 1979, firstly onsite at Salford University, then on the Mobile Team and then onsite at Shell Wythenshawe. Our Regional Office was initially in Stretford Road, but then moved to Cheetham Hill when Computer World Trade Ltd. (the parent company of CFM) took over BCL, who I believe had got into financial problems. I remember that the Cheetham Hill office was North of Strangeways Prison and Salford Van Hire. Looking on Google Maps, I think it may have been in Broughton Street. It had previously been BCL's Manchester office. BCL kept the front showroom (which had a Molecular 18 in it) and CFM took over the offices and workshops behind.
I never actually worked on a Molly 18, but I did work on the earlier Sadie and Susie machines - mainly fixing problems on the IBM Selectric console.
Michael Benn recalls...
A long, long time ago, I worked as a Computer Service Engineer for Systems Reliability, who had an office in Newcastle and who serviced all sorts of computer systems and peripherals, so I spent many a happy day wandering around the North East in my company Astra fixing 8" floppy drives, shuttle printers, telephone logging systems and one lonely Moly 18, which ran all of the payroll, stock control and invoicing for Bretts Oils in Gateshead.
The Moly was an early one, maybe a Mark Two from memory, with wire-wrapped boards and core-store, and it still had the manual switch panel with switches to set up programme pointer and data, and I still may have the muscle memory to allow me to programme the boot-loader code by resetting the programme counter, flipping the 15 or 17 switches to represent a word of the programme, then flicking the Load and Increment button to load that word into the memory and increment the programme counter ready for the next word (which involved more switch flipping). Once the loader was loaded up, you'd load some paper tape into the reader which contained the second boot loader that allowed the Moly to accesss the Phoenix disk drive, flick the 'Execute' (?) switch and the The Moly would spool through the tape, spin up the disk drive and away you'd go. I spent some very tedious hours applying constant update modifications from Molecular to the various boards early in the morning or at weekends so that the Moly could be back up and running within office hours for the staff to use, and still may have my wire-wrapping tool secreted somewhere :-S
I believe that the Bretts Buiilding is still there on the quayside in Gateshead, but hasn't been in use for a long time. Bretts website says that they are now based in Warrington, but you might be able to get hold of someone who used to be at their Gatehsead office who might know whether the Moly is still there and might be available for salvage.
Lynda Osborne recalls…
I began working for Business Computers Limited around October 1968, when I was 19. I started work as a Secretary, with the promise that I could learn computer programming. It was at the Tottenham Court Road office in London, where the salesmen were. It also had a small programming department. I worked for Derek Hough, who was a great boss, he saw the funny side of everything and made us laugh. He was about 36. Shortly after I began there, we were informed that the programming department was moving to Brighton and we had to move there too. I moved down there in March 1969. The factory was in Portslade and the programming department was moved there and expanded. Lots of the young people moved down from London at the same time and we met outside of work socially. There were about 26 people in the department including 10 new people. Mick Moorhead was Head of the Programming Department and ran courses to bring new programmers into the company. If people did not pass the tests, they had to leave. If they got really good marks for the Sadie course, they moved on to a Susie programming course. A Sadie took about I week to programme, and had circuit boards. The Susie took about 6 weeks to programme and had a large magnetic drum for memory.
After I kept reminding Derek that I wanted to be a programmer, and had found someone to take my place, I was allowed to go on a programming course. I did the Sadie and the Susie courses. We programmed in machine language. I think the calculations were made in a register (temporary memory) that had four compartments at the top and four at the bottom. I think 02 was a beta shunt. We subtracted numbers in the last two compartments to test for negative, to work out if the bottom number was larger than the top number.
I was a computer programmer/systems analyst. The salesman would tell us the customer's requirements, and we would make flowcharts to show how we would programme them. We did things like invoicing, stock control, and payroll. I think at the time they were planning a Sadie 5 and a multi Susie. Punch cards and paper tape were used for extra memory. Sometimes we visited the customer, I remember going to Birmingham and Manchester.
I had always wanted to live in Canada, and when I heard that BCL was going to start selling the computers in Vancouver, I asked for a job over there. In October, 1970 I moved to Vancouver and started working at M.P. Hofstetter (B.C.) Ltd. I worked for Max Muellder, and we did sell some computers. But I think we had competition from IBM and it was hard to compete with them, with British imports. The computers were expected to do more than in England, but I did programme them for it, and I was told that I was programming the impossible! Eventually Max left and they stopped selling them. I worked there until March, 1972. I remember visiting customers in Penticton, and also Westco Inc. in Vancouver. I think my starting Salary in London was £12 per week, which went up to £20 by the time I left, and then doubled in Canada to about £40 per week.
Rena Brewin recalls
We had an interesting tool to help with the programming, loads of lego bricks that had been printed with the different octal codes, and rather than write the programs we built them with the bricks in trays that would hold about 4ks worth of code. Then when we checked them over and found errors we could easily pull apart the bricks and add, subtract, modify the code. Remember we had to get it exactly right before the machine was hard wired, hell to pay from the engineers if they had to rewire software errors.
John Marchant recalls
So we looked around for a second-hand computer we could afford. We had done some programming for a computer maintenance firm: and they heard of this Molecular 18 in a warehouse in Paris. It was nearly new, and hardly used. Six months later the necessary paperwork and re-import licence were completed, and the beastie arrived at our premises.
Money was raised by a bank loan, and for 7,000 pounds (plus transport etc.) we got the processor; one hard disk drive which held an exchangeable single-plate disk cartridge and a fixed disk on the same spindle; two or three more disk packs; a VDU control console; a card reader; and a small Centronics line printer.
For a further sum which I forget, we also got a larger 'barrel' line printer and the special buffered interface it needed. This was a bargain and allowed us to do long printing runs over-night with very little trouble. But we couldn't afford a stacker or decollator (to separate the carbon copies): so we had to take turns on the night shift baby-sitting with the printer. This involved tidying the paper output at intervals; removing this every so often and decollating by hand. You could tell from the sound it made whether anything was amiss, while you ate your sandwiches, did your cross-word or a bit of urgent programming. I used some of these night shifts to work through a disassembly of the operating system.
The processor, disk-drive and power units were in 3 matching cabinets about 4ft high, 2ft wide and 3ft deep. Much of the power cabinet was empty, while the bottom half of the disk unit had a large drawer which could hold 2 or 3 disk packs. We called this the oven, and in fact it kept disks warm and ready for use. After a while we found this made no difference, and stopped using it.
The memory size was 32K, on several plug-in boards some of which were 2K and others 4K. The edge connectors gave a bit of trouble and had to be cleaned now and then.
The 3 cabinets were WATER COOLED! Inside each one was a sort of car radiator with a fan. They were plumbed in, using high-pressure rubber hoses to connect them to copper piping along the wall behind. This was an outside wall, and in the car-park outside was the circulating pump, electrically driven, which also heated the water in winter and cooled it in summer. This pump would fail about twice a year, and a red light would come on at the switch inside the room. We then had about half an hour in summer to do something about it before the computer overheated. (In winter we could just take off the cabinet sides and continue running.) So we would put 'Plan B' into action. We turned a couple of stop-cocks and ran a garden hose from the gent’s toilet down the passage and into the computer. The outlet went through the wall and down a drain. On one occasion a central heating pipe came apart while we were all out to lunch. We returned to find a flood, and the room full of steam. My boss remarked, 'I always thought it was steam-driven!'. Happily, our new stock of paper had been stacked on shelves.
The Molecular was built in England by Business Computers Ltd of Brighton. It really was an outstanding design which deserved better recognition. I don't know when the first ones were made: I suppose about 1970 or so. But the firm had financial problems and eventually went under. Not many machines were sold.
Its best feature was its incredible multi-tasking operating system. Again, I don't know how many jobs it could do at the same time: more than 6 for sure. I did a disassembly of the operating system and learned how - at each hardware interrupt - all details of the task in hand were stacked; and the job list was scanned, using a priority system to determine which task to resume. The limit was probably the size of the stack area. Factors determining priority included the priority allotted by the operator, how long since a task last had a bite of the cherry, what type of input/output device was involved etc. The control console always had top priority and received instant attention. This was followed by the disk controller which might be completing a ‘seek’ and wanting its buffer emptying or filling. We often had 3 tasks running together - a long printing run from disk, through a formatting program to the printer interface: a programmer doing editing or assemblies: and up to 3 clients putting in data from a network, via modems. The clients shared one program and one data input file on disk. Data was validated as it came in, and tagged with the user ID. Each evening it was processed.
We gave clients a high priority and the programmer a low one: but this seemed to make little difference. We did find that the clients must have higher priority than the printing program, or they noticed degradation in service.
Programming was all in assembler, which was a very nice 'language' to use. Particularly useful were the two accumulators A and B which meant less juggling with your variables. Also there was an excellent and versatile file handling library. Several file types were fully supported, including direct access, sequential, indexed-sequential, and a wonderful idea - the 'Pool' file on which several users could do their own thing in separate partitions. You could say (program) 'give me a free record', or 'I've finished with that one, return it to the pool'. When you used and wrote a record, you formed your own linked lists and you had to maintain your own pointers and index. But indexed-sequential was a dream, with indexing all done for you to your own specification.
The software manuals were very good, with plenty of examples: and there was a good range of utility software, though of course we wrote most of our own subroutine library. There was an assembly linker which made it easy to link program modules together.
File dumps, diagnostics and memory dumps were always printed out in octal which one quickly became used to reading. Octal also gives one a good mental picture of actual binary values. Naturally the company bought a TI programmer's calculator, which I still have - as one of the three share-holders and directors of the company when it wound up! We shared out perks of that kind; and I also won a swivel chair and my present sitting-room carpet.
Joe Templeman recalls
As a LOS programmer, all that I needed to know was: is it a Mark 1, a Mark 2 or later than a Mark 2. I only ever implemented LOS on one Mark 1, but it enabled me to spend two weeks in Brighton in the 1976 heatwave summer, the factory being the only place where I could copy LOS from a D1600 cartridge onto the Mark 1. The Mark 1's instruction set was slightly smaller than its successors (no multiple shifts/rotates).
The Mark 2 implemented the Base and Limit registers and came with a Brighton developed operating system to support them, otherwise as far as I recall the instruction set was the same as its successors. I attended a Mark 2 programming course at some point shortly prior to the Philip Harris project. It was clear that the function of the Base and Limit registers was to provide a multi-tasking environment by protecting each application's memory partition from access by other applications (tasks). Thus an application could happily crash itself but not the whole system, this apparently being perceived as the most serious problem on the Mark 1.
Unfortunately inter-task communication was not perceived as important in the design of the Mark 2 OS, to the extent of not being practical as far as I could tell (I can't recall if Zero Page could be shared or not, perhaps each task had it's own Zero Page). By the time we started on Philip Harris I knew that I could provide what was wanted provided I was not restricted in any way and I was keen to get on with it. In other words, the function of an operating system is to enable, not to inhibit, the imagination and creativity of the programmer. So I was somewhat surprised one day when Chris Green came into the office to tell me that a Mark 2 was to be delivered to Philip Harris! Luckily he knew too that this was a non-starter so did whatever was necessary and I heard no more about it.
Kevin Murrell recalls
I was dispatched off to a customer to do an upgrade, and it's the first time I had seen a Mk IV with a DD1600 (Hawk) Drive and a Multi-Platter D800 disk drive. Each surface in the D800 was viewed as a separate disk. They backed up each disk in turn on to the exchangable pack onthe DD1600. It must have taken ages. I was warned before I went: 'Don't tell them that most of the disk space is empty - they could run the whole lot on a single Hawk drive!'
I imagine that a huge expansion in usage was expected, but didn't happen.
Joe Templeman recalls
At a time when most computer systems had a "use by" date of a year to two, many Molly owners held on to their system for as long as possible - why? Perhaps because its capabilities were aimed precisely at their level and were wholly relevant to their requirements. People living in their world, not in some remote corporate or academic tower had designed their system. When their needs grew, the Molly came up with a trick or two to break through what had previously been considered its limits.
In this environment assemblers, compilers, "high-level" languages and all such technicalities were not an issue. What mattered was performance. Better reliability would have helped (but this was before the Japanese showed us what could be done, so nobody expected perfection). It wasn’t until the 1990s that Unix boxes began to match the Molly for performance, and thereafter reliability became the issue.
LOS was designed on the principle of co-operation, both with the Molly’s hardware and with the programmer, to produce what was wanted. In return it was not an option to divert resources to protect programmers from themselves (or from their colleagues). This didn’t just work; it often opened up possibilities well beyond what had originally been proposed. Of course, some programming developments were justified as they improved productivity. Such as the ability to load or edit a program while seated at a keyboard, rather than by flicking it in bit by bit standing at the control panel switches.
Elsewhere in the computer industry, manufacturers were rapidly evolving hardware to meet the perceived needs of the software developers. These people would always want more, no matter how much you gave them, so the industry was on to a sure thing, which continues to this day. At BCL we wrote our programs in pencil on foolscap coding sheets. Each of these sheets held 64 steps (instructions), and 32 sheets were needed to fill a whole Task Partition (2K words). If you laid these out on the desk, it looked a formidable amount of coding space (especially when you recall how much rubbing out you did before it was finished) - who could possibly need more?
At one extreme we might cram several little programs into one "module" and at the other a complex program (invoicing was usually considered "complex") could span several modules by fetching in the relevant code as required. Who could possibly need virtual memory when managing real memory was so easy? Also, the Task Partition had a specific layout, and we had to allow for workspace for our variables, so that not all of the partition could be filled with code. Incidentally, pre-defining the layout greatly reduced the amount of parameter passing between subroutines. Several operating system services took no parameters, e.g. the single instruction "JSBR IZ 1651" was sufficient to "spool and post" a simple job to a print queue. Knowing where our variables were in the partition meant that we could find them, watch them and even change them by running the programming program from another keyboard. We could modify the very code too, even whilst it was being executed! Others (encumbered by text editors, compilers and linkers) could only dream of such capabilities, but we had it all!
The processor’s instruction set barely changed and neither did its speed. Memory reference instructions took 2.4 microseconds in the 1970’s and they still took 2.4 microseconds in the 1990’s. Actually, 2.4 microseconds were pretty good for the 1970’s. Although we didn’t realise it we were already using RISC technology (albeit because the Molly never "progressed" to micro-code).
The 1K word page-addressing scheme never changed either. It is this aspect which stymied the development of an effective Assembler (let alone high level language). Try it and you’ll soon get into big problems! Whilst other manufacturers implemented more flexible addressing schemes in hardware, BCL meandered occasionally down this software dead-end.
The "Metacode" character set was an interesting case of making full use of the seventeen-bit word format. The cube root of 217 is just over 50. This means you can pack three characters into one word if you restrict the character set to 50, which is enough to be useful (in the 1970s respectable computers disdained lower case lettering anyway). To pack three into a sixteen-bit word you must restrict the set to 40 characters.
The hardware implementation of the "Greater Than" flag deserves comment, as it chose to ignore the sign bit thereby introducing inefficiency in software when working with signed numbers!
There are a couple of switches on the control panel that deserve "special mention". Interrupt if MA=SW allowed us to set a breakpoint whilst debugging a program. Alternatively, it could just as easily catch any read or write of a program variable. I have yet to meet any modern debugger offering this sometimes very useful service. The apparently useless (to software) Continuous Interrupt switch found its niche as a mains-off emulator. The real mains-off interrupt was supposed to trigger when there was enough juice left for maybe 300 instructions (I forget the exact timing). When it actually triggered depended on the setting of a variable resistor somewhere. Occasionally this resistor would be wrongly set and the juice ran short, so the Continuous Interrupt switch offered a stopgap means to switch off until it was fixed (a job very definitely left to an engineer). In the 1970s we always advised switching your Molly off at night: someone did leave one running on a first floor and next morning the staff found it in the basement with their smouldering building around it.
Even with the mains-off interrupt triggering correctly, LOS had to keep all its interrupt handlers short in case a mains-off became pending (it was not practical to interrupt an interrupt handler). Watching the system pick up after a power cut was quite a thrill, so how did it work?
Remember the trouble we could have with the track alignment on disc cartridges? To install our programs on the customer’s Molly meant we had to travel there and hope the cartridge we’d brought with us would be readable on the customer’s drive. If not, I recommended going for a walk outdoors, taking the cartridge with you. Slapping it quickly back onto the drive usually did the trick.
Almost certainly the following have grown further from the truth over time...
BCL produced a sales package for Livestock Markets (farmers bring cattle to market, selling typically for cash etc). It had been written under LOS, so John Griffiths and Anne McGrory travelled to the market, restored their backup disk and were ready for users to start the market. (LOS has simple feature that if you booted leaving switch 6 up, it would restore the backup. Clever!) At the end of the day, after all the sales and cash transactions had been entered, and all the reports printed, it was decided to do a backup. Quite why John needed to bootstrap the machine, and quite why he didn't notice switch 6 was still up, is not known. The Molly worked perfectly and restored the original backup. John and Anne spent the rest of the evening typing all that information back in!
Certain Mk5 backplanes had slightly awkward edge connectors on the PCB backplane: MIL spec connectors had been installed in error, and such was the force required to push in the large M18 circuit boards it wasn't always sure which might snap first.