It's the 1970s, and this young pilot fish working as a student assistant in a university data center gets Friday afternoon marching orders from the mainframe operators who are leaving early. How could that go wrong?
This county government has a jury application that interfaces with its mainframe, and it handles everything except cutting paychecks for the jurors. That takes an extra set of steps by the jury coordinators.
User at this state agency has a problem with her mainframe account, so her supervisor requests a new ID on the mainframe -- and that requires some approvals to gain access to certain screens.
This junior mainframe programmer is part of a team that's moved to a new location. But soon a senior data analyst starts complaining that she's getting headaches and her terminal isn't right.
This tech at a big bank gets a call from someone in Finance who's frantic because the "numbers report" is missing, Numbers report? "You know," user says, "that real big report we get each workday. I need to file it!"
Flashback to the late 1970s, when this IT pilot fish's team has just gone live with a custom hospital management system, complete with order entry for the nurse stations. But user acceptance is mixed.
Tech quits his job in this IT department, so someone has to pick up his support duties, and this pilot fish draws the assignment. An uneventful year and a half later, he gets his second call -- and it's a doozy.
Pilot fish is working for a company whose offices are located in a wooded, mostly residential area that's beautiful but has its downsides -- including regular power outages.
At this big manufacturing plant, an employee has a problem with a mainframe-terminal keyboard that sticks -- and unfortunately, the vendor has a fix for him.
A news report blames the Long Island Power Authority's slow response to restoring electricity on a 25-year-old mainframe. But are a mainframe and Cobol really the probelm?