VMS vs. U*ix - any horror stories?

[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

[Keith Parris]

> 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 looked up the presentation. It has a bullet item that says:
o DII COE
20 year commitment

So the existence of the committment is certainly mentioned there. But I didn't see any further details.

[Paul Jerrom]

Hhmm...2 problems with DII COE.
1) if you look at the list of validated products at http://www.disa.mil/ges/coe_kpc/validated_products.html VMS isn't listed. And
2) Red Hat Linux IS listed (ironically so is Tru64).

While the official VMS website mentions the certification process, nothing states a 20 year committment. A bit like the Vax server in Europe which hasn't been rebotted since 1983, me thinks - everyone 'knows' about it, but noone has actually seen it...

[Jan van den Ende]

Keith,

like I stated in my previous posting:

Until this ENSA presentation ALL of it was ONLY in speaking, NEVER in writing. I also mentioned that any details were second- third- ?- hand (although mostly from not-mentional HP personnel).
The big thing in my view is that NOW the 20 years ARE in plain writing!
And any dumbhead can make his own educated guess about the required hardness of your commitments if you give DoD a guarantee...

Jan

[Jan van den Ende]

Paul,


A bit like the Vax server in Europe which hasn't been rebotted since 1983, me thinks - everyone 'knows' about it, but noone has actually seen it...


There is a book
"OpenVMS and Windows NT integration for dummies"
by Jim McAndrew, Clark Schwffy, & Terry Sherlock,
(former?) Compaq Part #: 11N3-0200A-WWEN.
with a lot of input from "VMS" (engeneering, ambassadors, documentation, etc)

For references it gives www.idgbooks.com
& www.dummies.com
This book is from januari 2000, and on page 178 it mentions "a European railway" (ie. which did not reboot its VMS system for 18 years. The system manager of it (sorry, don't know his name) did a presentation about it at 1999 San Diego Decus. I last met him at 2002 Lyon Decus, and at time time it was still running.

And though we are still __WAY__ short off that, our production cluster, with a quite dynamic application portfolio, has an uptime of over 7 years.

hth

[John Pendergrass]

I would question the use of logic. You wrote: the battle is moving towards the "well, no one develops for VMS nowadays".

This reeks of logical fallacies. Clearly "someone" develops for VMS nowadays. Is their argument that there are "less" developers? If so, what is the perceived affect? And so on.

If these folks were purchasing a car would they argue for a Taurus instead of a Lexus based on the number of mechanics available? Well, it depends.

Shape the argument.