RE: ASP Problem

Hi Mark

To expand on what Larry said, a User Asp (like your ASP 2) is completely
different to an IASP; the User ASP resides in the same namespace as the
system ASP so you are in a difficult situation as it is essentially part of
the same file system. If you compare the machines in Operations Navigator
you will see an additional QSYS.LIB file system on the machine with the
IASP.

The real solution for you is (probably) to get that stuff on the DR machine
into an IASP, either over an extended period as Larry suggested, or to just
grit your teeth and take the hit. Either option sounds like it is going to
be pretty painful so it is a matter of which one can be best managed
alongside your business requirements.

Over the longer term keeping them different will quite possibly hurt you -
Restore operations between machines/ASP's will always require attention and
thought. Rebuilding one machine using a backup from the other will require
considerable advance planning and documentation.

If you can get both machines into similar/identical configurations then you
can possibly make your life much easier using something like XSM - if I had
to guess I'd figure this might have been part of the original intention.

You may be able to use BRMS in the shorter term to help manage your backups
on the DR machine - I believe it will do saves by ASP. If you don't have
this product then you have 70 days of use before you need a license key.
This may be enough to help with managing things until you can sort out your
IASP situation, but of course you'll have to weigh up whether the additional
effort is worth the payback. One note - when your license expires you may
find tapes don't initialize or can't be used as the backup rejects them BRMS
registers an exit point that can occasionally be troublesome in this
respect.

Hope this helps - good luck.

Regards
Evan Harris



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Mark_Sutherland@xxxxxxxxxxxxx
Sent: Tuesday, 2 June 2009 12:13 a.m.
To: midrange-l@xxxxxxxxxxxx
Subject: ASP Problem





As part of our company we hold a vast amount of images which is constantly
expanding, by around 15,000 a day. We recently created a DR machine to
house a duplicate of all of this information hosted on our primary System.
We have 2 DS6000 one attached to each system. On the primary systems the
device was added as an IASP (Indipendet auxiliary Storage pool), where it
can be taken of line with the WRKCFGSTS *DEV command, this works fine,
although due to it's size it take around 5 Hours to vary on (with lot of
memory in the machine pool). However on our backup machine The DS6000 was
added as an ASP (ASP2 more precisely), this has caused us numerous
headaches, the first is the ability to before a FULLSYSSAV as the save
operation starts to save ASP2, which is not appropriate due to the size.
The second is our inability to run a RCLSTG, recommend by IBM for a
previous problem we had with the machine, as again it runs the command on
ASP2. We have tried an unmount of the directory but to no avail, as it
still attempts to run the save and the reclaim disk on the directory. Has
anyone got any ideas how we could resolve our problems, with out the need
to wipe the disks?

Regards,

Mark Sutherland
Jordans Information Systems
Tel: 0117 918 1406

Jordans Limited
Registered in England and Wales No: 865285
Registered office: 21 St Thomas Street, Bristol BS1 6JS


This message is intended only for the addressee and may contain information
that is confidential or privileged. Unauthorised use is strictly
prohibited and may be unlawful.

If you are not the addressee, you should not read, copy, disclose or
otherwise use this message, except for the purpose of delivery to the
addressee.

If you have received this in error, please delete it and advise us
immediately.

Whilst we take reasonable care to ensure that any attachment to this e-mail
does not contain software viruses, this cannot be guaranteed and you should
therefore carry out your own virus checks before opening any attachment.
The Jordans Group of Companies accepts no responsibility or liability for
any damage that you suffer as a result of software viruses.