Re: Who deleted DSPF object?

On 13-Nov-2013 12:38 -0800, Tim Adair wrote:

<<SNIP>> Someone (or something) deleted a display file (type
*FILE, attribute DSPF) from our system today.
<<SNIP>>

Possibly, the object could have been moved or renamed vs deleted.

Assuming I'm just out of luck for now, I recreated the DSPF and
changed *PUBLIC authority to disallow deleting, but I'm not sure if
that's really going to help - I think that may be for deleting
records, not the object itself.

The /Object right/ AUT(*OBJEXIST) controls the ability of a user to delete the object. The /Data right/ AUT(*DLT) controls the ability of a user to delete data [from the data portion of the object], if an object has [conceptual] data capabilities; e.g. a database *FILE had data-records.

The symbolic authority of *USE does not include either of *OBJEXIST [object existence] object rights or the *DLT [data delete] data rights capabilities. So rather than revoking specifically the *OBJEXIST right, the typical resource-level control is assigned as *USE; thus giving only the *OBJOPR, *READ, and *EXECUTE rights to the user or public.

I tried setting up a journal, but you can't journal a DSPF.

As with data rights being specific to data, so too is journaling.

Any thoughts? (We're on 7.1)

If general object-level user action auditing is in effect, then finding the culprit is easy; minimally, the QAUDCTL system value must include *AUDLVL: The CPYAUDJRNE or DSPJRN QSYS/QAUDJRN can be used to look for the T-DO (Delete Object; e.g. DLTF) and T-OM (Object Management; RNMOBJ and MOVOBJ) entries. For the T-DO entry to have been logged, requires *DELETE was enabled, and for the T-OM to have been logged, requires *OBJMGT was enabled, in the QAUDLVL and QAUDLVL2 system values when the [delete or objmgt] action occurred. Or for specific user-level user action auditing, per explicitly requested of the specific user via CHGUSRAUD, those same action-auditing types need to have been enabled.