DIBOL to <different language>

[Tad Winters]

Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.

I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.

They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.

I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.

I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)

Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
be the best choice? Keep these details in mind:
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.

Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.

The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.

A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.

I await your wisdom.

[David J Dachtera]

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.

A local associate of mine (who happens to own openvms.com) had a client
who did their DIBOL development on VAX, then VESTed the images to Alpha.

My first suggestion, however, would be to troubleshoot the performance
issue, if at all possible. Demons could be lurking there which will
migrate to the new platform, if you try to move them to Alpha without
exploring that.

David J Dachtera
DJE Systems

[Hein RMS van den Heuvel]

On Feb 10, 6:34 pm, Tad Winters

 The custom forms editor generates additional MACRO code and DIBOL "include" files.

Since it is generated, a of 'perl' can probably readily transform that
into anything.

They've been using a single VAX system with an HSD30 for storage.  The
system runs rather slowly at times

Slowly 'at times' suggests to me that the basic need is met, but there
might be an addresable peformance/tuning issue. But they shoudl
probably move regardless.

The system has been tuned many times, without any appreciable improvement.

Personally I don't believe in system tuning.
Unless someting is really broken, that's just fumbling in the margins.
Application and DB tuning is the only way to make a proper difference.

I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL.  

Did you also check out our friend Bruce Claremon offerings?
http://www.migrationspecialties.com/CBL.html

I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable.  (Too bad CHARON-VAX is not an emulator
running on bare metal.)

It has been working well. Despite bad rap, I'm personally not so much
concerned about the underpinnings of the emulators. Windows is stable
in predictable environment. If is is just a host, then it will do
fine. Just don't use the same box too much native windows stuff. No
random web-browsing or family video productions on the side!

I would be more concerened about the application beginning to run into
inherent botlleneck which may be starting to show now on VAX but may
well still be there on Alpha or an other platform.

 The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL.  

Hmm, you don't mention C. Yeak it does not have native RMS (indexed
file) support, but it can call RMS any which way you like.

I (used) to like BASIC a lot, but it seems such a dead-end street to
me these days and it is NOT a high performance language, just a
'comfortable' language like perl. and where will you find folks
experienced with Vax-Basic's little gotcha's?
Fortran... ho hum
Cobol... proabbly the best match for Dibol
Pascal... Clean language, but how many programmers are available out
there?
My knee-jerk reaction is 'C'... you can write bad code in any
language.

Good luck!

Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Bill Gunshannon]

Post by Hein RMS van den Heuvel
Pascal... Clean language, but how many programmers are available out
there?

At least one.

bill

[Arne Vajhøj]

Post by Bill Gunshannon

Post by Hein RMS van den Heuvel
Pascal... Clean language, but how many programmers are available out
there?

At least one.

Pascal was a very widely used language for learning
programming in the golden VAX days. I think a lot
of VMS people will know Pascal. It may be a bit rusty
for some, but some say that it is like driving a bicycle.

Arne

[Bill Gunshannon]

Post by Arne Vajhøj

Post by Bill Gunshannon

Post by Hein RMS van den Heuvel
Pascal... Clean language, but how many programmers are available out
there?

At least one.

Pascal was a very widely used language for learning
programming in the golden VAX days. I think a lot
of VMS people will know Pascal. It may be a bit rusty
for some, but some say that it is like driving a bicycle.

Actually, I learned Pascal while in a production environment in order
to write serious applications for an LSI-11/02 based micro. It was
many years after that before I first saw it in use in academia.

Oh yeah, I became so enthraled with Pascal that even now I spend a
good deal of time examining and playing with Pascal Compilers and
systems.

bill

[u***@gmail.com]

On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages.  I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO.  The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage.  The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers.  The
system has been tuned many times, without any appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL.  Since Synergy charges for a runtime license, this is a show
stopper.  They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable.  (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question.  If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.  
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first.  I'd like to start down
the correct road first.  The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL.  This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.

Ask synergy to give you a break on the licensing ...
they are sometimes flexible for small companies ...

also there have been several dibol shops who have
used vest successfully ...

I would buy a DS10L from island for 200.00 and
try vest first ... it probably will work and its free ...

[Richard B. Gilbert]

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.

Tuning was not intended for miracles. Unless a system is horribly
mistuned to start with, the best you can hope for is to squeeze out the
last ten percent in performance!

Post by Tad Winters
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
A runtime license cost isn't going to fly.

Just about ANY language except Gnu C is going to require a license that
costs money! AFAIK there is no such thing as Gnu COBOL!

Post by Tad Winters
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.

You didn't say what model VAX they were using. Some were painfully
slow, others were much faster. Knowing the Model of the VAX, we might
be able to suggest a substantially faster machine. A faster machine
might very well require more "License Units"! OTOH, rewriting 350,000
lines of code in a new language, supported on the Alpha and/or Itanic,
is probably going to cost seven to ten man years of effort.

The other approach, the one that you asked about; is another language.
You can code just about anything, in just about any language! Languages
have both strengths and weaknesses. The language that was great for
doing Fourier Transforms would have to be bent out of shape to write
accounts receivable and vice versa of course.

The only widely available languages that might be close to DIBOL (a
language I know almost nothing about) are COBOL and PL/1. I believe
that PL/1 is available for Alpha; I don't know if it's available for Itanic.

I think that, if you cost this out carefully, you may find that a
$20,000 license is small change compared to the rest of it!

[Arne Vajhøj]

Post by Richard B. Gilbert
Just about ANY language except Gnu C is going to require a license that
costs money! AFAIK there is no such thing as Gnu COBOL!

Java, Perl, Python etc. are also free.

But may not be a good choice for the task (RMS, Macro-32 etc.).

Arne

[Tad Winters]

Post by Richard B. Gilbert
You didn't say what model VAX they were using. Some were painfully
slow, others were much faster. Knowing the Model of the VAX, we
might be able to suggest a substantially faster machine. A faster
machine might very well require more "License Units"! OTOH,
rewriting 350,000 lines of code in a new language, supported on the
Alpha and/or Itanic, is probably going to cost seven to ten man
years of effort.
The other approach, the one that you asked about; is another
language. You can code just about anything, in just about any
language! Languages have both strengths and weaknesses. The
language that was great for doing Fourier Transforms would have to
be bent out of shape to write accounts receivable and vice versa of
course.
The only widely available languages that might be close to DIBOL (a
language I know almost nothing about) are COBOL and PL/1. I believe
that PL/1 is available for Alpha; I don't know if it's available for Itanic.
I think that, if you cost this out carefully, you may find that a
$20,000 license is small change compared to the rest of it!

The last pricing I saw on a one user compiler license was $1995. That's
a far better price than $20,000.
I know this could take a lot of hours, but if I could convert the
smallest application, I think I could motivate someone else to help the
in the process. This would be good experience for similar work at
another company, which isn't having any performance problems, but would
like the comfort of having easily replaced hardware in the case of a
disaster.

[Tad Winters]

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is a
show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start
down the correct road first. The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. There are 120 detached processes performing (or waiting
to perform) specific application functions. The system is also running
MultiNet V4.4. I'd love to get this all upgraded, but there's no way
that would fly without guaranteed significant performance improvement.
If upgrading is the way to go, then it seems like it would be best to
make as much a jump as possible.
Thanks.

[Richard B. Gilbert]

Post by Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is a
show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start
down the correct road first. The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. <snip>

Is there some reason why some of these reports couldn't be run overnight
instead of from 8 AM to 10 AM??

[Tad Winters]

Post by Richard B. Gilbert

Post by Tad Winters
Perhaps I should mention that this is VMS V7.1. There are up to
150 concurrent users. The worst time is usually between 8 and 10
in the morning, when many reports are being run in batch in
addition to interactive use. <snip>

Is there some reason why some of these reports couldn't be run
overnight instead of from 8 AM to 10 AM??

I believe these vary from day to day. We're talking about reports having
to do with Accounts Payable, Accounts Receivable, General Ledger and
their very customized Distribution Management. If they planned ahead,
they could request the reports be run overnight, but this is a group of
order takers and warehouse people. Most of their work is reaction to
orders being placed. The few who could help by planning are those who
work the accounting applications and those who do purchasing.
This is certainly worth a try.
Thanks.

[Richard B. Gilbert]

Post by Tad Winters

Post by Richard B. Gilbert

Post by Tad Winters
Perhaps I should mention that this is VMS V7.1. There are up to
150 concurrent users. The worst time is usually between 8 and 10
in the morning, when many reports are being run in batch in
addition to interactive use. <snip>

Is there some reason why some of these reports couldn't be run
overnight instead of from 8 AM to 10 AM??

I believe these vary from day to day. We're talking about reports having
to do with Accounts Payable, Accounts Receivable, General Ledger and
their very customized Distribution Management. If they planned ahead,
they could request the reports be run overnight, but this is a group of
order takers and warehouse people. Most of their work is reaction to
orders being placed. The few who could help by planning are those who
work the accounting applications and those who do purchasing.
This is certainly worth a try.
Thanks.

If some of these reports are periodic; e.g. every day, every Friday,
etc, they could be handled as self submitting batch jobs. You might
benefit from a "clever" batch scheduler such as JAMS. Using JAMS you
can say "every Friday except holidays" and the job will be run that way.

Another possible solution is to buy another VAX 4000-600 and cluster the
two. You could have one grinding out reports while the other handled
order taking, accounts receivable, etc.

[Bill Gunshannon]

Post by Richard B. Gilbert

Post by Tad Winters

Post by Richard B. Gilbert

Post by Tad Winters
Perhaps I should mention that this is VMS V7.1. There are up to
150 concurrent users. The worst time is usually between 8 and 10
in the morning, when many reports are being run in batch in
addition to interactive use. <snip>

Is there some reason why some of these reports couldn't be run
overnight instead of from 8 AM to 10 AM??

I believe these vary from day to day. We're talking about reports having
to do with Accounts Payable, Accounts Receivable, General Ledger and
their very customized Distribution Management. If they planned ahead,
they could request the reports be run overnight, but this is a group of
order takers and warehouse people. Most of their work is reaction to
orders being placed. The few who could help by planning are those who
work the accounting applications and those who do purchasing.
This is certainly worth a try.
Thanks.

If some of these reports are periodic; e.g. every day, every Friday,
etc, they could be handled as self submitting batch jobs. You might
benefit from a "clever" batch scheduler such as JAMS. Using JAMS you
can say "every Friday except holidays" and the job will be run that way.
Another possible solution is to buy another VAX 4000-600 and cluster the
two. You could have one grinding out reports while the other handled
order taking, accounts receivable, etc.

Considering the stability of the operation and the desire to minimize
costs, this seems like the best suggestion yet. I would go one further
and suggest at least two more VAX 4000-600's for even better performance
and eliminating the chance that you would drop back to just the one
system shopuild anything go wrong. I would imagine VAX 4000 are still
available on the cheap. I have three and have never paid for any of them.

bill

[Bill Gunshannon]

Post by Richard B. Gilbert

Post by Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is a
show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start
down the correct road first. The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. <snip>

Is there some reason why some of these reports couldn't be run overnight
instead of from 8 AM to 10 AM??

That was the first thing that came to my mind, too. :-)

bill

[Richard B. Gilbert]

Post by Bill Gunshannon

Post by Richard B. Gilbert

Post by Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is a
show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start
down the correct road first. The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. <snip>

