Nostalgia: program flow charts

Junior programmers were once required to produce a flow chart of their program before beginning to code.  They were told that it would help them work out their logic so that their coding and testing would go more smoothly.

I think it was a scam.

The real purpose of a  Program flow-chart was to slow down the coding process in order to ease the workload of the keypunch department.

Full disclosure:  When I started my career there was no keypunch department where I worked.  We shared terminals; one for every two people.  Yes kiddies, I said terminals not PCs emulating terminals.

Those were not the good old days.

You can't do that with SQL

A long time ago I led a DB2 pilot project for one of IBM's earliest DB2 customers in Canada. By default, that made me one of the most experienced DB2 users, outside of IBM, in the country.

It wasn't long before it all went to my head, and I found myself making authoritative pronouncements on all things DB2 related. Why not? I was qualified; I had a whole 3 months of DB2 experience to draw on.

One of the challenges was learning how to use SQL when our only reference materials came from a 5 day IBM course. As you might expect, we ran into one obstacle after another. And it wasn't just SQL, we had to figure out how to Bind PLANs (there were no Packages in those days) and how to set up and use a DB2 test environment.

My programmers would ask me for advice on how to code an SQL statement and most of the time I could help them, but once in a while I had to declare: "You can't do that with SQL." I was the DB2 ghuru after all, so if I couldn't figure out how to do it, then obviously it was impossible.

Well, there was this very bright young trainee who, after hearing me say "You can't do that with SQL", came back 30 minutes later with an SQL statement that did exactly what I said couldn't be done.

I took it with good humour, not at all irritated to be corrected by a mere trainee. (Well, not for the first few times anyway). It eventually became a sort of game: every time I used the words "can't" and "SQL" in the same sentence, he would (almost) always prove me wrong.

That was an important lesson for me: whenever you think you're the smartest guy in the room, take another look, you may have missed someone.

Advice

Here is a list of some dubious career advice that I've been given over the years. The degree of dubiousness varies.

1981 : "Stay away from COBOL...it's a dead language."

1982: "Structured analysis, structured design, structured code...everything else is crap"

1983: "There won't be any more batch processing within 5 years, everything will be online"

1984: "Find another line of work. 4GLs will make programmers obsolete."

1985: "What, you're still using VSAM? Get a database!"

1986: "Hierarchical data bases are obsolete. If you're not relational, you're not in the game!"

1987: "*Still* using COBOL? You dumb #$@!"

1988: "CASE tools will solve the application backlog"

1989: "Code reuse will solve the application backlog"

1990: "Forget CASE tools. Desktop development is much faster!"

1991: "The mainframe is dead. Go client server"

1992: "Find another line of work. Overseas outsourcing will put you out of a job"

1993: "OO analysis, design and development will solve the application backlog"

1994: "What? You're still using IMS??"

1995: "Forget Cobol. Learn C".

1996: "Forget C. Learn C++".

1997: "Y2K will be the end of the world as we know it"

1998: "Okay, maybe COBOL isn't dead....but it will be after Y2K is finished"

1999: "All future application development will be in JAVA"

2000: "The mainframe is the best platform for e-business"

2001-present: I stopped listening to advice. :-)

The jury is still out on some of these items.....

Feeling young

Hearing old timers talk about TSO edit makes me feel young. (A rare pleasure that is getting rarer).

I was one of the first generation of programmers to have the privilege of using SPF right at the start of my career. During my entry level training, the topic of TSO was glossed over; I never even had to learn TSO Edit.

This was back in 1981, when it was called SPF (Structured Programming Facility). A few years later it was re-branded as ISPF (Interactive Structured Programming Facility...."Interactive" being the buzzword of the day).

Then, sometime in the late 1980s ISPF became "Integrated Systems Productivity Facility". "Integrated" was a fashionable buzzword at the time, and IBM decided that ISPF wasn't just for "Programming" any more.

Nowadays the official name of the product is "Interactive System Productivity Facility". Whatever happened to "Integrated"? Perhaps I have my chronology wrong.

Your memories may vary.  (Mine vary from day to day).

I think I first saw option 3.4 in 1986 +- 1 year or so. I didn't like it very much...real programmers knew all of their data set names, so who needs 3.4? (Twenty years later, I am hooked on SimpList, a product which is like 3.4 on steroids).

I remember when you had to hit RETURN rather than ENTER in order to use a Jump function. I also remember complaining when they changed that, but I soon got used to it.