Post by Seymour J MetzThe point to requiring use of SMP is not to satisfy a checklist, but to provide certain capabilities, e.g., tracking changes, installing fixes without having to do a "level set", backing off bad fixes, suspending the application of fixes with errors or requiring customer action.
The problem with applying fixes a la carte is that you end up with so
many combinations that virtually no-one is running the same combination,
let alone a comprehensively tested combination.
SMP/E does not work well with products that are written in modern
languages (and by modern, I mean languages with optimizers or even just
compilers that check parameters on calls to routines). SMP/E works best
for languages like assembler, where the programmer needs to track their
own dependencies, and products like the operating system where you have
a lot of components developed separately with loose relationships.
When developing a product in a higher level language, the compiler does
much of the work that SMP/E would do tracking interface changes.
As a developer you want to minimize public exposure of internal
interfaces, to simplify future changes and development. If you allow
components to be maintained individually, every interface becomes
quasi-public, in that you don't know how it might be called in the
future. Any change requires careful research of upstream and downstream
effects and writing PRE/IF/COREQs to match. On the other hand, if you do
a whole product replacement the need to keep track of requisites
essentially goes away, it is handled as part of the build. To get an
idea of the problems you could run into, have a play with the
refactoring tools available in modern IDEs and try to figure out how you
could package the changes in SMP/E, other than product replacement.
Individual fixes also prohibit a lot of the optimization that the
compiler can perform. The compiler can look at the program and inline
routines, throw away code that has no effect etc. To do that it has to
be able to examine the program as a whole. If you reserve the right to
replace individual modules then you limit the optimization the compiler
can do.
That's not to say that vendors can't provide a single fix to a specific
problem - they probably can. In many cases they would be able to check
out a specific version from source-control and provide a full
replacement with a single fix. How difficult that is would depend how
different the specific version was to the regular version containing the
fix. (Of course, if offered it might be a premium service at a
corresponding price.)
It's the same as a site's application code - I doubt there are any sites
that package their applications using SMP/E and migrate fixes from
development to production relying on PREREQs and COREQs to manage
dependencies.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN