Bob Eager
2024-02-22 10:38:27 UTC
In my first year as an undergraduate, we were taught BASIC - it was the
only language available online, as opposed to in 'batch' mode via punched
cards and printer (I ended up teaching that course myself some years
later).
After a few weeks of BASIC, I decided to learn assembly language for the
mainframe - an ICL 4130, which was a 24 bit word oriented machine with
96kW of memory. In practice, the best type of target program was a
'subsystem' for KOS, the online facility. Users had only 1536 words of
working memory (excluding the code itself), and about 600 of those were
used for the I/O system and other services. Nevertheless, I wrote a simple
linear regression program (mirroring the one we had done in BASIC for an
assessment).
Running a subsystem was something for which one had to get permission, as
a fault could stop the online system (although a simple operator command
would continue it from the stop point). Once I had proved myself, I was
allowed to write more programs.
However, I (and others) became increasingly ambitious, and did some
naughty things. Fairly early on, I 'acquired' a copy of the (assembler)
source code for the online system, KOS. My first venture into the
'naughty' area was to write a program that would simulate the effect of
Ctrl-C (well, its equivalent in those days) on a specified terminal. I was
able to do this by modifying a status bit in the terminal multiplexer
device driver (I had previously found a way to write anywhere in the
entire machine's memory, subverting the memory management). Later, I
discovered that I could remotely log someone out as well.
Various other programs followed, and a few of us decided it would be a
good idea to be able to submit batch work to the batch queue via a
terminal, instead of on punched cards. One could then use other languages
such as Algol and FORTRAN, which were not available in the on-line system.
This wasn't too difficult:
- Load a program that inserted itself between the executive card reader
driver and the batch system.
- Fulfil requests for 'next card' by getting one from the card reader
driver and passing it on - until an end of job card was detected.
- Pass on the end of job card, but follow it with card images taken from a
previously prepared file.
- At the end of that file, reconnect the batch system to the card reader
driver and exit the program.
It worked perfectly. Except ... when the computer operators came to
collect up all the punched cards for the completed jobs, and reconcile
them with their associated printouts ... there were no cards for one lot
of printout! They spent some time looking for them, and to avoid further
suspicion, action was taken. Cards were quickly typed for the 'phantom'
job, and dropped down the back of the table that held the trays of
returned cards. Then: "Oh look, what's that down there?".
We got away with that one. Over time we encountered restrictions on
running subsystems, and had to write a loader. That is another story.
only language available online, as opposed to in 'batch' mode via punched
cards and printer (I ended up teaching that course myself some years
later).
After a few weeks of BASIC, I decided to learn assembly language for the
mainframe - an ICL 4130, which was a 24 bit word oriented machine with
96kW of memory. In practice, the best type of target program was a
'subsystem' for KOS, the online facility. Users had only 1536 words of
working memory (excluding the code itself), and about 600 of those were
used for the I/O system and other services. Nevertheless, I wrote a simple
linear regression program (mirroring the one we had done in BASIC for an
assessment).
Running a subsystem was something for which one had to get permission, as
a fault could stop the online system (although a simple operator command
would continue it from the stop point). Once I had proved myself, I was
allowed to write more programs.
However, I (and others) became increasingly ambitious, and did some
naughty things. Fairly early on, I 'acquired' a copy of the (assembler)
source code for the online system, KOS. My first venture into the
'naughty' area was to write a program that would simulate the effect of
Ctrl-C (well, its equivalent in those days) on a specified terminal. I was
able to do this by modifying a status bit in the terminal multiplexer
device driver (I had previously found a way to write anywhere in the
entire machine's memory, subverting the memory management). Later, I
discovered that I could remotely log someone out as well.
Various other programs followed, and a few of us decided it would be a
good idea to be able to submit batch work to the batch queue via a
terminal, instead of on punched cards. One could then use other languages
such as Algol and FORTRAN, which were not available in the on-line system.
This wasn't too difficult:
- Load a program that inserted itself between the executive card reader
driver and the batch system.
- Fulfil requests for 'next card' by getting one from the card reader
driver and passing it on - until an end of job card was detected.
- Pass on the end of job card, but follow it with card images taken from a
previously prepared file.
- At the end of that file, reconnect the batch system to the card reader
driver and exit the program.
It worked perfectly. Except ... when the computer operators came to
collect up all the punched cards for the completed jobs, and reconcile
them with their associated printouts ... there were no cards for one lot
of printout! They spent some time looking for them, and to avoid further
suspicion, action was taken. Cards were quickly typed for the 'phantom'
job, and dropped down the back of the table that held the trays of
returned cards. Then: "Oh look, what's that down there?".
We got away with that one. Over time we encountered restrictions on
running subsystems, and had to write a loader. That is another story.
--
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org
Using UNIX since v6 (1975)...
Use the BIG mirror service in the UK:
http://www.mirrorservice.org