Oracle-RDB seminar notes

[Neil Rieck]

Oracle-RDB seminar notes:

Seminar:
http://www.oracle.com/technetwork/database/rdb/index-101986.html

Notes:
http://download.oracle.com/otndocs/products/rdb/zip/rdbtf_burl_130321.zip

In the presentation on OpenVMS Update, support for Poulson will not happen until update 800.

http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf


NSR

[se...@obanion.us]

>
> In the presentation on OpenVMS Update, support for Poulson will not happen until update 800.
>
>
>
> http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf
>

Except that Update 800 is out and there is no new hardware support.
Update 700 did have new hardware, but no new CPU/system type.


Sean

[MG]

On 21-mrt-2013 21:12, se...@obanion.us wrote:
> Except that Update 800 is out and there is no new hardware support.
> Update 700 did have new hardware, but no new CPU/system type.

You beat me to it, although I couldn't check for myself as I do
not run any actual Integrity or Alpha anymore, I was about to
remark that...

HP and its packs of lies known as roadmaps, eh? They should
call those things roadkills! It's the road to the next thing
HP is going to run over and kill.

- MG

[johnso...@gmail.com]

>> Except that Update 800 is out and there is no new hardware support.
>> Update 700 did have new hardware, but no new CPU/system type.
>
> You beat me to it, although I couldn't check for myself as I do
> not run any actual Integrity or Alpha anymore

I'm in the same spot in that I can't actually check anything. My interest
is more pained curiosity than anything.

The only evidence I saw that there was a release of "Update 800" was this
post that I had seen on openvms.org

http://www.openvms.org/stories.php?story=13/02/28/3581481

It is odd to hear from some avenues that it's out and from another avenue
that it's still coming and that it will have support for Poulson.

I had hoped that some information would emerge from the technical forum
in NH this week, but that doesn't seem to be happening. There is the chance
that information was shared, but it was wrapped up in an NDA.

Perhaps Keith Parris can offer some clarity as to the state of affairs.

EJ

[Jan-Erik Soderholm]

johnso...@gmail.com wrote 2013-03-22 02:34:
>
>>> Except that Update 800 is out and there is no new hardware support.
>>> Update 700 did have new hardware, but no new CPU/system type.
>>
>> You beat me to it, although I couldn't check for myself as I do not
>> run any actual Integrity or Alpha anymore
>
> I'm in the same spot in that I can't actually check anything. My
> interest is more pained curiosity than anything.
>
> The only evidence I saw that there was a release of "Update 800" was
> this post that I had seen on openvms.org

It has been available for download for some time.

>
> http://www.openvms.org/stories.php?story=13/02/28/3581481
>
> It is odd to hear from some avenues that it's out...

I have it and my ZIPEXE file is dated 19-dec-2012.

> and from another avenue that it's still coming...

From who/where? The referenced road-map was from mid-2012.

I have seen no new road-map that is dated *after* the release
of the 800 update. So I see no problem here.

> and that it will have support for Poulson.
>

The readme talkes abut i2 servers, no mention about i4.

Now, who has a i4 server in their server room just
waiting for a VMS dist to be loaded, hands up!

Jan-Erik.

[johnso...@gmail.com]

On Friday, March 22, 2013 4:47:37 AM UTC-4, Jan-Erik Soderholm wrote:

> Now, who has a i4 server in their server room just
> waiting for a VMS dist to be loaded, hands up!

You make a fair point that its highly unlikely anyone is waiting for this.

At this point, it might make more sense for HP to come clean and say that
Tukwila is the end of the line for VMS or indicate when to expect it.

EJ

[Jan-Erik Soderholm]

What on earth does it matter if it takes another year for
i4-server support from VMS to arrive !?

Again, sho has a i4 server sitting idle just waiting for VMS ??

Who would have bought a i4-server if VMS was available for
it 3 month ago. Now, those how might have, are usualy not
posting on c.o.v anyway, and they might very well already be
running (field-tests of) VMS on Poulson hardware, who knows?

Do something real with your current VMS environment instead... :-)

If one realy need some answers about VMS and Poulson, I
guess that HP is the one to ask.

Jan-Erik

[Neil Rieck]

On Friday, March 22, 2013 4:47:37 AM UTC-4, Jan-Erik Soderholm wrote:

I must confess that the OpenVMS roadmap shown yesterday in Burlington Mass was published after the one posted on the HP web site. The roadmap shown yesterday showed more Poulson stuff coming in 900 (which is not even mentioned on the currently published roadmap).

Back to the semimar...

NSR

[Jan-Erik Soderholm]

OK, right then. Let's wait until there is a current road-map.
Probably published after the Burlington event... :-)

I do not think I have seen anything else then "the next" update
on any roadmap, and at the point of publishing of the current
road-map, update 800 was "the next" update.

Anyway, this is a totaly non-issue. Anyway interested enough
has already asked HP directly, I guess.

Jan-Erik.

[Neil Rieck]

It may be just a point release, but there seems to be "a lot" of new tweaks and optimizations added to RDB-7.3

Back to the seminar...

NSR

[Jan-Erik Soderholm]

Was there anything said about the froozen version of 7.3
for Rdb due to the Oracle/HP war ? Note that 7.3 was the
"last version" in the Oracle tables since the Rdb team
had pushed it out "half-baked" to a single customer
right before the freeze.

Jan-Erik.

[Neil Rieck]

No mention of the war at all. They did indicate that they were previously testing with 7.3.0 and now were testing with 7.3.1 (you maybe could read something into this but that would be pure speculation).

It "sounded" like a few select customers might be playing with 7.3.1 but I wouldn't bet any money on it. However, they also said the first release to the public would be 7.3.2

p.s. I was very impressed with this morning's seminar about "compiling queries" which involved logically analyzing then optimizing query strings. I first saw things like this in so-called DEC language compilers after we migrated from VAX to Alpha but even the presenter (Ian Smith) mentioned that he was surprised this stuff hadn't been implemented in RDB before 7.3

[David Froble]

If HP keeps going on this same road, perhaps it will be HP that will be
roadkill ....

[David Froble]

Neil Rieck wrote:

> I must confess that the OpenVMS roadmap shown yesterday in Burlington Mass was published after the one posted on the HP web site. The roadmap shown yesterday showed more Poulson stuff coming in 900 (which is not even mentioned on the currently published roadmap).
>
> Back to the semimar...
>
> NSR

Isn't it interesting, JF stops crying "wolf", and is replaced by others
doing the same ....

[Richard B. Gilbert]

I have not studied the matter in any detail but I have the impression
that, while H-P was once a measurement and control technology company it
is now an ink and toner company company.

Does anyone have the figures to support the proposition that H-P is
now primarily am ink and toner company, rather than a producer of
measurement and control equipment?

[Jan-Erik Soderholm]

Well, the point is that what MG yells about is simply not the fact.

The roadmap he quotes was released *before* the 800 update and
it was in that regard correct.

If you look at the Aug-2012 (the latest published) road-map it
talkes about both the 800 update and Poulson support, but it
does *not* say that the Poulson support should come within the
800 update kit, they are both simply listed under "Future" :

http://h71000.www7.hp.com/openvms/pdf/openvms_roadmaps.pdf

There is *a lot* of things under "future" that never have been
in any UPDATE kit, new compilers versions and so on.

Yelling about lies is simply childish.

[Jan-Erik Soderholm]

The whole "measurement and control" division was sold of as Agilent
in 1999. You have to read up a little.

http://en.wikipedia.org/wiki/Agilent_Technologies



>
>

[johnso...@gmail.com]

On Friday, March 22, 2013 7:59:05 PM UTC-4, Jan-Erik Soderholm wrote:

> If you look at the Aug-2012 (the latest published) road-map it
> talkes about both the 800 update and Poulson support, but it
> does *not* say that the Poulson support should come within the
> 800 update kit, they are both simply listed under "Future" :

That's a fair point to make and its not one I had considered.

Looking forward to the next update to the roadmap and to whatever
appears in Update 900.

EJ

[MG]

On 23-mrt-2013 0:59, Jan-Erik Soderholm wrote:
> Well, the point is that what MG yells about is simply not the fact.

What isn't a fact? ("Yells"...?)

> The roadmap he quotes was released *before* the 800 update and
> it was in that regard correct.

A few inaccuracies here, straight off the bat: I didn't 'quote' it,
I merely commented on it and I certainly wasn't the first one. I
wasn't even specifically talking about any particular update.

At least then blame the OP who brought it up and the person who
first responded to it, if the /urge/ is somehow too great.

> If you look at the Aug-2012 (the latest published) road-map it
> talkes about both the 800 update and Poulson support, but it
> does *not* say that the Poulson support should come within the
> 800 update kit, they are both simply listed under "Future" :

Just like AdvFS and TruCluster for HP-UX at the time, right?

> There is *a lot* of things under "future" that never have been
> in any UPDATE kit, new compilers versions and so on.

Of course it's going to be "future", an 'image-aware' and
'marketing-savvy' cunning bunch like HP isn't going to
mention the graveyard in advance before a good milking...

> Yelling about lies is simply childish.

You mean you want me to stop mentioning those "roadmaps",
right? (Again, "yelling"... /seriously?/)

- MG

[David Froble]

Well, the issue that I'm looking at, is whether those people south of
the Himilayas can do anything serious. I have no idea how serious
testing VMS on new hardware, and making modifications if necessary, will
be. I'd think it should not be very serious.

Maybe a few successes will be some type of indicator. Abject failure
surely will be an indicator.

Going to tell a short story, and I have nothing to back it up.

The subject was off-shore development services. The claim was that a
rather responsible software company in the LA area did a study of the
people in India working as programmers. Their results were that less
than 5% were proficient in the work that they were attempting.

I'm not saying the story has any substance. I have nothing to
reference. Maybe it's just FUD. But what if it's true?

[Richard Maher]

On 3/23/2013 9:00 AM, MG wrote:

> You mean you want me to stop mentioning those "roadmaps",
> right? (Again, "yelling"... /seriously?/)
>
> - MG
>

I thought the IPsec debacle reduced the OpenVMS RoadMap to junk mail
long ago.

FairyTales and bed-time stories will not change what you have to wake up
to tomorrow.

Cheers Richard Maher

[Jan-Erik Soderholm]

Of course not. They are the best we have.
But saying that they contains lies is still childish.

They might contain (and have always contained) details that
might not materialize. That's normal for any roadmap.

Jan-Erik.

[Phillip Helbig---undress to reply]

In article <f3c5c413-66bc-438b...@googlegroups.com>, Neil

Rieck <n.r...@sympatico.ca> writes:

> It may be just a point release, but there seems to be "a lot" of new
tweaks and optimizations added to RDB-7.3

It has to be 7.3; it cannot be 8.0 otherwise Rdb would be developing new
software for HP systems, which Ellison said wouldn't happen. (This has
happened before in Rdb; 8.0 was renamed 7.2, IIRC, because no-one wanted
to go to a .0 release.)

[MG]

On 23-mrt-2013 13:15, Jan-Erik Soderholm wrote:
> Of course not. They are the best we have.

In the 'since sliced bread' or 'since there's any bread at
all, even stale bread' sense?

> But saying that they contains lies is still childish.

What if saying /that they contains/ lies just so happens to
hugely correspond with reality? Even if you may not want to
hear or see it, which I guess isn't childish at all.

> They might contain (and have always contained) details that
> might not materialize. That's normal for any roadmap.

Okay, I get it, I will use the more politically correct term
"details" from now on!

- MG

[Phillip Helbig---undress to reply]

In article <kii66f$ajd$1...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> writes:

> Was there anything said about the froozen version of 7.3
> for Rdb due to the Oracle/HP war ? Note that 7.3 was the
> "last version" in the Oracle tables since the Rdb team
> had pushed it out "half-baked" to a single customer
> right before the freeze.

Frozen version? Well, ANY version is frozen, right? I think the idea
is to bring new stuff with 7.3x since 8.0 (or even 7.4) would break
Ellison's directive.

[MG]

On 23-mrt-2013 14:29, Phillip Helbig---undress to reply wrote:
> Frozen version? Well, ANY version is frozen, right? I think the idea
> is to bring new stuff with 7.3x since 8.0 (or even 7.4) would break
> Ellison's directive.

How is that poor guy going to be able to afford another island
of his own if money has to be spent on VMS software development?

- MG

[Jan-Erik Soderholm]

