× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: CHGPF Question
  • From: DAsmussen@xxxxxxx
  • Date: Fri, 19 Sep 1997 20:03:55 -0400 (EDT)

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 thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.