Discussion:
VMS Software needs to port VAX DIBOL to OpenVMS X86 platform
Add Reply
ultr...@gmail.com
2020-12-14 19:08:16 UTC
Reply
Permalink
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.

This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.

I have started a project using DIBOL and need to implement it on the x86 platform.
Jan-Erik Söderholm
2020-12-14 22:40:51 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
If you need anything from VSI, it might be better to actually ask VSI.
Arne Vajhøj
2020-12-14 23:22:33 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
VSI may already have their plate more than full.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Something that will generate substantial revenue for VSI?

Arne
Simon Clubley
2020-12-15 13:45:22 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.

VSI have just lost a good number of VMS users with this one decision.

What I would like to know is how the hell did VSI allow this to happen ???

Synergex is _exactly_ the kind of company VSI should have been in continuous
and close contact with and VSI should have been working closely with them
to help port Synergy to x86-64 VMS.

VSI should have also been making all the right public marketing and update
noises to reassure Synergex (and other companies) that x86-64 VMS was
happening and that it was going to be a viable platform.

I wonder if Synergex saw that nothing appeared to be happening with x86-64
VMS and hence decided to drop any plans for porting to x86-64 VMS ?

With this one decision, VSI has not only lost the x86-64 VMS sales from
developers who would have bought x86-64 VMS to develop Synergy applications
on, but have also lost all the x86-64 VMS sales to customers of those
developers to run those applications on. That latter number is a much
larger number.

I would hope that VSI are now in touch with Synergy to see if anything can
be done to fix this, but based on VSI's public performance so far, I don't
have a great deal of confidence in that.

It's also probably too late if the decision has been driven by Synergex's
customers also moving on from VMS because those customers may have gained
the impression that nothing appeared to be happening with x86-64 VMS.

That marketing and building public confidence in x86-64 VMS stuff that I
was talking about a few weeks ago ? This is _exactly_ why that kind of thing
is required and I hope at least some of you are now starting to see that.
Post by Arne Vajhøj
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
That's not going to happen for two reasons:

1) It was already considered at the time of the VAX to Alpha migration and
rejected by DEC in favour of a partnership with Synergex. That's when there
were a lot more VMS users than there are now.

2) What VAX DIBOL offers is extremely limited compared to what Synergy offers.

Unless code written using Synergy was _very_ restricted in what language
features it used and didn't use Synergy specific features such as the UI
toolkit, there's no way you would get Synergy code to run under VAX DIBOL.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Michael C
2020-12-15 14:24:28 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.
VSI have just lost a good number of VMS users with this one decision.
What I would like to know is how the hell did VSI allow this to happen ???
Synergex is _exactly_ the kind of company VSI should have been in continuous
and close contact with and VSI should have been working closely with them
to help port Synergy to x86-64 VMS.
VSI should have also been making all the right public marketing and update
noises to reassure Synergex (and other companies) that x86-64 VMS was
happening and that it was going to be a viable platform.
I wonder if Synergex saw that nothing appeared to be happening with x86-64
VMS and hence decided to drop any plans for porting to x86-64 VMS ?
With this one decision, VSI has not only lost the x86-64 VMS sales from
developers who would have bought x86-64 VMS to develop Synergy applications
on, but have also lost all the x86-64 VMS sales to customers of those
developers to run those applications on. That latter number is a much
larger number.
I would hope that VSI are now in touch with Synergy to see if anything can
be done to fix this, but based on VSI's public performance so far, I don't
have a great deal of confidence in that.
It's also probably too late if the decision has been driven by Synergex's
customers also moving on from VMS because those customers may have gained
the impression that nothing appeared to be happening with x86-64 VMS.
That marketing and building public confidence in x86-64 VMS stuff that I
was talking about a few weeks ago ? This is _exactly_ why that kind of thing
is required and I hope at least some of you are now starting to see that.
Post by Arne Vajhøj
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
1) It was already considered at the time of the VAX to Alpha migration and
rejected by DEC in favour of a partnership with Synergex. That's when there
were a lot more VMS users than there are now.
2) What VAX DIBOL offers is extremely limited compared to what Synergy offers.
Unless code written using Synergy was _very_ restricted in what language
features it used and didn't use Synergy specific features such as the UI
toolkit, there's no way you would get Synergy code to run under VAX DIBOL.
Simon.
--
Walking destinations on a map are further away than they appear.
AMEN TO THE ABOVE.

BUT DIBOL IS WAY BETTER THAN THAT C THING EVERYONE THINKS IS A LANGUAGE IS USING
Arne Vajhøj
2020-12-15 14:51:11 UTC
Reply
Permalink
Post by Michael C
BUT DIBOL IS WAY BETTER THAN THAT C THING EVERYONE THINKS IS A LANGUAGE IS USING
That may depend on whether you are writing an OS or a business
application.

:-)

Arne
Jan-Erik Söderholm
2020-12-15 15:08:54 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Michael C
BUT DIBOL IS WAY BETTER THAN THAT C THING EVERYONE THINKS IS A LANGUAGE IS USING
That may depend on whether you are writing an OS or a business
application.
:-)
Arne
Or if you are still in an environemt using upper case only...
Bill Gunshannon
2020-12-15 15:24:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Michael C
BUT DIBOL IS WAY BETTER THAN THAT C THING EVERYONE THINKS IS A LANGUAGE IS USING
That may depend on whether you are writing an OS or a business
application.
:-)
A profound statement. I honestly think the biggest problem
with the introduction of C was it led to a move away from
Domain Specific Languages and toward general purpose languages
being used for everything.

bill
Arne Vajhøj
2020-12-15 15:37:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Michael C
BUT DIBOL IS WAY BETTER THAN THAT C THING EVERYONE THINKS IS A LANGUAGE IS USING
That may depend on whether you are writing an OS or a business
application.
:-)
A profound statement.  I honestly think the biggest problem
with the introduction of C was it led to a move away from
Domain Specific Languages and toward general purpose languages
being used for everything.
Yep.

But luckily that idea was dropped again a couple
of decades ago.

Arne
Arne Vajhøj
2020-12-15 14:49:57 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.
Yes.
Post by Simon Clubley
VSI have just lost a good number of VMS users with this one decision.
Not sure how popular Dibol/VMS is today (the Synergex decision somehow
hint at it not being huge), but there are some customers.

And VMS can ill afford to loose customers.

:-(
Post by Simon Clubley
What I would like to know is how the hell did VSI allow this to happen ???
VSI cannot force Synergex to support VMS x86-64. If they won't then VSI
cannot do much.
Post by Simon Clubley
Synergex is _exactly_ the kind of company VSI should have been in continuous
and close contact with and VSI should have been working closely with them
to help port Synergy to x86-64 VMS.
I would assume they have.

But sometimes companies make strategic decisions.
Post by Simon Clubley
VSI should have also been making all the right public marketing and update
noises to reassure Synergex (and other companies) that x86-64 VMS was
happening and that it was going to be a viable platform.
That VSI is working on VMS x86-64 and how far they are is pretty widely
known in VMS world.

There must be people in Synergex knowing current state.

It seems not to have been enough to make a good business
case for Synergex management.

Arne
Craig A. Berry
2020-12-15 16:17:31 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.
VSI have just lost a good number of VMS users with this one decision.
If in fact there has been any decision. As recently as May they were
still soliciting input from customers and waiting (like the rest of us)
for VSI to get far enough along with the port that it would even be
possible to investigate porting Synergy:

<https://www.synergex.com/blog/category/openvms/>

The blog author invites people to contact him directly if they have
interest in seeing Synergy on OpenVMS x86.
ultr...@gmail.com
2020-12-15 17:09:44 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.
VSI have just lost a good number of VMS users with this one decision.
If in fact there has been any decision. As recently as May they were
still soliciting input from customers and waiting (like the rest of us)
for VSI to get far enough along with the port that it would even be
<https://www.synergex.com/blog/category/openvms/>
The blog author invites people to contact him directly if they have
interest in seeing Synergy on OpenVMS x86.
they sent out a letter stating that as of may 2020 they have not committed to porting yet.
Here it is:
"Your decision-making process should take into account that Synergex has not yet committed to porting OpenVMS Synergy to the x86 platform. That decision has both technical and commercial aspects."

AND I WAS JUST LITERALLY ON THEIR ONLINE CONFERENCE JUST MOMENTS AGO AND THEY ARE HEAVILY PUSHING AN EMULATION PACKAGE. THEY SAID THE PORT WOULD NOT BE AS EASY
AS JUST A RECOMPILE. THEY HAVE NOT COMMITTED TO THE PORT YET.
Arne Vajhøj
2020-12-15 17:23:10 UTC
Reply
Permalink
Post by ***@gmail.com
Post by Simon Clubley
Post by Arne Vajhøj
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
That is not good.
It's more like a disaster if this is also happening with other ISVs.
VSI have just lost a good number of VMS users with this one decision.
If in fact there has been any decision. As recently as May they were
still soliciting input from customers and waiting (like the rest of us)
for VSI to get far enough along with the port that it would even be
<https://www.synergex.com/blog/category/openvms/>
The blog author invites people to contact him directly if they have
interest in seeing Synergy on OpenVMS x86.
they sent out a letter stating that as of may 2020 they have not committed to porting yet.
"Your decision-making process should take into account that Synergex has not yet committed to porting OpenVMS Synergy to the x86 platform. That decision has both technical and commercial aspects."
Not surprising that a software business look at both technical
and financial aspects.
Post by ***@gmail.com
AND I WAS JUST LITERALLY ON THEIR ONLINE CONFERENCE JUST MOMENTS AGO AND THEY ARE HEAVILY PUSHING AN EMULATION PACKAGE. THEY SAID THE PORT WOULD NOT BE AS EASY
AS JUST A RECOMPILE. THEY HAVE NOT COMMITTED TO THE PORT YET.
Compilers are for obvious reason not just a recompile.

But they have Dibol for VMS and they have Dibol for x86-64.

If there are customers then making it wok should be possible.

Arne
Simon Clubley
2020-12-15 18:47:00 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
they sent out a letter stating that as of may 2020 they have not committed to porting yet.
"Your decision-making process should take into account that Synergex has not yet committed to porting OpenVMS Synergy to the x86 platform. That decision has both technical and commercial aspects."
Not surprising that a software business look at both technical
and financial aspects.
I really hope VSI are actively talking to Synergex about both of these.

Even if VSI have to provide a lot of support/resources to help make this
happen, they may get the investment back many times over if the customers
of the developers using Synergex on VMS start buying VMS on x86-64 to run
these applications.

This assumes that the existing developers using Synergex on VMS have not
moved away from VMS by now because they have managed to form the impression
that VMS has no future.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-12-15 02:40:02 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Michael C
2020-12-15 13:05:37 UTC
Reply
Permalink
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
DIBOL runs circles around basic :0
Chris Townley
2020-12-15 13:17:46 UTC
Reply
Permalink
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?

Chris
Arne Vajhøj
2020-12-15 13:26:19 UTC
Reply
Permalink
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.

Arne
Bill Gunshannon
2020-12-15 15:19:43 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).

