VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
https://www.vajhoej.dk/arne/articles/vmstd6.html

Arne

On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
> https://www.vajhoej.dk/arne/articles/vmstd6.html
>
> Arne

A very professional article. On behalf of the OpenVMS community let me say "Thanks"

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net/OpenVMS.html

On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
> https://www.vajhoej.dk/arne/articles/vmstd6.html
>
> Arne

Synergy DIBOL is the naswer

On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>> https://www.vajhoej.dk/arne/articles/vmstd6.html
>>
>> Arne
>
> Synergy DIBOL is the naswer

Why?

While I think DIBOL is a pretty cool language, too, it suffers from
the same stigma as BLISS. Not generally available. COBOL is.

bill

On 2/17/2023 10:53 AM, bill wrote:
> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
>> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
>>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>>> https://www.vajhoej.dk/arne/articles/vmstd6.html
>>
>> Synergy DIBOL is the naswer
>
> Why?
>
> While I think DIBOL is a pretty cool language, too, it suffers from
> the same stigma as BLISS.  Not generally available.  COBOL is.

Bliss is let us call it an "ex-DEC whatever" language.

But I believe Dibol is available on VMS, Windows, Linux, AIX,
HP-UX and everything that supports .NET (Windows, Linux, macOS).
That is not everything with Cobol but it is a bit more than Bliss.

Arne

PS: I don't see what Dibol does for converting files between
VMS Cobol and GNUCobol though.

On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>> https://www.vajhoej.dk/arne/articles/vmstd6.html
>>
>> Arne
>
> Synergy DIBOL is the naswer
>

What is an "naswer" ????????????????

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

On 2/17/2023 11:39 AM, Dave Froble wrote:
> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
>> Synergy DIBOL is the naswer
>
> What is an "naswer" ????????????????

I think everybody is assuming that it was:
finger on right hand hit n + finger on left hand hit a
instead of:
finger on left hand hit a + finger on right hand hit n

Arne

On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/17/2023 10:53 AM, bill wrote:
>> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
>>> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
>>>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>>>> https://www.vajhoej.dk/arne/articles/vmstd6.html
>>>
>>> Synergy DIBOL is the naswer
>>
>> Why?
>>
>> While I think DIBOL is a pretty cool language, too, it suffers from
>> the same stigma as BLISS.  Not generally available.  COBOL is.
>
> Bliss is let us call it an "ex-DEC whatever" language.
>
> But I believe Dibol is available on VMS, Windows, Linux, AIX,
> HP-UX and everything that supports .NET (Windows, Linux, macOS).
> That is not everything with Cobol but it is a bit more than Bliss.
>

The main problem is that it's a language that's controlled by one
company and which you can only buy from them.

> Arne
>
> PS: I don't see what Dibol does for converting files between
> VMS Cobol and GNUCobol though.
>

Nothing as far as I am aware. Bob just likes to claim that DIBOL is
the answer to everything. It's not. In a previous life, I used to
write some applications in it, and while its well suited to certain
applications, it is not a general language in the same way as say
C++, Ada, Pascal, or Java.

It also suffers from not having a free version so you have to pay
for the compiler (and unless the payment model has changed over the
last decade or so), you also have to pay for runtime licences.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/17/2023 1:35 PM, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/17/2023 10:53 AM, bill wrote:
>>> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
>>>> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
>>>>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
>>>>> https://www.vajhoej.dk/arne/articles/vmstd6.html
>>>>
>>>> Synergy DIBOL is the naswer
>>>
>>> Why?
>>>
>>> While I think DIBOL is a pretty cool language, too, it suffers from
>>> the same stigma as BLISS. Not generally available. COBOL is.
>>
>> Bliss is let us call it an "ex-DEC whatever" language.
>>
>> But I believe Dibol is available on VMS, Windows, Linux, AIX,
>> HP-UX and everything that supports .NET (Windows, Linux, macOS).
>> That is not everything with Cobol but it is a bit more than Bliss.
>>
>
> The main problem is that it's a language that's controlled by one
> company and which you can only buy from them.

Sorry, but I do not see this as a problem.

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