That was what I ment with "froozen". 7.3 would have been the
last Rdb version according to the official Oracle documents.

But, as the manager for Rdb said at the Tech Update Days, there
could be *any* number of 7.3.n.n releases for more or less
any amount of time.

Anyway, I guess that 7.3 is on it's way "out of the doors" now.

(8.0 was "Rdb for NT", b.t.w).

Another thing...
When you register an Service Request (SR) using the Oracle web page,
and select "Oracle Rdb Server on HP OpenVMS" as the Product, you
get the following versions to select from :

7.3
7.3.2
7.3.2.2
7.3.2.1
7.3.1.1
7.3.1.0
7.3.0.3
7.3.0.2
7.3.0.1
7.2.5
7.2.5.4
7.2.5.3
7.2.5.2 <= current available version.
7.2.5.1
7.2.4
7.2.4.2
7.2.4.1
7.2.3.5
7.2.3.4
7.2.3.3
7.2.3
7.2.3.2
7.2.3.1
7.2
7.2.2

Whatever that says...

Jan-Erik.

[Richard B. Gilbert]

Sorry about that! I have very little contact with H-P these days. My
LaserJet 4000 has been running like a watch. Buying a replacement toner
catridge a couple of years ago is about my only contact in the last
ten-twelve years. The printer keeps right on working! So does the
computer itself!

[Neil Rieck]

On Friday, March 22, 2013 4:28:48 PM UTC-4, David Froble wrote:
>
> Isn't it interesting, JF stops crying "wolf", and is replaced by others
> doing the same ....

Not sure what you meant by this comment. I have always been a supporter of OpenVMS and whomever owned it at the time. Same for RDB. In the past, I have been critical of HP for not supporting OpenVMS enough, or Oracle for not wanting to support Itanium at all. The only thing I have ever been critical of is running OpenVMS on an emulator running on another OS (especially Windows), but I fear I will (some day) need to change my views on this if HP never ports OpenVMS to x86-64.

Just my 5-cents worth.

NSR

[MG]

On 23-mrt-2013 15:56, Neil Rieck wrote:
> In the past, I have been critical of HP for not supporting OpenVMS
> enough, or Oracle for not wanting to support Itanium at all.

That has changed since that time in the past..?

> The only thing I have ever been critical of is running OpenVMS on
> an emulator running on another OS (especially Windows), but I fear
> I will (some day) need to change my views on this if HP never ports
> OpenVMS to x86-64.

What is the point of commercially running VMS on an emulator though?
I was always under the impression that it was merely there to keep
certain (read: not easily/feasibly ported) software running.

All the main benefits, (historical?) selling points, of VMS are in
the hardware configurations providing reliability, high-availability,
balanced resources, security and so forth.

For instance, VMScluster is great, but it becomes utterly pointless
once you start virtualizing (i.e. through HPVM/IVM) or emulating one.

If VMS is going to survive, it's going to survive on a hardware
platform.

- MG

[David Froble]

I wasn't pointing at anyone in particular. Just the comments of alarm
because VMS isn't already running on a platform that as far as I know
isn't yet available.

[Paul Sture]

In article <kij10h$g10$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> wrote:

> Well, the issue that I'm looking at, is whether those people south of
> the Himilayas can do anything serious. I have no idea how serious
> testing VMS on new hardware, and making modifications if necessary, will
> be. I'd think it should not be very serious.
>
> Maybe a few successes will be some type of indicator. Abject failure
> surely will be an indicator.
>
> Going to tell a short story, and I have nothing to back it up.
>
> The subject was off-shore development services. The claim was that a
> rather responsible software company in the LA area did a study of the
> people in India working as programmers. Their results were that less
> than 5% were proficient in the work that they were attempting.
>
> I'm not saying the story has any substance. I have nothing to
> reference. Maybe it's just FUD. But what if it's true?

My personal experience with folks from developing countries is that the
good ones get promoted or headhunted. From my point of view that was
very frustrating, because more than once as soon as I had someone
suitable trained up they would be off doing something else.

In Africa for example, the locals on my team had good degrees from UK
universities but had to work for a state owned company for so many years
to pay back the costs or come up with the money themselves, but
meanwhile their pay was pretty lousy. These guys were a prime target
for the large international consultancies who could afford to pay off
their student loans and still give them a healthy pay rise.

Incidentally the head of IT there had been a Computer Science professor
in India. There's a theme here: he was another bright Indian who had
emigrated for better pay because he was good enough to do so.

--
Paul Sture

[Neil Rieck]

Just saw this post titled:

"Oracle's Q3 falls short, revenue misses mark; Hardware systems tank again"

http://www.zdnet.com/oracles-q3-falls-short-revenue-misses-mark-hardware-systems-tank-again-7000012910/

Now Oracle could:
1) reduce their costs by laying off staff (dumb)
2) sell the hardware division (could Ellison admit error?)
3) get back to developing software solutions for all operating systems
4) spend less time taking their partners to court

[David Froble]

Ok, I'm going to take a guess. Since HP sent VMS off to India, we'd
assume for lower costs, there ain't gonna be "better pay" to retain
anyone worth having ....

I'm going to guess that many of the DEC people had some loyalty to the
product, and perhaps to the company. Think there is any of this in India?

[Bill Gunshannon]

In article <fe08a6c7-b1e5-4250...@googlegroups.com>,

You missed #5.

Stop flushing money down the toilet supporting deadend platforms.
Oh wait, the courts are making them do that.

Just my 2-cents worth.


bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bob Koehler]

In article <514CD2C0...@comcast.net>, "Richard B. Gilbert" <rgilb...@comcast.net> writes:
>
> Does anyone have the figures to support the proposition that H-P is
> now primarily am ink and toner company, rather than a producer of
> measurement and control equipment?

How about $0? I suspect that's what HP gets from measurement and
control equipment since they spun that off into a separate company.

[Keith Parris]

On 3/23/2013 8:56 AM, Neil Rieck wrote:
> The only thing I have ever been critical of is running
> OpenVMS on an emulator running on another OS (especially
> Windows)

Check out AVTware's vtAlpha, which includes its own operating
system kernel and does not require Windows or any other host
OS. It can also run in a VMware, Xen, Hyper-V, or KVM virtual
machine. http://www.avtware.com/bare%20metal.html

[Keith Parris]

On 3/23/2013 9:10 AM, MG wrote:
> All the main benefits, (historical?) selling points, of VMS are in
> the hardware configurations providing reliability, high-availability,
> balanced resources, security and so forth.

VMS has become less dependent on proprietary hardware as time has
passed. In fact, VMS has increasingly made up for the shortcomings of
industry-standard hardware by using more-sophisticated software.
Examples: host-based Volume Shadowing to shadow between different
storage subsystems; host-based mini-merge using software to allow
industry-standard SAN storage subsystems rather than requiring
proprietary controller-based merge assists.

> For instance, VMScluster is great, but it becomes utterly pointless
> once you start virtualizing (i.e. through HPVM/IVM) or emulating one.

On the contrary, the addition of virtualization adds even more
capabilities to one's toolkit. At Boot Camp, we witnessed a
technology demonstration which moved a running VMS cluster node
from one HPVM host box to another without interruption; merely a pause
of a second or so, not anywhere long enough to cause a CLUEXIT.
Some customers are using HPVM to allow a single Integrity server
to provide Quorum Node service for multiple clusters at once. Many
others use an Alpha emulator on PC hardware for quorum nodes.

> If VMS is going to survive, it's going to survive on a hardware
> platform.

Intel is under contract to supply Itanium chips to HP until at least
2022, and HP has the option to renew. Even if HP didn't choose to renew,
it could always do a big final purchase, as it did for VAX and
again for Alpha.

So the Integrity hardware platform will be available for a very long
time yet. And even if HP continues in the direction of not porting
OpenVMS to x86, Integrity will likely not be the last hardware platform
on which you run your VMS applications. x86 may not even be the last,
either.

[Keith Parris]

On 3/21/2013 7:34 PM, johnso...@gmail.com wrote:

> Perhaps Keith Parris can offer some clarity as to the state of affairs.

As folks already figured out, in the August 2012 Roadmap both Update
800 and Poulson support were listed as separate bullet items, both
coming in the future. Update 800 has since shipped, and is not the
release intended to support Poulson.

[Phillip Helbig---undress to reply]

In article <kiqckf$m12$1...@usenet01.boi.hp.com>, Keith Parris

<keithparris...@yahoo.com> writes:

> VMS has become less dependent on proprietary hardware as time has
> passed. In fact, VMS has increasingly made up for the shortcomings of
> industry-standard hardware by using more-sophisticated software.
> Examples: host-based Volume Shadowing to shadow between different
> storage subsystems; host-based mini-merge using software to allow
> industry-standard SAN storage subsystems rather than requiring
> proprietary controller-based merge assists.

I can follow the second but what industry-standard equivalent is there
to HBVS? HBVS is not just RAID, because there is the availability
aspect as well.

> > For instance, VMScluster is great, but it becomes utterly pointless
> > once you start virtualizing (i.e. through HPVM/IVM) or emulating one.

Again, distributing the system across a large area has advantages.

[MG]

On 25-mrt-2013 21:22, Keith Parris wrote:
> Check out AVTware's vtAlpha, which includes its own operating
> system kernel

Linux you mean?

- MG

[MG]

On 25-mrt-2013 21:38, Keith Parris wrote:
> VMS has become less dependent on proprietary hardware as time has
> passed. In fact, VMS has increasingly made up for the shortcomings
> of industry-standard hardware by using more-sophisticated software.

You mean like Itanium...?

> On the contrary, the addition of virtualization adds even more
> capabilities to one's toolkit. At Boot Camp, we witnessed a
> technology demonstration which moved a running VMS cluster node
> from one HPVM host box to another without interruption; merely a
> pause of a second or so, not anywhere long enough to cause a
> CLUEXIT.

You just so happen to be directing this to someone who has used
HPVM/IVM. I certainly don't see the above example having to
rely on VMScluster. The HPVM/IVM online migration tools ought
to be enough, or am I overlooking something...?

I maintain that VMScluster is utterly pointless when one starts
to emulate one, but even more so when one virtualizes one.


> Some customers are using HPVM to allow a singleIntegrity server

> to provide Quorum Node service for multipleclusters at once.

So you need to buy an HP-UX system with at least the VSE-OE and
use HPVM/IVM to virtualize a small virtualized VMS guest node?
Sounds a bit excessive, if you ask me...

> Many others use an Alpha emulator on PC hardware for quorum
> nodes.

That would make a /bit/ more sense indeed...

> Intel is under contract to supply Itanium chips to HP until at
> least 2022, and HP has the option to renew. Even if HP didn't
> choose to renew, it could always do a big final purchase, as it
> did for VAX and again for Alpha.

Is 'final purchase' synonymous for undoing?

> So the Integrity hardware platform will be available for a very
> long time yet.

Unless it goes into the same direction as Tru64 UNIX years ago...

> And even if HP continues in the direction of notporting OpenVMS
> to x86

"Continues"? Does that mean that HP is actually porting to
x86/x86-64? That would probably be the best news for VMS its
survival and prolonged existence in a long while.

> Integrity will likely not be the last hardware platform on which
> you run your VMS applications. x86 may not even be the last,
> either.

This sounds a bit too good to be true.

- MG

[MG]

On 25-mrt-2013 22:21, Phillip Helbig---undress to reply wrote:
> Again, distributing the system across a large area has advantages.

...?

- MG

[MG]

On 25-mrt-2013 21:38, Keith Parris wrote:

> VMS has become less dependent on proprietary hardware as time has
> passed. In fact, VMS has increasingly made up for the shortcomings
> of industry-standard hardware by using more-sophisticated software.

You mean like Itanium...?

> On the contrary, the addition of virtualization adds even more
> capabilities to one's toolkit. At Boot Camp, we witnessed a
> technology demonstration which moved a running VMS cluster node
> from one HPVM host box to another without interruption; merely a
> pause of a second or so, not anywhere long enough to cause a
> CLUEXIT.

You just so happen to be directing this to someone who has used
HPVM/IVM. I certainly don't see the above example having to
rely on VMScluster. The HPVM/IVM online migration tools ought
to be enough, or am I overlooking something...?

I maintain that VMScluster is utterly pointless when one starts
to emulate one, but even more so when one virtualizes one.


> Some customers are using HPVM to allow a singleIntegrity server
> to provide Quorum Node service for multipleclusters at once.

So you need to buy an HP-UX system with at least the VSE-OE and
use HPVM/IVM to virtualize a small virtualized VMS guest node?
Sounds a bit excessive, if you ask me...

> Many others use an Alpha emulator on PC hardware for quorum
> nodes.

That would make a /bit/ more sense indeed...

> Intel is under contract to supply Itanium chips to HP until at
> least 2022, and HP has the option to renew. Even if HP didn't
> choose to renew, it could always do a big final purchase, as it
> did for VAX and again for Alpha.

Is 'final purchase' synonymous with undoing?

> So the Integrity hardware platform will be available for a very
> long time yet.

Unless it goes into the same direction as Tru64 UNIX years ago...


> And even if HP continues in the direction of notporting OpenVMS
> to x86

"Continues"? Does that mean that HP is actually porting to
x86/x86-64? That would probably be the best news for VMS its
survival and prolonged existence in a long while.

> Integrity will likely not be the last hardware platform on which
> you run your VMS applications. x86 may not even be the last,
> either.

[Stephen Hoffman]

On 2013-03-25 21:21:39 +0000, Phillip Helbig---undress to reply said:

> I can follow the second but what industry-standard equivalent is there
> to HBVS? HBVS is not just RAID, because there is the availability
> aspect as well.

...

> Again, distributing the system across a large area has advantages.

There are few direct equivalents. That there are few direct
equivalents does not imply there are no good alternatives, however.

As I have suggested to various folks seeking to learn VMS, it can be
best to forget what you know from other platforms when starting out,
and look around for what's available and how problems are solved on the
target platform. Don't (unnecessarily) get tied into porting over a
solution or a design from one platform to another. Put a different
way, HBVS, clustering and the DLM can be very useful for some
applications, though each can get in the way with other applications.
Reversing this suggestion, this is also why I've been repeatedly
suggesting folks learn other platforms and other solutions and other
approaches.

Oracle has among the closest to HBVS with their Automatic Storage
Management (AMS) <http://en.wikipedia.org/wiki/Oracle_ACFS> environment.

As for examples of alternative approaches, it's quite common for
applications requiring uptime to span Amazon data centers. Amazon S3
includes distributed data replication, as well.
<http://aws.amazon.com/s3/> Depending on what you're up to, an EBS
snapshot can be useful. <http://aws.amazon.com/ebs/> Snapshots are
similar to splitting out members of a shadowset, and snapshots and
clones and similar mechanisms are available with ZFS and various other
systems.

Common alternatives to HBVS include database-level replication.
<http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling>
<http://en.wikipedia.org/wiki/Multi-master_replication>
<http://the-paper-trail.org/blog/consensus-protocols-paxos/> It's
increasingly common to keep the data in memory and replicate across
servers, so the disks involved can be archival storage or a transaction
log or storage for overspill.

Different applications have different requirements for failover times,
uptimes, recovery times, redundancy, prices, etc., too. There's no
one-size-fits-all.

But sooner or later, all of these approaches will run into CAP
<http://en.wikipedia.org/wiki/CAP_theorem>, including OpenVMS.


--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

Seeking to reduce the severity of potential outages by distributing the
critical data, applications, communications links and staff across
different geographic regions. HBVS is one approach for replicating
data and applications across data centers. A classic example with
OpenVMS was the Credit Lyonnais fire
<http://www.drj.com/drworld/content/w4_126.htm>.

[MG]

On 26-mrt-2013 0:01, Stephen Hoffman wrote:
> On 2013-03-25 21:54:06 +0000, MG said:
>
>> On 25-mrt-2013 22:21, Phillip Helbig---undress to reply wrote:
>>> Again, distributing the system across a large area has advantages.
>>
>> ...?
>

> [...]

See the original context, then you may understand my reply.

- MG

[Stephen Hoffman]

Um, OK. I did. And I just re-read it. Again, I (still) don't know
what your "?" was intended to indicate. When improving disaster
tolerance, virtualization still involves the geographic
(re)distribution of the data, applications and related, as virtualized
servers still depend on physical hardware, and physical hardware is
subject to damage. Certainly shoveling images around is fairly easy
(given enough bandwidth), but having current and consistent data is a
requirement. In VMS terms, there's not a whole lot of difference
between a virtual server image and shoveling around disk images or
shadowset member volumes. There's clearly some other detail here that
I'm missing with your "?".

[David Froble]

Just a thought.

Not sure exactly when the first usable IA-64 system was introduced.
From that date until 2022 is how many years? I seem to recall that
when Alpha was being developed, the goal was a design for the next 25 years.

So, from that perspective, IA-64 seems to be approaching, by 2022, a 25
year life cycle.

When Alpha was being introduced, were we worrying about what would
replace it in another 25 years?

[David Froble]

I took a glance at their web site. Lots of claims, but, perhaps, not
much detail.

You could be right, perhaps they started with a Linux kernel to run on
the x86 hardware. But I didn't see that mentioned on the web site.

Didn't download and read any of the PDFs.

[glen herrmannsfeldt]

David Froble <da...@tsoft-inc.com> wrote:

(snip)

> Just a thought.

> Not sure exactly when the first usable IA-64 system was introduced.
> From that date until 2022 is how many years? I seem to recall that
> when Alpha was being developed, the goal was a design for the next 25 years.

> So, from that perspective, IA-64 seems to be approaching, by 2022, a 25
> year life cycle.

> When Alpha was being introduced, were we worrying about what would
> replace it in another 25 years?

From "VAX Architecture Reference Manual" in 1986:

"We expect VAX computers to remain the backbone of Digital's product
offerings for many years into the future."

From the beginning of the "Alpha AXP Architecture Reference Manual,
second edition":

"In the forward to the first edition of the VAX Architecture Reference
Manual, Sam Fuller stated "Computer design continues to be a dynamic
field; I expect we will see more rather than less change and
innovation in the decades ahead.""

and, in "The Preface from the First edition":

"We set a 15-25 year design horizon (longevity) and tried to avoid any
design elements that we thought would become limitations during
this time."

-- glen


-- glen

[John Wallace]

Perhaps if it was mentioned, it would make their claims of "bare
metal" emulation look rather foolish, at least in some people's eyes?

It was discussed in passing almost exactly a year ago (e.g. March 26)
on this very ng, in a 400+ post thread which was started on March 20
by JF with the title "VMS port to x86". Search for "bare metal" in
that thread and you'll find a bit more detail.

[Paul Sture]

In article <5150c850$0$6341$e4fe...@dreader35.news.xs4all.nl>,

MG <marc...@SPAMxs4all.nl> wrote:

> On 25-mrt-2013 21:38, Keith Parris wrote:
>
> > Some customers are using HPVM to allow a singleIntegrity server
> > to provide Quorum Node service for multipleclusters at once.
>
> So you need to buy an HP-UX system with at least the VSE-OE and
> use HPVM/IVM to virtualize a small virtualized VMS guest node?
> Sounds a bit excessive, if you ask me...
>
>
> > Many others use an Alpha emulator on PC hardware for quorum
> > nodes.
>
> That would make a /bit/ more sense indeed...

I can immediately see where emulators or VMs could be used to provide
quorum. Back in the 90s we were running two Alphas, one in each
building about a mile apart and when we asked DEC about a suitable
quorum system to go in a third building they said a humble VAX 2000
would be up to the job.

--
Paul Sture

[Paul Sture]

In article <5150c775$0$6340$e4fe...@dreader35.news.xs4all.nl>,

MG <marc...@SPAMxs4all.nl> wrote:

> I maintain that VMScluster is utterly pointless when one starts
> to emulate one, but even more so when one virtualizes one.

Could you expand on that please?

I don't see it as pointless if your aim is to migrate an existing
cluster to new hardware using emulation, and with the minimum of change,
i.e. risk.

Are you thinking of a cluster at one location or a distributed cluster
here? I can see the point of consolidation where a cluster started life
as a means of achieving more computing resources at a single location
than were available with a single machine at the time. Is this your
reasoning?

I think different considerations are in play for distributed clusters.
No doubt the increased bandwidth and network reliability we have now,
which wasn't around when those clusters were designed, is another
consideration.

--
Paul Sture

[Paul Sture]

In article <kioc2m$439$2...@dont-email.me>,

It rather looks that way :-(

I had a chat with an Indian project manager half a dozen years ago and
asked him about the working culture there. Among other things he told
me that for every vacancy they had 200 applicants so everyone was under
pressure to perform or be replaced.

Long working hours were expected as a matter of course, and while I am
no stranger to those I have often found that if I find myself banging my
head against a problem in an evening I am better off going home and
recharging my batteries (in fact very often the solution has occurred to
me within five minutes of leaving work, but I learned many years ago
that a fresh start next morning was the best approach here).

> I'm going to guess that many of the DEC people had some loyalty to the
> product, and perhaps to the company. Think there is any of this in India?

I get the impression that everyone has ambitions to be a manager rather
than an engineer so probably not.

--
Paul Sture

[Stephen Hoffman]

On 2013-03-26 14:04:20 +0000, Paul Sture said:

> In article <5150c775$0$6340$e4fe...@dreader35.news.xs4all.nl>,
> MG <marc...@SPAMxs4all.nl> wrote:
>
>> I maintain that VMScluster is utterly pointless when one starts
>> to emulate one, but even more so when one virtualizes one.

If the emulators or virtualization is all in the same box and barring
some limitations on resources within the emulator or virtual machine,
sure. Sometimes.

But even in those cases, a cluster can be handy as it allows rolling
upgrades; that's the closest that VMS has to a grid or compute farm.

I could see clusterng as being "pointless" where there's a non-critical
requirement; where the emulation allows for a cheaper solution than
keeping the hardware around and going, and particularly where the
applications are in end-of-life.

> Could you expand on that please?

I too am curious.

> I don't see it as pointless if your aim is to migrate an existing
> cluster to new hardware using emulation, and with the minimum of
> change, i.e. risk.

Yep. Moving from hardware to 1:1 emulation or 1:1 virtualization is
lower risk than server consolidation as you're not trying to
consolidate (potentially very different) OpenVMS environments together
on fewer OpenVMS emulations/guests. AFAIK there are license migration
programs, so costs are less of an issue here.

> Are you thinking of a cluster at one location or a distributed cluster
> here? I can see the point of consolidation where a cluster started
> life as a means of achieving more computing resources at a single
> location than were available with a single machine at the time. Is
> this your reasoning?
>
> I think different considerations are in play for distributed clusters.
> No doubt the increased bandwidth and network reliability we have now,
> which wasn't around when those clusters were designed, is another
> consideration.

Similar considerations hold for consolidating hosts into fewer boxes or
(in an earlier era) into a Galaxy configuration, too. Now upgrading
the host OS (whether that's Linux, Microsoft Windows, OS X or something
else) is still an issue for maintaining access, and that too can lead
into cluster configurations spanning boxes, and potentially spanning
data centers. If you need the availability for the application(s)
running in the emulator, which not all environments do.

[Keith Parris]

On 3/25/2013 3:57 PM, MG wrote:
> On 25-mrt-2013 21:38, Keith Parris wrote:
>> VMS has increasingly made up for the shortcomings
>> of industry-standard hardware by using more-sophisticated software.
>
> You mean like Itanium...?

Intel wanted Itanium to be the industry standard for 64-bit computing,
but that strategy failed when AMD introduced the x86-64 extensions and
Intel followed suit. So I don't consider Itanium to be an
industry-standard CPU.

>> Intel is under contract to supply Itanium chips to HP until at
>> least 2022, and HP has the option to renew. Even if HP didn't
>> choose to renew, it could always do a big final purchase, as it
>> did for VAX and again for Alpha.
>
> Is 'final purchase' synonymous with undoing?

A typical 'final purchase' is a large order of a component (in this
case, CPU chips), large enough to manufacture the expected number of
systems over a period of time, plus provide spares for the service
lifetime of the product.

So I don't see how 'final purchase' could be synonymous with 'undoing'
anything.

>> So the Integrity hardware platform will be available for a very
>> long time yet.
>
> Unless it goes into the same direction as Tru64 UNIX years ago...

Tru64 was not ported to Itanium (nor was its code -- other than AdvFS
--- released to open source) so its hardware platform ended with Alpha.

Tru64 does continue to run at customer sites today. Some run it on x86
hardware under Alpha emulators.

OpenVMS _was_ ported to Itanium, and thus has the benefit of extended
lifetime.

>> And even if HP continues in the direction of not porting OpenVMS

>> to x86
>
> "Continues"? Does that mean that HP is actually porting to
> x86/x86-64? That would probably be the best news for VMS its
> survival and prolonged existence in a long while.

HP has repeatedly stated it has no plans to port OpenVMS to x86.

Porting OpenVMS to x86 would not change the marketplace perception of
OpenVMS as being proprietary, costly, and falling behind. In a turn of
events I find somewhat ironic and even humorous, UNIX flavors like
Solaris, AIX, and HP-UX are being referred to using the words
"proprietary" and "legacy" and are seen as costly and old-fashioned
compared with Linux.

I believe that rather than a port of the existing OpenVMS code base to
x86, a new open source OpenVMS-compatible operating system with the same
capabilities as OpenVMS has the best chance of marketplace acceptance
and success, and thus continuing the OpenVMS heritage for the greatest
length of time.

>> Integrity will likely not be the last hardware platform on which
>> you run your VMS applications. x86 may not even be the last,
>> either.
>
> This sounds a bit too good to be true.

There are presently four vendors of Alpha emulators on which OpenVMS can
run. HP wrote an Itanium CPU emulator called 'ski' which it released to
open source under GPL v2. Whenever Itanium chips are no longer
available, and HP can no longer build systems, I'm convinced at least
one vendor is likely to sell a Itanium emulator on which you can run
OpenVMS.

[MG]

On 26-mrt-2013 15:52, Stephen Hoffman wrote:
> On 2013-03-26 14:04:20 +0000, Paul Sture said:
>
>> In article <5150c775$0$6340$e4fe...@dreader35.news.xs4all.nl>,
>> MG <marc...@SPAMxs4all.nl> wrote:
>>
>>> I maintain that VMScluster is utterly pointless when one starts
>>> to emulate one, but even more so when one virtualizes one.
>
> If the emulators or virtualization is all in the same box and barring
> some limitations on resources within the emulator or virtual machine,
> sure. Sometimes.

That's what I was talking about, a virtualized VMScluster. (If I had
meant anything else, I would've used plural forms or specified it.)

> But even in those cases, a cluster can be handy as it allows rolling
> upgrades; that's the closest that VMS has to a grid or compute farm.

But why would you want to do that in a virtualized setup? Why not
just one big virtualized guest instead a bunch of small ones? Or
are we afraid of 'virtual' power supplies failing...?

> I could see clusterng as being "pointless" where there's a non-
> critical requirement;

Even more so where it /is/. The high-availability aspect from
then on doesn't rely nor depend on VMS, its traditional safe-
guards and contrivances, from that point on.

> where the emulation allows for a cheaper solution than keeping the
> hardware around and going, and particularly where the applications
> are in end-of-life.

Yes, well, that's what I said: What will be the purpose of VMS
once you cut out all the traditional selling points? As an 'HA'
platform, to undercut it and place it in a virtual environment.

>> Could you expand on that please?
>
> I too am curious.

I hereby just did, once more.

> Yep. Moving from hardware to 1:1 emulation or 1:1 virtualization
> is lower risk than server consolidation as you're not trying to
> consolidate (potentially very different) OpenVMS environments
> together on fewer OpenVMS emulations/guests.

I was mostly talking about virtualization, emulation can have its
merits indeed.

If you'd reread my posts, you'd notice I'm specifically talking
about emulating and even more so about virtualizing a VMScluster.

> AFAIK there are license migration programs, so costs are less of
> an issue here.

You still need to pay for HP-UX B.11.31 VSE-OE. Also, even if it
was absolutely free of charge, what is the poin? (Like I wrote
above.)

Also, is VMS still even supported as a 'guest' under HPVM/IVM? I
could've sworn an HP-UX person told me a while back that in the
releases since December 2012 they cut out a number of platforms.

> Similar considerations hold for consolidating hosts into fewer
> boxes or (in an earlier era) into a Galaxy configuration, too.
> Now upgrading the host OS (whether that's Linux, Microsoft Windows,
> OS X or something else) is still an issue for maintaining access,
> and that too can lead into cluster configurations spanning boxes,
> and potentially spanning data centers. If you need the availability
> for the application(s) running in the emulator, which not all
> environments do.

What may a (cross-)'cluster' across Linux, Windows and OS X be,
or roughly resemble, if I may so kindly ask...?

- MG

[MG]

On 26-mrt-2013 18:54, Keith Parris wrote:
>> You mean like Itanium...?
>
> Intel wanted Itanium to be the industry standard for 64-bit computing,
> but that strategy failed when AMD introduced the x86-64 extensions and
> Intel followed suit. So I don't consider Itanium to be an
> industry-standard CPU.

In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
latest patches, each time one logs onto an I64 box...

$ SHOW LOGICAL SYS$ANNOUNCE
"SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

> A typical 'final purchase' is a large order of a component (in this
> case, CPU chips), large enough to manufacture the expected number of
> systems over a period of time, plus provide spares for the service
> lifetime of the product.

Okay, thank you for clarifying that. I don't always understand
the corporate lingo/jargon.

> So I don't see how 'final purchase' could be synonymous with
> 'undoing' anything.

You named two platforms that just so happen to be gone, that was
somehow the first association that came up for me...

> Tru64 was not ported to Itanium (nor was its code -- other than
> AdvFS --- released to open source) so its hardware platform ended
> with Alpha.

That's actually not true. But, okay, let's say HP had nothing to
do for it, because it was officially in the hands of Compaq at
the time...

> Tru64 does continue to run at customer sites today. Some run it
> onx86 hardware under Alpha emulators.

But isn't Tru64 UNIX itself entirely EOL now? So, why would any
business still prefer to run it? Also, the fact that still run
it doesn't make it less dead, it's merely a workaround for those
customers...

> OpenVMS _was_ ported to Itanium, and thus has the benefit of
> extended lifetime.

Or postponed execution, depending on which direction things may
go...

>>> And even if HP continues in the direction of not porting OpenVMS
>>> to x86
>>
>> "Continues"? Does that mean that HP is actually porting to
>> x86/x86-64? That would probably be the best news for VMS its
>> survival and prolonged existence in a long while.

Mea culpa, I think I over-read "not" in the above sentence (the
way the sentence was construed with "continues" must've caught me
off guard).

> HP has repeatedly stated it has no plans to port OpenVMS to x86.
>
> Porting OpenVMS to x86 would not change the marketplace perception
> of OpenVMS as being proprietary, costly, and falling behind.

That's the HP we know and love! It being costly and falling behind
is luckily not at all the fault of HP, fortunately not.

> In a turn of events I find somewhat ironic and even humorous,
> UNIX flavors like Solaris, AIX, and HP-UX are being referred to
> using the words "proprietary" and "legacy" and are seen as costly
> and old-fashioned compared with Linux.

How do you mean? (With regard to VMS.) Is this a sheer relief,
or supposed to alleviate the pain, once VMS ends up in the same
list as Tru64 UNIX some day possibly? Please do tell.

> I believe that rather than a port of the existing OpenVMS code
> base to x86, a new open source OpenVMS-compatible operating

> systemwith the same capabilities as OpenVMS has the best chance

> of marketplace acceptance and success, and thus continuing the
> OpenVMS heritage for the greatest length of time.

How can something continue being something that isn't it?
Such a hypothetical VMS-like operating system, something that
has been (quite unsuccessfully, so far) attempted with FreeVMS,
would still not actually be /VMS/. It would be a VMS knock-off,
reverse-engineered at best.

I also wonder, if it truly got off the ground, if HP wouldn't
be there with a couple of lawyers to pay real good attention...

> HP wrote an Itanium CPU emulator called 'ski' which it released
> to open source under GPL v2.

Emulator is a bit of a big word, isn't it? I remember it wasn't
more than an /instruction set simulator/, not a full-blown
emulator.

Also, why would anyone possibly want to emulate IA-64? Besides
VMS and HP-UX, there isn't Linux (anymore) or even NetBSD.

> Whenever Itanium chips are no longer available, and HP can no
> longer build systems, I'm convinced at least one vendor is
> likely to sell a Itanium emulator on which you can run
> OpenVMS.

Joy! Sounds like a wonderful future.

- MG

[MG]

On 26-mrt-2013 18:54, Keith Parris wrote:

>> You mean like Itanium...?
>
> Intel wanted Itanium to be the industry standard for 64-bit computing,
> but that strategy failed when AMD introduced the x86-64 extensions and
> Intel followed suit. So I don't consider Itanium to be an
> industry-standard CPU.

In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
latest patches, each time one logs onto an I64 box...

$ SHOW LOGICAL SYS$ANNOUNCE
"SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

> A typical 'final purchase' is a large order of a component (in this
> case, CPU chips), large enough to manufacture the expected number of
> systems over a period of time, plus provide spares for the service
> lifetime of the product.

Okay, thank you for clarifying that. I don't always understand
the corporate lingo/jargon.

> So I don't see how 'final purchase' could be synonymous with
> 'undoing' anything.

You named two platforms that just so happen to be gone, that was

somehow the first association (and correlating factor) that came
up for me...

> Tru64 was not ported to Itanium (nor was its code -- other than
> AdvFS --- released to open source) so its hardware platform ended
> with Alpha.

That's actually not true. But, okay, let's say HP had nothing to

do with it, because it was officially in the hands of Compaq at
the time...

> Tru64 does continue to run at customer sites today. Some run it

> onx86 hardware under Alpha emulators.

But isn't Tru64 UNIX itself (nearly) entirely EOL since several
years? So, why would any business still prefer to run it? Also,

the fact that still run it doesn't make it less dead, it's merely

a desparate workaround for those customers...

> OpenVMS _was_ ported to Itanium, and thus has the benefit of
> extended lifetime.

Or postponed execution, depending on which direction things may
go...

>>> And even if HP continues in the direction of not porting OpenVMS
>>> to x86
>>
>> "Continues"? Does that mean that HP is actually porting to
>> x86/x86-64? That would probably be the best news for VMS its
>> survival and prolonged existence in a long while.

Mea culpa, I think I over-read "not" in the above sentence (the
way the sentence was construed with "continues" must've caught me
off guard).

> HP has repeatedly stated it has no plans to port OpenVMS to x86.
>
> Porting OpenVMS to x86 would not change the marketplace perception
> of OpenVMS as being proprietary, costly, and falling behind.

That's the HP we know and love! It being costly and falling behind
is luckily not at all the fault of HP, fortunately not.

> In a turn of events I find somewhat ironic and even humorous,
> UNIX flavors like Solaris, AIX, and HP-UX are being referred to
> using the words "proprietary" and "legacy" and are seen as costly
> and old-fashioned compared with Linux.

How do you mean? (With regard to VMS.) Is this a sheer relief,
or supposed to alleviate the pain, once VMS ends up in the same
list as Tru64 UNIX some day possibly? Please do tell.

> I believe that rather than a port of the existing OpenVMS code
> base to x86, a new open source OpenVMS-compatible operating

> systemwith the same capabilities as OpenVMS has the best chance

> of marketplace acceptance and success, and thus continuing the
> OpenVMS heritage for the greatest length of time.

How can something continue being something that isn't it?
Such a hypothetical VMS-like operating system, something that
has been (quite unsuccessfully, so far) attempted with FreeVMS,
would still not actually be /VMS/. It would be a VMS knock-off,
reverse-engineered at best.

I also wonder, if it truly got off the ground, if HP wouldn't
be there with a couple of lawyers to pay real good attention...

> HP wrote an Itanium CPU emulator called 'ski' which it released
> to open source under GPL v2.

Emulator is a bit of a big word, isn't it? I remember it wasn't
more than an /instruction set simulator/, not a full-blown
emulator.

Also, why would anyone possibly want to emulate IA-64? Besides
VMS and HP-UX, there isn't Linux (anymore) or even NetBSD.

> Whenever Itanium chips are no longer available, and HP can no
> longer build systems, I'm convinced at least one vendor is
> likely to sell a Itanium emulator on which you can run
> OpenVMS.

[MG]

On 26-mrt-2013 18:54, Keith Parris wrote:

>> You mean like Itanium...?
>
> Intel wanted Itanium to be the industry standard for 64-bit computing,
> but that strategy failed when AMD introduced the x86-64 extensions and
> Intel followed suit. So I don't consider Itanium to be an
> industry-standard CPU.

In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
latest patches, each time one logs onto an I64 box...

$ SHOW LOGICAL SYS$ANNOUNCE
"SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

> A typical 'final purchase' is a large order of a component (in this
> case, CPU chips), large enough to manufacture the expected number of
> systems over a period of time, plus provide spares for the service
> lifetime of the product.

Okay, thank you for clarifying that. I don't always understand
the corporate lingo/jargon.

> So I don't see how 'final purchase' could be synonymous with
> 'undoing' anything.

You named two platforms that just so happen to be gone, that was
somehow the first association (and correlating factor) that came
up for me...

> Tru64 was not ported to Itanium (nor was its code -- other than
> AdvFS --- released to open source) so its hardware platform ended
> with Alpha.

That's actually not true. But, okay, let's say HP had nothing to
do with it, because it was officially in the hands of Compaq at
the time...

> Tru64 does continue to run at customer sites today. Some run it

> onx86 hardware under Alpha emulators.

But isn't Tru64 UNIX itself (nearly) entirely EOL since several
years? So, why would any business still prefer to run it? Also,

the fact that some customers still run it doesn't make it less
dead, it's merely a desperate workaround for those customers...

> OpenVMS _was_ ported to Itanium, and thus has the benefit of
> extended lifetime.

Or postponed execution, depending on which direction things may
go...

>>> And even if HP continues in the direction of not porting OpenVMS
>>> to x86
>>
>> "Continues"? Does that mean that HP is actually porting to
>> x86/x86-64? That would probably be the best news for VMS its
>> survival and prolonged existence in a long while.

Mea culpa, I think I over-read "not" in the above sentence (the
way the sentence was construed with "continues" must've caught me
off guard).

> HP has repeatedly stated it has no plans to port OpenVMS to x86.
>
> Porting OpenVMS to x86 would not change the marketplace perception
> of OpenVMS as being proprietary, costly, and falling behind.

That's the HP we know and love! It being costly and falling behind
is luckily not at all the fault of HP, fortunately not.

> In a turn of events I find somewhat ironic and even humorous,
> UNIX flavors like Solaris, AIX, and HP-UX are being referred to
> using the words "proprietary" and "legacy" and are seen as costly
> and old-fashioned compared with Linux.

How do you mean? (With regard to VMS.) Is this a sheer relief,
or supposed to alleviate the pain, once VMS ends up in the same
list as Tru64 UNIX some day possibly? Please do tell.

> I believe that rather than a port of the existing OpenVMS code
> base to x86, a new open source OpenVMS-compatible operating

> systemwith the same capabilities as OpenVMS has the best chance

> of marketplace acceptance and success, and thus continuing the
> OpenVMS heritage for the greatest length of time.

How can something continue being something that isn't it?
Such a hypothetical VMS-like operating system, something that
has been (quite unsuccessfully, so far) attempted with FreeVMS,
would still not actually be /VMS/. It would be a VMS knock-off,
reverse-engineered at best.

I also wonder, if it truly got off the ground, if HP wouldn't
be there with a couple of lawyers to pay real good attention...

> HP wrote an Itanium CPU emulator called 'ski' which it released
> to open source under GPL v2.

Emulator is a bit of a big word, isn't it? I remember it wasn't
more than an /instruction set simulator/, not a full-blown
emulator.

Also, why would anyone possibly want to emulate IA-64? Besides
VMS and HP-UX, there isn't Linux (anymore) or even NetBSD.

> Whenever Itanium chips are no longer available, and HP can no
> longer build systems, I'm convinced at least one vendor is
> likely to sell a Itanium emulator on which you can run
> OpenVMS.

[MG]

On 26-mrt-2013 18:54, Keith Parris wrote:

>> You mean like Itanium...?
>
> Intel wanted Itanium to be the industry standard for 64-bit computing,
> but that strategy failed when AMD introduced the x86-64 extensions and
> Intel followed suit. So I don't consider Itanium to be an
> industry-standard CPU.

In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
latest patches, each time one logs onto an I64 box...

$ SHOW LOGICAL SYS$ANNOUNCE
"SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

> A typical 'final purchase' is a large order of a component (in this
> case, CPU chips), large enough to manufacture the expected number of
> systems over a period of time, plus provide spares for the service
> lifetime of the product.

Okay, thank you for clarifying that. I don't always understand
the corporate lingo/jargon.

> So I don't see how 'final purchase' could be synonymous with
> 'undoing' anything.

You named two platforms that just so happen to be gone, that was
somehow the first association (and correlating factor) that came
up for me...

> Tru64 was not ported to Itanium (nor was its code -- other than
> AdvFS --- released to open source) so its hardware platform ended
> with Alpha.

That's actually not true. But, okay, let's say HP had nothing to
do with it, because it was officially in the hands of Compaq at
the time...

> Tru64 does continue to run at customer sites today. Some run it

> onx86 hardware under Alpha emulators.

But isn't Tru64 UNIX itself (nearly) entirely EOL since several
years? So, why would any business still prefer to run it? Also,
the fact that some customers still run it doesn't make it less
dead, it's merely a desperate workaround for those customers...

> OpenVMS _was_ ported to Itanium, and thus has the benefit of
> extended lifetime.

Or postponed execution, depending on which direction things may
go...

>>> And even if HP continues in the direction of not porting OpenVMS
>>> to x86
>>
>> "Continues"? Does that mean that HP is actually porting to
>> x86/x86-64? That would probably be the best news for VMS its
>> survival and prolonged existence in a long while.

Mea culpa, I think I over-read "not" in the above sentence (the
way the sentence was construed with "continues" must've caught me
off guard).

> HP has repeatedly stated it has no plans to port OpenVMS to x86.
>
> Porting OpenVMS to x86 would not change the marketplace perception
> of OpenVMS as being proprietary, costly, and falling behind.

That's the HP we know and love! It being costly and falling behind
is luckily not at all the fault of HP, fortunately not.

> In a turn of events I find somewhat ironic and even humorous,
> UNIX flavors like Solaris, AIX, and HP-UX are being referred to
> using the words "proprietary" and "legacy" and are seen as costly
> and old-fashioned compared with Linux.

How do you mean? (With regard to VMS.) Is this a sheer relief,
or supposed to alleviate the pain, once VMS ends up in the same
list as Tru64 UNIX some day possibly? Please do tell.

> I believe that rather than a port of the existing OpenVMS code
> base to x86, a new open source OpenVMS-compatible operating

> systemwith the same capabilities as OpenVMS has the best chance

> of marketplace acceptance and success, and thus continuing the
> OpenVMS heritage for the greatest length of time.

How can something continue being something that it isn't and
never started out as? Such a hypothetical VMS-like operating

system, something that has been (quite unsuccessfully, so far)
attempted with FreeVMS, would still not actually be /VMS/. It
would be a VMS knock-off, reverse-engineered at best.

I also wonder, if it truly got off the ground, if HP wouldn't
be there with a couple of lawyers to pay real good attention...

> HP wrote an Itanium CPU emulator called 'ski' which it released
> to open source under GPL v2.

Emulator is a bit of a big word, isn't it? I remember it wasn't
more than an /instruction set simulator/, not a full-blown
emulator.

Also, why would anyone possibly want to emulate IA-64? Besides
VMS and HP-UX, there isn't Linux (anymore) or even NetBSD.

> Whenever Itanium chips are no longer available, and HP can no
> longer build systems, I'm convinced at least one vendor is
> likely to sell a Itanium emulator on which you can run
> OpenVMS.

[Keith Parris]

On 3/26/2013 12:48 PM, MG wrote:
> Also, is VMS still even supported as a 'guest' under HPVM/IVM? I
> could've sworn an HP-UX person told me a while back that in the
> releases since December 2012 they cut out a number of platforms.

OpenVMS is still supported as a guest under HPVM. Right now, you'd want
to use the combination of HP-UX 11iv3 September 2011 + HPVM 4.3 + PK4 +
OpenVMS 8.4 + Update 800.

See Lars Sundqvist's session I328 "HPVM experiences and recommendations"
among the OpenVMS Boot Camp 2013 presentations at
https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

[MG]

On 26-mrt-2013 21:32, Keith Parris wrote:
> OpenVMS is still supported as a guest under HPVM. Right now, you'd
> want to use the combination of HP-UX 11iv3 September 2011 + HPVM 4.3
> + PK4 + OpenVMS 8.4 + Update 800.

What do you mean "right now", has it been removed or isn't it in
working state as of the latest release(s) of HP-UX and/or HPVM/
IVM?

Also, 2011 or 2012? The former is rather dated by now and as of
2012 it ought to still support VMS as a guest.

- MG

[Stephen Hoffman]

On 2013-03-26 18:48:36 +0000, MG said:

> On 26-mrt-2013 15:52, Stephen Hoffman wrote:
>> On 2013-03-26 14:04:20 +0000, Paul Sture said:
>>
>>> In article <5150c775$0$6340$e4fe...@dreader35.news.xs4all.nl>,
>>> MG <marc...@SPAMxs4all.nl> wrote:
>>>
>>>> I maintain that VMScluster is utterly pointless when one starts
>>>> to emulate one, but even more so when one virtualizes one.
>>
>> If the emulators or virtualization is all in the same box and barring
>> some limitations on resources within the emulator or virtual machine,
>> sure. Sometimes.
>
> That's what I was talking about, a virtualized VMScluster. (If I had
> meant anything else, I would've used plural forms or specified it.)

Nothing requires a virtualized cluster to exist within one box.

>> But even in those cases, a cluster can be handy as it allows rolling
>> upgrades; that's the closest that VMS has to a grid or compute farm.
>
> But why would you want to do that in a virtualized setup? Why not
> just one big virtualized guest instead a bunch of small ones? Or
> are we afraid of 'virtual' power supplies failing...?

Rolling VMS to new versions or new patches, which — when clustered —
allows VMS to remain available to clients and other servers.

>
>> I could see clusterng as being "pointless" where there's a non-
>> critical requirement;
>
> Even more so where it /is/. The high-availability aspect from
> then on doesn't rely nor depend on VMS, its traditional safe-
> guards and contrivances, from that point on.

Clustering is software-based, and doesn't particularly add to the
dependencies that the operating system has on the hardware, or the
emulation.

>> where the emulation allows for a cheaper solution than keeping the
>> hardware around and going, and particularly where the applications
>> are in end-of-life.
>
> Yes, well, that's what I said: What will be the purpose of VMS
> once you cut out all the traditional selling points? As an 'HA'
> platform, to undercut it and place it in a virtual environment.

If you posit that the hardware is flaky, then clustering can provide a
mechanism to survive failures.

But flaky hardware or flaky emulation is going to cause issues, as it
always has.

If you're booted and running on a ProLiant server, you get many of the
same sorts of HA features.

>>> Could you expand on that please?
>>
>> I too am curious.
>
> I hereby just did, once more.
>
>
>> Yep. Moving from hardware to 1:1 emulation or 1:1 virtualization
>> is lower risk than server consolidation as you're not trying to
>> consolidate (potentially very different) OpenVMS environments
>> together on fewer OpenVMS emulations/guests.
>
> I was mostly talking about virtualization, emulation can have its
> merits indeed.
>
> If you'd reread my posts, you'd notice I'm specifically talking
> about emulating and even more so about virtualizing a VMScluster.

Yes. Which lead me to wonder why. There are reasons folks can and do
want to cluster, whether virtualized, emulated or Galaxy'd.

>> AFAIK there are license migration programs, so costs are less of
>> an issue here.
>
> You still need to pay for HP-UX B.11.31 VSE-OE. Also, even if it
> was absolutely free of charge, what is the poin? (Like I wrote
> above.)

That's if you virtualize on Itanium. The emulation license transfer is
(was) handled differently.

> Also, is VMS still even supported as a 'guest' under HPVM/IVM? I
> could've sworn an HP-UX person told me a while back that in the
> releases since December 2012 they cut out a number of platforms.

That's a question for HP, but AFAIK yes.

>> Similar considerations hold for consolidating hosts into fewer
>> boxes or (in an earlier era) into a Galaxy configuration, too.
>> Now upgrading the host OS (whether that's Linux, Microsoft Windows,
>> OS X or something else) is still an issue for maintaining access,
>> and that too can lead into cluster configurations spanning boxes,
>> and potentially spanning data centers. If you need the availability
>> for the application(s) running in the emulator, which not all
>> environments do.
>
> What may a (cross-)'cluster' across Linux, Windows and OS X be,
> or roughly resemble, if I may so kindly ask...?

Emulators operate on those (and other) platforms, and OpenVMS booted on
the resulting environments can boot and can cluster.

Do I prefer emulation? No. Do I find it more complex? Yes. I'd much
prefer native-boot, or a lightweight ("get out of my way") virtual
machine. But there are various organizations using emulation and
virtualization in lieu of hardware. Including clustering.

[Keith Parris]

On 3/26/2013 1:19 PM, MG wrote:
> On 26-mrt-2013 18:54, Keith Parris wrote:
>> Intel wanted Itanium to be the industry standard for 64-bit computing,
>> but that strategy failed when AMD introduced the x86-64 extensions and
>> Intel followed suit. So I don't consider Itanium to be an
>> industry-standard CPU.
>
> In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
> latest patches, each time one logs onto an I64 box...
>
> $ SHOW LOGICAL SYS$ANNOUNCE
> "SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
> Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

As co-developer of the Itanium architecture with Intel, I think it's
fair to say HP shared the same hopes and dreams for Itanium as Intel
did. HP had no rights to the Itanium trademark and had to come up with a
name for OpenVMS not containing an Intel trademark. I think the name
chosen reflects the hope felt as of its incorporation into OpenVMS
Integrity version 8.0.

>> Tru64 was not ported to Itanium (nor was its code -- other than
>> AdvFS --- released to open source) so its hardware platform ended
>> with Alpha.
>
> That's actually not true.

You're quite right. Poor choice of words on my part, but they were not
intended to be insensitive. Let's instead say the port of Tru64 to
Itanium was never completed, although it was very close to completion.

> But isn't Tru64 UNIX itself (nearly) entirely EOL since several
> years?

According to
http://www.hp.com/softwarereleases/releases-media2/notices/HP_Tru64_UNIX_Alpha_Lifecycle_Chart.pdf
you can't buy Tru64 anymore, but you can still get support.

>> I believe that rather than a port of the existing OpenVMS code
>> base to x86, a new open source OpenVMS-compatible operating
>> systemwith the same capabilities as OpenVMS has the best chance
>> of marketplace acceptance and success, and thus continuing the
>> OpenVMS heritage for the greatest length of time.
>
> How can something continue being something that it isn't and
> never started out as? Such a hypothetical VMS-like operating
> system, something that has been (quite unsuccessfully, so far)
> attempted with FreeVMS, would still not actually be /VMS/. It
> would be a VMS knock-off, reverse-engineered at best.

As Linux can not actually be /UNIX/ ?? :-)

As I envision it, it might actually be better than OpenVMS.

>> HP wrote an Itanium CPU emulator called 'ski' which it released
>> to open source under GPL v2.
>
> Emulator is a bit of a big word, isn't it? I remember it wasn't
> more than an /instruction set simulator/, not a full-blown
> emulator.

It's true Ski does not include platform emulation code. I think perhaps
the quickest and easiest approach would probably be to emulate the
"platform" that HPVM provides, and use the paravirtualized drivers for
best performance.

> Also, why would anyone possibly want to emulate IA-64? Besides
> VMS and HP-UX, there isn't Linux (anymore) or even NetBSD.

To run OpenVMS (or HP-UX) on x86 hardware after Integrity hardware were
no longer available, or not supported.

We're talking long-term future here -- this would likely be a couple of
decades from now.

If HP doesn't exercise its option to renew the contract with Intel for
Itanium chips in 2022, and it chooses not to do a large final purchase,
but immediately stops selling Integrity servers, not even offering
refurbished systems for sale through HP Renew (both unlikely), and
supports the hardware for only its minimum policy of 5 years after last
sale (unlikely -- some VAX hardware is still supported 13 years later,
last sale being in 2000), and for the first time in history OpenVMS
support ends coincident with the end of hardware support instead of
continuing long afterward, then perhaps end of support could be as early
as 2027. But more realistic estimates of minimum support dates might be
more on the order of at least 2032, based on past history. See I314
"Possible Future Directions for the OpenVMS Ecosystem" in the collection
of OpenVMS Boot Camp 2013 sessions at
https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

[Keith Parris]

"Right now" means today, and today, to run OpenVMS guests under HPVM you
need to use specific versions. Nothing has been broken on purpose in
subsequent versions of HPVM or HP-UX, but qualification has not been
completed, so there's no official support yet for those subsequent
versions. Plans are to support HPVM version 6.something under the
then-current version of HP-UX with OpenVMS clients in the future. Read
Lars' presentation for more details.

[MG]

On 26-mrt-2013 22:27, Keith Parris wrote:
> As co-developer of the Itanium architecture with Intel, I think
> it's fair to say HP shared the same hopes and dreams for Itanium
> as Intel did. HP had no rights to the Itanium trademark and had

> to come up witha name for OpenVMS not containing an Intel
> trademark. I think the namechosen reflects the hope felt as of

> its incorporation into OpenVMS Integrity version 8.0.

Interesting, I didn't know that was one of the reasons why that
name/designation was chosen. I learned something new.

> According to
> http://www.hp.com/softwarereleases/releases-media2/notices/HP_Tru64_UNIX_Alpha_Lifecycle_Chart.pdf
> you can't buy Tru64 anymore, but you can still get support.

I see. Well, then I was mistaken, I thought the last form of
support ended in December 2012. That would've indeed been
rather early.

> As Linux can not actually be /UNIX/ ?? :-)

That, I guess, is a good point. Well, isn't that what "GNU"
asserts? Or, what that recursive acronym stands for.

(I was always under the impression, though, that of UNIX the
actual sources have always been 'floating around' and that
in several areas it required relatively little reverse-
engineering...)

> It's true Ski does not include platform emulation code. I think
> perhaps the quickest and easiest approach would probably be to

> emulate the "platform" that HPVM provides, and use the para-
> virtualized drivers for best performance.

Wouldn't that ultimately rely on IPF's brand of VT-x? Or do you
see a virtualization product in the future that can also do
emulation?

> To run OpenVMS (or HP-UX) on x86 hardware after Integrity hardware
> were no longer available, or not supported.

That would be useful, but wouldn't Alpha be more practical,
since that's 'there' already and much better understood than
IA-64?

> If HP doesn't exercise its option to renew the contract with
> Intel for Itanium chips in 2022, and it chooses not to do a
> large final purchase, but immediately stops selling Integrity
> servers, not even offering refurbished systems for sale through
> HP Renew (both unlikely), and supports the hardware for only its
> minimum policy of 5 years after last sale (unlikely -- some VAX
> hardware is still supported 13 years later, last sale being in
> 2000), and for the first time in history OpenVMS support ends
> coincident with the end of hardware support instead of continuing
> long afterward, then perhaps end of support could be as early as
> 2027. But more realistic estimates of minimum support dates might
> be more on the order of at least 2032, based on past history. See
> I314 "Possible Future Directions for the OpenVMS Ecosystem" in the
> collection of OpenVMS Boot Camp 2013 sessions at
> https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

