RE: LVLCHK *NO

[Michael Kranz <michaelkranz@xxxxxxxxxxxxx>]

Ouch!!!  Changing the file to Level Check *NO is asking for some serious 
invalid decimal data and field mapping errors.  The file definition in the 
RPG program is still referencing the OLD file format, and will do so until 
recompiled.

Understand what happens when you
        a) add a NEW field,
        b) change an existing field's attributes such as size, decimal 
position, 
alpha to numeric, etc (** note, TEXT and COLHDG changes are NOT a concern 
and do not change the Record Format Identifier)
        c) delete a field

you've changed your field mapping.  The PF compiler looks at the # of 
fields, field names, relative positions to each other, size, and data type. 
 It rolls them through an algorithm and calculates the Record Format 
Identifier, unique to that file and the # of fields, field names, etc. 
 Change any one of those, recompile the file, and the Record Format ID 
changes.  You can copy the PF source to 100 AS/400's, compile on each, and 
the Record Format ID is the same on all 100 boxes.  To see it, perform
        DSPFD filename
        and go to the bottom.  Look for the Record Format ID and value.

During the RPG compile, this Record Format ID is mapped into the program. 
 To see it, perform
        DSPPGMREF programname
        and search for the file.  Look for the Record Format ID and value.  
This 
will be the same value you see on the DSPFD.

When the program is called and the file is opening, the operating system 
compares the Record Format ID in the program to the one on the file.  If 
different, the program generates a runtime error, UNLESS you specified 
Level Check *NO.  In which case the program opens the file using the RPG 
program's definition of the file.  If you've increased the field length of 
field ABC by 4 bytes, then field DEF you think you're updating is really 
the last 4 positions of field ABC and the first 2 positions of DEF.

Now you have corrupt data!!!

Understanding that recompiling a boatload of RPG programs can be a pain in 
the schedule, it's worth it because you're still safeguarding that all 
files are mapped properly to the files.

Why would a third party vendor use LVLCHK *NO?  Because if they recompile 
all of their programs they have to RETEST all of their programs, and this 
takes time and $$.  They're shortcutting their own development process at 
the expense of the client's data.

Bill, in all of the classes I've taught, and at all of the clients I've 
worked, I have NEVER recommended this approach, since you now open the door 
to corrupting your data.

"BE AFRAID.  BE VERY AFRAID!!!"

Michael D. Kranz
The PowerTech Group
Seattle - Kansas City - St. Louis
Your AS/400 Technology Source

office:   913.888.6699
mobile:  913.488.TECH

AS/400 Training:................... http://www.400School.com
AS/400 Security Software........ http://www.400Security.com
Consulting Services................ http://www.PowertechGroup.com
=======================================



-----Original Message-----
From:   Bill Graziano [SMTP:Bill.Graziano@besi.com]
Sent:   Thursday, September 30, 1999 9:25 AM
To:     'RPG400-L@midrange.com'
Subject:        LVLCHK *NO

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