[Info-vax] Happy new Year !

H Vlems hvlems at freenet.de
Sun Jan 10 08:40:20 EST 2010


On Jan 10, 10:47 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <00c156c3$0$1606$c3e8... at news.astraweb.com>, JF Mezei
>
> <jfmezei.spam... at vaxination.ca> writes:
> > At the time Compaq bought Digital, VMS still had a chance to be
> > resurrected. In fact, the short lived "renaissance" where VMS was
> > allowed a tiny bit of marketing did show that it was possible to grow
> > VMS significantly.
>
> When I started with VMS in 1992, I heard from many people that it was
> already obsolete and wouldn't be around in 5 years, much less 10 or 15.
> Queue famous Mark Twain quote.  But...
>
>
>
>
>
> > One of the arguments used as an excuse to murder Alpha is that by moving
> > VMS to an "industry standard commodity CPU", it would enable a wider
> > breath of applications from desktops to data centres. (which had been
> > the original goal of IA64 back in the 1990s).
>
> > Initially, we were told to wait because once VMS was commercially
> > available on that IA64 thing, HP would start to market it as one of its
> > own products. It didn't. And that was the last reasonable window of
> > opportunity for a true VMS renaissance.
>
> > Remember that after the port to IA64 was done, HP began to downsize VMS
> > engineering.  Had it maintained the higher staffing levels, they would
> > have been able to push ahead with plans to make VMS more compatible with
> > Unix, and had they been able to complete this quickly, then all the
> > desktop Linux applications could have easily been made available on VMS.
> > And if done right, the #ifdefs for VMS could have been incorporated into
> > the main open source code, making every new version of the product
> > quickly available on VMS.
>
> > They did manage to port Mozilla to VMS (and all the middleware needed
> > for it). The problem is that they didn't have the resources to "finish
> > the job" by having all of the customizations sent back to the open
> > source   code so that it would then be easy to build the apps on VMS
> > whenever new versions come along. But the port of Mozilla was a proof
> > that it was possible to build modern applications on VMS.
>
> > Yes, it was possible to give VMS a new life, but that would have
> > required a nudge in both marketing and engineering resources. Neither
> > happened. Plans to make VMS "unix compatible" remain, but they are now
> > just pipe dreams still on the roadmap but without the quick delivery
> > needed to allow easy porting of Linux apps to VMS.
>
> > IA64 on the desktop was officially abandonned in early 2004 at roughly
> > the same time that Intel capitulated to market pressures and agreed to
> > produce what the market wanted: a 64 bit 8086.
>
> > In my case, I held my breath until 2004. HP had a chance between 2001
> > and 2004 to show that it would give VMS a chance. It didn't.
>
> > Between 2004 and 2009, it was a case of "not holding my breath, doesn't
> > look good, but still give HP a chance". As I recall, there was a speech
> > by Livermore in fall of 2008 which sealed the deal when she would not
> > include VMS in the "actively develop" and specified that they would
> > "support the VMS installed base".
>
> > And of course first week of january 2009, I learned that VMS engineering
> > was being disbanded.
>
> > Having said this, despite all the criticisms of the TCPIP Services
> > product, VMS had made great leaps forwards in gaining the functionality
> > of Unix. And now that I am learning Unix, I am also realising that the
> > TCPIP Services did have a few advantages and design improvements over
> > standard Unix stuff. Heck, the TCPIP> SHOW SERVICES display is
> > certaintly much better status of your system than LAUNCHDCTL LIST
>
> ...I have to agree that this is a good summary.
>
> What will happen?
>
> There are still paying customers who have a large investment in VMS with
> code which would be very difficult to port.  (And it is the PAYING
> customers who decide what will happen.)  I see four possibilities:
>
> 1) Oracle will buy VMS to keep Rdb customers.  Most Rdb customers, if
> forced to move off VMS, would probably move off Rdb as well.  This might
> not be as absurd as it might sound at first.  Remember Porsche wanted to
> buy Volkswagen, but what came out in the end is the Volkswagen bought
> Porsche.  Compaq paid $ 9 billion for DEC.  Say VMS is worth 1 or 2
> billion.  Shouldn't be a problem for Larry.
>
> 2) Big companies with a lot invested in VMS will get together and buy
> VMS so that they can call the shots, after realising that this would be
> cheaper than porting all their code, not to mention the decreased
> reliability, availability etc.
>
> 3) HP will decide to port VMS to REAL industry-standard hardware.  I
> think the technical reasons for not doing so are no longer valid.  After
> the ports to ALPHA and then Itanium, this should be relatively easy.
>
> 4) HP will abandon VMS, all customers will have to jump ship and in a
> few years HP will sell VMS for just a few million, realising that if it
> waits any longer it won't be able to sell it at all, or only for a token
> price.  Could VMS survive as some sort of open-source project?
> Probably, but it is not clear a) on what level and b) if this would be
> enough to keep big customers interested enough to fund support (which
> would make it possible for some folks to work on VMS full time who
> otherwise would have to earn their money otherwise).  Of course, HP is
> not obliged to open-source it, but they might.
>
> What would I like to happen, best first?  3 1 2 4.  What do I think will
> happen?  1 3 4 2.- Hide quoted text -
>
> - Show quoted text -

Phillip, you're an optimistic person...
I don't think option 2 is realistic at all, companies large enough to
afford the step are still trying tou outsource IT or trying to get it
back internally.
Anyway the're in a hate-love realtionship with IT. The cost involved
in option 3 will only be spent by HP if they can keep existing
customers on VMS.
That's basically a money driven decision and with HP being run as it
is, that just might happen.
Option 1 only makes sense if Oracle would want to offer database
engines, sitting on a LAN or the Internet as large black boxes. The
reasons behind the excercise
may be stability, availability, low maintenance and los susceptibility
for attacks from the internet. Will only work if Oracle wants to go to
war with Google I guess.
Option 4 is still at least 5 years in the future (provided HP keeps
current promises).
So my order is 3-1-2-4 (which makes me an optimist too ;-)
Hans



More information about the Info-vax mailing list