MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2014

Re: CPF1301 ACGDTA not journaled



fixed

On 07-Jan-2014 13:07 -0800, Bakutis, Becky wrote:
We recently restored data to a new P7 running V7R1. Now when the DDM
service profile job runs it is creating joblogs every minute. Message
CPF1301 is getting created:

Message: ACGDTA for 712257/QUSER/QRWTSRVR not journaled; reason 1.
Cause: Job resource accounting data for job 712257/QUSER/QRWTSRVR was
not journaled to the system accounting journal QSYS/QACGJRN. --
Reason codes and their meanings follow: -- 1-The accounting level
system value (QACGLVL) indicated that this level of resource
accounting was not to be done when the job entered the system.

System value QACGLVL is set to *NONE. Everything I have read states
to ignore this error. I am concerned that it is creating so many
joblogs. The jobd is set up with message logging of 4 0 *NOLIST with
End severity of 30. The joblog shows a severity of 30 for CPF1301.
Someone suggested adding *JOB to the QACGLVL system value plus
whatever else needs to be done. This is not a fix, but is it the
right solution?

My recollection also is that the msg CPF1301 in that [and various other] server job(s) is innocuous, as others state; i.e. merely a side effect of an explicit or implicit request to effect Change Accounting Code (CHGACGCDE), I believe at the start of reuse of each job.

Thus, just ignore that message...

Instead, investigate what is causing the jobs to spool a joblog; which is almost surely *not* the CPF1301. I would probably review a job trace to see if I could infer a reason... but perhaps searching the IBM support or the web more generally might find a similar issue being resolved.

There may be a trace or debug feature active, for which producing the joblog is the side effect; e.g. the IBM DRDA/DDM QRWOPTIONS Debug Data Area. For that specifically, review the following KB article [found be a web search of QRTWSRVR] to see what might have been done to start forced logging and thus infer how to reverse the effects:

www.ibm.com/support/docview.wss?uid=nas8N1019545
_Getting Job Log from QRWTSRVR Job_
Technote Reference #: N1019545
Historical Number: 21063654
"... Refer to Rochester Support Center knowledgebase document N1017342, IBM DRDA/DDM QRWOPTIONS Debug Data Area, for more information on the QRWOPTIONS data area. To link to document N1017342 <www.ibm.com/support/docview.wss?uid=nas8N1017342> ..."

Although not helpful with regard to reducing the occurrences directly, these may mitigate the effects on the system Work Management for number of jobs on the system and the amount of spool data maintained.

The effect of /detach/ of the joblog feature from tracking to the job may be of some use. The Job Description could be changed to have SPLFACN(*DETACH) instead of SPLFACN(*KEEP). There is a system value QSPLFACN.

Also there is the Job log output (LOGOUTPUT) setting for the JOBD, [there is a system value QLOGOUTPUT] and that is discussed in the following archived message; a doc link included after:

http://archive.midrange.com/midrange-l/201005/msg00408.html
Subject: QRWTSRVR jobs in JOBLOG PENDING status?; go CLEANUP!
From: <elehti@xxxxxxxxxxxxxxxxxx>
Date: Thu, 13 May 2010 12:48:47 -0500

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzalu/rzalucontrolnumber.htm
IBM i 7.1 Information Center -> Printing -> Basic printing -> Managing printing -> Managing spooled files
_Controlling the number of spooled files_






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact