Re: QDFTJOBD in QSYS not found

On 18-Sep-2015 09:47 -0600, Glenn Gundermann wrote:

We have some system users with a job description of QSYS/QDFTJOBD.
QAS400NT
QEJBSVR
QIPSJOB
QRJE
QSRV
QSRVBAS
QUSER

The thing is that QDFTJOBD is in QGPL and not in QSYS.

IIRC the OS was modified [sometime since the S/38] to be more forgiving of a missing *JOBD for starting a job, and the effect at run-time\startup is the establishment of the QDFTJOBD in QGPL for the Work Management setup. As such, the effect would be minimal for disruption; i.e. except for a diagnostic condition being logged, the implicit recovery from the current issue for JOBD(*doesnotexist), the effect is the /same/ as when the users have JOBD(QGPL/QDFTJOBD) explicitly specified.

I'm thinking that it must have changed at a certain release. I'm not
sure if the user profiles are correct or if the job description is in
the wrong place.

Do I change the user profiles so that jobd = QGPL/QDFTJOBD or
CRTDUPOBJ QDFTJOBD to QSYS or what?

I do not recall ever that the Default Job Description object QDFTJOBD was in QSYS. I suspect those profiles were changed by a user-request rather than established that way as part of an install\upgrade. Reviewing the last "Change Date/Time" object attribute for those user profiles, possibly would reveal when that change was made; all may have been changed on the same date [and nearly the same time]. If that change date\time was during an install\upgrade, then my supposition likely would be incorrect; if sufficient history [or auditing] exists to confirm what was happening at that time, I suspect the value will not correlate to an OS install.

The Change User Profile (CHGUSRPRF) command, for specification of an unqualified non-existent *JOBD, will fail with msg CPF2242; i.e. per the default for the library qualifier being *LIBL. For a qualified specification, only a diagnostic [or oddly, perhaps an Information] msg CPI2243 is used to inform\warn that the specified Job Description does not exist, yet the non-existent qualified-name _is accepted_, with an assumption that the object might [be intended to] exist prior to starting a job with that User Profile (USRPRF) object. Thus by user-change, specified as CHGUSRPRF JOBD(QSYS/QDFTJOBD), the change would have taken effect despite there never having existed a JOBD with that name.