| <<< Note 432.0 by ATZIS1::PIEBER "chaos has many faces" >>>
-< catalog handling functionality ABS >2.1 >-
Hi,
here is a list of features required for simplified catalog
handling:
1) There should be a way to allow catalog deletion.
I know, that this may cause inconsistencies with storage classes
pointing to it, but in case one simply has a typo when creating a
catalog, currently there is no official way to get rid of it.
--> there is an undocumented(/unsupported?) way to achieve this.
### We can add this to the requirements list.
2) The staging attribute should be possible to be toggled even after
catalog creation.
The staging flag is only used during a save operation. I tells,
whether ABS writes to the indexed files of the catalog directly, or
first to a sequential file (<Catlg>.STG) and to the indexed files
(BAOE, BAOE_INSNC) after the actual save operation is complete (staging).
This means, once the staging update is done, there is no difference for
subsequent restores, nor for the next save operation. So it can savely
be modified.
--> there is an undocumented(/unsupported?) way to achieve this.
### We can add this to the requirements list.
3) there should be a way to pre-expire catalog entries.
Currently, there is no way in ABS, to eliminate catalog entries,
unless they reach their expiration date and get removed by the catalog
cleaner. The other direction, trying to keep entries longer, than
initially determined, is less important.
### We can add this to the requirements list... A question for you -
### What would be the criteria to base the selection on?
4) There should be a tool to verify catalog consistency.
Since a node can crash in the middle of a cleanup operation, or a
staging update, or the process simply gets deleted, this might leave
inconsistencies in the catalog. There is no way so far, to tell,
whether such a case exists, nor can it be corrected. Long retention
periods will aggravate the situation.
### We can add this to the requirements list.
Ewald.
|
| Hi Kim,
> ### What would be the criteria to base the selection on?
For my point of view, it could be as simple as a wildcard specification
that selects all files desired plus the new specification for an
expiration date. In that way, one can select what should be covered by
the command and the new date (absolute or delta) will release the
objects hit to the catalog cleaner...
Selction qualifiers /SINCE, /BEFORE are required.
Other ways would come to mind, but would complicate matters:
* as the API now first evaluates a query in ABS LOOKUP first and then
starts writing the output, one could keep the selection around
until the next command inside ABS and allow the command
EXPIRE/Date=<date>. Example session, including error:
$ ABS
ABS> lookup/catalog=pies_Catalog $5$dka300:[Ewald_Pieber...]*.* -
/SINCE=<since>/BEFORE=<before>/OBJECT=VMS_FILES
.
. maybe tons of output, or /OUT=NL:
.
ABS> EXPIRE/DATE=1-JAN-1997 ! i.e. NOW
ABS> exit
$ ABS
ABS> EXPIRE/DATE=1-JAN-1997 ! no cursor, will not work
%ABS-F-NOSELECTION, no active selection, use LOOKUP first.
ABS> exit
$ ............................
* selection by SR: One can use REPORT SAVE_LOG to get the UID for a
specific SR and use this in the pre-expiration command.
* also allow to specify a date/time in the future, thus preventing
entries from being cleaned away.
==> This might cause headache with regard to MDMS volume
retention, since selected files might be on a whole list of
volumes and could bring troubles to the previewed pool
management.
I think, that's about it.
Ewald.
|