READ and WRITE vs. SEARCH/OUTPUT

[Phillip Helbig---undress to reply]

Imagine a file x.x like

A
A
A
B
A
A
B
A
A
A
A
B

Would SEARCH x.x B /OUT=X.LIS be better than

$ OPEN/READ IN X.X
$ OPEN/WRITE OUT X.LIS
$LOOP:
$ READ/END=DONE IN REC
$ IF REC .EQS. "B" THEN WRITE OUT REC
$ GOTO LOOP
$DONE:
$ CLOSE IN
$ CLOSE OUT
$ EXIT

Some tests indicate that SEARCH is much faster. Can one depend on this
always being the case?

[Jan-Erik Soderholm]

I would expect a single image activation doing the same "job"
as a DCL script to always beeing faster.
I can't think of a case where the DCL would be faster.

The only reason I see to use DCL would be if the syntax of SEA
can't handle the selection.

Jan-Erik.

[Richard B. Gilbert]

Not until you have tested with all possible inputs! Even then, keep
Murphy's law in mind; "If anything CAN go wrong, IT WILL!"

SEARCH *should* be faster because SEARCH is an executable and "IF" is
interpreted but I will not guarantee it for all cases.

And if I've just done your homework for you, I'm sorry and I hope your
instructor knows it!

[VAXman-]

I suspect that SEARCH, a single image designed to specifically perform the
function which is described by its verb, is much more efficient than a DCL
procedure to do the same; especially, when you are searching MANY records.
There are "search" optimization in SEARCH that would not come into play in
DCL -- at least, not with the example code you provided.

>SEARCH *should* be faster because SEARCH is an executable and "IF" is
>interpreted but I will not guarantee it for all cases.

You will not guarantee that "IF" is interpreted in all cases? :)

>And if I've just done your homework for you, I'm sorry and I hope your
>instructor knows it!

He could put your name on his written assignment as mentor.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Arne Vajhøj]

On 1/21/2012 11:29 AM, Phillip Helbig---undress to reply wrote:

DCL is interpreted. SYS$SYSTEM:SEARCH.EXE is compiled code. It seems
reasonable to expect that there exist a value N for which SEARCH is
faster than DCL for files with >=N lines.

Arne

[Arne Vajhøj]

And N could be 1.

Depends on how the image activation overhead compares with
the speed of an iteration in DCL loop.

Arne

[Louis Krupp]

On Sat, 21 Jan 2012 12:05:08 -0500, "Richard B. Gilbert"
<rgilb...@comcast.net> wrote:

<snip>

>And if I've just done your homework for you, I'm sorry and I hope your
>instructor knows it!
>

But who would be teaching DCL these days?

Louis

[Hans Vlems]

On 23 jan, 09:38, Louis Krupp <lkr...@nospam.pssw.com.invalid> wrote:
> On Sat, 21 Jan 2012 12:05:08 -0500, "Richard B. Gilbert"
>

> <rgilber...@comcast.net> wrote:
>
> <snip>
>
> >And if I've just done your homework for you, I'm sorry and I hope your
> >instructor knows it!
>
> But who would be teaching DCL these days?
>
> Louis

Furthermore I doubt Phillip is in need of a DCL course ....

[Paul Sture]

On Sat, 21 Jan 2012 16:29:00 +0000, Phillip Helbig---undress to reply
wrote:

> Some tests indicate that SEARCH is much faster. Can one depend on this
> always being the case?

1. If you try the comparison on a VAX, you are probably looking at SEARCH
being many times faster than DCL.

2. Empirical testing I did back in VAX days suggested that given
sufficient memory SEARCH uses larger buffers than, say, a COBOL
executable.

--
Paul Sture

[Keith Cayemberg]

On Jan 23, 9:38 am, Louis Krupp <lkr...@nospam.pssw.com.invalid>
wrote:

> On Sat, 21 Jan 2012 12:05:08 -0500, "Richard B. Gilbert"
>

> <rgilber...@comcast.net> wrote:
>
> <snip>
>
> >And if I've just done your homework for you, I'm sorry and I hope your
> >instructor knows it!
>
> But who would be teaching DCL these days?
>
> Louis

Why not? I provided a complete Introduction to DCL class, equivalent
to that provided by HP, over a period of 3 weeks to 6 of my colleagues
in August last year.

Despite the availability of other script languages such as Perl, Rexx
or Bash on OpenVMS, I would still regard DCL to definitely be a
prerequisite to proficiency on the OpenVMS platform, whether you are a
developer, DBA or system manager.

Cheers!

Keith Cayemberg

[Richard B. Gilbert]

DCL is not terribly difficult for simple tasks. Programming in DCL can
get a bit esoteric but it's far from being impossible. By using English
verbs, e.g. HELP, COPY, PRINT, etc you can find your way around fairly
easily. Say HELP HELP and you will get a tutorial on using
the HELP command and you are on your way.

If English is not your native tongue, DCL has been translated to use
French, German, Italian, Spanish, etc, verbs. I think there is even a
kata kana version.

[VAXman-]

No Kobaian?

[Richard B. Gilbert]

I give up! WTF is "Kobaian"

[VAXman-]

What? Has Google gargled and spit? Has wiki gone sicki?

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

[Arne Vajhøj]

Wouldn't that depend on how the COBOL program was written?

Arne

[Arne Vajhøj]

On 1/23/2012 11:03 AM, Keith Cayemberg wrote:

> On Jan 23, 9:38 am, Louis Krupp<lkr...@nospam.pssw.com.invalid>
> wrote:
>> On Sat, 21 Jan 2012 12:05:08 -0500, "Richard B. Gilbert"
>>
>> <rgilber...@comcast.net> wrote:
>>
>> <snip>
>>
>>> And if I've just done your homework for you, I'm sorry and I hope your
>>> instructor knows it!
>>
>> But who would be teaching DCL these days?
>

> Why not? I provided a complete Introduction to DCL class, equivalent
> to that provided by HP, over a period of 3 weeks to 6 of my colleagues
> in August last year.
>
> Despite the availability of other script languages such as Perl, Rexx
> or Bash on OpenVMS, I would still regard DCL to definitely be a
> prerequisite to proficiency on the OpenVMS platform, whether you are a
> developer, DBA or system manager.

Sure.

But the number of universities having students working on VMS
is small (too small!) these days.

Arne

[VAXman-]

Well, I just perused the nearly 4000 lines of BLISS that is SEARCH. I
doubt there's enough disk space in the known universe to translate all
that logic into COBOL source! :)

[Arne Vajhøj]

On 1/23/2012 8:21 PM, VAXman- @SendSpamHere.ORG wrote:
> In article<4f1e047c$0$281$1472...@news.sunsite.dk>, =?UTF-8?B?QXJuZSBWYWpow7hq?=<ar...@vajhoej.dk> writes:
>> On 1/23/2012 6:58 AM, Paul Sture wrote:
>>> On Sat, 21 Jan 2012 16:29:00 +0000, Phillip Helbig---undress to reply
>>> wrote:
>>>> Some tests indicate that SEARCH is much faster. Can one depend on this
>>>> always being the case?
>>>
>>> 1. If you try the comparison on a VAX, you are probably looking at SEARCH
>>> being many times faster than DCL.
>>>
>>> 2. Empirical testing I did back in VAX days suggested that given
>>> sufficient memory SEARCH uses larger buffers than, say, a COBOL
>>> executable.
>>
>> Wouldn't that depend on how the COBOL program was written?
>
> Well, I just perused the nearly 4000 lines of BLISS that is SEARCH. I
> doubt there's enough disk space in the known universe to translate all
> that logic into COBOL source! :)

I am no Cobol expert, but that would surprise me.

Another joke?

Arne

[Richard B. Gilbert]

VMS is not widely used these days. Princeton University had VAXen in:
Plasma Physics Laboratory, Gas Dynamics Laboratory, Physics Department,
and the Chemistry Department. It doesn't help if the students can't use
it, or if they choose to use something else. The University as a whole
was IBM oriented. The Computing Center had an IBM 360/91, one of
eighteen or so that were made. It was what passed for a "super
computer" in those days.

DEC had problems in those days. It was bought by Compaq which gave
it a new lease on life but failed to solve the underlying problems.
Compaq was acquired in turn. DEC's problems remained unsolved.
I'm not sure that DEC's problems COULD have been solved at that point.
It would have taken several fortunes in cash and a thorough house
cleaning. It didn't happen.

I have a couple of Alphas and, ISTR, even a VAX. I seldom use them.

The applications I want/need are word processing, spread sheets and
Turbo-Tax. None of these run under VMS. Well, there was a Word Perfect
for VMS but who could afford a license? PC's did it faster and cheaper!

[Paul Sture]

Wiki _claimed_ to be sick last week...

... but was visible on mobile devices or if you had Javascript switched
off.

http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Learn_more

"During the blackout, Wikipedia is accessible on mobile devices and smart
phones. You can also view Wikipedia normally by disabling JavaScript in
your browser, as explained on this Technical FAQ page. Our purpose here
isn't to make it completely impossible for people to read Wikipedia, and
it's okay for you to circumvent the blackout. We just want to make sure
you see our message."

Not exactly a blackout, though it gave the press something to write
about, their normal source of "reliable info" being temporarily
unavailable. ;-)
--
Paul Sture

[Paul Sture]

In COBOL the buffer sizes are defined using the RESERVE clause, somewhere
up in the Data Division. I know of no way of altering that at run time
to suit available resources. Set it too high and you might run out of
nonpaged pool, too low and normal COBOL reads won't go as fast as SEARCH.

Given plenty of memory though, the performance gain could be quite
impressive whipping up a large RMS indexed file though. It gave me a
faster way to count records in an indexed file than for example CONVERT
or ANAL/RMS/STATISTICS.

--
Paul Sture

[Paul Sture]

On Tue, 24 Jan 2012 01:21:44 +0000, VAXman- wrote:

> In article <4f1e047c$0$281$1472...@news.sunsite.dk>,
> =?UTF-8?B?QXJuZSBWYWpow7hq?= <ar...@vajhoej.dk> writes:
>>On 1/23/2012 6:58 AM, Paul Sture wrote:
>>> On Sat, 21 Jan 2012 16:29:00 +0000, Phillip Helbig---undress to reply
>>> wrote:
>>>> Some tests indicate that SEARCH is much faster. Can one depend on
>>>> this always being the case?
>>>
>>> 1. If you try the comparison on a VAX, you are probably looking at
>>> SEARCH being many times faster than DCL.
>>>
>>> 2. Empirical testing I did back in VAX days suggested that given
>>> sufficient memory SEARCH uses larger buffers than, say, a COBOL
>>> executable.
>>
>>Wouldn't that depend on how the COBOL program was written?
>
> Well, I just perused the nearly 4000 lines of BLISS that is SEARCH. I
> doubt there's enough disk space in the known universe to translate all
> that logic into COBOL source! :)

That's why I used the phrase "empirical testing". I didn't have access to
the sources when I was first trying out quick ways of getting up a large
files, and I don't think I knew the trick of searching for a null string:

$ search bigfile.dat "" /stat /wind=0

I'm not sure whether those qualifiers existing in V3 days either.



--
Paul Sture

[Michael Kraemer]

Richard B. Gilbert schrieb:

> VMS is not widely used these days. Princeton University had VAXen in:
> Plasma Physics Laboratory, Gas Dynamics Laboratory, Physics Department,
> and the Chemistry Department. It doesn't help if the students can't use
> it, or if they choose to use something else. The University as a whole
> was IBM oriented. The Computing Center had an IBM 360/91, one of
> eighteen or so that were made. It was what passed for a "super
> computer" in those days.

