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



It's simply an OS/400 bug, because the way you explain it should be OK

JOKE(*OFF)

The Record Format level identifier is a 13 byte string (looking like a hex
string). Way back is was an arbitrary string created when the file was
created, but today it calculated by a 'secret' formula constisting of field
name and some of the attributes. If you have an old R1 s/30 file and a newly
created file, the record format level might be different. The field text is
NOT one of theese, but the length and field order is. When you compile the
DDS of the PHYSICAL file this value is calculated and stored as a part of
the file. When you compile a logical with NO format changes (except
keyfields, select/omit etc) the identifier is copied from the physical. When
you compile an RPG program the identifier is copied from the file used. Note
that a file also have a member level identifier and a file level identifier,
but here we only talk about the record level identifier.

When you run the RPG program and the file does not have LVLCHK(*NO) or is
overridden to LVLCHK(*NO) the old identifier-copy in the program object is
compared to the actual identifier from the file, and if they do not mach,
you are in bad luck.

You can se the identifier in the file (DSPFFD) and in the program object
(DSPPGMREF). When you get the level check you can dump and see the actual
file and program used (incl. their library). Another entry to the problem is
to do an DSPFFD *ALLUSR/MyFile *OUTFILE and a DSPPGMREF *ALLUSR/MyProgram.
This will wit 99% guarantee find the problem child for you.

All this is what you already are dooing? Yes, so it IS an OS/400 bug!

Btw: My DOCPGMSTR (http://hkrebs.dk/docpgmstr.html) makes the check (option
8 or F8) before the execution fails.

Henrik



> From: Refaie.Heba@khb.hu
> To: MIDRANGE-L@midrange.com
> Subject: What is really the level check
> Date: Wed, 5 Jul 2000 12:30:36 +0200
> Reply-To: midrange-l@midrange.com
>
> This is a multipart message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hello Group,
>
>        I have a small problem that I can not understand...
>
> We have got a CL program running at the end of day, this program creates a
> logical file from a dds stored in a source library and calls a number of
> RPG programs and then it deletes the file at the end.
>
> I understand that the RPG program opening this file can give a level check
> error message when something significant in the file is changed, but
> actually the Physical file structure and the logical file structure never
> changed. Once I get this problem I recompiled the RPG program and I
> thought that his should solve the problem. But the next time I got the
> same error message again. I check the record format level identifier of
> the file and the one used in the program compilation and to my surprise I
> found them the same...Could you please explain to me what I am missing or
> advise me what I should check else?
>
> Thanks in advance for your help
> Kind regards
> Heba




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.