× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.