bill
Arne Vajhøj
2020-12-15 15:35:34 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on
the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
Wikipedia claims:
* BCD arithmetic
* data and procedure divisions

Arne
Bill Gunshannon
2020-12-15 15:47:18 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on
the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
* BCD arithmetic
Lots of languages did and do BCD Arithmetic doesn't mean they
resemble or acquired that from COBOL.
Post by Arne Vajhøj
* data and procedure divisions
While the manual states there is a data and a procedure division the
word division is not used in source code, the start of the data area
is not delinieated and the separation of the two is merely the symbol
PROC. Again, no similarity to COBOL.

This is all like saying French and English must be the same
language because the both use the letter "Q".


Wikipedia strikes again.

bill
Arne Vajhøj
2020-12-15 15:53:52 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on
the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
* BCD arithmetic
Lots of languages did and do BCD Arithmetic doesn't mean they
resemble or acquired that from COBOL.
Today most languages do have some sort of decimal type.

Back then not so many.
Post by Bill Gunshannon
Post by Arne Vajhøj
* data and procedure divisions
While the manual states there is a data and a procedure division the
word division is not used in source code, the start of the data area
is  not delinieated and the separation of the two is merely the symbol
PROC.  Again, no similarity to COBOL.
I find it very unlikely that those words was invented independently
of Cobol.

The claim was not that it used Cobol syntax but that it
was inspired by Cobol.

Arne
Bill Gunshannon
2020-12-15 17:45:45 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it
on the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
* BCD arithmetic
Lots of languages did and do BCD Arithmetic doesn't mean they
resemble or acquired that from COBOL.
Today most languages do have some sort of decimal type.
Back then not so many.
COBOL, PL/I and even 360 Assembler. May have been more, but my'memory
dims more every day.
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
* data and procedure divisions
While the manual states there is a data and a procedure division the
word division is not used in source code, the start of the data area
is  not delinieated and the separation of the two is merely the symbol
PROC.  Again, no similarity to COBOL.
I find it very unlikely that those words was invented independently
of Cobol.
Most languages (other than maybe BASIC :-) separate data and procedure.
Good programming practice would do it even if the language didn't. As
I said, the term Data Division appears only in the manual, no where
within a program.
Post by Arne Vajhøj
The claim was not that it used Cobol syntax but that it
was inspired by Cobol.
It looks much more inspired by Fortran given any examination of
a program source example.

bill
Arne Vajhøj
2020-12-15 18:03:23 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the
x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it
on the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
* BCD arithmetic
Lots of languages did and do BCD Arithmetic doesn't mean they
resemble or acquired that from COBOL.
Today most languages do have some sort of decimal type.
Back then not so many.
COBOL, PL/I and even 360 Assembler.  May have been more, but my'memory
dims more every day.
I am not sure that I would count any assembler. They support whatever
the HW supports.

Macro-32 also got P instructions.

But yes PL/I. Which supposedly got inspired by Cobol and Algol.
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
* data and procedure divisions
While the manual states there is a data and a procedure division the
word division is not used in source code, the start of the data area
is  not delinieated and the separation of the two is merely the symbol
PROC.  Again, no similarity to COBOL.
I find it very unlikely that those words was invented independently
of Cobol.
Most languages (other than maybe BASIC :-) separate data and procedure.
Most languages more than 35 years old separate data and code, but
they do typical have an implicit delimitation not an explicit.

Cobol and Dibol use an explicit marker. Different marker though.

Pascal also has an explicit separation, but that is a very different
style.

Newer languages tend to allow mixing.

Arne
Simon Clubley
2020-12-15 18:31:13 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
The claim was not that it used Cobol syntax but that it
was inspired by Cobol.
It looks much more inspired by Fortran given any examination of
a program source example.
At a conceptual level, the RECORD statement in DIBOL heavily resembles
the COBOL data division definition of variables and structures even if
the actual syntax is very different.

The general "feel" of the procedure section does feel sort-of Fortran-like.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Townley
2020-12-15 18:39:23 UTC
Reply
Permalink
Post by Simon Clubley
Post by Bill Gunshannon
Post by Arne Vajhøj
The claim was not that it used Cobol syntax but that it
was inspired by Cobol.
It looks much more inspired by Fortran given any examination of
a program source example.
At a conceptual level, the RECORD statement in DIBOL heavily resembles
the COBOL data division definition of variables and structures even if
the actual syntax is very different.
The general "feel" of the procedure section does feel sort-of Fortran-like.
Simon.
From Wikipedia:

DIBOL
Paradigm procedural, imperative, structured
Developer DEC
First appeared 1970
Stable release DIBOL 1992 / 2002
Typing discipline static
Major implementations
Synergex DBL, DEC VAX DIBOL, others

Influenced by
BASIC, Fortran, COBOL

DIBOL or Digital's Business Oriented Language is a general-purpose,
procedural, imperative programming language, designed for use in
Management Information Systems (MIS) software development.

It has a syntax similar to FORTRAN and BASIC, along with BCD arithmetic.
It shares the COBOL program structure of separate data and procedure
divisions. Unlike Fortran's numeric labels (for GOTO), DIBOL's were
alphanumeric; the language supported a counterpart to computed goto.


Chris
ultr...@gmail.com
2020-12-15 15:59:28 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on
the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
* BCD arithmetic
* data and procedure divisions
Arne
THINK OF DIBOL AS A TYPE OF 4 GL COBOL

RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles


PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.")
WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.")
WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
Stephen Hoffman
2020-12-15 19:47:39 UTC
Reply
Permalink
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...




for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")





This Swift code would be a little less involved if the code was
switched to the internationalized support for text messages and for
pluralization, and with the text strings moved to a local-language
file. This Swift code also eschews OO features, etc.

Other languages may and variously will be shorter than DIBOL or COBOL
code, too.

But then back to the original DIBOL availability question, the
production compilers and production OpenVMS x86-64 availability are all
going to be 2022 at the earliest. And quite possibly 2023, if something
slips somewhere. Call back closer to then, and maybe Synergex has a
port underway, or has a DIBOL compiler available.
--
Pure Personal Opinion | HoffmanLabs LLC
m***@gmail.com
2020-12-16 17:35:22 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...
for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")
Pure Personal Opinion | HoffmanLabs LLC
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE

BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS


RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
IF (NUMBOT .EQ. 1) EXITLOOP ;If just 1 bottle left, get out
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
END
SLEEP 2
CLOSE 8
STOP
m***@gmail.com
2020-12-16 17:45:10 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...
for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")
This Swift code would be a little less involved if the code was
switched to the internationalized support for text messages and for
pluralization, and with the text strings moved to a local-language
file. This Swift code also eschews OO features, etc.
Other languages may and variously will be shorter than DIBOL or COBOL
code, too.
But then back to the original DIBOL availability question, the
production compilers and production OpenVMS x86-64 availability are all
going to be 2022 at the earliest. And quite possibly 2023, if something
slips somewhere. Call back closer to then, and maybe Synergex has a
port underway, or has a DIBOL compiler available.
--
Pure Personal Opinion | HoffmanLabs LLC
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE

BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS


RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
END
SLEEP 2
CLOSE 8
STOP
m***@gmail.com
2020-12-16 17:50:56 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...
for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")
This Swift code would be a little less involved if the code was
switched to the internationalized support for text messages and for
pluralization, and with the text strings moved to a local-language
file. This Swift code also eschews OO features, etc.
Other languages may and variously will be shorter than DIBOL or COBOL
code, too.
But then back to the original DIBOL availability question, the
production compilers and production OpenVMS x86-64 availability are all
going to be 2022 at the earliest. And quite possibly 2023, if something
slips somewhere. Call back closer to then, and maybe Synergex has a
port underway, or has a DIBOL compiler available.
--
Pure Personal Opinion | HoffmanLabs LLC
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE

BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS


RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
END
SLEEP 2
CLOSE 15
STOP
Simon Clubley
2020-12-16 18:26:49 UTC
Reply
Permalink
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured

Bob, you no longer need to use an ASR33 to post to comp.os.vms.

Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)

BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.

What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
m***@gmail.com
2020-12-16 18:42:20 UTC
Reply
Permalink
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
^^
Perhaps you should have run it through a compiler first before posting. :-)
I saw that and corrected it. It's been a while give me a break :)
Post by Simon Clubley
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
All off my jobs had pre written code using that as the channel no. I just thought since that was a high channel no in dibol that it was used by default. So I just keep using it as the terminal number. I wasn't about to go thru all of that code to change just a channel no. either :)
Post by Simon Clubley
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Simon.
--
Walking destinations on a map are further away than they appear.
m***@gmail.com
2020-12-16 18:45:29 UTC
Reply
Permalink
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
first time I ever tried it. I was curious :)
Post by Simon Clubley
Walking destinations on a map are further away than they appear.
m***@gmail.com
2020-12-16 18:51:10 UTC
Reply
Permalink
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
CLOSE 15
STOP
Simon.
--
Walking destinations on a map are further away than they appear.
I started out on a vax dibol system using the MCBA accounting system with code
he had added to it. He used channel 15 and so did the MCBA package if I remember correctly.

I think he said he used 15 for the terminal as it was high channel number for dibol.

The example I just posted above from an old vax example used channel 8.
AT THIS POINT WHAT DOES IT MATTER? :)
Bill Gunshannon
2020-12-16 18:57:29 UTC
Reply
Permalink
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Well, in DIBOL-11 15 is the highest channel. Some people may
have developed a habit (or in house standard) of putting devices
at the top and regular files starting from the bottom.

For the curious, there is a DIBOL-11 category on Rosetta Code.

