Mike:
In the for what it's worth department, back around 1979 or 1980 (I'll
have to find a really old resume to get an exact date), I participated
on a task force which proposed exactly that. We proposed a two-prong
approach to making VM go away. This was a DSD project in Pougkeepsie,
NY. Our replacement consisted of a method to permit migration from one
operating system to another in the same machine (a major VM strength)
and would be accomplished by what we called "the thin layer" - you know
it today as PR/SM. The other solution was an implementation of a CMS
guest environment (a highly successful development environment) in MVS.
It would act exactly the same way as OMVS initially did. You could log
onto CMS from within a TSO session. We were able to give you a full CMS
environment which ran CMS applications by IPLing a CMS image under SIE.
Four of us produced a working prototype as proof of concept. We were
actually staffing up two teams to develop CMS under TSO when IBM pulled
the plug on the project. I was to be the team leader of one of the
development teams.
Mike Myers
Mentor Services Corporation
.Mike Walter wrote:
Personally, not speaking for Hewitt Associates...
:Rant on
Years ago IBM senior management tried to kill off not only CMS
development -- but all of VM. Actually, that's happened several
times. Sometimes the bell tolled for source code (effectively
preventing new features from being added by customers), sometime it
tolled as "co-existence" (functional VM stabilization). Most often
the bell tolled for marketing, of which effectively there was none for
many years. No marketing = no sales. No sales = business case for
IBM to say "no one cares: kill it." A self-fulfilling prophesy.
Apparently VM customers did not sell enough Big Iron - after all VM
and CMS apps are exceedingly "resource thrifty", needing far less
resources to perform the same tasks as some "O"ther "S"ystems.
At least twice customers rose up en mass, and in almost in arms, to
fight back. (Think: SHARE's "Source Force" and VMSHARE's "MEMO
NOTAGAIN".) The customer argument was that senior IBM management did
not know what they would lose if VM was dropped. Basically, IBM
senior management did not know for what VM customers used their
systems, nor how critical VM was to their business. And the VM
customers did not do a good job complaining to IBM when they wanted
something new in VM. We just used the terrific VM capabilities to
write our own. I'm still pretty sure that IBM doesn't have a good
grasp of what their customers "do" with VM, nor how valuable it is.
IMHO - the most important point is that VM did not sell enough Big Iron.
But now (even after so many attempts to kill off VM), it *is* selling
Big Iron -- a large percentage of all new Big Iron. For Linux. What
would have happened to IBM had senior management been successful in
killing off VM on the first try? (Think: OS/2 and the PC business.)
Certainly, no IFLs. And the inability to convert legions of
decentralized servers onto single System z platforms.
One of the arguments often heard against *nix is it's level of
immaturity. They are still trying to do things that CP and CMS have
done for years, honed to a fine edge, and do with excellent (mature)
reliability. But now CMS is only good as a maintenance tool? Again:
The customer argument was is that senior IBM management did does not
know what they would will lose if VM was CMS is dropped (to the level
of hipervisor support).
Ignorance breeds intolerance. There seems to be a lot of intolerance
by senior IBM management for continued CMS enhancements. I really
don't know how to educate senior IBM management. Maybe set up a
series of "common application" development projects and try them in
competing platforms to learn which is the first to reach production,
runs the fastest, runs with the lowest TCO, runs the most reliably
across a set of standard outages, and which recovers fully in the
least time? But I won't hold my breath waiting for that to happen.
CMS would probably score very well, not providing the desired results
to match the stated direction.
Another argument against CMS development: schools aren't teaching
mainframe skills for newbies. Commendably, IBM is attacking that
problem head on. For z/OS, Linux, and others - but I'd be willing to
bet a nice steak dinner that CMS application development is not
included in that educational attack. Chicken/egg. Good thing that my
bet wasn't a southern fried chicken dinner - we'd be EATing CMS
development! :-(
:Rant off - I'm getting too old to keep tilting at the same old
windmills, staffed by the next new senior managers with no CMS
expertise or understanding, but with a pre-closed mind.
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
represent the opinions or policies of Hewitt Associates.
*"Craig Dudley" <[EMAIL PROTECTED]>*
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
05/03/2007 01:26 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: z/VM usability
Alan,
How about comments on one of the basic premise of this thread - CMS
is "functionally stabilized"? From an external POV, it does appear
that CMS (and adjunct components like SFS) isn't (aren't) being enhanced
for the continuing support role it has in maintaining a z/VM CP
environment.
--
Craig Dudley
Manager, Mainframe Technical Support Group
Office of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
603-271-1506 Fax 603-271-1516
>On Thursday, 05/03/2007 at 11:35 AST, "Edward M. Martin"
><[EMAIL PROTECTED]> wrote:
>> But the "If it ain't broke, don't fix it." was caused by IBM not
>> supporting a product that is supported by the other IBM Operating
>> systems.
>>
>> IBM is basically breaking a working system. (IMHO)
>>
>> And I am working on away to get off the VM/VSAM part, and it looks like
>> it will be a NON-IBM solution. But I am still looking.
>
>By "business as usual", I mean that IBM continually withdraws products
>from the marketplace, even some that people are using. There are still
>people using VM/ESA V2.
>
>It was nearly two years ago (June 2005) that we announced that you would
>no longer be able to order VM/VSAM effective September 30, 2005. In
>August of the same year we announced that VM/VSAM would end service
>February 28, 2007. Standard meaning: "Don't deploy new applications
that
>depend on VM/VSAM and begin working on a migration or risk mitigation
plan
>for applications you already have." It's true that if there is no
>replacement product from IBM, and no 3rd-party substitute, then, yes,
the
>application is eventually re-hosted or discontinued completely. And
>sometimes on a non-IBM, non-Linux platform. IBM makes the decisions it
>makes and has to live with the consequences.
>
>I'm also sensitive to the fact that those decisions can also affect
>someone's livlihood (inside IBM and out). I don't blame anyone for
being
>upset, if that's the case.
>
>Don't get me wrong, I wish VM/VSAM was still around, but it isn't, so
>you're doing the right thing, triggering an application review. If you
>choose that the risk of being unsupported is greater than the benefit
your
>company derives from the application, then it is time for a change.
>
>Finally, to the best of my knowledge, we have done nothing to "break" a
>working system. If you find a defect in CMS that causes VSAM to break,
>and you have a VM support contract, we will fix it. If you find a
defect
>in VSAM itself, no such luck unless you have an extended VSAM support
>contract.
>
>Alan Altmark
>z/VM Development
>IBM Endicott
----------------- End Forwarded Message -----------------
--
Craig Dudley
Manager, Mainframe Technical Support Group
Office of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
603-271-1506 Fax 603-271-1516
------------------------------------------------------------------------
The information contained in this e-mail and any accompanying
documents may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient of
this message, or if this message has been addressed to you in error,
please immediately alert the sender by reply e-mail and then delete
this message, including any attachments. Any dissemination,
distribution or other use of the contents of this message by anyone
other than the intended recipient is strictly prohibited.
