You can still use native SMP/E in batch to retain control of your system
installs/maintenance: just do CBIPO instead of IBM's 'recommended'
installs (the distribution tapes should still be in the original format).
IBM had been trying to force us to use their SMP/E 'dialogs' since the
mid/late eighties; but we took no notice. Next IBM tried to force us to
use SystemPak, CustomPak, You-name-it-Pak etc. (as it was called then).
A bank asked me to install it for them in '99. So I did, I checked it -
and it was riddled with bugs (e.g. PROCs were written in lower case, and
why the heck did SystemPak need the master catalog password to install a
product anyway?). I raised a PMR with IBM about that and I got the
following answers.
- Level 1 said it was a 'wonderful product' and that all their customers
wanted it; so I replied that it was full of errors; escalate.
- Level 2 said that IBM had "found that many of its customers could not
afford to hire sysprogs" and that SystemPak allowed them to install
products without needing ditto; I replied again that it was full of
errors, that if IBM were so clever and their customers were so stupid
then why was it that IBM could not find e.g. the hlq of the current
PARMLIB instead of asking their customers to type it in a panel etc.;
escalate.
- Level 3 said (verbatim) "I never said that I agreed with it"; so I
replied "Thanks, you can close the PMR".
I then told the bank that SystemPak was full of errors and suggested
rewriting it for them - such that it would be 100% compatible with IBM's
version (in case IBM eventually fixed it), but without the bugs and
hassle. The bank said OK. So I wrote and installed my own version of
SystemPak for them.
IBM then spent several weeks calling and asking me to explain how I had
fixed their SystemPak, "so they could tell their developers in Canada" -
but forgot to mention how much they would pay me for that (tut tut).
Later, at a different company in 2000, I found that IBM had still not
fixed their SystemPak bugs. It's a pity I cannot remember the PMR number
I raised in '99 (I left it behind, at the bank).
IBM is following Microsoft's lead, because 99% of its customers are
computer illiterate but also have 99% of the money. So why bother with
the 1% of us who know how to avoid wasting CPU cycles, VS and DASD space
- but who thereby prevent IBM from selling more hardware - when there
are 'oodles' of customers out there to whom IBM can sell 10 times more
hardware than they actually need, and who believe that to follow IBM's
'recommendations' is the correct and proper way to avoid making
mistakes? (It used to be called "FUD".)
I would suggest that you stick with native SMP/E if you do not want IBM
to take it away from you ('out of support', as they say). You can create
your own CSIs by REPRO'ing the production ones (and then preferably into
a single VSAM KSDS as this is *not* recommended by IBM), then
"UCLIN"-changing them to point at your global/DLIB/TLIB zones and their
datasets (which you can also copy from the production ones) etc.
BTW TRSMAIN supports BLKSIZE=27648 for LRECL=1024 and IPCS supports
BLKSIZE=24960 for LRECL=4160, and you can ZAP any LMOD's hard-coded DCB
BLKSIZE to be whatever you want it to be - if it insists on overriding
yours.
Cheers, Chris Poncelet
Paul Gilmartin wrote:
On Mon, 22 Jul 2013 16:41:12 -0400, Dave Salt wrote:
SimpList can be added to that list as well. One reason is because many
developers want to try SimpList by installing it in their own private
libraries, and they don't have access to SMP/E.
Shame on IBM for transmogrifying SMP/E into a product that presents
an ineffable threat to system integrity, and for tolerating that
situation, apparently indefinitely! Prior to that all programmers
had access to SMP/E and could install products for trial in their own
private libraries.
On Mon, 22 Jul 2013 15:35:49 -0500, Tom Marchant wrote:
IMO, well-implemented SMP/E packaging is preferable to non-SMP/E.
However, non-SMP/E packaging is far preferable to poorly implemented
SMP/E packaging. Getting it right is difficult and some vendors do a very
poor job of it. IMO if a vendor doesn't do their SMP/E packaging correctly,
it is better that they not bother.
Where can I find some Rules of Thumb; an SMP/E style checker?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
