The LOS Archive
The BCL Molecular Series IV Computer System (1978)
LOS, the Leicester Operating System, provided multi-user services on the BCL Molecular range of minicomputers and was in commercial use in the United Kingdom from 8am on Monday 1 November 1976 until the last known LOS user migrated to UNIX sometime in 1999.
The photo above shows the basic installation as promoted by Business Computers (Systems) Ltd in 1978 to companies of moderate size seeking their first computer (click on a component in the photo for its technical details sheet).
LOS Overview at December 1978
LOS - The Molecular-18 Small Machine Operating System
LOS has been developed by BC(S)L to meet the multi-programming needs of Molecular Mk I, 6M, Mk III and Series IV users. At December 1978 it was in use at about three dozen installations, ranging in size from two input stations and one printer (running in 16K word core) up to eight input stations and two printers (running in 32K word core). Larger installations are planned, including remote peripherals linked by the GPO Datel service.
OPERATION
At the input station, under normal circumstances any program may be run at any time, regardless of the activity elsewhere in the system. Programs are called by name, up to four characters in length. If the program involves printout it does not matter if there is not a printer immediately available, because the station “posts” the job definition into a special disc file known as the “print spool” for later processing by a printer program running in the background.
The Mk I technique of prompting the user for the next input has been adopted, with the additional provision of a backspace key for immediate error correction and an “escape” key to get out of tricky situations caused by earlier incorrect input or misinterpreted prompts. Pressing the escape key causes the program to return to an earlier prompt without any further processing, whereupon the escape may be continued until the program is abandoned. Special keys are provided for prompts requiring Yes/No answers.
The system regards all input stations as equal. Critical programs such as month-end updates are normally protected by a password, which does not appear on the display screen when typed at the keyboard. Any program may be run at any type of input station, from the original 8-character keyboard to the 24-line Visual Display Unit (VDU). Since keyboard layouts vary, the control keys have been individually selected for user convenience on all the recognised input stations.
Where VDUs are available the program can do far more than merely prompt for input. Corroborative displays during invoicing might be the customer’s full name and address upon input of the account number, and the full product description with current stock and price information on each line. This may be developed to the interactive operator/computer dialogue as demonstrated by the “alpha-matching” technique for on-line telephone sales. The casual user may "borrow" an idle VDU for a few seconds to carry out a file enquiry (e.g. an up-to-date stock balance with sales statistics) or to request a printed report (e.g. an aged-debt or stock listing).
Because programs do not have to wait for printout there is minimal delay between prompts. The limiting factor is the speed with which the disc access mechanism can handle record transfer requests, and since this is of the order of 20 random transfers per second (D818 & D1600 drives) it requires a very high degree of activity before delays become significant. When a background printer program has completed a report, it flashes a message to this effect onto the issuing station’s display screen. In the case of documents such as invoices this notification is not normally required; instead the computer-assigned serial number will have been displayed to the operator upon posting the document to the print spool.
If the electricity supply is interrupted, when it is restored you just carry on from where you were.
SUPERVISION
The duties of the senior operator require only a small amount of attention during his/her working day. The main tasks are scheduling the workload of the printers and taking the all important security copies at the end of the day.
Print jobs are queued within the print spool according to paper type. Thus invoices will be programmed into one queue, credit notes into another, statements into another. Many jobs require only plain paper, and may all be placed in the same queue. A job is always entered at the end of its queue, and has to wait its turn in the queue. This is normally quite adequate, but just in case you need a report in a hurry the system provides more than one plain paper queue; by using an empty queue you can effectively jump the other queues.
Each input station is provided with a “command” key to enable instructions to be issued to the operating system. Pressing the key turns the station into a temporary Control Console. It does not matter if someone is running a program at the station; as soon as the command has been entered the station returns to the program at the point of interrupt without any loss of data. Commands are used to control the printers. They may be stopped for minor realignment of paper or to change the ribbon, and then restarted. An unintentional lengthy report may be cancelled (but non-repeatable jobs like invoices cannot be cancelled). A change of stationery is notified to the system by commanding the printer to switch to a new print queue; this command may well have been preceded by one or more “Line-up” commands to check the stationery alignment (this prints a few lines of pre-programmed XXX strings). When switching print queues, it is not necessary to empty the current queue; the switch will occur as soon as the current job has been printed.
In case of accidents a reprint capability may be provided for important documents, such as invoices, which cannot be simply re-entered at an input station. Since it is not possible to anticipate when reprints will be required, all are automatically transferred (on printing the original) into a special reprint queue. A standard utility program enables specific documents to be flagged for reprinting by entering their serial number. A reprint may itself be reprinted any number of times; indeed the facility provides a useful means to obtain occasional extra copies of documents.
The operating system alerts operators to matters requiring attention by means of messages flashed onto all screens (the message text “blinks” and is thus readily distinguished from program output). It may simply be a case of a printer or disc drive “unready”, but on the other hand it may be a disc status problem requiring engineering attention or a program halt requiring programmer assistance. The effects of these problems are minimised as much as possible: a disc status is continually retried in the hope that it will clear and the failure of one peripheral should not affect the rest of the system. In particular, a printer out of action does not stop the keying in of invoices, etc. A typical print spool, occupying perhaps 10% of the on-line disc capacity, should be able to hold two days printer workload. Modern peripherals can usually be repaired off-line, whilst a program logic fault can often be investigated and overcome over the telephone. Operations are most vulnerable to disc drive failure, but here the system provides an “on-line security” option under which all master cartridges have a duplicate “slave” cartridge on another drive. Should one drive fail its cartridges may be withdrawn and the system still continue with all files on-line and up-to-date.
Various utility programs are provided as standard: an enquiry to interrogate activity within the system; a facility to send messages to other input stations; a disc security program which leads the operator through the otherwise daunting task of securing both the exchangeable and fixed cartridges on a one-drive installation.
APPLICATION DESIGN & PROGRAMMING
LOS aims to provide maximum return from design and programming effort. In designing the operating system it has been kept firmly in mind that the user will be running Commercial applications on a Small Machine; there has been no attempt to emulate “mainframe” computers and facilities have been included only after a strict assessment of practical need. Almost all operating system services are permanently core-resident and immediately available to the applications programmer.
Hardware upgrades do not involve reprogramming because application programs are independent of individual peripheral characteristics (it is a trivial matter for the software to recognise additional input stations, printers, disc drives). File cataloguing and copying utilities enable available disc space to be re-allocated more effectively, and enable programmers to use test files. Program development is mainly carried out at BCL’s branch offices, where programmers may test different systems on one machine at the same time. The fully tested software is transported (on a disc cartridge) and installed with negligible disruption to your normal working.
Both Direct Access and Indexed Sequential files are supported: individual records may (respectively) be identified by a purely numeric “slot number” or by character string “key” (records within an Indexed Sequential file may be retrieved randomly, by quoting the key, or sequentially in alphabetic order starting at any point).
Each input station and each printer has its own fixed 2K word “task partition” in core, within which the current program and working data are held. The fundamental programming innovation is the use of bit 17 on all subroutine address parameters to indicate that the address is “offset” from the partition base (as distinct from “absolute”). This enables a program to run in any core partition without loosing absolute addressing capability. Any remaining core not required for the operating system and essential workspace (combined requirement is less than 10K words) may be advantageously allocated between specified files as “shared” transfer buffers. If a required record is already in a shared buffer the system does not need to re-read it from disc and the time thus saved can be substantial when processing records sequentially or searching indexes.
The print spool is not intended to contain print lines awaiting printout; this would be far too wasteful of disc space and input station processing time. Only the job definition is held in the spool file; the printer program sets up and transmits the print lines, accessing disc files as required. File updates may be carried out either when the job is entered at an input station or when the job is printed. The standard practice is to defer updates until printout unless there is an overriding requirement for immediate update (e.g. real-time ordering from stock). This simplifies the programming; e.g. it is relatively straightforward to allow the operator to review on the display screen an invoice just entered and perhaps make insertions, deletions and amendments before posting the job into the print queue.
Other Resources on this website
M18 Hardware Overview (hardware described for the programmer)
Software Development (how we wrote programs in Machine Code for LOS installations)
LOS Programmers' Manual (a reconstruction of the first edition)
See also
BCL Molecular 18 (Kevin Murrell's website)
