In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >I certainly remember (though obviously not as clearly as Mr. Blair) a day and age when overriding DD statements were required to appear in the same order as the overridden DDNAMEs in the proc. I was delighted to see the constraint relaxed. Suppose someone who does not know that proc X is used by 10 other jobs with overriding DDs in them decides to rearrange the DD statements within proc X. Which mode of processing by IBM would be better? Another possibility is that beaucoup jobs use overrides for a universally available vendor proc like ASM, LKED, FDRxxx, CAwhatever, etc., and then the vendor decides to rearrange the DD statements within the distributed machine-readable PROCLIB containing that proc. Yes, I know, we can blame change control when the inevitable errors are found. But it would be better to avoid the errors than to find someone to blame when they occur. This situation seems to me to be analogous to users' building job streams that use output from utilities like IDCAMS as their input and require data set names to begin in column X and volser in column Y, e.g. Then IBM changes the format of the utility's output. And it's not limited to IBM. Data centers also have locally developed programs that generate SYSOUT which is then used as input for other programs, and the developer in charge of a utility cannot be expected to know all the downstream users of his SYSOUT. Bill Fairchild Rocket Software
**************Get fantasy football with free live scoring. Sign up for FanHouse Fantasy Football today. (http://www.fanhouse.com/fantasyaffair?ncid=aolspr00050000000020) ---------------------------------------------------------------------- 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
