ADSM-L

Re: one stgpool migrates to two?/Scratch volumes in disk storage pools

1998-03-25 18:28:42
Subject: Re: one stgpool migrates to two?/Scratch volumes in disk storage pools
From: "Nicholas, Murray, Haltek/AU" <MurrayNi AT HALTEK.COM DOT AU>
Date: Thu, 26 Mar 1998 09:28:42 +1000
Allen,

When I read your solution I thought it was brilliant in its simplicity.
Then I read the "ADSM for MVS Admin Guide" under the heading "Assigning
Random Access Storage Pools".  The full text of this section of the
manual says
        "Volumes in random access storage pools must be predefined."

Unfortunately, unless you can demonstrate an error in the documentation
or a recent change, it would appear that you cannot allocate scratch
volumes to disk-based storage pools.

Given the specific problem and the conceptual validity of the solution,
it would seem to me that there is a valid basis for this becoming a
requirement for IBM to modify the code.

Murray Nicholas
IT Systems Consultant
Galeforce Information Services Pty Ltd
email:  murray AT galeforce.bu.aust DOT com

                ----------
                From:  Allen S. Rout[SMTP:asr AT CORNPONE.NERDC.UFL DOT EDU]
                Sent:  Wednesday, 25 March 1998 1:00
                To:  ADSM-L AT VM.MARIST DOT EDU
                Subject:  Re: one stgpool migrates to two?

                => On Fri, 20 Mar 1998 10:30:10 -0700, "Kelly J. Lipp"
<lipp AT STORSOL DOT COM> said:

                > No, a disk volume cannot belong to more than one pool.

                > I don't see a way around multiple pools for what
you're trying to do here.

                [ .... ]


                Since the issue was, roughly:


                - We have two major classes of backups, (A and B)

                - ( Incremental(A) + Incremental(B) ) <  ( My availiable
disk )

                - Incremental(A) > ( My availiable disk /2 )

                - Incremental(B) > ( My availiable disk /2 )


                What's wrong with:


                - Set all but a few of your disk storage pool volumes to
"scratch".

                - Create two disk pools (DISKA and DISKB) with large
numbers of "max scratch
                  volumes" and one or two dedicated volumes.

                - Make sure colocation is off (so you don't immediately
eat all availiable
                  scratch volumes)

                - Play with migration thresholds so you empty the disk
pools during the day,
                  and then make them availiable again before your
incrementals.


                Am I just missing something here?


                - Allen S. Rout

<Prev in Thread] Current Thread [Next in Thread>