On Mon, 28 Jul 2008 15:58:53 EDT, IBM Mainframe Discussion List wrote: > > >In a message dated 7/28/2008 10:55:50 A.M. Central Daylight Time, >PaulG 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.
Why ever would anyone do that? >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 I believe that the recent behavior where overriding DDNAMEs are associated regardless of order would be more robust under such a change than the older behavior where DDNAMEs newly out-of-order would be treated as added rather than overriding. >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. > We have a program that postprocesses assember and binder SYSOUT. It was broken by HLASM and we adapted it. It is further broken by Tachyon, so that to use that postprocessor we revert to HLASM. But it's unthinkable that HLASM wouldn't support 31-bit addressing. Perhaps in some distant future it will even be 64-bit savvy. And there will be LPA above-the-bar. -- 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