On 2/17/2023 11:42 AM, Arne Vajhøj wrote:
> On 2/17/2023 11:39 AM, Dave Froble wrote:
>> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
>>> Synergy DIBOL is the naswer
>>
>> What is an "naswer" ????????????????
>
> I think everybody is assuming that it was:
> finger on right hand hit n + finger on left hand hit a
> instead of:
> finger on left hand hit a + finger on right hand hit n
>
> Arne
>
>
>

There are such things as proof reading and spell checkers.

Yeah, I've also had typos, and it annoys me when I make that mistake.

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

On Fri, 2023-02-17 at 11:42 -0500, Arne Vajhøj wrote:
> > What is an "naswer" ????????????????
>
> I think everybody is assuming that it was:
>    finger on right hand hit n + finger on left hand hit a
> instead of:
>    finger on left hand hit a + finger on right hand hit n

Or, in other words, alien fingers. :-D
--
Tactical Nuclear Kittens

On 2023-02-17, Dave Froble <davef@tsoft-inc.com> wrote:
> On 2/17/2023 1:35 PM, Simon Clubley wrote:
>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 2/17/2023 10:53 AM, bill wrote:
>>>>
>>>> While I think DIBOL is a pretty cool language, too, it suffers from
>>>> the same stigma as BLISS. Not generally available. COBOL is.
>>>
>>> Bliss is let us call it an "ex-DEC whatever" language.
>>>
>>> But I believe Dibol is available on VMS, Windows, Linux, AIX,
>>> HP-UX and everything that supports .NET (Windows, Linux, macOS).
>>> That is not everything with Cobol but it is a bit more than Bliss.
>>>
>>
>> The main problem is that it's a language that's controlled by one
>> company and which you can only buy from them.
>
> Sorry, but I do not see this as a problem.
>

Yeah, I'm sure all those Java users _really_ appreciate what Oracle have
just done to them... :-)

Fortunately, at least with Java, there are options that some will be able
to move to.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/20/2023 8:15 AM, Simon Clubley wrote:
> On 2023-02-17, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 2/17/2023 1:35 PM, Simon Clubley wrote:
>>> On 2023-02-17, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 2/17/2023 10:53 AM, bill wrote:
>>>>>
>>>>> While I think DIBOL is a pretty cool language, too, it suffers from
>>>>> the same stigma as BLISS. Not generally available. COBOL is.
>>>>
>>>> Bliss is let us call it an "ex-DEC whatever" language.
>>>>
>>>> But I believe Dibol is available on VMS, Windows, Linux, AIX,
>>>> HP-UX and everything that supports .NET (Windows, Linux, macOS).
>>>> That is not everything with Cobol but it is a bit more than Bliss.
>>>
>>> The main problem is that it's a language that's controlled by one
>>> company and which you can only buy from them.
>>
>> Sorry, but I do not see this as a problem.
>
> Yeah, I'm sure all those Java users _really_ appreciate what Oracle have
> just done to them... :-)
>
> Fortunately, at least with Java, there are options that some will be able
> to move to.

In that particular case they can move from Oracle Java to
OpenJDK that is build from the same source code as Oracle Java.

The open source idea certainly works here.

But it is worth noting that if OpenJDK had not been created,
then there may still have been alternatives. There were
other Java implementations around - they died when OpenJDK
was created, but if OpenJDK had not been created then the
alternatives may have existed today (Apache Harmony effectively
died when IBM started supporting OpenJDK).

Arne

Yeah, Gnucobol, in my opinion; is more like something to play around as a concept; it’s not a serious mission-critical answer for OpenVMS COBOL migration. The C code it generates is nightmarish.

About 10 years ago, we at Sector7 created a tool that migrates OpenVMS COBOL to an ANSI COBOL compatible format. It does this by removing the various VMS extensions that have been built into the OpenVMS COBOL over the decades and let me tell you, there are a lot of them. One of the more complex ones is the concept of a DESCRIPTOR in arguments to a procedure.

