Greetings, all.

In an issue adjacent to the offsite reclamation question asked earlier
today, I have been chasing details on the details of remote volume
handling with IBM.   My PMR eventually ended up with a 'Working as
designed'.  I wanted to air my thoughts here before trying to make a
DCR or such.


In general, you can't append to a virtual volume.  This seems sane:
there's no reason to think it is convenient, or even possible, to
write to the next bit after the end of the existing volume, realized
as some file on some tape, some where.


But there is a time when it would make good sense to do so: On the
very first mount, during which the volume was created.  Appending then
would be technically equivalent to just continuing to write.

On this first mount, the remote volume is mounted R/W, but no second
process can open it.  This seems deeply busted to me, and it makes
impossible a variety of useful tactics.


I encountered this behavior when I began remote-volume offsites for a
large mail service, which gets by-list incrementals every 5-10
minutes.  I set up a copystgpool for this process, and set the remote
volumes to have a mount retention of 15 minutes.  I was expecting that
a given virtual volume would be appended to until MAXCAP, and would
then be closed, dismounted, and a new one begun.

Of course, what in fact happened was that the next backup process
ignored the extant, mounted, R/W remote volumes, and created new ones.
As soon as I verified this behavior, I stopped the copystgpool,
because it would lead to 600-1000 new volumes being defined a day,
most of them in the 30-40MB size range. (resourceutilization=8).  This
seemed to me a bad idea, likely to exercise new and stupid code paths
in the TSM base. :)


Being able to append on the create mount-pass of a virtual volume
would also help Ian; he could serialize N move data processes, and
they would mostly write to the same new volume.


Opinions?


- Allen S. Rout