Re: Upgraded to V5R4 and joblogs for normal completed jobs are now being produced

Don't forget to look if the user is closing the client access session
without doing a sign off.. This will cause a joblog, because the session
ends in error.



From:
CRPence <CRPbottle@xxxxxxxxx>
To:
midrange-l@xxxxxxxxxxxx
Date:
10/15/2009 05:09 PM
Subject:
Re: Upgraded to V5R4 and joblogs for normal completed jobs are now being
produced
Sent by:
<midrange-l-bounces@xxxxxxxxxxxx>



Rubino, Jim wrote:

What did the upgrade change to cause user when they sign off at
the end of the day to have joblogs produced, whereas on the
previous release (V5R3) did not? Is there a system setting or
user profile setting or jobd setting?

Any help will be greatly appreciated.

How the user signs off from an interactive session is what
determines whether a joblog is produced. So neither a *JOBD nor an
attribute of the *USRPRF apply, and the effective system setting is
the LOG() parameter of QSYS/SIGNOFF; i.e. there is no LOG(*JOBD),
LOG(*USRPRF), nor LOG(*SYSVAL) available on the QSYS/SIGNOFF command
used to sign off from the interactive session. The default behavior
was unchanged from prior releases; i.e. was, and remains, LOG(*NOLIST)

Review one of the joblogs and determine the last command issued.
If the last command was an unqualified SIGNOFF with no parameter
specifications, then investigate the LOG() parameter default on all
of the SIGNOFF commands; e.g. see result of ?ALTQSYS/SIGNOFF. If
the last request was a custom command such as unqualified LOGOFF,
then investigate each command definition by that name using DSPCMD &
review of parameter [defaults] by prompting; determine if any of its
parameter defaults or the CPP [command processing program] might be
effecting LOG(*YES) on its qualified invocation of QSYS/SIGNOFF.

Regards, Chuck