|
I dunno, Buck. If I followed the one proc/one page rule, I'd have hundreds of procs for a given application, each having logic that wouldn't be used anywhere else. Ok, so *maybe* you're not limiting yourself to *absolutely* one page. I would remind you that several weeks ago, I was the one getting beat up by Jon & Barbara & others in this very list for refusing to create one-line subroutines, i.e.: C S0_DONE BEGSR C EVAL *INLR = *ON C ENDSR @#$*&!!! These drive me crazy! I realize, from the list response, that I am likely in the minority. I like to think there's more of a balance between one-line subroutines and monolithic programs. Oh, and thanks for not lecturing. <g> Joe, thanks for the compliment. I am reminded that bleeding-edgers like myself (?) have to get past the "gee-whiz" giddy do-it-cuz-it's-new mindset and remember that my higher-ups require a business case for utilizing new technology (including new compiler features). Part of the problem of presenting an argument to do something new is that, without experience, your facts come from a magazine article or <gads> a mailing list thread. All the answers to the questions are prefaced with, "supposedly" or "from what the article says", which does not instill the greatest confidence. I actually *did* suggest in the meeting yesterday shifting new development to use service programs to handle all file I/O so that no application code ever has to do this. This, I thought I remembered from previous list discussions, could alleviate some of the performance concerns of having all of these modules reading from the same files. But that was too much, too fast. It seems a lot of our discussions on using new, esoteric (for us) techniques usually are acknowledged but eventually shot down with the phrase "In a perfect world". <g> As I indicated earlier, this shop is still light years ahead of any other shop I've worked for. Good things are happening. TIA, Dan __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.