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.
   

ISPF productivity

I love ISPF, I really do.  The Editor in particular is a brilliant piece of work, and in my opinion represents the gold standard for text-based editors.  ISPF also provides a very rich API so those that are conversant with ISPF dialog progamming can create useful and sometimes very complex applications. Yeah, those applications are text-based, but since most mainframe programming is done in a text-based world that doesn't matter.

I have written many such applications, and truth be told, it's a lot more fun to write ISPF Dialogs than to write Cobol code.  

Still, ISPF has its shortcomings.  The product uses hierarchical menus that require skill and experience to navigate.  To be sure, there are many short cuts, but it takes time to learn them.  Also, it does not provide a convenient mechanism for organizing the myriad of data sets, DB2 tables, IMS data bases and TSO commands that the programmer has to cope with every day.

I once wrote an ISPF Dialog application that helped me manage all of that stuff, and I was amazed how much time you could save if you aren't constantly searching for half-remembered data set names.   I've used such a tool for many years now, but more recently I've been relying on a commercial product called Simplist, which is way better than anything I've been able to write for myself. It's not free, but it's not expensive either.  I highly recommend it.

Don't believe me?  This guy likes it too.

Disclaimer: I have written about SimpList on several occasions.  I would like to point out that I have no financial interest in SimpList or any other commercial software product.  My opinion is that of an experienced mainframe developer and consultant, not a product shill.  My product review was originally published in Technical Support, the official journal of the Network and Systems Professionals Association (NaSPA).

Some recent Dilberts

Like many in the IT business, I am a big fan of Dilbert, not just because it's funny, but because it sometimes hits close to home.

Here are a couple of recent strips that I've enjoyed:

Guesstimating

Skills utilization

ISPF weirdness

It's not a bad idea to add an explanatory line near the top of each scrollable HELP panel:

"Press LEFT and RIGHT to scroll up and down"

Or, depending on your audience:

"Press LEFT and RIGHT to scroll up and down. No, I am not kidding."