Cole Software ships its z/XDC product in an SMP/E package, but we've
made some unusual philosophical choices that result in a considerably
simplified installation process as compared to the operating system
and to most other products.
Background: SMP/E is designed to support an incremental maintenance
philosophy for huge and hugely complex software structures (the
entire operating system, and its myriads or subproducts, for example).
Incremental?
- You RECEIVE and APPLY new maintenance to a software base.
- If you don't like it, you can RESTORE the base and then
REJECT the maintenance.
- But if you do like it, you can then ACCEPT the
maintenance and, thereby, establish a NEW BASE for
subsequent maintenance.
So the "base" to which you RECEIVE and APPLY maintenance increments
over time. And once maintenance has been ACCEPT'd into the base, you
CANNOT remove it. All you can do is to RECEIVE, APPLY and ACCEPT
superseding maintenance.
Supporting an incremental maintenance philosophy for complex and
fluidly interrelated software systems requires complex capabilities.
It's simply in the nature of the beast, so there is no way to keep
both SMP/E and the maintenance process itself from being complex.
The major reason why Cole Software packages z/XDC with SMP/E is that
it makes the management of post-release maintenance very simple for
me, and it makes the installation of maintenance trivially simple for
our customers. Also, it leads our customers to use an installation
process that is uniform across our customer base, and from a support
standpoint, that is extremely valuable.
But there are two things that we've done to our SMP/E process that
are, perhaps, unique and that extensively simplify the process both
for ourselves and for our customers. Both of these characteristics
are made possible by the fact that, from an installation issues point
of view, z/XDC is pretty simple. (They would not work for complex
products with complex interrelations with other products.)
First, we follow a cumulative methodology (not an incremental one)
for our maintenance. This means the following:
(a) Every maintenance file that we publish contains all
maintenance, accumulated since the product's release
date. The nice thing about this is that when a
customer needs to apply a year or two's worth of
back maintenance, all he has to do is download,
RECEIVE and APPLY just one maintenance file. That's
all.
(b) This requires the customer never to ACCEPT z/XDC
maintenance. Why not? Because the cumulative
maintenance file is always designed to fit the product
as it was originally installed. If an ACCEPT were to
be done, then the installation libraries would be
irretrievably changed such that the maintenance file
would no longer fit.
(c) So the maintenance job we provide does the following:
RESTORE: This removes prior maintenance from the
TLIBs, restoring them to their initial installation
state.
REJECT: This removes the prior maintenance data from
SMP/E's database.
RECEIVE: This introduces the new maintenance file
into SMP/E's database.
APPLY: This applies the new maintenance to z/XDC's
TLIBS.
Second, we are able to insure that all dependances that z/XDC might
have, either on Operating System capabilities or on other products,
are resolved at EXECUTION time, not at installation time. By doing
this, we are then able to require our customers to NOT install z/XDC
into there existing SMP/E libraries, but instead to create an
entirely independent set of SMP libraries (CSI, PTS, etc.) devoted
solely to z/XDC!
The benefits of this are profound:
(1) Waste of disk space? NOT! After initial installation, the
z/XDC-dedicated SMP database and libraries start out at 30 tracks.
Ok, allowing reasonable space for expansion, it might be better to
allocate a hundred or so (at most!).
(2) Since z/XDC's SMP/E datasets are independent from the rest of the
system, we can impose optional settings that (a) are specific to
z/XDC's maintenance needs and (b) are uniform across our customer
base and (c) do not conflict with the needs of other products.
(3) Since the SMP/E datasets are independent and uniform, we can
provide canned JCL for our customers to use that work right out of the box to:
(a) Purge older SMP/E datasets (CSI, PTS, etc.) and
product installation libraries (DLIBs and TLIBs)
(b) Create new ones
(c) Establish all needed SMP/E definitions and settings
(d) Install the product into new TLIBs and DLIBs
(e) Apply all accumulated maintenance
This is a suite of four jobs that take a grand total of four minutes
to run (even on a flop-top system such as ours!).
(4) Since the SMP/E process is uniform and the SMP/E phase jobs are
all canned, the installing programmer can run a successful install
with no (zero na-da zilch!) knowledge of SMP/E.
(5) Even if the sysprog screws up and does do an ACCEPT of z/XDC
maintenance, the recovery is dead simple: Just rerun the four canned
SMPE jobs to purge and rebuild the SMP-libs, DLIBs and TLIBs.
I suspect that many (if not most) commercial products would benefit
from taking an approach such as ours. At the least, using independent
SMP/E datasets would relieve problems created for customers and
vendors alike when one vendor uses poor judgement in their packaging designs.
Dave Cole REPLY TO: [EMAIL PROTECTED]
Cole Software WEB PAGE: http://www.xdc.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
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
