So the writing appears to be on the wall, and after scouring the web
and chatting to colleagues, I've finally been convinced that our large
business-critical application currently running on OpenVMS (IA64) has
to be moved to something that will be supported fifteen years down the
line.

Since this is a niche community, I'm appealing to anyone in the know
to find out who specialises in COBOL system migrations, specifically
*from* OpenVMS, to any modern platform (interpretation: Windows or
Linux)?  I'm looking for someone to come in and do the whole job and
leave us with a system that behaves just as it did before.

Eric Smith wrote:

> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.


If you have a lot of software on your VMS system, a move to Unix will
require a lot of work. You need to consider for instance what happens if
your Cobol uses indexed files and how you will provide that capability
on Unix.

You need to make a list of all VMS dependencies that you have, and then
take a look at alternative systems and middleware for the best replacement.

You need to make a policy decision of whether you are to go for open
sourced OS (less likely to be killed by the whims of one or more CEOs)
or whether you would accept going to a proprietary UNIX such as AIX
which might provide better mapping of VMS functionality.

Eric Smith wrote 2012-05-16 09:08:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
>

Have you actualy talked to HP ?
No matter what you think about HP or if you belive anything thay
say, there is absolutely no reason *not* to talk to them.


> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

I do not think this is possible without you participation.
A very risky project.


JF Mezei wrote 2012-05-16 09:53:
 > You need to make a policy decision of whether you are to go for open
 > sourced OS (less likely to be killed by the whims of one or more CEOs)

But more likely to be killed by the community. There are currently some
(some says big) problems with support/development of some former active
OSS stuff now when "everyone" jump on the app train.

The mantra saying that "you can support it yourself" or "just hire someone"
just isn't good enought for a professional business. That is, a business
that is not an IT-business itself (Google, Facebook...)

Jan-Erik Soderholm wrote:

> Have you actualy talked to HP ?

Not ever VMS shop is large enough to be fortunate enough to have the
privilege of having a contact within HP.

And HP has been closing a lot of local offices in recent years as well,
so having contacts at HP is even harder.

Also, HP is not going to give you the real time of day. HP employees
will give you the script they have been told to tell customers. If you
are to talk to HP, you should also read the Oracle court documents to
get the other side of the coin.

On Wednesday, May 16, 2012 3:08:17 AM UTC-4, Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
>=20
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

There are way too many issues to be discussed about this to allow anyone he=
re to give you useful information regarding the transition.  For example, i=
s the system uptime critical 24 hours per day? or is similar functionality =
and screen interaction mroe inmportant?  What does the system do? Are there=
 alternatives that already exist where a migration to another already exist=
ing package would be less expensive?  Do you have modules written in MAcro =
that would need to be implimented in another language?=20

Contact me directly for more information.

Dan

Dansabrservices AT Yahoo DOT com

There are two companies worth talking to. Sector7 and Transoft.  At the ver=
y least a conversation with both will sharpen your own thinking about what =
strategy can be good or what may not work.=20

You will need to think about whether you are looking at a port (recompile a=
nd go) or rearchitecting such that you are no longer in COBOL. Other issues=
 to think about would include whether the two systems (vms and new) need to=
 peacefully coexist or are you looking at a flag day type cutover. And of c=
ourse the answers to those questions have to be compatible with your budget=
 and internal expectations.=20

Good luck.=20

EJ

JF Mezei wrote 2012-05-16 13:07:
> Jan-Erik Soderholm wrote:
>
>> Have you actualy talked to HP ?
>
> Not ever VMS shop is large enough...

"our large business-critical application currently running
on OpenVMS (IA64)" sounds large enough.

> to be fortunate enough to have the privilege of having a contact within
> HP.
>

You do not need luck and it's not an privilege, of course.

> And HP has been closing a lot of local offices in recent years as well,
> so having contacts at HP is even harder.

When was the last time *you* contacted HP on some VMS issue !?

The whole IT business has closed "local offices" the last 10-20 years.
So what ? Anyway, it's up to you, Eric, to listen to JF or not.

Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:

>JF Mezei wrote 2012-05-16 13:07:
>> Jan-Erik Soderholm wrote:
>>
>>> Have you actualy talked to HP ?
>>
>> Not ever VMS shop is large enough...

>"our large business-critical application currently running
>on OpenVMS (IA64)" sounds large enough.

>> to be fortunate enough to have the privilege of having a contact within
>> HP.
>>

>You do not need luck and it's not an privilege, of course.

>> And HP has been closing a lot of local offices in recent years as well,
>> so having contacts at HP is even harder.

>When was the last time *you* contacted HP on some VMS issue !?

>The whole IT business has closed "local offices" the last 10-20 years.
>So what ? Anyway, it's up to you, Eric, to listen to JF or not.

It depends on the level of service contract with HP, if any, they have.
I worked for an organization that needed 24/7 support for its VMS systems
and every time I called in an issue, HP was very good at responding, at
least once you got past the first line of telephone service people who
often couldn't spell "VMS".  Of course, I'm sure HP charges $$$$$$$ for
that privilege.

In article <b888d449-be8b-481f-907a-602f72f76784@p27g2000vbl.googlegroups.com>, Eric Smith <serfsmith@gmail.com> writes:
> 
> leave us with a system that behaves just as it did before.

    ROTFLOL.

Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
> 
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

If you think you got 15 more years of VMS, what's the hurry ?

Then again, it might take more than 15 years ....

I think others have given good advice when they say "talk to HP".  While JF likes to run 
around declaring "the sky is falling", I don't (yet) have any lumps on my head.

If enough people talk to HP, perhaps it will cause HP to see that continuing to support 
VMS is a good idea.  If they don't hear from anyone, perhaps they'll think the train has 
already left ..

There are 2 basic (as I see it) questions for the future.  One is whether you will need 
more functionality in the OS, and the other is support for then current devices.

If you will not need any new features, then what's running today will run just as well 15 
and even 100 years down the road.  Big problem here is, you won't know what you need, 
until you know you need it.

The list of old disk drives is rather long.  Today it's S-ATA, and maybe serial SCSI, 
don't know.  What will it be tomorrow?

One seeming solution for hardware support is to run in emulation on current hardware. 
This takes care of the CPU, memory, disks, and basically everything else.  I see myself 
contemplating this path in the future.  50 pin SCSI disks just aren't made anymore.

As for disks, the way things are going, they look to be replaced as primary storage by 
solid state disks.  It's starting now, and will most likely continue to grow and become 
more cost effective.

The real kick in the teeth is whatever you choose may be in worse shape than VMS in 15 years.

The basic question I put to people is, if you don't have to spend a lot of money this year 
for what at best will be a sideways move, and most likely a downward move (you'll never 
get it all working as good as your current system), then why do so?  Conversions, ports, 
and such should be delayed until the pain is more than the cost of the change.  Anything 
else is throwing money away for no gain.


Or, you could really get stupid and contract with one of the "off-shore software" vendors. 
  If you do, I'd suggest that you don't pay one cent until you're 100% satisfied.  Even if 
you don't pay them anything when they fail to delived what you need, they'll have eaten up 
plenty of your time.

On Wednesday, May 16, 2012 3:08:17 AM UTC-4, Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
> 
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.



On Wednesday, May 16, 2012 3:08:17 AM UTC-4, Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
> 
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

Eric,

That could be a tall order, in any number of different respects.

Most importantly, to the best of my knowledge, NONE of the base OS suppliers will commit to anything being available in 15 years time. Certainly, linux versions have a far shorter life, and MS Windows has not been a model of forward compatibility either.

That said, the first (or many) important questions is: How OpenVMS dependent is the code base. Without that information, it is not possible to know how difficult a task a migration would be.

I will be happy to speak with you offline.

- Bob Gezelter, http://www.rlgsc.com

Michael Moroney wrote:

> It depends on the level of service contract with HP, if any, they have.

Service contract doesn't garantee you have access to a HP sales rep and
even if it does, it doesn't garantee that sales rep is allowed to talk
about transition yet.

Once HP publicly admits that IA64 is on its last leg and that VMS/HP-UX
are dead ended on IA64, then HP sales reps will be given a new script to
read to customers and will stop pretending IA64 is succesful. At that
point, HP should also announce some sort of migration assistance to
their new 8086 basaed Superdomes and servers.

Until then, HP reps are forced to deny this will happen so they are useless.

If you are important enough that you can talk to Meg Whitman, then
things owuld be different. But you wouldn't be coming here for advice.

JF Mezei wrote 2012-05-16 21:58:
> Michael Moroney wrote:
>
>> It depends on the level of service contract with HP, if any, they have.
>
> Service contract doesn't garantee you have access to a HP sales rep and
> even if it does, it doesn't garantee that sales rep is allowed to talk
> about transition yet.
>
> Once HP publicly admits that IA64 is on its last leg and that VMS/HP-UX
> are dead ended on IA64, then HP sales reps will be given a new script to
> read to customers and will stop pretending IA64 is succesful. At that
> point, HP should also announce some sort of migration assistance to
> their new 8086 basaed Superdomes and servers.
>
> Until then, HP reps are forced to deny this will happen so they are useless.
>
> If you are important enough that you can talk to Meg Whitman, then
> things owuld be different. But you wouldn't be coming here for advice.

Now, if and whenever HP/Intel stops further development of Itanium, that
doesn't make the currently available servers suddenly stop working.

In a 15 year timeframe there is plenty of time to wait-and-see and
make decissions from actual facts and not from what someone, who
feels burnt by DEC/CPQ/HP for his lost career, writes in a newsgroup.

Both my VMS customers are on AlphaServer DS20 or DS25 with no current
porting plans of the application to either Itanium or another OS.
Support is on one case by HP and in the other by a third part. One
of the custumers states a min lifetame of 3-5 years. Fine by me,
noone can look further into the future anyway.

So if IA64 would be EOL'd *today*, you could probably run your VMS
apps for at least 10 years or more on the currently available servers.

Jan-Erik Soderholm wrote:

> Now, if and whenever HP/Intel stops further development of Itanium, that
> doesn't make the currently available servers suddenly stop working.

That is correct. And when the last IA64 chip comes out in 2014, HP will
likely continue to sell IA64 based sytems for many years, just as they
did after EV7 came out.

However, if you know that a migration will come, it is best to start early.

As a first step, you stop using any VMS specific system services when
updating existing or writing new apps on VMS. (Uness you have made the
decision to rewrite from scratch when you port).

You need to make architectural decisions on middleware such as an SQL or
other database, how you will map indexed files on the new systen, VMS
mailboxes etc.

And you want to know the new system inside out before you actually begin
the code porting.

This isn't done overnight.

On 05/16/2012 12:08 AM, Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
>
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

My company has done a number of migrations both to OpenVMS and (lately) 
from OpenVMS and we have supported Cobol systems on OpenVMS for over 
twenty-five years. I would be interested in discussing your requirements 
to see if we can be of service. If interested, please either e-mail me 
or call me at +1-949-650-0526.

Jeff Coffield
www.digitalsynergyinc.com

On Wednesday, May 16, 2012 7:52:06 AM UTC-4, johnso...@gmail.com wrote:

> There are two companies worth talking to. Sector7 and Transoft. 

I knew I had forgotten one.  Maklee Engineering.

EJ

On Wednesday, May 16, 2012 2:01:52 PM UTC-4, David Froble wrote:

> The basic question I put to people is, if you don't have to spend a lot o=
f
> money this year for what at best will be a sideways move, and most likely
> a downward move (you'll never get it all working as good as your current
> system), then why do so?

I think this is very true. =20

If for some reason, you do begin a port or some sort of migration effort, y=
ou need to have a crystal clear understanding of what you expect the benefi=
t to be at the end.  You need that clarity because you need to be sure that=
 your project is successful along the way.

Big projects like this have an inherent need to go off the rails and right =
into the weeds.  Unlike real life, judging the success of a software projec=
t can come down to a matter of opinion and perspective.  One man's junk is =
another man's antique.

If you begin with a woozy understanding of what the benefit is - the entire=
 effort will meander into a thousand little directions and not achieve a wh=
ole lot other than spending a lot of quality engineering time that doesn't =
add up to much business value.

EJ

On 5/16/2012 3:53 AM, JF Mezei wrote:
> Eric Smith wrote:
>> Since this is a niche community, I'm appealing to anyone in the know
>> to find out who specialises in COBOL system migrations, specifically
>> *from* OpenVMS, to any modern platform (interpretation: Windows or
>> Linux)?  I'm looking for someone to come in and do the whole job and
>> leave us with a system that behaves just as it did before.
>
> If you have a lot of software on your VMS system, a move to Unix will
> require a lot of work. You need to consider for instance what happens if
> your Cobol uses indexed files and how you will provide that capability
> on Unix.

Just buy a replacement.

Arne

On 5/16/2012 4:15 AM, Jan-Erik Soderholm wrote:
> JF Mezei wrote 2012-05-16 09:53:
>  > You need to make a policy decision of whether you are to go for open
>  > sourced OS (less likely to be killed by the whims of one or more CEOs)
>
> But more likely to be killed by the community. There are currently some
> (some says big) problems with support/development of some former active
> OSS stuff now when "everyone" jump on the app train.
>
> The mantra saying that "you can support it yourself" or "just hire someone"
> just isn't good enought for a professional business. That is, a business
> that is not an IT-business itself (Google, Facebook...)

There are tens of thousands of open source projects dying every year
because the volunteers drop out of the project.

But since the open source project in question seems to be Linux
then the argument does not really apply.

Arne

johnson.eric@gmail.com wrote:

> I knew I had forgotten one.  Maklee Engineering.


Is thats still with Guy Peleg, the one we have to thank for the last big
improvements to Backup and a few DCL additions ?

On Wed, 16 May 2012 17:59:36 -0700 (PDT), johnson.eric@gmail.com
wrote:

>On Wednesday, May 16, 2012 2:01:52 PM UTC-4, David Froble wrote:
>
>> The basic question I put to people is, if you don't have to spend a lot of
>> money this year for what at best will be a sideways move, and most likely
>> a downward move (you'll never get it all working as good as your current
>> system), then why do so?
>
>I think this is very true.  
>
>If for some reason, you do begin a port or some sort of migration effort, you need to have a crystal clear understanding of what you expect the benefit to be at the end.  You need that clarity because you need to be sure that your project is successful along the way.
>
>Big projects like this have an inherent need to go off the rails and right into the weeds.  Unlike real life, judging the success of a software project can come down to a matter of opinion and perspective.  One man's junk is another man's antique.
>
>If you begin with a woozy understanding of what the benefit is - the entire effort will meander into a thousand little directions and not achieve a whole lot other than spending a lot of quality engineering time that doesn't add up to much business value.
>
>EJ

