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

The signoff command is still set to *nolist and all of our users jobd
are set like this:
Message logging:
Level . . . . . . . . . . . . 4 0-4, *SAME
Severity . . . . . . . . . . . 00 0-99, *SAME
Text . . . . . . . . . . . . . *NOLIST *SAME, *MSG, *SECLVL,
*NOLIST
Log CL program commands . . . . *NO *SAME, *NO, *YES

I looked into the spooled file loblog and the job logs that are getting
created are from the user being signed on and the system timing them out
for inactivity and then the system ending their job.

Is there a way to NOT have a loblog for when this happens?

TIA
Jim



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob P. Roche
Sent: Friday, October 16, 2009 8:29 AM
To: Midrange Systems Technical Discussion
Subject: Re: Upgraded to V5R4 and joblogs for normal completed jobs
arenow 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