On Fri, 13 Nov 2015 20:16:15 -0600, Ed Gould wrote:
>
>I remember discussions in other forums with IBM and they had the same
>response. Its been years but I think the user reply to IBM do it
>right the first time and document it well and nobody would mind.
>It appears that IBM fell down on the documentation issue.
>
No. You document crap and you get documented crap. It wasn't done
right the first time.
Consider the JCL fragment:
//*
// EXPORT SYMLIST=*
//*
// SET L=120
//STEP EXEC PGM=IEFBR14,PARM='L set to &L..'
//*
//ALFA DD *,SYMBOLS=JCLONLY,LRECL=&L
LRECL is &L
//*
// SET L=132
//BRAVO DD *,SYMBOLS=JCLONLY,LRECL=&L
LRECL is &L
//
The value 120 should be substituted in PARM (it is) and available to the SYMBOL
API in the job step because that's the value in effect at the EXEC statement.
The value 120 should be substituted as LRECL in DD ALFA (it is) and substituted
in the body of the instream data set because that's the value in effect at that
DD statement.
The value 132 should be substituted as LRECL in DD BRAVO (it is) and substituted
in the body of the instream data set because that's the value in effect at that
DD statement.
Anything less is indolent implementation, not fixable by prolix documentation.
No interpolation of IEFBR14 steps can make the extant behavior right, nor
should that sort of mickeymouse be necessary.
If you want to make a case that the scope of a SET is a job step and the last
SET of a given symbol within that job step should prevail, then for consistency
the last value of L (132) should be used throughout the job step: PARM, LRECL,
and instream data set bodies
Steve Jobs would have fired the developer who made that z/OS decision.
Rightly. That relentless concern with detail in the user interface was in
large part responsible for the phenomenal success of Apple.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