We can transform millions of LOC of OpenVMS COBOL code in a few minutes and the generated sources are ANSI COBOL. We have been using NETCOBOL as one of the compilers on Linux because it only requires an inexpensive development license to compile the code. The executables do not require a license to run on the production servers. Of course, if you have another ANSI COBOL compiler that you want to use, there may be some adjustment needed to the transformation tool, but the code should compile with you preferred COBOL compiler.

We also bundle in a set of extensions for gdb so you can debug and easily view/modify the data contained in the COBOL structures using gdb.

The migration code runs on Linux and the code it generates is pure COBOL, easily maintainable on Linux. The tool knows all about the Sector7 library of system services on Linux so the compiled code can be linked with the library and will run on Linux just like on OpenVMS.

On Mon, 2023-02-20 at 14:56 -0800, Denys Beauchemin wrote:
> The migration code runs on Linux and the code it generates is pure
> COBOL, easily maintainable on Linux.  The tool knows all about the
> Sector7 library of system services on Linux so the compiled code can
> be linked with the library and will run on Linux just like on
> OpenVMS.

Perhaps it should also migrate back onto VMS (x86_64). Who knows, that
might be a shot in the arm for OpenVMS. :-D
--
Tactical Nuclear Kittens

On 2/20/2023 5:56 PM, Denys Beauchemin wrote:
> Yeah, Gnucobol, in my opinion; is more like something to play around
> as a concept; it’s not a serious mission-critical answer for OpenVMS
> COBOL migration. The C code it generates is nightmarish.

If a company is spending X M$ or XX M$ migrating from Cobol/VMS
to Cobol/Linux, then paying for a commercial Cobol is not a problem
(you prefer Fujitsu - other may prefer Micro Focus).

But GnuCOBOL is pretty big in the hobbyist space.

Arne

On Tuesday, February 21, 2023 at 2:02:18 AM UTC-7, Single Stage to Orbit wrote:
> On Mon, 2023-02-20 at 14:56 -0800, Denys Beauchemin wrote:
> > The migration code runs on Linux and the code it generates is pure
> > COBOL, easily maintainable on Linux. The tool knows all about the
> > Sector7 library of system services on Linux so the compiled code can
> > be linked with the library and will run on Linux just like on
> > OpenVMS.
> Perhaps it should also migrate back onto VMS (x86_64). Who knows, that
> might be a shot in the arm for OpenVMS. :-D
> --
> Tactical Nuclear Kittens

Having attempted to move sample code from two flavors of COBOL code (OpenVMS terminal and HP-UX ANSI format) to GnuCOBOL, I had to modify every comment and most continuation lines to get them to compile. Shell script was fairly simple to write to fix these issues, but still changed the code. None of the VMS code used by descriptor calls in the main code, but calls to system services on both side were a pain. Both had database precompiler needs (CODASYL and Informix) and those certainly would not work at all.

Chocked up the two weeks spent to playing with a toy that was not ready for prime time.

On Tuesday, February 21, 2023 at 3:02:18 AM UTC-6, Single Stage to Orbit wrote:
> On Mon, 2023-02-20 at 14:56 -0800, Denys Beauchemin wrote:
> > The migration code runs on Linux and the code it generates is pure
> > COBOL, easily maintainable on Linux. The tool knows all about the
> > Sector7 library of system services on Linux so the compiled code can
> > be linked with the library and will run on Linux just like on
> > OpenVMS.
> Perhaps it should also migrate back onto VMS (x86_64). Who knows, that
> might be a shot in the arm for OpenVMS. :-D
> --
> Tactical Nuclear Kittens
You can most certainly do that.