Can I keep this for a quote on all software improvement projects?  Oh,
how many times do they meander...

Mark DeArman

"Eric Smith" <serfsmith@gmail.com> wrote in message 
news:b888d449-be8b-481f-907a-602f72f76784@p27g2000vbl.googlegroups.com...
>
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

"All your money are belong to us", is the first thing that comes to mind. 

"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message 
news:4fb35cf2$0$32182$c3e8da3$40d4fd75@news.astraweb.com...
> Eric Smith wrote:
>
>> Since this is a niche community, I'm appealing to anyone in the know
>> to find out who specialises in COBOL system migrations, specifically
>> *from* OpenVMS, to any modern platform (interpretation: Windows or
>> Linux)?  I'm looking for someone to come in and do the whole job and
>> leave us with a system that behaves just as it did before.
>
>
> If you have a lot of software on your VMS system, a move to Unix will
> require a lot of work. You need to consider for instance what happens if
> your Cobol uses indexed files and how you will provide that capability
> on Unix.
>
> You need to make a list of all VMS dependencies that you have, and then
> take a look at alternative systems and middleware for the best 
> replacement.
>
> You need to make a policy decision of whether you are to go for open
> sourced OS (less likely to be killed by the whims of one or more CEOs)
> or whether you would accept going to a proprietary UNIX such as AIX
> which might provide better mapping of VMS functionality.

No he doesn't.
He wants somebody to come in and do it, and he appears to have an unlimited 
bank account to do so. 

On Thu, 17 May 2012 12:40:30 -0400, John Smith \(who cares if I'm the one
@ HP - if here's even still there\) wrote:

> "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message
> news:4fb35cf2$0$32182$c3e8da3$40d4fd75@news.astraweb.com...
>> Eric Smith wrote:
>>
>>> Since this is a niche community, I'm appealing to anyone in the know
>>> to find out who specialises in COBOL system migrations, specifically
>>> *from* OpenVMS, to any modern platform (interpretation: Windows or
>>> Linux)?  I'm looking for someone to come in and do the whole job and
>>> leave us with a system that behaves just as it did before.
>>
>>
>> If you have a lot of software on your VMS system, a move to Unix will
>> require a lot of work. You need to consider for instance what happens
>> if your Cobol uses indexed files and how you will provide that
>> capability on Unix.
>>
>> You need to make a list of all VMS dependencies that you have, and then
>> take a look at alternative systems and middleware for the best
>> replacement.
>>
>> You need to make a policy decision of whether you are to go for open
>> sourced OS (less likely to be killed by the whims of one or more CEOs)
>> or whether you would accept going to a proprietary UNIX such as AIX
>> which might provide better mapping of VMS functionality.
> 
> No he doesn't.
> He wants somebody to come in and do it, and he appears to have an
> unlimited bank account to do so.

If he has an unlimited bank account, IBM may be a good suggestion.  They 
have porting tools to translate other flavours of COBOL into their own.

-- 
Paul Sture

On 5/17/2012 12:39 PM, John Smith (who cares if I'm the one @ HP - if 
here's even still there) wrote:
> "Eric Smith"<serfsmith@gmail.com>  wrote in message
> news:b888d449-be8b-481f-907a-602f72f76784@p27g2000vbl.googlegroups.com...
>>
>> Since this is a niche community, I'm appealing to anyone in the know
>> to find out who specialises in COBOL system migrations, specifically
>> *from* OpenVMS, to any modern platform (interpretation: Windows or
>> Linux)?  I'm looking for someone to come in and do the whole job and
>> leave us with a system that behaves just as it did before.
>
> "All your money are belong to us", is the first thing that comes to mind.
>
>

If the code does not contain hardware or O/S dependencies, you should be 
able to compile, link, and go.  If the code DOES contain O/S or hardware 
dependencies, you are in deep trouble!  Your first concern should be to 
have the perpetrators killed!

Richard B. Gilbert wrote:

> If the code does not contain hardware or O/S dependencies, you should be 
> able to compile, link, and go.  If the code DOES contain O/S or hardware 
> dependencies, you are in deep trouble!  Your first concern should be to 
> have the perpetrators killed!

One of the many values of VMS was its rich set or proprietary system
services.

Any shop that has developped a lot of stuff on VMS over decades is bound
to have developped many dependencies on VMS specific stuff.

Just consider the terminal driver's built-in timeout capability. If you
use that and move to Unix or even TCPIP, you need to re-invent the wheel.


This is why it is so important to do an inventory of all the OS specific
depednencies and work a plan to map those to the target system either by
writing equivalent routines, or changing the programs.

John Smith (who cares if I'm the one @ HP - if here's even still there) wrote:
> "JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message 
> news:4fb35cf2$0$32182$c3e8da3$40d4fd75@news.astraweb.com...
>> Eric Smith wrote:
>>
>>> Since this is a niche community, I'm appealing to anyone in the know
>>> to find out who specialises in COBOL system migrations, specifically
>>> *from* OpenVMS, to any modern platform (interpretation: Windows or
>>> Linux)?  I'm looking for someone to come in and do the whole job and
>>> leave us with a system that behaves just as it did before.
>>
>> If you have a lot of software on your VMS system, a move to Unix will
>> require a lot of work. You need to consider for instance what happens if
>> your Cobol uses indexed files and how you will provide that capability
>> on Unix.
>>
>> You need to make a list of all VMS dependencies that you have, and then
>> take a look at alternative systems and middleware for the best 
>> replacement.
>>
>> You need to make a policy decision of whether you are to go for open
>> sourced OS (less likely to be killed by the whims of one or more CEOs)
>> or whether you would accept going to a proprietary UNIX such as AIX
>> which might provide better mapping of VMS functionality.
> 
> No he doesn't.
> He wants somebody to come in and do it, and he appears to have an unlimited 
> bank account to do so. 
> 
> 

Well, now, that's another story.  If the bank account truly is unlimited, then call on me. 
  :-)

David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486

Jan-Erik Soderholm wrote:
> JF Mezei wrote 2012-05-16 21:58:
>> Michael Moroney wrote:
>>
>>> It depends on the level of service contract with HP, if any, they have.
>>
>> Service contract doesn't garantee you have access to a HP sales rep and
>> even if it does, it doesn't garantee that sales rep is allowed to talk
>> about transition yet.
>>
>> Once HP publicly admits that IA64 is on its last leg and that VMS/HP-UX
>> are dead ended on IA64, then HP sales reps will be given a new script to
>> read to customers and will stop pretending IA64 is succesful. At that
>> point, HP should also announce some sort of migration assistance to
>> their new 8086 basaed Superdomes and servers.
>>
>> Until then, HP reps are forced to deny this will happen so they are 
>> useless.
>>
>> If you are important enough that you can talk to Meg Whitman, then
>> things owuld be different. But you wouldn't be coming here for advice.
> 
> Now, if and whenever HP/Intel stops further development of Itanium, that
> doesn't make the currently available servers suddenly stop working.
> 
> In a 15 year timeframe there is plenty of time to wait-and-see and
> make decissions from actual facts and not from what someone, who
> feels burnt by DEC/CPQ/HP for his lost career, writes in a newsgroup.

:-)  :-)

Bullseye !!!

Take another shot ...


> Both my VMS customers are on AlphaServer DS20 or DS25 with no current
> porting plans of the application to either Itanium or another OS.
> Support is on one case by HP and in the other by a third part. One
> of the custumers states a min lifetame of 3-5 years. Fine by me,
> noone can look further into the future anyway.
> 
> So if IA64 would be EOL'd *today*, you could probably run your VMS
> apps for at least 10 years or more on the currently available servers.
> 
> 
> 

On 2012-05-17, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>
> Just consider the terminal driver's built-in timeout capability. If you
> use that and move to Unix or even TCPIP, you need to re-invent the wheel.
>

Unix terminal drivers have a built in timeout capability (at least the
ones I am familiar with); the timeout is in units of 0.1 seconds.

BTW, if you want to start sending terminal data over a TCP/IP connection
on Unix use select() with a timeout.

Simon.

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

On May 18, 1:47=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
> On 2012-05-17, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
>
>
> > Just consider the terminal driver's built-in timeout capability. If you
> > use that and move to Unix or even TCPIP, you need to re-invent the whee=
l.
>
> Unix terminal drivers have a built in timeout capability (at least the
> ones I am familiar with); the timeout is in units of 0.1 seconds.
>
> BTW, if you want to start sending terminal data over a TCP/IP connection
> on Unix use select() with a timeout.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

I've done the Linux/Unix serial driver stuff. As you say, it's
sufficient for many applications. For user interfaces with timeouts
there's [n]curses too (think SMG, in concept anyway).

For one obscure project where process-level latencies meant the
standard serial timeout stuff was too coarse and the buffering was
inadequate, I took an existing Linux low level serial driver and put
what I needed into the driver itself. You could do that kind of thing
with VMS at one stage, but then DEC stopped documenting the serial
interface hardware (round about the CXY08 era?). Now a decade or two
later, with PCI serial interfaces with documentation, you could in
principle do a DIY driver under VMS again. Fortunately not many people
need to, and even fewer want to.

In article <7b6abf8e-0b3d-4f72-9a37-5c1e5ab5fdd6@m10g2000vbn.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
> You could do that kind of thing
> with VMS at one stage, but then DEC stopped documenting the serial
> interface hardware (round about the CXY08 era?).

   I thought the CXY08 was DEC's last serial interface board.

In article 
<b888d449-be8b-481f-907a-602f72f76784@p27g2000vbl.googlegroups.com>,
 Eric Smith <serfsmith@gmail.com> wrote:

> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.
> 
> Since this is a niche community, I'm appealing to anyone in the know
> to find out who specialises in COBOL system migrations, specifically
> *from* OpenVMS, to any modern platform (interpretation: Windows or
> Linux)?  I'm looking for someone to come in and do the whole job and
> leave us with a system that behaves just as it did before.

I see to big problems here.

The first is, as others have noted, you probably won't get a commitment 
from any vendor that will say their product will still be supported 15 
years in the future.

The second is "leave us with a system that behaves just as it did 
before".  Do you have a complete document that says how the system 
behaves now?  Do you have a test suite that you can run on your current 
system so you will be able to test and know if the new system behaves 
the same way as the one you have now?

I'm not trying to be confrontational.  If you don't have a complete 
up-to-date accurate description of how the system works now, you will 
never be able to tell, in any reasonable time frame, if the new system 
is the same as the old one.  If you don't have a test suite, you won't 
be able to test the new system.

If you don't have these things, the first step is to create them.  In 
the process, you will obtain a much better idea of just what it is that 
your current system does.  You may (will probably) find that the system 
does more than you think it does, or that it does things differently 
than you think it does.  You will also have a much better idea of how 
big a job it's going to be to port the system, and what resources are 
going to be needed.

Bart.

"Simon Clubley"  wrote in message news:jp5gd4$khd$1@dont-email.me...

>Unix terminal drivers have a built in timeout capability (at least the
>ones I am familiar with); the timeout is in units of 0.1 seconds.


Yep, Google "tcsetattr" and you'll find:

In noncanonical mode input is available immediately (without the user having 
to type a line-delimiter character), and line editing is disabled. The 
settings of MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) determine the 
circumstances in which a read(2) completes; there are four distinct cases:

* MIN == 0; TIME == 0: If data is available, read(2) returns immediately, 
with the lesser of the number of bytes available, or the number of bytes 
requested. If no data is available, read(2) returns 0.

* MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or the 
number of bytes requested are available, and returns the lesser of these two 
values.

* MIN == 0; TIME > 0: TIME specifies the limit for a timer in tenths of a 
second. The timer is started when read(2) is called. read(2) returns either 
when at least one byte of data is available, or when the timer expires. If 
the timer expires without any input becoming available, read(2) returns 0.

* MIN > 0; TIME > 0: TIME specifies the limit for a timer in tenths of a 
second. Once an initial byte of input becomes available, the timer is 
restarted after each further byte is received. read(2) returns either when 
the lesser of the number of bytes requested or MIN byte have been read, or 
when the inter-byte timeout expires. Because the timer is only started after 
the initial byte becomes available, at least one byte will be read. 

John Reagan wrote:
> 
> 
> "Simon Clubley"  wrote in message news:jp5gd4$khd$1@dont-email.me...
> 
>> Unix terminal drivers have a built in timeout capability (at least the
>> ones I am familiar with); the timeout is in units of 0.1 seconds.
> 
> 
> Yep, Google "tcsetattr" and you'll find:
> 
> In noncanonical mode input is available immediately (without the user 
> having to type a line-delimiter character), and line editing is 
> disabled. The settings of MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) 
> determine the circumstances in which a read(2) completes; there are four 
> distinct cases:
> 
> * MIN == 0; TIME == 0: If data is available, read(2) returns 
> immediately, with the lesser of the number of bytes available, or the 
> number of bytes requested. If no data is available, read(2) returns 0.
> 
> * MIN > 0; TIME == 0: read(2) blocks until the lesser of MIN bytes or 
> the number of bytes requested are available, and returns the lesser of 
> these two values.
> 
> * MIN == 0; TIME > 0: TIME specifies the limit for a timer in tenths of 
> a second. The timer is started when read(2) is called. read(2) returns 
> either when at least one byte of data is available, or when the timer 
> expires. If the timer expires without any input becoming available, 
> read(2) returns 0.
> 
> * MIN > 0; TIME > 0: TIME specifies the limit for a timer in tenths of a 
> second. Once an initial byte of input becomes available, the timer is 
> restarted after each further byte is received. read(2) returns either 
> when the lesser of the number of bytes requested or MIN byte have been 
> read, or when the inter-byte timeout expires. Because the timer is only 
> started after the initial byte becomes available, at least one byte will 
> be read.

Or read the VAX Basic manual, keyword "Wait" ....

But I think the granularity is more course, wait is in seconds.

INKEY$

    The INKEY$ function reads a single keystroke from a terminal opened  on  a
    specified  channel  and  returns  the  typed  key.   Escape  sequences are
    interpreted and are returned as mnemonic strings.

    Example

    keystroke$ = INKEY$(0%, WAIT)

A lot more overhead than getting a string of characters, but sometimes that's what is 
required.

Don't know much (anything) about Unix, but with the tools on VMS some very capable input 
functions can be implemented.  What's important to me is, on VMS I don't have to use "C".

On 2012-05-20, David Froble <davef@tsoft-inc.com> wrote:
>
> Don't know much (anything) about Unix, but with the tools on VMS some
> very capable input functions can be implemented.  What's important to me
> is, on VMS I don't have to use "C".

