Lynn Wheeler <lynn@garlic.com> writes:

however, all 3270s were half-duplex and if you were unfortunate to hit a >> > key same time system went to write to screen, it would lock the keyboard >> > and would have to stop and hit the reset key. YKT developed a FIFO box
for 3277, unplug the keyboard from the 3277 head, plug the FIFO box into >> > the head and plug the 3277 keyboard into the fifo box ... eliminating
the unfortunate keyboad lock.

On 2025-02-03, Colin Macleod <user7@newsgrouper.org.uk.invalid> wrote:

This reminds me of something when I was a student around 1975. My university's
only computer was an IBM 360/44 and we could use some 2260 terminals. Digging through some manuals I got the idea that by munging the "carriage control character" from a Fortran program I might be able to break out of the restriction of block-mode operation and persuade a 2260 to do animated graphics.

When tried my proof-of-concept program I did get the terminal to keep redrawing a very flickery but changing few lines. But while I was watching this, the other users in the lab started complaining that their terminals were
frozen. Then the operators started running around trying to find out why
the whole mainframe had hung. It appeared that my hack had somehow elevated the priority of my animation such that nothing else was getting run at all.
I couldn't even interrupt my own program. They had to reboot the machine to fix it and I was told in no uncertain terms to never do that again!

My own "NEVER do that again" stories:
1) 1971, I think:

I was one of three part-time operators of an IBM 1130 that had been
pressed into service as a HASP RJE terminal for the new IBM/360-65 MVT
system at NEUCC (DTU, Lyngby), but we still had a tray full of
pre-punched IBM 1130 DOS control cards:
// JOB T
// FOR
// XQT

One of my coworkers pondered what would happen if you submitted a small
deck with an 1130 JOB card instead of an OS/360 JOB card. I explained
that the spool system would take it as a job with a sort-of valid job
card, but with invalid values in most fields, such as the billing
account, the job queue (class=) field etc. Then when the job scheduler
got to that point in the queue, it would fail all sorts of syntax and
validity checks, and a printout would be returned with all sorts of
error messages. He did not believe me, so I proved it by submitting it.
The one solitary JOB card came back as 4 or so pages of print:
- front separator page
- HASP console message log
- JCL processing log
- back separator page

He then pondered what would happen if we read in a whole stack of JOB
cards, and I said "same thing for each card in the stack". So we did
it.

It read the first couple of dozen cards quite fast, then slowed down a
lot, and read one card at a time, a couple of seconds apart. And then it
went REALLY slow, reading one card after printing the 4 pages of job
output.

That was because the HASP job queue had about 100 slots, with a
pre-allocated cylinder for the input cards for the job and I think also
the log files. Once all the job queue slots were taken up by the BAD
jobs, no new jobs could be read in FROM ANYWHERE in the RJE network,
until a job slot had been finished and the slot made available for a new
job.

But it was worse. The OS/360 job card had a job ID field at the
beginning of the card (before the word JOB), and all the BAD jobs had
the same invalid ID. So when a job came in with a blank ID field, it was
a duplicate of the preceding BAD jobs; each new job had to be assigned a
unique new ID, and this generated a console message announcing a
duplicate ID, folowed by a console message announcing the new ID,
followed by a message that the new job had been placed in HOLD status,
so that only one of these jobs with the same ID could be in the OS job
queue. After the first duplicate, the newly generated ID was also a
duplicate, triggering more HASP console messages as the queue was
searched trying to find a new unique name. As each job finished, HASP
would release the jobs tht had been HELD, tgriggering more messages.
Soon, the 1050 console was running 15 minutes behind, and the operator
was unable to get a command in.

In the end, I think they had to re-IPL the system and FORMAT the HASP
SPOOL disk to recover.

I was lucky to keep my job.

I think someone wrote a PTF for HASP to make sure that could not happen
again!

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Tue, 4 Feb 2025 20:26:30 -0000 (UTC), Lars Poulsen wrote:

In the end, I think they had to re-IPL the system and FORMAT the HASP
SPOOL disk to recover.

I was lucky to keep my job.

IBM was, of course blameless. It was easier to sack a hapless employee
than to switch to a supplier of better-quality products.

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Lars Poulsen <lars@cleo.beagle-ears.com> wrote:

That was because the HASP job queue had about 100 slots, with a
pre-allocated cylinder for the input cards for the job and I think also
the log files. Once all the job queue slots were taken up by the BAD
jobs, no new jobs could be read in FROM ANYWHERE in the RJE network,
until a job slot had been finished and the slot made available for a new
job.

But it was worse. The OS/360 job card had a job ID field at the
beginning of the card (before the word JOB), and all the BAD jobs had
the same invalid ID. So when a job came in with a blank ID field, it was
a duplicate of the preceding BAD jobs; each new job had to be assigned a
unique new ID, and this generated a console message announcing a
duplicate ID, folowed by a console message announcing the new ID,
followed by a message that the new job had been placed in HOLD status,
so that only one of these jobs with the same ID could be in the OS job
queue. After the first duplicate, the newly generated ID was also a
duplicate, triggering more HASP console messages as the queue was
searched trying to find a new unique name. As each job finished, HASP
would release the jobs that had been HELD, triggering more messages.
Soon, the 1050 console was running 15 minutes behind, and the operator
was unable to get a command in.

In the end, I think they had to re-IPL the system and FORMAT the HASP
SPOOL disk to recover.

I was lucky to keep my job.

I think someone wrote a PTF for HASP to make sure that could not happen
again!

On 2025-02-05, Peter Flass <peter_flass@yahoo.com> wrote:

There were only so many WTO (console) buffers, too, so writing lots of
stuff to the console would also bog the system down.

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. ;-)

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

In article <slrnvq7v9f.kpad.lars@cleo.beagle-ears.com>,
Lars Poulsen <lars@cleo.beagle-ears.com> wrote:

[snip; great story]
On 2025-02-05, Peter Flass <peter_flass@yahoo.com> wrote:

There were only so many WTO (console) buffers, too, so writing lots of
stuff to the console would also bog the system down.

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. ;-)

Ah! So, what you're saying is that you added value by identify
the issue and its cause early on, allowing it to be corrected
before it appeared elsewhere. Well done! :-D

- Dan C.


--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: PANIX Public Access Internet and UNIX, NYC (3:633/280.2@fidonet)

It appears that Lars Poulsen <lars@cleo.beagle-ears.com> said:

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.

As I've mentioned before, I crashed Princeton's 360/91 with this two line Fortran program:

CALL MAIN
END

MAIN was the default name for a Fortran main program, so it recursively called itself. The Fortran initialization code told the system to save the existing floating point trap handlers, set up its own, and then restored them when the program exited.

Except that the space where it saved the existing trap handlers wasn't very big.
Oops. Kaboom!
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: Taughannock Networks (3:633/280.2@fidonet)

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)