Thompson, Steve wrote:
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
Behalf Of John Eells
Sent: Tuesday, September 11, 2007 7:35 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ServerPac Installs and dataset allocations
<SNIP>
Oddly enough I'd looked already. I wrote the SMS support spec for
ServerPac and I'd have been acutely aware of defects related to the
design or its execution. Even now, as you see, I retain some degree of
professional interest.
In any event, searching for ServerPac, volser, and SMS return one hit in
RETAIN, OW54994, which has nothing to do with primary or secondary space
allocation specification. ServerPac and SMS return 21 hits (most are
even for ServerPac ;-), none of which have to do with space allocation
specification either. Dialog defects, incorrectly built JCL and such,
sure, but I found nothing that says the code that processes the space
allocation amounts is broken.
<SNIP>
I think I see the problem. I have not been talking about the allocation
from the viewpoint of amount of space but VOLSER specific issues.
ServerPac logic was, shall we say, declaring volumes to be SMS volumes,
based on the first two digits of the VOLSER. This then made volumes
in-eligible for the datasets that were specifically set to go to those
volumes.
Example: CMSRES, CMSCAT, CMSnnn as you can see start with "CM". But when
telling the install what the volume was for SMS control, it saw the "CM"
and decided from that point forward that any volume starting with CM was
an SMS controlled volume.
<snip>
I can't find an APAR that describes that problem and I don't recall it,
either, but that doesn't absolutely mean it never happened. (Memory is
the second thing to go, right? ;-)
But it's the *logical* volume (LVOL) serial starting with "SM" that
identifies a group of SMS-managed data sets. There is no *physical*
volume serial displayed for an SMS-managed data set in the dialog,
because we can't know where the data set will wind up in advance; that's
up to your SMS configuration and ACS routines. Instead, the dialog
displays a STORCLAS for SMS-managed data sets.
The CHANGE command can switch back and forth at the group level (either
by LVOL, originally, or by View and Change attribute, the latter being
much easier) and you can use the panels to switch back and forth at the
data set level. (In either case, the SMS-eligible and SMS-required
attributes control whether you can make the change.)
There are additional restrictions, such as the requirement to change the
LVOL of a data set to change its SMS-managed status unless you change
the status of the entire LVOL's worth of data sets at the same time (if
you change from SMS to non-SMS, the dialog will rename the LVOL so it no
longer starts with "SM"). It would not be terribly hard to get lost
here and think that a data set was "stuck" in an SMS-managed state.
The SMS support was, admittedly, somewhat complex and confusing before
we introduced the View and Change option in a later release. This is
largely the consequence of very old design decisions that created LVOLs
and how they were processed to begin with. I would like to think that
nobody is messing with them any more now that View and Change can shield
everyone from having to worry about them.
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