Is there some reason why some of these reports couldn't be run overnight
instead of from 8 AM to 10 AM??

That was the first thing that came to my mind, too. :-)
bill

Yeah! It used to be known as "Performance Management". A few of us old
fogies still remember! Instead of paying the hardware and licensing
costs for a faster machine, work the old one harder! There's no point
in letting it loaf from 6:00 PM to 6:00 AM.

[Tad Winters]

Post by Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is
a show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor
and support applications, which I would port first. I'd like to
start down the correct road first. The languages which I first
thought would meet the requirements are FORTRAN, BASIC, Pascal, and
COBOL. This doesn't strictly rule out others, and it would seem
prudent to choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. There are 120 detached processes performing (or
waiting to perform) specific application functions. The system is
also running MultiNet V4.4. I'd love to get this all upgraded, but
there's no way that would fly without guaranteed significant
performance improvement. If upgrading is the way to go, then it
seems like it would be best to make as much a jump as possible.
Thanks.

And one more thing. This is a VAX 4000-600A.

[Bob Willard]

Tad Winters wrote: <and I snipped>

Post by Tad Winters

Post by Tad Winters
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is
a show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)

And one more thing. This is a VAX 4000-600A.

1.Try a faster VAX
2.Try more RAM
3.Try a SMP VAX and/or a cluster
4.Try faster storage, esp. RAID0 and/or 15K RPM SCSI HDs

I suspect that a concurrent batch DIBOL workload is I/O intensive,
rather than CPU intensive, so souping up the storage would be my
first priority. But, measuring the workload attributes to find
the bottleneck(s) would be smarter than relying on my long-distance
crystal ball.

Unless the VAX 4000 is maxed out, adding RAM is the simplest and
cheapest hardware improvement you can make. Regardless of the
long-term solution you pursue, I'd add RAM for short-term relief
if possible.

You can buy a hell of a lot of second-hand VAXen for less than the
cost of a team of porters, esp. porters with VMS and DIBOL creds.

[Bill Gunshannon]

Post by Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers. The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL. Since Synergy charges for a runtime license, this is a
show stopper. They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert. I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start
down the correct road first. The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. There are 120 detached processes performing (or waiting
to perform) specific application functions. The system is also running
MultiNet V4.4. I'd love to get this all upgraded, but there's no way
that would fly without guaranteed significant performance improvement.
If upgrading is the way to go, then it seems like it would be best to
make as much a jump as possible.
Thanks.

And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump. You could have had them for the cost of a
rental truck. :-(

bill

[Tad Winters]

***@cs.uofs.edu (Bill Gunshannon) wrote in news:***@mid.individual.net:

[..snip..]

Post by Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump. You could have had them for the cost of a
rental truck. :-(
bill

Pennsylvania to Oregon would have been quite the trip. Their current
system (actually 2, with 1 acting as their stand-by) is below grade (like
their entire operation) in a room about 10' by 10', 3 line printers,
built-in cabinets on one wall and boxes of paper lining another wall. I
can't say I've seen a VAX 7000 in person, but I suspect there would have
been space, cooling and power issues to address.
Just 2 days ago, the most IT person in that company asked me about
putting what they have in racks, since a water main had broken just a
block away (down hill) in the last week, which caused flooding for the
adjacent businesses.
Another interesting fact is the "computer room" is carpetted.

[Bill Gunshannon]

Post by Tad Winters
[..snip..]

Post by Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump. You could have had them for the cost of a
rental truck. :-(
bill

Pennsylvania to Oregon would have been quite the trip.

True, but a real bargain once oyu discount what a VAX 7000 actually costs.

Post by Tad Winters
Their current
system (actually 2, with 1 acting as their stand-by) is below grade (like
their entire operation) in a room about 10' by 10', 3 line printers,
built-in cabinets on one wall and boxes of paper lining another wall.

I've worked for people like that. Sometimes the best idea is to just
wash your hands and walk away. (It took 3 major data lossdes here before
they finally agreed we should have a tape drive fast enough and with the
capacity to do real regular backups.)

Post by Tad Winters
I
can't say I've seen a VAX 7000 in person, but I suspect there would have
been space, cooling and power issues to address.

Very likely. :-) Think of the size of a walk-in fridge. Only hotter.

Post by Tad Winters
Just 2 days ago, the most IT person in that company asked me about
putting what they have in racks, since a water main had broken just a
block away (down hill) in the last week, which caused flooding for the
adjacent businesses.

Dependingon how far below grade that might not help much. :-)

Post by Tad Winters
Another interesting fact is the "computer room" is carpetted.

That comes as no surprise as I have seen companies that sell raised
floor tiles that are carpet. As long as it is anti-static and the
dust get's vacuumed out of it regularly not really a problem. But,
I would imagine it is merely bargain-basement carpet from the local
outlet store.

bill

[Richard B. Gilbert]

Post by Tad Winters
[..snip..]

Post by Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump. You could have had them for the cost of a
rental truck. :-(
bill

Pennsylvania to Oregon would have been quite the trip. Their current
system (actually 2, with 1 acting as their stand-by) is below grade (like

<snip>

Post by Tad Winters
Another interesting fact is the "computer room" is carpetted.

Unusual but by no means impossible. You can buy "anti-static" carpet
for such purposes. You can even buy raised floor panels with carpet
topping. I don't recall ever having seen such panels or a carpeted
computer room but at least one company tried to sell me such a thing.
I don't even want to think about keeping a carpeted computer room clean!

[Bob Koehler]

Post by Richard B. Gilbert
Unusual but by no means impossible. You can buy "anti-static" carpet
for such purposes. You can even buy raised floor panels with carpet
topping. I don't recall ever having seen such panels or a carpeted
computer room but at least one company tried to sell me such a thing.
I don't even want to think about keeping a carpeted computer room clean!

We had a carpeted raised floor in one computer room. It kept the
noise from the 11/70 and 11/785 down. Their updraft cooling
kept the carpet clean. We still have computer filter problems in
that room, long after the 11/70 and 11/785 have been removed.

[Stanley F. Quayle]

Post by Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump.

"Lightly used", but certainly not "light".

It seems a shame, though. Some should at least parted them out first...

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[Bill Gunshannon]

Post by Stanley F. Quayle

Post by Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump.

"Lightly used", but certainly not "light".
It seems a shame, though. Some should at least parted them out first...

I offered them here for nothing. I offered them in other places for
free. As a last resort I put them on Ebay. I sold one for $100.
Al Kossow asked to have one CPU for his collection (which I sent him).
Don't really know what else I could have done. I kept them hanging
around for more than a year trying to avoid just dumping them. Sad,
really......

bill

[FrankS]

I offered them here for nothing.  I offered them in other places for
free.  As a last resort I put them on Ebay.  I sold one for $100.

I know of four VAX 7640s that may become available by the end of the
year, if not sooner. They will likely be sold by the pound to a
computer systems liquidator.

If somebody is creating a VAX 7600 museum to complement the MicroVAX
II museum in Israel then maybe we'll find a better home for this
stuff. :-)

[Tom Linden]

Post by FrankS

I offered them here for nothing.  I offered them in other places for
free.  As a last resort I put them on Ebay.  I sold one for $100.

I know of four VAX 7640s that may become available by the end of the
year, if not sooner. They will likely be sold by the pound to a
computer systems liquidator.
If somebody is creating a VAX 7600 museum to complement the MicroVAX
II museum in Israel then maybe we'll find a better home for this
stuff. :-)

How about the computer history museum in San Jose? I think I know someone
who might be interested, drop me a note offline.

[u***@gmail.com]

On Feb 10, 10:47 pm, Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages.  I'm after honest, technical answers.
I've done some work for a small company who happens to use some
custom software, written largely in DIBOL, with the rest in MACRO.
The custom forms editor generates additional MACRO code and DIBOL
"include" files.
They've been using a single VAX system with an HSD30 for storage.
The system runs rather slowly at times and this both frustrates the
users and probably causes some customers to consider other
suppliers.  The system has been tuned many times, without any
appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be
Synergy DBL.  Since Synergy charges for a runtime license, this is a
show stopper.  They would be looking at more than $20,000 for
Synergy DBL alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable.  (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question.  If a person was interested in
moving code from DIBOL to another language (on OpenVMS), what
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they
would with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to
convert.  I'm going to guess between 300,000 and 350,000, but don't
hold me to it.
The routines directly written in MACRO have previously been ported
to the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first.  I'd like to start
down the correct road first.  The languages which I first thought
would meet the requirements are FORTRAN, BASIC, Pascal, and COBOL.
This doesn't strictly rule out others, and it would seem prudent to
choose a language which is also supported on Itanium.
I await your wisdom.

Perhaps I should mention that this is VMS V7.1.  There are up to 150
concurrent users.  The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use.  There are 120 detached processes performing (or waiting
to perform) specific application functions.  The system is also running
MultiNet V4.4.  I'd love to get this all upgraded, but there's no way
that would fly without guaranteed significant performance improvement.
If upgrading is the way to go, then it seems like it would be best to
make as much a jump as possible.
Thanks.- Hide quoted text -
- Show quoted text -

you have two inexpensive options ...

1. we ran DIBOL on a vaxstation 4000-90 and 4000-96 for years
on vms 6.2 and it ran very well for allour accounting apps ...
So go out on the second hand market or even Ebay and BUY
a vaxstation 4000-9x ...

2. Buy s DS10L from island computer and put 7.1-2 vms on it
and VEST from the vax (which for development purposes can
be replaced with a vaxstation VLC for CHEAP) to the alpha
vms 7.1 ds10l box (which is also cheap) ... like I said I know
of several DIBOL shops in the past that succesfully used vest
to take dibol apps from 7.1 vax to 7.1 alpha ...

Either solution above would NOT cost $20,000 ... if would probably
cost more like $2,000 ...

[Jerry]

On Feb 11, 12:34 am, Tad Winters

Post by Tad Winters
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first.  I'd like to start down
the correct road first.  The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL.  

I've used FORTRAN, BASIC and Pascal in short term projects only. I
can't say much about them.

After being a COBOL and C programmer for years, I worked a few years
with DIBOL/DBL, so I can only comment on those languages. I used to
joke that DIBOL was a language with all the power of COBOL with the
ease of use of C.

For straight forward business applications COBOL is probably the
easiest to learn and maintain. You can use copylibs instead of
includes. COBOL does have its limitations compared to C but it pretty
much can do anything that DIBOL can do.

Post by Tad Winters
Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.

...

Post by Tad Winters
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.

On the other hand, from a business view, this doesn't make sense. The
time and effort it would take to rewrite 300K lines of DIBOL to
another language makes $20K look like small stuff. Just to let you
know, for close to 10 years, I've been doing budget estimates and
project management solely on migration work. $20K is a mere fraction
of the cost of this type of migration. You've got some tough choices
ahead.

Good luck, though.

[FrankS]

On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
I await your wisdom.

a) The cheapest solution may be to upgrade from a 4000-600A to either
a -700A or -705A. Both of those -7xxA systems were faster than the
-600A, yet had the same license rating. You should be able to find
them at various used system resellers. Make sure you max out the
memory if you go that route.

Similarly, upgrade the HSD30 to an HSD50. You didn't mention what
disk cabinet the HSD30 is in. If it's an RA450 then I believe the
HSD50 will just slide in. That will give you 6 SCSI channels instead
of 3 so you can spread the I/O a bit, and the controller itself is
faster. You would also want to max out the cache on the HSD (128mb,
if I remember correctly).

b) Clustering the 4000-600A with another VAX probably isn't a good
solution because you'd have to find and buy VAXcluster licenses. HP
may still sell them, but the cost for two nodes may be more than the
Synergy license.

