VMS vs. U*ix - any horror stories?

[Paul Jerrom]

Hi all,
Nice to have this contact with other like-minded VMS-ites.
I am looking after a site that has multiple environments - different OSs, hardware, programming environments etc. Now, unfortunately, the IT Manager has decided that he wants a unified environment - single or reduced number of OSs, reduced languages, uniform hardware etc. I know, I know, it's all my fault and I should have him better trained, and shouldn't have let him mingle with other IT Managers...
Now it looks like there will be a VMS vs. U*ix shoot-off, with the winner taking all. Or at least keeping a job for a while...
Now, I don't need any help with espousing the benefits of VMS, and I can dish as much FUD about U*ix as I receive about VMS [I've been using VMS 20 years, I was in Digital pre-sales for 5 years, and a VMS Ambassador for 3 yrs]. However, as I am continually winning the arguments wrt performance, availability, security, TCO etc, the battle is moving towards the "well, no one develops for VMS nowadays". And this is where I need some help...
I know about the Singapore Stock Exchange, but can anyone help me with examples of a) customers new to VMS or b) applications being ported to VMS or c) companies developing in-house VMS software or better still d) examples of companies who have moved from VMS elsewhere and then come back again. Especially any examples which have the pleasant side effect of knocking Linux, or which emanate from this side of the world.

Thanks guys,

Paul Jerrom (from sunny New Zealand)

[Martin P.J. Zinser]

Hello Paul,

one good source are the success stories at

http://h71000.www7.hp.com/success-stories.html

Then, do not look far, just posted here very recently, Jan described his really long running cluster here in the forum at

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=550510

Last but not least, the company I am working for is running the worlds largest derivatives exchange as well as a couple of other exchanges very successfully on OpenVMS clusters. As far as I am aware we do not intend to move our core systems away from VMS ;-), actually we did commission a new cluster last year to run the central counter party system for Stock trading in Germany.

Greetings, Martin

[Mike Naime]

Paul:

I am covered under one of the success stories that Martin provided the link for. I think that we would also be an Example "C" because we wrote the Application "In-house".

Our App was written to run on both the AIX and VMS hardware/OS. The thought process being that the company did not want to be stuck with only one hardware vendor. Our clients have a choice on what they want to purchase.

If we host the system in house. It goes on VMS. (this is the success story) If I have to host an AIX system, (A migration from a client site) it currently requires twice the disk space that I would give a VMS system for the AIX "Cluster" because it cannot truly access/share the same volume at the same time. I have heard that this issue is being fixed in future releases of AIX. (It may already be there, I don't know)

WHQ is working with the Nashua NH Performance Lab folks to port our App to Itanium. Reports from 1 year ago were that it booted on Itanium, and promply crashed after 15 minutes! :-)

I suppose that my "new install" clients would be examples of Customers new to VMS.

Mike Naime

[Willem Grooters]

You want a 'horror story':

Years ago, I happened to work at a company that was 'in transition' from VMS to Unix.
I don;t know why - but it's likely to be FUD spread by some company at management level. I don't remember their name - doesn't matter anyway, they don't exist anymore.

During that time, the advantages of VMS became clear. Outage-time ran up due to several reasons, but only on the newly installed Unix machines - where the VAXen silently did their job. Furthermore, they had not anticipated the huge cost of transferring their software to the new platform - altough they should use "standrad software" this had to be heavily modified to meet their (legal!) standards.
All that time, the one system-group I worked at (yes, the VMS one), had time left to do good things on the user side (using VT terminals...), where the Unix 'guru's' had to concentrate on their machines. Failure of some of these introduced massive panic - to get the spare system up-and-running, as soon as possible, to minimize production loss.
Well, this failed several times, causing really HUGE damages - so high, insurence became impossible...

Luckily, I left before the transition was completed. After some years I met some ex-collegues, that updated me on the status. It has never come right again. As stated: the company ceased...

You want a success story? Then read the "Celebration" threads: a cluster that is up and running for 7 years now - and has been COMPLETELY renewed within that time. In that, there is a link to the original posting (at www.openvms.org) as well.
NO Unix site can achive that!!!

[John Eerenberg]

Not really horror stories, but two reality stories. I'll appologize in advance for not providing too many details since my employeer may frown on that.

1) In 2003, moved several VMS and Oracle apps to Unix and Oracle. Under VMS, the app was poorly written and ran slowly. Straight forward to fix but not done since the port to unix was pending.
The port to unix included a rewrite; it is still pretty slow. Costs went up for hardware and labor to support the system. Not as flexible or easy/safe to make changes. Former VMS developers complain about the hoops they go through now on unix. I presume some level of productivity was lost. On the plus side, everyone has better job security (tongue in cheek).

