cancel
Showing results for 
Search instead for 
Did you mean: 

Message ID CPF7024, reason Code # 2

Former Member
0 Kudos

Hi Guys,

In our SCM production system, we use the the program given by SAP for managing the journal receivers..It deletes an old journal from the journal library and saves it to a another library, which we back off everynight...

Now all of a sudden, the program is not able to delete one of the old journals, and hence the subsequent journals are also not deleted, and hence our ASP is shooting up.

The reason code for not being able to delete the journal, its showing as Message ID CPF7024, reason Code # 2...which basically states that :

2 -- The receiver contains entries for changes that are not committed or

rolled back. These entries are necessary for IPL recovery operations.

This receiver is from last night...Is there a way to commit these or look at what has not been committed, so that we can delete the journals....

I have not brought down the system so far(offline)...and have not tried deleting this journal after that. I am speculating that it may give me the same message after that as well...

Any suggesstions?? Will it be alright if i bring down the system and then try the operation...??

Thanks

Abhi

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi all, i have the same problem.

But in my case i can't do the IPL because the upgrade still running...

Is there other options to delete the journals manually?

I have search on internet and i got the following below, to use WRKJRNA...

Valid Reasons Why a DLTJRNRCV Receives Message CPF7024 RC2

The following are valid reasons why a DLTJRNRCV receives message CPF7024 with RC2 - the receiver contains entries for changes that are not committed or rolled back:

oThere are uncommitted changes. To resolve the problem, type WRKJRNA for the journal, press F15 to get into the receiver directory, and select Option 8 on the journal receiver to be deleted.

For example, if a journal receiver called rcv34011 was attached on 12-13-99 at 13:03 and detached at 13:18, the user can locate the job that has not done a commit or rollback since 13:18. The user can use the WRKJRNA for the journal, press F19 and use Option 6 to display all commitment definitions currently associated with the journal. Work with each job that is active and determine if it was started after the Journal Receiver in question was attached and if this job can be ended.

On this Work with Commitment Definitions screen, press F11 until the State field is displayed.

Any commitment definitions with a State of PREPARED or LAST AGENT PENDING represent transactions that the application tried to commit, but are in-doubt due to a failure between phases one and two of the two-phase commit. Now determine whether the in-doubt commitment definitions are XA transactions by pressing F11 again until the Global Transaction ID field is displayed. If that field is blank, the transaction is non-XA, and should resolve by itself once communications are re-established with the remote system(s) involved in the transaction. If some unrecoverable error has occurred that will prevent communications with those system(s) from ever being re-established, the transaction will have to be manually completed using Option 14=Forced commit or Option16=Forced rollback, followed by Option 19=Cancel resync to make the commitment definition go away. If the Global Transaction ID field is not blank, the commitment definition represents an XA transaction. Such transactions must be completed per XA standard protocol.

If any of the commitment definitions are not in a PREPARED or LAST AGENT PENDING state, they are still pending commit or rollback. You can display the commit cycle for such transactions by using Option 5=Display from the Work with Commitment Definitions screen, then Option F6=Display resource status, page down and select Journal, then Option 5=Display commit cycle entries. If the timestamp of the first entry (C SC) is later than the timestamp when the journal receiver was detached, this transaction is not preventing the receiver from being deleted. If the C SC timestamp is older than that, the user will have to determine why their application has not committed or rolled back such an old transaction.

Can somebody explain me how to use it?

Thanks all,
Cheung

volker_gldenpfennig
Active Participant
0 Kudos

Hi Cheung,

I still would do an IPL ...

You could stop after this phase and then stop the upgrade in a clean state ... otherwise, when you would be in e.g. shadow_import_inc, you could even kill it and do an IPL and restart afterwards ... in case you still do have the shadow, you would have to start it yourself ...

Regards,

Volker Gueldenpfennig, consolut international ag

Former Member
0 Kudos

