Re[2]: CHGPF Question

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

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