> Updated the device class to refer to the second library? The pools would
> remain associated with the device class, the (new|moved) drives would be
> defined to the new library, and the tapes would be checked out of the old
> library and checked into the new one (with the device class change in
On 01/22/2014 05:36 PM, Remco Post wrote:
indeed, the trick is to change the primary pool, new device class, new
pool etc. The copy pool can remain unchanged. Now, you do make me doubt
about what we did 10 years ago when we got our second library. We moved
tapes, I'm sure of that.
Updated the
gt;
>
>> -Original Message-
>> From: ADSM-L@VM.MARIST.EDU [mailto:ADSM-L@VM.MARIST.EDU]
>> Sent: Wednesday, January 22, 2014 11:53 AM
>> To: ADSM-L@VM.MARIST.EDU
>> Subject: [ADSM-L] moving to new copy storage pool
>>
>> We are upgrading o
EDU
> Subject: [ADSM-L] moving to new copy storage pool
>
> We are upgrading our server from v5.5.4 to 6.2.5. At the same time, we
> are changing platforms to redhat on x86 from suse under vm.
>
> I have tested the upgrade process, and it seems to work well.
> In the curre
Op 22 jan. 2014, om 17:52 heeft Lee, Gary het volgende
geschreven:
> We are upgrading our server from v5.5.4 to 6.2.5. At the same time, we are
> changing platforms to redhat on x86 from suse under vm.
>
vm (mainframe) or vmware? And if VMWare, is tape (physical or virtual)
supported on VMW
We are upgrading our server from v5.5.4 to 6.2.5. At the same time, we are
changing platforms to redhat on x86 from suse under vm.
I have tested the upgrade process, and it seems to work well.
In the current 5.5 server, the primary tape pool uses the same devclass as the
offsite copy pool.
I no
