My first mainframe job was the night shift, and a woman named Dolores taught me everything

Some of the younger folks here asked me, after a comment I left on another thread, how a person ends up doing COBOL for thirty-nine years. The honest answer is that I needed a job in 1986 and an insurance company on the Southbank was hiring night operators. I want to tell you about that job, and mostly about the woman who ran the night shift, because I have been thinking about her a great deal since I started counting down to retirement.

The machine room

The data center was on the third floor behind a door with a combination lock and a sign that said AUTHORIZED PERSONNEL ONLY in red. Inside it was 64 degrees all year round, and loud. An IBM 3081, a row of 3420 tape drives with their reels spinning and stopping, disk drives the size of washing machines, and two big printers that went through a box of green-bar paper every forty minutes during the billing run. I was 21 years old and I had taken one programming course at FCCJ. I thought I knew something. I did not.

The shift supervisor was Dolores Pruitt. She had been running that machine room since it had a 360 in it, she wore a cardigan year round because of the air conditioning, and she kept a thermos of coffee and a spiral notebook on the console desk. The first night, she handed me the notebook and said, "You will write down everything that happens on this shift, with the time. Everything. If it is not in the book, it did not happen, and if it did not happen, you cannot explain it at 7 AM to a man in a tie."

What Dolores taught me

I worked for her for three years. Here is what I learned, roughly in the order I learned it, mostly by doing it wrong first.

1. The batch runs at 2 AM whether you understand it or not

The nightly cycle was a long chain of jobs: premium billing, claims, the general ledger, then the reports that had to be on desks at 8. Each job depended on the one before it. I did not understand what most of them did. Dolores said that was fine, nobody understood all of it, but I had to understand the ORDER, and I had to understand what each job needed before it could start. She drew the whole chain on a sheet of paper taped to the wall next to the console. When I see a modern "DAG" in one of these orchestration tools, I think of that sheet of paper. It is the same picture.

2. Read the JCL before you touch the job

About my second month, a job abended (that is "crashed", for those who did not grow up with an IBM manual) with a space problem on an output dataset. I knew the fix. I had seen her do it. I was going to resubmit with a bigger SPACE parameter and look clever. Dolores put her hand flat on the desk in front of the keyboard and said, "Read me the DISP."

I did not know what she meant. She made me read the JCL out loud, line by line. The dataset was coded DISP=(NEW,CATLG,CATLG), which meant the half-written output from the failed step was still sitting there, cataloged. If I resubmitted as it was, the job would fail again on the duplicate name. If I "fixed" that by changing it to MOD, which I was about to do, it would have appended the whole run onto the end of the half-finished file, and Monday's premium notices would have gone out twice to half of Duval County. You delete what the failed run left behind (we had a little IEFBR14 step for exactly that), you fix the cause, and only then do you rerun. In that order. I have taught that to every junior who has ever sat next to me.

3. The book is for the next person, not for you

Dolores's notebooks went back to 1971. When something strange happened, the first thing she did was go to the shelf and look for the last time it had happened. More often than you would believe, it was in there, in her handwriting or somebody else's, with what they had tried. I keep a log to this day. It is a text file now, not a spiral notebook, and it has entries going back to 1992. Last year a young man on my team spent two days on an intermittent failure in our month-end interest job, and I found the same symptom in my file from 2004, with the fix. He looked at me like I was a wizard. I am not. I just wrote it down.

4. Do not be a hero at 4 AM

Once, in my second year, the general ledger job failed at about 4 AM with an error I had never seen. Dolores was off sick. I spent an hour and a half trying things, because I did not want to call the on-call programmer at home and look stupid. When I finally called him, he fixed it in ten minutes, and then he told me, very kindly, that the hour and a half I had wasted was the reason the reports were late, not the error. Calling for help early is not weakness. It is arithmetic.

5. Know who is waiting on the other end

Every job had a person at the end of it. The billing run meant somebody's insurance notice. The claims run meant somebody's check for a roof after a hurricane. Dolores knew which jobs mattered to whom, and she prioritized accordingly when things went wrong. "The claims checks go out," she would say. "Management can wait. Mrs. Johnson with no roof cannot."

Where it went from there

She pushed me into programming. She told the data processing manager I was "wasted on the console", and in 1989 I moved to the programming staff. Three years after that I went to the bank, and I have been there since. Dolores retired in 1994. I went to her retirement lunch at a seafood place on the beach, and she gave me one of her old notebooks as a present. 1979. It is still in my desk drawer at work.

She passed away in 2011. I did not find out until a year later, which I am still sorry about.

In about two years it will be my turn. I have been thinking about what I will leave behind for the young people on my team, and I keep coming back to the same answer: not the code. The code will be replaced eventually, whatever the consultants tell you about the timeline. What I can leave behind is the book.

Write things down. Read the JCL before you touch the job. Call for help early. And remember there is a person at the end of every batch run.

Walt