- Westpac Bank losing a whole data centre floor of these 3380 DASDs in the late 1980’s when the water-based fire sprinklers went off.
- That ASIO, instead of trading in their old 3380’s, had the disks ground up. Information security was the reason given.
- A computer operator, during a mainframe shutdown procedure, thinking that because the 3380 was taking too long to power off, flicked the emergency power off switch.
Resetting the switch required a visit from an IBM Customer Service Engineer.
- Disks shattering at (high rotational) speed, and exploding out the side of the cabinet. Urban myth, or not? Heard it happening from a number of mainframe operators over the years. So there might be a grain of truth there.
- Vacant data centre floors caused by the 3380 & 3390’s being replaced by the much smaller IBM 9394 RAMAC units.
I’ve only seen cold fusion used once. StorageTek used to make mainframe printers with cold fusion technology. You’d take paper off the printer, and it would be icy cold. Cold enough to burn you.
On the other hand, the first commercial laser printer, the IBM 3800 used hot fusion.
I had the privilege of working with one of those beasts. The things I remember about them:
- Speed. they were capable of printing 20,040 lines per minute.
- Keeping them filled with paper was a constant chore.
IBM claimed they could produce 1.7 miles of paper every hour. I’d believe it.
- Toner. They used 5 litre (guessimate) bins, and we’d go though 1.5 bins on an eight hour shift.
In comparison, the StorageTek had a toner hopper. You’d pour toner into the hopper, and then watch the cloud of toner form above you.
- At the backup site, the IBM 3800 generated so much heat, it would trigger the fire alarm.
The root cause? Don’t put a big printer in a small room.
The fix? We’d leave the computer room doors open when we ran it.
I worked with a company who operated a large IBM Mainframe network.
Now back in the day (late 1980’s), essentially there were two products that could be used to monitor an IBM SNA Network. The NetMaster product, and the somewhat inferior IBM Netview Product.
You could use either product to detect network problems, but the (free) NetView product required more skill to interpret the information.
The type of errors we’d generally aim to spot were latency and transmission errors.
Latency is a measure of how long it takes for a packet to travel along a network. With IBM SNA, you would get a broken network connection with a latency of more than 2 seconds. So you start to worry about traffic taking 1.2+ seconds.
Transmission errors. Much like how static on a phone line makes it hard to talk, high transmission error rates makes it hard for computers to talk on networks. Eventually, with growing transmission errors, the computers would stop talking.
So in a well managed network, you’d monitor both, with the aim of keeping up times, up.
“We don’t do that here.”, was the comment I heard in the first week I was there. I was amazed the company managed to function at all.
I had to descend one level, to check out one of our systems.
Swiped my access card and swung the door open.
No strange sounds. Certainly no smoke or fire.
Out onto the ICL Mainframe floor I ventured.
One of the prettiest sites you can see in IT, are all the blinking lights, from the hundreds of modems, hubs, switches, and routers; flashing off and on.
On any Friday and Saturday night, you’d find the hard working ICL Mainframe Operators of the State Bank Victoria IT branch, having a snooze.
In their sleeping bags.
Bank branch processing had finished for the week, and so they’d switch the lights out and have a sleep.
The IBM Mainframes were a 3084, 3090-600J, System 36 & 4341. The main processing was performed on the 3090. The ICL’s were Series 39’s.
The IBM’s and ICL’s lived on different floors @ 330 Spencer Street.
Now the official word as to why we had the biggest ICL Mainframe complex in the Southern Hemisphere, was this:
IBM Mainframes are good for batch processing. ICL Mainframes are better at online transactional processing (ie. bank branch transaction processing).
The unofficial, or as I like to say, real reason was rumoured to be this:
One night, the ICL On-site Engineer2 was on the IBM floor, and noticed the ICL “J” scheduler program running on one of the IBM 4341 mainframes. He reported this to ICL Management. An SBV programmer had ported the “J” scheduler to the IBM Mainframe. Clever bit of programming it seems.
“Discussions” occurred between SBV IT & ICL Management.
Costly legal action avoided, and SBV became the largest ICL Mainframe operator in the Southern Hemisphere.
1. The Mainframe floor was derisively called “Heaven” by the SBV ICL Mainframe Operators, as the IBM floor was one floor above them.
Superseded as the 4341 was, we still used it for one production job.
FarmBank PINs and TANs.
A PIN is something you already know about, as you use one when you use an Automatic Teller Machine. A TAN on the other hand, you might not have heard of. A TAN was a Transaction Authorisation Number. Each FarmBank transaction required a TAN. We issued a PIN; and TANs, when customers requested them.
Graziers were the target customers for FarmBank. It allowed them to check their bank accounts from the comfort of their farm house. FarmBank was gatewayed off from the main Telecom Australia Viatel system. Viatel was a forerunner to the internet for most online users in Australia.
Now FarmBank PINs and TANs printing was considered highly sensitive, and only trusted staff were allowed to do it.
But mistakes happen. Sometimes the PINs and TANs would be printed on blank paper stock, which we’d then have to shred.
Except on one afternoon shift. The supervisor took the printout, and threw it straight into the waste bin.
Just as the Data Centre Manager strolled past, doing the MBWA thing. The supervisor was hauled over the coals, and PIN/TAN printing became a two-person operation aka “No-Lone Zone”.
One of the functions of the Network Operations Group had was managing the IBM Mainframe network. Let’s say 2,500 terminals in all.
Now, back in those days, there was a 2% training levy that employers were required to spend on their employees. So our management thought
We could send the Network Operations team to learn NetMaster.
NetMaster, later known as Solve:NetMaster, is a product which allows you to manage IBM Mainframe Networks. Sure YOU CAN manage the network from a System Console (SysCon), but NetMaster makes it easier to do.
The other thing NetMaster could let you do is string commands into a batch file, so you could do complex network tasks. Very useful in the right hands.
Enter the Newly Trained Operator, keen to see what all these scripts in front of him could do. So, one by one, he ran them. Everything went well until he reached Z.
Specifically the ZNET script.
Newly Trained Operator entered
and pressed ENTER.
The console screens filled with errors, the 30 transaction log printers all started up at the same time, and the phones started ring.
Some clever Systems Programmer created ZNET to do a “Z NET, CANCEL”. The reasons for doing so are lost in time.
Z NET, CANCEL forces the network to shutdown RIGHT NOW. Kind of like unplugging your computer from the wall socket, without turning it off first.
The cost? Whole branch banking and ATM network fell over, costing over $1 million and 2 hours downtime.
The following day? Security permissions were applied to the NetMaster scripts.
The excuses I’ve heard have included:
- it was taking too long to shutdown.
- I thought that’s how we did it(!?!)
- I wanted to see what would happen.
The last excuse was made when “Gibbo” powered off the whole IBM 3090 mainframe complex, by pushing the big red switch. Shortly afterwards, all the big red switches had perspex covers fitted.