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?
--- [email protected] wrote: From: Mitch <[email protected]> To: [email protected] Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) Date: Thu, 7 Nov 2013 12:34:39 -0500 Ze'ev, I work with a product that would prevent this type of thing from happening. JCL that does not meet site requirements would never make it into production. It can also optionally be prevented from being added to the production batch schedule, if so desired. Regards, Mitch McCluhan, Legacy Modernization Consultant www.lcmg.us -----Original Message----- From: Ze'ev Atlas <[email protected]> To: IBM-MAIN <[email protected]> Sent: Thu, Nov 7, 2013 8:39 am Subject: Re: JCL (was: Re: Aging Sysprogs = Aging Farmers) 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 ZA ---------------------------------------------------------------------- or IBM-MAIN subscribe / signoff / archive access instructions, end email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN _____________________________________________________________ Netscape. Just the Net You Need. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