This scenario wasn't/isn't unusual for academia (uni's and bigger labs).
For larger tasks one had big iron in the Computing Centre.
For data taking or process control one used PDP's or, later, VAXen.
So until the late 1980's there was little chance for a student
*not* to be exposed to one of those DEC products. From the end
of the 1980's onwards, however, Unix took over. DEC still had
a good chance to ride that wave too, e.g. by migrating their
large VMS base to Ultrix, while constantly improving the latter.
DEC chose to blow that opportunity.

>
> DEC had problems in those days. It was bought by Compaq which gave
> it a new lease on life but failed to solve the underlying problems.
> Compaq was acquired in turn. DEC's problems remained unsolved.
> I'm not sure that DEC's problems COULD have been solved at that point.
> It would have taken several fortunes in cash and a thorough house
> cleaning. It didn't happen.

DEC (and VMS) were like Kodak and analog photography are today.

> I have a couple of Alphas and, ISTR, even a VAX. I seldom use them.
>
> The applications I want/need are word processing, spread sheets and
> Turbo-Tax.

You have a turbo-income?

> None of these run under VMS.

DIY. As a retiree, you have all the time of the world.

[Bob Koehler]

In article <00ABBD52...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>
> No Kobaian?

I would think Klingon would be more usefull. (More people speak
Klingon now than ever spoke Esperanto.)

Hm, I'll have to find my Klingon dictionary and see if the QaH
library can easily be translated. As for DCL, already I'm having
trouble finding a translation of "verb".

[VAXman-]

In article <OX7ovJ...@eisner.encompasserve.org>, koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00ABBD52...@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
>>
>> No Kobaian?
>
> I would think Klingon would be more usefull. (More people speak
> Klingon now than ever spoke Esperanto.)

Klingon is to dweebs what couldn't get laid with a $1000 bill in a
whorehouse full of nymphomaniac prostitutes is to a Star Trek fan.

[AEF]

On Jan 23, 7:51 pm, VAXman- @SendSpamHere.ORG wrote:

> In article <WLKdnfpm59_oa4DSnZ2dnUVZ_rSdn...@giganews.com>, "Richard B. Gilbert" <rgilber...@comcast.net> writes:
>
>
>
>
>
>
>
>
>
> >On 1/23/2012 12:24 PM, VAXman- @SendSpamHere.ORG wrote:

> >> In article<9rWdnbqXbJSdEoDSnZ2dnUVZ_q2dn...@giganews.com>, "Richard B. Gilbert"<rgilber...@comcast.net>  writes:

Hmmmm. Must be true if it's on Wikipedia! (~_^)

AEF

[AEF]

On Jan 23, 7:51 pm, VAXman- @SendSpamHere.ORG wrote:

> In article <WLKdnfpm59_oa4DSnZ2dnUVZ_rSdn...@giganews.com>, "Richard B. Gilbert" <rgilber...@comcast.net> writes:
>
>
>
>
>
>
>
>
>
> >On 1/23/2012 12:24 PM, VAXman- @SendSpamHere.ORG wrote:

> >> In article<9rWdnbqXbJSdEoDSnZ2dnUVZ_q2dn...@giganews.com>, "Richard B. Gilbert"<rgilber...@comcast.net>  writes:

You mean you don't know either?

AEF

[AEF]

On Jan 24, 12:07 pm, VAXman- @SendSpamHere.ORG wrote:
> In article <OX7ovJP+e...@eisner.encompasserve.org>, koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:

>
> >In article <00ABBD52.7AD4B...@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>
> >> No Kobaian?
>
> >   I would think Klingon would be more usefull.  (More people speak
> >   Klingon now than ever spoke Esperanto.)
>
> Klingon is to dweebs what couldn't get laid with a $1000 bill in a
> whorehouse full of nymphomaniac prostitutes is to a Star Trek fan.
>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
>
> Well I speak to machines with the voice of humanity.

Can you please rephrase that in a grammatically correct sentence with
correct spelling? I tried, but I just can't make sense of it. Let me
try Google. Nope, didn't match any documents. Hmmm. Maybe it really
doesn't make sense.

It's late.

AEF

[VAXman-]

In article <512b514a-fb41-4c59...@hs8g2000vbb.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:
>>{...snip...}

>> http://en.wikipedia.org/wiki/Kobaian
>
>Hmmmm. Must be true if it's on Wikipedia! (~_^)

True? You doubt the veracity of the Wiki link? I've seen Magma perform
live several times. While I don't speak a lick of Kobaian, I can attest
to you that they do.

[VAXman-]

In article <dbbedc0f-e72d-4cde...@b18g2000vbz.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:
>{...snip...}
>>

>> Well I speak to machines with the voice of humanity.
>

>Can you please rephrase that in a grammatically correct sentence with
>correct spelling? I tried, but I just can't make sense of it. Let me
>try Google. Nope, didn't match any documents. Hmmm. Maybe it really
>doesn't make sense.

Funny (as in peculiar, not ha ha) thing. I put that line into Google
and the first hit was its source. Do you have Googletitis Inputicus?


>It's late.

It must be.

[Phillip Helbig---undress to reply]

In article <OX7ovJ...@eisner.encompasserve.org>,

koe...@eisner.nospam.encompasserve.org (Bob Koehler) writes:

> > No Kobaian?
>
> I would think Klingon would be more usefull. (More people speak
> Klingon now than ever spoke Esperanto.)
>
> Hm, I'll have to find my Klingon dictionary and see if the QaH
> library can easily be translated. As for DCL, already I'm having
> trouble finding a translation of "verb".

Search the web for "If Klingons wrote software". What I remember:

Our routines do not have parameters, they have arguments---and they
always win them!

Our software is not released---it escapes!

[Phillip Helbig---undress to reply]

In article <00ABBEB6...@SendSpamHere.ORG>, VAXman-

@SendSpamHere.ORG writes:

> In article <dbbedc0f-e72d-4cde...@b18g2000vbz.googlegroups.com>, AEF <spamsi...@yahoo.com> writes:
> >{...snip...}
> >>

> >> Well I speak to machines with the voice of humanity.
> >

> >Can you please rephrase that in a grammatically correct sentence with
> >correct spelling? I tried, but I just can't make sense of it. Let me
> >try Google. Nope, didn't match any documents. Hmmm. Maybe it really
> >doesn't make sense.
>
> Funny (as in peculiar, not ha ha) thing. I put that line into Google
> and the first hit was its source. Do you have Googletitis Inputicus?

But was he referring to the song lyric or the Star Trek statement?

[AEF]

On Jan 25, 6:54 am, VAXman- @SendSpamHere.ORG wrote:

> In article <dbbedc0f-e72d-4cde-bb32-f5c3f02ae...@b18g2000vbz.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes:
>
> >{...snip...}
>
> >> Well I speak to machines with the voice of humanity.
>
> >Can you please rephrase that in a grammatically correct sentence with
> >correct spelling? I tried, but I just can't make sense of it. Let me
> >try Google. Nope, didn't match any documents. Hmmm. Maybe it really
> >doesn't make sense.
>
> Funny (as in peculiar, not ha ha) thing.  I put that line into Google
> and the first hit was its source.  Do you have Googletitis Inputicus?

I still can't make any sense of it. Oh, crap. I was referring to the
"Klingon dweebs" bit, not what you thought I meant. I misplaced my
question. Sorry. My fault. Point: VAXMAN!

Hey, can you please rephrase the Klingon bit? It almost makes sense as
is, but I just can't make the necessary (probably minor)
correction(s).

I was lazy and copied and pasted it as is. Being as I pasted the wrong
thing, it's no surprise it didn't work.

Your search - Googletitis Inputicus - did not match any documents.

Point: AEF!

>
> >It's late.
>
> It must be.

Yep! No points. Too easy a response.

>
> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG
>
> Well I speak to machines with the voice of humanity.

The only things I say to machines are: Work, you stupid machine! _and_
Work you son bitch! (the latter usually to a printer) I guess that's
why they don't like me. (drum, cymbal crash!)


Take care

AEF

[AEF]

On Jan 25, 6:46 am, VAXman- @SendSpamHere.ORG wrote:

> In article <512b514a-fb41-4c59-b599-b3a46a56c...@hs8g2000vbb.googlegroups.com>, AEF <spamsink2...@yahoo.com> writes:
>
> >>{...snip...}
> >>http://en.wikipedia.org/wiki/Kobaian
>
> >Hmmmm. Must be true if it's on Wikipedia! (~_^)
>
> True?  You doubt the veracity of the Wiki link?  I've seen Magma perform
> live several times.  While I don't speak a lick of Kobaian, I can attest
> to you that they do.

Acknowledged. OK.

[Paul Sture]

On Wed, 25 Jan 2012 11:46:36 +0000, VAXman- wrote:

> In article
> <512b514a-fb41-4c59...@hs8g2000vbb.googlegroups.com>, AEF
> <spamsi...@yahoo.com> writes:
>>>{...snip...}
>>> http://en.wikipedia.org/wiki/Kobaian
>>
>>Hmmmm. Must be true if it's on Wikipedia! (~_^)
>
> True? You doubt the veracity of the Wiki link? I've seen Magma perform
> live several times. While I don't speak a lick of Kobaian, I can attest
> to you that they do.

So how do you _know_ that they were speaking Kobaian and not something
else? :-)



