You needed Vary Off
Eons ago I was the 1st Unix geek in a mainframe (MF) company. We were a print shop, junk mail, many dozens of VERY LARGE printers you did not want to fall into, that were fed from huge rolls of paper, and ended up running through multiple printers (to print different colors on the same page) before being chopped, folded, and inserted into envelopes. We had several football field sized warehouses filled with these printers. All running via bus&tag connectors (initial post reference). The correct process to remove these devices is via the “vary off” command. You did not need to halt the computer. Later on the connectors became ESCON (17mbit?) then FICON (100mbit?)
We got a forklift upgrade every 18 months, new CPU for a couple million dollars. We had dozens of 3480 cartridge drives feeding the MF sort / merge / purge processes. We had about 6 tape monkeys on site at all times that did nothing but run around, gather cartridges, and feed the beast. We also had a big EMC disk pack, but it was trivially small compared to the amount of work we pushed through via the tape drives.
The MF director HATED me. I spent years cherry picking projects, moving them to Unix, building my teams, and taking floor space. When the initial xeon chips shows up, these devices had CPU speed equivalency, so my systems would kick ass on compute bound tasks, but I had no desire to drive those printers. At this point I had about 50 Linux based compute servers and a dozen Sun systems.
The MF director had a favored bit of software called copycross. This software pretended disk files were tapes. It would also compress/decompress them on the fly. This allowed decades of tape based software to run seamlessly on disk based files, no recoding, plus it ran a lot faster since disks are faster than tapes (sometimes). As long as we were willing to buy enough disk space to support it (sold by EMC of course).
Except – it was a PIG. It would suck down about 30% of MF compute cycles, dramatically impacting other tasks concurrently running. The MF director denied it. He brought out reams of performance reports to “prove it”. Our boss told me to prove otherwise or back off. I was given a MF login and access to a status program. The program was like “ps” on steroids, full screen deep dive interface. Forget what it was called, but it was kick-ass. I used perl driving a 3270 sessions to screen shoot a session every 10 seconds. I then parsed that out, pulled the REAL performance data, proved my point, and torpedoed his project.
But: Each time I ran the process monitoring screen, it took up a job number in the mainframe. And I didn’t run the correct exit command to collect/free up the job. After about 20 hours of running, I consumed every available job id on the mainframe. CRASH.
Oops.
Biting the hand that feeds IT
