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.
--
Radoslaw Skorupka
Lodz, Poland
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
