Just a SWAG that this is an alternate manifestation\symptom for the
problem documented in APAR SE47157 with PTF SI43058
"OSP-DB-OTHER-RC6-MSGCPF8361 APPLICATIONS USING DRDA USER MAY"
superseded by PTF SI45177 "OSP-DB INTERNAL DRDA MAINTENANCE" [not on any
cumulative; for APAR SE50020].
While the mention of DRDA may seem amiss given the originally
described scenario, the RW component [which gets the error; i.e. the
QRWSARDB as shown below] implements the [implicit] "connection" to the
[local and remote] database(s), so that would suggest an apparent
relationship\relevance. As well, the "newness" of the PTF being
available only since a somewhat recent cumulative c1256610. Finally
that the APAR suggests that "RDB registrations" are origin for an rc6 as
the "resource being exceeded" condition, and the failure seems probably
to match with the failing program QRWSARDB in the scenario described in
the quoted message. As well, other APARs naming the partial symptom
f/QTNCMTSP msgCPF8361 do not seem to be for rc6, are specific to DDM
[connect] versus [implicit] database connections, or are very old.
_APAR SE47157_
http://www-01.ibm.com/support/docview.wss?uid=nas2e0b6d53d48137d258625784900421fd7
"
Abstract:
OSP-DB-OTHER-RC6-MSGCPF8361 APPLICATIONS USING DRDA USER MAY
ACCUMULATE EXCESSIVE RMTDB RESOURCES CAUSING MSGCPF8361 RC6
"
_PTF SI43058_
http://www-01.ibm.com/support/docview.wss?uid=nas3eb166d6dc686fb778625788000630ff2
"
APAR Error Description / Circumvention
-----------------------------------------------
Customer upgraded from V5R4M5 to V6R1M1 and ran into problem of
programs getting MSGCPF8361 Reason Code 6 after several days.
The resource being exceeded is Relational Data Base (RDB)
registrations under commitment control.
CORRECTION FOR APAR SE47157 :
-----------------------------
A change will be made so that a buildup of RDB registrations
does not occur.
CIRCUMVENTION FOR APAR SE47157 :
--------------------------------
None.
"
Restatement of joblog snippet in symptom kwd form, with accompanying
and possibly relevant [replacement\cause\recovery] text:
msgCPF8361 rc6 f/QTNCMTSP t/QRWSARDB fm/QTNCRDSP fp/SNDMSG stmt/17178
tm/QRWSARDB tp/REGLCLRSC stmt/9895 "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 <ed: *DFTACTGRP>
X'5CC4C6E3C1C3E3C7D9D7'. The activation group number is X'00000002'. The
lock space <ed: add kwd *LCKSPC> id is UDB_01000000001A5E1D. <ed: Does
that mean this is an XA transaction?> The lock space associated space id
is 1. The XID is <ed: *none>
msgSQL0752 rc0 f/QSQCONN t/QSQCONN fm/QSQCONN fp/CLEANUP stmt/21002
tm/QSQCONN tp/CLEANUP stmt/21002 "Connection cannot be changed.
Reason code is 0. Cause . . . . . : Connection cannot be made because
the application process is not in a connectable state. The reason code
is 0. Reason codes and their meanings are: <ed: rc0 is undefined>
Recovery . . . : Do one of the following based on the reason code: <ed:
rc0 is undefined>
msgSQL0900 f/QSQROUTS t/QSQROUTS fm/QSQCLNUP fp/SQROUTE_CLEANUP
stmt/3945 tm/QSQCLNUP tp/SQROUTE_CLEANUP stmt/3945 "Application process
not in a connected state. Cause . . . . . : One of the following
occurred: -- The current connection was disconnected using the
DISCONNECT statement. -- The current connection was released and a
commit occurred. -- A previous error has left the application process in
an unconnected state. Use the Display Job Log (DSPJOBLOG) command to
see previous errors. Recovery . . . : Issue CONNECT statement with
the TO or RESET clause or the SET CONNECTION statement to enter the
connected state.
msgSQL0900 <ed: duplicate of above>
Regards, Chuck
On 29-Dec-2011 23:40 , Åke Olsson wrote:
I have added the complete job log listing from where the problem
starts. As recommended by Chuck:
All the "to" vars (procedure, module etc.) apparently point to stuff
in the OS itself. The system is on V6R1M0. As for PTF:s (since I do
not manage PTF:s) the question is which product to look for.
A full version of the log messages follow. Interestingly there is no
telling what reason code "6" is - despite the logging level is
*seclvl.
The sequence below then repeats over and over again for over 90
thousand pages.
Anyhow this is a full version of where the messages start:
<<SNIPpedjoblog; see the original >>
---------------------------------------------------
On Thu, 29 Dec 2011 11:04:27 -0800 CRPence wrote:
On 29-Dec-2011 01:37 , ?ke Olsson wrote:
We have an overnight job where we from time to time see an
enormous number of job logs. Last night over 91 thousand pages.
Most of this is repeats of the same information and it all
happens in the flow between calls to two programs:
The starting point for the issues is a call to non-sql program.
We get a CPF8361 "Cannot place resource under commitment
control. Reason code 6" Followed by SQL0752 "Connection cannot be
changed" SQL0900 "Application process not in a connected state."
And this continues for another 90785 pages of joblog - same
three messages in that sequence. The time used by this is just
under 3 minutes.
I have checked all SQL programs in the flow to see if there could
be any SQL statements with problems and found none. We do not
user journaling or commitment control at all.
Any ideas on where to look?
The best place to start would be with the messages, but viewed for
the full details available from a LOG(4 0 *SECLVL) spooled joblog.
That will show all of the replacement text for each message as well
as exactly which program(s) receive the errors [i.e. the "to"
program] such as the program that apparently is wanting to place
some resource under CmtCtl for which that request is being denied,
and the program(s) that identified both the resource as being
ineligible for the request [i.e. the "from" program] and the
connection status difficulties.
Which release of the LIC and OS [plus optionally PTF cumulative
and database group levels] is installed where the problem is being
encountered might be relevant to assist in excluding unrelated
defect searches. The first listed error has a partial [per lack of
the full second level spooled joblog message details] symptom
string which could be used in a defect search [though alone,
produces results spanning several releases] as:
msgCPF8361 RC6
midrange.com
