I am the one who rejected this requirement.
While I certainly don't want to paint us as unresponsive to client
wishes, and as much as I can appreciate the wish that every module had
an eye-catcher, I am afraid that in this case an infinite number of
votes seem unlikely to change the answer.
There are consequences to consider for each approach to adding this data
to every module shipped by IBM. Let's look at the four I can think of:
1. Suppose we were to change SMP/E to insert this information into the
programs it stores. Every load module and program object (including
those in the z/OS UNIX file system, and those that already have
eye-catchers) would grow by a minimum of 32 bytes or so (FMID, RMID,
UMID, date). Many would grow considerably more than that (32 bytes per
MOD entry associated with an LMOD). That would increase both the
virtual and real storage required to load each program, including those
loaded into common storage areas such as the Nucleus and LPA, both above
and below the line. (We cannot predict the growth because we don't know
how many MODs wind up in more than one LMOD.)
The growth could have other consequences we cannot predict without
testing, and testing the variations would be quite expensive. Product
teams across IBM would need to agree that this was a Good Thing, too,
since their listings would no longer match what SMP/E actually put away,
and gaining their agreement is unlikely on that basis alone.
This would be a platform-wide issue as well, affecting other software
vendors who package their products using SMP/E. I have not asked, but I
doubt many of them would want to have SMP/E add data to their code, either.
2. Another alternative is to repackage every IBM FMID that is compiled
without eye-catchers to add them. That is simply impractical. The
ServerPac catalog in Shopz shows that we have 681 orderable products
today. Many, even most, of those products have more than one FMID.
Every single FMID that does not provide eye-catchers would have to be
recoded to add the eye-catchers to every module, recompiled, reinstalled
and retested, have a new copy sent to Software Manufacturing, and so on.
The storage requirements for those products would grow, too, but at
least it would be only those that don't have eye-catchers today that
grew instead of "all of them."
In addition to being an impractical undertaking, this would introduce
risk and churn for everyone. Some older products have not been
recompiled in their entirety in a long time. We would need recompile
many of them using newer compilers, and replace the products with new
releases that would have no new function. We would want to sunset the
old releases, and people would be forced to "upgrade" to stay current
when they could otherwise leave the affected products alone.
3. We (collectively, I hope) don't even want to *think* about replacing
every module without an eye-catcher with new modules via PTFs.
4. If we were to require only new products to be packaged using
eye-catchers, we would have a Fifty Year Plan to get the entire
portfolio into compliance. Even though this has the merit of being
practical to some degree, it would be woefully ineffective in providing
anything useful any time soon.
Can anyone think of a #5?
IBM recommends that you clone your SMP/E zones with your software. One
reason is so you can use the existing functions we provide to display
software service levels.
I'm happy to continue this discussion online or offline to see if there
is anything we can and should do here, but when we get a requirement
that specifies an implementation (vs. a "what we want to be able to do"
requirement), the ship of wishes is often wrecked on the rocks of
practicality. I'm afraid that's the case here.
Karlheinz wrote:
Hi,
we have opened a RFE at IBM for having related FMID, PTFID and APARID as an eye
catcher in each load module being generated and maintained via SMP/E.
This would help to detect easily the maintenance level of a particular module
and load module.
Although the information is available in SMP/E (which PTF is applied), SMP/E
doesn't tell in which system a particular LMOD is used. This depends on the
deployment concept after SMP/E apply and the administration information where
particular maintenance levels are deployed.
We think this is a long outstanding requirement from each systems programmer
side to always be able to see at which maintenance level a particular module or
load module is.
It would support customer and vendor side in case of an incident.
Various teams in IBM and at other vendor side are already incorporating this
information during their maintenance packaging process. Unfortunately not all.
It would be great to have this setup as a standard.
This is the link to the IBM RFE:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=102792
If you support the implementation of this eye catcher information please vote.
--
John Eells
z/OS Installation Strategy
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