bill
m***@gmail.com
2020-12-16 19:08:49 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Well, in DIBOL-11 15 is the highest channel. Some people may
have developed a habit (or in house standard) of putting devices
at the top and regular files starting from the bottom.
For the curious, there is a DIBOL-11 category on Rosetta Code.
bill
thanks for the reminder the MCBA package we had ran on a PDP-11 RSTS/E
DIBOL machine before we ported to the VAX. So that is what I was thinking of.
Dave Froble
2020-12-16 20:32:02 UTC
Reply
Permalink
Post by m***@gmail.com
Post by Bill Gunshannon
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Well, in DIBOL-11 15 is the highest channel. Some people may
have developed a habit (or in house standard) of putting devices
at the top and regular files starting from the bottom.
For the curious, there is a DIBOL-11 category on Rosetta Code.
bill
thanks for the reminder the MCBA package we had ran on a PDP-11 RSTS/E
DIBOL machine before we ported to the VAX. So that is what I was thinking of.
Guess you missed the PDP-8 version, huh?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
m***@gmail.com
2020-12-16 19:12:24 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Well, in DIBOL-11 15 is the highest channel. Some people may
have developed a habit (or in house standard) of putting devices
at the top and regular files starting from the bottom.
For the curious, there is a DIBOL-11 category on Rosetta Code.
bill
that is exactly what they did.

Channel 15 was for terminal
14 was the line printer
1 thru 12 was for files
Dave Froble
2020-12-16 20:34:59 UTC
Reply
Permalink
Post by m***@gmail.com
Post by Bill Gunshannon
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Well, in DIBOL-11 15 is the highest channel. Some people may
have developed a habit (or in house standard) of putting devices
at the top and regular files starting from the bottom.
For the curious, there is a DIBOL-11 category on Rosetta Code.
bill
that is exactly what they did.
Channel 15 was for terminal
14 was the line printer
1 thru 12 was for files
How restrictive ...

:-)

However, the practice is common. My Basic programs use KB% for the
terminal device, and the variable is set to 99. Must get tiring typing
all those "15"s, huh? Not very descriptive either.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Tad Winters
2020-12-16 21:23:52 UTC
Reply
Permalink
Post by Simon Clubley
Post by m***@gmail.com
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE
BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS
$ set response/mode=good_natured
Bob, you no longer need to use an ASR33 to post to comp.os.vms.
Other input devices are available these days.
Post by m***@gmail.com
RECORD MISC
I ,D2
NUMBOT ,D2,99 ;Default # of bottles to 99
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
^^
Perhaps you should have run it through a compiler first before posting. :-)
BTW, it's the first time I've seen channel 15 used for TT: in a DIBOL
program that I can remember. I always used to use channel 1 as it was
the first channel I used to open in a program when DIBOL was the
language I was using to write the program.
What channel did others use for TT: ? Is channel 15 from something
(such as someone's training sessions) that I never saw ?
Post by m***@gmail.com
END
SLEEP 2
CLOSE 15
STOP
Simon.
The software company I worked for in the 90s used channel 15 for all
terminal I/O. I have no explanation for this, but I'm going to guess it
may have been the highest channel number available on some PDP11 OS.

- Tad
m***@gmail.com
2020-12-16 18:14:04 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...
for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")
This Swift code would be a little less involved if the code was
switched to the internationalized support for text messages and for
pluralization, and with the text strings moved to a local-language
file. This Swift code also eschews OO features, etc.
Other languages may and variously will be shorter than DIBOL or COBOL
code, too.
But then back to the original DIBOL availability question, the
production compilers and production OpenVMS x86-64 availability are all
going to be 2022 at the earliest. And quite possibly 2023, if something
slips somewhere. Call back closer to then, and maybe Synergex has a
port underway, or has a DIBOL compiler available.
--
Pure Personal Opinion | HoffmanLabs LLC
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE

BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS


RECORD MISC
I ,D2
NUMBOT ,D2,99 ; Set default to 99
PROC
XCALL FLAGS (0007000000,1) ;Supress STOP message
OPEN(15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall.',13,10,13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
END
SLEEP 2
CLOSE 15
STOP
m***@gmail.com
2020-12-16 18:19:29 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
THINK OF DIBOL AS A TYPE OF 4 GL COBOL
RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles
PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.") WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.") WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
For grins, and written entirely off the cuff...
for i in (1...99).reversed() {
print("\(i) bottle\((i == 1 ? "" : "s")) of beer on the wall, \(i)
bottle\((i == 1 ? "" : "s")) of beer.")
print("Take one down and pass it around, ", terminator: "")
if i == 1 {
print("no more bottles of beer on the wall.")
} else {
print("\(i - 1) more bottle\((i == 2) ? "" : "s") of beer on the wall.)
}
}
print("No more bottles of beer on the wall, no more bottles of beer.")
print("Hey, the beer's all gone, I'm outta here.")
This Swift code would be a little less involved if the code was
switched to the internationalized support for text messages and for
pluralization, and with the text strings moved to a local-language
file. This Swift code also eschews OO features, etc.
Other languages may and variously will be shorter than DIBOL or COBOL
code, too.
But then back to the original DIBOL availability question, the
production compilers and production OpenVMS x86-64 availability are all
going to be 2022 at the earliest. And quite possibly 2023, if something
slips somewhere. Call back closer to then, and maybe Synergex has a
port underway, or has a DIBOL compiler available.
--
Pure Personal Opinion | HoffmanLabs LLC
YOU DIDN'T THINK I WOULD PASS ON A CHALLENGE DID YOU? :)
THAT WAS AN OLD VAX DIBOL CODE EXAMPLE NOT USING THE FOR LOOP STRUCTURE

BEHOLD THE POWER OF SYNERGY DIBOL I THINK MY CPU PROCESS TIME WILL BEAT YOURS


RECORD MISC
I ,D2
NUMBOT ,D2,99 ; Set default to 99
PROC
XCALL FLAGS (0007000000,1) ;Supress STOP message
OPEN(15,O:C,"TT:") ;Open the terminal/display
FOR I FROM NUMBOT THRU 1 BY -1
DO
BEGIN
USING NUMBOT SELECT
(1), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottle of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,13,10,'Hey the Beer's gone, I am out of here...',13,10)
END
(), BEGIN
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer,',13,10)
DISPLAY(15,' Take one down, pass it around,',13,10)
DISPLAY(15,NUMBOT<FORMAT:'ZX'>,' Bottles of Beer on the wall.',13,10,13,10)
END
ENDSUING
END
SLEEP 2
CLOSE 15
STOP
ultr...@gmail.com
2020-12-15 15:56:19 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of
DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86
OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on
the x86 platform.
Use Basic ....
:-)
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
It is supposedly inspired by Cobol and Basic and Fortran.
Point out one thing in a DIBOL program that even vaguely
resembles COBOL (other than the last three letters of the
name).
bill
UH DATA AND PROCEDURE DIVISIONS FOR ONE

RECORD MISC
NUMBOTTLES ,D2,99 ;Default # of bottles to 99
ANUMBOTTLES ,A2 ;Used to mask the output of bottles


PROC
XCALL FLAGS (0007000000,1) ;Suppress STOP message
OPEN (8,O:C,"TT:") ;Open the terminal/display
REPEAT
BEGIN
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer on the wall,")
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES (8,ANUMBOTTLES+" Bottles of Beer,")
WRITES (8," Take one down, pass it around,")
DECR NUMBOTTLES ;Reduce # of bottles by 1
IF (NUMBOTTLES .LE. 1) EXITLOOP ;If just 1 bottle left, get out
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottles of Beer on the wall.")
WRITES (8," ")
END
ANUMBOTTLES = NUMBOTTLES,'ZX'
WRITES(8,ANUMBOTTLES+" Bottle of Beer on the wall.")
WRITES (8," ")
WRITES (8,ANUMBOTTLES+" Bottle of Beer on the wall,")
WRITES (8,ANUMBOTTLES+" Bottle of Beer,")
WRITES (8," Take one down, pass it around,")
WRITES (8," ")
WRITES (8," ")
WRITES (8, "Hey the Beer's gone, I am out of here...")
SLEEP 2
CLOSE 8
STOP
END
Bill Gunshannon
2020-12-15 15:18:23 UTC
Reply
Permalink
Post by Chris Townley
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
DIBOL runs circles around basic :0
Wasn't Dibol based on Cobol?
As someone very familiar with both, I can assure there is no
similarity at all. :-)

To be honest, when written it looks more like Fortran,
Assembler and maybe a little RPG.


bill
Dave Froble
2020-12-15 15:45:56 UTC
Reply
Permalink
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
DIBOL runs circles around basic :0
Circles? Not very efficient, huh? Shortest distance between two points
is a straight line.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-12-15 15:48:53 UTC
Reply
Permalink
Post by Michael C
Post by Dave Froble
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Well Bob, perhaps you can acquire a copy of the DIBOL product in order
to implement it on x86 VMS?
Post by ***@gmail.com
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
This forum, as Jan-=Erik may have mentioned, is not a VSI support venue.
Post by ***@gmail.com
I have started a project using DIBOL and need to implement it on the x86 platform.
Use Basic ....
:-)
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
DIBOL runs circles around basic :0
Circles?  Not very efficient, huh?  Shortest distance between two points
is a straight line.
BASIC Code has never been famous for doing anything in a straight line. :-)

bill
Arne Vajhøj
2020-12-15 16:12:13 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
Curious - what is your source?

https://www.synergex.com/roadmap/

<quote>
Features Under Consideration

The following features are under consideration for research and
development. We are also reviewing other features that have been
submitted to the Ideas forum in Synergex’s Resource Center Community. If
you have ideas for improving or extending Synergy/DE, we encourage you
to post them on the Ideas site for consideration. Also, if you are
interested in any of the ideas that are already posted, we encourage you
to add your input and votes for those features in the forum.

VSI OpenVMS
VMS advanced file system
VMS x64 port
</quote>

Arne

PS: It seems quite obvious from that roadmap that .NET Core is
what they see as the future.
Stephen Hoffman
2020-12-15 17:12:49 UTC
Reply
Permalink
PS: It seems quite obvious from that roadmap that .NET Core is what
they see as the future.
.NET is the OpenVMS calling standard a couple of decades on, and .NET
is widely available, so that perception hardly surprising.

There've been previous newsgroup discussions around porting .NET core
to OpenVMS.

I remain skeptical that the addition of .NET support will be a
particular draw for folks to choose and use OpenVMS. This too as the
older OpenVMS support for Microsoft COM/DCOM/OLE didn't see a
substantial uptake.

