Re: LVLCHK *NO

     Bill,
     
     You are correct in your understanding.  When the file is created, the 
     record layout is hashed into a record format level identifier, which 
     can be seen with DSPFFD.  When a program is compiled that uses the 
     file, the level ID is stored in the program and compared at run time 
     to that of the file.  The reason for this is basically that at compile 
     time, the compiler generates I-specs to match the field layout in the 
     record format.  If the file layout changes, the I-specs don't 
     necessarily still reflect the locations of the fields in the record 
     buffer.
     
     If the file has changed and the program not recompiled, the result 
     depends on how the layout changed.  If fields were added at the end of 
     the record format, and nothing else changed, it shouldn't cause any 
     major problems.  In fact, this is generally why LVLCHK(*NO) is used - 
     to allow this type of change without having to recompile.  If fields 
     were added anywhere else, or fields were removed or sizes changed, any 
     existing programs will no longer work correctly.
     
     It _is_ a bad practise.  Generally it indicates an unwillingness to 
     chase down the programs that use a file, and do a proper upgrade 
     procedure.
     
     ____________
     Paul Cunnane
     The Learning Company
     


______________________________ Reply Separator _________________________________
Subject: LVLCHK *NO
Author:  Bill Graziano <Bill.Graziano@besi.com> at InterNet
Date:    30-09-99 10:24 am


I use a third party software package where the physical files are compiled 
with the record level check field set to *NO (LVLCHK *NO). I was raised to 
believe that this is NOT the preferred setting for this parameter, because 
it helps keep the programs and files they were compiled against "in sync". 
In other words, if the file definition changes and the program is not 
recompiled, a runtime error will result. This will then alert the programmer 
of the problem. The issue I that I believe exists is to the custom rpg 
applications that we have written in the past that use these files. We are 
preparing to do a version upgrade. Some of the file definitions have 
changed. If I do not recompile the custom programs using the new file 
descriptions, I believe that I will not get a runtime error. 
     
1) Am I correct in my understanding of LVLCHK *NO?
2) If the file definition HAS changed but the program has NOT been 
recompiled, what file definition is the program running against, and what 
results can be expected? 
3) What would be the most likely reason a third party vendor would use 
LVLCHK *NO?
     
     
Thanks in advance for your time (and knowledge) 
Bill Graziano
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---