The mainframe strikes back

I attended an interesting IBM presentation today on the topic of zIIPs, zAAPs and IFLs.

These specialty z processors are designed to support "new" workloads that were formerly the domain of Java, Linux, and *ix.  After spending the past two decades losing workloads to the other platforms, the mainframe is finally* winning some of it back.


*Actually these processors have been around for the past decade or so, so it's not that recent a development.

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.

Checkpoint

You may have noticed that I haven't posted anything since January 2010.  There is no deep dark reason for this; just the usual combination of laziness and busy-ness.

Most of the posts prior to this point represent a collection of stuff that I've posted on the Internet over the past several years.  A "best of" collection, I suppose.

I've recently started a new job, and that is always a good way to find some inspiration.

In my first IT job, I was well indoctrinated (brainwashed) in the procedures and processes demanded by that company.  The procedure and processes were (mostly) reasonable, and what the hell, I didn't know any better anyway.

The problem came on my second career stop.  I thought the new shop was idiotic for doing things differently than my old one.  It was quite an adjustment, but eventually I realized that there were some interesting ideas there that I have since incorporated into my own work.

Now, many years later, I find myself back at the original company, older, wiser, and with a broader perspective.  

5 ways to start a war on a mainframe forum

1. Use the acronym "USS" to refer to z/OS Unix features.
2. Propose the elimination of the 100 byte limit on PARM length in JCL.
3. Complain about the limitations on the use of System Symbols in JCL.
4. In a COBOL forum, declare that coding is Paragraphs is better than coding in Sections.   Or vice-versa.
5. Praise Oracle on a DB2 forum.
   

5 more ways to start a war on a mainframe forum

Uninitialized storage (2)

It is generally a Very Bad Idea to make any assumptions about the contents of uninitialized storage.

What might work today may fail miserably tomorrow, without warning and without apparent cause.

If you care about it, then initialize it.

Application entropy

If you wait long enough, people will start treating a bug as a feature.  Then you can't fix it because you'll break their application.  Sigh.  I have seen this type of application entropy many times.

Business programmers

At the risk of stating the obvious, COBOL programmers work in a business environment, and in that environment people are rewarded more for their business acumen than their facility with nested IF statements. If you can charm the user and convince him that you understand his needs and that you know how to meet them, then it doesn't matter if you go back to your desk and write crappy code.  As long as you deliver something that more-or-less works in a more-or-less timely manner, you will be well regarded and rewarded.

Many (perhaps most) programmers in a business environment are not there for the long haul.  Programming is merely a phase they have to go through at the entry level.

Business programmers fall into the following groups:

1. Managers in waiting.  To this group, programming is just a step on the career ladder.  This is a large group (maybe 25%).  This group cares little about the code they develop, other than it meets company standards and is delivered on time.
2. Business analysts in training.  This group cares more about the company's business than about the programs that support it.  This is the largest group,  and they eventually abandon programming to become full-time business analysts or end users (about 50%).   This group regards programming as utter drudgery, and tend to delegate it to junior team members whenever they can..
3. Clerks in training.  This group does what they're told to do, no more no less.   A smaller group (about 15%).  This group is capable of producing good code, if they're given detailed specifications and good sample code to work from.
4. Technicians.  This group see programming as a profession (or at least a skilled trade) that they can take pride in.   A small group (10%), they tend not to care much about the business they are supporting.  Even though they work with COBOL and can use it creatively, many of them have bought into the myth that it is a Creaky Obsolescent Boring Old Language and yearn to move on to other technologies.