https://dotnet.microsoft.com/learn/dotnet/what-is-dotnet
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-12-15 17:42:36 UTC
Reply
Permalink
PS: It seems quite obvious from that roadmap that .NET Core is what
they see as the future.
.NET is the OpenVMS calling standard a couple of decades on, and .NET is
widely available, so that perception hardly surprising.
There've been previous newsgroup discussions around porting .NET core to
OpenVMS.
I remain skeptical that the addition of .NET support will be a
particular draw for folks to choose and use OpenVMS. This too as the
older OpenVMS support for Microsoft COM/DCOM/OLE didn't see a
substantial uptake.
COM and .NET Core (just .NET after latest rebranding) are
very different.

I think .NET on VMS would be very interesting.

But also a huge task.

So it will not happen anytime soon.

Arne
Stephen Hoffman
2020-12-15 19:49:32 UTC
Reply
Permalink
COM and .NET Core (just .NET after latest rebranding) are very different.
Thank you Captain Obvious.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-12-15 21:08:22 UTC
Reply
Permalink
Post by Stephen Hoffman
COM and .NET Core (just .NET after latest rebranding) are very different.
Thank you Captain Obvious.
Point being that little interest for COM on VMS should not be taken
to predict little interest for .NET on VMS.

Arne
Stephen Hoffman
2020-12-15 17:02:50 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
There are no good choices here.

Your available choices are to...

...convince Synergex to port DIBOL/DBL, or convince somebody to port an
existing DIBOL compiler or to write a new DIBOL compiler for you, or
write one yourself. For folks writing a new DIBOL compiler, the back
end will prolly be LLVM, that for either native code or (using
emscripten) to WebAssembly for browser-based operations, or otherwise.
And no, I'm not aware of an open-source DIBOL compiler.

...translate the existing DIBOL code into C or into some other
language, using the available d2c or dibol2c or other tooling, or
home-grown tooling. That'll prolly then best use a C refactoring tool
such as Xcode or a Visual Studio Code plug-in, or potentially using
manual translations. That there are vendors with automated translation
services available would not surprise. I looked around for tools that
translated into C, there may well be other language targets for other
tools. Migration Specialties was offering CBL, though that targets DEC
VAX DIBOL and apparently doesn't target DIBOL/DBL.

...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.

...If the project is just starting and there is not yet an extensive
installed base of DIBOL code, use a different programming language with
the required support. VSI expects to have BASIC, Fortran, and COBOL
available for OpenVMS x86-64, and there are other common languages and
other DSLs available for various requirements.

...Leave (for another job, retirement, etc) before this DIBOL situation
blows up; defer, delay, deny, etc.


Absent a sufficiently large number of zeros included with the request,
VSI won't be writing the compiler for you. They've far too much work
already. VSI also prolly doesn't have the VAX DIBOL compiler source
code as AFAIK all that went to the predecessor of Syngergex a
quarter-century ago.

Complicating the cost calculations, if Synergex isn't porting
DIBOL/DBL, that can be inferred to believe the market here is small,
and which usually then means a custom compiler will be expensive, and
for a product at risk of being undercut by some future port by
Synergex. That'll be an expensive compiler, for the work and for the
risk involved.

It's also some time before this OpenVMS x86-64 discussion is even
particularly relevant, as the second native-tooling beta V9.1 hasn't
arrived yet (early 2021 was predicted), and the V9.2 production release
will prolly be a year or three after that. Few third-party vendors are
likely to commit to porting until after V9.1 is available and tested,
and variously of those vendors may not release statements until much
closer to or even after V9.2 is released; until they know more about
the target and about the platform and the market.

If the priority for this whole porting discussion is due to concerns
about existing and old hardware, maybe replace that with less-old
hardware and/or with emulation as an interim step in whatever the
long-term plans here might be.

The referenced dibol2c and d2c tools are open-source. YMMV, etc.

There are various LLVM examples around, and open-source projects using
LLVM, if you're inclined to write your own front-end and DIBOL parser.
http://llvm.org/docs/tutorial/index.html
https://tomassetti.me/a-tutorial-on-how-to-write-a-compiler-using-llvm/
Etc.

*Visions of a GoFundMe being run for and by the few sites still using DIBOL*
--
Pure Personal Opinion | HoffmanLabs LLC
ultr...@gmail.com
2020-12-15 17:14:04 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
There are no good choices here.
Your available choices are to...
...convince Synergex to port DIBOL/DBL, or convince somebody to port an
existing DIBOL compiler or to write a new DIBOL compiler for you, or
write one yourself. For folks writing a new DIBOL compiler, the back
end will prolly be LLVM, that for either native code or (using
emscripten) to WebAssembly for browser-based operations, or otherwise.
And no, I'm not aware of an open-source DIBOL compiler.
...translate the existing DIBOL code into C or into some other
language, using the available d2c or dibol2c or other tooling, or
home-grown tooling. That'll prolly then best use a C refactoring tool
such as Xcode or a Visual Studio Code plug-in, or potentially using
manual translations. That there are vendors with automated translation
services available would not surprise. I looked around for tools that
translated into C, there may well be other language targets for other
tools. Migration Specialties was offering CBL, though that targets DEC
VAX DIBOL and apparently doesn't target DIBOL/DBL.
...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.
...If the project is just starting and there is not yet an extensive
installed base of DIBOL code, use a different programming language with
the required support. VSI expects to have BASIC, Fortran, and COBOL
available for OpenVMS x86-64, and there are other common languages and
other DSLs available for various requirements.
...Leave (for another job, retirement, etc) before this DIBOL situation
blows up; defer, delay, deny, etc.
Absent a sufficiently large number of zeros included with the request,
VSI won't be writing the compiler for you. They've far too much work
already. VSI also prolly doesn't have the VAX DIBOL compiler source
code as AFAIK all that went to the predecessor of Syngergex a
quarter-century ago.
Complicating the cost calculations, if Synergex isn't porting
DIBOL/DBL, that can be inferred to believe the market here is small,
and which usually then means a custom compiler will be expensive, and
for a product at risk of being undercut by some future port by
Synergex. That'll be an expensive compiler, for the work and for the
risk involved.
It's also some time before this OpenVMS x86-64 discussion is even
particularly relevant, as the second native-tooling beta V9.1 hasn't
arrived yet (early 2021 was predicted), and the V9.2 production release
will prolly be a year or three after that. Few third-party vendors are
likely to commit to porting until after V9.1 is available and tested,
and variously of those vendors may not release statements until much
closer to or even after V9.2 is released; until they know more about
the target and about the platform and the market.
If the priority for this whole porting discussion is due to concerns
about existing and old hardware, maybe replace that with less-old
hardware and/or with emulation as an interim step in whatever the
long-term plans here might be.
The referenced dibol2c and d2c tools are open-source. YMMV, etc.
There are various LLVM examples around, and open-source projects using
LLVM, if you're inclined to write your own front-end and DIBOL parser.
http://llvm.org/docs/tutorial/index.html
https://tomassetti.me/a-tutorial-on-how-to-write-a-compiler-using-llvm/
Etc.
*Visions of a GoFundMe being run for and by the few sites still using DIBOL*
--
Pure Personal Opinion | HoffmanLabs LLC
WHY WOULD YOU DO ALL OF THAT? SYNERGY DBL CAN JUST BE PORTED TO EITHER WINDOZE OR LINUX. IT RUNS ON 3 OS ENVIRONMENTS.
BUT THAT MEANS GOOD BYE OPENVMS PLATFORM.
Stephen Hoffman
2020-12-15 20:00:45 UTC
Reply
Permalink
Post by ***@gmail.com
Post by Stephen Hoffman
...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.
...
WHY WOULD YOU DO ALL OF THAT? SYNERGY DBL CAN JUST BE PORTED TO EITHER
WINDOZE OR LINUX. IT RUNS ON 3 OS ENVIRONMENTS.
BUT THAT MEANS GOOD BYE OPENVMS PLATFORM.
Use whatever platforms best meet your current and expected needs.

Whether that's Microsoft Windows, Linux, OpenVMS, or otherwise.

DIBOL is not a common choice for new development in this era, which
then makes a DIBOL prerequisite problematic.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-12-16 13:25:30 UTC
Reply
Permalink
Post by Stephen Hoffman
DIBOL is not a common choice for new development in this era, which
then makes a DIBOL prerequisite problematic.
VMS is not a common choice for new development in this era, which
then makes a VMS prerequisite problematic.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2020-12-15 17:51:47 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
...convince Synergex to port DIBOL/DBL, or convince somebody to port an
existing DIBOL compiler or to write a new DIBOL compiler for you, or
write one yourself. For folks writing a new DIBOL compiler, the back end
will prolly be LLVM, that for either native code or (using emscripten)
to WebAssembly for browser-based operations, or otherwise. And no, I'm
not aware of an open-source DIBOL compiler.
Synergex may be convinced to do it.

Somebody creating a Dibol compiler from scratch seems unrealistic.
Post by Stephen Hoffman
...translate the existing DIBOL code into C or into some other language,
using the available d2c or dibol2c or other tooling, or home-grown
tooling.
The referenced dibol2c and d2c tools are open-source. YMMV, etc.
In my opinion either Dibol was the wrong choice to begin with or
C is the wrong choice to port to.

If it is traditional business code, then using C in 2020 does
not make much sense in my opinion.
Post by Stephen Hoffman
...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.
Synergex supports other platforms.

I have no idea if Synergex DBL code is portable between
their supported platforms.

Arne
Doug Phillips
2020-12-15 18:24:54 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
...convince Synergex to port DIBOL/DBL, or convince somebody to port
an existing DIBOL compiler or to write a new DIBOL compiler for you,
or write one yourself. For folks writing a new DIBOL compiler, the
back end will prolly be LLVM, that for either native code or (using
emscripten) to WebAssembly for browser-based operations, or otherwise.
And no, I'm not aware of an open-source DIBOL compiler.
Synergex may be convinced to do it.
Somebody creating a Dibol compiler from scratch seems unrealistic.
Post by Stephen Hoffman
...translate the existing DIBOL code into C or into some other
language, using the available d2c or dibol2c or other tooling, or
home-grown tooling.
The referenced dibol2c and d2c tools are open-source. YMMV, etc.
In my opinion either Dibol was the wrong choice to begin with or
C is the wrong choice to port to.
If it is traditional business code, then using C in 2020 does
not make much sense in my opinion.
Post by Stephen Hoffman
...port the DIBOL apps to another platform with a supported DIBOL
compiler. This when continued use of the current platform and current
compiler becomes untenable. This other platform may well co-exist as a
guest with OpenVMS x86-64 in a virtual machine, too. Either long-term,
or for the duration of the platform migration.
Synergex supports other platforms.
I have no idea if Synergex DBL code is portable between
their supported platforms.
Arne
If you don't use OS-specific code, it is portable; compile, link & run.
If a language routine exists in multiple OS versions, then the routine's
internals handle the differences.

