|
In a message dated 97-09-19 07:35:49 EDT, you write: > Dean Asmussen (DAsmussen@aol.com) wrote: > > >> Truth is, it depends. Like, where do you put the new fields, in > >> the middle or the end? Should be at the end, but we don't always do as we > >> should, do I? Then you <bold>might</bold> not have to recompile dependent > >> programs. If in the middle, you'll definitely need to recompile. > > > >Why should the fields go at the end? With the prevalence of query > >tools, I'd think that you'd want them grouped with like elements. > > If you're going to use LVLCHK(*NO) to avoid recompiling programs that > reference the file for input, then you have no choice but to put the new > fields at the end. The programs will be using the record definition as > it was at before the layout changed. If you put the fields at the end > they simply won't see the new fields. Put them anywhere else and all > hell will break loose. Ahhh, but I DISAGREE with level check *NO. Has NOBODY out there ever modified a program that was once input-only to allow maintenance? What will happen to your LVLCHK(*NO) if some programmer uses an old x-ref prior to the aforementioned change to determine what programs to re-compile when he/she makes the NEXT one? Just what is the BIG DEAL about re-compiling all programs that use the file -- heck, I could crank out a CL to do it automatically in less than half a day... > >Personally, from a "purist" standpoint, I disagree completely with > >the entire premise of the new CHGPF functions. If the customer > >WANTED an SQL database, they'd have bought a PC with SQL > >Server or some such and used the ALTER TABLE command -- > >but they didn't. They wanted an AS/400. Known for its reliability, > >ease of maintenance, and cross-application integrity. Having the > >ability to change files and fields "on the fly" takes the AS/400 two > >steps back to program-described files. If I wanted THAT, I'd have > > stayed with the S/36... > ><<snip>> > > Actually I'm all in favour of it. It doesn't do anything you couldn't do > before, and it doesn't work instantaneously. It's not "on the fly" in > that sense. It just makes a complex process simpler and less error > prone. I can't see that's such a bad thing. How so? I'd appreciate the "particulars"... Regards, Dean Asmussen Enterprise Systems Consulting, Inc. Fuquay-Varina, NC USA E-Mail: DAsmussen@AOL.COM "Everywhere is walking distance if you have the time." -- Steven Wright +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "MIDRANGE-L@midrange.com". | To unsubscribe from this list send email to MAJORDOMO@midrange.com | and specify 'unsubscribe MIDRANGE-L' in the body of your message. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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 copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.