2) In 2004, moved an app from VMS to AIX. Old hardware was a VAX 7800 with 6 CPUS and memory (twice for the redundant system in another city). New hardware is a 12 processor AIX box, unix, and suitable/adequate memory (twice for the redundant system). The port was to include new enhancements. The actual port did not include new functionality. Very costly in terms of both hardware and labor. Performance is better then the old VAX but some performance problems exist (which doesn't make sense when going from CI based MHz VAXen to GHz AIX with new IO subsystems). Hardware costs are estimated to be roughly 2-3x the VAX. System Admin support is a full three times the old VMS staff. Same 3X for developers and application support. This was planned for and understood up front but I never understood why . . . until now.

In both cases the unix staff and developers are very good and skilled people. This appears to be reality in our field of business.

[Jan van den Ende]

Paul,

hope this suits you

(it DID happen some 10 years ago, but I guess the main line would still be valid).

At a previous client (sorry, no name) the computer centre was running some IBM MVS, some BULL UNIX, and a 2-node (8800's) VAX-VMS cluster. During the nearby construction activities the main powerline was dug up (~08:00). It was more-or-less anticipated (previous experience), and an emergency cable was rolled out and in place in some 10 minutes. In the mean time 3 brands of "sys-admins", and the head of the computer centre had all found their way to the computer room.
The head told us "BULL holds the most important apps, when they are through with their inital power surges, they signal IBM to go ahead. VMS 'only' runs the architect's CAD software. Better tell those 40 odd people to find something else to do today that doesn't require the system." Meanwhile power was back on, the bootstrap sequence was already displaying, and by the time our BULL friends started their power-up activities, our console reported database recovery completed, so at about 8:30 every(-VMS-)body was back at work, and we left the computer room telling the head we were fine.
At ~ 16:00 the head came to us:
H: "Well, it may be getting late today, but you can go reboot"
We: "Reboot? Why?"
H: "Because the IBM's are up now, and the Bull guys thinks they won't be troubled if only you are rebooting"
W: "But WHY should we reboot now"
H: "Well, then the architects can work again tomorrow".
W: "But they have been working all day".
H: "How can, I know you crashed as well, and tou left the computerroom when power came back up?"

We were back up and recovered in less the 15 minutes, while the Unix guys took over SEVEN hours to get "back" to a consistent situation (yes, full restore!). And then they were lucky that the only mutations they missed were bach-input while the input was still available and cound be re-run. Normally at about 8:00 all kind of individual transaction mutations start going, so they were very lucky. Had the outage happened some later...

But then, of course, every U*ix promotor will be telling that nowadays they have very good disaster recovery etc.
Try and get a demo of a U*ix system with full applic activity and a simulated hard crash. And if they "of course" have no-break, then simulate a power-supply failure, or pull the cable form (a) disk(s).
Try the same on VMS, and observe the resilience and/or recovery difference.

I sure hope you succeed in winning your shoot-off!!

Jan

[Willem Grooters]

Try and get a demo of a U*ix system with full applic activity and a simulated hard crash. And if they "of course" have no-break, then simulate a power-supply failure, or pull the cable form (a) disk(s).
Try the same on VMS, and observe the resilience and/or recovery difference.


I've seen the demo.
On last year's ENSA@WORK in Amsterdam there has indeed been a demo with combined NAS and SAN storage, "fully redundant" to show the capacity of data-failover for Windows and Unix (that is: HP-Ux, Linux and Solaris) clusters. Access problems were manullay caused by pushing a (big red) button, so one side simply 'broke down'. The operator (= HP representative) said, on my question of automated fail-over, that that wasn't possible: it ALWAYS required operator intervention, it had to do with data replication and checks before control could be handled over to another machine. I must have looked surprised, he looked at me, noticed my (VMS) badge and said: "If you're running VMS, Sir, then I know _you_ won't have to worry, but here we cannot be so sure and need to check first".

[Andreas Fassl]

Paul,

I'm sending this forum thread to Sue Skonetski, she's the editor of the VMS Technical Journal, she has LOTS of success stories and she will help you in your task.

With kind regards

Andreas Fassl

Von "Skonetski, Susan"
Datum Montag, Dezember 29, 2003 4:39 pm
An "Skonetski, Susan"
Betreff OpenVMS: When Continuous Availability Really Matters
Dear Folks,

This is from 2001 but it is a good reference paper. Alan Muir, thanks
for forwarding.

I just stumbled on the white paper entitled "OpenVMS: When Continuous
Availability Really Matters" by accident (while Google searching for
information on OpenVMS support in Veritas) at the ITPapers.com website
(http://www.itpapers.com/abstract.aspx?&sortby=compd&scid=260&docid=4010
4). It was a great read!

Warm Regards,
Sue


Von "Skonetski, Susan"
Datum Dienstag, Dezember 2, 2003 5:28 pm
An "Skonetski, Susan"
Betreff Excellent OpenVMS Pearl - Vienna Firefighters plan a great future with OpenVMS - OK for external distribution
Dear Folks,

If you would like the nice word document of the attached please let me know.

OK for external use per Peter Ranisch.

Thank you very much Peter.

Warm Regards,
Sue


-----Original Message-----
From: peter r. ranisch - OpenVMS V8.0 on Itanium(R) is on the road [mailto:peter.ranisch@chello.at]
Sent: Tuesday, December 02, 2003 9:02 AM
To: Skonetski, Susan
Subject: Vienna Firefighters plan a great future with OpenVMS


Sue,

Attached is a short overview about the histroy and the future of OpenVMS usage at the Vienna firefighters. You can distribute this as an OpenVMS Pearl. Further information about it could be acchieved by contacting Peter Götzl at gop@rts.co.at

Peter

_____________________

Vienna firefighters use OpenVMS for their call and mission center
The mission planning system for Vienna's professional firefighters was put into service in 1988. The system was in charge of the active missions and did the alarming of 24 remote fire stations throughout Vienna. The Hardware consisted of 2 VAX-11/750 servers with 20 terminals (VT220 and VT240). The external sites were connected via terminal servers and serial lines to the headquarters. The operating system was VMS 3.7 (?), ORACLE was used as a database, and programming was done in C. Two PDP-11s running RSX-11M were used as preprocessors for data gathering on the status of the emergency vehicles. The PDP-11s also displayed the status of these vehicles on 6 monitors. In 1989 the VAX-11/750s were replaced by VAX 11/780s to improve performance. In 1993 the 11/780s were replaced by 2 MicroVAX 3800s. An additional MicroVAX 2000 was used for training and test purposes. VMS was upgraded to version 5.1. In 1998 the PDP-11 was replaced by Windows/NT boxes due to millennium end. In 2000 the MicroVAX 3800 and 2000 were replaced by 3 DS20s which included a RAID 320 controller to be able to do Hardware-based mirroring. OpenVMS 7.1 was used together with ORACLE 8.0 and the program source was ported to C++. The control stations are still terminal-based, but some of the terminals have been replaced with Windows-based PCs and terminal emulators. Since July 2002 the DS20 has been running under OpenVMS 7.3-2. Starting in 2003 a general redesign of the environment will be done: The application software will be completely rewritten in C++ and C#. The 3 DS20s servers will be connected via DCOM and .NET to 50 Windows clients. Redundancy will be application-driven; no clustering will be used. The operating system will be 7.3-2 and ORACLE 9.x. The servers will be connected via two independent LANs, one 100MB-based and the other Gigabit. Each external site will be connected via 3 different independent networks to the headquarters. All systems will be monitored via SNMP. A giant video wall with twelve projection screens will display all mission-relevant information. The project is planned to be completed by 2006.

Von "Skonetski, Susan"
Datum Mittwoch, März 24, 2004 3:24 pm
An "Skonetski, Susan"
Betreff OpenVMS Pearl - HP Awarded $784 Million Services Contract by Department of Veteran Affairs-(OpenVMS Clusters) Please distribute
Dear Distribution lists, this is a public Document. Many thanks to the
OpenVMS Ambassadors working on this account. In particular Mark Z.

Warm Regards,
Sue


-

HP Awarded $784 Million Services Contract by Department of Veteran
Affairs 3/24/2004 7:45:00 AM



PALO ALTO, Calif., Mar 24, 2004 (BUSINESS WIRE) -- HP (HPQ) (HPQ) today
announced that it has been awarded a ten year, $784 million contract by
the Department of Veterans Affairs (VA) for Engineering Support Services
and Maintenance of the VistA Health Information Systems. Under the VistA
Maintenance and Expertise Center (VMEC) contract, HP Services will
provide support and maintenance to the mission critical VistA systems,
helping the VA deliver vital health care data across the VA's 21
networks.

The Veterans Health Administration (VHA) operates 170 medical centers
throughout the United States, Puerto Rico, and the Philippines. More
than 4.5 million people received care in VA health care facilities in
2002 and more than 6.8 million people are enrolled in the VA healthcare
system. The unprecedented growth in medical system workload has
reinforced the VA's need for an adaptive environment that facilitates
the seamless flow and availability of critical data across its networks.


"HP is honored to have been selected by the VA to provide mission
critical support to the clinicians and IRM personnel dedicated to
serving our nation's veterans," said Tom Iannotti, senior vice president
and general manager, Consulting & Integration, HP Services. "The VA's
teamwork, combined with HP's Adaptive Enterprise strategy, has resulted
in VistA being recognized as one of the premier hospital information
systems in the world."

The VA's VistA solution is implemented at all VA medical centers. VistA
provides automation and record keeping for almost every clinical and
administrative office and function in the VA through the many custom
integrated software modules running from a single integrated database at
individual medical or regional computing centers. The VA continues to
demand more access, speed, manageability, scalability, and high
availability from the systems on which it implements VistA.

A strong record of collaboration

HP has been an infrastructure, consulting and services provider to the
VA since 1983 through its work on the Decentralized Hospital Computer
Program (DHCP) and Enhanced Decentralized Hospital Computer Program
(EDHCP) contracts. Over time, HP and the VA have collaborated closely to
continually evolve the VA's IT environment and have successfully
deployed HP's OpenVMS clusters on AlphaServer systems to build an
adaptive environment that has increased performance, utilizes 64-bit
architecture and has enhanced reliability and up-time. As part of this
latest agreement, HP takes responsibility for maintenance and support
for all hardware and software products that comprise the VistA solution.


"The HP team has worked closely with VA over the last 20 years as VA has
grown VistA from three core applications to a single integrated system
which services over 100 clinical and administrative functions," said a
VA representative. "We look forward to teaming with the HP architects,
engineers, and service teams as we continue to ensure VistA provides
world class automation for veterans healthcare needs."

HP has also worked with the VA in other areas related to the VistA
solution, using technology to improve patient care. This includes the
implementation of BCMA (Bar-Code Medication Administration), MAF (Mumps
Audio-Fax), automated patient information and interaction, and VistA
Imaging.

Information about VistA is available at www.va.gov/vista_monograph/.

About HP

HP is a technology solutions provider to consumers, businesses and
institutions globally. The company's offerings span IT infrastructure,
personal computing and access devices, global services and imaging and
printing. For the fiscal year ending on Oct. 31, 2003, HP revenue
totaled $73.1 billion. More information about HP is available at
www.hp.com.

The information contained herein is subject to change without notice.
The only warranties for HP products and services are set forth in the
express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional
warranty. HP shall not be liable for technical or editorial errors or
omissions contained herein.

SOURCE: HP

HP
Brad Bass, 240-744-8119
brad.bass@hp.com


Customize your Business Wire news & multimedia to match your needs. Get
breaking news from companies and organizations worldwide. Logon for FREE
today at www.BusinessWire.com.


Copyright (C) 2004 Business Wire. All rights reserved.


Mark

VA Team - Solutions Architect
OpenVMS Ambassador
Consulting & Integration
Federal Government Region
hp
(301) 918-5577 (office)
(240) 472-1385 (cell)
Mark.Zimmermann@hp.com


-----Original Message-----
From: Zimmermann, Mark
Sent: Tuesday, March 23, 2004 1:50 PM
To: Skonetski, Susan
Subject: RE: Mark do you still think the press release will go out this
week?


I haven't heard anymore about it. And my boss (Donna) is out today, so
I can't check. Is it important?

Mark

VA Team - Solutions Architect
OpenVMS Ambassador
Consulting & Integration
Federal Government Region
hp
(301) 918-5577 (office)
(240) 472-1385 (cell)
Mark.Zimmermann@hp.com


-----Original Message-----
From: Skonetski, Susan
Sent: Tuesday, March 23, 2004 12:15 PM
To: Zimmermann, Mark
Subject: Mark do you still think the press release will go out this
week?

[Brad McCusker]

Paul,

Have you contacted any of your former Ambassador collegues for the latest and greatest VMS stories?

If you aren't sure just whom that may be in NZ these days, send me mail back channel and I'll try to hook you up.

Brad McCusker
OpenVMS Engineering

[Antoniov.]

Paul,
my little success story ...

My biggest customer, in 1995 had one VAX 3300, one VAX 3100 and one VAX 2000, mixed V5.2 and V4.6.
After DEC presented alpha processor my customer asked me what had to do and how make. I made porting of my software from VAX to AXP in only three months and he migrated quickly to DS400. I had to made only minimal updated on source.
VMS has granted investiment of my little customers; it's very very important bacause it's easy grant big business such as banks, assurance or others but when entry level customers(now they use DS10) can evolve without problems, money is in money-box!
Don't forget, HP has a big focus on its customers: everytime I contatted HP I've always received an answer.

Regards
@Antoniov

[Cass Witkowski]

You can always show your boss John Wisniewski's recent security briefing

http://www.mindiq.com/resources/webcasts/JohnwEncompasswebcast031804.ppt

John will be missed!

[Paul Jerrom]

Martin: Thanks, I am familiar with the success stories, my company is one of them. Unfortunately it is hard to tell new VMS users from old ones in most of these (actually, it appears all have been using the OS for yonks.)
Mike, Willem, John&Jan: Great ammo, thanks.
Andreas: Thanks, I have been in touch with my friend Sue. Unfortunately most of the success stories, including the VA one, are for existing VMS customers who have been using the OS for years.
Brad: I have requested this info from my local Ambassador often. Seems little 'ol HPNZ has other focusses...
Antoniov: thanks for the story, but unfortunately you fit into the category of pre-existing VMS customer.
Cass: No, I hadn't seen that presentation before, thanks for the pointer. And yes, John will be sadly missed.

From what I can fathom, the attempt will be made to show that VMS resources are scarce and limited to old wrinklies like me, who attract a reasonable hourly rate, rather than the kids straight from school who will cut code/patch OS's for minimum wage...I will, of course, be fighting from the availability/security/scaleability/clustering/support/good-over-evil angle.

As I said, I can fight the fud, but just want some ammo to put out any last lingering hot spots that might flare up!!

Let me now if you hear of new VMS customers or other horror stories.

Thanks for your help, folks, I will let you know how the good fight goes (or ask you for job vacancies!!)

Keep the faith!!

[Willem Grooters]

Paul


From what I can fathom, the attempt will be made to show that VMS resources are scarce and limited to old wrinklies like me, who attract a reasonable hourly rate,...


Indeed a problem but do not despair: about two years ago, I have been involved in educating and training 10 YOUNG VMS system administrators. (VMS system administration is core business of our company).
Somewhat longer ago, when I set up a VMS system, a Windows-oriented collegue was sent to a VMS user course and he came back very enthousiastic. He is now a convinced VMS admin.

...

... rather than the kids straight from school who will cut code/patch OS's for minimum wage...


... but often it's forgotton what the cost will be in case there is something wrong.

IMHO, most of these "programmers" simply don't have a clue of real programming, let alone good programming practices. They just learned to do the trick.
Never heard of change control, version management, co-existence....All things YOU would care about.

Your task would be to coach these youngsters and learn them the real thing. That's an investment that will pay back. Regardless the OS.

[Jan van den Ende]

Paul,


... rather than the kids straight from school who will cut code/patch OS's for minimum wage...


I coundn't agree more with Willem.

I even have one other 'point of professionalism'.
From some of my other postings you can read that in my present environment (Amsterdam Police) there is also a big political pressure to "standardise (!) " to N*IX (btw, NIX & NIKS pronounce the same, and in Dutch means: Nothing) for backoffice & M$ for frontend. Pressure mostly at the overlaying countrywide coordination & application development.

EVERY new development, when reaching us for pilot runs EACH TIME AGAIN proves they have NOT got the slightest idea of scaling ean concurrency. YES, the app HAS been 'tested' for multi-user use. Usually meaning that several users CAN access the app simultaniously. And if each of them locks 'something vital' for about 5-10% of the time, it runs just fine with 5 users. And if that uses 5 % CPU, you extrapolate 100 users need 10 times the test-ssytems CPU power, and 'everything will run fine'. So after a disastrous pilot with 25 users I drastic redesign considering locking has to be done. And then all tests are done on a db with 1 - 10 K records. And for some reason nobody had imagined that this kind of work doesn't scale well.... which is found out after (a subset of) the production data, say 1 or 10 M records is loaded. Only then someone starts extrapolation to 100+ M records.
Well, it IS good for my own job security:
10 years ago I was hired for 6 months, with 3 more of option) "to help VMS keep alive in the final days while the apps get ported to Unix." The options were "a bit" extended, and now "we are in the final days of VMS, everything is re-develloped for Unix or Windooze". And the horizon has remained steady at "1 year, two at the most".

