While your examples are not false, they're hardly true either. In my many years of MV programming, I've never seen such alternate files or other methods. The closest I've seen is code within the program to decide which files to use.
I think you are implying contemporary intelligence against an old technique. This entire application is written this way so the chances of having EVERYTHING have alternate files is pretty slim. Thanks Mark Johnson ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Friday, June 29, 2007 11:08 AM Subject: RE: [AD] [U2] Basic developments "reverse engineering" tool ? > Just to play devil's advocate, there ARE good reasons for doing the code that > way: > > 1. The same program can be used for processing live and historical data if > they're in different files. Just create two procs and pass live files in one > and historical files in the other. > 2. The same program can be used for other file sets - assuming it's a > generic routine. > 3. Filenames can be changed without having to recompile the program. > Although it's a little safer in U2, recompiling code out from under a user > isn't a good thing in most flavors of Pick - unless you enjoy sending them to > a RIF error. > > Again, I'm not saying there aren't better ways to do it, but there are legit > reasons for this type of code - and who knows how long ago the code was > written too. > > My 1.5" > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Norman Morgan > Sent: Friday, June 29, 2007 9:02 AM > To: u2-users@listserver.u2ug.org > Subject: RE: [AD] [U2] Basic developments "reverse engineering" tool ? > > Joking aside, that looks almost like something written by someone who > was accustomed to writing mainframe COBOL where actual file assignments > were made outside the program code in JCL. That doesn't excuse the > internal naming style, but the technique harks back to my "misspent > youth" as a COBOL programmer. > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Timothy > > > Snyder > > > Sent: Friday, June 29, 2007 8:21 AM > > > To: u2-users@listserver.u2ug.org > > > Subject: Re: [AD] [U2] Basic developments "reverse > > engineering" tool ? > > > > > > > One of my clients has procs like this: > > > > > > > > HRUN BP SOP1500 > > > > STON > > > > HORDER< > > > > HCUSTOMER< > > > > HPRODUCT< > > > > HVENDOR< > > > > P > > > > > > > > whereby the program (BP SOP1500) has the corresponding INPUT > > > > statements > > > for > > > > the file names and opens them as F1, F2, F3 which is a real > > > bear when > > > > reading the code. > > > > > > Wow - that's just plan mean! There may have been a thought that it > > > was a way to avoid hard-coding file names in case they ever changed > > > (though that would be a weak argument), but then they're > > hard-coded in > > > the PROC, so I can't see any benefit at all, other than > > obfuscation. > > > The person that created it must have had a future grudge against > > > whoever came along to maintain the code. "Take my job from me, did > > > you? > > > I'll teach you a lesson." :-) > > > > > > Tim Snyder > > > Consulting I/T Specialist > > > U2 Lab Services > > > Information Management, IBM Software Group > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. > Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is > strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
