On Thu, 7 Nov 2013 09:41:40 -0800, Richard Pinion wrote:
>And to throw another twist to this thread, some people say the LRECL and RECFM
>should not be coded in the JCL. That way when a change is made to the program
>source, that affects LRECL and/or RECFM, the corresponding JCL doesn't have to
>be updated. What are some opinions about that methodology?
>
If by changing the program source you mean coding LRECL and RECFM in the
DCB, the JCL needn't be changed. Values coded in the DCB quietly override
any coded in JCL. Shouldn't a warning of such disagreement be issued?
I believe so, but via what channel?
>-----Original Message-----
>From: Ze'ev Atlas
>Sent: Thu, Nov 7, 2013 8:39 am
>
>Let me add another complains about JCL, it allows changing source code meaning
>n run time and sometimes this is hairy:
>//XXX DD DSN=....
>/ DCB=(LRECL=80,&R
>/...
>The above is legit although I would fire anybody who doed it. R could be
>esolved to:
>/ EXEC YYY,R='BLKSIZE=8000)'
>or it could be resolved to an early example of cose injection of your choice
>
I applaud languages such as Rexx in which lexical metacharacters are
never recognized in text introduced by variable substitution. Rexx
provides a workaround in the ever-so-controversial INTERPRET instruction.
My first mentor in JCL had a habit disabling options by defaulting
a PROC parameter to ' ' and enabling them by substituting ''.
E.g.:
FOO PROC C=' ' (set C='' to bypass step!)
S EXEC PGM=WOMBAT&C,COND=(0,LE)
PEND
(Now you know how I got to be the way I am.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