And if, for legal reasons, something new MUST me done, then chanches are that one of the older develloppers 'quickly' uses some old skill, and a new VMS app is born.

fwiw,


Jan

[Anton van Ruitenbeek]

Paul,

...

... rather than the kids straight from school who will cut code/patch OS's for minimum wage...


After DEFCON 9 was ended we mentioned this at some students who where here during there training period working at a client of mine. At that time we also needed to get rid of some old VAXes we had phased out. We add VMS (and latest patches) on it and these student went home with those machines. The most of these students had implemented these machines as common file server in there student appartments and where wild about the operating system.

So there is hope .......

I hope also in the long strugle against NIX.

Anton.

[Brad McCusker · Accepted solution]

Paul,


From what I can fathom, the attempt will be made to show that VMS resources are scarce and limited to old wrinklies like me, who attract a reasonable hourly rate, rather than the kids straight from school who will cut code/patch OS's for minimum wage...


We're really working hard to address this.

The UNIX Portability effort has as its primary goal to get OpenVMS to look and feel like *NIX from a _programmers_ perspective. A natural side benefit will be similar look and feel for the system managers and operators. In other words, we'll be making as much of the UNIX shell and utilities available on VMS as we can.

Our UNIX Portability effort is detailed here: http://h71000.www7.hp.com/portability/index.html

