|
|
         
|
10
Ways to Destroy a ServerPac: Mistakes to Avoid By
Jim Schesvold & Amy Dodge Synopsis: The article describes 10 mistakes
commonly made with ServerPac and the impact these miscues can have on a software
migration. Callout: The time and effort a ServerPac entails
is greatly increased when indecision and ambivalence rule the day. Over the last 10 years, we've participated in 14
release or version upgrades of OS/390, CICS, DB2 and z/OS, all of which were
installed using ServerPac. These software migrations, which were performed
jointly with members of our client’s staff, gave us the chance to see how
different sites implement ServerPac and some mistakes they made along the way.
As with so many projects, these mistakes are due to inexperience, a lack of
planning and research, and an unwillingness to change. Here are 10 mistakes
we've seen made with ServerPac and the impact these miscues can have on a
software migration: As a starting point, ServerPac is IBM’s most recent
installation technique, whereby all target, distrtribution, SMP/E, etc. data
sets are loaded directly from tape, bypassing the SMP/E Receive, Apply, and
Accept steps. Through a set of
dialogs, such things as data set placement can be specified, and a set of
installation jobs and accompanying documentation is also supplied. 1. It's my DASD farm and I'll put data where I want to! We've worked
with clients who have put their production master catalog on the same volume as
third-party products, with SMP/E data sets, and in one case, with application
data. We've seen similar cases involving working data sets (JES checkpoint, SMS
ACDS/SCDS, couple, etc.), and in one case, where working, target, and
distribution data sets were all mixed together on the same volumes. We've also
seen a lot of out-of-space problems, a lot of unnecessary data set movement, and
a lot of confusion in these situations. The data set layout an installation has implemented and
the effort involved in changing a system's structure are major considerations,
but wherever possible, follow IBM's recommendations on data set placement,
naming, and use of facilities. These recommendations can be found in z/OS
Planning for Installation: Chapter
8–Preparing for Future Installations, at http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/e0z2b132/8.0.
Using this approach, system software–defined as
target, distribution, SMPE (CSI, PTS, etc.), HFS, and working (JES spool, page,
couple, etc.) data sets plus the master catalog–is separated from all other
data. By establishing this separation, many migration tasks (particularly moving
non-ServerPac data sets to new volumes) can be eliminated. ServerPac data sets
should be allocated on dedicated volumes as follows:
Use the IBM-recommended data set layout if possible. If
you choose to change the ServerPac-supplied layout extensively, Modify Dataset
Layout can easily be by far the most time-consuming step of the ServerPac
process. The IBM-recommended data set layout groups data sets by type, such as
CLIST, PNLxxx, HELPxxx, MSGxxx, LMOD, and so forth, and then lets you define how
ServerPac should automatically assign the target and distribution data sets. For
more on this, see http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/CPP2UD40/8.1. 2. It's my DASD farm and I'll name the data what I want!
We've also worked with clients who rename the data sets supplied with
an IBM ServerPac. In one case, a client used a SYS1 high-level qualifier for all
data sets (including third-party products) needed for system startup. In another
case, they renamed the JES2 data sets (which had the
version/release/modification as a second-level qualifier) to that of a different
release. The purpose was to eliminate some JCL changes. Whenever possible, leave
the IBM-supplied names alone! Among
other things, you’ll have to change data set names in Modify Data Set Layout
every time you install a ServerPac, and if you’re changing data set names to
ones that already exist, it’s both confusing and rife with problems. 3. It's my
master catalog and I'll fill it my way! Especially
in the case of the ServerPac full refresh, working with a master catalog that
contains a myriad of non-ServerPac data sets can really complicate the creation
of the new ServerPac test system master catalog (as well as consequent
production systems). The most egregious instance like this that we're run into
was when a large number of third-party product loadlibs and working data sets,
plus a few application data sets, were given SYS1 prefixes to force them into
the master catalog. The reason for this approach was an obsolete disaster
recovery procedure that required only the master catalog for full system
startup; because it was no longer required, we removed all unnecessary data sets
from the master catalog during the software migration. As is often the case when
changing system structure, JCL changes and other implications require a
significant effort, but one that makes future migrations much simpler. Another master catalog consideration when deciding
whether to do a full refresh or a software upgrade is that a full refresh
creates a master catalog where all data sets directly reference the volumes
they're placed on. The catalog entry contains the specific volume where the data
set exists, rather than a symbolic reference to the volume placement. Indirect
cataloging is highly recommended because it greatly simplifies the cloning of
one MVS image to another, as well as simplifying software migrations. If you do
a full refresh, you’ll have to manually convert most of the catalog entries to
indirect references, a time-consuming task that’s not necessary when doing a
software upgrade. A tool called RCNVTCAT, which is written in REXX and
which can be found on the CBT Tape collection, eases the process of making data
set name changes, defining new data sets, and indirectly cataloging data sets
into a new master catalog. Learn more by scrolling down to file 542 at http://www.cbttape.org/cbtdowns.htm
or by downloading the CBT542.zip file. 4. Do it the
way it's always been done! No
changes allowed! IBM has added several features in recent releases of OS/390 and
z/OS:
ServerPac builds such things as PARMLIB entries,
startup PROCs, allocation jobs, and other entities using these features. So, if
you choose not to implement these features, you’ll have to "reverse
engineer" ServerPac-created objects to define and implement your new
system. For example, SYS1.PARMLIB, CPAC.PARMLIB, and SYS1.IBM.PARMLIB must be
merged in that order if concatenated PARMLIB isn’t used; the same applies to
PROCLIB data sets. Changes in file allocation defaults have to be made via
Modify Data Set Layout. We've had to make these and other similar modifications
to ServerPac and can testify to how this complicates and delays what should be a
straightforward set of tasks. For more information, see “Structuring Your
System for ServerPac” at www.mainframehelp.com/structure_your
system_for_serverpac.htm. 5. Let's try
it this way. One of our
greatest challenges is when a client repetitively changes data set names,
placement, size, or other ServerPac variables, especially after the ServerPac
installation jobs have already been run. System-Specific Aliases (SSAs) may need
to be rebuilt, PARMLIB members will have to be changed, jobs may need to be
rerun, and there are no directions on how to do this. HFS data sets need to be
repopulated and rebuilt from your existing HFS data sets. And, especially in the
case of MVS working data sets (couple, spool, page, etc. data sets), we've
worked with clients who change their minds five and six times before they're
satisfied. The time and effort a ServerPac entails is greatly increased when
indecision and ambivalence rule the day. Taking the time to get it right the
first time is key to a smooth, efficient ServerPac installation. The way to
eliminate much of the indecision in building a ServerPac is to meet as a group
and fill out ServerPac worksheets before actually doing it. Everyone should
discuss and decide on variables, zone names, data set names, structure, layout,
aliases, and SSAs before starting ServerPac, then stick with those decisions. 6. I can do
my technical research after the ServerPac is installed. Putting off
the technical research necessary to determine the proper settings for ServerPac
variables means those values can change once the research has been completed.
Data set sizes in particular may change once the size of current data sets have
been evaluated in light of the new release. Do this review before installing a
ServerPac, not after! This can save
enormous amounts of time and effort, and prevent mistakes that can turn a
straightforward process into a convoluted, confusing maze. The most outlandish situation we've run into where
technical research was needed upfront, but was never performed, involved a
client who attempted to create their production OS/390 image directly from the
ServerPac. We attempted to get this client to document what he wanted, but
somehow there was never time to do this, and the result was that we created a
"pseudo-production" test LPAR. It's nearly impossible to create a
running clone of a running production MVS image via ServerPac. LPAR settings are
different, SYSNAME name must be different (in a sysplex), couple data sets must
be initialized differently, etc. These changes had to be resolved one at a time
as errors occurred. It would have been so much easier if only the research and
planning had been done first. 7. The
ServerPac is here, but it will have to wait for a while. If you let a ServerPac sit for a
few months before installing it, the maintenance will be outdated. If it's a
software release that's still available from IBM, this isn’t a big deal
because the ServerPac can be reordered and brought to a current maintenance
level before it’s installed. But if IBM has withdrawn the product from
marketing, you must order some form of maintenance to obtain current support. In our most notorious experience with this, an OS/390
ServerPac was almost a year old when the client was finally ready to install it,
and OS/390 was by then withdrawn from marketing. After ordering the necessary
maintenance to bring the ServerPac up-to-date, 27 tapes showed up, sufficient to
fill up the SMPPTS when an SMPE RECEIVE was run. After increasing the SMPPTS
size several times up to the size of a full 3390-3 and still running out of
space, the maintenance was put on in pieces. It became a repetitive process of
APPLYing and ACCEPTing a portion of the maintenance (freeing up some SMPPTS
space), then selectively RECEIVEing more prerequisite Program Temporary Fixes (PTFs)
that prevented other PTFs from APPLYing, running the APPLY and ACCEPT again to
free more space, RECEIVEing more PTFs, etc., until all the maintenance was on. A similar situation is developing with z/OS V1.4. z/OS
was scheduled to be withdrawn on March 31, 2004, so if your plan was to install
z/OS V1.4 late in the year, you had no choice but to do it with an outdated
ServerPac. Although IBM extended the marketing withdrawal date to September 9,
2004, the lesson still holds: Install a ServerPac as soon as possible after it
arrives or the maintenance will become outdated and need to be upgraded. 8. I don't
need or want to understand ServerPac. ServerPac does some obscure things such as using the
SSAs to get around a duplicate data set situation. ServerPac unloads target,
distribution, SMPE, and other data sets, many of which already exist on your
driving system, by putting a High-Level Qualifier (HLQ) you determine on these
data sets. This avoids duplication in the data sets being unloaded; it puts an
alias in your current, driving system master catalog that uses this HLQ in
conjunction with the actual data set name to point to the real data set. SSAs may not be the easiest concept to grasp, because
only ServerPac uses them, but they’re a fact of life. We had a client,
however, who was so convinced they were unnecessary that he would delete them
when he worked with related data sets. We would then either refer to the data
sets by volume, or restore the SSA, and our attempts to explain what SSAs were
and why they were important fell on deaf ears. Similarly, this individual
refused to consider doing a software upgrade rather than a full refresh because
the software upgrade wasn't available when he worked with ServerPac, and he
wasn't willing to spend the time to evaluate it. To effectively use ServerPac, you need to understand
the philosophy behind it and the reasons it works as it does. Otherwise,
ServerPac will be a lot more work and more mistake-prone. 9. What is
this SMS stuff? Why should
I need HFS files? Even if you don't use System Managed Storage (SMS) or HFS
files, you need both for ServerPac. We had a client who was upgrading from
OS/390 V1.3 to OS/390 V2.7, however, who was convinced this wasn’t the case,
and who wanted to have nothing to do with something new. An Initial Program Load
(IPL) or an aborted facsimile of one finally convinced him of the need for these
functions. SMS must be brought up in a null configuration because
SMS must be active to use HFS files, but since it's only in a null
configuration, this isn’t a difficult task. For more on the SMS null
configuration requirement, see the following resources:
Especially in the case of the z/OS ServerPac (CICS and
DB2 also have their own HFS files), there are several steps involved to prepare
the data sets for use:
The HFS file creation process is somewhat unwieldy and
confusing, but it’s necessary. What can you do to smoothly get through these
steps? Ensure that someone on staff
has working Unix System Services skills, especially regarding HFS files. Second,
get it right the first time. Deleting and re-creating the HFS files can get much
more complicated and time-consuming than for most other files, and it should be
avoided, if possible. 10. Planning
and communication? Who needs it? It seems obvious that project planning, management, and
control are cornerstones of a successful migration. But in most migrations we've
been involved in, it's been a real struggle to get effective project management
in place. You can produce a good migration plan, but without client management
support, the plan will be ignored. If client management gives strong support,
the plan gets followed, and things go smoothly. Otherwise, we've seen the
following:
The project manager must have a basic understanding of
what's involved in a z/OS, CICS, or DB2 migration. He doesn't have to be a
technical whiz, but he should be able to follow the conversation during a status
meeting and understand the general ramifications of the technical issues. We've
worked with project managers who didn't have a clue as to what was going on, who
became nothing more than timekeepers due to their limited background, and who
asked us to do their minutes because they were so lost they were incapable of
doing so. A project manager like this is a severe detriment to the
migration–an obstacle to be overcome rather than an expediter of progress. ServerPac is an installation tool with its strengths
and weaknesses, and a great improvement on the CBPDO process that preceded it.
But to really get the full benefit of ServerPac, you must understand how it
works and be willing to adapt your system structure to the ServerPac
methodology. It’s a significant effort, and there may be situations where your
unique system requirements will preclude adoption of certain ideas, but the
closer you can follow ServerPac's approach, the easier and quicker your software
migration will occur. |
|
Send mail to solution@mainframehelp.com
with questions or comments about this web site.
|