On Tuesday, February 21, 2023 at 3:12:04 PM UTC-6, Paul Gavin wrote:
> On Tuesday, February 21, 2023 at 2:02:18 AM UTC-7, Single Stage to Orbit wrote:
> > On Mon, 2023-02-20 at 14:56 -0800, Denys Beauchemin wrote:
> > > The migration code runs on Linux and the code it generates is pure
> > > COBOL, easily maintainable on Linux. The tool knows all about the
> > > Sector7 library of system services on Linux so the compiled code can
> > > be linked with the library and will run on Linux just like on
> > > OpenVMS.
> > Perhaps it should also migrate back onto VMS (x86_64). Who knows, that
> > might be a shot in the arm for OpenVMS. :-D
> > --
> > Tactical Nuclear Kittens
> Having attempted to move sample code from two flavors of COBOL code (OpenVMS terminal and HP-UX ANSI format) to GnuCOBOL, I had to modify every comment and most continuation lines to get them to compile. Shell script was fairly simple to write to fix these issues, but still changed the code. None of the VMS code used by descriptor calls in the main code, but calls to system services on both side were a pain. Both had database precompiler needs (CODASYL and Informix) and those certainly would not work at all.
>
> Chocked up the two weeks spent to playing with a toy that was not ready for prime time.

In a current project, the Sector7 COBOL remediation tool does over 400,000 remediations to about 2 million LOC of COBOL. Case changes, dashes to underscores, descriptors, and various other fixes are applied. It takes about 10 minutes to process all the OpenVMS COBOL code. It takes about 6 minutes to compile all the remedied COBOL code on Linux and another 4 minutes to link and create the 1000 executables. On Itanium, the OpenVMS code base takes about 8-10 hours to compile and link.

On Tuesday, February 21, 2023 at 1:16:03 PM UTC-6, Arne Vajhøj wrote:
> On 2/20/2023 5:56 PM, Denys Beauchemin wrote:
> > Yeah, Gnucobol, in my opinion; is more like something to play around
> > as a concept; it’s not a serious mission-critical answer for OpenVMS
> > COBOL migration. The C code it generates is nightmarish.
> If a company is spending X M$ or XX M$ migrating from Cobol/VMS
> to Cobol/Linux, then paying for a commercial Cobol is not a problem
> (you prefer Fujitsu - other may prefer Micro Focus).
>
> But GnuCOBOL is pretty big in the hobbyist space.
>
> Arne

Gnucobol may be big in the hobbyist space, but it's not a viable solution for mission-critical production. As for the choice of commercial compilers, the price difference between something like Fujitsu NETCOBOL and Micro Focus COBOL is a couple of orders of magnitude. You only need a development license for NETCOBOl, (a few thousand dollars) and you can run the executables on other servers license-free. With MF COBOL, you pay for everything, everywhere, and it's not cheap. I happen to think that's a big factor in the migration decision. Sites are drawn to open-source, or low-cost licenses.. Witness Postgres Vs Oracle costs. If someone is going to migrate from a closed system like VMS, they do not want to jump into another environment with huge license costs.

On Friday, February 17, 2023 at 1:35:57 PM UTC-5, Simon Clubley wrote:
> On 2023-02-17, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> > On 2/17/2023 10:53 AM, bill wrote:
> >> On 2/17/2023 10:33 AM, ultr...@gmail.com wrote:
> >>> On Sunday, February 12, 2023 at 2:34:06 PM UTC-5, Arne Vajhøj wrote:
> >>>> VMS Tech Demo 6 - converting files between VMS Cobol and GnuCOBOL:
> >>>> https://www.vajhoej.dk/arne/articles/vmstd6.html
> >>>
> >>> Synergy DIBOL is the naswer
> >>
> >> Why?
> >>
> >> While I think DIBOL is a pretty cool language, too, it suffers from
> >> the same stigma as BLISS. Not generally available. COBOL is.
> >
> > Bliss is let us call it an "ex-DEC whatever" language.
> >
> > But I believe Dibol is available on VMS, Windows, Linux, AIX,
> > HP-UX and everything that supports .NET (Windows, Linux, macOS).
> > That is not everything with Cobol but it is a bit more than Bliss.
> >
> The main problem is that it's a language that's controlled by one
> company and which you can only buy from them.
> > Arne
> >
> > PS: I don't see what Dibol does for converting files between
> > VMS Cobol and GNUCobol though.
> >
> Nothing as far as I am aware. Bob just likes to claim that DIBOL is
> the answer to everything. It's not. In a previous life, I used to
> write some applications in it, and while its well suited to certain
> applications, it is not a general language in the same way as say
> C++, Ada, Pascal, or Java.
>
> It also suffers from not having a free version so you have to pay
> for the compiler (and unless the payment model has changed over the
> last decade or so), you also have to pay for runtime licences.
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

