Re: Level Check Issue

Hi, Kelley:

It sounds like you may be changing the record name in the DDS, then recompiling. That will change the value of the Record format Level ID. :-o

Instead, just give the record format name a "generic" name, e.g. "OETXX", and use CRTDUPOBJ to create each new instance of the file. And, you would need to issue OVRDBF to point to the correct files, when CALLing the RPG programs to process the data.

Or, perhaps better still, this might be a good case for using multi-member files. Each member represents one year. The member name can reflect the year. The record format names will not change, and the physical file name will not change, only the member name. Of course, you must then use a CL wrapper program to issue the relevant OVRDBFs to point to the correct member to process.

HTH,

Mark S. Waterbury

> Kelley wrote:

We have many files that are recreated each fiscal and calendar year end. They are mainly detail files for A/R, O/E, and so on. The format of the files is XXXYYN where XXX is related to the system, YY is the current year, and N is any logical files. All of the files for the new year are created automatically whenever a program that needs to update the detail files runs in the new year. They are all built off of a dummy file.

As an example, our detail order entry file for 2007 would be OET07. The first program that tried to add detail in 2008 created OET08. All of these files have been built using a dummy file, OETXX. This file hasn't changed in years. The problem started showing up as we convert all the legacy code to external files.

Almost all of the programs that use the detail files have the XX version in the file spec (OETXX if we follow the above example). It seems that everytime a file gets created for the new year, nothing but level checks. The program is compiled with OETXX and the new file is created using OETXX. The only way to get around it is to compile with level check no, which I don't want to do.

Any thoughts?

Kelley