× 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[2]: CHGPF Question
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Mon, 22 Sep 1997 11:46:18 -0400

<snipping about LVLCHK(*NO)>
>
>I know that I sound like I'm whining at this point (and perhaps I am), but
>WHAT IS THE BIG DEAL with compiling all programs that access a given file???

Downtime.  The customer is unable to do production during the time that the
programs, etc. are compiling.

For me, this is the ONLY issue in recompiling, and the ONLY reason I've used
LVLCHK(*NO) in the past.  In the past, I've made every effort possible to help
maintenance by: Blinking comment at the top of the DDS source, changed the
text to note that LVLCHK(*NO) is in effect, and commented the specific fields
that were added...

Dean brought up a point which seems very convincing to me, and that is
"what about the other platforms that access the /400 database?"  That is, 
there are PC applications (Visual Basic, Delphi, ODBC, etc.) as well as
possible FTP applications that can access our database.   If I take the
traditional view that the database is on the /400, and that only /400 apps
use it, then I'm going to sink some poor bugger on the PC if I change the
database without conferring with everyone involved...

After listening to some of the concerns that have been voiced about
LVLCHK(*NO), I've come to the conclusion that the real issue is not
the LVLCHK parameter, but whether I've done my homework on the
change.  Do I understand all the downstream ramifications of the
change, or am I just charging ahead with a shortcut that'll come
back to haunt me later?

Personally, I think that the use of LVLCHK(*NO) had it's place in the
past, but I can see that I'll need to do a lot more research before I
make any database changes.  That research will have to include
effects on outside access to the /400 database as well as what 
programs on the /400 are affected.  After that research, 
I still may find that LVLCHK(*NO) is the appropriate course to take, 
but I must admit that I'll be much more cautious before I take it.

Buck Calabro
Commsoft, Rensselaer, NY

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