c) For an Alpha solution you'd have to get the VMS Base license, an
unlimited user license, and any other licenses that are on the VAX
that need to be transferred. Because of HP's licensing policies you
can only get the Base license from an HP authorized reseller and it
must be sold with the Alpha system. Don't forget that you'd need a
license for whichever language compiler you decide to use. (The
assumption is that you will be looking for valid licenses and not
using other methods to get VMS licenses onto the Alpha.)

While you can get DSSI for an Alpha system you'd probably want to
switch to fiber. That introduces other costs of moving the data from
the HSD array to an HSG array. The HSG80 controllers and cabinets are
cheap enough on eBay or other sources, and even disk drives in the
blue Storageworks caddies are fairly inexpensive. But it all adds up.

d) The biggest cost factor as others have pointed out is your time in
converting the applications from DIBOL to any other language. You
might be able to use TPU to create an automated solution, but I'm not
familiar enough with DIBOL syntax to know how feasible that would be.
Still, testing is going to add up in billable hours, unless you're
doing this pro-bono.

e) If you do decide to go the migration route then consider
Integrity. From what I can remember the lowest priced Integrity with
licenses, media, and cabinetry lists at $5k. HP will likely provide
discounts on trade-up licenses from the VAX which will lower that cost
somewhat.

You can try VESTing the DIBOL compiler to Alpha, then AEST it to
Integrity. If it works you've saved yourself a bundle on migration
costs. Otherwise the work involved in translating the DIBOL to
another language is not going to change whether you're moving to Alpha
or Integrity.

f) The performance gains to be had when going from a VAX 4000-600A +
DSSI to a DS10L (or practically any Alpha) + fiber are significant.
Likewise for a switch to Integrity. It would be well worth the $20k
investment, in my opinion, to stick with the DIBOL environment. You
might not put as much money into your own pocket because the migration
effort isn't as complicated as rewriting to another language, but your
customer would be a lot happier.

[Bill Gunshannon]

Post by Hein RMS van den Heuvel
On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
I await your wisdom.

You can try VESTing the DIBOL compiler to Alpha, then AEST it to
Integrity.

I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?

bill

[FrankS]

Post by Bill Gunshannon
I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?

Honestly, after I posted that I realized a similar issue: the VAX
license needed to run the DIBOL compiler might not be loadable on
either Alpha or Integrity OpenVMS. Worth trying, though.

Certainly, using VEST/AEST on any application for which you don't have
the source code leaves you stuck at the version you're running, as far
as upgrades. In the case of the DIBOL compiler, though, I don't think
that's a concern. :-)

[Tad Winters]

Post by FrankS

Post by Bill Gunshannon
I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?

Honestly, after I posted that I realized a similar issue: the VAX
license needed to run the DIBOL compiler might not be loadable on
either Alpha or Integrity OpenVMS. Worth trying, though.
Certainly, using VEST/AEST on any application for which you don't have
the source code leaves you stuck at the version you're running, as far
as upgrades. In the case of the DIBOL compiler, though, I don't think
that's a concern. :-)

VESTing the compiler itself? Wouldn't it still create a VAX object file?

If VESTing the application, I'd plan on maintaining a little MicroVAX,
like a 3100, for code changes. For that matter, maybe just use a virtual
VAX for compiling DIBOL code. Where do I get the tools to VEST a
program? (I assume this must run on Alpha.) And the VESTing tool is
free, isn't it?

[FrankS]

On Feb 11, 2:18 pm, Tad Winters

VESTing the compiler itself?  Wouldn't it still create a VAX object file?

Not necessarily. Of course, I haven't tried this so it's all
theoretical and maybe it won't work at all. However, I would expect
that if it did work the Alpha versions of shareable images the
compiler relied on would generate Alpha code.

On Feb 11, 2:18 pm, Tad Winters

 Where do I get the tools to VEST a
program?  (I assume this must run on Alpha.)  And the VESTing tool is
free, isn't it?

Yes, it runs on Alpha, and it's free from HP at this URL ...

http://h71000.www7.hp.com/openvms/products/omsva/omsva.html

[Bob Gezelter]

Post by FrankS
On Feb 11, 2:18 pm, Tad Winters

Post by Tad Winters
VESTing the compiler itself? Wouldn't it still create a VAX object file?

Not necessarily. Of course, I haven't tried this so it's all
theoretical and maybe it won't work at all. However, I would expect
that if it did work the Alpha versions of shareable images the
compiler relied on would generate Alpha code.
On Feb 11, 2:18 pm, Tad Winters

Post by Tad Winters
Where do I get the tools to VEST a
program? (I assume this must run on Alpha.) And the VESTing tool is
free, isn't it?

Yes, it runs on Alpha, and it's free from HP at this URL ...
http://h71000.www7.hp.com/openvms/products/omsva/omsva.html

Tad,

Even though I am a great believer in the use of VEST and AEST as
tools, I do not think that I would recommend this path without a good
deal of study. Debugging problems in this environment (VESTed compiler
generating VAX code that is then VESTed and possibly AESTed to produce
the actual executable image) would be a challenge. I would more look
to using VEST/AEST as I illustrated in my "Strategies for Migrating
from Alpha and VAX systems to HP Integrity Servers on OpenVMS",
accessible from http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html
.

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

[Stanley F. Quayle]

Post by FrankS

VESTing the compiler itself? =A0Wouldn't it still create a VAX object =

file?

Post by FrankS
Not necessarily. Of course, I haven't tried this so it's all
theoretical and maybe it won't work at all.

Of course it would. How would the VEST'd compiler "know" it's supposed to=
generate
Alpha, Itanium, or Power PC instructions??

You'd have to VEST the result of the compiler to get something that runs o=
n Alpha, too.

Post by FrankS
However, I would expect that if it did work the Alpha versions of sharea=

ble

Post by FrankS
images the compiler relied on would generate Alpha code.

There's no shareable image that generates Alpha or any other kind of code.=
There's a
back-end tool called GEM that most VMS compilers use, but it's not somethi=
ng that you can
just use.

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[FrankS]

There's no shareable image that generates Alpha or any other kind of code.  There's a
back-end tool called GEM that most VMS compilers use, but it's not something that you can
just use.

I don't think it was too much of a stretch to guess that the GEM
functions common to all compilers would be located in a shareable
image. Since, to my knowledge, GEM generates the object files then
the Alpha version of the GEM code would generate Alpha objects with
Alpha instructions.

If you VEST the DIBOL compiler and are able to mate it to the Alpha
GEM routines then one could expect it to produce Alpha code. It
wouldn't surprise me if some of Digital's earliest efforts at porting
to Alpha involved new GEM code with VESTed compilers.

And I did say it was all theoretical and that I hadn't actually tried
it. Not knowing if the GEM entry points are the same between Alpha &
VAX (I would think they are) or how they are packaged (shareable or
linked in with each compiler) I thought I left my comments fairly open-
ended and full of the necessary disclaimers.

[Stanley F. Quayle]

Post by FrankS
I don't think it was too much of a stretch to guess that the GEM
functions common to all compilers would be located in a shareable
image. Since, to my knowledge, GEM generates the object files then
the Alpha version of the GEM code would generate Alpha objects with
Alpha instructions.

You could ask Tom Linden of Kednos. He now owns the PI/I compiler, which is available
for VAX and Alpha. It uses GEM.

That's also the reason that PI/I isn't available for Itanium -- GEM changed and HP hasn't
released the API.

Post by FrankS
If you VEST the DIBOL compiler and are able to mate it to the Alpha
GEM routines then one could expect it to produce Alpha code.

Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am
a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to
reverse-engineering something like a compiler.

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[JF Mezei]

Post by Stanley F. Quayle
Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am
a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to
reverse-engineering something like a compiler.

From a hardware point of view, you are correct. Since Alpha is no longer
developped, it is just as dead as VAX so there is no real point to
migrate VAX to Alpha.

The one big difference however is that VMS is now sigificantly more
advanced on Alpha than on VAX, so moving to Alpha does give you many
software advantages. If not for that one application, it gives you for
oither applications.

If VMS were still developped on VAX, then the Charron solution would be
the best.

Now, if VMS development has been scaled down to a point where progress
is minimal from the point of view of the user/programmer, then the gap
between VAX-VMS and Alpha-VMS will stop growing. (aka: if new version of
VMS are made onlyto support new HP hardware, this doesn't change the
value of vMS to the user/programmer).

[Bob Koehler]

Post by FrankS
I don't think it was too much of a stretch to guess that the GEM
functions common to all compilers would be located in a shareable
image. Since, to my knowledge, GEM generates the object files then
the Alpha version of the GEM code would generate Alpha objects with
Alpha instructions.

The contents of, and use of, the GEM back end is not consistent
across compilers. The concept and much of the implementation is
the same.

[JF Mezei]

Post by FrankS
If you VEST the DIBOL compiler and are able to mate it to the Alpha
GEM routines then one could expect it to produce Alpha code. It
wouldn't surprise me if some of Digital's earliest efforts at porting
to Alpha involved new GEM code with VESTed compilers.

Did any VAX compilers use GEM ?

[Tom Linden]

On Wed, 13 Feb 2008 10:41:40 -0800, JF Mezei

Post by JF Mezei

Post by FrankS
If you VEST the DIBOL compiler and are able to mate it to the Alpha
GEM routines then one could expect it to produce Alpha code. It
wouldn't surprise me if some of Digital's earliest efforts at porting
to Alpha involved new GEM code with VESTed compilers.

Did any VAX compilers use GEM ?

no

[Larry Kilgallen]

Post by FrankS
I don't think it was too much of a stretch to guess that the GEM
functions common to all compilers would be located in a shareable
image.

It might not be much of a stretch, but it is not true.

Post by FrankS
It
wouldn't surprise me if some of Digital's earliest efforts at porting
to Alpha involved new GEM code with VESTed compilers.

The actual approach was building cross compilers on VAX.

[Bob Koehler]

Post by Tad Winters
VESTing the compiler itself? Wouldn't it still create a VAX object file?

Yes, it would still create a VAX object file. And the command entry
in DCLTABLES won't VEST, IIRC, so you'ld have to extract it (try
getting the VERB utility), and enter it into the Alpha by hand.

The LINKER on Alpha will operate as a cross linker, but you'll have
to drag all the VAX object and image libraries over to where they
can be picked up while cross linking on the Alpha.

Then the resulting VAX image would have to be VESTed.

All a bit of a pain compared to running Charon-VAX or simh.

[Bob Koehler]

Post by Bill Gunshannon

Post by Hein RMS van den Heuvel
On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
I await your wisdom.

You can try VESTing the DIBOL compiler to Alpha, then AEST it to
Integrity.

I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?

You have to maintain a VAX to run the compiler. Charon-VAX or simh
would do, so you don't have to maintain VAX hardware.

Maintaing VAX hardware isn't all that difficult when you can buy
replacements cheap.

[Bill Gunshannon]

Post by Bob Koehler

Post by Bill Gunshannon

Post by Hein RMS van den Heuvel
On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
I await your wisdom.

You can try VESTing the DIBOL compiler to Alpha, then AEST it to
Integrity.

I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?

