At 10:09 AM 5/20/99 +0200, Reinhard Mersch wrote:
>Trevor,
>
>let me explain my wholehearted assistance to your complaints. In March,
>Paul Zarnowski already complained about it (Subject: Archive retention for
>directories). Paul, has anything happend in between?
Yes, just this week the kind folks in the Support Center have informed me
that the set of related Archive problems will be fixed. There are
primarily two APARs related to this. The first, IX89638 has already been
appended to this list in an earlier response from Rejean Larivee (thank
you, Rejean). The second is IX85975, which I will append at the end of
this e-mail. With these fixes, I believe that ADSM Archive will behave
correctly, allowing the type of archival usage that I and others have
discussed here. I was told that the fixes will be included in the next fix
level.
>In my case, this new "feature" of ADSM V.3 prevents at least one of my
>clients from being upgraded to version 3. This client archives about 200
>files per day, using seperate archive commands. The files are archived for
>30 days. With version 3, the 5 directories above these files would also be
>archived, and they would be archived for 10 years. I would end up with
>3660000 archived directories (5 directories for each of the 200 files per
>day archived for 3660 days), which largely are identical (the archived
>files all come from the same directory), and which are never needed.
>
>This way, my perpetual struggle to keep the ADSM data base at a manageable
>size is condemned to fail.
Exactly right - this problem would make itself evident over time. But -
this is not a "feature". IBM now recognizes it as a bug, and will be
providing fixes. There are fixes to both the server and the client.
As a side note, I would encourage folks to call problems into the Support
Center when they encounter them. I know this can take precious time, but
it really does help to improve the product not just for you, but for the
entire community of ADSM users. When we first called in this problem, back
in December, I was told that there were APARs for this that were closed as
SUG (Suggestion). I suspect that IBM did not realize the full impact of
this bug at first, and might have realized it sooner if more folks had
called it in. This is just speculation on my part, of course. I know it
can be frustrating trying to convince someone else that there is a bug when
it clear to you, having just experienced it. However, I have found that
(with some patience), once they understand the problem they take action to
fix it.
Possibly some good has come out of this - since we could not wait for the
fix for this problem for one of our larger users, we decided to explore
converting them to use HSM.
..Paul
---
Item IX85975
Item IX85975
APAR Identifier ...... IX85975 Last Changed ........ 99/04/26
DELETE ARCHIVE DELETES THE FILES AND DIRECTORIES BELOW THE
SPECIFIED DIRECTORY, BUT NOT THE SPECIFIED DIRECTORY ITSELF.
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 99/01/18
Component .......... 565511904 Duplicate of ........
Reported Release ......... 31A Fixed Release ............ 999
Component Name ADSM AIX V4 CLI Special Notice
Current Target Date ..99/05/08 Flags
SCP ................... AIXRSC
Platform ............ AIX
Status Detail: Not Available
PE PTF List:
PTF List:
Release 31A : PTF not available yet
Release 31B : PTF not available yet
Parent APAR: IX85967
Child APAR list: IC23738 PQ26379
ERROR DESCRIPTION:
DELETE ARCHIVE deletes archive versions of files and directories
below the specified directory, but does not delete the specified
directory itself. The only way to delete the specified directory
is to delete the next highest-level directory, but this would
also cause peer files and directories of the specified directory
to also be deleted. For example, suppose the following directory
structure is archived:
/TopDir/Dir1/File1
/TopDir/Dir1/File2
/TopDir/Dir2/File3
/TopDir/File4
The command "DELETE ARCHIVE /TopDir/Dir1/ -SUBDIR=YES" would
delete the archived versions of File1 and File2, but Dir1 itself
would not be deleted.
The only way to delete Dir1 is to issue the command
"DELETE ARCHIVE /TopDir/ -SUBDIR=YES", except this has the
undesired side-effect of deleting *all* the files and
directories under TopDir, including Dir2 and its files, and
File4.
The DELETE ARCHIVE command should delete not only the files
and subdirectories in the specified directory, but the specified
directory itself.
LOCAL FIX:
Currently the user can delete the directory using -PICK with the
DELETE ARCHIVE command, but that capability is a defect (APAR
IC22894) that will be removed from the product in the next PTF.
Note that using the -PICK option won't work in scripts.
PROBLEM SUMMARY:
****************************************************************
*USERS AFFECTED: All Platforms *
****************************************************************
*PROBLEM DESCRIPTION: Delete Archive -subdir=yes, the files and*
* directories below the specified directory*
* are deleted, but not the directory itself*
****************************************************************
PROBLEM CONCLUSION:
When archive_delete is performed, dsmc queries the server with
the required filespec and then builds list of files/directories
to be deleted. The server returns ONLY "childs" of the specified
directory, not directory itself. It must be added with the help
of one more query.
Now, if DELETE ARCHIVE -SUBDIR=YES is issued for a directory,
that directory as well as its files and subdirectories will be
deleted.
TEMPORARY FIX:
COMMENTS:
MODULES/MACROS: EXE DSMC
EXE DSM
SRLS: NONE
RTN CODES:
CIRCUMVENTION:
MESSAGE TO SUBMITTER:
2/25/99, ml, added to conclusion
---
=========================================================================
|
