Why is one system's ACF2 CPF journal file not recording entries?
Article ID: 234533
Updated On:
Products
Issue/Introduction
ACF2 CPF reporting seems to be incorrect. When looking at the journal files, one system does not show the expected journal entry. It is also significantly shorter than the other CPF journal files. What is causing this?
Example - SYS1 propagates a password change to SYS2 and SYS3:
SYS1 system
2021340 094859 SYS1 TESTUSR 000268135 Extended Password Sync Request - TESTUSR
2021340 094859 SYS1 TESTUSR 000268135 Request( PSWD-VIO PWP-VIO KERB-VIO PW_UNSUSPEND )
2021340 094859 SYS1 TESTUSR 000268135
2021340 094859 SYS1 TESTUSR 000268135
2021340 094859 SYS2 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
2021340 094859 SYS3 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
SYS2 system
2021340 094859 SYS1 TESTUSR 000268135 Extended Password Sync Request - TESTUSR
2021340 094859 SYS1 TESTUSR 000268135 Request( PSWD-VIO PWP-VIO KERB-VIO PW_UNSUSPEND )
2021340 094859 SYS1 TESTUSR 000268135
2021340 094859 SYS1 TESTUSR 000268135
2021340 094859 SYS2 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
SYS3 system
No logging for TESTUSR password sync
Environment
Release : 16.0
Component : ACF2 for z/OS
Resolution
The CPF Journal file for one system was much smaller in size when it was created than the journal files on other systems causing a logging discrepancy. CPF journaling does not alert when the file is full. Instead, it wraps to the beginning of the file and continues writing entries from where it left off. While it may seem like the journal entry was never written, if there are many CPF journal entries being written then it's more likely to have been overwritten by more recent records.
CPF journal entry structure:
yyyyddd hhmmss node logonid recordid message
yyyy Year
ddd Julian date. Can be between 001-365.
hh Hour in military time.
mm Minutes.
ss Seconds.
node Relevant node name. This could be the sending or receiving node depending on the context.
logonid Logonid of the user who initiated the command.
recordid A number to identify individual command propagation requests. This can be used to assist in identifying a specific request in one node's SEND journal and a different node's RECEIVE journal.
message Relevant message containing more information about the CPF request.
Example issue:
With this information, the issue of a receiving journal file having a record being overwritten becomes more apparent. From the example issue above, the date and time this request occurred was December 6th, 2021 (Julian date of 340) at 9:48:59 AM. This request was sent to two different nodes:
2021340 094859 SYS2 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
2021340 094859 SYS3 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
SYS2's RECEIVE journal file contains the request:
2021340 094859 SYS2 TESTUSR 000268135 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL
SYS3's RECEIVE journal file does not appear to contain the request. The next step is to review the entire RECEIVE file to find the point where the records are being overwritten by reviewing the timestamps:
...Additional entries above...
2021340 110906 SYS3 TESTUSR3 000050477 CA ACF2/CPF PASSWORD SYNC UPDATE SUCCESSFUL << Latest time found on report
2021340 104205 SYS1 TESTUSR5 000205037 Extended Password Sync Request - USER5 << Earliest time found on report
..Additional entries below...
For SYS3, the earliest time still on the report is 10:42:05. The request from SYS1 at 9:48:59 has already rolled off the report.
CPF Journal sizing considerations:
Continuing the example, SYS3's receive journal file is large enough to contain about 1 hour and 27 minutes worth of records while SYS1 and SYS2 seem to contain records for a longer amount of time. It's important to remember that the exact timeframe of records held is dependent on 2 factors:
1. How many requests are being sent and received
2. How large the journal file allocation is
While the amount of requests may fluctuate, the amount of space allocated to the journal file can be modified to accommodate a system that may be overall busier than another system. To make modifications to a journal file, CPF journaling must be turned off. The following steps detail the process to make modifications to the CPF journal files
1. Stop the journaling process on the system with the following ACF2 console command:
F ACF2,CPF(NOJOURNAL)
2. Make changes to the journal files using job INITJNL in the CAX1JCL0 library (sample JCL below).
3. If the datasets for the journal files were renamed in step 2 to something other than what they were before, then be sure to update the JRNLRECV and JRNLSEND parameters in the CONTROL(CPF) OPTIONS record:
SET C(CPF)
CHA OPTIONS JRNLRECV(datasetname) JRNLSEND(datasetname)
F ACF2,REFRESH(OPTIONS),TYPE(CPF)
4. Turn journaling back on by issuing the following ACF2 console command:
F ACF2,CPF(JOURNAL)
Sample JCL:
//INITJNL JOB
//*
//INITJNL EXEC PGM=CPFC1IJL
//STEPLIB DD DSN=CAI.CAX1LINK,DISP=SHR
//SYSPRINT DD SYSOUT=*
//CPFJRNL DD DSN=CHICAGO.JRNLRECV,
// SPACE=(133,(5000)),UNIT=SYSDA,
// DISP=(,CATLG,DELETE),VOL=SER=VOLSER
//SYSIN DD *
BLOCKS=5000
Note that the numbers in red must be the same. This is the number that determines how many lines long the journal file is/how many entries the journal file can hold. Determine how many lines the current journal has, then increase this number depending on site needs.
Feedback