--
Paul Sture

[Arne Vajhøj]

On 1/24/2012 4:06 AM, Michael Kraemer wrote:
> Richard B. Gilbert schrieb:
>> VMS is not widely used these days. Princeton University had VAXen in:
>> Plasma Physics Laboratory, Gas Dynamics Laboratory, Physics
>> Department, and the Chemistry Department. It doesn't help if the
>> students can't use it, or if they choose to use something else. The
>> University as a whole was IBM oriented. The Computing Center had an
>> IBM 360/91, one of eighteen or so that were made. It was what passed
>> for a "super computer" in those days.
>
> This scenario wasn't/isn't unusual for academia (uni's and bigger labs).
> For larger tasks one had big iron in the Computing Centre.
> For data taking or process control one used PDP's or, later, VAXen.
> So until the late 1980's there was little chance for a student
> *not* to be exposed to one of those DEC products. From the end
> of the 1980's onwards, however, Unix took over. DEC still had
> a good chance to ride that wave too, e.g. by migrating their
> large VMS base to Ultrix, while constantly improving the latter.
> DEC chose to blow that opportunity.

Or made OSF/1 a bigger success. Many people consider OSF/1 aka
DU aka Tru64 to be a lot better than Ultrix.

Note that they would still have been toast today, but Unix
would have given them 10-15 more years until Linux and Windows
would have taken over anyway.

Arne

[Richard B. Gilbert]

DEC's pricing was such that nearly all of its competitors could
undersell them and nearly all of them did just that!

As far as I can tell, DEC either could not or would not sell at
the "Market Price".

Suicide! R.I.P. Digital Equipment Corp.

[Michael Kraemer]

Arne Vajhøj schrieb:

> Or made OSF/1 a bigger success. Many people consider OSF/1 aka
> DU aka Tru64 to be a lot better than Ultrix.

The first versions (up to V3) didn't look and feel
much different from Ultrix, apart from being
binary incompatible, of course.
Not a good prerequisite for success in competition with
the offerings from IBM, HP, Sun, etc.

> Note that they would still have been toast today,

not necessarily, if they had a consistent product to sell.
IBM for example has a healthy Unix business,
as far as I can see.
If vendors shoot themselves in the foot, however,
like HP did with their Itanic adventure,
or DEC with the alpha transition,
they loose the race.

> but Unix
> would have given them 10-15 more years until Linux and Windows
> would have taken over anyway.

VMS' fate wouldn't be different, but its niche would have
been more comfortable with a healthy parent company
in the background.

[John Wallace]

On Jan 29, 12:55 am, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:

There's more to success than being cheap (although commercial
beancounters often fail to understand this).

Apple don't seem to be bothered by not being competitively priced but
that's been done to death and these days they don't even try to
compete seriously in the enterprise market.

