At 9/12/2006 02:12 PM, ArthurT wrote:
On 12 Sep 2006 10:28:29 -0700, David Cole wrote:
(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.
<snip>
I suspect that many (if not most) commercial products would benefit
from taking an approach such as ours.
Please don't encourage this misuse of SMP.
Hi Arthur,
I guess I have to take strong exception to your characterization of
my suggestion as a "misuse" of SMP/E. Yes, it is different than
"normal", but my process suggestions offer significant benefits both
to the vendor and the customer for those products whose installation
requirements are simple enough that they can take advantage of it.
In any case, my process uses proper SMP commands and packaging with
no degradation of SMP/E capabilities. It's not like I'm suggesting
that nonsupported interfaces or methods be used.
So I will continue to strongly encourage my approach for those
products that can benefit from it.
I like your product [thank you -dbc], but this technique is contrary
to the spirit of SMP. [I'm not sure I agree that SMP has a "spirit".
;)] Therefore, it causes cognitive dissonance in some of us who do
understand SMP, and wish to use it correctly. Since the technique
is different from what I'm used to, it takes longer than if it were
the normal, "complicated" SMP install of maintenance. ACCEPT,
(Optionally REJECT,) RECEIVE, APPLY is the normal route for mass
maintenance, and takes very little time or thought, as long as the
maintenance is packaged correctly.
As I explicitly state in z/XDC's Installation Guide:
"If you don't like SMP, if you don't know SMP, if you
don't want to know SMP, then this is the installation
process for you. It is self contained, and it works very
well. Just use the installation jobs and process that
I've supplied, and you won't have to go anywhere near
your system's SMP libraries. In fact, you will have an
easier time then the experienced Sysprog who is probably
going to insist on remangling this stuff into something
that works 'the right way'. (Oh well.)"
Note particularly the last sentence:
"In fact, you will have an easier time then the
experienced Sysprog who is probably going to insist on
remangling this stuff into something that works 'the
right way'."
Perhaps your view of the "correct" way of using SMP is more limited
than it could be?
Since many sysprogs are "just" SMP jockeys, is it too much to ask
that they be able to use SMP? If they can, then there should be no
need to "simplify" things for them.
Many of my customers are small shops that cannot afford to hire
people dedicated to being "SMP jockeys". So, anything I can do to
simplify their lives with respect to my product, they're grateful for.
In fact, the same goes for the large shops as well. Even the
dedicated SMP jockeys appreciate the exceedingly low impact that the
SMP/E phase of z/XDC's installation process has on their lives.
They've already got more than enough to do coping with the more
complicated installs.
And of course, appreciative customers benefit us in many ways.
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