You have to maintain a VAX to run the compiler. Charon-VAX or simh
would do, so you don't have to maintain VAX hardware.
Maintaing VAX hardware isn't all that difficult when you can buy
replacements cheap.

I was thinking more along the lines of cost as this is a real business
application. You have to factor in the cost of the hardware (or the
emulator) and licenses for yet another system just to keep that old
DIBOL application running.

bill

[Stanley F. Quayle]

this not leave you stuck keeping, maintaining and paying licensing for a VAX

Paying for licenses?

I encounter customers all the time that don't know that HP owns VMS. They're certainly
not paying anyone license fees for their VAX.

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[Bill Gunshannon]

Post by Stanley F. Quayle

this not leave you stuck keeping, maintaining and paying licensing for a VAX

Paying for licenses?
I encounter customers all the time that don't know that HP owns VMS. They're certainly
not paying anyone license fees for their VAX.

Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

bill

[Malcolm Dunnett]

Post by Bill Gunshannon
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

I'd take that bet if there was any way to prove it one way or the
other. Personally I doubt there's "a lot" of that going on. For one
thing there aren't "a lot" of commercial VMS systems out there (compared
to Windows or Linux). An organization sophisticated enough to recognize
the value of VMS probably is sophisticated enough to realize the risk
they could be at by running pirate software.

I would bet that the percentage of VMS systems running with dodgy
software licensing is several orders of magnitude below the percentage
of Windows systems that are improperly licenses.

VMS licenses are actually pretty cheap these days (at least for the
"foundation" level). If you can afford an Itanium box from HP you can
probably afford the VMS license.

I believe that what the OP was actually saying was that there are
many VAX sites running older versions of VMS that they aren't paying
support fees on anymore ( which is perfectly legal as the licenses are
perpetual ).

[Richard B. Gilbert]

Post by Malcolm Dunnett

Post by Bill Gunshannon
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

I'd take that bet if there was any way to prove it one way or the
other. Personally I doubt there's "a lot" of that going on. For one
thing there aren't "a lot" of commercial VMS systems out there (compared
to Windows or Linux). An organization sophisticated enough to recognize
the value of VMS probably is sophisticated enough to realize the risk
they could be at by running pirate software.
I would bet that the percentage of VMS systems running with dodgy
software licensing is several orders of magnitude below the percentage
of Windows systems that are improperly licenses.
VMS licenses are actually pretty cheap these days (at least for the
"foundation" level). If you can afford an Itanium box from HP you can
probably afford the VMS license.
I believe that what the OP was actually saying was that there are
many VAX sites running older versions of VMS that they aren't paying
support fees on anymore ( which is perfectly legal as the licenses are
perpetual ).

A support contract on modern equipment is anything but cheap.
Supporting antiques usually costs extra!

[Bill Gunshannon]

Post by Malcolm Dunnett

Post by Bill Gunshannon
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

I'd take that bet if there was any way to prove it one way or the
other. Personally I doubt there's "a lot" of that going on. For one
thing there aren't "a lot" of commercial VMS systems out there (compared
to Windows or Linux).

I guess "a lot" is rather subjective. 10 VMS sites doing it would be a
lot more relative to the number of legitimate VMS sites than 10,000 MS
sites relative to the number of MS systems.

Post by Malcolm Dunnett
An organization sophisticated enough to recognize
the value of VMS probably is sophisticated enough to realize the risk
they could be at by running pirate software.

You would think that, but my experience is quite different. I have spent
a lot of time and effort convincing people here that they can't buy one
copy of a program and then install it on every machine in site.

Post by Malcolm Dunnett
I would bet that the percentage of VMS systems running with dodgy
software licensing is several orders of magnitude below the percentage
of Windows systems that are improperly licenses.

Again, it probably depends on your interpretation of "commercial use".
I had a lot of people tell me that I should have just been using a
hobbyist license for the machines I set up for the students to play
with. That is certainly not the way I see it and I never did it.
Same thing with the PDP-11's I set up. There is no hobbyist or edu
program for them and still I had dozens of people telling me to just
go ahead and do it. Software piracy is a bigger problem than many
people want to admit and it is not limited to MS products.

Post by Malcolm Dunnett
VMS licenses are actually pretty cheap these days (at least for the
"foundation" level). If you can afford an Itanium box from HP you can
probably afford the VMS license.

But we are not talking about Itaniums, we are talking about VAX.

Post by Malcolm Dunnett
I believe that what the OP was actually saying was that there are
many VAX sites running older versions of VMS that they aren't paying
support fees on anymore ( which is perfectly legal as the licenses are
perpetual ).

Not the way I read it: "Paying for licenses?
I encounter customers all the time that don't know
that HP owns VMS. They're certainly not paying anyone
license fees for their VAX."

Hard to interpret that as anything short of running VAX without
a valid license.

bill

[Stanley F. Quayle]

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time that don't know
that HP owns VMS. They're certainly not paying anyone
license fees for their VAX."
Hard to interpret that as anything short of running VAX without
a valid license.

What I meant was that the licenses that came with their VAX, good forever, stay good for,
well, forever.

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[Bill Gunshannon]

Post by Stanley F. Quayle

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time that don't know
that HP owns VMS. They're certainly not paying anyone
license fees for their VAX."
Hard to interpret that as anything short of running VAX without
a valid license.

What I meant was that the licenses that came with their VAX, good forever, stay good for,
well, forever.

OK, I stand corrected. I guess I have seen so much violation of IP
rights I have just become too cynical.

bill

[FrankS]

Post by Stanley F. Quayle
What I meant was that the licenses that came with their VAX, good forever, stay good for,
well, forever.

I don't remember what the license policies were back when Digital was
issuing them. Current HP policy is that the license you buy is good
for the version you buy, and nothing else. In order to install new
versions you must be on a software support contract which gives you
the "right to new versions" (RTNV).

So, if you buy an OpenVMS Base license today at the current version
(v8.3-1H1) and don't get a software support contract then you are not
allowed to upgrade, say, to v8.4 when it is issued. You can continue
to run v8.3-1H1 forever, though.

[Richard B. Gilbert]

Post by FrankS

Post by Stanley F. Quayle
What I meant was that the licenses that came with their VAX, good forever, stay good for,
well, forever.

I don't remember what the license policies were back when Digital was
issuing them. Current HP policy is that the license you buy is good
for the version you buy, and nothing else. In order to install new
versions you must be on a software support contract which gives you
the "right to new versions" (RTNV).
So, if you buy an OpenVMS Base license today at the current version
(v8.3-1H1) and don't get a software support contract then you are not
allowed to upgrade, say, to v8.4 when it is issued. You can continue
to run v8.3-1H1 forever, though.

DEC's policy was the same!

[Richard B. Gilbert]

Post by Bill Gunshannon

Post by Stanley F. Quayle

this not leave you stuck keeping, maintaining and paying licensing for a VAX

Paying for licenses?
I encounter customers all the time that don't know that HP owns VMS. They're certainly
not paying anyone license fees for their VAX.

Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

And some of us bought systems with licenses included!

[Wilm Boerhout]

on 13-2-2008 17:38 Richard B. Gilbert wrote...

Post by Richard B. Gilbert
And some of us bought systems with licenses included!

If you bought them new, that's OK. If you bought'm second hand, (VAX or
Alpha), it's only OK for the base OS license + "hardware attached"
software (Category 1 software). All other licenses are not transferable
outside of the first owner legal entity (relicensing), although they are
transferable within the original legal entity (redesignation).
Relicensing is not free where it is permitted. Written permission from
HP required in all cases.

Software License Policy
http://licensing.hp.com/swl/view.slm?page=xfer

I'm not sure whether HP staff does enforce this policy, well, then
again, I'm sure they don't. When I was a Digital employee in the 80's,
everyone selling second hand knew this. It was enforced then.

[Tom Linden]

On Wed, 13 Feb 2008 10:37:48 -0800, Wilm Boerhout =

Post by Wilm Boerhout
on 13-2-2008 17:38 Richard B. Gilbert wrote...

Post by Richard B. Gilbert
And some of us bought systems with licenses included!

If you bought them new, that's OK. If you bought'm second hand, (VAX o=

r =

Post by Wilm Boerhout
Alpha), it's only OK for the base OS license + "hardware attached" =
software (Category 1 software). All other licenses are not transferabl=

e =

Post by Wilm Boerhout
outside of the first owner legal entity (relicensing), although they a=

re =

Post by Wilm Boerhout
transferable within the original legal entity (redesignation). =
Relicensing is not free where it is permitted. Written permission from=

=

Post by Wilm Boerhout
HP required in all cases.
Software License Policy
http://licensing.hp.com/swl/view.slm?page=3Dxfer
I'm not sure whether HP staff does enforce this policy, well, then =
again, I'm sure they don't. When I was a Digital employee in the 80's,=

=

Post by Wilm Boerhout
everyone selling second hand knew this. It was enforced then.

As a matter of law if you are aware of a violation and don't act to enfo=
rce
your rights you may abdicate them



-- =

PL/I for OpenVMS
www.kednos.com

[Richard B. Gilbert]

Post by Wilm Boerhout
on 13-2-2008 17:38 Richard B. Gilbert wrote...

Post by Richard B. Gilbert
And some of us bought systems with licenses included!

If you bought them new, that's OK. If you bought'm second hand, (VAX or
Alpha), it's only OK for the base OS license + "hardware attached"
software (Category 1 software). All other licenses are not transferable
outside of the first owner legal entity (relicensing), although they are
transferable within the original legal entity (redesignation).
Relicensing is not free where it is permitted. Written permission from
HP required in all cases.

I bought from a dealer and the machine was new. This was back in the
late 1990's when the AlphaStation 200 went EOL.

[JF Mezei]

Post by Bill Gunshannon
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

I don't think so. Your presumption would assume that there would have
been new customers who started to use VMS since the hobbyisty programme
was started and who would have decided to use those licences "illegally".

I would think that almost all customers are long tike VMS customers who
have had their licences for a very long time even if they no longer pay
for the support fees.

Where hobbyist may be "abused" are those legitimate shops needing a new
licence to compile some freeware utility etc and being unable to reach
Digital to buy such licence, they go the way of hobbyist.

[Bill Gunshannon]

Post by JF Mezei

Post by Bill Gunshannon
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.

I don't think so. Your presumption would assume that there would have
been new customers who started to use VMS since the hobbyisty programme
was started and who would have decided to use those licences "illegally".

No, no such presumption. It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........

Post by JF Mezei
I would think that almost all customers are long tike VMS customers who
have had their licences for a very long time even if they no longer pay
for the support fees.

Seems like you are making suppositions, too.

Post by JF Mezei
Where hobbyist may be "abused" are those legitimate shops needing a new
licence to compile some freeware utility etc and being unable to reach
Digital to buy such licence, they go the way of hobbyist.

And how is this any differnt than what I said up above? Not being
able to contact HP to buy a license does not change the legal or
moral responsibility to have a legitimate license in place before
using a machine for business purposes. Believe it or not, the
dificulty or inability to contact Mentec was the most common reason
given for running PDP-11's without valid licenses.

bill

[Stanley F. Quayle]

Post by Bill Gunshannon
No, no such presumption. It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........

DSPP members get VMS licenses for free, including VAX ones...

--Stan Quayle
Quayle Consulting Inc.

----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[Bill Gunshannon]

Post by Stanley F. Quayle