As an alternative, one which is acceptable in industry, you might want
to have a look at National Instruments and their fans, and see how NI
continue to do well despite being more expensive (according to
beancounters) than many of their competitors. Quality product, price
isn't cheapest but it is good value in the bigger picture, and quality
support (that's how it seems to me anyway).

[Arne Vajhøj]

On 1/30/2012 3:29 AM, Michael Kraemer wrote:
> Arne Vajhøj schrieb:
>> Or made OSF/1 a bigger success. Many people consider OSF/1 aka
>> DU aka Tru64 to be a lot better than Ultrix.
>
> The first versions (up to V3) didn't look and feel
> much different from Ultrix, apart from being
> binary incompatible, of course.
> Not a good prerequisite for success in competition with
> the offerings from IBM, HP, Sun, etc.

Hmm.

I think the programming and sysadm was somewhat different.

>> Note that they would still have been toast today,
>
> not necessarily, if they had a consistent product to sell.
> IBM for example has a healthy Unix business,
> as far as I can see.

IBM may still make money on AIX, but the big commercial
unixes (AIX, Solaris, HP-UX) are loosing marketshare
quickly.

The point they are being sol on now are:
- they are good for very big database servers
- they have various Linux compatibility kits

Sound familiar?

Arne

[Michael Kraemer]

Arne Vajhøj schrieb:

> Hmm.
>
> I think the programming

not much different.
The usual crop of languages and libraries
(C/C++,Fortran,Pascal) on both sides.
Ultrix even had a PL/I compiler,
I don't know if OSF/1 had one right from the start.
The main difference I can remember that
mmap() was sort of substandard on Ultrix
and OSF/1 supported dynamic loading.
Not much progress, considering the relevant time span
from 1989 to 1992/93.

> and sysadm was somewhat different.

Installation procedures are almost undistinguishable
(did it many times).
Neither Ultrix nor OSF/1 in its first versions had
admin tools to speak of.
At least nothing comparable to HP's contemporary SAM,
let alone IBM's smit.

> IBM may still make money on AIX, but the big commercial
> unixes (AIX, Solaris, HP-UX) are loosing marketshare
> quickly.

Last business report (and several ones before)
says Power systems increased business,
and istr Oracle claiming the same for their
inherited Sun gear. HP BCS may be on the decline,
but that's due to their Itanic desaster.
Not inevitable fate, but self-inflicted damage.

>
> The point they are being sol on now are:
> - they are good for very big database servers
> - they have various Linux compatibility kits
>
> Sound familiar?

If you refer to VMS: it's in a much worse shape
if you consider that HP says the vast majority
of Itanics sail under HP-UX.

[Hein RMS van den Heuvel]

On Jan 21, 11:29 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
:
> Would SEARCH x.x B /OUT=X.LIS be better than
>
> $  OPEN/READ IN X.X
> $  OPEN/WRITE OUT X.LIS
> $LOOP:
> $  READ/END=DONE IN REC

:
> Some tests indicate that SEARCH is much faster.  Can one depend on this
> always being the case?

Sorry, late to the party. Work and such. Read most replies, but this
may still be redundant.

Anyways, typically for all but the shortests of file ANYTHING will
beat out DCL in performance.
This is because DCL tells RMS to use a 1 block buffer, no read-ahead.
I have a monthly meeting with RMS Engineering where I've been lobbying
to fix this past-century choice.

SEARCH is often fastest and most convenient, but it does not have to
be because it just uses RMS
Since 2003, with Guy's well meant change it uses these hardcoded
values
MBF = 3 (Multi-buffer count), MBC = 127 ( I/O transfer size ), ROP =
(RAH,LOC) Read-ahead, locate mode
These are typically fin values. But we lost the ability to override
with SET RMS.
- A few more buffers MIGHT help some IO configurations.
- 'Even' buffers sizes (multiple of 16) MIGHT help some IO/XFC
configs.
- As of 8.4 and with patches back to 7.3-2 one can request up to 255
buffers with SET RMS

COBOL, SORT, and CRTL based programs (AWK, PERL) can outperform
SEARCH, notably on SHORT records.
Why? Because they use SYS$READ and processes records entirely in USER
mode.
Search uses RMS and thus goes in and out of exec mode, probing buffer
and rabs as goes for each record.

As usual... it all depends but if performance is of any concern then
just don't use DCL.
Beyond that it matters little what tool you pick as far as processing
speed goes.
If development performance/speed matters more than execution speed
then DCL is often a fine choice.
Myself I prefer PERL, AWK, for searching because of the regulare
expressions.
Sort can be neat as well.


Cheers,
Hein

[Arne Vajhøj]

On 1/31/2012 6:55 AM, Michael Kraemer wrote:
> Arne Vajhøj schrieb:
>> Hmm.
>>
>> I think the programming
>
> not much different.
> The usual crop of languages and libraries
> (C/C++,Fortran,Pascal) on both sides.
> Ultrix even had a PL/I compiler,
> I don't know if OSF/1 had one right from the start.
> The main difference I can remember that
> mmap() was sort of substandard on Ultrix
> and OSF/1 supported dynamic loading.
> Not much progress, considering the relevant time span
> from 1989 to 1992/93.

Having the same compilers does not exactly say
similar to program to me.

>> IBM may still make money on AIX, but the big commercial
>> unixes (AIX, Solaris, HP-UX) are loosing marketshare
>> quickly.
>
> Last business report (and several ones before)
> says Power systems increased business,
> and istr Oracle claiming the same for their
> inherited Sun gear. HP BCS may be on the decline,
> but that's due to their Itanic desaster.
> Not inevitable fate, but self-inflicted damage.

Unix market share in servers has dropped from
50% to 20% over the last decade.

>> The point they are being sol on now are:
>> - they are good for very big database servers
>> - they have various Linux compatibility kits
>>
>> Sound familiar?
>
> If you refer to VMS: it's in a much worse shape
> if you consider that HP says the vast majority
> of Itanics sail under HP-UX.

I was referring to VMS mid 90's.

Arne

[Michael Kraemer]

Arne Vajhøj schrieb:

> Having the same compilers does not exactly say
> similar to program to me.

Then what's the difference coding for Ultrix 4.x,
compared to DEC OSF/1 1.2, 1.3, 2.0 or 3.0?

> Unix market share in servers has dropped from
> 50% to 20% over the last decade.

That would not be "quickly".

>>
>> If you refer to VMS: it's in a much worse shape
>> if you consider that HP says the vast majority
>> of Itanics sail under HP-UX.
>
>
> I was referring to VMS mid 90's.

even worse (for VMS).

[Arne Vajhøj]

On 2/2/2012 4:06 AM, Michael Kraemer wrote:
> Arne Vajhøj schrieb:
>> Having the same compilers does not exactly say
>> similar to program to me.
>
> Then what's the difference coding for Ultrix 4.x,
> compared to DEC OSF/1 1.2, 1.3, 2.0 or 3.0?

I do not have access to an Ultrix system, but there
should be pretty big differences between a 32 bit
BSD using K&R C and a 64 bit third Unix family
using ANSI C.

And a quick look in C-Kermit, Lynx and JAM header
files reveals that Ultrix and OSF/1 has different
includes/definitions.

The official answer is probably this:

http://www.helsinki.fi/atk/unix/dec_manuals/DOC_40D/APS3EETE/PRGRMPRT.HTM

>> Unix market share in servers has dropped from
>> 50% to 20% over the last decade.
>
> That would not be "quickly".

Rather quickly.

In 10 years it will be like VMS today.

Arne

[Subcommandante XDelta]

On Sat, 04 Feb 2012 21:58:56 -0500, Arne Vajhøj <ar...@vajhoej.dk>
wrote:
:

>>> Unix market share in servers has dropped from
>>> 50% to 20% over the last decade.
>>
>> That would not be "quickly".
>
>Rather quickly.
>
>In 10 years it will be like VMS today.
>
>Arne

And what is going to fill the void? - and why?

(not a totally rhetorical pair of questions)

[Arne Vajhøj]

On 2/4/2012 10:45 PM, Subcommandante XDelta wrote:
> On Sat, 04 Feb 2012 21:58:56 -0500, Arne Vajhøj<ar...@vajhoej.dk>
> wrote:
> :
>>>> Unix market share in servers has dropped from
>>>> 50% to 20% over the last decade.
>>>
>>> That would not be "quickly".
>>
>> Rather quickly.
>>
>> In 10 years it will be like VMS today.
>

> And what is going to fill the void? - and why?
>
> (not a totally rhetorical pair of questions)

Linux and to some extent Windows are filling the void.

Arne

[Bob Koehler]

In article <4f2e96ac$0$295$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>
> Linux and to some extent Windows are filling the void.

Niether one of which can do some of the jobs that VMS has been used
for. But there are other options.

[Michael Kraemer]

Arne Vajh�j schrieb:

>
> I do not have access to an Ultrix system, but there
> should be pretty big differences between a 32 bit
> BSD using K&R C and a 64 bit third Unix family
> using ANSI C.

Back then we coded in Fortran and C on Ultrix(Mips)
as well as other Unices (plus proprietary OSs).
Although Ultrix was always a bit behind,
it wasn't a showstopper. I can't even remember
which C "standard" we used, we simply made it
work on as many platforms as necessary.
Nothing which couldn't be solved with a few ifdefs.
OSF/1 made no difference in that scenario.
32 vs 64 bit is a different story, of course,
but this has little to do with the language itself.

> And a quick look in C-Kermit, Lynx and JAM header
> files reveals that Ultrix and OSF/1 has different
> includes/definitions.

I don't remember there were more differences between them
than between OSF/1 and any other Unix of those days.

> The official answer is probably this:
>
> http://www.helsinki.fi/atk/unix/dec_manuals/DOC_40D/APS3EETE/PRGRMPRT.HTM

part of that is "exotic", part is "business as usual".

>>> Unix market share in servers has dropped from
>>> 50% to 20% over the last decade.
>>
>>
>> That would not be "quickly".
>
>
> Rather quickly.

not quickly.

> In 10 years it will be like VMS today.

10 years are rather long time in IT and pretty hard to predict.
Who would have thought in 1989 that DEC wouldn't
exist any more just ten years later?
(there also was the prediction that DEC would have surpassed
IBM in 2007 ...)
If you predicted in 1992/1993 that the shiny new Alpha
would be dead only ten years later, the last bunch being fabbed
by arch rival IBM, well, people would have called you a bit
crazy.

[Arne Vajhøj]

On 2/6/2012 10:52 AM, Bob Koehler wrote:
> In article<4f2e96ac$0$295$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<ar...@vajhoej.dk> writes:
>>
>> Linux and to some extent Windows are filling the void.
>
> Niether one of which can do some of the jobs that VMS has been used
> for.

Like?

Arne

[Bob Koehler]

In article <jgpkla$bop$1...@solani.org>, Michael Kraemer <M.Kr...@gsi.de> writes:
>
> I don't remember there were more differences between them
> than between OSF/1 and any other Unix of those days.

As in all things UNIX, it depends.

To the end user, they're all pretty much alike.

To the programmer, they're a bit different.

To the system admin, they're very different.

And for the programmer, it very much depends on the application.

Want to store huge amounts of customer data in an Orcale database?
You'll not see much difference.

Want to maniplulate a tape drive from your code? Very different.
Very, very, different. Been there, done that.

[Bob Koehler]

Hard real-time. How many times do I have to repeat that?

[John Wallace]

On Feb 7, 2:03 pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:

> In article <4f308264$0$282$14726...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <a...@vajhoej.dk> writes:
>
> > On 2/6/2012 10:52 AM, Bob Koehler wrote:

> >> In article<4f2e96ac$0$295$14726...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<a...@vajhoej.dk>  writes:

>
> >>> Linux and to some extent Windows are filling the void.
>
> >>     Niether one of which can do some of the jobs that VMS has been used
> >>     for.
>
> > Like?
>
>    Hard real-time.  How many times do I have to repeat that?

You might want to give an example of the kind of hard RT you mean.
Some Linuxes aren't at all bad at hard realtime (they even have
preemptible kernels for 'relatively' low latencies, and RT schedulers,
and such like). They're not VMS, but nothing else is. WNT certainly is
not VMS++.

[Arne Vajhøj]

On 2/7/2012 9:03 AM, Bob Koehler wrote:

It does not get more correct of repeating it.

VMS is not hard real time (VAXELN was).

One of the most widely used hard RTOS is RTLinux.

Arne

[Keith Cayemberg]

On Feb 8, 2:59 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 2/7/2012 9:03 AM, Bob Koehler wrote:
>

> > In article<4f308264$0$282$14726...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<a...@vajhoej.dk>  writes:

> >> On 2/6/2012 10:52 AM, Bob Koehler wrote:

> >>> In article<4f2e96ac$0$295$14726...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?=<a...@vajhoej.dk>   writes:
>
> >>>> Linux and to some extent Windows are filling the void.
>
> >>>      Niether one of which can do some of the jobs that VMS has been used
> >>>      for.
>
> >> Like?
>
> >     Hard real-time.  How many times do I have to repeat that?
>
> It does not get more correct of repeating it.
>
> VMS is not hard real time (VAXELN was).
>
> One of the most widely used hard RTOS is RTLinux.
>
> Arne

Just because DEC developed an additional Hard Real-Time OS specialized
for implementing embedded applications on the new one board VAXen,
doesn't mean that VMS wasn't already provided with all the
prerequisites of a Hard Real-Time OS.

The definition of Hard vs. Soft Real-Time is "partially"
implementation specific.

A Hard Real-Time OS is defined by having a mathematically absolute
determinable guaranteed response time to any/all critical event time
limits regardless of any incidental event combinations, the definition
does not set any specific latency time as a prerequisite.

Soft Real-Time systems have a low latency response time that meets
critical event response times in a very high percentage of instances,
but is not guaranteed to meet every specific critical response time
limit.

An app with no critical response time less than one hour to process a
few bytes may still be considered to be a Hard Real-Time application
by this definition. A Soft Real-Time OS may still not be able to
guarantee even that response time since a scheduler path, process
state, interrupt chain, or lock may be able to exceed even this
response time limit under extreme event combinations or environmental
conditions.

