Lars Poulsen <
lars@cleo.beagle-ears.com> writes:
The more I have learned later, the more I understand just how bad it
was. It was an impressive denial-of-service attack for its time. As the
phone calls flew from the machine room operator to the operations
manager, to the head systems programmer, to the IBM field support, and
on and on, red faces of embarrassment must have triggered explosive
anger.
And like any other system vulnerability then or later, it was a simple
case of insufficient input validation. In retrospect, it was bound to
happen sooner or later. ;-)
As an undergraduate in the 60s, I had rewritten lots of CP67
.... including doing dynamic adpative resource management and scheduling.
After graduation I joined the science center and one of my hobbies was
enhanced operating systems for internal datacenters.
In the decision to add virtual memory to all 370s, there was also the
creation of the VM370 group and some of the people in the science split
off from CSC, taking over the IBM Boston Programming Center on the 3rd
flr (Multics was on 5th flr, CSC was on the 4th flr and CSC machine room
was on the 2nd flr). In the morph of CP67->VM370, lots of stuff was
simplified and/or dropped, no more multiprocessor support, in-queue
scheduling time was only based on virtual problem CPU, and kernel
integrity was really simplified, other stuff.
Now virtual machine could in get into top, interactive Q1 and execute
some code that was almost supervisor CPU (and very little virtual
problom CPU) ... resulting in run-away CPU use ... locking out much of
the rest of the users. The simplification in kernel integrity resulted
in "zombie" users. In 1974, I started migrated lots of CP67 to
VM370R2-base for my internal CSC/VM ... which included curing the
run-away CPU use and zombie users.
Another problem was CP67 would determine long wait state drop from queue
and interactive Q1 based on real terminal type ... VM370 changed it to
virtual terminal type. That worked OK as long as the virtual terminal
type was the similar to the real terminal type ... which broke with CMS
virtual terminal type 3215 but the real terminal was 3270. CMS would put
up READ for 3215 and go into virtul wait (waiting for the enter
interrupt indicating end of typing input) and would be dropped from
queue. 3270 typing would be saved in local buffer, user hits enter and presents a ATTN to system, CMS does a read and goes into wait state and
is dropped from queue, but end of read is almost immediately (rather
than waiting for somebody typing).
CP67 increased the count of virtual machine active "high-speed" real
device channel programs and at entry to virtual wait state and check "high-speed" channel program count ... if it was zero, virtual machine
dropped from queue. VM370 at virtual machine entry to wait, would scan
complete virtual device configuration looking for "high-speed" device
active channel program, and virtual 3215 didn't qualify.
After transfer out to SJR on the west coast, ran into a different
problem, SJR replaced it 370/195 MVT system with 370/168 MVS and 370/158
VM370. It included MVS 3830 disk controller and MVS 3330 string with
VM370 3830 disk controller and VM370 3330 string. Both the MVS & VM370
3830 disk controller had dual channel connections to both systems,
however there was strict rules that never would MVS 3330 on VM370 string
.... but one morning operator mounted a MVS 3330 on VM370 drive ... and
almost immediately operations started getting irate phone calls from all
over the bldg.
Issue was OS/360 and descendents make exensive use of multi-track search
CCW ... which can take 1/3rd sec elapsed time ... which locks up
controller ... and locks out all devices on that controller
.... interferring with trivial interactive response that involves any
disk I/O (MVS/TSO users are use to it, but the CMS users were use to
better than .25sec interactive response).
Demands that operations move the offending MVS disk to the MVS string
was met with it would be done offshit. We get a VM370-tuned VS1 system
and mount its sysem pack on a MVS 3330 drive and start a program. The
highly tuned VM370 VS1, even running on loaded VM370 158 ... could bring
the MVS 168 nearly to a halt ... minimizing its interference with CMS workloads. Operations immediately agree to move the offending MVS 3330
if we move the VS1 3330.
--
virtualization experience starting Jan1968, online at home since Mar1970
--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: Wheeler&Wheeler (3:633/280.2@fidonet)