Post by Bill Gunshannon
No, no such presumption. It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........

DSPP members get VMS licenses for free, including VAX ones...

What does DSPP membership cost?

bill

[Bill Gunshannon]

Post by Bill Gunshannon

Post by Stanley F. Quayle

Post by Bill Gunshannon
No, no such presumption. It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........

DSPP members get VMS licenses for free, including VAX ones...

What does DSPP membership cost?

Nevermind. I eventually found it (but it wan't easy or obvious.)
Of course, there are other requirements that would make my example
above not qualify anyway. So we're back to: someone who needs
another machine to test something and they are only going to need
it for a month or two, so........ :-)

bill

[V***@SendSpamHere.ORG]

This post might be inappropriate. Click to display it.

[Wilm Boerhout]

on 13-2-2008 20:52 Stanley F. Quayle wrote...

Post by Stanley F. Quayle
DSPP members get VMS licenses for free, including VAX ones...

Yes, but not to run their *own* business applications on. If you want to
sell email services using your Alpha as a server, DSPP licensing is not
enough. Demo purposes, OK.

[FrankS]

No, no such presumption.  It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........

HP can and does issue temporary licenses. I would think they're a bit
tight-fisted about them and probably don't do it unless you're on a
support contract.

[Wilm Boerhout]

on 13-2-2008 19:40 JF Mezei wrote...
[snip]

Post by JF Mezei
Where hobbyist may be "abused" are those legitimate shops needing a new
licence to compile some freeware utility etc and being unable to reach
Digital to buy such licence, they go the way of hobbyist.

No excuses in my country. It is still possible (and not very difficult
either) for me and my customers to buy VMS licenses (the old Q*-*****-**
scheme). VAX as well as Alpha. Whether you like the price for your
VAX/DEC/HP C compiler is another thing...

[Jeffrey H. Coffield]

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.

Basic or Cobol would be my choice, in that order. We have done a number
of conversions from other systems to OpenVMS as well as upgrades. One
approach that has been successful on a couple of those is to write code
converters that get 90 to 95% of the standard code converted and then
tackle the rest by hand.

If you would like to discuss this in more detail, including us possibly
helping you in the conversion, please call me at [phone].

Jeff Coffield
www.digitalsynergyinc.com

[Wilm Boerhout]

on 11-2-2008 0:34 Tad Winters wrote...

Post by Tad Winters
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)

Having read up on this thread, an weighing the possible cost and risk of
all different kinds of ports/migrations, I seriously think you are
robbing your customer of the best possible solution: CHARON-VAX.

Mind you, although my company resells CHARON-VAX products, I will not
benefit from this particular deal, or any deal in your geography. I have
implemented this product (and CHARON-AXP) many times in heavy production
environments, and it (and Windows alongside it) has never failed me (or
my customers). Windows is really only used in the installation and
program load stages. When it's running, it's in the processor L2 cache,
with Windows running beside in another processor. Windows *is*
remarkably stable when it's not used. Services may be stopped and
disabled, and especially when you don't connect the Windows instance to
any network, it will run for months/quarters/years without intervention.

No license issues, instant spectacular performance improvement, only
disadvantage: up and running in the time it takes to do a
backup/restore. Not free though, but well within your apparent budget.

So, set religion aside, and do what's best for your customer.

[Peter Weaver]

Post by Tad Winters
...
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
...

OK, I am a CHARON-VAX reseller, but I need to point out that CHARON-VAX and
CHARON-AXP on Windows are very stable. I have many customers who are true
VMS bigots running CHARON-VAX and CHARON-AXP and they are happy that the
boxes are as stable or even more stable than the old hardware. You can run
CHARON as an appliance and turn off everything that Windows does not need,
even turn off the IP stack so Windows can not talk to anything on the
Ethernet. If Windows is not allowed to see the network then it is extremely
stable.

Contact your nearest CHARON-VAX reseller (or me if you there is nobody in
driving distance of your customer, I usually only sell to customers in
Canada just because of the issues dealing across a border but I would be
happy to help) and give CHARON-VAX a try. In the end you will get a faster
CPU, faster memory and faster disk I/O without any changes except maybe some
physical disk names. I have customers who went from VAX 4000 machines to
CHARON-VAX and had batch jobs run in minutes rather than hours.

Peter Weaver
www.weaverconsulting.ca
CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial
Hardware

[Bob Gezelter]

On Feb 10, 6:34 pm, Tad Winters

Post by Tad Winters
Let me start by saying, this is _not_ meant to start a war over
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.

Tad,

For porting, it depends on the style of code. If you want integrated
(non-custom) support for access to indexed and other files, you are
probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
difficult to access keyed files from C/C++, but it will be in the
nature of a non-integrated add-in (or in the case of C++, probably a
class).

Hoiwever, before I go deep into porting the code, I would invest some
effort to tuning the system. Having been involved in tuning many such
systems over the years, I always caution clients that performance
improvements can almost always be achieved with far less effort than
porting to a new language. Often, significant results can be achieved
with a relatively small scale consulting project (days to a week or
so). It is not possible to make blanket assurances, but that has been
my overwhelming experience. In any event, porting 300,000 lines of
code is going to be a non-trivial project, and the performance work is
less expensive by orders of magnitude (e.g., 1% - 5% of a conversion
project). [Disclosure: My firm does provide services in this area, as
well as tools development ].

Peak load performance problems are often relatively straightforward to
address, at far less cost.

Charon-VAX is also, if I recall correctly, available on OpenVMS-Alpha/
Itanium for VAX emulation, that may be another possibility (as would
the use of one of the freeware emulators).

I hope that the above is helpful. If I have been unclear, please let
me know.

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

[Wilm Boerhout]

on 11-2-2008 20:00 Bob Gezelter wrote...
[snip]

Post by Bob Gezelter
Charon-VAX is also, if I recall correctly, available on OpenVMS-Alpha/
Itanium for VAX emulation, that may be another possibility (as would
the use of one of the freeware emulators).

On Alpha, yes, Itanium, no. Not so spectacular performance improvement
on readily available / cheap Alpha's though.

You cannot legally transfer your VMS licenses to SIMH or another
freeware emulator.

[John Reagan]

Post by Bob Gezelter
For porting, it depends on the style of code. If you want integrated
(non-custom) support for access to indexed and other files, you are
probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
difficult to access keyed files from C/C++, but it will be in the
nature of a non-integrated add-in (or in the case of C++, probably a
class).

Not to divert the topic, but Pascal has just as good support for indexed
and relative files as the langauges listed above. Well, you can't
CREATE a file with segmented keys from Pascal without resorting to a
USERACTION routine, but you can open an existing file and even use FINDK
to lookup a record.

[Tad Winters]

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above. Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language. Why did Digital drop it
with the move to Alpha?

[Hank Vander Waal]

It IS a great language.

They did not drop it - they farmed it out to some one who was still
developing it. One less thing for them to worry about
It is now DBL and runs on all kinds of platforms.


-----Original Message-----
From: Tad Winters [mailto:***@verizon.net]
Sent: Tuesday, February 12, 2008 7:34 PM
To: Info-***@Mvb.Saic.Com
Subject: Re: DIBOL to <different language>

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above. Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language. Why did Digital drop it
with the move to Alpha?

[Doug Phillips]

On Feb 12, 6:33 pm, Tad Winters

Post by Tad Winters

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above. Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language. Why did Digital drop it
with the move to Alpha?

To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
time of the Alpha port, Synergex (or was it still DISC then?) had
extended DBL to a higher level, while still keeping DIBOL
compatibility, and they were going to port DBL to Alpha anyway. DEC
likely decided that their own resources would be better utilized in
other areas.

Someone only familiar with DEC DIBOL should not harshly judge Synery/
DE (the modern name) by that standard any more than someone who hasn't
used VMS since early VAX should prejudge todays VMS by that
experience.

Beyond setting up the user environment as needed with any platform
change, moving from DIBOL to the Synergy product on VMS usually
involves little more than compile, rebuild your libraries and link
your apps. Then, you can play with all of the fancy new stuff
(Synergex offers training, too.)

We still have some apps running today that started life on
CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
little more effort than that. And, don't overlook the DIBOL features
you take for granted, like the built-in understanding and support of
RMS records/files and the convenience of the Message Manager, that
you'll need to "bolt-on" to most other languages.

Like HVW said, too, DBL can move to non-VMS platforms easier than most
languages. If your stuff is overly hard-coded with VMS specifics then
that would be a handicap for other languages, too. But, even if it is,
DBL might have a built-in subroutine or function that you could use
instead without having to reinvent your own or find a third-party
substitute.