Strangely enough, I'm not forced to use C on Unix either. :-)

My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
you won't catch me using it at home), and bash for shell scripting.

Other languages I have used or have considered using on Unix over the
years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.

Simon.

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

On Thursday, May 17, 2012 5:33:28 PM UTC-4, JF Mezei wrote:

> One of the many values of VMS was its rich set or proprietary system
> services.
>
> Any shop that has developped a lot of stuff on VMS over decades is bound
> to have developped many dependencies on VMS specific stuff.

Here's a thought on a way to begin disentangling oneself from the platform.=
  It attacks the problem from a slightly different angle so it may not work=
 for everyone.

Consider a C program that made use of functions like SYS$CONNECT, SYS$OPEN,=
 and SYS$TRNLNM.  It would be nice if one could just re-compile that on Lin=
ux and run it.  But of course, you can't do that.  If it was that easy, the=
se threads wouldn't exist here on comp.os.vms.

Being rhetorical here, why can't one just recompile it?  Well, for starters=
 the compiler won't be able to find the include files you need.  Files like=
 rmsdef.h, namdef.h, fabdef.h, etc won't be there.

With a little bit of effort, you can get those to be accepted by gcc nearly=
 as is.  You have to deal with a few common issues such as __int64 and prag=
mas for packing, but beyond that, they are just straight up headers.  There=
's nothing that unnatural about them apart from Digital's fondness for the =
dollar sign.

But that doesn't satisfy the linker now does it?  The linker of course asks=
 for an implementation to SYS$TRNLNM and whatever else you might have calle=
d from starlet.h.  So what do you do?

Instead of attempting to implement your own solution of SYS$TRNLNM, why not=
 forward that invocation back to a peer process on VMS?  Same for SYS$CONNE=
CT, SYS$OPEN, or LBR$GET_MODULE or any of the other common user mode pieces=
 of functionality.

If you get the native headers to compile on linux, it's fairly easy to writ=
e code to perform a deep copy of the entire structures that are passed into=
 those routines. =20

The idea here is a bit like an RPC model.  One would completely replicate t=
he function call such that the runtime on linux is completely unaware that =
the execution is on linux rather than on VMS.  But the underlying SYS$ func=
tionality is still performed on VMS.  Everything is copied back including t=
he return value.

I realize there are a lot of "yeah, buts" to be placed here.  I'll preempti=
vely enumerate some of them.

1) But what about ASTs?
2) But what about network performance/latency?
3) What about C library routines (eg: fopen, read, stat, etc).
4) How should the vms server process match up to the client linux process?
5) But why would you do this??!!  How does this help??

For now, I'll just address (5) and address other topics if there's really i=
nterest in the thought here.  And these are nothing more than thoughts.  I =
have no product to offer and no intent to do so.  It's more of an intellect=
ual curiosity to see if the ideas are useful.

As I see it, there are really two issues confounding VMS systems.  First, t=
he Itanium CPU is moribund.  Regardless of HP's announcement, it's clear th=
e x86 has surpassed it and will continue to be the future for the mainstrea=
m commodity world.  Second, VMS is effectively at the end of the line.  Tra=
gic, but true.

It's understandable that those problems get lumped together, but it might b=
e useful to see them as separate problems.

I think I can articulate an approach that at least enables you to move your=
 CPU load off of VMS while mapping out the nature of your dependency to VMS=
..  If one can successfully remote the access to VMS, you are turning your V=
MS nodes into a sophisticated "SAN head".  Once all of the execution is the=
n on another OS, you can then begin the task of redirecting those pieces to=
 other solutions.

One of the features of VMS that I think a lot of people admire is how easy =
it is to just "add a node" to the cluster.  It's a great way to expand your=
 capacity.  It also makes it easier to migrate to newer hardware.  One can =
bring in the newer nodes and then slowly retire the older ones.

I think an effective migration strategy off of VMS has to consist of findin=
g a way to get a "linux node" to be as near "peer like" as possible in that=
 VMS cluster.  Linux processes would have to be brokered through another pr=
ocess on a VMS node, but I think one can get very far with this approach an=
d then ultimately cut the cord.

The approach doesn't work for everyone.  I think it works best for a system=
 that is still growing and would need greater performance and capacity in t=
he future.  Systems that are mature should probably stay where they are.  A=
lso, it's an approach that would require one to have access to most of the =
code too.

Rather than write a tome on the topic, I thought I'd quickly sketch out the=
 idea, and see if there was interest in fleshing it out more.

EJ

On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:

> On 2012-05-20, David Froble <davef@tsoft-inc.com> wrote:
>>
>> Don't know much (anything) about Unix, but with the tools on VMS some
>> very capable input functions can be implemented.  What's important to
>> me is, on VMS I don't have to use "C".
> 
> Strangely enough, I'm not forced to use C on Unix either. :-)
> 
> My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
> you won't catch me using it at home), and bash for shell scripting.

I came across this rant about PHP over the weekend.

"PHP: a fractal of bad design"

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

> Other languages I have used or have considered using on Unix over the
> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.

I was looking for a Unix COBOL a few years ago, but came up with a blank, 
though I will admit I was looking at free/cheap solutions.


-- 
Paul Sture

On 2012-05-21, Paul Sture <paul@sture.ch> wrote:
> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>
>> On 2012-05-20, David Froble <davef@tsoft-inc.com> wrote:
>>>
>>> Don't know much (anything) about Unix, but with the tools on VMS some
>>> very capable input functions can be implemented.  What's important to
>>> me is, on VMS I don't have to use "C".
>> 
>> Strangely enough, I'm not forced to use C on Unix either. :-)
>> 
>> My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
>> you won't catch me using it at home), and bash for shell scripting.
>
> I came across this rant about PHP over the weekend.
>
> "PHP: a fractal of bad design"
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>
>> Other languages I have used or have considered using on Unix over the
>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>
> I was looking for a Unix COBOL a few years ago, but came up with a blank, 
> though I will admit I was looking at free/cheap solutions.
>

The two I know about are:

OpenCOBOL at http://www.opencobol.org/

and

TinyCOBOL at http://tiny-cobol.sourceforge.net/

TinyCOBOL development has now ended. COBOL is a language I considered
using on Unix but never actually did, so I don't know what quality and
functionality the compilers possess.

I've found the following link which should give you a overview for the
other languages on my list: http://en.wikipedia.org/wiki/List_of_compilers

Modula-2 is not on that list however, and can be found at:

http://www.nongnu.org/gm2/homepage.html

That is the other language I considered, but never used so I also don't
know the quality of the port. Be aware that it's based on what is now
a old version of gcc (4.1.2).

For Pascal, the GNU Pascal port is seriously dated, so you are probably
far better off with the Free Pascal port. It's been many years since I
last used either of them however, so my knowledge about them is not
current.

Simon.

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

Simon Clubley wrote:
> On 2012-05-21, Paul Sture<paul@sture.ch>  wrote:
>> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>>
>>> On 2012-05-20, David Froble<davef@tsoft-inc.com>  wrote:
>>>>
>>>> Don't know much (anything) about Unix, but with the tools on VMS some
>>>> very capable input functions can be implemented.  What's important to
>>>> me is, on VMS I don't have to use "C".
>>>
>>> Strangely enough, I'm not forced to use C on Unix either. :-)
>>>
>>> My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
>>> you won't catch me using it at home), and bash for shell scripting.
>>
>> I came across this rant about PHP over the weekend.
>>
>> "PHP: a fractal of bad design"
>>
>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>>
>>> Other languages I have used or have considered using on Unix over the
>>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>>
>> I was looking for a Unix COBOL a few years ago, but came up with a blank,
>> though I will admit I was looking at free/cheap solutions.
>>
>
> The two I know about are:
>
> OpenCOBOL at http://www.opencobol.org/

OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No 
updates in 4 years? Seems a rather dead project to me.


>
> and
>
> TinyCOBOL at http://tiny-cobol.sourceforge.net/
>
> TinyCOBOL development has now ended. COBOL is a language I considered
> using on Unix but never actually did, so I don't know what quality and
> functionality the compilers possess.
>
> I've found the following link which should give you a overview for the
> other languages on my list: http://en.wikipedia.org/wiki/List_of_compilers
>
> Modula-2 is not on that list however, and can be found at:
>
> http://www.nongnu.org/gm2/homepage.html
>
> That is the other language I considered, but never used so I also don't
> know the quality of the port. Be aware that it's based on what is now
> a old version of gcc (4.1.2).
>
> For Pascal, the GNU Pascal port is seriously dated, so you are probably
> far better off with the Free Pascal port. It's been many years since I
> last used either of them however, so my knowledge about them is not
> current.
>
> Simon.
>

Le 21/05/2012 17:05, Dirk Munk a �crit :
> Simon Clubley wrote:
>> On 2012-05-21, Paul Sture<paul@sture.ch> wrote:
>>> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>>>
>>>> On 2012-05-20, David Froble<davef@tsoft-inc.com> wrote:
>>>>>
>>>>> Don't know much (anything) about Unix, but with the tools on VMS some
>>>>> very capable input functions can be implemented. What's important to
>>>>> me is, on VMS I don't have to use "C".
>>>>
>>>> Strangely enough, I'm not forced to use C on Unix either. :-)
>>>>
>>>> My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
>>>> you won't catch me using it at home), and bash for shell scripting.
>>>
>>> I came across this rant about PHP over the weekend.
>>>
>>> "PHP: a fractal of bad design"
>>>
>>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>>>
>>>> Other languages I have used or have considered using on Unix over the
>>>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>>>
>>> I was looking for a Unix COBOL a few years ago, but came up with a
>>> blank,
>>> though I will admit I was looking at free/cheap solutions.
>>>
>>
>> The two I know about are:
>>
>> OpenCOBOL at http://www.opencobol.org/
>
> OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No
> updates in 4 years? Seems a rather dead project to me.

No. It is not ! But Roger While is working alone on a major update. In 
the meantime, Brian Tiffin has just uploaded on Sourceforge the current 
version, wrongly named OpenCobol 1.1 prerelease (or Beta) IMHO. It is a 
mature project although there is still room for improvement.
>
>
>>
>> and
>>
>> TinyCOBOL at http://tiny-cobol.sourceforge.net/
>>
>> TinyCOBOL development has now ended. COBOL is a language I considered
>> using on Unix but never actually did, so I don't know what quality and
>> functionality the compilers possess.
>>
>> I've found the following link which should give you a overview for the
>> other languages on my list:
>> http://en.wikipedia.org/wiki/List_of_compilers
>>
>> Modula-2 is not on that list however, and can be found at:
>>
>> http://www.nongnu.org/gm2/homepage.html
>>
>> That is the other language I considered, but never used so I also don't
>> know the quality of the port. Be aware that it's based on what is now
>> a old version of gcc (4.1.2).
>>
>> For Pascal, the GNU Pascal port is seriously dated, so you are probably
>> far better off with the Free Pascal port. It's been many years since I
>> last used either of them however, so my knowledge about them is not
>> current.
>>
>> Simon.
>>
>

