RE: Level Check Issue

DSPPGMREF will show the record format level id that the program was
compiled over.

Mark Walter
Paragon Consulting Services, Inc.
IBM Certified System i Specialist
717-764-7909 Ext. 26
mwalter@xxxxxxxxxxxxxxx
www.paragon-csi.com



"Crispin" <cbates@xxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
01/15/2008 04:28 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Level Check Issue






Jim,

Just to be clear. You can compile a file from the same DDS as many times
as
you want, and on as many machines as you want. The format level id will
always be the same (given the same CCSID - and I'm not sure that CCSID is
actually a problem as far as Format Level Id is concerned, but _may_ cause
a
problem with CPYF, just know I ran into an issue with CCSID's recently,
but
could be mistaken on that point).

It shouldn't matter about the order that the files/programs are created.
If
the DDS _is_ the same, you will get the same format level id...

Crispin.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of James.Hawkins@xxxxxxxxxx
Sent: Tuesday, January 15, 2008 4:22 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Level Check Issue

When any object is created on the system it is given a unique ID (level
identifier). Remember that programs need to be compiled after files? The
program records the unique level ID of the file, if this is different at
run time, you will get a level check error. I immediately see several
options.

1. change objects to level check *NO (Sorry list, it is an option-I do
not recommend this one)
2. Using your example. Change the program to use OETXX instead of OET08.
Call the program from a CL program that overrides OETXX with OET08.
3. Change the program to use OETXX. OETXX is current year data. At the
end of the year, archive (CPYF) OETXX to OET08 and purge (CLRPFM) OETXX to

prepare for 2009.
4. Redefine all of the files as internally described again (and endure the

maintenance nightmare--not a recommended solution either)
5. I believe (and someone is sure to correct me if I am wrong) that if you

use CPYF of OETXX to create OET08 instead of a compile you will avoid the
level check issue, I believe that the new file copies the level identifier

of the original file.
6. Instead of creating a new file each year, make the file a multiple
member file with each year a member in the file.


Jim
===========================

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