QDFTJRN in V5R4 - authority issues

All,

On V5R4, journaling all files in a library via the QDFTJRN data area
existing in that lib.

Throughout the day a number of work files are created by users via a
CRTDUPOBJ of a skeleton file. These work files are backed up that night
and deleted the following morning. I would like these work files to be
journaled for the duration of the day when created, but they are not.
The joblog says:

CPF2207 Escape 40 06/26/08 22:35:48.219648 QSYHNAUT
To module . . . . . . . . . : QDBCRTFI
To procedure . . . . . . . : FIND_JRN
Statement . . . . . . . . . : 18398
Message . . . . : Not authorized to use object MASTER in library JRNLIB
type *JRN.
Cause . . . . . : You are not allowed to do the requested function
because you do not have the correct authority. Recovery . . . : Have the security officer or the object owner give you the authority needed to do the requested operation.

The redbooks technote "Journaling At Object Creation On DB2 For iSeries" states:

*Assuring your users have sufficient authority to succeed*

For journaling to successfully start in this automated fashion, all of
the normal authority rules still apply. Because applications creating
new objects are not only creating the object but also, under the covers, are performing a start journal operation, any user adding objects to the library must have sufficient authority to both the journal specified in
the QDFTJRN data area and the journal’s library. You might recall that start journal operations require both *OBJOPR and *OBJMGT authority to
the journal and *EXECUTE authority to the journal’s library. Do not
worry that giving all your users this much authority to the journal
means that they can see information they should not. The secret to
proper authority management is that you are really dealing with two
objects: the journal to which the newly created object is journaled, and the underlying journal receiver into which the resulting object changes
are recorded. Your users need not be given authority to both objects.
You can limit how much information your users can access by excluding
their access to the journal receivers.

I have ensured that *PUBLIC has these authorities:

Library:

Edit Object Authority

Object . . . . . . . : JRNLIB Owner . . . . . . . : QPGMR
Library . . . . . : QSYS Primary group . . . : *NONE
Object type . . . . : *LIB ASP device . . . . . : *SYSBAS

Type changes to current authorities, press Enter.

Object secured by authorization list . . . . . . . . . . . . *NONE

Object -----Object------ ------Data-------
User Group Authority O M E A R R A U D E
*PUBLIC USER DEF X X X X
*GROUP QPGMR *ALL X X X X X X X X X X


Journal:

Edit Object Authority

Object . . . . . . . : MASTER Owner . . . . . . . : QPGMR
Library . . . . . : JRNLIB Primary group . . . : *NONE
Object type . . . . : *JRN ASP device . . . . . : *SYSBAS

Type changes to current authorities, press Enter.

Object secured by authorization list . . . . . . . . . . . . *NONE

Object -----Object------ ------Data-------
User Group Authority O M E A R R A U D E
*PUBLIC USER DEF X X
*GROUP QPGMR *ALL X X X X X X X X X X


Anyone know what other authority might be needed? *PUBLIC has *ALL
authority to the file itself at the time it is created (though I later
reduce that authority to *USE so when that task is completed the file
cannot be altered).

--
Jeff Crosby
UniPro Foodservice/Dilgard
260-422-7531
Opinions expressed are my own and not necessarily those of my company. Unless I say so.