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?
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.
And, no, the -FILESONLY option does not help. At least the 3.1.0.6 clients
I tested, do archive the directories in spite of specifying that option.
According to APAR IX78468 this is the target behaviour. Again, I do not
understand the reason.
As Paul noted, IBM has suggested using DELETE ARCHIVE combined with a
clever use of archive descriptions. While I might do that on the clients
managed by me (although I do not like it - it's extra work), it is not an
option for all other clients; they probably simply don't care.
Best regards,
Reinhard
Trevor Foley writes:
> G'day,
>
> I am having a bit of a problem understanding the why archives work the way
> that they do. I am hoping that someone might be able to explain it to me. If
> not, I'll log a call with IBM.
>
> First, I like that fact that with ADSM V3 the directories are now save along
> with the files. What I am having trouble understanding is why the
> directories are bound to the management class with the longest retention
> period. That makes sense for backups, but when you perform on archive, all
> files that are archived with one command are bound to the same management
> class. Should directories also be bound to this management class? The only
> reason that I see that this should not be the case is that it is possible to
> add files to an archive group by specifying the same description. But is
> seems that directories get archived again when you do this.
>
> We have a situation where the number of directories being saved is getting a
> little out of control. An example. If I execute the following select
> command, where 'DUMP' is the name of a directory:
>
> select count(*) from archives where node_name='AUPOZA404' and
> filespace_name='\\aupoza404\d$' and hl_name='\SYSDATA\SQL\' and
> ll_name='DUMP'
>
> I get 13782 returned. The SYSDATA and SQL directories have a similar count
> (each 13785). If I now look at the files within that directory by doing:
>
> select count(*) from archives where node_name='AUPOZA404' and
> filespace_name='\\aupoza404\d$' and hl_name='\SYSDATA\SQL\DUMP\'
>
> I get 2575 returned. So to have 2575 files archived, I have to wear another
> 13782+13785+13785=41352 database entries for the directories. And this is
> just one of approximately 100 ADSM clients.
>
> Many of the files that are archived from this directory are archived for
> only short periods (days or a few weeks) but the directories are getting
> archived for 10 years because the management class with the longest
> retention specifies 10 years. What then happens is that the files are
> expired quite quickly, but the directories do not.
>
> So in the worst case, if I archive a file from this directory with a 1 day
> retention, I get 3 directories ('SYSDATA', 'SQL' and 'DUMP') archived as
> well which stay around for 10 days. And if this file is archived every day,
> the number of directories grows very quickly.
>
> Yes, I could specify -FILESONLY on the archive, but I want the directories
> archived with the files. It would also require changes to some application
> code that I would like to avoid.
>
> So I have to questions. First, can I change this behaviour? My understanding
> is no, so I guess that means talking to IBM. And second, how to I clean up
> the mess (automatically and regularly). If we were using the default archive
> descriptions (date, time, etc) I can see a way of doing it manually. But we
> use the same description every time we run the archive.
>
> thanks,
>
>
> Trevor
--
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Reinhard Mersch Westfaelische Wilhelms-Universitaet
Zentrum fuer Informationsverarbeitung - ehemals Universitaetsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de Fax:
+49(251)83-31653
|
