Your "no interaction between the product and any other component"
implicitly includes it, but perhaps it should be explicitly stated that
this means the non-SMP/E product, or a product with its own SMP/E zones,
may not require the installation of any elements in libraries "owned" by
any other product or SMP/E zone. While it is acceptable to have a
non-owning product or zone reference and use elements in a library
associated with some other SMP/E zone, it should be mandatory that only
one zone "owns" any given library and FMIDs in that zone own all
elements in the library. You can get away with violating that rule if
the element names are still all unique, but it is a bad idea to do so.
And, so that one SMP/E zone always knowns the state of all elements in
an owned library, any local customization to a product maintained by
SMP/E should either be applied via USERMOD or to separate non-SMP/E
local libraries.
JC Ewing
On 07/23/2013 07:32 AM, R.S. wrote:
> W dniu 2013-07-23 13:41, Donald Likens pisze:
>> I have been working with SMP/E since before there was an E (SMP) (over
>> 40 years) and I believe shops that limit themselves to SMP/E installed
>> products are simply causing themselves extra work.
>>
>> I am a consultant and a software developer. Recently had two installs.
>> One from IBM using SMP/E and another not using SMP/E. Both products
>> were of similar size and complexity. The installation for the none
>> SMP/E installation took under a day. The installation for the SMP/E
>> installed product took about a week and cost my client much more money
>> (consulting fees).
>>
>> I think SMP/E is required for products as complicated as the operating
>> system, DB2, or CICS because it keeps track of the maintenance
>> installed but for products that can be version controlled a non-SMP/E
>> install is much quicker and easier. The product I develop does not use
>> SMP/E simply because it is not needed.
>>
>> If a shop required an SMP/E maintained product, I guess I would create
>> a CSI etc. but I would download it like a serverpac.
>>
> IMHO some people think consider SMP/E a black magic.
> SMP/E is IBM standard, it's always good to adhere the standards, but:
> - if you install the product in separate CSI (with no "cross-link"
> DDDEFs), then there is no interaction between the product and any other
> component.
> - if you provide service as replacement of whole modules/libraries/all
> the product, then internal dependencies give no value.
> - if your product checks required dependencies at runtime level, then
> it's pointless to use SMP/E for that.
> - it is much easier to install simple product by using XMIT format and
> RECEIVE few libraries.
> - it XMIT itself does not precludes further SMP/E process, it can be a
> method to omit the tape or pax/zip archives.
>
>
> SMP/E is overcomplicated, non error-free and definitely not error-proof
> (and idiot-proof).
>
> Some examples:
> 1. IBM Encryption Facility v1. Two loadmodules were added to
> SYS1.LINKLIB, 50k+ lines of sysout. Overcomplication.
> There is an option to install it in separate CSI, but then nothing is
> installed (AFAIR due to lack or pre-req's in the separate zone).Of
> course no clue about it.
>
> 2. IBM CCCA, delivered as a part of Debug Tool. It's veeeery old tool,
> last change/update happened many years ago. Unfortunately ther is a
> mistake in description of one component. And THERE IS NO WAY TO FIX IT!
> It CANNOT be fixed by PTF, the only way to fix it is the following:
>
> SET BDY (TARGET).
> UCLIN.
> REP SAMP(ABJ058)
> RMID(H09F210).
> ENDUCL.
> SET BDY (DLIB).
> UCLIN.
> REP SAMP(ABJ058)
> RMID(H09F210).
> ENDUCL.
>
> You can order up-to-date package with the latest service and you will
> still get the same old error and still NO CLUE about it, unless you know
> it.First time I met it in 2006, nothing happened since then. It's still
> not fixed and no clue.
>
> 3. HOLD(ACTION) informing that ...you have to apply the PTF. THIS PTF
> containing the action. Other HOLD(ACTION)'s informing about DOC changes,
> DB2 binds, etc. etc.There are plenty of misnamed HOLDs.
>
> 4. Job samples with REGION=4M at IEFBR14 step as well as at GIMSMP step.
> In first case it's only funny, for the second one itwon't work.
>
> 5. Program Directory. It's related to SMP/E in some way (strictly or
> loosely - your choice). PGMdir describes non-existent world of "Product
> Tapes", while it's known for years that you get CBPDO (or other) tapes.
> So you have to interpret the description in a way applicable to real
> world. It's like description of the travel by a horse when driving new
> car on the highway.
>
> 6. Memo to users, readme first. The only information is "print Memo to
> Users Extension".
>
> 7. Installation tape. It's happened to me many years ago. I've got 40
> carts in the box, but SMP/E treat it as THE TAPE. Singular. It's
> multi-volume TAPE. When miexed with nonexistent product tapes it's
> really misleading.
>
> 8. Some products are installed using SMP/E every module is under strict
> version control, but later ...you have to unpax some big archive and
> continue installation completely out of SMP/E control. SMP/E is used to
> "apply" the installation package, a kind of SETUP.EXE. In such case any
> update means another SETUP.EXE. And we have both complexity of SMP/E and
> no control of the SMP/E. One of the examples is WAS. The installation of
> WAS is a nightmare, don't even try to change any RACF username or any
> other detail - you will never know what is hardcoded!
>
> 9. SMP/E is not enough to install the product. Even wih job samples you
> sometimes have to perform many actions not covered by the installation
> process. It's not only allocation of the libraries (out of SMP/E but
> usually in samples), but also LPA, LNKLST, APF, PARMLIB, operational
> datasets, and many, many other activities, required to make the product
> working. Usually it's called "post installation activities", but it's
> simply part of the installation, completely out of SMP/E scope.
>
> 10. Cross-dependencies. When installing z/OS using ServerPac, you are
> asked about names f several CICS and DB2 libraries. Assuming it's new
> installation and you don't have those products yet, or you don't use
> them at all what are the correct answers? Despite of your answers you
> will get JCL errors, unless you manually fix the jobs, or omit them.
> Of course there is absolutely no clue what to do in such case. Quite
> usual, IMHO.
>
> 11. The idea of SMP/E is to have one CSI and all the products,
> components in that. Even IBM ignores it - the ServerPac consist of
> separate installations, divided by SREL. Later they ask you to create
> "cross-links" to some libraries, so DB2 CSI has a DDDEF to SYS1.CSSLIB,
> etc.
>
> 12. No consistent (included in SMP/E) way for samples customization. I
> mean HLQs, dzone, tzone, etc.
>
>
>
>
>
>
>
>
>
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