Bernard Giroud wrote 2012-05-21 17:21:
> Le 21/05/2012 17:05, Dirk Munk a �crit :
>> Simon Clubley wrote:
>>> On 2012-05-21, Paul Sture<paul@sture.ch> wrote:
>>>> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>>>>
>>>>> On 2012-05-20, David Froble<davef@tsoft-inc.com> wrote:
>>>>>>
>>>>>> Don't know much (anything) about Unix, but with the tools on VMS some
>>>>>> very capable input functions can be implemented. What's important to
>>>>>> me is, on VMS I don't have to use "C".
>>>>>
>>>>> Strangely enough, I'm not forced to use C on Unix either. :-)
>>>>>
>>>>> My day-to-day languages on Unix include C, Ada, Python, PHP (work only;
>>>>> you won't catch me using it at home), and bash for shell scripting.
>>>>
>>>> I came across this rant about PHP over the weekend.
>>>>
>>>> "PHP: a fractal of bad design"
>>>>
>>>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>>>>
>>>>> Other languages I have used or have considered using on Unix over the
>>>>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>>>>
>>>> I was looking for a Unix COBOL a few years ago, but came up with a
>>>> blank,
>>>> though I will admit I was looking at free/cheap solutions.
>>>>
>>>
>>> The two I know about are:
>>>
>>> OpenCOBOL at http://www.opencobol.org/
>>
>> OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No
>> updates in 4 years? Seems a rather dead project to me.
>
> No. It is not ! But Roger While is working alone on a major update. In the
> meantime, Brian Tiffin has just uploaded on Sourceforge the current
> version, wrongly named OpenCobol 1.1 prerelease (or Beta) IMHO. It is a
> mature project although there is still room for improvement.
>>

Who is the target for this kind of tool?
A major company looking at porting their bet-their-business
COBOL applications from OpenVMS to Linux ?

I don't know...

Or is it just for happy-hackers that couldn't care less
if the tool suddenly dies?

Jan-Erik.


>>
>>>
>>> and
>>>
>>> TinyCOBOL at http://tiny-cobol.sourceforge.net/
>>>
>>> TinyCOBOL development has now ended. COBOL is a language I considered
>>> using on Unix but never actually did, so I don't know what quality and
>>> functionality the compilers possess.
>>>
>>> I've found the following link which should give you a overview for the
>>> other languages on my list:
>>> http://en.wikipedia.org/wiki/List_of_compilers
>>>
>>> Modula-2 is not on that list however, and can be found at:
>>>
>>> http://www.nongnu.org/gm2/homepage.html
>>>
>>> That is the other language I considered, but never used so I also don't
>>> know the quality of the port. Be aware that it's based on what is now
>>> a old version of gcc (4.1.2).
>>>
>>> For Pascal, the GNU Pascal port is seriously dated, so you are probably
>>> far better off with the Free Pascal port. It's been many years since I
>>> last used either of them however, so my knowledge about them is not
>>> current.
>>>
>>> Simon.
>>>
>>
>

Le 21/05/2012 17:31, Jan-Erik Soderholm a �crit :
> Bernard Giroud wrote 2012-05-21 17:21:
>> Le 21/05/2012 17:05, Dirk Munk a �crit :
>>> Simon Clubley wrote:
>>>> On 2012-05-21, Paul Sture<paul@sture.ch> wrote:
>>>>> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>>>>>
>>>>>> On 2012-05-20, David Froble<davef@tsoft-inc.com> wrote:
>>>>>>>
>>>>>>> Don't know much (anything) about Unix, but with the tools on VMS
>>>>>>> some
>>>>>>> very capable input functions can be implemented. What's important to
>>>>>>> me is, on VMS I don't have to use "C".
>>>>>>
>>>>>> Strangely enough, I'm not forced to use C on Unix either. :-)
>>>>>>
>>>>>> My day-to-day languages on Unix include C, Ada, Python, PHP (work
>>>>>> only;
>>>>>> you won't catch me using it at home), and bash for shell scripting.
>>>>>
>>>>> I came across this rant about PHP over the weekend.
>>>>>
>>>>> "PHP: a fractal of bad design"
>>>>>
>>>>> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
>>>>>
>>>>>> Other languages I have used or have considered using on Unix over the
>>>>>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>>>>>
>>>>> I was looking for a Unix COBOL a few years ago, but came up with a
>>>>> blank,
>>>>> though I will admit I was looking at free/cheap solutions.
>>>>>
>>>>
>>>> The two I know about are:
>>>>
>>>> OpenCOBOL at http://www.opencobol.org/
>>>
>>> OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No
>>> updates in 4 years? Seems a rather dead project to me.
>>
>> No. It is not ! But Roger While is working alone on a major update. In
>> the
>> meantime, Brian Tiffin has just uploaded on Sourceforge the current
>> version, wrongly named OpenCobol 1.1 prerelease (or Beta) IMHO. It is a
>> mature project although there is still room for improvement.
>>>
>
> Who is the target for this kind of tool?
> A major company looking at porting their bet-their-business
> COBOL applications from OpenVMS to Linux ?
>
> I don't know...

Well, the post specifically mentioned Unix, and there is
no support in OC for VMSismes. It is more suited to
either IBM downsizing, or Microfocus/Fujitsu replacement.

>
> Or is it just for happy-hackers that couldn't care less
> if the tool suddenly dies?
No more development for an FOSS project does not implies
death. Anybody (with some specific competences) can take
the baby again at any time.

Bernard.

>
> Jan-Erik.
>
>
>>>
>>>>
>>>> and
>>>>
>>>> TinyCOBOL at http://tiny-cobol.sourceforge.net/
>>>>
>>>> TinyCOBOL development has now ended. COBOL is a language I considered
>>>> using on Unix but never actually did, so I don't know what quality and
>>>> functionality the compilers possess.
>>>>
>>>> I've found the following link which should give you a overview for the
>>>> other languages on my list:
>>>> http://en.wikipedia.org/wiki/List_of_compilers
>>>>
>>>> Modula-2 is not on that list however, and can be found at:
>>>>
>>>> http://www.nongnu.org/gm2/homepage.html
>>>>
>>>> That is the other language I considered, but never used so I also don't
>>>> know the quality of the port. Be aware that it's based on what is now
>>>> a old version of gcc (4.1.2).
>>>>
>>>> For Pascal, the GNU Pascal port is seriously dated, so you are probably
>>>> far better off with the Free Pascal port. It's been many years since I
>>>> last used either of them however, so my knowledge about them is not
>>>> current.
>>>>
>>>> Simon.
>>>>
>>>
>>
>

On 2012-05-21, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
> Bernard Giroud wrote 2012-05-21 17:21:
>> Le 21/05/2012 17:05, Dirk Munk a �crit :
>>> Simon Clubley wrote:
>>>> On 2012-05-21, Paul Sture<paul@sture.ch> wrote:
>>>>> On Sun, 20 May 2012 23:51:17 +0000, Simon Clubley wrote:
>>>>>> Other languages I have used or have considered using on Unix over the
>>>>>> years include Fortran, Java, COBOL, Pascal, Modula-2 and C++.
>>>>>
>>>>> I was looking for a Unix COBOL a few years ago, but came up with a
>>>>> blank,
>>>>> though I will admit I was looking at free/cheap solutions.
>>>>>
>>>>
>>>> The two I know about are:
>>>>
>>>> OpenCOBOL at http://www.opencobol.org/
>>>
>>> OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No
>>> updates in 4 years? Seems a rather dead project to me.
>>
>> No. It is not ! But Roger While is working alone on a major update. In the
>> meantime, Brian Tiffin has just uploaded on Sourceforge the current
>> version, wrongly named OpenCobol 1.1 prerelease (or Beta) IMHO. It is a
>> mature project although there is still room for improvement.
>
> Who is the target for this kind of tool?
> A major company looking at porting their bet-their-business
> COBOL applications from OpenVMS to Linux ?
>

Paul was looking for free/low cost COBOL for Unix which is what I pointed
him to. If you want support and someone to call when things go wrong, I
am sure there are various vendors who will gladly take your money in
return for letting you run their version of COBOL on various versions
of Unix.

(As for the other language pointers, I included those in case people
were interested in the other languages I mentioned.)

Simon.

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

On May 21, 2:50=A0am, Eric Johnson <johnson.e...@gmail.com> wrote:
> On Thursday, May 17, 2012 5:33:28 PM UTC-4, JF Mezei wrote:
> > One of the many values of VMS was its rich set or proprietary system
> > services.
>
> > Any shop that has developped a lot of stuff on VMS over decades is boun=
d
> > to have developped many dependencies on VMS specific stuff.
>
> Here's a thought on a way to begin disentangling oneself from the platfor=
m. =A0It attacks the problem from a slightly different angle so it may not =
work for everyone.
>
> Consider a C program that made use of functions like SYS$CONNECT, SYS$OPE=
N, and SYS$TRNLNM. =A0It would be nice if one could just re-compile that on=
 Linux and run it. =A0But of course, you can't do that. =A0If it was that e=
asy, these threads wouldn't exist here on comp.os.vms.
>
> Being rhetorical here, why can't one just recompile it? =A0Well, for star=
ters the compiler won't be able to find the include files you need. =A0File=
s like rmsdef.h, namdef.h, fabdef.h, etc won't be there.
>
> With a little bit of effort, you can get those to be accepted by gcc near=
ly as is. =A0You have to deal with a few common issues such as __int64 and =
pragmas for packing, but beyond that, they are just straight up headers. =
=A0There's nothing that unnatural about them apart from Digital's fondness =
for the dollar sign.
>
> But that doesn't satisfy the linker now does it? =A0The linker of course =
asks for an implementation to SYS$TRNLNM and whatever else you might have c=
alled from starlet.h. =A0So what do you do?
>
> Instead of attempting to implement your own solution of SYS$TRNLNM, why n=
ot forward that invocation back to a peer process on VMS? =A0Same for SYS$C=
ONNECT, SYS$OPEN, or LBR$GET_MODULE or any of the other common user mode pi=
eces of functionality.
>
> If you get the native headers to compile on linux, it's fairly easy to wr=
ite code to perform a deep copy of the entire structures that are passed in=
to those routines.
>
> The idea here is a bit like an RPC model. =A0One would completely replica=
te the function call such that the runtime on linux is completely unaware t=
hat the execution is on linux rather than on VMS. =A0But the underlying SYS=
$ functionality is still performed on VMS. =A0Everything is copied back inc=
luding the return value.
>
> I realize there are a lot of "yeah, buts" to be placed here. =A0I'll pree=
mptively enumerate some of them.
>
> 1) But what about ASTs?
> 2) But what about network performance/latency?
> 3) What about C library routines (eg: fopen, read, stat, etc).
> 4) How should the vms server process match up to the client linux process=
?
> 5) But why would you do this??!! =A0How does this help??
>
> For now, I'll just address (5) and address other topics if there's really=
 interest in the thought here. =A0And these are nothing more than thoughts.=
 =A0I have no product to offer and no intent to do so. =A0It's more of an i=
ntellectual curiosity to see if the ideas are useful.
>
> As I see it, there are really two issues confounding VMS systems. =A0Firs=
t, the Itanium CPU is moribund. =A0Regardless of HP's announcement, it's cl=
ear the x86 has surpassed it and will continue to be the future for the mai=
nstream commodity world. =A0Second, VMS is effectively at the end of the li=
ne. =A0Tragic, but true.
>
> It's understandable that those problems get lumped together, but it might=
 be useful to see them as separate problems.
>
> I think I can articulate an approach that at least enables you to move yo=
ur CPU load off of VMS while mapping out the nature of your dependency to V=
MS. =A0If one can successfully remote the access to VMS, you are turning yo=
ur VMS nodes into a sophisticated "SAN head". =A0Once all of the execution =
is then on another OS, you can then begin the task of redirecting those pie=
ces to other solutions.
>
> One of the features of VMS that I think a lot of people admire is how eas=
y it is to just "add a node" to the cluster. =A0It's a great way to expand =
your capacity. =A0It also makes it easier to migrate to newer hardware. =A0=
One can bring in the newer nodes and then slowly retire the older ones.
>
> I think an effective migration strategy off of VMS has to consist of find=
ing a way to get a "linux node" to be as near "peer like" as possible in th=
at VMS cluster. =A0Linux processes would have to be brokered through anothe=
r process on a VMS node, but I think one can get very far with this approac=
h and then ultimately cut the cord.
>
> The approach doesn't work for everyone. =A0I think it works best for a sy=
stem that is still growing and would need greater performance and capacity =
in the future. =A0Systems that are mature should probably stay where they a=
re. =A0Also, it's an approach that would require one to have access to most=
 of the code too.
>
> Rather than write a tome on the topic, I thought I'd quickly sketch out t=
he idea, and see if there was interest in fleshing it out more.
>
> EJ

Is there not some serious wheel-reinventing being looked at here? OK,
some organisations do prefer reinventing from scratch rather than
purchasing, but...

"Consider a C program that made use of functions like SYS$CONNECT, SYS
$OPEN, and SYS$TRNLNM.  It would be nice if one could just re-compile
that on Linux and run it.  But of course, you can't do that.  If it
was that easy, these threads wouldn't exist here on comp.os.vms."

Sector7 has already been mentioned once in this thread. I only know
what I've read here and elsewhere, but their stuff would appear to
cover that, and a whole lot more too, if it's still around - I believe
their UK subsidiary company went away, but that doesn't mean they're
not still around. No idea what Sector7's costs or quality are, but I
know what re-inventing the wheel usually costs (and what its impact on
support is).

"The idea here is a bit like an RPC model. "

Fine idea. Then add a few other essentials such as generic security
services, location brokers and the like. In fact why not set the
wayback machine to the 1990s and call it CORBA (or, maybe less likely,
DCE)?

Bear in mind that for a lot of folks, whether it's right or it's wrong
according to contributors here, there is a short term goal to get off
VAX, Alpha, and Itanium, and a longer (but not long) term goal to get
completely off VMS regardless of the business impact of lost VMS
functionality e.g. by abandoning VMS-specific functionality such as
decent security, decent clustering, etc, by redesigning the
application from scratch for a commodity database on a commodity OS
(or going to IBM in some cases).

In view of the relatively short lifetime of the mixed OS
implementation, any investment in retaining VMS (real or emulated) may
need a reasonably short payback time in comparison with traditional
VMS projects (though maybe not in comparison with MS-centric projects
where a three year lifecycle seems remarkably common).

Not saying what you are suggesting is a bad idea (it isn't, at least
on paper), but wondering if there are particular reasons why you are
thinking of starting from a low level of abstraction when higher level
more functional stuff apparently already exists, especially if there
is a real budget for the project?

Dirk Munk wrote:

> OpenCobol 1.0 dates from 2008, OpenCobol 1.1 beta dates from 2007. No 
> updates in 4 years? Seems a rather dead project to me.


Out of curiosity, when was the VMS Cobol
on Alpha or Ia64 last updated ?

John Wallace wrote:

> Bear in mind that for a lot of folks, whether it's right or it's wrong
> according to contributors here, there is a short term goal to get off
> VAX, Alpha, and Itanium, and a longer (but not long) term goal to get
> completely off VMS regardless of the business impact of lost VMS
> functionality e.g. 

I view this differently.

Starting on the day you decide to downsize VMS out of existance, any new
projects go on the target platform. This is where growth happens from
that point on.  This may require some interfaces with legacy VMS to be
built so new apps on Linux can talk to old all on VMS.

Then, you slowly migrate apps from VMS to Linux one by one. As you
reduce the load on the VMS hardware by moving apps one by one, you make
room for growth in traffic for remaining apps.

If you start NOW to plan this move, then you have plenty of time to
execute it, plenty of time to model/shape your new architecture
properly, setup proper procedure for the system management aspects
(backups, recovery, database replication of hardware based disk
mirroring to replace volume shadowing etc).

And if you start now, you still have one or two speed bumps coming for
IA64 if needed.

On May 21, 7:01=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> John Wallace wrote:
> > Bear in mind that for a lot of folks, whether it's right or it's wrong
> > according to contributors here, there is a short term goal to get off
> > VAX, Alpha, and Itanium, and a longer (but not long) term goal to get
> > completely off VMS regardless of the business impact of lost VMS
> > functionality e.g.
>
> I view this differently.
>
> Starting on the day you decide to downsize VMS out of existance, any new
> projects go on the target platform. This is where growth happens from
> that point on. =A0This may require some interfaces with legacy VMS to be
> built so new apps on Linux can talk to old all on VMS.
>
> Then, you slowly migrate apps from VMS to Linux one by one. As you
> reduce the load on the VMS hardware by moving apps one by one, you make
> room for growth in traffic for remaining apps.
>
> If you start NOW to plan this move, then you have plenty of time to
> execute it, plenty of time to model/shape your new architecture
> properly, setup proper procedure for the system management aspects
> (backups, recovery, database replication of hardware based disk
> mirroring to replace volume shadowing etc).
>
> And if you start now, you still have one or two speed bumps coming for
> IA64 if needed.

That approach may well apply where IT policy and projects are driven
by business need. My point was in reference to the IT departments
we've surely all come across where the policy is driven by fashion and
comfort zones:
IT: "if it's not Wintel, we want it out, because it's not strategic"
Business: "based on our product evaluations, product XYZ continues to
be the best value for the business, and indeed the only product that
does [PQR] but it does not run on Window boxes"
IT: "the policy says Dell and Windows"
Business: "why?"
IT: "because... because Daddy says so?" [etc]

John Wallace wrote:

> IT: "if it's not Wintel, we want it out, because it's not strategic"
> Business: "based on our product evaluations, product XYZ continues to
> be the best value for the business, and indeed the only product that
> does [PQR] but it does not run on Window boxes"

I have seen this at a bank. Dept chose a VAX solution for SWIFT funds
transfers because of the functionality not available on other platforms
(mostly at application level).

Palmer told SWIFT to move from VMS, and SWIFT announced to their
customers to start to plan to move away from VMS.

At the bank, the IT folks were happy to finaly get rid of the VAX. But
it took years before they were able to find/build a solution with equal
capabilities. (with acceptable compromises for disaster tolerance).

