Drum vs. Core
Roger Holmes
roger.holmes at microspot.co.uk
Mon Jul 2 13:51:35 CDT 2007
On 2 Jul, 2007, at 18:02, cctalk-request at classiccmp.org wrote:
>> When I was at university (71-74), the college's mainframe
>> still used a drum from program overlays (probably really the virtual
>> memory backing storage, but possibly just dumping and restoring the
>> whole program between time slices. The machine was no slouch, it was
>> serving about a hundred terminals and running a couple of batch
>> streams as well (Maximop and George 2).
>
> I take it that this was an ICL 1905E (probably at Swansea or QMC).
Yes, QMC. It got upgraded to a 1904S whilst I was there. Maybe it was
the 4S which had 100+ terminals, there was certainly a large increase
whilst I was there. Initially most were printing terminals with
lights inside, not Teletypes, can't remember the maker's name. There
was also just two CRT terminals, on which you typed a load of lines
and told the computer to read it. You could edit small programs on
screen but on the priniting terminals you had to give it commands to
change character and to step through your code. Later on we got Data
Dynamics terminals, an acoustic box (to save the ears) around a naked
ASR33 or KSR33 Teletype. Then we got the fairly standard 'glass
teletypes', though by then I was mostly using the IMLAC graphics
terminal.
Do you think the drum got kicked out when we went over to the 4S? I
never got to see the 4S. It was all hands off. All changed when I got
to Marconi-Elliott Avionics, the training consisted of - there's the
computer, here's how you turn the thing on, there's the mylar tape
library, the bootstrap is at 8181, get on with it.
> That processor benchmarks about the same as an IBM PC/AT (!)
> [somehow I cannot see running 100 terminals off an AT]
Was it really that slow! We really put up with a lot back then.
>
> Originally on the 1900 series the drum was considered a different
> peripheral
> type (ie needed different programming) from an Exchangeable Disk
> (EDS) or
> Fixed Disk (FDS), but, by the time we at City acquired Swansea's old
> 1905E and drum (and some EDS30s), new Executives appeared with
> UDAS (Unified Direct Access) where the drum was programmed just the
> same as a disk. These Execs, unlike the previous versions, were
> overlaid
> (I think they were still, however, written in engineers assembler
> which used
> numeric op-codes rather than the mnemonics of PLAN or GIN5).
Interesting. Maybe it was like my school maths teachers who forced us
to use fountain pens instead of ball points because it slowed us down
so we thought more about what we were doing and so made less
mistakes. At Marconi, the hardware test programmers/engineers always
used a different language than those of us in the utility software
group, and we provided the higher level language compilers for the
applications writers to use.
> Each overlay was (most of) a 128 word disk sector ... tight modular
> code
> was rather forced! ... it also had to be position independent on a
> machine
> with no real architectural support for such - and you had only
> minimal use
> of the Datum/Limit registers in Exec mode.
Very difficult. I had always assumed the executive lived at a fixed
position in memory. Maybe it used relativisers, 1300 style, where
every instruction could specify what block start address should be
added to it, but maybe that would slow down loading the overlays too
much. I wonder if any of the concepts in the 1302 executive got re-
used on 1900. Obviously not the code itself, very different
architectures, just sharing the 'standard interface' and the concept
of the executive itself.
> The drum was, I think, 512K characters (128K 24-bit words). We put the
> Exec overlays and the Maximop overlay file on the drum - I'm not sure
> what else. It probably was too small for the Maximop swap file.
> George II
> and the main compilers and consolidator (ICL's name for the link
> editor)
> were probably also on the drum. George had little to gain fromsuch a
> location
> as it did not use overlays except that job wrap-up and start
> reloaded the
> full code, some of which got overwritten during processing - British
> operating
> systems of the era tended to use a "job description" at the start
> rather
> than
> the interspersed "control cards" typical of IBM.
Right.
> We got rid of the drum at the start of our transition from ICL to
> Honeywell -
> it took up too much space in the machine room and the Level 66 was a
> BIG machine (physically).
Maybe ICL had been bumping up the maintenance charges for old kit
they really did not want to support any more. Keeping engineers
trained up on kit for a handful of customers is not very cost
effective, and the older engineers who knew the old kit keep getting
'promoted' into management.
More information about the cctech
mailing list