GNV includes a bash shell on VMS (currently mainatined ans supported by VMS engineers as part of the Open Source community): http://gnv.sourceforge.net/

At the fall bootcamp, I had a hands on session that allowed the users to use GNV and some of the recent enhancements to VMS to port some OpenSource applications. Some of the students were VMS newbies (UNIX pros), and they were all suprised at just how well the GNV tools worked on VMS. Yes, it is not perfect, yet, but, it was very manageable for them. It might be worth your while to fire up GNV and show them just how easily the UNIX types can work on VMS.

While our initial focus is on programmers, not managers, the further we advance with the programming interfaces, the easier it is to get the management tools running too.

Lastly, as engineering winds down the IA64 development, its getting very exciting for me to see the activity starting on VMS 8.next. Lots of work on UNIX Portability related features is getting underway.

I'll be more than happy to discuss this further offline with you (or anyone else).

Regards,

Brad McCusker
OpenVMS UNIX Portability Project Leader
OpenVMS Engineering



At the fall bootcamp I had a hands on session that attempted to show off

[Willem Grooters]

Hi Brad,

I'll be more than happy to discuss this further offline with you (or anyone else).


Count me one of the rest!

Willem

[John Eerenberg]

Paul,

Good to hear you are working hard to help the decision makers to understand what is at risk when short cuts are taken (i.e., lower cost).
I too have been using VMS for 20+ years and worked for Digital in pre-sales/consulting.
Sounds like you are the lone voice. My rhetorical question is "where is HP in all this?" I really don't want a response since I would have to respond and do a "$ Set Flame/On." ;-)