Thanks Volker for your reaction, i am not possible to do an IPL (i don't know how to do that)...

the disk% is now: % system ASP used  . . :    81,0887

i am phase preprocessing in MAIN_SHDRUN/DDIC_UPG.

You are correct that i can stop the phase, but i want to know if its possible to remove the journals manually....

I already try this:

wrklib r3prdjrn -> 12

delete: dltjrnrcv r3prdjrn/qsqjrn*

But its not possible:

Message ID . . . . . . :   CPF7024                                          

Date sent  . . . . . . :   12/10/14      Time sent  . . . . . . :   16:45:48

                                                                            

Message . . . . :   Receiver QSQJRN9001 in R3PRDJRN not deleted.  Reason code

  2.                                                                        

                                                                            

Cause . . . . . :   Journal receiver QSQJRN9001 in library R3PRDJRN cannot be

  deleted because of reason code 2. The reason codes and their meanings     

  follow:                                                                   

    1 -- A journaled object associated with journal receiver QSQJRN9001 has 

  changes that have not been forced to auxiliary storage.                   

    2 -- The receiver contains entries for changes that are not committed or

  rolled back.  These entries are necessary for IPL recovery operations.    

    3 -- The receiver must be kept for recovery purposes.                   

    5 -- One or more access paths are being journaled and a reorganize      

  physical file member (RGZPFM) command is in progress for one or more of the...

Thanks,

Cheung

volker_gldenpfennig
Active Participant
0 Kudos

Hi Cheung,

yes, that is your problem ;-(

There is some inconsistency, that might only be solved by an IPL ...

As you are in DDIC_UPG, it would be perfect, to stop before ACT_UPG / SPDD and ask for a person, that knows how to run PWRDWNSYS ....

Regards,

Volker Gueldenpfennig, consolut international ag

Former Member
0 Kudos

Hi Abhi,

I would guess, you are having running a long running batch job, that doesn't issue a commit :-(((

Then this is totally normal ...

If you do bring down the system, this "problem" should disappear ... but you should expect this as normal ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Volker,

Thanks for the response. Last night we had a few issues with our background jobs...some of them failed coz of wrong data/concurrent locks by data load and delete at the same time..so we fixed those....But then noticed this journal, which was blocking the deletion of all subsequent journals...

Hence , wanted to clarify...will update with the results tommorrow...

Thanks a lot...

Abhi

Former Member
0 Kudos

Hi Volker,

Even After shutting down the system, it does not allow to delete the journal.

It still gives the same error message Message ID CPF7024, reason Code # 2, as I suspected....

What are the options we have to get rid of the journal receiver without damaging the system??

Thanks

Abhi

Former Member
0 Kudos

Hi,

in my eyes you need an IPL now :-((

If this doesn't help, you have to contact IBM ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Former Member
0 Kudos

Hi Volker,

I even tried changing the journal receiver to a journal/library using the CHGJRN so that if somehow , if was locked somehow, it releases it..but just doesn't take it even after that...I tried doing a CLRLIB for my journal library after I had changed the journal...but since it was not able to delete that single journal receiver, it did not work even with CLRLIB...

I also tried DLTJRNRCV JRNRCV(R3SCPJRN/QSQ*)...but not able to delete the journal...

Since I had got a downtime of half an hour only..could not experiment much...

Right now changed back to the journal receiver in the journal library and started the system...since the background jobs will kick off in 10 minutes...

I am able to do a clean switch off for the SAP system and a clean start for the system...no problem there...

Any suggestions guys...

Thanks

Abhi

Former Member
0 Kudos

Hi Abhi,

I had similar issues with R/3 4.6C on OS/400 V4R5 before... basically job(s) ended without commit/rollback. Eventually IPL fixed it.

Best regards,

Victor

Former Member
0 Kudos

Hi Victor,

I am also hoping for the same...I am going to do the IPL tonight...after office hours...lets see how it goes...

Will inform you all, if everthing goes allright...

SAP has asked me to open a PMR with IBM, if the IPL doesn't fix it...

If this thing doesn't get fixed, then for the time being I will have to change the journal receiver/journal library, so that atleast I can delete those newly created journals...so that my system does no come to a grinding halt...coz if I continue to use this journal library, my system is for sure coming to come to a stop :((..as the ASP will fill up...pretty soon, maybe by max 2 days...its growing at approx 10%...per day...is up at 76 % already within day and a half...

Anyway ....

Thanks guys

Abhi

Former Member
0 Kudos

Hi all,

The IPL fixed the issue..

Thanks all

Abhi