The thing is that once you know that you will have to move from one
platform, you need to start planning this years ahead because you need
to make a considerate choice of platform, find middleware that will
approximate your currrent functionlity etc etc.

You don't just hire some geeks and tell them to port this to Linux.

On 5/16/2012 5:07 AM, JF Mezei wrote:
> Not every VMS shop is large enough to be fortunate enough to have the
> privilege of having a contact within HP.

Every VMS shop, regardless of size, is large enough to e-mail 
OpenVMS.Programs@hp.com, and the group manning that e-mail address seems 
to be very responsive.

If I understand your ideas, it implies that you'd still have VMS.

My question is, if you still have VMS, then why are you messing with the other "junk"?

"JF Mezei"  wrote in message 
news:4fba809b$0$3977$c3e8da3$b23f186d@news.astraweb.com...

>Out of curiosity, when was the VMS Cobol
>on Alpha or Ia64 last updated ?

Not sure about Alpha, but the Itanium version has been updated to V3.0 
within the past year.  No new features if I remember correctly, but several 
bugfixes were included.  It might be one of the most recent compilers to be 
updated.  For instance, Pascal hasn't been updated since I left the project.

John 

In article <jpe6l4$cl6$1@usenet01.boi.hp.com>, Keith Parris <keithparris_deletethis@yahoo.com> writes:
>On 5/16/2012 5:07 AM, JF Mezei wrote:
>> Not every VMS shop is large enough to be fortunate enough to have the
>> privilege of having a contact within HP.
>
>Every VMS shop, regardless of size, is large enough to e-mail 
>OpenVMS.Programs@hp.com, and the group manning that e-mail address seems 
>to be very responsive.

....but is that "support"?  Unless there is feedback from and resolution to
issues reported through this mechanism, it might has well be sending email
to the absolute elsewhere.

FWIW, I've gone through the formal channels for three bugs that still have
not been resolved/fixed.  One has caused me to have to kludge a workaround
in my code because of a day-one bug in Itanium code.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

John Wallace wrote:
> On May 21, 7:01 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> John Wallace wrote:
>>> Bear in mind that for a lot of folks, whether it's right or it's wrong
>>> according to contributors here, there is a short term goal to get off
>>> VAX, Alpha, and Itanium, and a longer (but not long) term goal to get
>>> completely off VMS regardless of the business impact of lost VMS
>>> functionality e.g.
>> I view this differently.
>>
>> Starting on the day you decide to downsize VMS out of existance, any new
>> projects go on the target platform. This is where growth happens from
>> that point on.  This may require some interfaces with legacy VMS to be
>> built so new apps on Linux can talk to old all on VMS.
>>
>> Then, you slowly migrate apps from VMS to Linux one by one. As you
>> reduce the load on the VMS hardware by moving apps one by one, you make
>> room for growth in traffic for remaining apps.
>>
>> If you start NOW to plan this move, then you have plenty of time to
>> execute it, plenty of time to model/shape your new architecture
>> properly, setup proper procedure for the system management aspects
>> (backups, recovery, database replication of hardware based disk
>> mirroring to replace volume shadowing etc).
>>
>> And if you start now, you still have one or two speed bumps coming for
>> IA64 if needed.
> 
> That approach may well apply where IT policy and projects are driven
> by business need. My point was in reference to the IT departments
> we've surely all come across where the policy is driven by fashion and
> comfort zones:
> IT: "if it's not Wintel, we want it out, because it's not strategic"
> Business: "based on our product evaluations, product XYZ continues to
> be the best value for the business, and indeed the only product that
> does [PQR] but it does not run on Window boxes"
> IT: "the policy says Dell and Windows"
> Business: "why?"
> IT: "because... because Daddy says so?" [etc]

Best solution, fire IT ....

It really gets me frustrated when IT people attempt to drive changes they feel is better 
for their resume than what is good for the company.

I encountered a "we want to be a Microsoft only shop", and they do not exist today. 
Darwin wins a few now and then.

On 5/16/2012 1:08 AM, Eric Smith wrote:
> So the writing appears to be on the wall, and after scouring the web
> and chatting to colleagues, I've finally been convinced that our large
> business-critical application currently running on OpenVMS (IA64) has
> to be moved to something that will be supported fifteen years down the
> line.

Eric, what CPU architecture are you running on today?

Based on past history, OpenVMS itself is very likely to still be 
supported fifteen years down the road. Martin Fink of HP has publicly 
committed to "more than 10 years" of support 
(http://h30507.www3.hp.com/t5/Mission-Critical-Computing-Blog/HP-puts-customers-first-and-remains-committed-to-Integrity/ba-p/89983), 
and he's most likely referring there to hardware support. Software 
support typically goes on for much longer. For example, the last VAX 
system was sold in 2000, and according to 
http://h71000.www7.hp.com/openvms/openvms_supportchart.html HP still 
supports OpenVMS on VAX 22 years later.

So hardware support is the crucial item. HP officially supports hardware 
for a minimum of 5 years after last sale, but the actual support life is 
typically much longer (and based on availability of spare parts). 
Although "officially" HP stopped selling Alpha systems in 2007 (upgrades 
until 2008), I'm working with a customer who just got two new-to-them 
GS-1280 32-CPU systems from HP Financial Services recently (this 
Spring). (And some customers choose to get around the potential end to 
hardware support by moving to emulation technology on modern hardware 
platforms.)

If you're on Itanium, things are even better. Even if Kittson or 
Kittson+ turns out to be the last Itanium CPU generation developed by 
Intel, you should easily be able to run machines based on those CPUs out 
to at least 15 years from now. Press reports quote an Intel rep. saying 
HP has access to Itanium microprocessors from Intel through at least 
2022, and can extend that even longer if they wish 
(http://www.theinquirer.net/inquirer/news/2170327/hp-force-intel-develop-itanium-2022). 
So if HP can sell Itanium-based systems through at least 2022, and 
there's a minimum of 5 years of hardware support after the last sale, 
that's your 15 years right there.

So there doesn't seem to be a need for panic at this point.

Keith Parris wrote:

> So there doesn't seem to be a need for panic at this point.

While I have no probem believing that HP will continue to accept support
dollars for both hardware and software, the issue becomes that of a
stale operating system in maintenance mode with no new or updated
applications on it.

Currently, HP and its employees continue to pretend all is well and that
both IA64 and VMS are actively developped.


While the market has accepted that IA64 is dead, HP is still in denial
mode (and thus its employees who must toe the corporate line)

Unless employees are allowed to dicuss plans to port VMS to the 8086,
the only possible outcome is that VMS and HP-UX are coming to a dead end
 with the end of IA64.

While HP might provide an IA64 emulator to run on 8086 servers, this
does not mean that VMS or HP-UX will continue to be actively developped
with new features and applications. Such emulator would exist solely to
help customers move to new servers.

On Mon, 21 May 2012 16:59:24 +0000, Simon Clubley wrote:

> Paul was looking for free/low cost COBOL for Unix which is what I
> pointed him to. If you want support and someone to call when things go
> wrong, I am sure there are various vendors who will gladly take your
> money in return for letting you run their version of COBOL on various
> versions of Unix.

To put this into context Simon, about 4 years ago someone was asking for 
help getting some tax tables into Excel.  I took a look at the file 
layouts and they screamed COBOL at me.  As proof of concept, I wrote a 
piece of COBOL using my Hobbyist Alpha (it took me all of 15 minutes* and 
I got a clean compile on the first pass), but I didn't feel comfortable 
using that because there was a large chance it could turn into a 
commercial project.

* obviously a proper product would take somewhat longer than 15 minutes, 
but it proved that using COBOL was the easiest way to deal with the data. 
26 sets of tax tables, one for each canton in Switzerland, so automation 
had to be far easier than slogging through 26 Excel imports.

So I was looking for a COBOL compiler which I could run on my OS X system 
where I wasn't constrained by the Hobbyist licence.

Since then, I've got the hang of the freeware concepts and would take 
that route instead, but at the time I was having difficulty with the idea 
of working for free and seeing others make money out of my work.

> (As for the other language pointers, I included those in case people
> were interested in the other languages I mentioned.)

Much appreciated. Thanks.

-- 
Paul Sture

> My question is, if you still have VMS, then=20
> why are you messing with the other "junk"?=20

I see a couple of values with the approach.=20

First, one could begin to draw benefit from the rapid pace of x86 performan=
ce gains without first disentangling oneself from the VMS APIs that you mig=
ht be leveraging.  It would be like an out of box CPU upgrade. =20

Second, the migration approach could be done with less rearchitecting of a =
current system.=20

Third, the migration approach avoids flag day cutovers. To me, flag day cut=
overs are the worst because you don't really know what the new world is lik=
e until you are there but when you are there, you are committed and going b=
ack is no more appealing than staying.

For me the main motivation of the idea is to provide an avenue to capture t=
he gains offered by the x86 world which has (to me) clearly surpassed the i=
tanium. I would think that systems that are not hungry for CPU upgrades may=
 not see value in the approach.=20

I suspect the other half of your question is - then how does one finally cu=
t ties to VMS. But wasn't 100% if that was the question or why begin to go =
towards this weird hybrid run time with a foot in both worlds.=20

EJ

In article <jpecna$n47$1@usenet01.boi.hp.com>, Keith Parris <keithparris_deletethis@yahoo.com> writes:

> For example, the last VAX 
> system was sold in 2000, and according to 
> http://h71000.www7.hp.com/openvms/openvms_supportchart.html HP still 
> supports OpenVMS on VAX 22 years later.

   Typo?  12 when I learned arithmatic.  Which is still pretty
   impressive when you consider how long HP supported 68K HP-UX system
   and thier MPE systems.

   Or rather, when you consider how short.

In article <qNWdnaQA98NTPifSnZ2dnUVZ_vGdnZ2d@insightbb.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
> 
> Not sure about Alpha, but the Itanium version has been updated to V3.0 
> within the past year.  No new features if I remember correctly, but several 
> bugfixes were included.  It might be one of the most recent compilers to be 
> updated.  For instance, Pascal hasn't been updated since I left the project.

   A .0 release that is just bug fixes?

JF Mezei wrote:
> Keith Parris wrote:
> 
>> So there doesn't seem to be a need for panic at this point.
> 
> While I have no probem believing that HP will continue to accept support
> dollars for both hardware and software, the issue becomes that of a
> stale operating system in maintenance mode with no new or updated
> applications on it.
> 
> Currently, HP and its employees continue to pretend all is well and that
> both IA64 and VMS are actively developped.
> 
> 
> While the market has accepted that IA64 is dead, HP is still in denial
> mode (and thus its employees who must toe the corporate line)
> 
> Unless employees are allowed to dicuss plans to port VMS to the 8086,
> the only possible outcome is that VMS and HP-UX are coming to a dead end
>  with the end of IA64.

It might be more reasonable to discuss specifics instead of generalities, or, perhaps not.

I've asked myself the question, what would it really take?

"I'd guess that would probably involve thirty senior engineers dedicated to design, 
porting the kernel and related pieces, porting the compilers, plus all of the other 
engineers with specific responsibilities for various components dealing with their own 
pieces."

(Wasn't me, but I'm not going to attribute private correspondence to anyone.)

So, what is the cost of 30 senior engineers for say 4 years?  Since I don't know what a 
"senior engineer" salary might be, I'll just throw out a quarter million per year, keeps 
the math easy, which would come to 30 million for 4 years.

While 30 million would be a nice tidy sum for me, or you, I doubt it's unsurmountable for 
a large corporation.

So unless VMS is considered rather worthless, which I personally will not accept, then we 
perhaps have some rough idea of the cost.  As to who might wish to foot the bill, well, 
that could be interesting.

Perhaps some group of large users might consider it less costly to pay for the port to x86 
than to migrate their applications to another platform.  Perhaps VMS bigots could 
contribute to a porting fund.  I'm sure others could come up with all kinds of ideas.  If 
it wasn't strictly HP, then perhaps a more user friendly list of supported hardware might 
occur.

One consideration might be whether HP wants VMS to survive.  Would they allow such a port 
of their property.  Perhaps we all write our congressmen and have the US government "lean" 
on HP a bit.  Other wild-ass ideas are solicited ....

As for the benefits.  The way I see it, x86 is going to be with us for a while.  It's 
entrenched enough that I cannot imagine (though I think it's possible and will happen in 
time) what it would take to replace x86.  So, VMS on x86 would be as viable as anything 
else for the next 25 years.

I've got to wonder what HP will pay to develop their x86 based SuperDomes or whatever.

In article <jpecna$n47$1@usenet01.boi.hp.com>, Keith Parris
<keithparris_deletethis@yahoo.com> writes: 

> Based on past history, OpenVMS itself is very likely to still be 
> supported fifteen years down the road. Martin Fink of HP has publicly 
> committed to "more than 10 years" of support 

While I agree with all of your post, and am still using VMS LONG after
most people said it would be dead, what one really needs is ammunition
against arguments from people who trot out other public commitments from
the past in relation to VMS, not all of which have been honoured. 

"Bob Koehler"  wrote in message 
news:sOD49au7adpM@eisner.encompasserve.org...

In article <qNWdnaQA98NTPifSnZ2dnUVZ_vGdnZ2d@insightbb.com>, "John Reagan" 
<johnrreagan@earthlink.net> writes:
>
> Not sure about Alpha, but the Itanium version has been updated to V3.0
> within the past year.  No new features if I remember correctly, but 
> several
> bugfixes were included.  It might be one of the most recent compilers to 
> be
> updated.  For instance, Pascal hasn't been updated since I left the 
> project.

   A .0 release that is just bug fixes?

Yep.  We were at V2.9 and didn't have anywhere else to go.  The longstanding 
debate is what comes after 9.  Is that V2.91 or V2.A or something else. 
PCSI is a little more forgiving, but VMSINSTAL tied our hands for years. 
Also, much of the internal paperwork for submitting a product didn't like 
either ".91", ".A", ".9.1", etc.

John 

On May 22, 11:46 am, David Froble <da...@tsoft-inc.com> wrote:
> JF Mezei wrote:
> > Keith Parris wrote:
>
> >> So there doesn't seem to be a need for panic at this point.
>
> > While I have no probem believing that HP will continue to accept support
> > dollars for both hardware and software, the issue becomes that of a
> > stale operating system in maintenance mode with no new or updated
> > applications on it.
>
> > Currently, HP and its employees continue to pretend all is well and that
> > both IA64 and VMS are actively developped.
>
> > While the market has accepted that IA64 is dead, HP is still in denial
> > mode (and thus its employees who must toe the corporate line)
>
> > Unless employees are allowed to dicuss plans to port VMS to the 8086,
> > the only possible outcome is that VMS and HP-UX are coming to a dead end
> >  with the end of IA64.
>
> It might be more reasonable to discuss specifics instead of generalities, or, perhaps not.
>
> I've asked myself the question, what would it really take?
>
> "I'd guess that would probably involve thirty senior engineers dedicated to design,
> porting the kernel and related pieces, porting the compilers, plus all of the other
> engineers with specific responsibilities for various components dealing with their own
> pieces."
>
> (Wasn't me, but I'm not going to attribute private correspondence to anyone.)
>
> So, what is the cost of 30 senior engineers for say 4 years?  Since I don't know what a
> "senior engineer" salary might be, I'll just throw out a quarter million per year, keeps
> the math easy, which would come to 30 million for 4 years.
>
> While 30 million would be a nice tidy sum for me, or you, I doubt it's unsurmountable for
> a large corporation.
>
> So unless VMS is considered rather worthless, which I personally will not accept, then we
> perhaps have some rough idea of the cost.  As to who might wish to foot the bill, well,
> that could be interesting.
>
> Perhaps some group of large users might consider it less costly to pay for the port to x86
> than to migrate their applications to another platform.  Perhaps VMS bigots could
> contribute to a porting fund.  I'm sure others could come up with all kinds of ideas.  If
> it wasn't strictly HP, then perhaps a more user friendly list of supported hardware might
> occur.
>
> One consideration might be whether HP wants VMS to survive.  Would they allow such a port
> of their property.  Perhaps we all write our congressmen and have the US government "lean"
> on HP a bit.  Other wild-ass ideas are solicited ....
>
> As for the benefits.  The way I see it, x86 is going to be with us for a while.  It's
> entrenched enough that I cannot imagine (though I think it's possible and will happen in
> time) what it would take to replace x86.  So, VMS on x86 would be as viable as anything
> else for the next 25 years.
>
> I've got to wonder what HP will pay to develop their x86 based SuperDomes or whatever.


I think you've touched upon some of the reasons but if we make the
really off-the-wall presumption that HP's management has a forward
looking view of technology, the real question is: What can VMS do that
other platforms can't do and will never be able to do? The capability
curve of other platforms is rising rapidly. Maybe the people driving
VMS (whoever they are now) have looked around them and seen the
future. That's something our long-departed drivers failed to do, but
if they had we probably wouldn't be worrying about VMS today.

Even the cursed Windows Servers can now do multi-site availability and
load-balancing clustering quite well. The x86 platform is growing in
strength and is likely to continue. My favorite "best and most secure
platform in the world" is fighting a losing battle and that makes me
sad, but reality often does that.

A little off-topic, maybe, but it isn't hard to see a future without
binary computers. If HP were close to their projections we should be
seeing memristor memory devices in 2013, and that technology could
make binary as obsolete as vacuum tubes ("valves" for the UK folks).
Where would you spend your money if you were HP?

Doug Phillips wrote:

> A little off-topic, maybe, but it isn't hard to see a future without
> binary computers. If HP were close to their projections we should be
> seeing memristor memory devices in 2013, and that technology could
> make binary as obsolete as vacuum tubes ("valves" for the UK folks).
> Where would you spend your money if you were HP?

You're assuming that Mark Hurd didn't cut that project like he did much
of the HP R&D.

With HP out of the chip business, what would HP really do with them
memristors ? HP might do like it did with the rest of its chip business:
donate it to Intel.

On May 22, 1:52=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Doug Phillips wrote:
> > A little off-topic, maybe, but it isn't hard to see a future without
> > binary computers. If HP were close to their projections we should be
> > seeing memristor memory devices in 2013, and that technology could
> > make binary as obsolete as vacuum tubes ("valves" for the UK folks).
> > Where would you spend your money if you were HP?
>
> You're assuming that Mark Hurd didn't cut that project like he did much
> of the HP R&D.
>

Correct. My suspicion, though, and it's based on the assumption that
MH wasn't completely stupid, is that some of the cuts might have been
made to help the memristor project... at least that would seem the
wise thing to do. Invest R&D money to grow the future. But as another
frequent poster is fond of saying, "I know nothing."

> With HP out of the chip business, what would HP really do with them
> memristors ? HP might do like it did with the rest of its chip business:
> donate it to Intel.

I don't know what HP is doing or will do. Shirley Someone knows,
though, but she ain't talkin' ;-)

On 2012-05-22 10:56, John Reagan wrote:
>
>
> "Bob Koehler" wrote in message
> news:sOD49au7adpM@eisner.encompasserve.org...
>
> In article <qNWdnaQA98NTPifSnZ2dnUVZ_vGdnZ2d@insightbb.com>, "John
> Reagan" <johnrreagan@earthlink.net> writes:
>>
>> Not sure about Alpha, but the Itanium version has been updated to V3.0
>> within the past year. No new features if I remember correctly, but
>> several
>> bugfixes were included. It might be one of the most recent compilers
>> to be
>> updated. For instance, Pascal hasn't been updated since I left the
>> project.
>
> A .0 release that is just bug fixes?
>
> Yep. We were at V2.9 and didn't have anywhere else to go. The
> longstanding debate is what comes after 9. Is that V2.91 or V2.A or
> something else. PCSI is a little more forgiving, but VMSINSTAL tied our
> hands for years. Also, much of the internal paperwork for submitting a
> product didn't like either ".91", ".A", ".9.1", etc.

What about V2.10? :-)

	Johnny

