Down with periods!

I still see recently written Cobol programs where the author uses a period after virtually every Procedure Division statement.  


I find this puzzling.  


The introduction of END-IF over 20 years ago has made periods unnecessary in the Procedure Division except for the end of a paragraph and paragraph names.  When maintaining a period-infested program I like to remove all unnecessary periods in the paragraph I am working on.  If I have time, I change the necessary periods to END-IF and NEXT SENTENCE to CONTINUE.  If you are careful, there is very little risk in doing this, and you will leave the program a little better than you found it.  Make it Right!

Rant: Cobol line numbers

Why on God's green earth do so many programmers continue to use sequence numbers in their Cobol programs?

Come on guys, when was the last time you even saw a card deck, never mind dropped one?

Ditto for the numbers in columns 73-80.  If you have a source management system, you don't need to use these numbers to track changes, the source manager will do it for you.  If you don't have a source management system, a source comparison tool (SUPERC works just fine, and it's free with ISPF) will tell you all you need to know.

Down in the Dumps

I found myself with some spare cycles at work the other day, so I spent some time reading a few dumps created by our online production regions.

Does that make me weird?

There was a time that I found dumps to be both tedious and intimidating, but modern dump formatters have made it much easier to figure out what happened. For example, except in very rare cases, a Cobol programmer reading a dump no longer needs to know the register contents or indeed, what a register is.  Nor does the programmer have to know how to determine the instruction in error or how to find the program's BLW and BLL cells.  The dump formatter lays it all out for you.

I must hasten to add that interpreting a dump is still a challenging intellectual exercise because you need the ability to understand the application logic and have enough imagination to figure out how your data got into the state it is in.  In many cases you also require an intimate understanding of how your application interacts with its execution environment.

Thanks to the dump formatter, it only took me a few hours to diagnose a handful of problems that were responsible for about half of the abends in our application's online regions.   Were it not for the formatter, I probably would not have volunteered for the job.

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.
   

Risk-averse programming

In my experience,  there are a lot of COBOL programmers who don't give a damn about programming either as an art form or as scientific discipline (take your pick).  They spend their days attending endless meetings with business users trying to tease out system requirements from endless discussions that go round and round forever....   At the end of  each day, they don't sign on to comp.lang.cobol to debate the merits of Sections vs Paragraphs.  To them, programming is a just a chore that they have to do in order to get the end result the user wants.

Generally, business programmers are given the following objectives from their manager (in order of importance):

1. Don't screw up
2. Deliver it on time
   
3. Deliver what the user wants
   

From the users, they get the following objectives:

1. Don't screw up
2. Deliver what I want
3. Deliver it on time
   

I think this breeds a very conservative, risk-averse programmer, for whom avoidance of error is the primary concern.  Don't tell him/her about EVALUATE, he/she knows that nested IFs work. 

Field Name Prefix on DCLGEN command

I strongly advise using the "Field Name Prefix" feature of the DCLGEN command. This causes each Cobol field in the DCLGEN to have the same prefix. This makes coding much easier, as it can eliminate the need to code Cobol "OF"s when referring to a field.

How many of your tables contain an account number field? A good many of them, probably. It is easier to code

MOVE WS-TEMP-ACCT-NUM TO VIFCACCT-ACCT-NUM

than

MOVE WS-TEMP-ACCT-NUM TO ACCT-NUM OF ACCT-TABLE.

Using prefixes, the programmer can tell at a glance which ACCT-NUM is being referred to.

The prefix name should be related to the table name. Our shop adopted a procedure in which we establish an 8 character 'short name' for each table. The short name is used as the prefix name, and is also used to build the table space name.

I feel so strongly about this that, years ago, before DCLGEN even had a "Field Name Prefix" feature, I wrote an edit macro that added a field name prefix to the DCLGEN output. It is still in use today.

Whose default is it? (sorry)

The LE run time parameter CBLQDA can bite the unwary.  It doesn't help that IBM has changed the default value over the years.  I was just recently able to convince our local sysprogs to change it to OFF.  Their first reaction was that there had been no change, that the system had always behaved that way, and OFF was the default. 

The story I heard was that IBM originally delivered CBLQDA(ON) as the default, with a recommendation to turn it OFF.  This was to comply with some ANSI COBOL standard.  Our local sysprogs accepted IBM's recommendation and set it to OFF.  A few years later, IBM changed the default to 'OFF'.  The local sysprogs knew that in the past they didn't use the default value, so, by reflex, they switched it to 'ON'.  And for a long time no one complained.

(For those not intimately familiar with IBM's Language Environment, the CBLQDA setting controls the behaviour of COBOL programs that fail to assign a dd name to an output file.  CBLQDA(OFF) means that an error is thrown, CBLQDA(ON) means that the problem is ignored.)

I was remined of this when I was approached by a desperate colleague who had been banging his head against the wall for two days, trying to figure out why, no matter what he did, his output file remained empty.  He could see the EXCP counts, so he knew data was being written somewhere.  It turned out he had a misspelled ddname, and because CBLQDA(ON) was in effect, z/OS was writing to output to an uncataloged temporary file instead of the one that was intended.

Ouch.

Standards are forever

I am presently working at a shop where static linked modules are the standard practice. Much to my dismay, convincing them to change to DYNAM is proving to be more difficult than I expected.  Change is a constant in this business, except where Standards are concerned.

Fortunately, the chief defender of the standard retired recently, so there is now some hope that it will change.

Cobol scope terminators

All the scope terminators are great, but I especially like END-IF because it allows you to avoid programming in SENTENCES. IMO, the designers of Cobol took the natural language metaphor a bit too far when they introduced the concept of logic flow delimited by periods (aka "full stops").

IMO the lack of END-IF in early versions of Cobol severely damaged the reputation of the language. I think that is the reason why Dijsktra said:

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

END-IF is easily the most important innovation ever made to the language in the 28 years that I've been working with it.