Re: Function CHGACGCDE not allowed.

On 2/28/11 7:46 PM, Chamara Withanachchi wrote:

In our Day End Program it tries to change the Accounting Level by
using CHGACGCDE command but it is giving an Error message I have list
the messages

CPA0702 "CPF180B received by procedure PCOMBDAILY. (C D I R)
Cause . . . . . : ILE Control language (CL) procedure PCOMBDAILY in
module PCOMBDAILY in program PCOMBDAILY in library I720MSDBP detected
an error at statement number 0000089020. Message text for CPF180B is:
Function CHGACGCDE not allowed. Use F10 (if available) or the Display
Job Log (DSPJOBLOG) command to see the messages in the job log for a
more complete description of what caused the error. If you still are
unable to solve the problem, please contact your technical support
person.
Recovery . . . : This inquiry message can be avoided by changing the
procedure. Monitor for the error (MONMSG command) and perform error
recovery within the procedure. To continue, choose a reply value.

550 - CALL PGM(STM004)
556 - CLRPFM FILE(SHR00101)
Member SHR00101 file SHR00101 in I720SDBDTF cleared.
557 - CALL PGM(SHR002)
Environment variable added.
Java Virtual Machine is Classic.
Environment variable removed.
- RETURN /* RETURN due to end of CL program */
- RETURN /* RETURN due to end of CL program */
89000 - CHGDTAARA DTAARA(RESTART (1 10)) VALUE(CLRFILES)
89020 - CHGACGCDE ACGCDE('001CLRFILES')
Function CHGACGCDE not allowed.
Function check. CPF180B unmonitored by PCOMBDAILY at statement
0000089020, instruction X'0000'.
CPF180B received by procedure PCOMBDAILY. (C D I R)

Program: BPCOMBD Library: I720LSDBP Module: BPCOMBD
1 PGM
2
3 /* Variable Declaration */
4 DCL VAR(&RTNVAL) TYPE(*CHAR) LEN(1) VALUE(' ')
5
6 /* Call Transaction Server Batch Audit Program */
7 CALL PGM(SPD001R) PARM('A')
8
9 /* Check the Month End */
10 CALL PGM(CHKMONE) PARM(&RTNVAL)
11
12 IF COND(&RTNVAL = '1') THEN(DO)
13 CALL PGM(MONBPCOM)
14
15 ENDDO
Debug . . . THREAD(*SERIALIZE)

MONBPCOM program calls the SHR001R program and it is calling some
Java Classes. The SHR001R program compiled with THREAD(*SERIALIZE).
Can any one tell me how to overcome this.

The CL command CHGACGCDE "is conditionally thread safe. Access will be denied if the job being changed has secondary threads active. This command may be issued from either the initial thread or a secondary thread of a multi-threaded job if the target job is single threaded." Having serialized threads does not equate with a "single" thread active as the requirement alludes.
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/cl/chgacgcde.htm

The multi-threaded application could wait for all secondary threads to complete before returning control to the CLP. Or the CLP could await that condition if ending of secondary threads occurs naturally. In that manner, the later Change Accounting Code CL command request can be performed because\when only one thread remains active.

Using a thread safe method to change the accounting code, if one is available, might be an option. However that is not likely, since even the Change Job (QWTCHGJB) API suggest that the key Attribute "1001: Job accounting code" is scoped to the job and not threadsafe for any of the formats:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/apis/qwtchgjb.htm

Generally not a reasonable option, but SBMJOB can be used to perform some of the activity in a separate job to avoid the conflict; ensuring the desired AcgCde value is set before multiple threads are started.

Another option is to MONMSG CPF180B to ignore the condition, if changing the accounting code is not mandatory. If the value shown might be phase\logging information rather than actual "job accounting" information, that might be reason enough to utilize an alternate means for those phase\log details for the application; i.e. do not use "job accounting" feature for something other than the purpose of "job accounting", and in this scenario being sure to use a threadsafe feature.

Regards, Chuck