Re: File Still Open

On 01 May 2012 12:17, Jerry C. Adams wrote:

I was restoring my test environment's data library. Issued a CLRLIB
on it first. That's when I got the error (forget the CPF #): Not all
objects could be removed/deleted. At least, I *think* that's what I
was doing at the time; the little gray cells are pushing out and
coloring the hair leaving very little behind.

CLRLIB should not be affected by the pseudo-closed cursor; at least not by v5r3. I just verified for a pseudo-closed cursor in both *DFTACTGRP and a named activation group.

I would suspect a restore over the open file would be more likely to have been affected; i.e. perhaps there was an error only when CLRLIB was not done prior to the restore.? IIRC the database restore feature was not one of the earliest to change to support the close-before-action enhancement; the lack causes the code to suffer the normal open restrictions, because of course, the file is not closed in a preemptive request. The database file delete would have been one of the first to have that enhancement, and that is what implements the delete effect of database *FILE objects for CLRLIB; available since way back in the day.

Plus, I'm just a neat freak. I don't like leaving a mess behind; when
the programs are through, I want all of the trash taken out (closed).
Of course, looking at my desk one would not surmise that.

FWiW, best to change that perception with regard to "open files" that are merely pseudo-closed for the SQL, to avoid impacting the attempts by SQL to improve its performance. That is, rather than trying to force the programs that might effect pseudo-closes to stop doing that, for the sake of neatness, allow that effect in\of the programs, and only remove the open files when feeling the need *outside* of the programs; e.g. by RCLACTGRP. Reclaim of the activation group would of course, for the sake of neatness, also need to be done ;-)

Regards, Chuck