Not expressly "hidden", but as the side effect of being an "internal
object type" versus and "external object type", indeed the object is not
directly viewable by interfaces such as WRKOBJ and CHKOBJ, for example.
The database recovery objects are implementation objects for
"reserving object names", a semaphore for pending work; work which may
or may not be performed under commitment control.
The object can be "seen" by a request of "DMPSYSOBJ Q* TheLib 19 D4",
which for this case probably just "DMPSYSOBJ *ALL CMKTWRKLIB 19 D4" is
best. If the object is not found [by an authorized user] with that
request, then the problem would [though seems unlikely given the
description] be something else. Nice thing about the dump output is the
CREATION DATE information divulges the timestamp of the start of the
operation which was terminated before giving up the object name. The
owner of the object is probably the user that issued the previously
failing\ended request. That information can be correlated to another
failure, perhaps by QHST for an error or an indication of a job ended
[immediately].
If the recovery object exists for CmtCtl, WRKCMTDFN *ALL might assist
to find that pending work.
While a RCLSTG does clean up recovery objects, if the database
cross-reference is or will be correct for having destroyed the recovery
object, many non-cmtctl requests can be cleaned up directly by following
some simple patch instructions. More complicated objects [such as the
composite and relations for database *FILE objects] and
situations\operations may not be so easy as that, and although a "simple
patch" may be offered, that might not be so good in advice coming from
level-2 versus level-3 support.
Anyhow the "type of operation" is defined encoded in the space
object, which is more detail in correlating the origin of the previously
terminated request.
Regards, Chuck
On 2/8/11 11:13 AM, Morgan, Paul wrote:
What the heck is a 'database recovery object'? Would that be one of
those hidden MI spaces?
Charles Wilt on Tuesday, February 08, 2011 1:18 PM wrote:
Strange one here....
CL Code:
CLRSAVF FILE(&WRKLIB/&SNAME)
MONMSG MSGID(CPF9812) EXEC(DO)
CRTSAVF FILE(&WRKLIB/&SNAME)
ENDDO
In the joblog I see:
CPF9812 - File CDSEATTLE in library CMKTWRKLIB not found.
CPF0626 - CDSEATTLE in Library CMKTWRKLIB already exists.
Cause . . . . . : An attempt was made to create a file with the same
name as a database recovery object.
Following the job crashing....we've signed on with a 5250 session to
try to figure out what is going on.
We, including an *ALLOBJ user, see no object named CDSEATTLE in
CMKTWRKLIB, yet every attempt to create a save file with that name
fails with the CPF0626 message...
So, does anybody have any experience with such "hidden" objects?
How can we get rid of it?
midrange.com
