On 2010-02-20 at 17:44 concerning "Consolidate Storage Groups",
Rebecca Martin <reb...mar...@tgs...org> wrote to IBM-Main :
> We are a small shop with a big SMS mess as far as the ACS routines and
> number of storage groups. We have over 80 storage groups [snip] The
> storage admin believes [snip] the datasets have to be moved.
> [snip] get down to around 15 to 20 storage groups. [snip] reassign all
> the volumes in 1 pool to another. [snip] Is it that easy? [snip]
Rebecca : additional to all the good advice...
It sounds like my situation where SC<->SG and pools were used to keep
one group from clobbering another space-wise ie x37 problems. Now,
everything goes into my STD pool of 80 volumes unless there're very
compelling reasons not to. For me that leaves DB2 - IVP (3 sub-sys),
AppDev (3 sub-sys), and Prod (2 sub-sys), PERM - LnkLst, LpaLst, etc,
Recovery - Logs & backups that are migrated daily, plus a coupla
specialities for under 15 total. (the maximum number allowable for
&SG=) StorClas's are to identify the type of data & service not
where it should be placed. There's no reason they can't occupy the
same SG pool. We also FDR Archive by MgmtClas in all pools.
I used a FiltList to convert obsolete classes (DC, SC, MC) so that it
was not necessary to Alter old entries. Any new dataset creation -
JCL, TSO, IdcAms, recalls, etc. will be automagically transferred to
their new values ie.
FILTLIST OBS_SC_SYSDATA INCLUDE ('MONITOR', 'CICSDATA')
SELECT (&STORCLAS)
WHEN (&OBS_SC_SYSDATA) SET &STORCLAS='SYSDATA'
Keep your old StorGrps around but assign them one fake volume ie.
BOGON00, BOGON01, etc. All StorGrps in the SG ACS should include an
Overflow SG (ie. SET &STORGRP = 'thisGrp' 'SPILL') and I use one for
all my pools. It's make them stick out like a sore thumb. Each pool
should also have a quiesced volume (or several) to allow for that
occasional, really large allocation request. I find the actual size
used is often *much* smaller than SPACE= so I have a daily FDRMove
job that attempts to scour those quiesced volumes and usually finds
space elsewhere in the pool.
I still have a couple of volumes from obsolete SG pools hanging
around in my STD pool (DISNEW) because I haven't bothered to move the
datasets and they're in continual use ie. TcpParms, Ucats, OMVS Home.
It's only been 3 years - I'll find an outage time for them
eventually.
My DBA is also pleased with the new Scratch pool I cooked up. I took
all of the non-assigned volumes and made a pool of them for large,
temporary, gone-in-a-week type uses. (They're sitting empty anyway &
I keep a handful aside for emergency use.) The DBA uses it for
intermediary datasets (a mid-step backup) when he needs to do a whole
bunch of table/index space re-orgs. It's faster than tape and they
default to an MC that deletes them after a while so he doesn't have
to clean-up. When I need to add a volume to a pool, I find an empty
one in the Scratch pool. When my Scratch pool gets small, time to
order new Dasd.
ps. I do my activations mid-afternoon which is a local lull and
always from a different SCDS/ACDS so I can instantly switch back.
After 7+ days, I transfer the IGDSMS10.SCDS into IDGSMS00.SCDS and
activate the permanent copy. Then I can start work on my next
iteration.
pps. DB2 doesn't seem to care what SMS does. I started managing one
sub-system and the DBA's didn't notice for a whole year. They have
approx. 10-20 StoGroups defined but DB2 didn't care if the volume
wasn't what it requested. Naturally, we're not at production yet
with its performance/placement considerations but I think I have a
solution for that worked out.
ppps. ABRInit StorClas= is to get the allocation pointed at the
right SG where the volume resides. After that, it's extraneous
information.
ooops... this was meant to be short. ah well.
----------> signature = 6 lines follows <--------------
Neil Duffee, Joe SysProg, U d'Ottawa, Ottawa, Ont, Canada
telephone:1 613 562 5800 x4585 fax:1 613 562 5161
mailto:NDuffee of uOttawa.ca http:/ /aix1.uottawa.ca/ ~nduffee
"How *do* you plan for something like that?" Guardian Bob, Reboot
"For every action, there is an equal and opposite criticism."
"Systems Programming: Guilty, until proven innocent" John Norgauer
2004
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