In article <jpgftk$te5$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
> I've asked myself the question, what would it really take?
> 
> "I'd guess that would probably involve thirty senior engineers dedicated to design, 
> porting the kernel and related pieces, porting the compilers, plus all of the other 
> engineers with specific responsibilities for various components dealing with their own 
> pieces."

   What did it take to port from Alpha to IA64?  Parts should be easier
   since Alpha had a few features to make VMS work, like PALcode, and
   IA64 didn't.  A Macro-32 compiler might be harder since IA32 is CISC,
   so you don't have the one-to-many relationship between VAX
   instructions and IA32 instructions that you have with VAX to RISC or
   EPIC.

   But that latter is a matter of generating efficient code, just
   getting code to work should not be such a big deal.  A 32 bit add
   instruction on VAX has different side affects than the same
   instruction on IA32, but you can still add additional instructions
   to get the side effects when needed, just like RISC.

On Wed, 23 May 2012 00:11:46 -0700, Johnny Billquist wrote:

> On 2012-05-22 10:56, John Reagan wrote:
>>
>>
>> "Bob Koehler" wrote in message
>> news:sOD49au7adpM@eisner.encompasserve.org...
>>
>> In article <qNWdnaQA98NTPifSnZ2dnUVZ_vGdnZ2d@insightbb.com>, "John
>> Reagan" <johnrreagan@earthlink.net> writes:
>>>
>>> Not sure about Alpha, but the Itanium version has been updated to V3.0
>>> within the past year. No new features if I remember correctly, but
>>> several
>>> bugfixes were included. It might be one of the most recent compilers
>>> to be
>>> updated. For instance, Pascal hasn't been updated since I left the
>>> project.
>>
>> A .0 release that is just bug fixes?
>>
>> Yep. We were at V2.9 and didn't have anywhere else to go. The
>> longstanding debate is what comes after 9. Is that V2.91 or V2.A or
>> something else. PCSI is a little more forgiving, but VMSINSTAL tied our
>> hands for years. Also, much of the internal paperwork for submitting a
>> product didn't like either ".91", ".A", ".9.1", etc.
> 
> What about V2.10? :-)
> 
> 	Johnny

Apple tried that with OS X Tiger.

IIRC 10.4.10 broke the version number definition in the source header 
files, and they didn't catch it until after it had been released.



-- 
Paul Sture

"Bob Koehler"  wrote in message 
news:0kp36lkfTvGW@eisner.encompasserve.org...



>   What did it take to port from Alpha to IA64?  Parts should be easier
>   since Alpha had a few features to make VMS work, like PALcode, and
>   IA64 didn't.  A Macro-32 compiler might be harder since IA32 is CISC,
>   so you don't have the one-to-many relationship between VAX
>   instructions and IA32 instructions that you have with VAX to RISC or
>   EPIC.

>   But that latter is a matter of generating efficient code, just
>   getting code to work should not be such a big deal.  A 32 bit add
>   instruction on VAX has different side affects than the same
>   instruction on IA32, but you can still add additional instructions
>   to get the side effects when needed, just like RISC.

Again, don't forget that you need BLISS and C just for the OS and you'll 
want all the rest of the compilers for the customer base.  GEM's old x86 
target was 32-bit only, just did the things that Visual Fortran required, 
and generated Windows object files and Windows debugging info.  All of that 
would need fixing.  And switching to some other code generator (gcc, LLVM, 
open64) might work but I'd have to think about it.

As I've mention before, the smaller register set (as compared to Itanium and 
Alpha) causes more rework for facilities like RMS that currently use lots of 
GLOBAL REGISTERs to pass around implicit arguments between routines.  Since 
the Alpha and Itanium compilers were able to make it all work (there is some 
funky spilling involving GLOBAL REGISTERs on Itanium and corresponding 
funky-ness in the unwind descriptors and LIB$ calling standard routines to 
cover it up), nobody had ever attempted to clean up all those RMS internal 
interfaces.  I suspect a move to x86 would force that issue.  It would also 
impact user code as well (any Macro that specified non-standard arguments to 
..CALL_ENTRY or .CALL_LINKAGE).

So while the Itanium port only required touching of 5% of the code (I think 
that's the number that Clair Grant used to quote), I would guess the number 
would go up to at least 25% of the code for x86 (including some rather 
important code).

On the bright side, x86 doesn't have NaTs. :)

On Wed, 23 May 2012 10:40:21 -0400, John Reagan wrote:

> Again, don't forget that you need BLISS and C just for the OS and you'll
> want all the rest of the compilers for the customer base.  GEM's old x86
> target was 32-bit only, just did the things that Visual Fortran
> required, and generated Windows object files and Windows debugging info.
>  All of that would need fixing.  And switching to some other code
> generator (gcc, LLVM, open64) might work but I'd have to think about it.

ISTR some standard utilities were written in Pascal and possibly other 
languages.  I used to see the occasional stack dump which revealed the 
language.



-- 
Paul Sture

On Wednesday, May 23, 2012 11:21:07 AM UTC-4, Paul Sture wrote:
> On Wed, 23 May 2012 10:40:21 -0400, John Reagan wrote:
> 
> > Again, don't forget that you need BLISS and C just for the OS and you'll
> > want all the rest of the compilers for the customer base.  GEM's old x86
> > target was 32-bit only, just did the things that Visual Fortran
> > required, and generated Windows object files and Windows debugging info.
> >  All of that would need fixing.  And switching to some other code
> > generator (gcc, LLVM, open64) might work but I'd have to think about it.
> 
> ISTR some standard utilities were written in Pascal and possibly other 
> languages.  I used to see the occasional stack dump which revealed the 
> language.
> 
> 
> 
> -- 
> Paul Sture

Monitor is a good example.  It was written in PL/I and on alpha runs as a "VEST'd" image.

Dan

In article <SOOdnWdNnfJGayHSnZ2dnUVZ_t2dnZ2d@insightbb.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
> 
> Again, don't forget that you need BLISS and C just for the OS and you'll 
> want all the rest of the compilers for the customer base.  GEM's old x86 
> target was 32-bit only, just did the things that Visual Fortran required, 
> and generated Windows object files and Windows debugging info.  All of that 
> would need fixing.  And switching to some other code generator (gcc, LLVM, 
> open64) might work but I'd have to think about it.

   I don't see generating compilers for IA32 as any more difficult than
   generating compilers for Alpha or IA64.  There are plenty of examples
   of code generators for IA32 (and IA32-64).
 
> As I've mention before, the smaller register set (as compared to Itanium and 
> Alpha) causes more rework for facilities like RMS that currently use lots of 
> GLOBAL REGISTERs to pass around implicit arguments between routines.

   GLOBAL REGISTERS can be replaced with ordinary variables.  VAXen didn't 
   have all those registers and it survived.  There may be a minor
   performance hit.

On May 23, 8:22=A0am, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <jpgftk$te...@dont-email.me>, David Froble <da...@tsoft-inc.co=
m> writes:
> > I've asked myself the question, what would it really take?
>
> > "I'd guess that would probably involve thirty senior engineers dedicate=
d to design,
> > porting the kernel and related pieces, porting the compilers, plus all =
of the other
> > engineers with specific responsibilities for various components dealing=
 with their own
> > pieces."
>
> =A0 =A0What did it take to port from Alpha to IA64? =A0Parts should be ea=
sier
> =A0 =A0since Alpha had a few features to make VMS work, like PALcode, and
> =A0 =A0IA64 didn't. =A0A Macro-32 compiler might be harder since IA32 is =
CISC,
> =A0 =A0so you don't have the one-to-many relationship between VAX
> =A0 =A0instructions and IA32 instructions that you have with VAX to RISC =
or
> =A0 =A0EPIC.
>
> =A0 =A0But that latter is a matter of generating efficient code, just
> =A0 =A0getting code to work should not be such a big deal. =A0A 32 bit ad=
d
> =A0 =A0instruction on VAX has different side affects than the same
> =A0 =A0instruction on IA32, but you can still add additional instructions
> =A0 =A0to get the side effects when needed, just like RISC.

