2009-11-17

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.

No comments:

Post a Comment