> "From what I can fathom, the attempt will be made to show that VMS resources are scarce and limited to old wrinklies like me, who attract a reasonable hourly rate, rather than the kids straight from school who will cut code/patch OS's for minimum wage...I will, of course"

IMHO you shouldn't back down from the wage cost argument since a lot of VMS people now have other OS experience but that doesn't mean a number of them would not go back to VMS.

Which is better? A) Training "kids straight from school" to become professionals. or B) Employing professionals to start with.

I think if management wants a system that is cheap and fast but not "mission critical" in orientation (i.e., clusters, security, blah, blah, . . .), then generic unix is fine and I would't argue the point very much. If management's goal is to have a fast and solid system, there is no cheap for any OS and they need to get a grip.

In this response I am dealing with reality. The reality is that taking an OS, any OS, from shrink-wrap to mission critical (or a level approaching), is costly; better to start with VMS in that case. If approaching a mission critical level of operation is not needed . . . you always have the stability, security, etc. points in your favor. :-)

John

[Martin P.J. Zinser]

Hello Paul,

unfortunatly I do not have this in a publishable form, but anyhow for your entertainment:

Recently our company was evaluated by one of the big consultancy firms to determine how to increase efficency. One of their results was that our department doing all the VMS stuff (plus some other work) gets x% more salary than average, but also provides x% more productivity per employee ;-)

