Two necessary steps you left out of your example are moving the model MF=Ls and similar structures to the DSECT, and the relocation of address constants in those structures. More complexity = more places for an error to occur.
Further, I am working as a contractor, and most readers of this list are working for hourly wages, or are at least limited in what they can accomplish for their employers by the number of hours they work. I cannot justify putting more time into a program than is appropriate to its intended function, on the theory that making it reentrant would be more elegant. Obviously, I am not talking about cases where reentrancy has a tangible benefit to my employer. You ARE right that temporary programs and temporary taxes have a way of sticking around forever. But it's hard to see how my "load the product with a bunch of stupid, hard-coded DD overrides" ever makes it into daily production. I think one has to be willing to trust the good judgment of an experienced developer -- which is another way of saying what John Baker has said on this thread: there are few absolutes. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Saturday, October 21, 2006 9:34 AM To: [email protected] Subject: Re: Is the teaching of non-reentrant HLASM coding practices ever defensible? You've hit a "sore spot" with me. In my experience, anything (not just a program) that starts out as a "One Off" or "Quick & Dirty" implementation often has a way of eventually being used for daily, production use. There's always time to do something over but never enough time to do it right the first time. Like others on this list, I write 99% reentrant code and believe that non-reentrant programs and programming techniques should generally be discouraged, _especially_ when working with less experienced programmers. Of course, there are always exceptional cases in which reentrancy can/should not be used. But focusing on such exceptions gives the false impression that they are more numerous than they actually are. Bad habits are harder to unlearn than to never learn in the first place. I think everyone reading this can agree that adding something like what's shown below to a program skeleton is trivial: | STORAGE OBTAIN,LENGTH=MyWkLen | LR Rx,R1 | USING MyWk,Rx | . | . (program here) | . |MyWk DSECT , | . | . (data here) | . |MyWkLen EQU *-MyWk ---------------------------------------------------------------------- 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
