Re: File object got deleted!

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> 1. Thinking that creating a new file from DDS will lead to recompiling 
> all programs to avoid level check error
[SNIP]
> Creating a duplicate object, to production didn't change the 
> Identifier??
[SNIP]
> Can you explain me?

What does a record format level check do, and why do we need it?

First, understand the problem that it's designed to solve:

When you compile an RPG program that uses an external definition, what it 
does is look at the fields in the file and generate I-specs (yes, the old 
fashioned input specs) in your program for you.

Since these are now compiled into your program, if you change anything in 
the record format, it would read from the wrong positions.

For example, consider the following file:

     A          R TESTFMT
     A            FIELD1        10A
     A            FIELD2        10A

When you compile an RPG program that uses this file, and use an external 
definition, the system will AUTOMATICALLY create the following input 
specs...

      ITESTFMT   NS
      I                                  1   10  field1
      I                                 11   20  field2

If you go back and change the file so tha FIELD1 is 15A instead of 10, 
you now have the following:

     A          R TESTFMT
     A            FIELD1        15A
     A            FIELD2        10A

Now FIELD1 is taking up positions 1-15 and field2 is 16-25. However, 
unless you re-compile your RPG program, it won't know that!  Instead, 
it'll continue to try to read field1 from positions 1-10, and FIELD2 from 
11-20.  That means that FIELD2 in the RPG program will actually read data 
out of FIELD1!

So, IBM insituted record format level identifiers.  The system computes a 
"checksum" or "hash" of the things that are important to the format of a 
record.  These things are the field's name, length, data type, and 
position in the record.

So, in the above example, the record format level identifier would have 
changed, since the size of FIELD1 has changed, and also because the 
position of FIELD2 has changed.

When you compile your RPG program, it reads the external definition and 
generates the input specs as I explained above.  It saves the record 
format level from the file into the RPG program's compiled object.  Every 
time it tries to open that file, it compares the one it saved with the one 
in the file. If they don't match, it knows it's input specs are wrong, and 
aborts the program.  This way, a programmer won't forget to recompile his 
program to generate the correct input specs.

Now that you understand that, why didn't CRTDUPOBJ or re-building the PF 
from source cause the record format level id to be different?  Quite 
simply because the record format was the same. Since it was the same, the 
system generates the same checksum.  The input specs that it would 
generate are identical, so there's no reason for the level id to be 
different.

Make sense?

> 2. How can we know from which AS400 id was this object deleted?. History 
> log (DSPLOG QHST) is no good.

The history log isn't intended for that sort of thing.  If you want the 
system to log who deleted files, you need to turn on object auditing. 
Unfortunately, if the file is already gone, it's too late. You need to 
turn it on ahead of time so that these sort of events are logged.

Do a search for CHGOBJAUD and CHGUSRAUD and you should find more info on 
object auditing.

good luck