Thanks for your comments, Mark. You raise some good points, requiring
me to review choices originally made 15+ years ago.
Almost all my maintenance is in the form of ++ZAPs. I do this because
it simplifies various source management issues. Once I've published a
release, there will be only one source library I have to keep for that release.
But SMP/E has a rather annoying restriction with respect to zap maintenance:
"Only one ZAP can be applied to a module by a single
APPLY command. If you need to install several ZAPs for
a given module, each one must be packaged separately
and installed by a separate APPLY command."
(from the ++ZAP MCS section of the SMP/E Reference
manual)
This means that if I packaged multiple fixes (to a single load
module) into multiple ++APARs, then I would not be able to have them
applied via a single APPLY command. Instead, I would have to require
the SYSPROG to use a different APPLY command for each ++APAR. That
would impose an unacceptable burden upon the SYSPROG.
It also leads to the incremental maintenance process being
unacceptably complex, because when a customer decides to download and
apply a year's worth of back maintenance, the one zap per module per
APPLY restriction would require that customer to run as many
APPLY-and-ACCEPT steps as there were fixes!
So for each load module, I have to gather my zaps together into a
single ++APAR.
Well, after thinking about this requirement for awhile, and
considering and testing various packaging strategies, I came to
realized that treating maintenance as being cumulative rather than
incremental was by far the best response to this restriction.
That was what got me started with the cumulative idea. But once
there, a whole lot of other benefits (amply described in my prior
posts) began cropping up.
So the methodology works well.
It is fast.
It is simple.
It is reliable.
It is easy for me to maintain and support.
It insures a high level of consistency across my customer base.
I'm happy with it.
My customers are happy with it.
So exactly, what is it I'm supposed to be caring about here?
At 9/13/2006 03:27 PM, MZelden wrote:
On Wed, 13 Sep 2006 14:13:56 -0400, David Cole <[EMAIL PROTECTED]> wrote:
At 9/13/2006 01:30 PM, TMerchant wrote:
But why does it require that previously received maintenance be
REJECTed and that previously APPLY'ed maintenance be RESTORed?
Because our maintenance is cumulative, not incremental.
So?
- That means that the latest maintenance file always
contains all maintenance, not just the most recent.
Okay. That's a good thing.
Thanks.
- That means that the file as a whole has to be APPLY'd to
the instance of the product that existed immediately
after initial install.
Because of the way you are packaging sample jobs and sysmods?
No, because the maintenance is cumulative, not incremental.
- That means that all prior maintenance has to be removed
before the new maintenance file can be successfully
APPLY'd.
- And that's what RESTORE and REJECT do.
- And that's why our canned maintenance JCL contains
RESTORE, REJECT, RECEIVE and APPLY, in that order.
In other words, the process is fully automated by a
single job.
If all the PTF relationships are correct, why can't someone just
receive the cumulative maintenance and apply what hasn't been
applied previously?
Because of the restriction that multiple ZAP fixes cannot be applied
to the same load module via a single APPLY command.
I guess for a small product your method works, but I don't see where
it is any easier. I would hate to do all that extra restore /
reject work for nothing.
It's not really "all that" much work, Mark. The canned JCL automates
it and is very reliable.
Even prior to RECEIVE ZONEGROUP(ALLZONES) (which has been available
since OS/390 2.5) you could have supplied one additional REJECT
PURGE(dlibzone) ("mass mode reject") after your receive job to get
rid of any extra sysmods received that had already been accepted. If
they had not been accepted, they wouldn't get re-received anyway.
There have been many advances in SMP/E since around 1990 or so when I
first started using SMP/E packaging. But I have not bothered to keep
up. Why not? Well ...
- I am not an SMP expert.
- I don't live, breath, or even like the stuff.
- What I did come up with works well and is well accepted
by my customers.
So I have no incentive whatsoever to "upgrade".
In any case, what you've mentioned here is not the issue. The real
issue is the one-zap-per-APPLY restriction.
Regards,
Mark
Ditto,
Dave
----------------------------------------------------------------------
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
