On Sun, 20 Apr 2008 18:11:45 -0700, Skip Robinson wrote: >I remember back when a very fundamental utility changed to SDB by default. >I believe it was IEBGENER itself. If we had HOLDDATA back then, I'm not >sure how big a deal we made of it. In any case, one major application had >an 'outage' because a particular job step had been counting on the historic >default where output blocksize was equal to input blocksize. Their master >file was required to be a certain blocksize. For years the offending >utility step copied the file without specifying blocksize. Suddenly with >SDB the output changed, and subsequent steps failed. > Silly application designer. A well designed application should not be sensitive to blocksize, simply because it should be designed to accommodate future changes in device geometries.
IEBGENER changed to SDB by default and subsequently (or immediately) grew a PARM to override the behavior. I believe later the design changed to make the historic behavior the default. I'm torn on this one. Much as I admire SDB, I respect the intent of a copy program to replicate all attributes of the input data. OTOH, it ought to support optimal copying to a different device type. The final solution should be FBA, where block size becomes irrelevant. Or something like PDSE's protean treatment of BLKSIZE: on input it can be anything the programmer codes in the DCB. >I once had to explain to the author of a very silly CLIST why it suddenly >failed to enter an expected (!) ERROR routine because underscore was no >longer invalid in labels. I didn't feel very guilty about that one. What a >dope. > Every well-designed language, application, programming system should have a way to force an error. IDCAMS has such; HLASM has MNOTE; zSeries has x'00'. Rexx lacks such; I resort to dividing by zero or accessing an uninitialized variable to force an error. Also, every well-designed language should have: o Comments o A no-op. >I remember reading about a new OP code being introduced on a processor. >There was a note of caution that I found almost funny: the new OP code >would not cause a problem for any program *unless* that program were >depending on the OP code *not* to be valid. Where's my S0C1? I need my >S0C1! After all these years in the business, I would not bet the farm on >there being no such program. > This more likely happens with new OP codes overloading user-defined macro names. As a courtesy, the vendor should partition the name space and commit to leaving some fraction available for user-defined macros and promising that no new OP code or macro will intrude on the space ceded to users. The component prefix registry could be used for this, and also to mitigate contention between ISVs. The statement should be that no new OP code or macro name will ever overlap a registered component prefix. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