I imagine you've read it, Bob, but for those who haven't, the OpenVMS
Technical Journal-v6 -Porting OpenVMS to HP Integrity Servers- is
worth reading (and rereading if it's been a while.)

John Reagan wrote:
> 
> Again, don't forget that you need BLISS and C just for the OS and you'll 
> want all the rest of the compilers for the customer base.  GEM's old x86 
> target was 32-bit only, just did the things that Visual Fortran 
> required, and generated Windows object files and Windows debugging 
> info.  All of that would need fixing.  And switching to some other code 
> generator (gcc, LLVM, open64) might work but I'd have to think about it.

I seem to recall that there have been some things in the past that sort of never "made 
it".  Macro 32 and maybe Bliss, to implement RDB on windows, or something like that.  It 
has been maybe 10+ years so memories may not be 100% accurate.  But such stories seem to 
indicate that Macro-32, Bliss, and such can be implemented on x86.  I can guess that 
something such as SimH which emulates in software the VAX instruction set might be a more 
difficult task.  As for C, unfortunately, we already got several flavors of that.

> As I've mention before, the smaller register set (as compared to Itanium 
> and Alpha) causes more rework for facilities like RMS that currently use 
> lots of GLOBAL REGISTERs to pass around implicit arguments between 
> routines.  Since the Alpha and Itanium compilers were able to make it 
> all work (there is some funky spilling involving GLOBAL REGISTERs on 
> Itanium and corresponding funky-ness in the unwind descriptors and LIB$ 
> calling standard routines to cover it up), nobody had ever attempted to 
> clean up all those RMS internal interfaces.  I suspect a move to x86 
> would force that issue.  It would also impact user code as well (any 
> Macro that specified non-standard arguments to .CALL_ENTRY or 
> .CALL_LINKAGE).
> 
> So while the Itanium port only required touching of 5% of the code (I 
> think that's the number that Clair Grant used to quote), I would guess 
> the number would go up to at least 25% of the code for x86 (including 
> some rather important code).
> 
> On the bright side, x86 doesn't have NaTs. :)
> 
> 

Regardless, it's an exercise in software engineering, and that's always been doable.  What 
hasn't been available is the resolve to fund and do it.

It's the lack of resolve that puzzles me.  We're not talking about some mistic thing here. 
  We're talking about something entirely do-able.  The arguments are the same, at least to 
me, as they were 10-12 years ago.

As an example, the Codis application package.  It's been in existence and continually 
upgraded for longer than VMS has been around.  I've been asked more than once what it 
would take to port / re-implement Codis on Windows.  At first I tried to explain the 
difficulties.  The windows environment is different enough that it would be a 
re-implementation, not a port.  People being people, if they don't like an answer, they 
keep asking until they get an answer they like.  So I finally came up with the simple 
answer of $50 million.  For at best a sideways move, and most likely would lose some 
functionality.  That usually ends the discussion.

To digress a bit, it's not that the customers demand that the system run on windows, they 
just want a windows user interface, and I've told them that a client / server model could 
easily present some selected functions in a windows user uinterface, or a browser based 
user interface.  Big problem there is nobody can make up their mind, and if I choose, it 
will be the wrong choice.

Regardless, and I'm not claiming any of the dollar amounts are correct, but if it cost $50 
million to get Codis on another platform, and $30 million to get VMS on x86, wouldn't the 
better business case be to port VMS?  That is just one application, and I've got to 
consider there being hundreds or thousands of others.  So from that perspective, I just 
cannot understand why VMS is not already running on x86, nor before the itanic port could 
I understand abandoning Alpha.

On Wed, 23 May 2012 17:21:07 +0200, Paul Sture wrote:

> On Wed, 23 May 2012 10:40:21 -0400, John Reagan wrote:
> 
>> Again, don't forget that you need BLISS and C just for the OS and
>> you'll want all the rest of the compilers for the customer base.  GEM's
>> old x86 target was 32-bit only, just did the things that Visual Fortran
>> required, and generated Windows object files and Windows debugging
>> info.
>>  All of that would need fixing.  And switching to some other code
>> generator (gcc, LLVM, open64) might work but I'd have to think about
>> it.
> 
> ISTR some standard utilities were written in Pascal and possibly other
> languages.  I used to see the occasional stack dump which revealed the
> language.

Someone has kindly contacted me offline with this information:

"it was revealed some years ago (at a DECUS symposium I believe) that
VMS engineering had arranged to code at least one utility that was part 
of VMS in every language available for the system. This was intended to
guarantee that the runtimes for every language would have to be included 
with VMS.

You may remember that many years back, some vendors were charging 
separately for language runtimes, so you could write programs in a 
language, but to distribute them usefully to others you had to pay toll 
to the vendors. This was a method which ensured that such a thing could 
not happen with VMS."

I recall a glitch in the system circa 1989/90 when the COBOL compiler 
shipped with run time components with a version bump that wasn't 
accompanied by appropriate patches for vanilla VMS.  We had no problem 
obtaining permission from DEC to ship the relevant run time components to 
our customers direct.

-- 
Paul Sture

Paul Sture <paul@sture.ch> wrote:
(snip)
> Someone has kindly contacted me offline with this information:

> "it was revealed some years ago (at a DECUS symposium I believe) that
> VMS engineering had arranged to code at least one utility that was part 
> of VMS in every language available for the system. This was intended to
> guarantee that the runtimes for every language would have to be included 
> with VMS.

Also, VAX (I believe VAX, and not VMS) included a common calling
convention so that it would be easier for one language to call
routines in another. That should reduce the need for so many
different runtimes, though there are likely language specific
parts.

> You may remember that many years back, some vendors were charging 
> separately for language runtimes, so you could write programs in a 
> language, but to distribute them usefully to others you had to pay toll 
> to the vendors. This was a method which ensured that such a thing could 
> not happen with VMS."

In addition, there is the client license system of MS, such that
you have to have a separate license for each user of a program
on a server.

-- glen

> but wondering if there are particular=20
> reasons why you are=A0thinking of starting
> from a low level of abstraction when=20
> higher level=A0more functional stuff=20
> apparently already exists

I'm advocating a level of abstraction that matched what current code was do=
ing.  I don't see it as low level of abstraction vs higher level abstractio=
n. I see it as - providing a way for current code to be recompiled on a new=
 CPU and still have real time access to the data sets that are currently wa=
rehoused in an existing VMS cluster.  Real time access through native APIs.=
=20

One of the themes in this thread is that everyone wishes HP would just port=
 VMS to x86. I certainly think that's a good technolgical move for VMS but =
I don't think it will happen.

So if that's not going to happen - is there a way to provide the benefit of=
 an x86 CPU upgrade without completely uprooting out of the VMS investment?=
  I think the answer lies in providing a very low latency high speed pipe b=
etween a Linux box and a vms node.

Such a pipe would enable one to get access to the files in a way that nativ=
e vms code would want it and not the "narrow" view that NFS/Samba provides.=
 Its not just files either  dont forget about things like SYS$TRNLNM.  And =
just as important - share access with other systems and processes in a clus=
tered environment so that they are oblivious to the fact that some parts of=
 the system are now puppet mastered from an x86 box.=20

I can understand the comparisons to CORBA, ORBs, DCOM, SOAP, RESTful, web s=
ervices, etc and their history of hype. I think some of those complexities =
can be avoided by keeping a simpler process model and not trying to be so g=
eneral. I see this approach as being philosophically closer to the ATA over=
 Ethernet mindset than CORBA.=20

EJ

"Paul Sture"  wrote in message news:3sbv89-25e.ln1@news.sture.ch...

> ISTR some standard utilities were written in Pascal and possibly other
> languages.  I used to see the occasional stack dump which revealed the
> language.

EDIT/FDL was written in Pascal but was recoded into C about a dozen years 
ago.  The error log formatter was written in Fortran many years ago, but it 
too was recoded into C.

Besides C, BLISS, and Macro-32, the AUDIT_SERVER and ACME_SERVER are written 
in Ada.  There are pieces of the Pascal RTL written in Pascal.  As far as I 
know, there is no COBOL, BASIC, or Fortran in the build.

"Bob Koehler"  wrote in message 
news:BdP6xyUFC4sj@eisner.encompasserve.org...

In article <SOOdnWdNnfJGayHSnZ2dnUVZ_t2dnZ2d@insightbb.com>, "John Reagan" 
<johnrreagan@earthlink.net> writes:
>
> Again, don't forget that you need BLISS and C just for the OS and you'll
> want all the rest of the compilers for the customer base.  GEM's old x86
> target was 32-bit only, just did the things that Visual Fortran required,
> and generated Windows object files and Windows debugging info.  All of 
> that
> would need fixing.  And switching to some other code generator (gcc, LLVM,
> open64) might work but I'd have to think about it.

   > I don't see generating compilers for IA32 as any more difficult than
   > generating compilers for Alpha or IA64.  There are plenty of examples
   > of code generators for IA32 (and IA32-64).

Never said it was impossible, just work to do.

> As I've mention before, the smaller register set (as compared to Itanium 
> and
> Alpha) causes more rework for facilities like RMS that currently use lots 
> of
> GLOBAL REGISTERs to pass around implicit arguments between routines.

   > GLOBAL REGISTERS can be replaced with ordinary variables.  VAXen didn't
   > have all those registers and it survived.  There may be a minor
   > performance hit.

Uh, those BLISS GLOBAL REGISTER declarations have been in RMS' BLISS code 
forever.  They are there in the VAX code stream.   We use GLOBAL REGISTERs 
in the Pascal frontend on all three architectures (VAX, Alpha, and Itanium).

And you can certainly try to recode the BLISS GLOBAL REGISTERs with explicit 
loads and stores to static variables.  You'll touch lots of modules and take 
care getting the "registers" put back when unwinding.  You might be able to 
get the BLISS compiler to help out with automatic loads/stores but I'm not 
sure it can do it all (especially when you are mixing BLISS' GLOBAL 
REGISTERs with Macro-32 input/output arguments, you need both compilers to 
help).  I actually looked at eliminating the GLOBAL REGISTERs from the 
Pascal frontend.  After several hours, I came to my senses, put the rock 
back down, and backed away slowly.

John 

John Reagan wrote:

> Never said it was impossible, just work to do.


Are you paid to twiddle your thumbs ? :-) :-) :-)


When Compaq bought Digital, hanges were made to Alpha plans to include
lockstep functiosn in order to allow Tandem's NSK to be ported to Alpha.

Wouldn't HP have similar pull with Intel to have it add more registers
to x86 to make it easier to port BCS operatings systems if it wanted to
do so ?

On May 24, 12:12=A0am, johnson.e...@gmail.com wrote:
> > but wondering if there are particular
> > reasons why you are=A0thinking of starting
> > from a low level of abstraction when
> > higher level=A0more functional stuff
> > apparently already exists
>
> I'm advocating a level of abstraction that matched what current code was =
doing. =A0I don't see it as low level of abstraction vs higher level abstra=
ction. I see it as - providing a way for current code to be recompiled on a=
 new CPU and still have real time access to the data sets that are currentl=
y warehoused in an existing VMS cluster. =A0Real time access through native=
 APIs.
>
> One of the themes in this thread is that everyone wishes HP would just po=
rt VMS to x86. I certainly think that's a good technolgical move for VMS bu=
t I don't think it will happen.
>
> So if that's not going to happen - is there a way to provide the benefit =
of an x86 CPU upgrade without completely uprooting out of the VMS investmen=
t? =A0I think the answer lies in providing a very low latency high speed pi=
pe between a Linux box and a vms node.
>
> Such a pipe would enable one to get access to the files in a way that nat=
ive vms code would want it and not the "narrow" view that NFS/Samba provide=
s. Its not just files either =A0dont forget about things like SYS$TRNLNM. =
=A0And just as important - share access with other systems and processes in=
 a clustered environment so that they are oblivious to the fact that some p=
arts of the system are now puppet mastered from an x86 box.
>
> I can understand the comparisons to CORBA, ORBs, DCOM, SOAP, RESTful, web=
 services, etc and their history of hype. I think some of those complexitie=
s can be avoided by keeping a simpler process model and not trying to be so=
 general. I see this approach as being philosophically closer to the ATA ov=
er Ethernet mindset than CORBA.
>
> EJ

" I see this approach as being philosophically closer to the ATA over
Ethernet mindset than CORBA."

OK, let's look at that particular example then. I don't know ATA over
Ethernet (or iSCSI). What's the security model with them? Does it
credibly map onto a VMS security model , or does the storage have one
level of authentication which entitles any authenticated client to get
at all the blocks? Simple/lightweight usually means low functionality.
Sometimes that's good, sometimes that's not good.

I note also that the Sector 7 part of my earlier post hasn't had much
response - they (allegedly) already have (for fee) versions of SYS
$CONNECT and a wide variety of VMS-derived stuff.

On May 24, 8:02=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> John Reagan wrote:
> > Never said it was impossible, just work to do.
>
> Are you paid to twiddle your thumbs ? :-) :-) :-)
>
> When Compaq bought Digital, hanges were made to Alpha plans to include
> lockstep functiosn in order to allow Tandem's NSK to be ported to Alpha.
>
> Wouldn't HP have similar pull with Intel to have it add more registers
> to x86 to make it easier to port BCS operatings systems if it wanted to
> do so ?

"hanges were made to Alpha plans to include lockstep functiosn in
order to allow Tandem's NSK to be ported to Alpha."

Were they, really?

Have you forgotten the stuff you read in the "VMS port to x86" thread
you started on 20 March? E.g.Keith Parris's links to NSK
presentations, or mine to the Availability Digest article at
http://www.availabilitydigest.com/public_articles/0308/ns_blades.pdf
which you said you liked?

Some text I posted back there, explaining how Tandem used "commodity"
processors in fault tolerant systems.

Tandem hasn't needed CPU lockstep since they dropped their own
proprietary processor architectures, and that's a LONG time ago in
processor history. This isn't a secret, but it may as well be as far
as the trade media and others are concerned.

In modern Tandem boxes, the synchronisation is not at instruction
level or even main-memory access level but conceptually more like "IO
access level" (or maybe process context switch level). The
synchronisation is not on the CPU chip, not even particularly close to
it, but is managed by a piece of complex external logic called the
Logical Synchronization Unit, which doesn't care about instruction-
level lockstep but does care that each processor's operations result
in the same IO with the outside world (and the same context if a
processor swap has to occur). The LSU also does a lot more than that,
which I won't go into here.

> I don't know ATA over=A0Ethernet (or iSCSI).=20
> What's the security model with them?=20
> Does it=A0credibly map onto a VMS security
> model , or does the storage have one=A0
> level of authentication which entitles any=20
> authenticated client to get=A0at all the blocks?

Darn. I created confusion with my quick broad stroke comparison to ATA over=
 Ethernet.  It's not something to use here. I liked that they took a tradit=
ional (legacy?) protocol and put new life into it by effectively redirectin=
g it over a commodity medium - Ethernet.  When you start using 10 gig and w=
ring out the latency, good things can happen.=20

But still - you asked about the security model and how would that work. In =
my view, each Linux side process would have a corresponding VMS side proces=
s to represent it in the VMS cluster. The one to one client/server process =
relationship makes it easier to preserve an existing security model. So if =
the code invokes SYS$GET_SECURITY then that function on the x86 side would =
be forwarded to the corresponding buddy process for execution on VMS.=20

> they [sector 7] (allegedly) already have=20
> (for fee) versions of SYS=A0$CONNECT=20
> and a wide variety of VMS-derived stuff.=A0

You are certainly right that they offer that. The difference in what I'm pr=
oposing is that the sector7 style solution is effectively creating a new cl=
uster. Whereas what I'm describing gives you concurrent real time access to=
 your current cluster and the data it has access to. It's the same differen=
ce between adding a node to a cluster versus starting a new one.=20

I think that some systems may do better transitioning to a newer system wit=
h an "add a node to the cluster" model versus "let's make a new cluster". T=
hat premise may be wrong though.=20