On non-RMS platforms, DBL has a built-in file/record system that to
the programmer looks pretty much like RMS (even has RFA's.) We ported
an entire accounting system to Windows in only a few weeks. All of the
data files were stripped to sequential, copied over, and we used their
utilities to reload them. The first time we did this we were amazed at
how easy it was. It isn't 100% simple, but it's 99.99% easier than
converting that much code to any other language I know of.

Porting everything to a new language sounds like a programmers idea of
fun, but what's it really going to cost the business?

[u***@gmail.com]

Post by Doug Phillips
On Feb 12, 6:33 pm, Tad Winters

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above.  Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language.  Why did Digital drop it
with the move to Alpha?

To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
time of the Alpha port, Synergex (or was it still DISC then?) had
extended DBL to a higher level, while still keeping DIBOL
compatibility, and they were going to port DBL to Alpha anyway. DEC
likely decided that their own resources would be better utilized in
other areas.
Someone only familiar with DEC DIBOL should not harshly judge Synery/
DE (the modern name) by that standard any more than someone who hasn't
used VMS since early VAX should prejudge todays VMS by that
experience.
Beyond setting up the user environment as needed with any platform
change, moving from DIBOL to the Synergy product on VMS usually
involves little more than compile, rebuild your libraries and link
your apps. Then, you can play with all of the fancy new stuff
(Synergex offers training, too.)
We still have some apps running today that started life on
CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
little more effort than that. And, don't overlook the DIBOL features
you take for granted, like the built-in understanding and support of
RMS records/files and the convenience of the Message Manager, that
you'll need to "bolt-on" to most other languages.
Like HVW said, too, DBL can move to non-VMS platforms easier than most
languages. If your stuff is overly hard-coded with VMS specifics then
that would be a handicap for other languages, too. But, even if it is,
DBL might have a built-in subroutine or function that you could use
instead without having to reinvent your own or find a third-party
substitute.
On non-RMS platforms, DBL has a built-in file/record system that to
the programmer looks pretty much like RMS (even has RFA's.) We ported
an entire accounting system to Windows in only a few weeks. All of the
data files were stripped to sequential, copied over, and we used their
utilities to reload them. The first time we did this we were amazed at
how easy it was. It isn't 100% simple, but it's 99.99% easier than
converting that much code to any other language I know of.
Porting everything to a new language sounds like a programmers idea of
fun, but what's it really going to cost the business?- Hide quoted text -
- Show quoted text -

functionality is not the issue ... COST is ...

there are many small businesses with vax DIBOL packages
from many companies who cannot afford to spend $10,000+
dollars to go to synergy ... and unless synergy gives a price
break, they will loose these small customers which is exactly
the stupid move DEC made ...

call synergy first to try to get a price break, if not look at
at vaxstation 4000-96 or vest from vax to alpha ...

DO NOT PORT to something else which would cost a lot
more money ...

solutions exist ...

[Doug Phillips]

Post by u***@gmail.com

Post by Doug Phillips
On Feb 12, 6:33 pm, Tad Winters

-snipped-

Porting everything to a new language sounds like a programmers idea of
fun, but what's it really going to cost the business?

functionality is not the issue ... COST is ...

How much will it cost to duplicate the functionality? I can't separate
the two in my mind. Maybe you can. Like someone who hangs around here
is fond of saying: The choices are good, fast and cheap; pick two.

Post by u***@gmail.com
there are many small businesses with vax DIBOL packages
from many companies who cannot afford to spend $10,000+
dollars to go to synergy

An operation with 150 interactive users likely has annual revenue of
at least $10M - $20M/year. A company running an old VAX for all of
their mission-critical has likely not spent their industry average
percentage of income on IT for years, and has become "spoiled."
Sometimes reality sucks.

Post by u***@gmail.com
... and unless synergy gives a price
break, they will loose these small customers which is exactly
the stupid move DEC made ...
call synergy first to try to get a price break,

Or at least get an actual number that could be used for cost analysis.

Post by u***@gmail.com
if not look at
at vaxstation 4000-96 or vest from vax to alpha ...

Both short-sighted choices, IMO, if the future is of any concern. The
old saw "penny wise and pound foolish" comes to mind.

Post by u***@gmail.com
DO NOT PORT to something else which would cost a lot
more money ...

If cost is the only factor, or the company doesn't expect to be around
for long, then they shouldn't do much of anything. If things are
working fine except for a few high-load times, then some job
rescheduling might be enough.

Post by u***@gmail.com
solutions exist ...

and it's usually better to pick a good one.

[Tad Winters]

Post by Doug Phillips
On Feb 12, 6:33 pm, Tad Winters

Post by Tad Winters
It seems like DIBOL was quite a good language. Why did Digital
drop it with the move to Alpha?

To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
time of the Alpha port, Synergex (or was it still DISC then?) had

It was still DISC.

Post by Doug Phillips
extended DBL to a higher level, while still keeping DIBOL
compatibility, and they were going to port DBL to Alpha anyway. DEC
likely decided that their own resources would be better utilized in
other areas.

So they decided that it was better to give someone else the business
rather than compete. That's an interesting way to do business.

Post by Doug Phillips
Someone only familiar with DEC DIBOL should not harshly judge
Synery/ DE (the modern name) by that standard any more than someone
who hasn't used VMS since early VAX should prejudge todays VMS by
that experience.

"harshly judge"? Who's doing that?

Post by Doug Phillips
Beyond setting up the user environment as needed with any platform
change, moving from DIBOL to the Synergy product on VMS usually
involves little more than compile, rebuild your libraries and link
your apps. Then, you can play with all of the fancy new stuff
(Synergex offers training, too.)

With the move of some other code from DIBOL to DBL, there were a number
of things that didn't just compile. I remember one item was the
DISPLAY statements which didn't work with field attributes. Also, the
SLICE subroutine that was included in DIBOL was absent in DBL.
Strangely, some other programmer put in some conditional compilation
statements to avoid calling it under DBL. When I found it later, I
just wrote a SLICE subroutine to accomplish the task. (It was only a
few lines of code.)

Post by Doug Phillips
We still have some apps running today that started life on
CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
little more effort than that. And, don't overlook the DIBOL features
you take for granted, like the built-in understanding and support of
RMS records/files and the convenience of the Message Manager, that
you'll need to "bolt-on" to most other languages.

We had a customer who used TSX+ and DBL. We also had one on RSTS (I
think) in which we had to carefully craft the linking of the code
because of 32K code segments.
We definite use the Message Manager. I hadn't really considered that.
To address that use, I guess I'd have to write a replacement. Yikes,
that sounds like a whole lot more work.

Post by Doug Phillips
Like HVW said, too, DBL can move to non-VMS platforms easier than
most languages. If your stuff is overly hard-coded with VMS
specifics then that would be a handicap for other languages, too.
But, even if it is, DBL might have a built-in subroutine or function
that you could use instead without having to reinvent your own or
find a third-party substitute.

If the goal was to change platforms, I would prefer to not carry the
old code along. I'd rather just look at the old functionality and
write from scratch.

Post by Doug Phillips
On non-RMS platforms, DBL has a built-in file/record system that to
the programmer looks pretty much like RMS (even has RFA's.) We
ported an entire accounting system to Windows in only a few weeks.
All of the data files were stripped to sequential, copied over, and
we used their utilities to reload them. The first time we did this
we were amazed at how easy it was. It isn't 100% simple, but it's
99.99% easier than converting that much code to any other language I
know of.
Porting everything to a new language sounds like a programmers idea
of fun, but what's it really going to cost the business?

I'm not sure I'd call it fun, but it is an excuse to create what I
would consider better code, exchanging cryptic variable name for one
with clear meaning, moving away from the idea that a particular
variable has to be used for completely different purposes, just to save
memory, allowing the applications to make use of the full size of
screen when terminals (emulators) have move than 24 rows and/or 80
columns, etc.

[Doug Phillips]

On Feb 13, 3:32 pm, Tad Winters

Post by Tad Winters

Post by Doug Phillips
On Feb 12, 6:33 pm, Tad Winters

Post by Tad Winters
It seems like DIBOL was quite a good language. Why did Digital
drop it with the move to Alpha?

To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
time of the Alpha port, Synergex (or was it still DISC then?) had

It was still DISC.

That's what I thought, but I didn't look it up.

Post by Tad Winters

Post by Doug Phillips
extended DBL to a higher level, while still keeping DIBOL
compatibility, and they were going to port DBL to Alpha anyway. DEC
likely decided that their own resources would be better utilized in
other areas.

So they decided that it was better to give someone else the business
rather than compete. That's an interesting way to do business.

Yea, bean-counters tend to look at cost-benefit kinds of things. DIBOL
wasn't really making enough money to justify the cost of porting it to
compete with DBL, which was a "better" DIBOL.

So, once DISC bought out Softbol and DEC handed them the Alpha, DISC
had a monopoly on the language. I think that fact more than any other
ticked some people off and caused them to bail.

Post by Tad Winters

Post by Doug Phillips
Someone only familiar with DEC DIBOL should not harshly judge
Synery/ DE (the modern name) by that standard any more than someone
who hasn't used VMS since early VAX should prejudge todays VMS by
that experience.

"harshly judge"? Who's doing that?

My mistake.

Post by Tad Winters

Post by Doug Phillips
Beyond setting up the user environment as needed with any platform
change, moving from DIBOL to the Synergy product on VMS usually
involves little more than compile, rebuild your libraries and link
your apps. Then, you can play with all of the fancy new stuff
(Synergex offers training, too.)

With the move of some other code from DIBOL to DBL, there were a number
of things that didn't just compile. I remember one item was the
DISPLAY statements which didn't work with field attributes. Also, the
SLICE subroutine that was included in DIBOL was absent in DBL.
Strangely, some other programmer put in some conditional compilation
statements to avoid calling it under DBL. When I found it later, I
just wrote a SLICE subroutine to accomplish the task. (It was only a
few lines of code.)

The screen attributes were something I'd forgotten about. All of our
screen I/O was done (or was *supposed* to be done:-) in subroutines,
though, and those were simple to convert. The compiler uncovered the
few "stragglers" and that forced us to clean things up. Not even a
days worth of work if I recall.

I don't recall ever using SLICE so that was not a problem. ISTR, now
that you've mentioned those, there were a few other minor differences
that were easy to fix or just needed a DBLOPT setting. We'd probably
done most of the work when we took the code to TSX, which was before
we ever saw a VAX.

Post by Tad Winters

Post by Doug Phillips
We still have some apps running today that started life on
CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
little more effort than that. And, don't overlook the DIBOL features
you take for granted, like the built-in understanding and support of
RMS records/files and the convenience of the Message Manager, that
you'll need to "bolt-on" to most other languages.

We had a customer who used TSX+ and DBL. We also had one on RSTS (I
think) in which we had to carefully craft the linking of the code
because of 32K code segments.

Overlays. Yuck. Bad memories. The need for linking overlays was one of
the reasons our code was so modular, though, and that made many things
easier to port. Our code was no where near as "modular" (if that's the
word) as the MCBA stuff, though. Their code was hard to deal with, and
we inherited a few of their abandoned sites to support. Most we
converted to our stuff for near-cost just to get away from maintaining
that ####. Some we lost to merger or acquisition, but some of those
sites are still around today running on VMS (not exactly using the
same old code, though:-)

Post by Tad Winters
We definite use the Message Manager. I hadn't really considered that.
To address that use, I guess I'd have to write a replacement. Yikes,
that sounds like a whole lot more work.

SO many things we've come to take for granted;-)

Post by Tad Winters

Post by Doug Phillips
Like HVW said, too, DBL can move to non-VMS platforms easier than
most languages. If your stuff is overly hard-coded with VMS
specifics then that would be a handicap for other languages, too.
But, even if it is, DBL might have a built-in subroutine or function
that you could use instead without having to reinvent your own or
find a third-party substitute.

If the goal was to change platforms, I would prefer to not carry the
old code along. I'd rather just look at the old functionality and
write from scratch.

More fun. Much more time. Much more $$$.

Post by Tad Winters

Post by Doug Phillips
On non-RMS platforms, DBL has a built-in file/record system that to
the programmer looks pretty much like RMS (even has RFA's.) We
ported an entire accounting system to Windows in only a few weeks.
All of the data files were stripped to sequential, copied over, and
we used their utilities to reload them. The first time we did this
we were amazed at how easy it was. It isn't 100% simple, but it's
99.99% easier than converting that much code to any other language I
know of.
Porting everything to a new language sounds like a programmers idea
of fun, but what's it really going to cost the business?

I'm not sure I'd call it fun, but it is an excuse to create what I
would consider better code, exchanging cryptic variable name for one
with clear meaning, moving away from the idea that a particular
variable has to be used for completely different purposes, just to save
memory, allowing the applications to make use of the full size of
screen when terminals (emulators) have move than 24 rows and/or 80
columns, etc.

Cleaning up variable names and spaghetti code and such might be good,
and porting to a different language will mean finding new ways to do
some things anyway. The temptation to "fix" or "improve" too many
things, though, means going "off-script." Debugging gets more
difficult because the new stuff no longer follows the old flow and if
something doesn't work you have to determine if the bug was in the
original logic and has now decided to surface, or was caused by an
"improvement." Been there. I've had better results porting the logic
"feature for feature," noting where I'd make any significant changes,
making allowances in the code and implementing them after the new code
has been tested and proven sound. Each to his own, though:-)

I've become so accustomed to the power of DBL that using any other
language for business apps seems painful, so I guess I am a bit biased.
8^O

[Tad Winters]

Doug Phillips <***@netscape.net> wrote in news:eebcffae-f4a5-4df2-b84e-***@s12g2000prg.googlegroups.com:

[..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any other
language for business apps seems painful, so I guess I am a bit
biased. 8^O

So you're still coding in DBL? If I could find some more companies in my
area in need of someone to maintain their DBL code, I'd be pretty happy.
The 2 companies I do occasional work for right now just ask for minor
changes or minor new features. The last "large" projects were
implementing faxing of invoices (a failure since they counted on using a
VOIP line), emailing invoices (CSV file created and transferred to a *nix
box at an ISP to be converted to PDF), and parsing a tab delimited file,
received via ftp from an ISP hosted web server, into an order.

[u***@gmail.com]

On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any other
language for business apps seems painful, so I guess I am a bit
biased. 8^O

So you're still coding in DBL?  If I could find some more companies in my
area in need of someone to maintain their DBL code, I'd be pretty happy.  
The 2 companies I do occasional work for right now just ask for minor
changes or minor new features.  The last "large" projects were
implementing faxing of invoices (a failure since they counted on using a
VOIP line), emailing invoices (CSV file created and transferred to a *nix
box at an ISP to be converted to PDF), and parsing a tab delimited file,
received via ftp from an ISP hosted web server, into an order.

goldfax and dibol work together

[u***@gmail.com]

On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any other
language for business apps seems painful, so I guess I am a bit
biased. 8^O

So you're still coding in DBL?  If I could find some more companies in my
area in need of someone to maintain their DBL code, I'd be pretty happy.  
The 2 companies I do occasional work for right now just ask for minor
changes or minor new features.  The last "large" projects were
implementing faxing of invoices (a failure since they counted on using a
VOIP line), emailing invoices (CSV file created and transferred to a *nix
box at an ISP to be converted to PDF), and parsing a tab delimited file,
received via ftp from an ISP hosted web server, into an order.

goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...

why not run their own web server? purveyor/wasd and dibol/dcl as
script languages work terrific ...

txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...

sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...

vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...

[Tad Winters]

Post by u***@gmail.com
On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any
other language for business apps seems painful, so I guess I am a
bit biased. 8^O

So you're still coding in DBL?  If I could find some more companies
in my area in need of someone to maintain their DBL code, I'd be
pretty happy.   The 2 companies I do occasional work for right now
just ask for minor changes or minor new features.  The last "large"
projects were implementing faxing of invoices (a failure since they
counted on using a VOIP line), emailing invoices (CSV file created
and transferred to a *nix box at an ISP to be converted to PDF),
and parsing a tab delimited file, received via ftp from an ISP
hosted web server, into an order.

goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...

I suggested looking at other faxing software before the project
started, but the lead said he wanted to stick with what he'd used
before.

Post by u***@gmail.com
why not run their own web server? purveyor/wasd and dibol/dcl as
script languages work terrific ...

The system is already overloaded.

Post by u***@gmail.com
txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...

I looked into txt2pdf and wanted to use it, but I couldn't get them to
make the necessary changes with their ISP, i.e. MX record for their IP
address, DNS IP addresses for the VMS system to do lookups for sending
email and preferably letting the VMS system do zone transfers (to be a
secondary.)
PMDF would be more software on an already overloaded system, more
money, and would require them to open port 25 on their firewall. Since
they're managing the firewall themselves, I don't think I could get
them to do it. Also, anti-spam would be more load and more money.

Post by u***@gmail.com
sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...

Once again, more money. Someone else mentioned they must not be
spending enough, based on what their revenues must be for having 150
concurrent users. I don't know what their revenues are, though I could
look, since I have access to their system, but it's not my business.
If I really need to know, I'll ask. If it's only to tell them they're
not spending enough, then it's just as easy to tell them what is called
for in the industry.

Post by u***@gmail.com
vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...

[u***@gmail.com]

On Feb 14, 1:49 am, Tad Winters

Post by Tad Winters

Post by u***@gmail.com
On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any
other language for business apps seems painful, so I guess I am a
bit biased. 8^O

So you're still coding in DBL?  If I could find some more companies
in my area in need of someone to maintain their DBL code, I'd be
pretty happy.   The 2 companies I do occasional work for right now
just ask for minor changes or minor new features.  The last "large"
projects were implementing faxing of invoices (a failure since they
counted on using a VOIP line), emailing invoices (CSV file created
and transferred to a *nix box at an ISP to be converted to PDF),
and parsing a tab delimited file, received via ftp from an ISP
hosted web server, into an order.

goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...

I suggested looking at other faxing software before the project
started, but the lead said he wanted to stick with what he'd used
before.

Post by u***@gmail.com
why not run their own web server?  purveyor/wasd and dibol/dcl as
script languages work terrific ...

The system is already overloaded.

Post by u***@gmail.com
txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...

I looked into txt2pdf and wanted to use it, but I couldn't get them to
make the necessary changes with their ISP, i.e. MX record for their IP
address, DNS IP addresses for the VMS system to do lookups for sending
email and preferably letting the VMS system do zone transfers (to be a
secondary.)
PMDF would be more software on an already overloaded system, more
money, and would require them to open port 25 on their firewall.  Since
they're managing the firewall themselves, I don't think I could get
them to do it.  Also, anti-spam would be more load and more money.

Post by u***@gmail.com
sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...

Once again, more money.  Someone else mentioned they must not be
spending enough, based on what their revenues must be for having 150
concurrent users.  I don't know what their revenues are, though I could
look, since I have access to their system, but it's not my business.  
If I really need to know, I'll ask.  If it's only to tell them they're
not spending enough, then it's just as easy to tell them what is called
for in the industry.

Post by u***@gmail.com
vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...- Hide quoted text -

- Show quoted text -- Hide quoted text -
- Show quoted text -

put pmdf on a separate DS10L ... they only cost $200
plus memory and disks from island ... a ds10l is cheap
and would make a great mailserver or webserver ...

you do not have to run everything on one system ...
alphas are cheap enough to load balance with
multiple systems ...

ds20e systems were on ebay for $800 last year ...
for $1500 you could have bought another 667mhz
cpu card and 4gb mem ... just last week there was
an es40 with 4 833mhz cpus for only $3000 ...

can't they afford $200 for another alpha?

[u***@gmail.com]

On Feb 14, 1:49 am, Tad Winters

Post by Tad Winters

Post by u***@gmail.com
On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any
other language for business apps seems painful, so I guess I am a
bit biased. 8^O

So you're still coding in DBL?  If I could find some more companies
in my area in need of someone to maintain their DBL code, I'd be
pretty happy.   The 2 companies I do occasional work for right now
just ask for minor changes or minor new features.  The last "large"
projects were implementing faxing of invoices (a failure since they
counted on using a VOIP line), emailing invoices (CSV file created
and transferred to a *nix box at an ISP to be converted to PDF),
and parsing a tab delimited file, received via ftp from an ISP
hosted web server, into an order.

goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...

I suggested looking at other faxing software before the project
started, but the lead said he wanted to stick with what he'd used
before.

Post by u***@gmail.com
why not run their own web server?  purveyor/wasd and dibol/dcl as
script languages work terrific ...

The system is already overloaded.

Post by u***@gmail.com
txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...

I looked into txt2pdf and wanted to use it, but I couldn't get them to
make the necessary changes with their ISP, i.e. MX record for their IP
address, DNS IP addresses for the VMS system to do lookups for sending
email and preferably letting the VMS system do zone transfers (to be a
secondary.)
PMDF would be more software on an already overloaded system, more
money, and would require them to open port 25 on their firewall.  Since
they're managing the firewall themselves, I don't think I could get
them to do it.  Also, anti-spam would be more load and more money.

Post by u***@gmail.com
sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...

Once again, more money.  Someone else mentioned they must not be
spending enough, based on what their revenues must be for having 150
concurrent users.  I don't know what their revenues are, though I could
look, since I have access to their system, but it's not my business.  
If I really need to know, I'll ask.  If it's only to tell them they're
not spending enough, then it's just as easy to tell them what is called
for in the industry.

Post by u***@gmail.com
vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...- Hide quoted text -

- Show quoted text -- Hide quoted text -
- Show quoted text -

why have IP and be afraid of using it?

have they ever heard of internal networks?

vms doesn't get viruses or trojans or hacked when properly
configured ... they are not getting the most out of their vms
investment ... how are these guys even in business if they
are afraid to use IP? tell them just to go back to phones
and paper and just manually fax stufff ... unbelievable ...

[u***@gmail.com]

On Feb 14, 1:49 am, Tad Winters

Post by Tad Winters

Post by u***@gmail.com
On Feb 13, 7:49 pm, Tad Winters

 [..snip..]

Post by Doug Phillips
I've become so accustomed to the power of DBL that using any
other language for business apps seems painful, so I guess I am a
bit biased. 8^O

So you're still coding in DBL?  If I could find some more companies
in my area in need of someone to maintain their DBL code, I'd be
pretty happy.   The 2 companies I do occasional work for right now
just ask for minor changes or minor new features.  The last "large"
projects were implementing faxing of invoices (a failure since they
counted on using a VOIP line), emailing invoices (CSV file created
and transferred to a *nix box at an ISP to be converted to PDF),
and parsing a tab delimited file, received via ftp from an ISP
hosted web server, into an order.

goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...

I suggested looking at other faxing software before the project
started, but the lead said he wanted to stick with what he'd used
before.

Post by u***@gmail.com
why not run their own web server?  purveyor/wasd and dibol/dcl as
script languages work terrific ...

The system is already overloaded.

Post by u***@gmail.com
txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...

I looked into txt2pdf and wanted to use it, but I couldn't get them to
make the necessary changes with their ISP, i.e. MX record for their IP
address, DNS IP addresses for the VMS system to do lookups for sending
email and preferably letting the VMS system do zone transfers (to be a
secondary.)
PMDF would be more software on an already overloaded system, more
money, and would require them to open port 25 on their firewall.  Since
they're managing the firewall themselves, I don't think I could get
them to do it.  Also, anti-spam would be more load and more money.

Post by u***@gmail.com
sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...

Once again, more money.  Someone else mentioned they must not be
spending enough, based on what their revenues must be for having 150
concurrent users.  I don't know what their revenues are, though I could
look, since I have access to their system, but it's not my business.  
If I really need to know, I'll ask.  If it's only to tell them they're
not spending enough, then it's just as easy to tell them what is called
for in the industry.

Post by u***@gmail.com
vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...- Hide quoted text -

- Show quoted text -- Hide quoted text -
- Show quoted text -

put the vms mail or web servers outside of the useless
firewall ...

vms does not need no firewall ... it is its own firewall!

have they ever heard of captive accounts, acls?

vms configured properly is better than any firewall
they could ever buy ... sounds like someone does not
know what they are doing ...

[u***@gmail.com]

On Feb 12, 7:33 pm, Tad Winters

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above.  Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language.  Why did Digital drop it
with the move to Alpha?

because of $$$$$$$$$$$$$$$$$$$$$$$$$$$$$

and they was stupid to do so ... the port would have been easy
and they lost a lot of business because of it, i.e. MCBA ...

DIBOL was a one time license multiple user solution unlike
synergy ... now synergy has many more features that takes
DIBOL to a whole other level, but those features are not free ...

MCBA was responsible for the huge DIBOL market with all
their accounting packages and there where many others
small companies because of that which began using it to
develop other packages such as legal software I used to
modify before ...

DEC pulled the rug from under them and synergy was unwilling
to give them a license break and MCBA ported to cobol and
cost DEC a lot of customers ... another stupid move on DECs
part ...

and DIBOL is superior to cobol, basic, pascal or any other
3GL ... going to those is a step backwards ...

[Doug Phillips]

On Feb 12, 7:33 pm, Tad Winters

Post by Tad Winters

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want
integrated (non-custom) support for access to indexed and other
files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
not inherantly difficult to access keyed files from C/C++, but it
will be in the nature of a non-integrated add-in (or in the case of
C++, probably a class).

Not to divert the topic, but Pascal has just as good support for
indexed and relative files as the langauges listed above. Well, you
can't CREATE a file with segmented keys from Pascal without
resorting to a USERACTION routine, but you can open an existing file
and even use FINDK to lookup a record.

It seems like DIBOL was quite a good language. Why did Digital drop it
with the move to Alpha?

because of $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
and they was stupid to do so ... the port would have been easy
and they lost a lot of business because of it, i.e. MCBA ...
DIBOL was a one time license multiple user solution unlike
synergy ... now synergy has many more features that takes
DIBOL to a whole other level, but those features are not free ...
MCBA was responsible for the huge DIBOL market with all
their accounting packages and there where many others
small companies because of that which began using it to
develop other packages such as legal software I used to
modify before ...
DEC pulled the rug from under them and synergy was unwilling
to give them a license break and MCBA ported to cobol and
cost DEC a lot of customers ... another stupid move on DECs
part ...

If you remember, MCBA was bought out and it was the new owners who
tried to force the customer-base to either buy their package or find
another solution. That software carried a very high price and many
companies bailed rather than cough up the often $100K or so for the
"upgrade" to stay with the new owners -- who were known to be, um,
less concerned about customer support than one might desire.

Near the end, MCBA had a large presence in the DISC/DBL world, maybe
even larger than in DEC DIBOL.

and DIBOL is superior to cobol, basic, pascal or any other
3GL ... going to those is a step backwards ...

Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
easy to learn and code, but other languages were gaining capabilities
that DIBOL didn't have. Synergy/DE, on the other hand, has some really
great features that are not "built-in" to most other languages.

[Tom Linden]

Post by Doug Phillips
Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
easy to learn and code, but other languages were gaining capabilities
that DIBOL didn't have. Synergy/DE, on the other hand, has some really
great features that are not "built-in" to most other languages.

Like what?

[Doug Phillips]

Post by Tom Linden

Post by Doug Phillips
Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
easy to learn and code, but other languages were gaining capabilities
that DIBOL didn't have. Synergy/DE, on the other hand, has some really
great features that are not "built-in" to most other languages.

Like what?

Not easy to answer here, so you'll have to look for yourself:

<http://www.synergyde.com/>

We are no longer a reseller, and receive no rewards for promoting it,
but we do have a lot of DBL code running in enough places to provide a
major percentage of our income. So anyone interested in Synergy/DE
should contact Synergex directly. They're good people and while I
haven't always agreed with the direction they've taken, I appreciate
the fact that they do have a good product and do care about their
customers.

I guess I could likewise ask: What does PL/I offer that Synergy/DE
doesn't? - except you asked first:-)

[Larry Kilgallen]

Post by John Reagan

Post by Bob Gezelter
For porting, it depends on the style of code. If you want integrated
(non-custom) support for access to indexed and other files, you are
probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
difficult to access keyed files from C/C++, but it will be in the
nature of a non-integrated add-in (or in the case of C++, probably a
class).

Not to divert the topic, but Pascal has just as good support for indexed
and relative files as the langauges listed above. Well, you can't
CREATE a file with segmented keys from Pascal without resorting to a
USERACTION routine, but you can open an existing file and even use FINDK
to lookup a record.

DEC/Compaq/HP Ada forces one to specify a FDL string to do that,
but after getting accustomed to it that is not such a bad approach
if your rate of file creation is sufficiently low that overhead
from parsing the FDL string is not an issue.

[Dan Allen]

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 12:36 PM
Subject: Re: VMS license fees?

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time

that don't know

Post by Bill Gunshannon
that HP owns VMS. They're

certainly not paying anyone

Post by Bill Gunshannon
license fees for their VAX."
Hard to interpret that as anything short of running VAX without a
valid license.

What I meant was that the licenses that came with their VAX,
good forever, stay good for, well, forever.
--Stan Quayle
Quayle Consulting Inc.

Indeed. I have a file cabinet drawer full of license PAKS originally purchased
for an 11/780 in the early eighties (including a host of unlimited VMS and
layerd product licenses) that were transferred as part of an Alpha upgrade and
are still good. Too bad there's no interest in the Alpha aside from me....

Dan

Post by Hank Vander Waal
----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"

[Richard B. Gilbert]

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 12:36 PM
Subject: Re: VMS license fees?

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time

that don't know

Post by Bill Gunshannon
that HP owns VMS. They're

certainly not paying anyone

Post by Bill Gunshannon
license fees for their VAX."
Hard to interpret that as anything short of running VAX without a
valid license.

What I meant was that the licenses that came with their VAX,
good forever, stay good for, well, forever.
--Stan Quayle
Quayle Consulting Inc.

Indeed. I have a file cabinet drawer full of license PAKS originally purchased
for an 11/780 in the early eighties (including a host of unlimited VMS and
layerd product licenses) that were transferred as part of an Alpha upgrade and
are still good. Too bad there's no interest in the Alpha aside from me....

I think your dates are a little off Dan. In 1984 there were licenses
but no License PAKs. You did need a software "patch" to enable DECnet
but that was not the same thing as a PAK.

Paper license PAKs came along a couple of years later!

[V***@SendSpamHere.ORG]

This post might be inappropriate. Click to display it.

[Dan Allen]

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 5:49 PM
Subject: Re: VMS license fees?

Post by Richard B. Gilbert

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 12:36 PM
Subject: Re: VMS license fees?

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time

that don't know

Post by Bill Gunshannon
that HP owns VMS. They're

certainly not paying anyone

Post by Bill Gunshannon
license fees for their VAX."
Hard to interpret that as anything short of running VAX without a
valid license.

What I meant was that the licenses that came with their VAX, good
forever, stay good for, well, forever.
--Stan Quayle
Quayle Consulting Inc.

Indeed. I have a file cabinet drawer full of license PAKS

originally

Post by Richard B. Gilbert

Post by Dan Allen
purchased for an 11/780 in the early eighties (including a host of
unlimited VMS and layerd product licenses) that were

transferred as

Post by Richard B. Gilbert

Post by Dan Allen
part of an Alpha upgrade and are still good. Too bad

there's no interest in the Alpha aside from me....

Post by Richard B. Gilbert
I think your dates are a little off Dan. In 1984 there were

licenses

Post by Richard B. Gilbert
but no License PAKs. You did need a software "patch" to

enable DECnet

Post by Richard B. Gilbert
but that was not the same thing as a PAK.
Paper license PAKs came along a couple of years later!

1987/88 time frame when VMS V5.0 and the LMF were introduced.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker
VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html

Well I transfered into "The Bureau" in 1986 so it wouldn't be any earlier than
that. I guess "early Eighties" is a stretch. Still beaucoup $$$$ worth of PAKS
in that drawer - Fortran, C, Pascal, Cobol, Basic, RDB - all unlimited usage and
all perfectly legit as long as you don't mind the versions. And I was indeed the
lucky guy who got to install the initial LMF deployment. It's been a while and
I'm afraid I've killed quite a few gray cells in the interim so my memory is a
bit shakey.....

Dan

[Tom Linden]

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 5:49 PM
Subject: Re: VMS license fees?

Post by Richard B. Gilbert

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 12:36 PM
Subject: Re: VMS license fees?

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time

that don't know

Post by Bill Gunshannon
that HP owns VMS. They're

certainly not paying anyone

Post by Bill Gunshannon
license fees for their VAX."
Hard to interpret that as anything short of running VAX without a
valid license.

What I meant was that the licenses that came with their VAX, good
forever, stay good for, well, forever.
--Stan Quayle
Quayle Consulting Inc.

Indeed. I have a file cabinet drawer full of license PAKS

originally

Post by Richard B. Gilbert

Post by Dan Allen
purchased for an 11/780 in the early eighties (including a host of
unlimited VMS and layerd product licenses) that were

transferred as

Post by Richard B. Gilbert

Post by Dan Allen
part of an Alpha upgrade and are still good. Too bad

there's no interest in the Alpha aside from me....

Post by Richard B. Gilbert
I think your dates are a little off Dan. In 1984 there were

licenses

Post by Richard B. Gilbert
but no License PAKs. You did need a software "patch" to

enable DECnet

Post by Richard B. Gilbert
but that was not the same thing as a PAK.
Paper license PAKs came along a couple of years later!

1987/88 time frame when VMS V5.0 and the LMF were introduced.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker
VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html

Well I transfered into "The Bureau" in 1986 so it wouldn't be any earlier than
that. I guess "early Eighties" is a stretch. Still beaucoup $$$$ worth of PAKS
in that drawer - Fortran, C, Pascal, Cobol, Basic, RDB - all unlimited usage and

You forgot PL/I.

Post by Dan Allen
all perfectly legit as long as you don't mind the versions. And I was indeed the
lucky guy who got to install the initial LMF deployment. It's been a while and
I'm afraid I've killed quite a few gray cells in the interim so my memory is a
bit shakey.....
Dan

[Dan Allen]

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 10:03 PM
Subject: Re: FW: VMS license fees?

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 5:49 PM
Subject: Re: VMS license fees?

Post by Richard B. Gilbert

Post by Dan Allen

Post by Hank Vander Waal
-----Original Message-----
Sent: Wednesday, February 13, 2008 12:36 PM
Subject: Re: VMS license fees?

Post by Bill Gunshannon
Not the way I read it: "Paying for licenses?
I encounter customers all the time

that don't know

Post by Bill Gunshannon
that HP owns VMS. They're

certainly not paying anyone

Post by Bill Gunshannon
license fees for their VAX."
Hard to interpret that as anything short of running

VAX without a

Post by Dan Allen

Post by Hank Vander Waal

Post by Richard B. Gilbert

Post by Dan Allen

Post by Hank Vander Waal

Post by Bill Gunshannon
valid license.

What I meant was that the licenses that came with their

VAX, good

Post by Dan Allen

Post by Hank Vander Waal

Post by Richard B. Gilbert

Post by Dan Allen

Post by Hank Vander Waal
forever, stay good for, well, forever.
--Stan Quayle
Quayle Consulting Inc.

Indeed. I have a file cabinet drawer full of license PAKS

originally

Post by Richard B. Gilbert

Post by Dan Allen
purchased for an 11/780 in the early eighties

(including a host of

Post by Dan Allen

Post by Hank Vander Waal

Post by Richard B. Gilbert

Post by Dan Allen
unlimited VMS and layerd product licenses) that were

transferred as

Post by Richard B. Gilbert

Post by Dan Allen
part of an Alpha upgrade and are still good. Too bad

there's no interest in the Alpha aside from me....

Post by Richard B. Gilbert
I think your dates are a little off Dan. In 1984 there were

licenses

Post by Richard B. Gilbert
but no License PAKs. You did need a software "patch" to

enable DECnet

Post by Richard B. Gilbert
but that was not the same thing as a PAK.
Paper license PAKs came along a couple of years later!

1987/88 time frame when VMS V5.0 and the LMF were introduced.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker
VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
http://tmesis.com/drat.html

Well I transfered into "The Bureau" in 1986 so it wouldn't be any
earlier than that. I guess "early Eighties" is a stretch. Still
beaucoup $$$$ worth of PAKS in that drawer - Fortran, C, Pascal,
Cobol, Basic, RDB - all unlimited usage and

You forgot PL/I.

Oddly enough that's one we never had although I did miss GKS, PHIGS, OPEN3D,
CLUSTER, DECNET, ADL, DTR, DCE, and a few others....