My understanding is that properly programmed applications on OpenVMS
meets the Hard-Real Time definition above. However, in most practical
cases the OpenVMS should not be a member of cluster to meet the Hard
Real-Time OS definition.

Many OS's will meet the Soft Real-Time definition for many
applications (apps that earlier actually required a Hard-Time OS
solution) by virtue of the inevitably reduced latencies of more modern
hardware. However, that still doesn't make that OS a Hard Real-Time
OS.

There are many examples of OpenVMS being used for Real-Time
applications, especially apps that required resources beyond the
capabilities of embedded systems at the time. To my knowledge the
Flight Control System governing the entire North Atlantic airspace and
based in Iceland is still running on OpenVMS. There are also several
radar systems, military communication systems and satellite control
systems running on OpenVMS. There are also multiple testimonies
provided by IT proffessionals such as Bob Koehler that they do indeed
write Hard Real-Time apps on OpenVMS.

Still the above apps, although good indicators, do not automatically
mean that OpenVMS is a Hard-Real Time OS, but rather by virtue of it's
well documented Real-Time Kernel implementation it is one. This
includes, but not limited to, the ability to run the program at
priority levels that are above the entire scheduler chain,
asynchronous and non-maskable interrupts, the ability to lock
instructions and data in main memory so that they are not paged/
swapped, and the allocation dedicated I/O channels.

Excuse me if the above has missing or incomplete information. I'm
writing this spontaneously from memory, and do not have time now to
look for supporting sources as required in a formal essay or white
paper.

Cheers!

Keith Cayemberg
Wipro Technologies

[Subcommandante XDelta]

On Wed, 8 Feb 2012 03:46:45 -0800 (PST), Keith Cayemberg
<keith.c...@arcor.de> wrote:
:
:

>There are many examples of OpenVMS being used for Real-Time
>applications, especially apps that required resources beyond the
>capabilities of embedded systems at the time. To my knowledge the
>Flight Control System governing the entire North Atlantic airspace and
>based in Iceland is still running on OpenVMS. There are also several
>radar systems, military communication systems and satellite control
>systems running on OpenVMS.

May we assume that some of the VMS userbase, at least, would have
strong opinions about the extinction of VMS if they knew it was on the
drawing board?

[Bob Koehler]

In article <4f31d6fb$0$293$1472...@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <ar...@vajhoej.dk> writes:
>
> It does not get more correct of repeating it.
>
> VMS is not hard real time (VAXELN was).
>
> One of the most widely used hard RTOS is RTLinux.

I did a ton of hard real-time with VMS, that Linux, UNIX, and Windows
couldn't do.

Yes, I know there were and are pure real-time sysyems like VAXEln, I
use VxWorks on a regular basis. That's why I said there are
alternatives.

And doing real-time on the RTLinux real-time kernel is not doing it on
Linus Torvaldis' Linux kernel. We've looked at moving from VxWorks
to RTLinux and found it didn't offer us any adavantages.

[Johnny Billquist]

I actually don't know how much guarantee VMS can give to processes with
realtime priorities. Are there some guaranteed maximum times for device
drivers to lock things out, and so on?

> One of the most widely used hard RTOS is RTLinux.

Which is a realtime OS, with Linux grafted as a process on top of it,
with restrictions, yes... :-)
Anything that wants to play realtime in there, cannot use any of the
Linux parts.

Johnny

[Richard B. Gilbert]

It will take more than "a strong opinion". Add a large amount of cash!

Face it! In the absence of a couple of major miracles, VMS is dead!
The hand writing on the wall is quite clear; VMS has been been on life
support for the last fifteen years or so! A few diehards will be using
VMS for the next ten or twenty years. There will be little or no
support from H-P. The "diehards" will continue to use VMS. Everyone
else will ignore it just as they have been doing. There will not be
enough paying users to support maintenance let alone development.
There will not be enough new users to replace our losses!

[Bob Koehler]

In article <jgu6kl$7l8$2...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:
>
> I actually don't know how much guarantee VMS can give to processes with
> realtime priorities. Are there some guaranteed maximum times for device
> drivers to lock things out, and so on?

No. But the VMS kernel spends very little time at elevated IPL,
custom device drivers can be tight, and the kernel genreally
wouldn't go off and do something else just when our realtime task
needed the CPU. (Yes, I know it can, I can force it to.)

In comparison the typical UNIX and the Linux kernel would go off
and do something else for up to 500ms (depending on which UNIX),
something which had nothing to do with the realtime work we were
trying to do. Windows is worse.

[Johnny Billquist]

On 2012-02-09 15:27, Bob Koehler wrote:
> In article<jgu6kl$7l8$2...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@softjar.se> writes:
>>
>> I actually don't know how much guarantee VMS can give to processes with
>> realtime priorities. Are there some guaranteed maximum times for device
>> drivers to lock things out, and so on?
>
> No. But the VMS kernel spends very little time at elevated IPL,
> custom device drivers can be tight, and the kernel genreally
> wouldn't go off and do something else just when our realtime task
> needed the CPU. (Yes, I know it can, I can force it to.)

Ok. I was thinking and comparing with RSX here, which I know more
intimately. In RSX, a driver is not allowed to spend more than a
specific time at elevated priority. It's documented in the manual on
writing device drivers, and it essentially means that excepting if you
actually get a storm of interrupts, you can more or less calculate the
maximum time before your program is serviced. Of course, this is still
not good enough for hard real time, but interrupt storms is something
that generally will fall under broken hardware, and no system will be
able to guarantee anything in the face of broken hardware.

Oh, I just remembered/realized another thing. Can you in VMS lock the
full process in memory, so that you don't run the risk of page faults?
(This is another thing you can do in RSX, to make sure response times
aren't messed up by the memory subsystem.)

> In comparison the typical UNIX and the Linux kernel would go off
> and do something else for up to 500ms (depending on which UNIX),
> something which had nothing to do with the realtime work we were
> trying to do. Windows is worse.

Real time in Unix does not exist. People who think otherwise just have
not looked enough at it, and buy words like "rtLinux" without
understanding what that is. You can easily get into more than 500ms
issues as well, if you are unlucky.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Bob Koehler]

In article <jh2tt7$75p$1...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@softjar.se> writes:

> Oh, I just remembered/realized another thing. Can you in VMS lock the
> full process in memory, so that you don't run the risk of page faults?
> (This is another thing you can do in RSX, to make sure response times
> aren't messed up by the memory subsystem.)

Sure can, although we generally just locked the I/O buffers. At
the time this required properly customizing the device drivers since
the default interfaces lock the buffer before each I/O and unlock
them afterward, but this is now actually a supported interface
(fastpath?).

Since we had custom hardware, we had to do custom drivers anyhow.

[Keith Parris]

On 2/10/2012 7:10 AM, Bob Koehler wrote:
> the default interfaces lock the buffer before each I/O and unlock
> them afterward, but this is now actually a supported interface
> (fastpath?).

You were thinking of Fast I/O. It uses Buffer Objects, which are locked
into memory once, thus avoiding the overhead of locking and unlocking an
I/O buffer for every I/O operation.

Fast Path allows assigning interrupt workload to specific CPUs, to avoid
overloading the Primary CPU (or any other single CPU) in an SMP system.

Fast Path and Fast I/O are described in the OpenVMS Programming Concepts
Manual at http://h71000.www7.hp.com/doc/82final/5841/5841pro_069.html

[Keith Cayemberg]

> Oh, I just remembered/realized another thing. Can you in VMS lock the
> full process in memory, so that you don't run the risk of page faults?
> (This is another thing you can do in RSX, to make sure response times
> aren't messed up by the memory subsystem.)

The following is written in the HP OpenVMS Operating System for Alpha
Version 7.3–1 and 7.3–2, and VAX Version 7.3 SPD 25.01.68
http://h71000.www7.hp.com/doc/spdalpha731732vax73.pdf

-------------
Real-time processes can be assigned higher priorities to
ensure that they receive processor time whenever they
are ready to execute. Real-time processes are scheduled
preemptively; that is, if a real-time process is ready
to execute, it is given to the processor immediately, unless
a process with a higher priority is ready to execute.

Programmers can control memory management from
within an image. An image executing in a real-time process,
for example, can inhibit paging or swapping of
critical code and data.

Peripheral devices can be managed by the system or allocated
by individual processes.
-------------

Also the 1003.4 Real-Time POSIX standard was implemented on OpenVMS
POSIX Shell, which is just layered on top of the OpenVMS kernel
services.
Taken from the OpenVMS Programming Environment Manual...
http://h71000.www7.hp.com/doc/73final/documentation/pdf/ovms_prog_environ.pdf
-------------
OpenVMS POSIX implements the POSIX 1003.4 draft standard, which
defines
a set of real-time functions. For applications that have real-time
computing
requirements, these extensions provide support for such functions as
enhanced
interprocess communication, scheduling and memory management control,
and
asynchronous I/O operations.
For more information about OpenVMS POSIX programming interfaces, see
the Guide to Programming with VMS POSIX, the Guide to Programming with
POSIX for OpenVMS AXP, and other documentation in the OpenVMS POSIX
documentation set.
------------

Hoff has a very similar definition of Hard Real-Time to what I
presented in my recent posting...
http://labs.hoffmanlabs.com/node/899
"If the real-time system cannot miss an event, then different designs
and requirements are in force. This RT system is variously referred to
as a hard real-time system, to distinguish this from other RT
environments."

In his article he also more focused on the economics of the
traditional embedded systems, PLC, DCS, SCADA systems hierarchy that
best fits the vast majority of industrial process control and
distribution systems today. OpenVMS-based solutions are more often
found near the top of that hierarchy, which can also have critical
response time limits of their own. I have seen this especially in the
steel industry, where the supervisory level OpenVMS systems must
respond to alarms given by a PLC within a specific time frame, and no
alarm event can be dropped. Similar strict response requirements are
needed for some OpenVMS SCADA systems controlling oil and gas
pipelines of Europe and the Middle East, some electrical power
distribution systems and nuclear power generation systems in Germany,
and some medical intensive care monitoring systems that I am aware of.
I don't take Hoff's article to mean that there are no (Hard or Soft)
real-time applications existing which are appropriate for OpenVMS
implementation today.


Here are some other interesting links...

VAX/VMS REALTIME PROGRAMMING by Bill Forbes
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/hardware/micronotes/numerical/micronote44.txt

ARS offers several OpenVMS Real-Time Programming courses...
http://www.arsi.com/rtvms.htm

[Subcommandante XDelta]

Subcommandante XDelta:

Mr Mezel, in a recent conversation thread, estimated, IIRC (senior
moments notwithstanding), that the remaining VMS end-user population
might be circa 100,000 shops.

So this topic is not about who or what those shops are, but rather what
they are using VMS for.

Port the FCS cited above to NSK from VMS, with new generations of
Bohrbugs and Heisenbugs to iron out? - not bloody likely.

[Bill Gunshannon]

In article <529c1b27$0$36907$c3e8da3$f67c...@news.astraweb.com>,

Subcommandante XDelta <v...@star.enet.dec.com> writes:
> Subcommandante XDelta:
>> On Wed, 8 Feb 2012 03:46:45 -0800 (PST), Keith Cayemberg
>> <keith.c...@arcor.de> wrote:
>> :
>> :
>>> There are many examples of OpenVMS being used for Real-Time
>>> applications, especially apps that required resources beyond the
>>> capabilities of embedded systems at the time. To my knowledge the
>>> Flight Control System governing the entire North Atlantic airspace and
>>> based in Iceland is still running on OpenVMS. There are also several
>>> radar systems, military communication systems and satellite control
>>> systems running on OpenVMS.
>>
>> May we assume that some of the VMS userbase, at least, would have
>> strong opinions about the extinction of VMS if they knew it was on the
>> drawing board?
>
> Mr Mezel, in a recent conversation thread, estimated, IIRC (senior
> moments notwithstanding), that the remaining VMS end-user population
> might be circa 100,000 shops.

I expect that number to be much higher than reality. HP made it clear
quite some time ago that there was no future on VMS. No serious company
waits until the plug is pulled to find an alternative.

>
> So this topic is not about who or what those shops are, but rather what
> they are using VMS for.
>
> Port the FCS cited above to NSK from VMS, with new generations of
> Bohrbugs and Heisenbugs to iron out? - not bloody likely.

Given that there are no bugs in the currently running version (yeah,
right!) and that you have the source, a good project is not likely to
introduce all that many, if any, new bugs. A bigger problem would be
VMS funtions not provided by NSK. One has to wonder if HP actually has
a VMS -> NSK Porting Kit and Library.

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>