Art Gutowski wrote:
At the last SHARE, the question was asked at the multivendor
installation-related
session about how many in the room were z/OSMF users. In the past, I've seen
those raising a hand to be perhaps 25% of a similarly-sized crowd, but in March
about 2/3 of those present raised a hand (a pleasant surprise). Of course, one
room at SHARE does not a valid statistical sample make, but it's one data point.
But is it a valid data point? We use z/OSMF only insofar as we are forced to
for IP configuration and upkeep. We did not use z/OSMF to install v2.2, and I
don't know whether we'll use it to install v2.3. There is talk of it, but it
seems to be largely motivated by the thought that we will be forced into it
(kind of like zFS).
It's certainly a valid data point (by which I mean, some people sent me
notes and their estimates were similar!), but it might or might not be
representative of the population at large.
Don't get me wrong, we've had talks... I'm with simple and common software
management processes, and I'm glad to see ISVs on board, but I'm not convinced
that z/OSMF in and of itself is either necessary or sufficient to achieve the
goal. If you have good SMP/E packaging, z/OSMF is unnecessary as an installer.
If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be
sufficient to address the shortfall.
SMP/E packaging, good or bad, cannot by itself:
- Aggregate products into a single package with a single installation
path to use no matter how many products are included
- Support integrating service "back at the ranch" so that you don't have
to do that on the receiving end
- Address the direction and management of tasks to the appropriate
people on your teams in the right order
- Help you get through setup tasks that must be done everywhere the
software is deployed
- ...and so on.
We need a platform to do that, and we have it in z/OSMF. That's why
we're going to use it. Also, one point is that, like ServerPac, you can
*avoid* the lion's share of the SMP/E-related work. Another is that
things that are not SMP/E packaged, and are likely never to be SMP/E
packaged, can be installed and deployed across your shop with the same
process.
I don't see the need for z/OSMF for software deployment. We have plenty of
experience here, and are easily passing that along to our newer sysprogs. I
recoil at the thought of using it for configuration. ISPF is sufficient to
edit PARMLIB, et al, and it runs in a WS client, if you so choose.
Seems to me, any of the substantive improvements offered by z/OSMF ought to be
UI-agnostic. It doesn't take a "sticky" UI and and the overhead (FSVO minimal)
of a server address space to improve product installation. These might have been made
accessible ServerPac, or even the SMP/E dialogs, but they weren't. It's a fine thing for
someone who wants the trouble of installing and configuring Liberty et al (and I've heard
the cursing all the way from Austin and Phoenix), but ISPF apps ought to continue as
supported options for those who prefer them.
That's my buck-two-eight-five, after adjusting for inflation. :)
--
John Eells
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