When we ported some code from old PDP-11 DIBOL to VAX and then VAX to
Alpha/DBL it was compile, link & run. We adjusted a few things
afterwards to take advantage of the OS differences and processor speed.
We had code running on TSX+ so we were familiar with DBL. Going from
there to Windows/*nix needed some tweaking because there were some DEC
specifics in our code, but it was easy. Fortunately most of that code
was in our subroutines so we could just make OS-specific versions of
those routines & libraries. We did add some compile-time options to some
routines so they could live on any platform.

Synergy/DBL is DIBOL standards compliant but it goes way beyond DIBOL.
And, it really shouldn't be called DIBOL anymore unless it's actually DIBOL.
Steve Ives
2020-12-15 21:42:49 UTC
Reply
Permalink
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
Just a quick note to point out that the content of this post is inaccurate.

My name is Steve Ives, and I work for Synergex as the Synergy/DE Product Manager. We are indeed currently reviewing whether to port Synergy/DE to OpenVMS on x86, but no decision has yet been made. For the past ten months, we have been actively engaged with our many OpenVMS customers, both ISV's and end-users alike, making sure that they are fully aware of the significant changes taking place in the OpenVMS market place and community, helping them to understand their many options, and trying to judge demand for a Synergy/DE port to OpenVMS on the x86 platform.

We at Synergex are proud of our long-standing involvement with and service to the OpenVMS development community, but we are a business and can only invest in porting our products to new platforms if there is sufficient commercial demand for us to do so. Unfortunately, at the current time, there appears to be very little demand. But this is not a done deal; discussions are still taking place, both internally and with our customers. OpenVMS is still an important part of our business, and we remain fully committed to delivering exceptional service to our many valued customers in that space.

I would also like to point out that we are, of course, in contact with VSI, at the highest possible levels and that we value the ongoing relationship that we have shared since the launch of their company back in 2014.

I'm not sure if this forum strips out email addresses, but if anyone wants to contact me directly regarding this topic, you can do so by emailing me at "steve dot ives at synergex.com".

Steve Ives
Product Manager
Synergex International, Corp.
Phillip Helbig (undress to reply)
2020-12-16 08:11:50 UTC
Reply
Permalink
Post by Steve Ives
Post by ***@gmail.com
So Synergex as of now refuses to port their OpenVMS version of DIBOL to OpenVMS X86.
This is a request for VMS software to port VAX DIBOL to the x86 OpenVMS environment.
I have started a project using DIBOL and need to implement it on the x86 platform.
Just a quick note to point out that the content of this post is inaccurate.
I know almost nothing about DIBOL and so have just been skimming the
posts in this thread. However, even to me it was clear that THE
DECISION HAD NOT BEEN MADE, i.e. there was no "refusal to port the
product" or whatever.
Post by Steve Ives
My name is Steve Ives, and I work for Synergex as the Synergy/DE Product
Manager. We are indeed currently reviewing whether to port Synergy/DE to
OpenVMS on x86, but no decision has yet been made.
Sounds pretty official to me.
Post by Steve Ives
Unfortunately, at the current time, there appears to be very little demand.
That's the way the cookie crumbles. If you really, really need a
product which requires significant effort, but the total revenue from
all customers is not enough to do so, then tough luck.
Post by Steve Ives
I would also like to point out that we are, of course, in contact with VSI,
at the highest possible levels and that we value the ongoing relationship
that we have shared since the launch of their company back in 2014.
Sounds pretty official to me.
Simon Clubley
2020-12-16 13:47:36 UTC
Reply
Permalink
Post by Steve Ives
Just a quick note to point out that the content of this post is inaccurate.
My name is Steve Ives, and I work for Synergex as the Synergy/DE Product
Manager. We are indeed currently reviewing whether to port Synergy/DE to
OpenVMS on x86, but no decision has yet been made. For the past ten months,
we have been actively engaged with our many OpenVMS customers, both ISV's
and end-users alike, making sure that they are fully aware of the
significant changes taking place in the OpenVMS market place and community,
helping them to understand their many options, and trying to judge demand
for a Synergy/DE port to OpenVMS on the x86 platform.
We at Synergex are proud of our long-standing involvement with and
service to the OpenVMS development community, but we are a business and can
only invest in porting our products to new platforms if there is sufficient
commercial demand for us to do so. Unfortunately, at the current time,
there appears to be very little demand. But this is not a done deal;
discussions are still taking place, both internally and with our customers.
OpenVMS is still an important part of our business, and we remain fully
committed to delivering exceptional service to our many valued customers in
that space.
Interesting. You say that VMS is still important to you and that you
have many VMS customers, but that there is very little demand for running
Synergy on x86-64 VMS.

Do you know why that is ? Was there initial demand but it died off as
the VMS on x86-64 port took longer and longer to complete ?

And before people jump on me for asking that, just remember that VMS
currently only runs in production use on obsolete or soon to be obsolete
architectures. That by itself is enough to make some people uncomfortable
regardless of the merits of VMS itself, especially given that VMS on x86-64
for production use is still some way off and we don't know if the timetable
is going to further slip.

The reason for asking this question is simple: is there anything that VSI
can do at this stage to make Synergex's customers stay on the VMS path for
a bit longer instead of switching to another operating system ?

He says that Synergex still has many VMS customers, so now is the time
for VSI to act if there's still any chance of convincing them to remain
as VMS customers.
Post by Steve Ives
I would also like to point out that we are, of course, in contact with
VSI, at the highest possible levels and that we value the ongoing
relationship that we have shared since the launch of their company back in
2014.
That's nice to hear but I am puzzled why you have only been actively
engaged with the VMS customers over the last 10 months.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-12-16 15:07:18 UTC
Reply
Permalink
Post by Simon Clubley
Post by Steve Ives
Just a quick note to point out that the content of this post is inaccurate.
My name is Steve Ives, and I work for Synergex as the Synergy/DE Product
Manager. We are indeed currently reviewing whether to port Synergy/DE to
OpenVMS on x86, but no decision has yet been made. For the past ten months,
we have been actively engaged with our many OpenVMS customers, both ISV's
and end-users alike, making sure that they are fully aware of the
significant changes taking place in the OpenVMS market place and community,
helping them to understand their many options, and trying to judge demand
for a Synergy/DE port to OpenVMS on the x86 platform.
We at Synergex are proud of our long-standing involvement with and
service to the OpenVMS development community, but we are a business and can
only invest in porting our products to new platforms if there is sufficient
commercial demand for us to do so. Unfortunately, at the current time,
there appears to be very little demand. But this is not a done deal;
discussions are still taking place, both internally and with our customers.
OpenVMS is still an important part of our business, and we remain fully
committed to delivering exceptional service to our many valued customers in
that space.
Interesting. You say that VMS is still important to you and that you
have many VMS customers, but that there is very little demand for running
Synergy on x86-64 VMS.
Do you know why that is ? Was there initial demand but it died off as
the VMS on x86-64 port took longer and longer to complete ?
And before people jump on me for asking that, just remember that VMS
currently only runs in production use on obsolete or soon to be obsolete
architectures. That by itself is enough to make some people uncomfortable
regardless of the merits of VMS itself, especially given that VMS on x86-64
for production use is still some way off and we don't know if the timetable
is going to further slip.
The reason for asking this question is simple: is there anything that VSI
can do at this stage to make Synergex's customers stay on the VMS path for
a bit longer instead of switching to another operating system ?
He says that Synergex still has many VMS customers, so now is the time
for VSI to act if there's still any chance of convincing them to remain
as VMS customers.
Post by Steve Ives
I would also like to point out that we are, of course, in contact with
VSI, at the highest possible levels and that we value the ongoing
relationship that we have shared since the launch of their company back in
2014.
That's nice to hear but I am puzzled why you have only been actively
engaged with the VMS customers over the last 10 months.
Simon.
I've watched you beat this subject to death for a while Simon. It
appears that you're being a bit "inventive". Where did you get the idea
of "last 10 months" when Steve Ives clearly stated that Synergex has
been in contact with VSI since 2014?

Regardless, this entire thread about DIBOL on x86 VMS, just as the topic
of Rdb on x86 VMS, is a bit premature. At "this time" there is no x86
on VMS, unless one accepts cross compilers to build executables. I do
not do so. As an ISV, I will look at x86 VMS when it actually exists.
I do believe that it will soon exist, and will be a path forward for
current users of VMS, and an option for new users in the future.

You may believe differently. As an ISV using VMS, and in contact with
VSI, I suggest that perhaps your beliefs are not the same as ISVs using VMS.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-12-16 17:21:42 UTC
Reply
Permalink
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-12-16 18:14:49 UTC
Reply
Permalink
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
Thank you Stephen.

I accept David's upcoming apology for accusing me of being "inventive".

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John H. Reinhardt
2020-12-16 19:34:44 UTC
Reply
Permalink
Post by Simon Clubley
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
Thank you Stephen.
I accept David's upcoming apology for accusing me of being "inventive".
Simon.
For the past ten months, we have been actively engaged with our many OpenVMS customers, both ISV's and end-users alike,
and
Post by Simon Clubley
I would also like to point out that we are, of course, in contact with VSI, at the highest possible levels and that we value the ongoing relationship that we have shared since the launch of their company back in 2014.
Which implies that while Synergex has been talking with *customers* and *ISVs* for the past 10 months, they also have been in contact with VSI since 2014.

I believe Simon may have interpreted that the former implied that the connection with VSI had only been for the last 10 months when Steve's email clearly says since 2014.

Simon may owe Dave an apology...
--
John H. Reinhardt
m***@gmail.com
2020-12-16 20:20:06 UTC
Reply
Permalink
Post by John H. Reinhardt
Post by Simon Clubley
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
Thank you Stephen.
I accept David's upcoming apology for accusing me of being "inventive".
Simon.
For the past ten months, we have been actively engaged with our many OpenVMS customers, both ISV's and end-users alike,
and
Post by Simon Clubley
I would also like to point out that we are, of course, in contact with VSI, at the highest possible levels and that we value the ongoing relationship that we have shared since the launch of their company back in 2014.
Which implies that while Synergex has been talking with *customers* and *ISVs* for the past 10 months, they also have been in contact with VSI since 2014.
I believe Simon may have interpreted that the former implied that the connection with VSI had only been for the last 10 months when Steve's email clearly says since 2014.
Simon may owe Dave an apology...
--
John H. Reinhardt
what matters is VSI gets the Synergy DIBOL port done.

Synergy DBL has its own DBMS as well as connectivity tools galore.
DBL is light years ahead of basic cobol fortran compilers
VMS has now. Losing it as a development platform could cost
potential customers down the road.
Steve Ives
2020-12-16 20:24:33 UTC
Reply
Permalink
By the way, just a bit of fun. In modern "DIBOL", written in Visual Studio (optional), bottles of beer can now be done like this:

proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")

Steve
m***@gmail.com
2020-12-16 20:35:17 UTC
Reply
Permalink
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
Steve
Steve here is the top 50 most vulnerable OSs so far to make a point.

Top 50 Products By Total Number Of "Distinct" Vulnerabilities
Go to year: 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 All Time Leaders
Product Name Vendor Name Product Type Number of Vulnerabilities
1 Debian Linux Debian OS 3067
2 Android Google OS 2563
3 Linux Kernel Linux OS 2357
4 Mac Os X Apple OS 2212
5 Ubuntu Linux Canonical OS 2007
6 Firefox Mozilla Application 1873
7 Chrome Google Application 1858
8 Iphone Os Apple OS 1655
9 Windows Server 2008 Microsoft OS 1421
10 Windows 7 Microsoft OS 1283
11 Acrobat Reader Dc Adobe Application 1182
12 Acrobat Dc Adobe Application 1182
13 Windows 10 Microsoft OS 1111
14 Flash Player Adobe Application 1078
15 Windows Server 2012 Microsoft OS 1050
16 Enterprise Linux Desktop Redhat OS 1039
17 Internet Explorer Microsoft Application 1030
18 Safari Apple Application 1029
19 Enterprise Linux Server Redhat OS 979
20 Windows 8.1 Microsoft OS 978
21 Acrobat Adobe Application 949
22 Enterprise Linux Workstation Redhat OS 941
23 Thunderbird Mozilla Application 921
24 Opensuse Opensuse OS 918
25 Windows Server 2016 Microsoft OS 889
26 Windows Rt 8.1 Microsoft OS 848
27 Windows Vista Microsoft OS 831
28 Windows Xp Microsoft OS 741
29 Mysql Oracle Application 716
30 Seamonkey Mozilla Application 698
31 Fedora Fedoraproject OS 697
32 Acrobat Reader Adobe Application 681
33 Firefox Esr Mozilla Application 672
34 Enterprise Linux Redhat OS 662
35 Mac Os X Server Apple OS 640
36 IE Microsoft Application 631
37 JRE Oracle Application 617
38 Edge Microsoft Application 615
39 JDK Oracle Application 607
40 PHP PHP Application 604
41 Itunes Apple Application 601
42 Leap Opensuse OS 595
43 Wireshark Wireshark Application 576
44 Sunos SUN OS 569
45 Office Microsoft Application 546
46 Imagemagick Imagemagick Application 545
47 IOS Cisco OS 532
48 Windows 2000 Microsoft OS 514
49 Watchos Apple OS 473
50 Solaris SUN OS 465
Jon Pinkley
2020-12-18 04:54:39 UTC
Reply
Permalink
Post by m***@gmail.com
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
Steve
Steve here is the top 50 most vulnerable OSs so far to make a point.
Top 50 Products By Total Number Of "Distinct" Vulnerabilities
Go to year: 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 All Time Leaders
Product Name Vendor Name Product Type Number of Vulnerabilities
1 Debian Linux Debian OS 3067
2 Android Google OS 2563
3 Linux Kernel Linux OS 2357
4 Mac Os X Apple OS 2212
5 Ubuntu Linux Canonical OS 2007
6 Firefox Mozilla Application 1873
7 Chrome Google Application 1858
8 Iphone Os Apple OS 1655
9 Windows Server 2008 Microsoft OS 1421
10 Windows 7 Microsoft OS 1283
11 Acrobat Reader Dc Adobe Application 1182
12 Acrobat Dc Adobe Application 1182
13 Windows 10 Microsoft OS 1111
14 Flash Player Adobe Application 1078
15 Windows Server 2012 Microsoft OS 1050
16 Enterprise Linux Desktop Redhat OS 1039
17 Internet Explorer Microsoft Application 1030
18 Safari Apple Application 1029
19 Enterprise Linux Server Redhat OS 979
20 Windows 8.1 Microsoft OS 978
21 Acrobat Adobe Application 949
22 Enterprise Linux Workstation Redhat OS 941
23 Thunderbird Mozilla Application 921
24 Opensuse Opensuse OS 918
25 Windows Server 2016 Microsoft OS 889
26 Windows Rt 8.1 Microsoft OS 848
27 Windows Vista Microsoft OS 831
28 Windows Xp Microsoft OS 741
29 Mysql Oracle Application 716
30 Seamonkey Mozilla Application 698
31 Fedora Fedoraproject OS 697
32 Acrobat Reader Adobe Application 681
33 Firefox Esr Mozilla Application 672
34 Enterprise Linux Redhat OS 662
35 Mac Os X Server Apple OS 640
36 IE Microsoft Application 631
37 JRE Oracle Application 617
38 Edge Microsoft Application 615
39 JDK Oracle Application 607
40 PHP PHP Application 604
41 Itunes Apple Application 601
42 Leap Opensuse OS 595
43 Wireshark Wireshark Application 576
44 Sunos SUN OS 569
45 Office Microsoft Application 546
46 Imagemagick Imagemagick Application 545
47 IOS Cisco OS 532
48 Windows 2000 Microsoft OS 514
49 Watchos Apple OS 473
50 Solaris SUN OS 465
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.

And the lack of reported vulnerabilities has very little to do with real vulnerabilities.

For example, I don't see CP/M or MS-DOS or even Windows 95, Windows 98, or Windows NT on the list. Does that imply they have no vulnerabilities?

I don't see any SCADA devices on the list either.
Simon Clubley
2020-12-18 13:38:55 UTC
Reply
Permalink
Post by Jon Pinkley
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.
Bob is just being Bob. :-)
Post by Jon Pinkley
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
Thank you. That's another point I wish more people understood.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
s***@gmail.com
2020-12-18 14:02:18 UTC
Reply
Permalink
Post by Simon Clubley
Post by Jon Pinkley
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.
Bob is just being Bob. :-)
you mean right again :)
Post by Simon Clubley
Post by Jon Pinkley
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
Thank you. That's another point I wish more people understood.
I hope you also understand that history is a good way to gauge future events.
Post by Simon Clubley
Simon.
--
Walking destinations on a map are further away than they appear.
Simon Clubley
2020-12-18 18:31:46 UTC
Reply
Permalink
Post by s***@gmail.com
Post by Simon Clubley
Post by Jon Pinkley
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
Thank you. That's another point I wish more people understood.
I hope you also understand that history is a good way to gauge future events.
Only if the operating systems being compared have the same level
of probing. Linux and Windows are probed by an entire army of
security researchers every day. VMS might get probed once in a
blue moon (at least until someone notices VSI's marketing claims).

Jon is right in his comment above and it's the same thing I have
also said multiple times.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Michael C
2020-12-20 00:03:42 UTC
Reply
Permalink
Post by Simon Clubley
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.
Bob is just being Bob. :-)
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
Thank you. That's another point I wish more people understood.
Simon.
--
Walking destinations on a map are further away than they appear.
so you are saying this is invalid

https://www.cvedetails.com/product/4990/HP-Openvms.html?vendor_id=10
Simon Clubley
2020-12-21 01:18:35 UTC
Reply
Permalink
Post by Michael C
Post by Simon Clubley
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.
Bob is just being Bob. :-)
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
Thank you. That's another point I wish more people understood.
so you are saying this is invalid
https://www.cvedetails.com/product/4990/HP-Openvms.html?vendor_id=10
That's _exactly_ what I am saying!!!

When VMS has the same number of people probing it daily that Linux
does then you can do that comparison. Until then, the comparison
means absolutely nothing.

BTW, I hope the summary pages for the other CVEs are more accurate
than the one for my CVE is. :-)

Just for the record, the most glaring oversight is in the "Integrity
Impact" section. With my exploit, you can modify whatever you want
and you have _full_ control over what is modified without any limits.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-12-21 16:17:06 UTC
Reply
Permalink
When VMS has the same number of people probing it daily that Linux does
then you can do that comparison. Until then, the comparison means
absolutely nothing.
To extend this...

When the OpenVMS owners even *log* CVEs, when others *target* OpenVMS,
when the variety of components receiving CVEs within an OS are
comparable, etc., *then* comparing CVE accounts... will still be less
than a pile of manure mulch.

There's a whole pile of SMH CVEs waiting, for anybody that wants to
investigate those. I've verified a couple against OpenVMS, and they do
work. But those more recent SMH CVEs were never logged against OpenVMS,
only Linux and Windows. I don't think that NTP reflection attack was
logged as a CVE against OpenVMS, either. The applicable Apache CVEs
definitely weren't logged against OpenVMS.

"But Apache isn't part of OpenVMS!" is quite true, but then various of
the OSes often compared do include Apache in their CVE counts. And many
other pieces OpenVMS does not. BIND, for instance, is present, and
there've been various BIND updates since the version that has shipped
with TCP/IP Services. Which means a less-problematic CVE count
comparison has to filter all those other pieces out, and account for
the OpenVMS CVEs that were fixed but not logged. And that's still
subject to differing vendor policies and differing researcher policies
around logging CVEs.

That NTP reflection attack:
https://groups.google.com/g/comp.os.vms/c/s_Oq-Oug76I/m/uWfSOz5fmosJ
Apache: https://www.cvedetails.com/vulnerability-list.php?vendor_id=45
SMH: https://www.cvedetails.com/google-search-results.php?q=smh&sa=Search
etc.

So in conclusion... comparing CVEs across wildly-disparate operating
systems with disparate CVE-logging policies provides a pile of "data"
that is... less than the argument that the author might think it is.
--
Pure Personal Opinion | HoffmanLabs LLC
s***@gmail.com
2020-12-18 14:00:01 UTC
Reply
Permalink
Post by Jon Pinkley
Post by m***@gmail.com
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
Steve
Steve here is the top 50 most vulnerable OSs so far to make a point.
Top 50 Products By Total Number Of "Distinct" Vulnerabilities
Go to year: 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 All Time Leaders
Product Name Vendor Name Product Type Number of Vulnerabilities
1 Debian Linux Debian OS 3067
2 Android Google OS 2563
3 Linux Kernel Linux OS 2357
4 Mac Os X Apple OS 2212
5 Ubuntu Linux Canonical OS 2007
6 Firefox Mozilla Application 1873
7 Chrome Google Application 1858
8 Iphone Os Apple OS 1655
9 Windows Server 2008 Microsoft OS 1421
10 Windows 7 Microsoft OS 1283
11 Acrobat Reader Dc Adobe Application 1182
12 Acrobat Dc Adobe Application 1182
13 Windows 10 Microsoft OS 1111
14 Flash Player Adobe Application 1078
15 Windows Server 2012 Microsoft OS 1050
16 Enterprise Linux Desktop Redhat OS 1039
17 Internet Explorer Microsoft Application 1030
18 Safari Apple Application 1029
19 Enterprise Linux Server Redhat OS 979
20 Windows 8.1 Microsoft OS 978
21 Acrobat Adobe Application 949
22 Enterprise Linux Workstation Redhat OS 941
23 Thunderbird Mozilla Application 921
24 Opensuse Opensuse OS 918
25 Windows Server 2016 Microsoft OS 889
26 Windows Rt 8.1 Microsoft OS 848
27 Windows Vista Microsoft OS 831
28 Windows Xp Microsoft OS 741
29 Mysql Oracle Application 716
30 Seamonkey Mozilla Application 698
31 Fedora Fedoraproject OS 697
32 Acrobat Reader Adobe Application 681
33 Firefox Esr Mozilla Application 672
34 Enterprise Linux Redhat OS 662
35 Mac Os X Server Apple OS 640
36 IE Microsoft Application 631
37 JRE Oracle Application 617
38 Edge Microsoft Application 615
39 JDK Oracle Application 607
40 PHP PHP Application 604
41 Itunes Apple Application 601
42 Leap Opensuse OS 595
43 Wireshark Wireshark Application 576
44 Sunos SUN OS 569
45 Office Microsoft Application 546
46 Imagemagick Imagemagick Application 545
47 IOS Cisco OS 532
48 Windows 2000 Microsoft OS 514
49 Watchos Apple OS 473
50 Solaris SUN OS 465
I am not sure what point you are trying to make. Most of those "products" are not Operating Systems.
And the lack of reported vulnerabilities has very little to do with real vulnerabilities.
For example, I don't see CP/M or MS-DOS or even Windows 95, Windows 98, or Windows NT on the list. Does that imply they have no vulnerabilities?
I don't see any SCADA devices on the list either.
vulnerability history is a good way to gauge future occurences and the stability of the overall OS. I can cut out the non OS stuff if you can't and you will get a good idea of the insecure OSs.
Arne Vajhøj
2020-12-17 01:49:50 UTC
Reply
Permalink
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
Is that just for .NET platform or have you
implemented Console.WriteLine for native as well?

Arne
Steve Ives
2020-12-17 04:17:39 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
Is that just for .NET platform or have you
implemented Console.WriteLine for native as well?
Arne
In this form it's .NET code, but we do have Console.WriteLine in traditional DBL (DIBOL) also. But it doesn't do all the String.Format() substitution stuff.
Simon Clubley
2020-12-17 01:56:41 UTC
Reply
Permalink
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
That's not your grandfather's DIBOL. :-)

That's like the difference between Fortran 77 and the current Fortran
standards. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2020-12-17 02:07:49 UTC
Reply
Permalink
Post by Simon Clubley
Post by Steve Ives
proc
data i, int
for i from 99 thru 1 by -1
Console.WriteLine("{0} Bottle{2} of Beer on the wall,{1}{0} Bottle{2} of Beer,{1}Take one down, pass it around,{1}{0} Bottle{2} of Beer on the wall.'{1}",i,%char(13)+%char(10),i>1?"s":"")
That's not your grandfather's DIBOL. :-)
That's like the difference between Fortran 77 and the current Fortran
standards. :-)
Or real C and ANSI C. :-)

bill
Simon Clubley
2020-12-17 01:54:33 UTC
Reply
Permalink
Post by John H. Reinhardt
Post by Simon Clubley
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
Thank you Stephen.
I accept David's upcoming apology for accusing me of being "inventive".
Simon.
For the past ten months, we have been actively engaged with our many OpenVMS customers, both ISV's and end-users alike,
and
Post by Simon Clubley
I would also like to point out that we are, of course, in contact with VSI, at the highest possible levels and that we value the ongoing relationship that we have shared since the launch of their company back in 2014.
Which implies that while Synergex has been talking with *customers* and
*ISVs* for the past 10 months, they also have been in contact with VSI since
2014.
That's how I read it.
Post by John H. Reinhardt
I believe Simon may have interpreted that the former implied that the
connection with VSI had only been for the last 10 months when Steve's email
clearly says since 2014.
The problem with that theory is that I directly quoted Steve saying they
had been in touch with VSI since 2014. :-)

There is a difference between Synergex talking to VSI and Synergex also
talking to _their_ customers and Steve has now clarified his comments.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-12-16 19:58:35 UTC
Reply
Permalink
Post by Simon Clubley
...For the past ten months, we have been actively engaged with our many
OpenVMS customers...
...Where did you get the idea of "last 10 months" when Steve Ives
clearly stated that Synergex has been in contact with VSI since 2014?...
Thank you Stephen.
I accept David's upcoming apology for accusing me of being "inventive".
Simon.
Guess I've lost any ability to read accurately.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Steve Ives
2020-12-16 18:16:42 UTC
Reply
Permalink
Post by Simon Clubley
Post by Steve Ives
Just a quick note to point out that the content of this post is inaccurate.
My name is Steve Ives, and I work for Synergex as the Synergy/DE Product
Manager. We are indeed currently reviewing whether to port Synergy/DE to
OpenVMS on x86, but no decision has yet been made. For the past ten months,
we have been actively engaged with our many OpenVMS customers, both ISV's
and end-users alike, making sure that they are fully aware of the
significant changes taking place in the OpenVMS market place and community,
helping them to understand their many options, and trying to judge demand
for a Synergy/DE port to OpenVMS on the x86 platform.
We at Synergex are proud of our long-standing involvement with and
service to the OpenVMS development community, but we are a business and can
only invest in porting our products to new platforms if there is sufficient
commercial demand for us to do so. Unfortunately, at the current time,
there appears to be very little demand. But this is not a done deal;
discussions are still taking place, both internally and with our customers.
OpenVMS is still an important part of our business, and we remain fully
committed to delivering exceptional service to our many valued customers in
that space.
Interesting. You say that VMS is still important to you and that you
have many VMS customers, but that there is very little demand for running
Synergy on x86-64 VMS.
Do you know why that is ? Was there initial demand but it died off as
the VMS on x86-64 port took longer and longer to complete ?
And before people jump on me for asking that, just remember that VMS
currently only runs in production use on obsolete or soon to be obsolete
architectures. That by itself is enough to make some people uncomfortable
regardless of the merits of VMS itself, especially given that VMS on x86-64
for production use is still some way off and we don't know if the timetable
is going to further slip.
The reason for asking this question is simple: is there anything that VSI
can do at this stage to make Synergex's customers stay on the VMS path for
a bit longer instead of switching to another operating system ?
He says that Synergex still has many VMS customers, so now is the time
for VSI to act if there's still any chance of convincing them to remain
as VMS customers.
Post by Steve Ives
I would also like to point out that we are, of course, in contact with
VSI, at the highest possible levels and that we value the ongoing
relationship that we have shared since the launch of their company back in
2014.
That's nice to hear but I am puzzled why you have only been actively
engaged with the VMS customers over the last 10 months.
Simon.
--
Walking destinations on a map are further away than they appear.
Hi Simon,

There are many reasons that there is little demand. Some customers have been working towards alternate solutions (applications) for some time, and that process will continue for them, while others have several options available. Probably the main reason that there is a lack of interest in x86 is that many customers plan to move their "DIBOL" applications to alternate platforms, such as Linux or Windows. Synergy DBL is available on many platforms, and for most, porting an OpenVMS application to say Linux is almost a trivial exercise, and porting to Windows is not much harder. The fact of the matter is that most customers have several viable options available to them, and porting to OpenVMS on x86 is just one of those options.

And of course, we are constantly engaged and have close working relationships with all of our customers. My reference to the "last 10 months" was specifically referring to a series of webinars and meetings on this specific subject.

Steve Ives
m***@gmail.com
2020-12-16 18:23:31 UTC
Reply
Permalink
Post by Steve Ives
Post by Simon Clubley
Post by Steve Ives
Just a quick note to point out that the content of this post is inaccurate.
My name is Steve Ives, and I work for Synergex as the Synergy/DE Product
Manager. We are indeed currently reviewing whether to port Synergy/DE to
OpenVMS on x86, but no decision has yet been made. For the past ten months,
we have been actively engaged with our many OpenVMS customers, both ISV's
and end-users alike, making sure that they are fully aware of the
significant changes taking place in the OpenVMS market place and community,
helping them to understand their many options, and trying to judge demand
for a Synergy/DE port to OpenVMS on the x86 platform.
We at Synergex are proud of our long-standing involvement with and
service to the OpenVMS development community, but we are a business and can
only invest in porting our products to new platforms if there is sufficient
commercial demand for us to do so. Unfortunately, at the current time,
there appears to be very little demand. But this is not a done deal;
discussions are still taking place, both internally and with our customers.
OpenVMS is still an important part of our business, and we remain fully
committed to delivering exceptional service to our many valued customers in
that space.
Interesting. You say that VMS is still important to you and that you
have many VMS customers, but that there is very little demand for running
Synergy on x86-64 VMS.
Do you know why that is ? Was there initial demand but it died off as
the VMS on x86-64 port took longer and longer to complete ?
And before people jump on me for asking that, just remember that VMS
currently only runs in production use on obsolete or soon to be obsolete
architectures. That by itself is enough to make some people uncomfortable
regardless of the merits of VMS itself, especially given that VMS on x86-64
for production use is still some way off and we don't know if the timetable
is going to further slip.
The reason for asking this question is simple: is there anything that VSI
can do at this stage to make Synergex's customers stay on the VMS path for
a bit longer instead of switching to another operating system ?
He says that Synergex still has many VMS customers, so now is the time
for VSI to act if there's still any chance of convincing them to remain
as VMS customers.
Post by Steve Ives
I would also like to point out that we are, of course, in contact with
VSI, at the highest possible levels and that we value the ongoing
relationship that we have shared since the launch of their company back in
2014.
That's nice to hear but I am puzzled why you have only been actively
engaged with the VMS customers over the last 10 months.
Simon.
--
Walking destinations on a map are further away than they appear.
Hi Simon,
There are many reasons that there is little demand. Some customers have been working towards alternate solutions (applications) for some time, and that process will continue for them, while others have several options available. Probably the main reason that there is a lack of interest in x86 is that many customers plan to move their "DIBOL" applications to alternate platforms, such as Linux or Windows. Synergy DBL is available on many platforms, and for most, porting an OpenVMS application to say Linux is almost a trivial exercise, and porting to Windows is not much harder. The fact of the matter is that most customers have several viable options available to them, and porting to OpenVMS on x86 is just one of those options.
And of course, we are constantly engaged and have close working relationships with all of our customers. My reference to the "last 10 months" was specifically referring to a series of webinars and meetings on this specific subject.
Steve Ives
Sreve do you keep track of the CERT counts for linux and windows. If I was a customer that is the last choice I would make.
1tim....@gmail.com
2020-12-19 22:44:19 UTC
Reply
Permalink
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.

import parser
import System.Collections

record

parse ,@StringParser
arry ,@ArrayList
proc
parse = new StringParser() ;; create instance of parser

parse.parseNameValue("abc~123;test this string", "~",";") ;; load our test string to do name / value parse

console.writeline("-[abc~123;test this string]-")
console.writeLine("NameStr = "+ parse.ThisNameStr)
console.writeLine("valueStr = "+ parse.ThisValueStr)
console.writeLine("commentStr = "+ parse.ThisCommentStr)
console.writeline(" ")

parse.parseNameValue("~abc123;test this string", "~",";") ;;load case without name part of name value pair

console.writeline("-[~abc123;test this string]-")
console.writeLine("NameStr = "+ parse.ThisNameStr)
console.writeLine("valueStr = "+ parse.ThisValueStr)
console.writeLine("commentStr = "+ parse.ThisCommentStr)
console.writeline(" ")

parse.parseNameValue(";abc123test this string", "~",";") ;; load case where entire string is comment

console.writeline("-[;abc123test this string]-")
console.writeLine("NameStr = "+ parse.ThisNameStr)
console.writeLine("valueStr = "+ parse.ThisValueStr)
console.writeLine("commentStr = "+ parse.ThisCommentStr)
console.writeline(" ")

parse.parseNameValue("abc123test this string", "~",";") ;; load case with only name part

console.writeline("-[abc123test this string]-")
console.writeLine("NameStr = "+ parse.ThisNameStr)
console.writeLine("valueStr = "+ parse.ThisValueStr)
console.writeLine("commentStr = "+ parse.ThisCommentStr)
console.writeline(" ")

parse.parseList("A~B~C~D~E~F~G~;this is a comment", "~",";") ;; parse a list into an array object

arry = parse.ThisListArr

begin ;; use begin / end for local data scope
data count ,i4
data idx ,i4
data value ,@String

console.writeline("-[A~B~C~D~E~F~G~;this is a comment]-")

count = arry.count

console.writeline("ary contains: " + string(count) + " elements")

for idx from 1 thru count ;; loop thru array object
begin
value = (String) arry.indexer(idx-1)
console.writeLine(" { " + value + " }")
end

console.writeLine("commentStr = "+ parse.ThisCommentStr)

end
console.writeline(" ")


end
Arne Vajhøj
2020-12-20 01:34:53 UTC
Reply
Permalink
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).

If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.

Arne
1tim....@gmail.com
2020-12-21 20:15:16 UTC
Reply
Permalink
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
Arne
Arne Vajhøj
2020-12-22 02:07:15 UTC
Reply
Permalink
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??

Arne
Dave Froble
2020-12-22 04:16:43 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Arne
I got no idea what that is, but, why not? I'm assuming that it is some
procedure, and such can be implemented in almost any language. Doesn't
mean there is not a lot of code behind the capability, just that the
user doesn't have to write that code. A bit like what everyone seems to
like about things such as Python.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-12-22 15:02:11 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Arne
I got no idea what that is, but, why not?  I'm assuming that it is some
procedure, and such can be implemented in almost any language.  Doesn't
mean there is not a lot of code behind the capability, just that the
user doesn't have to write that code.  A bit like what everyone seems to
like about things such as Python.
Like with COBOL and a number of other legacy languages my objection
is when they totally change the language and still have the nerve to
call it what it was. Like calling "DELPHI" "Pascal" or calling "ANSI
C" "C". If you want a new language then give it a new name and stop
pretending it's something it is not. Kinda like calling "Windows"
"VMS" because Cutler helped develop it.

bill
Dave Froble
2020-12-22 16:34:53 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Arne
I got no idea what that is, but, why not? I'm assuming that it is
some procedure, and such can be implemented in almost any language.
Doesn't mean there is not a lot of code behind the capability, just
that the user doesn't have to write that code. A bit like what
everyone seems to like about things such as Python.
Like with COBOL and a number of other legacy languages my objection
is when they totally change the language and still have the nerve to
call it what it was. Like calling "DELPHI" "Pascal" or calling "ANSI
C" "C". If you want a new language then give it a new name and stop
pretending it's something it is not. Kinda like calling "Windows"
"VMS" because Cutler helped develop it.
bill
Well Bill, they don't call it DIBOL, they call it DBL.

Regardless, when extensions are made to an existing language, I would
not consider it "totally change".

As for me, I'm sort of tired of all the re-named stuff proliferating as
it does ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
1tim....@gmail.com
2020-12-22 17:19:28 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Arne
I got no idea what that is, but, why not? I'm assuming that it is some
procedure, and such can be implemented in almost any language. Doesn't
mean there is not a lot of code behind the capability, just that the
user doesn't have to write that code. A bit like what everyone seems to
like about things such as Python.
Like with COBOL and a number of other legacy languages my objection
is when they totally change the language and still have the nerve to
call it what it was. Like calling "DELPHI" "Pascal" or calling "ANSI
C" "C". If you want a new language then give it a new name and stop
pretending it's something it is not. Kinda like calling "Windows"
"VMS" because Cutler helped develop it.
bill
Ironically, you'd be more correct to call windows Prism than VMS - with a very healthy dose of OS/2 thrown in.
Stephen Hoffman
2020-12-22 21:10:00 UTC
Reply
Permalink
Post by ***@gmail.com
Ironically, you'd be more correct to call windows Prism than VMS - with
a very healthy dose of OS/2 thrown in.
MICA. Not PRISM. PRISM was the hardware. MICA was the software.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-12-22 18:18:36 UTC
Reply
Permalink
Post by Bill Gunshannon
Like with COBOL and a number of other legacy languages my objection
is when they totally change the language and still have the nerve to
call it what it was.  Like calling "DELPHI" "Pascal" or calling "ANSI
C" "C".  If you want a new language then give it a new name and stop
pretending it's something it is not.
It must depend on how big the change is.

I don't see K&R -> C89 as being a change that justfies
a name change.

Fortran 77 to 90 could have justified a name change IMHO.

Delphi is Object Pascal. Apple could have chosen a different
name, but they did not. I do not see why Borland should not
call Delphi for Object Pascal given the Apple
decision.

Arne
Arne Vajhøj
2020-12-22 18:10:02 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
I got no idea what that is, but, why not?  I'm assuming that it is some
procedure, and such can be implemented in almost any language.  Doesn't
mean there is not a lot of code behind the capability, just that the
user doesn't have to write that code.  A bit like what everyone seems to
like about things such as Python.
.NET has a class System.Collections.ArrayList with a number of methods.

Basically a dynamic sized array.

Mostly replaced in 2005 by System.Collections.Generic.List.

Arne
Steve Ives
2020-12-22 08:02:01 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Arne
Yes! Since V9 which was released in April 2007, Synergy DBL, in addition to being a procedural language like DIBOL was (programs, subroutines and functions), is also an OO language, with namespaces, classes, objects, methods, properties, enums, inheritance, overloading, constructors and destructors, etc. And YES, even on VMS!

Our OO support pre-dates our support for Microsoft .NET, which was introduced in our 9.5 release in November 2010, but we knew we were going to support .NET, so we kept things as compatible as possible. So ... System.Collections.ArrayList is a collection of objects, just like it is in .NET, even on VMS!

The cool thing is, like with EVERYTHING we do, you don't have to re-write to take advantage. OO can be used from within 40-year-old procedural code, and 40-year-old procedural code can be called from within OO apps. Best of both worlds.

This dedication to, and obsession with forward and backward compatibility is one of the main reasons that we are still in business after almost 45 years of servicing "DIBOL".

Steve Ives
Product Manager
Synergy/DE
https://www.synergex.com
Arne Vajhøj
2020-12-22 18:11:14 UTC
Reply
Permalink
Post by Steve Ives
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
Yes! Since V9 which was released in April 2007, Synergy DBL, in
addition to being a procedural language like DIBOL was (programs,
subroutines and functions), is also an OO language, with namespaces,
classes, objects, methods, properties, enums, inheritance,
overloading, constructors and destructors, etc. And YES, even on
VMS!
Our OO support pre-dates our support for Microsoft .NET, which was
introduced in our 9.5 release in November 2010, but we knew we were
going to support .NET, so we kept things as compatible as possible.
So ... System.Collections.ArrayList is a collection of objects, just
like it is in .NET, even on VMS!
That is pretty cool!

Arne
Bill Gunshannon
2020-12-22 14:58:16 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
If he does, it wasn't ported from RSTS or RSX. :-)

bill
Bill Gunshannon
2020-12-22 15:05:12 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
And what's this "import" thing? I just looked in my DIBOL-11
manual and couldn't find any reference to it. Could it be this
really isn't DIBOL at all? :-)

bill
1tim....@gmail.com
2020-12-22 17:17:48 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by ***@gmail.com
Post by Arne Vajhøj
Post by ***@gmail.com
here is a more modern Dibol example - not 99 bottles of beer. it was
written just to test a String parser class, written in Dibol.
import parser
import System.Collections
record
proc
parse = new StringParser() ;; create instance of parser
Again the code is for .NET platform (System.Collections.ArrayList).
If all modern Dibol code is being written for .NET (.NET is a great
platform so I can understand that) then that may explain why
Dibol on VMS x86-64 is still TBD.
wrong, that is OpenVMS Code. And Linux Code. That is Modern DBL
You got System.Collections.ArrayList on VMS??
And what's this "import" thing? I just looked in my DIBOL-11
manual and couldn't find any reference to it. Could it be this
really isn't DIBOL at all? :-)
bill
you can compile legacy Dibol, modern DBL, mix the two, call OpenVMS routines, mix languages - whatever. It's still DBL (Dibol). You can Mix OO code with 80's era Dibol - ask me how I know :-)
Loading...