C ???? AT LEAST DIBOL CAN BE DEBUGGED ...

On 2/21/2023 5:47 PM, Denys Beauchemin wrote:
> On Tuesday, February 21, 2023 at 1:16:03 PM UTC-6, Arne Vajhøj wrote:
>> On 2/20/2023 5:56 PM, Denys Beauchemin wrote:
>>> Yeah, Gnucobol, in my opinion; is more like something to play around
>>> as a concept; it’s not a serious mission-critical answer for OpenVMS
>>> COBOL migration. The C code it generates is nightmarish.
>> If a company is spending X M$ or XX M$ migrating from Cobol/VMS
>> to Cobol/Linux, then paying for a commercial Cobol is not a problem
>> (you prefer Fujitsu - other may prefer Micro Focus).
>>
>> But GnuCOBOL is pretty big in the hobbyist space.
>
> Gnucobol may be big in the hobbyist space, but it's not a viable solution for mission-critical production.

I believe you.

But there are other things than mission-critical production.

You guys probably focus on mission-critical production because that is
where someone is willing to pay. And you have tools for data conversion.

The potential readers of my little write-up is a different audience.

Arne

Paul Gavin <paulgavinco@gmail.com> wrote:
>Having attempted to move sample code from two flavors of COBOL code (OpenVM=
>S terminal and HP-UX ANSI format) to GnuCOBOL, I had to modify every commen=
>t and most continuation lines to get them to compile. Shell script was fair=
>ly simple to write to fix these issues, but still changed the code. None of=
> the VMS code used by descriptor calls in the main code, but calls to syste=
>m services on both side were a pain. Both had database precompiler needs (C=
>ODASYL and Informix) and those certainly would not work at all.=20

The comment and continuation issues are addressed with compiler flags.
Not that updating the code that way might not be a good idea anyway.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-02-21, ultr...@gmail.com <ultradwc@gmail.com> wrote:
> On Friday, February 17, 2023 at 1:35:57 PM UTC-5, Simon Clubley wrote:
>> Nothing as far as I am aware. Bob just likes to claim that DIBOL is
>> the answer to everything. It's not. In a previous life, I used to
>> write some applications in it, and while its well suited to certain
>> applications, it is not a general language in the same way as say
>> C++, Ada, Pascal, or Java.
>>
>> It also suffers from not having a free version so you have to pay
>> for the compiler (and unless the payment model has changed over the
>> last decade or so), you also have to pay for runtime licences.
>>
>
> C ???? AT LEAST DIBOL CAN BE DEBUGGED ...

Bob, where did I mention C in the above list ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/22/2023 7:52 AM, Scott Dorsey wrote:
> Paul Gavin <paulgavinco@gmail.com> wrote:
>> Having attempted to move sample code from two flavors of COBOL code (OpenVM=
>> S terminal and HP-UX ANSI format) to GnuCOBOL, I had to modify every commen=
>> t and most continuation lines to get them to compile. Shell script was fair=
>> ly simple to write to fix these issues, but still changed the code. None of=
>> the VMS code used by descriptor calls in the main code, but calls to syste=
>> m services on both side were a pain. Both had database precompiler needs (C=
>> ODASYL and Informix) and those certainly would not work at all.=20
>
> The comment and continuation issues are addressed with compiler flags.
> Not that updating the code that way might not be a good idea anyway.
> --scott

I wold love to hear why people might think that GnuCOBOL isn't
ready for production use. And unreadable C intermediate code
is not a valid reason as it was never intended to be read or
modified by humans any more than the RTL in other compilers
or the assembler they generate.

I have done some playing with moving COBOL from IBM, Univac and
even MicroFocus and most take a minimal amount of hand modification
in order to get them running. Certainly a lot less than re-writting
them in Java. I don't have any examples from VMS and VMS is famous
for having a lot of stuff handled by their compilers that are not a
part of the language, but I still think it would work just fine.

bill