RE: Mandatory Job Log

Chuck,

Thanks. I thought I had read somewhere that the job description could, if
defined correctly, force a joblog even if the job ended normally. Can't
find it now so maybe the dementia is kicking in again.

Jerry C. Adams
IBM i Programmer/Analyst
Money is better than poverty, if only for financial reasons. -Woody Allen
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, January 06, 2012 1:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Mandatory Job Log

On 06-Jan-2012 10:40 , Jerry C. Adams wrote:

I am having problems with a couple of users telling me, "I didn't do
that" (whatever THAT is). I wanted to force a joblog. If they signoff
using a menu option, I have SIGNOFF *LIST, but if they just type
SIGNOFF the default is *NOLIST.

I thought that changing the job description
<ed:> CHGJOBD LOG(4 00 *SECLVL) LOGCLPGM(*YES) </ed:>
and putting that into their user profile would always get a job log
no matter how they signed off. I know (because I tested it - again)
that on a SBMJOB with this job description I get a job log.

What am I missing regarding the interactive sessions?

The LOG() "Job log" parameter allows [at least] two possible values,
either *LIST or *NOLIST. The LOG parameter specifies whether a Job Log
is to be produced when the user is signed off using the SIGNOFF CL command.

What is missing is the dissociation between the LOG() parameters on
the two commands. When changing the Job Description [or the Job with
CHGJOB], the LOG parameter is the LOG() "Message logging" parameter, not
the LOG() "Job Log" parameter; the latter determines if a joblog will be
produced, and the former identifies what level of logging is included in
a joblog *if* a joblog is produced [e.g. either by DSPJOBLOG or SIGNOFF
LOG(*LIST)]

As Roger suggests, the command default for the LOG() parameter on the
SIGNOFF command could be customized using CHGCMDDFT. The effect should
be recorded in the System Change Management, and eventually undone or
re-applied as necessary; e.g. after an upgrade. Note that there may be
other SIGNOFF commands [by CRTDUPOBJ, even to another name] rather than
just proxy commands which may also need to be changed [and any
duplicated commands should also be part of SCM to ensure the old copy is
deleted and duplicated anew before re-applying the customization to the
default].

Regards, Chuck