After upgrading from V5R4 to V6R1 we have begun to encounter CPF8361 errors related to Committment Control running embeded SQL. Transactions get hung up in RDB and then processes get stuck. Is this specifically related to the upgrade and is there a simple process to correct the issue.
Software/Hardware used:
iSeries,V6R1, in house applications
ASKED:
February 11, 2011 4:58 PM
UPDATED:
March 1, 2011 5:42 PM
We are receiving a Reason Code 6. I remember reading a lot of information concerning changes related to SQL with the V6R1 upgrade. My concern is that we are in the process of upgrading several systems and we need to determine what the fix is because the code that is receiving the error will be running on all systems. Is it as simple as recompiling the programs or do we need to modify the programs.
Can you supply the rest of the message text after the reason code? For some reason, IBM created this message description with a bunch of substitution variables to create the description dynamically. It’s possible that everyone will see different text, so we’ll need to see your copy. (Sheesh… after so many times asking for message ID, we hit this one!)
Tom
Message ID . . . . . . : CPF8361 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 02/10/11 Time sent . . . . . . : 08:44:58
Message . . . . : Cannot place resource under commitment control. Reason
code 6.
Cause . . . . . : An attempt was made to place a resource under commitment
control for commitment definition *DFTACTGRP that was not valid. Reason code
is 6 — One of the following limits was exceeded: system storage, user
profile storage limit for user profile QDBSHR, no more than 2,097,143 unique
commitment definition/journal combinations on the system, or the maximum
resources for the commitment definition exceeded.
Recovery . . . : Depending on which limit was exceeded, do one of the
following: (1) Free some storage STG(*FREE) parameter on the SAVOBJ command.
(2) Assign storage to user profile QDBSHR using the MAXSTG parameter on the
CHGUSRPRF command. (3) Have fewer than 2,097,143 unique commitment
definitions/journal combinations on the system. (4) Remove some resources
from commitment control.
Technical description . . . . . . . . : The commitment definition identifier
is X’5CC4C6E3C1C3E3C7D9D7′. The activation group number is X’00000002′. The
lock space id is UDB_0100000000049BCE. The lock space associated space id is
1. The XID is
X’00000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000′.
Can you provide your cume level and perhaps DB2 group level?
There are a few V6R1 PTFs connected to MSGCPF8361. Some are on cume/group packages; others are not yet.
Tom
Tom,
These are our PTF Levels
SF99616 8
SF99610 10215
SF99609 72
SF99608 18
SF99601 15
SF99562 13
SF99357 17
SF99356 18
SF99354 8
SF99353 13
SF99115 14
Are these related to remote DBs at all? (Either sending or receiving transactions.) Or are they all local processes, either batch or interactive?
Tom
Tom,
The DB is local but the processes are batch. This is occurring with enbedded QSL in our CC processing application. I found a recent PTF from IBM SI41047 that is specific to RC6 that I am currently reviewing. Please let me know what your thoughts are.
I saw a number of related PTFs, but it looked like many were tied to potential comm elements. If it’s all local, those might be weeded out.
As for SI41047, I didn’t see a V6R1 equivalent, not yet. IBM might make one available quickly if asked. Or I might have just looked incorrectly.
Your embedded SQL is in programs compiled through the SQL precompiler, and not ‘embedded’ as SQL CLI could be called ‘embedded’, right?
Tom
After working with IBM for over 2 weeks on this issue it seems that we are not the only ones experiencing this issue after upgrading to V6R1. The developers are working of a fix for the issue.