EJ

In article <5ktv89-3ef.ln1@news.sture.ch>, Paul Sture <paul@sture.ch> writes:
> 
> "it was revealed some years ago (at a DECUS symposium I believe) that
> VMS engineering had arranged to code at least one utility that was part 
> of VMS in every language available for the system. This was intended to
> guarantee that the runtimes for every language would have to be included 
> with VMS.

   That is an old tale that has repeatedly been shot down by folks from
   VMS engineering.  They have cited languages which VMS supports but
   no VMS code is written in.

> 
> You may remember that many years back, some vendors were charging 
> separately for language runtimes, so you could write programs in a 
> language, but to distribute them usefully to others you had to pay toll 
> to the vendors. This was a method which ensured that such a thing could 
> not happen with VMS."

   Such a thing happened with VMS.  When VAX C first shipped, thier 
   was no C RTL in VMS and the only way to get it was to buy the compiler. 
   Soon DEC gave C developers permission to ship the RTL with thier
   product.

   When DEC C++ first shipped, thier was no C++ RTL in VMS and the only
   way to get it was to buy the compiler.  Soon VMS 6.0 shipped with the
   C++ RTL included.

   We were early adopters of VMS 6.0 as we needed the C++ RTL for code
   developed under VMS 5.5 and did not want to buy the compiler for 5.5.

In article <jpjm9q$ru2$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> Also, VAX (I believe VAX, and not VMS) included a common calling
> convention so that it would be easier for one language to call
> routines in another. That should reduce the need for so many
> different runtimes, though there are likely language specific
> parts.

   VAX has a calling standard.  VMS obeys it.  I suspect ULTRIX and
   VAXeln obey it, but I'm not so sure about or all the other UNIX 
   variants that run on VAX.  It was changed when VAX C shipped.

   Alpha has a calling standard.  VMS obeys it.  I'm fairly sure 
   OSF-1/digital UNIX/Tru64 UNIX obeys it.  I'm not so sure about 
   Cray OS or any other OS.

   IA64 has a calling standard.  VMS has trouble with it and I'm not
   sure the exact state, but VMS does follow a standard and all native
   languages for VMS on IA64 can be mixed.

   The calling standards used by VMS are published for all three
   architectures.

   Despite this, language RTLs vary greatly.  There is no printf() in
   Fortran, COBOL, Pascal, ..., there is no TYPE statement in C, COBOL,
   Pascal, ...

   There are common OTS$ routines and all the RTLs take advantage of all 
   the VMS APIs, but I've never seen a compiler generate a direct call to 
   any OTS$ routine that wasn't written in the source.

In article <1a5b3a73-2804-43ab-9343-8bdd3f1b6871@googlegroups.com>, abrsvc <dansabrservices@yahoo.com> writes:
> 
> Monitor is a good example.  It was written in PL/I and on alpha runs as a "VEST'd" image.

   Early versions of MONITOR told us so.  Error messages often started
   with PLI as the facility name.

In article <9cdfdfd0-50b6-4345-84ff-072a67b12385@googlegroups.com>, johnson.eric@gmail.com writes:
> 
> So if that's not going to happen - is there a way to provide the benefit of=
>  an x86 CPU upgrade without completely uprooting out of the VMS investment?=
>   I think the answer lies in providing a very low latency high speed pipe b=
> etween a Linux box and a vms node.

   Not transparent and would require massive investments in changing
   code.  I'll stick with SIMH.

"Bob Koehler"  wrote in message 
news:Fr+gezjxaCrO@eisner.encompasserve.org...


   >VAX has a calling standard.  VMS obeys it.  I suspect ULTRIX and
   >VAXeln obey it, but I'm not so sure about or all the other UNIX
   >variants that run on VAX.  It was changed when VAX C shipped.

Well, VAX/VMS has a Calling Standard.  It isn't an ABI attached to the 
hardware.  And the Calling Standard was not "changed" for VAX C.  Might have 
been extended, but always upwards compatible.

   >Alpha has a calling standard.  VMS obeys it.  I'm fairly sure
   >OSF-1/digital UNIX/Tru64 UNIX obeys it.  I'm not so sure about
   >Cray OS or any other OS.

The OpenVMS Alpha Calling Standard and the Tru64 Calling Standard are not 
the same.  Close.  Written by the same folks.  But not quite the same.

   >IA64 has a calling standard.  VMS has trouble with it and I'm not
   >sure the exact state, but VMS does follow a standard and all native
   >languages for VMS on IA64 can be mixed.

Not sure what you mean.  The OpenVMS I64 Calling Standard works just fine. 
All the compilers follow it.  The OS follows it.  Perhaps you are confusing 
it with the Intel Runtime Conventions (their equivalent of a Calling 
Standard that their compilers follow).  We started with the Intel 
conventions but then extended/integrated it into the traditional OpenVMS 
Calling Standard to allow such things as uplevel references, bound procedure 
values, translated code, etc.

There is an appendix in the Calling Standard doc that highlights the 
differences between the Intel written conventions and what we eventually 
adopted for the Calling Standard.

John (former member of the Calling Standard committee) 

"Bob Koehler"  wrote in message 
news:RliP6w29qhWz@eisner.encompasserve.org...

   >Early versions of MONITOR told us so.  Error messages often started
   >with PLI as the facility name.

Looked at the sources.  All PL/1 was converted to C back in 2002.  I see a 
mixture of Macro-32, BLISS, and C.  Looking at the dates, even the VAX PL/1 
version had the Macro-32 and BLISS modules (I saw edit dates for the BLISS 
modules going tall the way to the 1980s).

John 

In article <q6GdnQj3F63x1yPSnZ2dnUVZ_q2dnZ2d@insightbb.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
> 
>    >VAX has a calling standard.  VMS obeys it.  I suspect ULTRIX and
>    >VAXeln obey it, but I'm not so sure about or all the other UNIX
>    >variants that run on VAX.  It was changed when VAX C shipped.
> 
> Well, VAX/VMS has a Calling Standard.  It isn't an ABI attached to the 
> hardware.  And the Calling Standard was not "changed" for VAX C.  Might have 
> been extended, but always upwards compatible.

   The VAX calling standard prior to VAX C called for one longword in the
   argument list for every argument.  In order to pass doubles and
   structs by value in VAX C it was changed to one or more longwords 
   per argument.

In article <foednafrXoDqUSDSnZ2dnUVZ_jmdnZ2d@insightbb.com>, "John
Reagan" <johnrreagan@earthlink.net> writes: 

> EDIT/FDL was written in Pascal but was recoded into C about a dozen years 
> ago.  The error log formatter was written in Fortran many years ago, but it 
> too was recoded into C.

What is EDT written in?  (I believe it is also a VESTed image on 
Itanium, maybe even on ALPHA.)

> Besides C, BLISS, and Macro-32, the AUDIT_SERVER and ACME_SERVER are written 
> in Ada.  There are pieces of the Pascal RTL written in Pascal.  As far as I 
> know, there is no COBOL, BASIC, or Fortran in the build.

So the 6-character limit for node names has another source (no pun 
intended) than the limit on a variable name in Fortran before Fortran90.

Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:

(snip)
> So the 6-character limit for node names has another source (no pun 
> intended) than the limit on a variable name in Fortran before 
> Fortran90.

Hmmm. Fortran was developed on 36 bit machines with a 6 bit 
character set. (The IBM 704 and BCDIC.) 

DEC conveniently also build 36 bit machines that, in addition
to using ASCII (five per word) also used SIXBIT with six per word,
among other place for file names. 

It certainly wouldn't surprise me if node names could be traced
back to the PDP-10 (maybe TOPS-20), from there to its IBM ancestors, 
and then to Fortran. But note that it would be that both traced
back to 36 bit machines, but no causal relationship between them.

There are stories tracing back the size of the space shuttle
solid rocket boosters back even farther than that.

-- glen

On Thursday, May 24, 2012 2:38:12 PM UTC-7, glen herrmannsfeldt wrote:
> Phillip Helbig---undress to reply <helbig@astro.multiclothesvax.de> wrote:
> 
> (snip)
> > So the 6-character limit for node names has another source (no pun 
> > intended) than the limit on a variable name in Fortran before 
> > Fortran90.

DECnet node names.

> Hmmm. Fortran was developed on 36 bit machines with a 6 bit 
> character set. (The IBM 704 and BCDIC.) 
> 
> DEC conveniently also build 36 bit machines that, in addition
> to using ASCII (five per word) also used SIXBIT with six per word,
> among other place for file names. 
> 
> It certainly wouldn't surprise me if node names could be traced
> back to the PDP-10 (maybe TOPS-20), from there to its IBM ancestors, 
> and then to Fortran. But note that it would be that both traced
> back to 36 bit machines, but no causal relationship between them.

Yeah, I expect this goes back to the 36 bit machines.  DECnet
is supported (first appeared?) on PDP-10, then that 6-character
restriction was carried forward to VMS (and PDP-11 operating
systems) so that all of them could talk to each other.

   -Ken

On Wed, 2012-05-23 at 11:42 -0700, Doug Phillips wrote:
> >    But that latter is a matter of generating efficient code, just
> >    getting code to work should not be such a big deal.  A 32 bit add
> >    instruction on VAX has different side affects than the same
> >    instruction on IA32, but you can still add additional
> instructions
> >    to get the side effects when needed, just like RISC.
>=20
> I imagine you've read it, Bob, but for those who haven't, the OpenVMS
> Technical Journal-v6 -Porting OpenVMS to HP Integrity Servers- is
> worth reading (and rereading if it's been a while.)=20

http://h71000.www7.hp.com/openvms/journal/v6/porting_openvms_to_integrity.p=
df
--=20
Tactical Nuclear Kittens

On 2012-05-24 15:21, Ken Fairfield wrote:
> On Thursday, May 24, 2012 2:38:12 PM UTC-7, glen herrmannsfeldt wrote:
>> Phillip Helbig---undress to reply<helbig@astro.multiclothesvax.de>  wrote:
>>
>> (snip)
>>> So the 6-character limit for node names has another source (no pun
>>> intended) than the limit on a variable name in Fortran before
>>> Fortran90.
>
> DECnet node names.
>
>> Hmmm. Fortran was developed on 36 bit machines with a 6 bit
>> character set. (The IBM 704 and BCDIC.)
>>
>> DEC conveniently also build 36 bit machines that, in addition
>> to using ASCII (five per word) also used SIXBIT with six per word,
>> among other place for file names.
>>
>> It certainly wouldn't surprise me if node names could be traced
>> back to the PDP-10 (maybe TOPS-20), from there to its IBM ancestors,
>> and then to Fortran. But note that it would be that both traced
>> back to 36 bit machines, but no causal relationship between them.
>
> Yeah, I expect this goes back to the 36 bit machines.  DECnet
> is supported (first appeared?) on PDP-10, then that 6-character
> restriction was carried forward to VMS (and PDP-11 operating
> systems) so that all of them could talk to each other.

Nice try, but wrong. DECnet was initially developed on PDP-11 running 
RSX. The 36-bit machines were very much behind the leading edge during 
their whole time on DECnet. Eventually VMS became the leading edge, but 
it stayed with RSX for quite a while...

However, 6 characters also pack nicely into two 16-bit words, using 
Radix 50...

The PDP-10 often used 7-bit ASCII, packing five bytes to the word, yes. 
SIXBIT was used in lots of cases when a more restricted character set 
was enough, such as for symbols, filenames, usernames, and god knows 
what else. But it was also not totally unheard of to use 9-bit 
characters and pack 4 to a word. The PDP-10 had variable sized bytes, so 
they can be anything from 1 bit to 36 bits... Even nicer, even files 
(atleast in TOPS-20) actually know what bytesize they are in.

	Johnny

Johnny Billquist wrote:

> However, 6 characters also pack nicely into two 16-bit words, using 
> Radix 50...


Far more likely that the VMS engineers rolled a dice and it ended up on
"6" and so the node name length limit was set to 6 :-) :-) :-) :-) :-)

On Thu, 24 May 2012 23:18:54 -0700, Johnny Billquist wrote:

> However, 6 characters also pack nicely into two 16-bit words, using
> Radix 50...

Even Dibol had routines to pack and unpack RAD-50.

6 characters also worked nicely for index entries along with an integer*2 
address (don't ask).

-- 
Paul Sture

On 25/05/2012 08:27, JF Mezei wrote:
> Johnny Billquist wrote:
>
>> However, 6 characters also pack nicely into two 16-bit words, using
>> Radix 50...
>
>
> Far more likely that the VMS engineers rolled a dice and it ended up on
> "6" and so the node name length limit was set to 6 :-) :-) :-) :-) :-)

Micro$**t probably also rolled a die (note: singular) for the names of
their disk drives and it ended up a "1" ...

On Fri, 25 May 2012 09:43:48 +0100, Roy Omond wrote:

> On 25/05/2012 08:27, JF Mezei wrote:
>> Johnny Billquist wrote:
>>
>>> However, 6 characters also pack nicely into two 16-bit words, using
>>> Radix 50...
>>
>>
>> Far more likely that the VMS engineers rolled a dice and it ended up on
>> "6" and so the node name length limit was set to 6 :-) :-) :-) :-) :-)
> 
> Micro$**t probably also rolled a die (note: singular) for the names of
> their disk drives and it ended up a "1" ...

Windows Server 2008 has a nice little denial of service trick.  When you 
assign a disk drive for backup, WS2008 takes away the drive letter so 
that nobody can get to it.

When you subsequently decide to use that drive for other purposes, you 
tell Windows backup to release it, and hey presto it comes back as A:

Now try rebooting :-)

P.S. Release another drive at the same time and that will come back as B:



-- 
Paul Sture

On 5/25/2012 3:27 AM, JF Mezei wrote:
> Johnny Billquist wrote:
>
>> However, 6 characters also pack nicely into two 16-bit words, using
>> Radix 50...
>
>
> Far more likely that the VMS engineers rolled a dice and it ended up on
> "6" and so the node name length limit was set to 6 :-) :-) :-) :-) :-)

Just to set the record straight:

Dice is plural.  Die is singular.  The engineers rolled a die!

On 2012-05-25 00:27, JF Mezei wrote:
> Johnny Billquist wrote:
>
>> However, 6 characters also pack nicely into two 16-bit words, using
>> Radix 50...
>
>
> Far more likely that the VMS engineers rolled a dice and it ended up on
> "6" and so the node name length limit was set to 6 :-) :-) :-) :-) :-)

Nice try as well, but if you read all I wrote, this wasn't done in VMS 
first... :-)

	Johnny