|
Also FWIW, LVLCHK(*NO) really shouldn't be an issue if the application is designed decently and modified later appropriately. For most files, is there good reason to have more than a single program access the physical file? If access is through appropriate logical views with explicit field lists, then physical files can have fields added easily, at the end, beginning or middle. Just recreate the LFs and there are no level checks except for the single program that accesses the physical file. Only the single program needs to be recompiled (or run as LVLCHK(*NO) but I couldn't recommend that). Naturally, I realize that existing applications can have trouble; but I thought the original question was forward-looking. Tom Liotta ----- Original Message ----- From: rpg400-l-request@midrange.com > 1. RE: LVLCHK(*NO) (Frank.Kolmann) > > FWIW, I often use LVLCHK(*NO) to move into production a > file that I add fields to (note. never insert the new fields > between existing fields nor change existing fields). > BUT, later at a more convenient time I always recompile all > programs using the file and when that is done I switch the > file to LVLCHK(*YES). > It is nice to be able to separate the task into 2 stages, > the first is concentrate on getting the fix/change done then > later recompile related objects.LVLCHK lets me do this > and I still feel safe that the external file defns are > up to date in all my programs. > > Frank Kolmann > > > -----Original Message----- > From: J Michael Smith > > After reviewing the archives, I find that most would not recommend using > LVLCHK(*NO). > > With that as a given, we are considering adding two alpha(3 position > fields) > to a master file. There are no changes of any kind to the previous > "fields" > and the new fields will be added a the end of the DDS. > > Can someone tell me why using LVLCHK(*NO) would the a bad thing to do in > this situation. > > Michael Smith > -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
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.