RE: LVLCHK *NO

Some friday afternoon musings.....

I have some thoughts on level checking,  born out of past experience,  and when 
I express them I often get the reactions that have been expressed by Dave, 
Chris and Michael already !  However,  I have experienced the advantages of 
using lvlchk(*no), and this is a discussion forum after all....   so....  here 
goes..... !

Level checking allows programs to express their concern when they are run over 
files that have changed since the program was compiled.  Of course, this is a 
natural thing for a program to want to do !  If I was a program and I'd been 
running happily for years using a file that had 15 fields and then one morning 
just as I was firing up I realised the file now had sixteen fields, I would be 
concerned - like - "hey guys, what d'you expect me to do with this sixteenth 
field ? - dont you want to change my code to do tell me what to do with it, or 
at the very least recompile me, so I know where it is and what it looks like 
when I'm dealing with all the other fields around it ? "

As the programmer/developer, I have the choice of recompiling the program or 
ignoring any level checks.  By taking the second option, I am effectively 
saying "its ok, I know the file has changed, but trust me - you dont need to 
know about it.  I would have recompiled you if it was important for you to know 
about it !"

"Trust me - I'm a programmer" doesnt have quite the same ring as "Trust me - 
I'm a doctor",  I know !  :)

When might I do this ?

Well, I can give one example from my own experience. Consider  a system where 
every physical file has one logical file created specially for updates.  It 
shares the unique access path with the physical or one other logical used for 
read-only purposes. These "update-only" logicals are created lvlchk(*yes), all 
others, including the physical, are created lvlchk(*no). When adding a new 
field to a file, the process is add the field, assign a default value, 
re-create the file & its logicals, recompile any program referencing the 
"updates-only" logical, plus any others that you know need access to the field 
you just added.

You could even use the share(*yes/*no) parameter in the same way.  Create the 
"updates-only" logical share(*no), the others share(*yes).  All interactive 
inquiry programs would then share any existing odp when opening files. Except 
for the ones that were being updated !  Big potential for performance 
improvements.

On the one site where I encountered this approach, machine performance was 
excellent due to these and other considerations that went into the design of 
the database and the programs.  The lvlchk(*no) share(*yes) approach was one 
part of an overall design philosophy.

The consequence of the lvlchk(*no) aspect of the design philosophy were  :- 

1. The only programs logged out for changes were those with genuine changes to 
functionality.
2. Fewer programs were moved between production and development.
3. Testing time was reduced.
4. The cost of implementing such changes was less than it would otherwise have 
been.
5. On those occasions when changes were made to one of the system-wide master 
files, the guy doing the implementation got home in time for Sunday lunch 
rather than supper !

The price paid for this was that it was much more important to have good 
knowledge and reliable information about the database, to know where files were 
used and updated.  If we did miss compiling a program that needed to be 
recompiled, then  "Unpredictable results would occur" .  A major disadvantage, 
I agree. But in four years there were no major catastrophes that I remember, 
and few minor ones. Certainly no more than at other sites.  

So, yes it can be dangerous, but there is a difference between using 
lvlchk(*no) to get around CPF4131 messages, and using it to purposefully design 
a system making the best of what is available within OS400.

The point I really wanted to make is that by dismissing a solution or vendor,  
based on one isolated aspect of their development standards, you could be 
missing out  a system which is well-designed, costs less to maintain, and 
performs better than one of the alternatives !   Maybe I should have just said 
that at the top !!  


Nigel Waters
----------------------------

ps...   this was the same site that had one display file with over two-hundred 
formats... but thats another story !!
(strangely enough, the display file was lvlchk(*no) too !)



Dave wrote..

>>3) What would be the most likely reason a third party vendor would use
>>LVLCHK *NO?

>The third party vendor has no confidence in the integrity of his package.


Chris  wrote..

>Return your software package for a full refund.  LVLCHK(*NO) is a BIG NO NO.
>You are correct with your understanding of LVLCHK.  If the file has been
>changed you may get decimal data errors, data placed into the wrong fields,
>all sorts of problems.  The most likely reason is laziness.  Fire that
>software vender.

Michael wrote..

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




$ConflictAction: 1

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