You're a very patient man and I really appreciate your replies.
(2000 though, wasn't that still in the Compaq era...?)

I will read that document, also the one you referred me to
earlier. If you don't mind, I wouldn't mind looking in some
of the others there.

- MG

[MG]

On 26-mrt-2013 22:39, Keith Parris wrote:
> "Right now" means today, and today, to run OpenVMS guests under
> HPVM you need to use specific versions.

Strange, a while back I had set up HP-UX B.11.31 (Sept. 2012) with
its bundled HPVM/IVM (don't recall the version, though) and I set
up a hexa-node VMScluster. All seemed to work, I didn't encounter
any serious flaws... (Other than the strange HP-UX installation
procedure itself.)

> Nothing has been broken on purpose in subsequent versions of HPVM
> or HP-UX

I would certainly hope not... I was actually merely, surprised.

> but qualification has not been completed, so there's no official
> support yet for those subsequent versions.

I see.

> Plans are to support HPVM version 6.something under the then-
> current version of HP-UX with OpenVMS clients in the future.
> Read Lars' presentation for more details.

I will, thanks for pointing me again to that document.

- MG

[BillPedersen]

On Tuesday, March 26, 2013 7:37:10 PM UTC-4, MG wrote:
> On 26-mrt-2013 22:27, Keith Parris wrote:
>
>
> > It's true Ski does not include platform emulation code. I think
> > perhaps the quickest and easiest approach would probably be to
> > emulate the "platform" that HPVM provides, and use the para-
> > virtualized drivers for best performance.
>
> Wouldn't that ultimately rely on IPF's brand of VT-x? Or do you
> see a virtualization product in the future that can also do
> emulation?

Only if you planned to use a virtualization or emulation.

> > To run OpenVMS (or HP-UX) on x86 hardware after Integrity hardware
> > were no longer available, or not supported.
>
> That would be useful, but wouldn't Alpha be more practical,
> since that's 'there' already and much better understood than
> IA-64?

Why emulate?

That is not the direction Keith is proposing. And to be honest I believe this is an excellent potential for another alternative to the paths that might exist for OpenVMS customers. An open source OpenVMS. Not a port of the existing OpenVMS to "open source" but an implementation from nearly the ground up. Giving the opportunity to change the implementation where it might make sense.

This means, to a great degree, an implementation of the many, many APIs (defined in the BROADEST sense) which exist in OpenVMS. For those that are not aware there is a fair amount of "licensed" intellectual property within OpenVMS. This is not easily moved to open source. The "re-engineering" of OpenVMS in an Open Source style - a la GNU/Linux is really what we are talking about.

So, you would need CTRL, LIB$, SYS$, OTS$, SMG$, STR$, and all the rest of the interfaces. But it also gives us the opportunity to implement a file system or file systems which are 21st Century in style, rather than modifications of a file system from 1972. The implications are enormous!

And to some extent, just like the move from VAX to Alpha and the move from Alpha to IA64 this is more of a compiler project than a porting project. Once you have the compilers working this then moves forward fairly smoothly.

Oh, let us not try to trivialize it though! This would be a BIG effort. But, it might be an effort which energizes the OpenVMS Community to a similar extent that Linux energized that community.

So, would you be involved in such a project?

I know I would!

There are some hurdles here. It would be GREAT if we could get HP as a key sponsoring member of the parent foundation/non-profit behind this effort. No, this needs more than a few souls in the garage to make this happen. But we would of course engage ANYONE who wanted to contribute.

Keep the conversation alive!

Keith and I look forward to hearing your thoughts.

Bill.

[Craig A. Berry]

In article <fa0102b2-b14e-4265...@googlegroups.com>,

BillPedersen <pede...@ccsscorp.com> wrote:

> Why emulate?
>
> That is not the direction Keith is proposing. And to be honest I believe
> this is an excellent potential for another alternative to the paths that
> might exist for OpenVMS customers. An open source OpenVMS. Not a port of
> the existing OpenVMS to "open source" but an implementation from nearly the
> ground up. Giving the opportunity to change the implementation where it
> might make sense.

So basically try to round up enough volunteers to do what OpenVMS
Engineering in its heyday decided *not* to do during the port from VAX
to Alpha, i.e., rewrite it from scratch? I don't think so.

The Joel on Software blog has a famous entry on the folly of attempting
such things, using the case of Netscape/Mozilla as its prime example:

<http://www.joelonsoftware.com/articles/fog0000000069.html>

And that's when you have a sizable, dedicated, commercial engineering
team, not a collection of very part-time volunteers.

It's slightly more possible (though not probable) that if HP were to
release the *existing* source, including all the build dependencies,
that a consortium of companies and individuals could maintain it in
some fashion. It would be *very* complicated and require a lot of
lawyers.

The SSH port, for example, is a custom port by a third party that would
be unlikely to release HP from their obligation to keep it proprietary.
Of course we'd all be better off technically with a properly done port
of OpenSSH, but SSH is just one example of many and every piece that
would have to be replaced would take considerable resources and risk
various kinds of breakage and compatibility problems.

Open source projects work very well when they start small and steadily
accumulate a community, especially when that community involves
commercial enterprises that offer various flavors of support and added
value. I can't think of any that thrived when they started by the
proprietary owner abandoning the product and releasing it into the
wild.

[BillPedersen]

Well, that would be if what you expected to do is replace it over night. We are not even going to suggest that. But if you go off to this collection of the 2013 OpenVMS Boot Camp proceedings:

https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb

and check the documents with the titles "I314 Possible Future Directions for the OpenVMS Ecosystem" you can get an understanding of how we are looking at this.

It is not that this is something which needs to happen today. Yes, it needs to start happening. It might even be something that is sponsored by HP, as well as other vendors in the OpenVMS product space. This is really nothing more than an implementation of an OpenVMS centric Linux style open source environment.

Could it happen? Sure? But it would not be easy. Is it something reasonable to consider? Might it create sufficient buzz and energy in the Community that it raises the fortunes of OpenVMS?

I know and Keith knows that there are many obstacles. And also many doubters but then even Linus Torvalds did not think his contribution would amount to much when he offered it up to the Open Source Community.

Thanks for your thoughts.

[Phillip Helbig---undress to reply]

In article
<craigberry-6B474...@news.eternal-september.org>, "Craig A.

Berry" <craig...@mac.com.invalid> writes:

> An open source OpenVMS. Not a port of
> > the existing OpenVMS to "open source" but an implementation from nearly the
> > ground up. Giving the opportunity to change the implementation where it
> > might make sense.
>

> So basically try to round up enough volunteers to do what OpenVMS
> Engineering in its heyday decided *not* to do during the port from VAX
> to Alpha, i.e., rewrite it from scratch? I don't think so.

Agreed. Completely unrealistic. People massively underestimate the
amount of work which went into VMS. The fact that a Finnish student
could write a unix kernel on his summer holiday says more about the lack
of sophistication of a unix kernel than his abilities as a programmer.

> The Joel on Software blog has a famous entry on the folly of attempting
> such things, using the case of Netscape/Mozilla as its prime example:
>
> <http://www.joelonsoftware.com/articles/fog0000000069.html>
>
> And that's when you have a sizable, dedicated, commercial engineering
> team, not a collection of very part-time volunteers.

Right.

> It's slightly more possible (though not probable) that if HP were to
> release the *existing* source, including all the build dependencies,
> that a consortium of companies and individuals could maintain it in
> some fashion. It would be *very* complicated and require a lot of
> lawyers.

Even if there were no legal issues involved, I think even keeping the
existing code viable would be a huge effort.

[Simon Clubley]

On 2013-03-26, Craig A. Berry <craig...@mac.com.invalid> wrote:
>
> Open source projects work very well when they start small and steadily
> accumulate a community, especially when that community involves
> commercial enterprises that offer various flavors of support and added
> value. I can't think of any that thrived when they started by the
> proprietary owner abandoning the product and releasing it into the
> wild.

What about Blender ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[MG]

On 27-mrt-2013 7:38, Simon Clubley wrote:
> What about Blender ?

Blender started out as commercial software (which didn't do
very well), from here in the Netherlands. Eventually, it made
the move to open source, presumably when the animation studio
"NeoGeo" (no relation to that Japanese gaming platform, as far
as I'm aware anyway) and eventually "Not A Number" ("NaN" for
short), that grew out of it, went out of business.

So, Blender never had to reverse-engineer, or not nearly as
much as would be required for an open source VMS knock-off.
They could simply pick up where the commercial Blender stopped.

In the case of VMS: Whether I'm for or against this? Well,
there isn't exactly much choice, now is there? It's either
being at the mercy of HP and especially its higher echelons
(despite the very good and dedicated people, like Egolf,
Parris, Woertman, etc.).

- MG

[MG]

On 27-mrt-2013 11:18, MG wrote:
> Blender started out as commercial software (which didn't do
> very well), from here in the Netherlands. Eventually, it made
> the move to open source, presumably when the animation studio
> "NeoGeo" (no relation to that Japanese gaming platform, as far
> as I'm aware anyway) and eventually "Not A Number" ("NaN" for
> short), that grew out of it, went out of business.

Not presumably, I seem to have remembered it correctly. (You can
read more about it here, on the Blender Foundation web site:
<http://www.blender.org/blenderorg/blender-foundation/history/>)

- MG

[Bob Koehler]

In article <5151f4e3$0$26888$e4fe...@dreader37.news.xs4all.nl>, MG <marc...@SPAMxs4all.nl> writes:
>
> $ SHOW LOGICAL SYS$ANNOUNCE
> "SYS$ANNOUNCE" = " Welcome to HP OpenVMS Industry Standard 64
> Operating System, Version V8.4 " (LNM$SYSTEM_TABLE)

Well, on my systems SYS$ANNOUNCE contains the text I put in it.

But ever since DEC introduced the silent "Open" to VMS, we've
all become use to ignoring silly attributes like "Industry Standard".

HP can name it anything they want. We know it' just VMS ported to
Itanium, with features not shared by Alpha or VAX.

[Paul Sture]

In article <kisncc$ict$1...@usenet01.boi.hp.com>,

Keith Parris <keithparris...@yahoo.com> wrote:

> Porting OpenVMS to x86 would not change the marketplace perception of
> OpenVMS as being proprietary, costly, and falling behind. In a turn of
> events I find somewhat ironic and even humorous, UNIX flavors like
> Solaris, AIX, and HP-UX are being referred to using the words
> "proprietary" and "legacy" and are seen as costly and old-fashioned
> compared with Linux.

Definitely ironic after all the propaganda we had telling us that Unix
was open, even when it wasn't.

--
Paul Sture

[Robert A. Brooks]

On 3/27/2013 10:34 AM, Bob Koehler wrote:

> HP can name it anything they want. We know it' just VMS ported to
> Itanium, with features not shared by Alpha or VAX.

What software-specific features does VMS on IA64 have that
VMS on Alpha does not? It's literally the same codebase,
modulo some conditional compilation in a few places.
Note that I'm not talking about support for hardware that
is only on Itanium.

Yes, the "objects and images" stuff is IA64-specific,
as it must be, but I suspect that's not what you
were referencing.


--- Rob

[Paul Sture]

In article <5151f349$0$26888$e4fe...@dreader37.news.xs4all.nl>,

MG <marc...@SPAMxs4all.nl> wrote:

> In the meantime, SYS$ANNOUNCE still shows this as of V8.4 with the
> latest patches, each time one logs onto an I64 box...

MG, are you aware that you are posting the same messages multiple times?

Some of your posts in the last few days have been duplicates, and this
one came through 3 times.

--
Paul Sture

[Jan-Erik Soderholm]

Maybe not a specific VMS features, but the Cobol compiler V3 will
not be available on Alpha (V2.9), as far as I can understand from
the roadmaps (you know, that Book of Truth... ).

[John Wallace]

VMS *used to* have a certain amount of 3rd party or otherwise
encumbered software in it.

Is any of it relevant today? Here are a few random examples:

DisplayPostscript? Who cares?

CDE? Open/free since last year (LGPL).

MSCP? Who cares?

LAT? Who cares? Well actually some small and getting smaller number of
people might care, but...

So, where can one find a list of currently relevant software in VMS
which has licence issues that are not solely down to HP?

[Keith Parris]

On 3/26/2013 5:37 PM, MG wrote:
> On 26-mrt-2013 22:27, Keith Parris wrote:
>> It's true Ski does not include platform emulation code. I think
>> perhaps the quickest and easiest approach would probably be to
>> emulate the "platform" that HPVM provides, and use the para-
>> virtualized drivers for best performance.
>
> Wouldn't that ultimately rely on IPF's brand of VT-x? Or do you
> see a virtualization product in the future that can also do
> emulation?

Ski "cheated" by intercepting system calls and passing them up to the
host Linux (x86) operating system. So Ski didn't have to provide
emulation of the hardware platform or I/O devices like NICs and disk
controllers and such, since the host platform provided those.

If you started with the Ski Itanium CPU emulator code and wanted to
build a complete emulation product that would run OpenVMS, you'd need to
add enough code to emulate some specific platform that OpenVMS is
familiar with running on, including the I/O devices for network and disk
I/O. I was suggesting that instead of choosing to do a specific platform
model like an rx4640 or BL890c blade or whatever with all its I/O
devices, one might consider instead emulating the "platform" HPVM
presents to OpenVMS. HPVM provides a feature called Accelerated Virtual
I/O (AVIO) which is a paravirtualized interface which provides a
low-overhead way to do I/Os through to the host compared with emulating
all the instructions in the code path of, say, EWDRIVER for NICs or
DKDRIVER for SCSI disks. (NPIV is a another way of virtualizing device
I/O useful for SAN device access, and NPIV is being added to HPVM and
might be another good approach.)

This is an approach to provide an Itanium emulator on which to run
OpenVMS Integrity, unmodified.

For an open-source OpenVMS-compatible operating system, it might be
helpful to use Ski to provide Itanium instruction emulation allowing
OpenVMS Integrity (Itanium executable) images to run, unmodified, on top
of the OpenVMS-compatible operating system. OpenVMS system calls could
be intercepted and passed along to the underlying OpenVMS-compatible
operating system, much as Ski did on Linux during the Linux IA64 porting
effort using Ski before Itanium chips were available. To run VAX images,
one might use Simh VAX emulation code. To run Alpha images, one might
finish the Beta Simh Alpha emulation code
(http://simh.trailing-edge.com/sources/simhv39-0-beta.zip) or clean up
the open source ES40.org Alpha emulator code, or obtain cooperation and
assistance from one of the existing Alpha emulator vendors.

[Bill Gunshannon]

In article <nospam-F1556C....@news.chingola.ch>,

I don't remember anyone saying it was Open when it wasn't. In fact, I
can remember scrambling to find the UNiversity's AT&T license once just
to buy a CD.

Solaris was proprietary, while (I think) there is a proprietary version
today I expect most people are running one of the Open Source version.

AIX and HP-UX are definitely proprietary.

None of them are Legacy as there is constant develoment and improvement
being made. But I expect it is mostly Linux weenies spreading this kind
of FUD. Sadly, none of the Open Source *nix developers or advocates has
any interest in combating it.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Sprag]

On Wednesday, March 27, 2013 1:44:50 AM UTC-4, Phillip Helbig---undress to reply wrote:

> "Craig A. Berry" writes:
>
>
>
> > An open source OpenVMS. Not a port of
>
> > > the existing OpenVMS to "open source" but an implementation from nearly the
>
> > > ground up. Giving the opportunity to change the implementation where it
>
> > > might make sense.
>
> >
>
> > So basically try to round up enough volunteers to do what OpenVMS
>
> > Engineering in its heyday decided *not* to do during the port from VAX
>
> > to Alpha, i.e., rewrite it from scratch? I don't think so.
>
>
>
> Agreed. Completely unrealistic. People massively underestimate the
>
> amount of work which went into VMS. The fact that a Finnish student
>
> could write a unix kernel on his summer holiday says more about the lack
>
> of sophistication of a unix kernel than his abilities as a programmer.
>
>

There's some truth to that, but I think there's a much bigger reason why a FreeVMS system is destined to fail: the closed-source ecosystem. With Linux, and other Unix-like OSes, the source for most utilities were available one way or another -- "all" that was necessary was to cross-compile them for your new system. VMS doesn't have that. The few open source things that exist for VMS are all related to end user and not related to the core of the OS, so nearly everything needs to be written from scratch.

So even after the full OS is there, what are you going to run on it? None of the existing binaries will work so you're back to the open source ecosystem, which is a problem because even if there was full coverage of tools, the number of languages used by those programs means that a bunch of different compilers will be needed.

The unix ecosystem is primarily in C and pretty much all parts have the source available from one source or another so you can easily jumpstart a new Unix-Like OS.

So, as much as I like VMS and would like to see a freeware alternative, the effort required to reproduce the whole ecosystem is way beyond what pretty much anyone is willing to put into it.

[Johnny Billquist]

On 2013-03-27 17:32, Bill Gunshannon wrote:
> In article <nospam-F1556C....@news.chingola.ch>,
> Paul Sture <nos...@sture.ch> writes:
>> In article <kisncc$ict$1...@usenet01.boi.hp.com>,
>> Keith Parris <keithparris...@yahoo.com> wrote:
>>
>>> Porting OpenVMS to x86 would not change the marketplace perception of
>>> OpenVMS as being proprietary, costly, and falling behind. In a turn of
>>> events I find somewhat ironic and even humorous, UNIX flavors like
>>> Solaris, AIX, and HP-UX are being referred to using the words
>>> "proprietary" and "legacy" and are seen as costly and old-fashioned
>>> compared with Linux.
>>
>> Definitely ironic after all the propaganda we had telling us that Unix
>> was open, even when it wasn't.
>
> I don't remember anyone saying it was Open when it wasn't. In fact, I
> can remember scrambling to find the UNiversity's AT&T license once just
> to buy a CD.

What, you mean like the "Open Software Foundation"?
Or "Unix International"?
Or how about "Common Open Software Environment"?
And we should not forget X/Open, nor Posix.

:-)

Johnny

[Keith Parris]

On 3/27/2013 10:32 AM, Bill Gunshannon wrote:
> Solaris was proprietary, while (I think) there is a proprietary version
> today I expect most people are running one of the Open Source version.
>
> AIX and HP-UX are definitely proprietary.

Oracle seems to have effectively killed OpenSolaris. From
http://en.wikipedia.org/wiki/OpenSolaris
"After the acquisition of Sun Microsystems in 2010, Oracle decided to
discontinue open development of the core software, and replaced the
OpenSolaris distribution model with the proprietary Solaris Express."

[Paul Sture]

In article <kivh8l$akm$1...@usenet01.boi.hp.com>,

It is now known as OpenIndiana

http://openindiana.org/

I tried it a couple of years ago but that was in its early days under
the new organisation. The video performance on my kit was appalling so
I didn't pursue it.

--
Paul Sture

[MG]

On 27-mrt-2013 15:28, Paul Sture wrote:
> MG, are you aware that you are posting the same messages multiple
> times?
>
> Some of your posts in the last few days have been duplicates, and
> this one came through 3 times.

Yes, I'm aware. Sorry about that.

- MG

[MG]

On 27-mrt-2013 15:35, Robert A. Brooks wrote:
> Yes, the "objects and images" stuff is IA64-specific,
> as it must be, but I suspect that's not what you
> were referencing.

And in ELF format, strangely yet interestingly.

- MG

[Phillip Helbig---undress to reply]

In article <nospam-F1556C....@news.chingola.ch>, Paul Sture
<nos...@sture.ch> writes:

> Definitely ironic after all the propaganda we had telling us that Unix
> was open, even when it wasn't.

There are lies, damned lies, and open systems.

[Keith Parris]

On 3/27/2013 11:46 AM, Sprag wrote:
> I think there's a much bigger reason why a FreeVMS system is
> destined to fail: the closed-source ecosystem.

We were proposing an open source ecosystem to replace the existing,
closed-source ecosystem. Just like open source Gnu/Linux replaced the
proprietary AT&T UNIX.

> With Linux, and other Unix-like OSes, the source for most utilities
> were available one way or another -- "all" that was necessary was to
> cross-compile them for your new system. VMS doesn't have that.

...

> so nearly everything needs to be written from scratch.

If you were at a University with an AT&T license, you had access to
source code. Otherwise, you were out of luck, until the Gnu project
recreated all the UNIX pieces from scratch, minus the kernel which Linus
Torvalds kindly supplied with Linux. OpenBSD later recreated all the
code in open source form as well. No AT&T code could be included, due
to copyrights, so every line of code in UNIX had to be recreated from

scratch.

> So even after the full OS is there, what are you going to run on it?
> None of the existing binaries will work

If the new open source OpenVMS-compatible operating system provided the
same APIs, it seems technologically feasible to take an Itanium, Alpha,
or VAX image, execute the instructions under emulation, and anytime
the program calls a system service, pass that call into the underlying
native operating system.

> The UNIX ecosystem is primarily in C and pretty much all parts have the

> source available from one source or another so you can easily jumpstart
> a new Unix-Like OS.

Easy to say now, but where did all that readily-available source code
come from? Someone had to write it from scratch. The Gnu project was
started in 1984. Most of UNIX was duplicated by 1990, and then Linux
provided the missing piece -- the kernel -- in 1991. And Gnu had to
create the entire compiler collection as well during that time.

It will be many years before OpenVMS has no more Itanium hardware to
run on. I believe it can be recreated in time for customers to move
to it when it is needed. But we'd need to get started soon.

[Bill Gunshannon]

In article <kivh8l$akm$1...@usenet01.boi.hp.com>,

Take a look at: http://en.wikipedia.org/wiki/OpenIndiana

Doesn't do much good to lock the barn door after the horse has bolted.
All Oracle has really done is stop contributing.

[David Froble]

BillPedersen wrote:

> Well, that would be if what you expected to do is replace it over night. We are not even going to suggest that. But if you go off to this collection of the 2013 OpenVMS Boot Camp proceedings:
>
> https://www.dropbox.com/sh/77vbsdlg8w5ejt0/BCXgXHReTb
>
> and check the documents with the titles "I314 Possible Future Directions for the OpenVMS Ecosystem" you can get an understanding of how we are looking at this.
>
> It is not that this is something which needs to happen today. Yes, it needs to start happening. It might even be something that is sponsored by HP, as well as other vendors in the OpenVMS product space. This is really nothing more than an implementation of an OpenVMS centric Linux style open source environment.
>
> Could it happen? Sure? But it would not be easy. Is it something reasonable to consider? Might it create sufficient buzz and energy in the Community that it raises the fortunes of OpenVMS?
>
> I know and Keith knows that there are many obstacles. And also many doubters but then even Linus Torvalds did not think his contribution would amount to much when he offered it up to the Open Source Community.
>
> Thanks for your thoughts.
>

I see two possible problems.

1) Direction. Who or what holds all development on course? Who defines
the course? You'd first need to know just what is in VMS, then decide
on any changes, and future development. Remember, with VMS, backward
compatibility has been a big objective. Will such be maintained? Will
other strengths of VMS be retained? If not, why bother?

2) Why re-invent the wheel? There is much in VMS that perhaps is "as
good as it gets". Instead of spending valuable time re-doing things,
would it not be better to work on areas where improvement is needed?
Maybe a better implementation of TCP/IP? I read about things such as a
better file system. (I'm ok with the current one.) If things such as
SSH is a problem, then a new and better and more VMS type of SSH.

But as an example, is there anything wrong with things such as the DLM,
and other core parts of VMS?

A personal rant. If there is any language running on VMS that violates
some of the things that make VMS good, such as the common calling
standard, it's C. I'm guessing that some would want to re-write the
whole thing in C. Not interested.

[David Froble]

Phillip Helbig---undress to reply wrote:

> In article
> <craigberry-6B474...@news.eternal-september.org>, "Craig A.
> Berry" <craig...@mac.com.invalid> writes:
>
>> An open source OpenVMS. Not a port of
>>> the existing OpenVMS to "open source" but an implementation from nearly the
>>> ground up. Giving the opportunity to change the implementation where it
>>> might make sense.
>> So basically try to round up enough volunteers to do what OpenVMS
>> Engineering in its heyday decided *not* to do during the port from VAX
>> to Alpha, i.e., rewrite it from scratch? I don't think so.
>
> Agreed. Completely unrealistic. People massively underestimate the
> amount of work which went into VMS. The fact that a Finnish student
> could write a unix kernel on his summer holiday says more about the lack
> of sophistication of a unix kernel than his abilities as a programmer.

You mean 20 years of work by what arguably was the finest software team
this planet has ever seen? (I'm not counting the last 10 years.)

>> The Joel on Software blog has a famous entry on the folly of attempting
>> such things, using the case of Netscape/Mozilla as its prime example:
>>
>> <http://www.joelonsoftware.com/articles/fog0000000069.html>
>>
>> And that's when you have a sizable, dedicated, commercial engineering
>> team, not a collection of very part-time volunteers.
>
> Right.
>
>> It's slightly more possible (though not probable) that if HP were to
>> release the *existing* source, including all the build dependencies,
>> that a consortium of companies and individuals could maintain it in
>> some fashion. It would be *very* complicated and require a lot of
>> lawyers.
>
> Even if there were no legal issues involved, I think even keeping the
> existing code viable would be a huge effort.
>

Yeah, there would need to be something like a committee who oversaw and
approved things. Pieces would first need to be documented and submitted
to such a group for official approval. One of the things VMS is NOT
famous for is chaos.

[David Froble]

Keith Parris wrote:
> On 3/27/2013 11:46 AM, Sprag wrote:
>> I think there's a much bigger reason why a FreeVMS system is
> > destined to fail: the closed-source ecosystem.
>
> We were proposing an open source ecosystem to replace the existing,
> closed-source ecosystem. Just like open source Gnu/Linux replaced the
> proprietary AT&T UNIX.

Ok, I can see that.

>> With Linux, and other Unix-like OSes, the source for most utilities
> > were available one way or another -- "all" that was necessary was to
> > cross-compile them for your new system. VMS doesn't have that.
> ...
> > so nearly everything needs to be written from scratch.
>
> If you were at a University with an AT&T license, you had access to
> source code. Otherwise, you were out of luck, until the Gnu project
> recreated all the UNIX pieces from scratch, minus the kernel which Linus
> Torvalds kindly supplied with Linux. OpenBSD later recreated all the
> code in open source form as well. No AT&T code could be included, due
> to copyrights, so every line of code in UNIX had to be recreated from
> scratch.

Could you compare the complexity of Unix to VMS? Are we talking the
same size of job?

>> So even after the full OS is there, what are you going to run on it?
> > None of the existing binaries will work
>
> If the new open source OpenVMS-compatible operating system provided the
> same APIs, it seems technologically feasible to take an Itanium, Alpha,
> or VAX image, execute the instructions under emulation, and anytime
> the program calls a system service, pass that call into the underlying
> native operating system.

The compiler front ends should not need much. The GEM back end is
another story. It would need to be able to take the result of all the
compiler front ends and produce code that could be run on the selected
hardware platform(s).

If you get that far, then a lot of things become possible. But, that in
itself would be a big job, and then there is the question of any needed
changes to the VMS code, assuming you could get parts of the VMS code.

>> The UNIX ecosystem is primarily in C and pretty much all parts have the
>> source available from one source or another so you can easily jumpstart
> > a new Unix-Like OS.
>
> Easy to say now, but where did all that readily-available source code
> come from? Someone had to write it from scratch. The Gnu project was
> started in 1984. Most of UNIX was duplicated by 1990, and then Linux
> provided the missing piece -- the kernel -- in 1991. And Gnu had to
> create the entire compiler collection as well during that time.
>
> It will be many years before OpenVMS has no more Itanium hardware to
> run on. I believe it can be recreated in time for customers to move
> to it when it is needed. But we'd need to get started soon.

A start would be things such as the "Internals and Data Structures"
book(s), and such. Are they anywhere close to being up to date? Does
HP have documentation that defines VMS, and if so, would they part with it?

[BillPedersen]

So what if there were a non-profit "foundation" that was created which oversaw such a venture? I really do not think this can be done without some sort of "clearing house" function.

And do not think we would not want to make things so they worked effectively for existing binaries. Keith has proffered a concept on how that might be handled. But the concept of reverse compatibility is a bit misleading here Alpha did not specifically provide for compatibility with VAX, not even necessarily at the source level and IA64 did not do that with Alpha. NOW, they were VERY close! But not exact. So to have a FOURTH flavor of OpenVMS which might even offer the ability to run binary code from any of the other three might be very interesting even if the exact code could not be directly ported to that platform without minor changes.

Additionally what if there were significant sponsors to the project. Either in way of code or technology or money? Again, I believe this is key as well.

And even contributions by the everyday programmer and user...

Not simple. Not overnight.

Look, this is a concept. It is NOT a done deal in any way. But let us say that there is another 10 to 15 years in OpenVMS on IA64. This "fourth alternative" to other environments (IA64, Binary level emulators, porting to another environment are generally the other three alternatives) could have a significant following in that time.

There are rumors that several former OpenVMS engineers would jump at contributing. I do not know whom but there is interest there.

Keith and I look forward to the continued conversation.

[David Froble]

Well, that is, and isn't, VMS. A compiler is not part of an OS. But
one of the strengths of VMS was / is the support of many compilers and a
robust development environment.

The sad part is, I doubt continuing to provide the latest compilers on
Alpha would not be a big job. And even where appropriate, on VAX.

[Paul Sture]

In article <kj043e$b9p$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> wrote:

> A personal rant. If there is any language running on VMS that violates
> some of the things that make VMS good, such as the common calling
> standard, it's C. I'm guessing that some would want to re-write the
> whole thing in C. Not interested.

The fact that FreeVMS was apparently entirely in C was the thing that
put me off volunteering when I first heard of it. At the time I simply
didn't think I was competent enough in that language, nor did I enjoy
using it.

--
Paul Sture

[Paul Sture]

In article <kivmpi$hl$1...@online.de>,
hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply)
wrote:

:-)

--
Paul Sture