Re: LVLCHK(*NO)

Couple of exceptions to what you have said here Vern.

It really only applies to RPG. In COBOL for example the whole record is mapped and could in theory be accidentally changed. Same applies with C - I don't use files in CL so not sure of that.

In RPG it is also not true when DS I/O is used.

Personally unless all I/O is via SQL I would never use LVLCHK(*NO) - it is one of those accident waiting to happen scenarios.


Jon


On Jan 29, 2021, at 8:37 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx> 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 !

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com