I am looking for some input to see if a proposed change would break anyone
out there.  S/390 (MVS,VM,VSE users) can ignore this since ADSM does not
have libraries on these platforms, therefore there will be no change in
their behavior.

It has been brought to our attention that DELETE VOLUME and RESTORE VOLUME
will return a volume to scratch status even if it was a private volume to
the storage pool.  I have dug through the code and it is only these two
cases that seem to have the problem.  Before I make a change to fix this I
want to know if anyone depends on the DELETE VOLUME and RESTORE VOLUME
commands to move a volume to scratch status even if it was defined to the
storage pool by the use of the DEFINE VOLUME command rather than being
introduced to the storage pool through a scratch mount request.

An example of the effect of the change is consider a D/T3494 library.  If a
volume gets checked into the library and then defined to a storage pool, a
DELETE VOLUME command will put that volume in the scratch category now.
With this change that command would leave the volume in the private
category but still remove the volume from any association with the storage
pool.

Any input would be useful.  I would hate to make this change and then find
out it breaks someone that depends on it working this way.

David Bohm
ADSM server development
(520) 799-5082 T/L 321-5082
email - bohm AT us.ibm DOT com