Re: LVLCHK(*NO)

I am aware of several shops that work this way. Just always be sure to add fields to the end of the record format and never remove anything. They have been successful at this for decades and they modify code every day.

I do not recommend this and never have. I refer to it as the 'lazy man's approach' though I've been told 'hey we're just letting the computer do the work.' OK I suppose.

I think Vern is spot on here. I also agree that with SQL taking a larger and larger role it does make less difference. Just a side note: If you are NOT using SQL, you should be!

- DrF


On 1/29/2021 8:37 AM, Vernon Hamberg wrote:

Hi Dave

I'll jump in where angels fear to tread, perhaps.

Your program knows nothing about the new fields - it uses a buffer that contains only the other fields it already knows about.

My understanding is, the data in the new fields is not brought into memory in any meaningful way - your program won't change them even by accident.

Now does the new program use those fields? Probably not. I think there will be no ill effects.

Now although I generally support checking the format level, as we use SQL more and more, that becomes less used - SQL functions know nothing about format level checks.

Anyhow, I'm happy to be found incorrect. Learning happens every day, I hope.

Cheers
Vern

On 1/29/2021 7:11 AM, Dave wrote:

Hi,



I was rather surprised to discover that in my current shop, it is a regular
practice to use files in this way, thus avoiding (sometimes) the need to
recompile some of the programs sources where they are declared.

I’ve just modified such a file, placing a couple of new fields at the end
of the DDS. The program seems to function normally. But what happens
exactly when the program reads the file ? Surely, the memory pointing to
the new data somewhere is modified. Where is it and how can one be sure
there can be no ill effects ?



Thanks !