Re: LVLCHK(*NO)

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

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