Still I do concurr (and have tried to point this out several times to hp already) that getting VMS back into Edu is an important thing and should not be measured by immediate profit made by HW sales!

Greetings, Martin

[Ian Miller.]

The unix portability program is vital especailly if hp then use it to get more apps ported to VMS and shorten the time delay for VMS versions of oracle etc. However it is also important to show new people the 'VMS way' of doing this. VMS is properly designed from the start and this makes a huge different when programming and using VMS - the consistance of API's, the simplicity and consistancy of DCL, the insistance on backward compatability (does that VMS V1 program still run on the latest VMS), etc.

[Willem Grooters]

Paul

More ammo.

1. I don't know the exact URL, but others will: The DEFCON-9 story (2001) - where a (standard!)VMS machine was heavily under fire by hackers, but was NEVER breached (unless by social engineering - but that could happen with all systems).
2. An OpenVMS engineer told us of a VMS system, setup with CSWS and disguised as an ISS machine. It was advertised in DNS and accessed within 30 minutes, by quite a number of hackers - worldwide, trying to bring it down exploiting all then known ISS/Windows issues. It could be seen in the logs - attempt after attempt.
Of coourse, they failed...
Another process was able to track them down to their own machines (most used a chain of different, badly protected systems (mostly (!) educational), and an email was sent to each of them - on that final machine - thanking for proving the system was safe (and apologising it wasn't an Windows machine after all).
3. That same engineer told us of an environment, where VMS cluster was running Advanced Server, set up as backup Domain controller. When they had to move the (NT-based) primary controllers, they shut down the NT machines, moved them - and kept them switched off. It was when something had to be shown that the PDC's were switched on - some weeks (or was it months) later. NO-ONE noticed the difference - except the speed and reliability. (I don't remember if the NT boxes were switched down afterwards. probably: yes.)
4. Probably of little use, since it's not exactly "production": my own VMS machine is connected to the Internet, protected by a firewall allowing http(s), dns and smtp only. I have also seen break-in attempts - on all these ports, but all fail (up to now...).
The very same applies to quite a number of colleagues (both Alpha and VAX). Some have Linux servers also, also behind a firewall, but these ARE hacked once in a while. Their VMS servers however keep running. Unhacked.

[Willem Grooters]

YET another PLUS (but: VMS related)

I don't remember the exact details, but the story went like this:

A company archived certain data on (open reel) tape. They also kept the sources of the programs they used to store, maintain and read this data as well, for a LONG time: what is that data's value if you cannot access it...

Over the years, all hardware and software was upgraded, from VAX to Alpha, their existing VAX software (COBOL and FORTRAN, a little bit of MACRO) was partly VESTed, partly rebuild on Alpha in that transition.
The old software was phased out in favour of new developments - built in C and C++.

Then, there was a request to take a look at this old data. BIG problem: NO HARDWARE to read it. Luckily, Compaq still had, so their (open-reel) tape could be copied to disk. The old executables and commandprocedures were restored - and just ran. ALL data could be read and handled WITHOUT CONVERSION.

Another example - to show what could be an implication of version upgrade - if not VMS:

About 10 years ago, I did the technical maintenance of a system, based on a HP-product, running on a small HP9000-system under HP-UX 9, requiring a specific version of Oracle. The application could NOT be stopped during the day (normal, interactive priocessing) nor during the night (batch processing, finalizing the daily process and reporting, and preparing next day's proceses)
A transition to a much bigger system, required change to HP-UX 10. In itself alone, this caused system management to redo quite a number of scripts. But for the application, it required a next version of the HP software - and because of that, a new Oracle version.
Result:
- This next version of the package required changes in the software, so I had to check THE WHOLE APPLICATION and make changes - and test it all.
- I had to design and test the data transfer from one database to the other
- I had to do the transition in a as short as possible timeframe, and in one time
- There was NO RETURN POSSIBLE once the application was restarted in the new environment
- finally - I could just HOPE that ALL that was in pipeline of processing, could be finished properly. There was simply no way to foresee the FULL implications.

Preperation cost me 6 months. Transition was done on a Saturday, in a number of hours, a small number of carefully designed tests revealed no problems and then the application was started. That night and the following Sunday I monitored the system, on Monday and Wednesday I had to deal with the (foreseen) backlog of the old environment.

Would this have been a VMS system, I don't think that ANY of these would have been required. In a cluster, the application wouldn't have to be stopped at all....
Funny detail: HP technicians at the time _agreed_ :-)

[Jan van den Ende]

Another one:

Anybody remember the Y2K madness?

At that time our IT environment consisted of 2 computer rooms, 7 KM apart, equipped with

- a number of AS400 systems in remote site "DUAL-switched" with similar on the local site
- some remote-site TRU64 running a.o. a vital, not-to-small db, duplicated at the local site with redo-log technique
- both sites several NETWARE service, serving the local users, with some options to access data at the other site as well (and several dozen secundairy sites all having their own NETWARE sever and ability to access the central data)
- a VMS cluster, 2 nodes at calling the remote site and 1 node at the local site, where also the 'admins' of all those systems are located, in two adjacent rooms.

In hindsight the following happened:
The department responsible for the buildings decided they had to test the fire-alarm in the remote-site building for Y2K-readiness. Of course you include the supplier of the installation, and in advance you contact the fire brigade that there SHOULD come an alarm, but only for test.
Of course no need to contact the IT department...
What does a well-designed fire-alarm do, except warning the fire-brigade? Well, if the lights are still burning, it only helps the firemen, and when they cause a short-circuit the fuses will blow, and they are depending on their own light. But: if you have got machinery (powered 380V, several 100 A ) then you could fry your firemen, so a good fire alarm leaves on the 220V for the lights, but shuts down the 380V. And in a computer room they have no-break, but in case of fire you HAVE to switch of 380, so you switch it of INSIDE the no-break.
And it worked as designed: 7 DEC 1999, 9:10, I still remember the exact date and time.

EVERYTHING went out.
It soon showed that the local AS400, TRU64, and NETWARE still functioned, and also the network devices in the remote building were still responding. One phonecall later we knew that in the remote computer room "everything was silent, and all those little lights were out".
So we, VMS system management, declared the remote site "dead", we did an IPC quorum recalc, and within 3 minutes everything resumed.

Restoring power was estimated "easier" and "quicker" than failing over for AS400 & Tru64.
At 14:00 Tru64 was back up again, only to discover that the database integrity was lost. After a full restore they were alive again at 21:00, with data between 0:30 (backup time) and 9:10 lost / to be entered again.
AS400 was available again at 15:00.

-- and we, VMS management, complained about the 3 - 4 minutes stall.
We insisted that THIS kind of event showed we really should have a quorum site, because that would have prevented the quorum-loss.
Main argument: if it would have happened in non-office hours, we would probably also have lost remote access to the consoles, so we would have stalled for the drive-up time as well.

One would think this should be reason to try and move FROM *IX (AS400 was planned to go, and is already gone) TO vms, but policy remains unchainged: Standardise on M$ for frontend, and TRU64 (!!) as backend.

Maybe for your fight stories like this DO make a point.

jan

[Wim Van den Wyngaert]

Jan,

It all depends on the reason for the database corruption. The same can happen on VMS due to shadowing bugs.

We had the case (on VMS) that an operator halted the system during a mini copy (using bitmaps).

Result : both members of the shadow set didn't contain the same info (bug 7.3 for which there is now a patch). Because it is an interbuilding cluster using the SITE parameter, we noticed sybase corruption in 1 building only. The DBA team repaired it before we knew that and this caused a loss of data. Luckely, the application team could rebuild the tables (took a weekend).

[Jan van den Ende]

Paul,

how about some real BIG ammo?

Most of what I will write now is from memory, and explicitly UNdocumented for reasons I will point out.

If a new major IT system is to be set up, of course an estimated evaluation of the furure of it should be an important factor.

How many OSses do you think give a GUARANTEE for future maintenamce and development, and how strong IS that guarantee?

Well, there DOES exist an OS with 20 year HARD warrantee! You guess which.

In order to be eligible for the USA DoD contract (the famous "COE initiative") that guarantee had to be given. And that guarantee is backed by a contract that states:
(never seen in writing, but spoken by several non-USA then-Compaq employee's who would be very displeased should they be named, which would also break my promise never to name them)
- ALL code, old, new, existing, and future) is given in escrow.
- should the owner of OpenVMS fail to deliver,
.. the fine is rumoured to be "a manyfold of the (then) total stock value of Compaq)
.. AND all rights on OpenVMS (including commercial, and the right to pass it on) will fall to the DoD
.. ALL then current OpenVMS-related personnel will pass into the service of DoD.
- Should ownership of OpenVMS change (like Compaq => HP), then this contract is a key part of OpenVMS

NOW, does anyone think HP could junk VMS? They are absolutely bankrupt at the same moment!

WHY is this fantastic marketing argument never used?

Because (I am told) USA law forbids making commercial promises further than 5 years hence, (because no-one is supposed to have any real view so distant in the future).

So, on the one hand, a prohibition of showing plans more than 5 year in the future, on the other hand, a contract that is as solid as the USA DoD (and should THAT fail, well, I think a REAL lot of our world-view will need to be adapted!).

And why can I write this down now?

At the Munich ENSA@WORK there was a presentation ("OpenVMS delevers the adaptive enterprise now" by Dave Holt) that actually DID state this 20 YEAR warrantee ON SCREEN, IN WRITING!

I contacted the speaker (HP employee, but I think non-USA) about it, and told him NOW I could use it.
"oh well, ok with me, about time it got out".

The presentations from ENSA are not available yet, but when they are, I will post the URL.

What do you think, does this qualify as ammo?



Since you are in New-Zealand, and I am in Europe, and both of us have no relation with HP other than as customer, USA's commercial laws cannot prevent my writing this.




Jan