× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



There has been discussion about this exact scenario, adding fields to the end 
of a file.

If you can guarantee that that is the place you will ever add new fields, at 
the end of the record, then some people do compile with LVLCHK(*NO) for your 
scenario.

There have been other discussions about this also, such as not having any 
programs open up the physical file itself, but only logical files and the 
fields that are needed, and compiling with LVLCHK(*YES) to the logicals.  You 
can still change the physical and add new fields without the programs 
complaining about level checks, and you could just change the logicals that 
needed the new fields, and be required to only compile the programs that would 
be effected by the new fields.  There are some drawbacks to this, the main one 
being now you have to maintain the list of fields not only in the physical file 
DDS but in the logical file DDS.

There has also been talk about having programs read fields through ILE 
functions, but field mapping seems to be a major block and I don't know if 
anyone has actually succeeded in this in any large applications.

So, I guess my answer is... it depends.

Regards,

Jim Langston

-----Original Message-----
From: J Michael Smith [mailto:JMichael.Smith@arch.com]

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.