Re: QDFTJOBD in QSYS not found

Thank you Chuck and Rob.

I have changed them to jobd(qgpl/qdftjobd).
It's good to know the jobs would continue without a problem. I just don't
like seeing error messages in joblogs.

Thank you again. It's always very much appreciated!

Yours truly,

Glenn Gundermann
Email: glenn.gundermann@xxxxxxxxx
Work: (416) 675-9200 ext. 89224
Cell: (416) 317-3144


On 18 September 2015 at 13:01, CRPence <crpbottle@xxxxxxxxx> wrote:

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.

--
Regards, Chuck