Chuck,
1) I ran RTVDSKINF.
2) Created a query over QUSRSYS/QAEZDISK, selecting DIOBAS EQ 02.
3) Found one object
4) QSYS Q1ABRMSF02 LIB 73,728
This looks like a BRMS system object that was created 12/17/15 21:22:5.
This was when I first created ASP02, and was testing RSTLIBRM, restoring to ASP 02.
I would have thought that this BRMS system object should have been created in *SYSBAS, which would be ASP01.
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, January 07, 2016 9:29 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: How does one identify what is in ASP02
On 06-Jan-2016 17:28 -0700, Steinmetz, Paul wrote:
1) I created Virtual ASP02, usage to start was 0.0%.
2) RSTLIBBRM 20 libraries to ASP02.
3) Ran some benchmark tests, etc.
4) Deleted same 20 libraries I restored in step 2 above.
5) I expected ASP02 to be at 0.0% but ASP02 drives showing .1 .2 etc.
Why?
Might any directories\STMF have been created in ASP02?
Were all of the Restore Library (RSTLIB) and Delete Library (DLTLIB) requests 100% successful according to their joblogs; i.e. beyond just an apparent completion? The DB2 for i is /tolerant/ of errors in Delete [Database] File (DLTF) deletion, so may leave remnants of composite pieces despite the apparent success of the Delete Library request; i.e.
errors will have been logged, LIC logs would have been generated, but the *FILE object will be gone. Similar errors that could be logged during a restore might have left partially-created objects that would be expected to be deleted, but could actually be the origin for later failures to delete.
The reclaim instruction would be able to purge some partially-created objects [that instruction runs with the Retrieve Disk Information
(RTVDSKINF) feature], and after an IPL the request to Reclaim Storage
(RCLSTG) for *ALL [again, the reclaim instruction runs with that request] would /associate/ any orphaned pieces [of data] of a file with a system-created *FILE in the QRCL library for the ASP(02). Also if the RCLSTG *ALL ran while ASP02 had data, there may have been /reclaim/ directories created but not deleted to store [non-/QSYS.LIB] IFS objects; the ASP-specific directories of either\both of '/QReclaim' and '/QOpenSys/QReclaim'
Re the Subject, How does one identify what is in ASP02: Given the objects and data in the ASP were there only via *LIB [and they were according to described scenario, not being restricted to SAVF data and\or JRNRCV data], then the DSPOBJD *ALL *LIB OUTPUT(*OUTFILE) and a query of the output file for ODASP=2 would identify any library object in that ASP and then review for the objects in that library should reveal what objects remain on that ASP. If there are no *LIB objects in that ASP, then the objects not in a library that are in ASP02 may be capable of being queried from the QCURRENT member of the QAEZDISK output file, IIRC with DIOBAS=2; those identified would be expected to be deleted or re-associated in QRCL. For objects outside of /QSYS.LIB, the objects also should be listed in that same query, but those objects must be found in their directory associated with the ASP02.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
