f



Home use of COBOL

I imagine a number of people here are using Micro Focus and Fujitsu 
versions of COBOL on a machine at home?

One problem with this is that it is expensive and you need a copy for 
each machine on your LAN.

A number of PRIMA products which generate COBOL, need access to a 
compiler and we have addressed this by using a single machine with COBOL 
on it as a "COBOL server" and letting other machines access this server 
remotely across the client LAN.

(As an aside, you can understand why we would love to provide GNU COBOL 
as the COBOL server instance, but it has to support the Component Object 
Model (COM) and currently GNU COBOL doesn't do this. One of the main 
reasons we use and recommend Fujitsu NetCOBOL over other available 
options, is because they have outstanding support for COM component 
development and provide a *COM Class that removes most of the 
housekeeping and "fiddly stuff" that is required. It is also possible to 
batch compile COM components with Fujitsu and it is not, with some of 
the others. I have an inventory of over 200 COM components which are 
gradually being converted to C# but there are still many in COBOL and I 
NEED to batch compile them...)

Most people using our products already have a registered copy of COBOL 
on at least one of their machines, so using the "COBOL server" concept 
is more a matter of convenience than saving on license costs. Our 
products are designed to run COBOL "locally" (on the machine where our 
software is running) or "remotely" (by accessing the "COBOL server" 
across the LAN)

For my own use I have pushed this concept further by making the "COBOL 
server" a Virtual Machine. I currently use ORACLE Virtual BOX for this, 
and find it excellent; simple to use, and free.)

For my home LAN this means I can run machines with different OSes and 
use NetCOBOL with all of them, whether the Fujitsu product is available 
for that OS or not.

Obviously, I spent a great deal of time and effort to design and build 
the necessary mechanisms to make this happen, but it all runs 
faultlessly and we have had no complaints from clients regarding access 
to remote COBOL. (To be fair, most of them run COBOL locally anyway 
because they already have a bunch of COBOL licensed machines.)

I was reviewing some of these mechanisms today and the thought occurred 
to me that there could be people who are not using PRIMA software, but 
who might still like to have remote access to a COBOL compiler.

It would take me a few days to break out the currently integrated 
solution so it could be used free-standing (without running only from 
PRIMA software) but I would be prepared to do this if there is interest.

For home or solo-developer use I'll make it free; for commercial use 
there would be a (small) charge.

Register your interest by posting your thoughts here or by private mail 
to me.

Cheers,

Pete.
-- 
I used to write COBOL; now I can do anything...
0
pete
12/10/2016 11:14:28 PM
comp.lang.cobol 4278 articles. 1 followers. Post Follow

4 Replies
515 Views

Similar Articles

[PageSpeed] 34

On Sun, 11 Dec 2016 12:14:28 +1300, pete dashwood
<dashwood@enternet.co.nz> wrote:

>I imagine a number of people here are using Micro Focus and Fujitsu 
>versions of COBOL on a machine at home?
>
>One problem with this is that it is expensive and you need a copy for 
>each machine on your LAN.
>
>A number of PRIMA products which generate COBOL, need access to a 
>compiler and we have addressed this by using a single machine with COBOL 
>on it as a "COBOL server" and letting other machines access this server 
>remotely across the client LAN.
>
>(As an aside, you can understand why we would love to provide GNU COBOL 
>as the COBOL server instance, but it has to support the Component Object 
>Model (COM) and currently GNU COBOL doesn't do this. One of the main 
>reasons we use and recommend Fujitsu NetCOBOL over other available 
>options, is because they have outstanding support for COM component 
>development and provide a *COM Class that removes most of the 
>housekeeping and "fiddly stuff" that is required. It is also possible to 
>batch compile COM components with Fujitsu and it is not, with some of 
>the others. I have an inventory of over 200 COM components which are 
>gradually being converted to C# but there are still many in COBOL and I 
>NEED to batch compile them...)
>
>Most people using our products already have a registered copy of COBOL 
>on at least one of their machines, so using the "COBOL server" concept 
>is more a matter of convenience than saving on license costs. Our 
>products are designed to run COBOL "locally" (on the machine where our 
>software is running) or "remotely" (by accessing the "COBOL server" 
>across the LAN)
>
>For my own use I have pushed this concept further by making the "COBOL 
>server" a Virtual Machine. I currently use ORACLE Virtual BOX for this, 
>and find it excellent; simple to use, and free.)
>
>For my home LAN this means I can run machines with different OSes and 
>use NetCOBOL with all of them, whether the Fujitsu product is available 
>for that OS or not.
>
>Obviously, I spent a great deal of time and effort to design and build 
>the necessary mechanisms to make this happen, but it all runs 
>faultlessly and we have had no complaints from clients regarding access 
>to remote COBOL. (To be fair, most of them run COBOL locally anyway 
>because they already have a bunch of COBOL licensed machines.)
>
>I was reviewing some of these mechanisms today and the thought occurred 
>to me that there could be people who are not using PRIMA software, but 
>who might still like to have remote access to a COBOL compiler.
>
>It would take me a few days to break out the currently integrated 
>solution so it could be used free-standing (without running only from 
>PRIMA software) but I would be prepared to do this if there is interest.
>
>For home or solo-developer use I'll make it free; for commercial use 
>there would be a (small) charge.
>
>Register your interest by posting your thoughts here or by private mail 
>to me.


You should carefully review the licensing terms for the compilers in
question.  They almost certainly will object to the creation of such a
publically available compilation server.  In fact, the license likely
forbids the internal usage you describe, unless you have (at least) a
license (perhaps not installed) for each user (or perhaps machine) on
the internal network that may access the compilation server.
0
Robert
12/11/2016 9:07:02 AM
On 11/12/2016 10:07 p.m., Robert Wessel wrote:
> On Sun, 11 Dec 2016 12:14:28 +1300, pete dashwood
> <dashwood@enternet.co.nz> wrote:
>
>> I imagine a number of people here are using Micro Focus and Fujitsu
>> versions of COBOL on a machine at home?
>>
>> One problem with this is that it is expensive and you need a copy for
>> each machine on your LAN.
>>
>> A number of PRIMA products which generate COBOL, need access to a
>> compiler and we have addressed this by using a single machine with COBOL
>> on it as a "COBOL server" and letting other machines access this server
>> remotely across the client LAN.
>>
>> (As an aside, you can understand why we would love to provide GNU COBOL
>> as the COBOL server instance, but it has to support the Component Object
>> Model (COM) and currently GNU COBOL doesn't do this. One of the main
>> reasons we use and recommend Fujitsu NetCOBOL over other available
>> options, is because they have outstanding support for COM component
>> development and provide a *COM Class that removes most of the
>> housekeeping and "fiddly stuff" that is required. It is also possible to
>> batch compile COM components with Fujitsu and it is not, with some of
>> the others. I have an inventory of over 200 COM components which are
>> gradually being converted to C# but there are still many in COBOL and I
>> NEED to batch compile them...)
>>
>> Most people using our products already have a registered copy of COBOL
>> on at least one of their machines, so using the "COBOL server" concept
>> is more a matter of convenience than saving on license costs. Our
>> products are designed to run COBOL "locally" (on the machine where our
>> software is running) or "remotely" (by accessing the "COBOL server"
>> across the LAN)
>>
>> For my own use I have pushed this concept further by making the "COBOL
>> server" a Virtual Machine. I currently use ORACLE Virtual BOX for this,
>> and find it excellent; simple to use, and free.)
>>
>> For my home LAN this means I can run machines with different OSes and
>> use NetCOBOL with all of them, whether the Fujitsu product is available
>> for that OS or not.
>>
>> Obviously, I spent a great deal of time and effort to design and build
>> the necessary mechanisms to make this happen, but it all runs
>> faultlessly and we have had no complaints from clients regarding access
>> to remote COBOL. (To be fair, most of them run COBOL locally anyway
>> because they already have a bunch of COBOL licensed machines.)
>>
>> I was reviewing some of these mechanisms today and the thought occurred
>> to me that there could be people who are not using PRIMA software, but
>> who might still like to have remote access to a COBOL compiler.
>>
>> It would take me a few days to break out the currently integrated
>> solution so it could be used free-standing (without running only from
>> PRIMA software) but I would be prepared to do this if there is interest.
>>
>> For home or solo-developer use I'll make it free; for commercial use
>> there would be a (small) charge.
>>
>> Register your interest by posting your thoughts here or by private mail
>> to me.
>
>
> You should carefully review the licensing terms for the compilers in
> question.  They almost certainly will object to the creation of such a
> publically available compilation server.

Yes, that would certainly violate the intention at least of the license. 
However, what I am doing is NOT PUBLICLY AVAILABLE, it is only available 
privately to a user who has already licensed at least one copy of the 
compiler.

If GNU COBOL ever gets COM support it would then be feasible to base the 
compiler in the cloud and make it then publicly available... (We have no 
current plans to do that).


   In fact, the license likely
> forbids the internal usage you describe, unless you have (at least) a
> license (perhaps not installed) for each user (or perhaps machine) on
> the internal network that may access the compilation server.
>
Yes, I thought I covered that; our clients generally have multiple 
licensed machines and generally run COBOL locally. But home users may 
have a single Licence. (I certainly did...) I did check the Licence 
terms some years back when I first wanted to do this (It was Fujitsu 
NetCOBOL 7). There was no Fujitsu provided facility for multiple access 
at the time, so the Licence did not cover it. The compiler ran (and was 
licensed as) a single desktop installation for a single licensed 
machine. (Licenses today are often sold for groups of say, 4 machines, 
I'm not sure it is still possible to get a "single seat" Licence... 
Possibly buying the software second-hand it might be possible; I don't 
know. Certainly, I had a single machine Licence for a single desktop 
application.

However, there would be nothing to stop a number of users sitting down 
at that machine (in turn) and using it. It is exactly the same 
principle; one machine is licensed and ONE (licensed) machine is being 
used. The USERs are not licensed because users come and go...

Anyway, I didn't make the post as a way for people to avoid licensing;
(although home users probably don't want to license 4 machines). The 
main advantage is that you can run COBOL from machines that don't 
support it (like Win 98...) and somebody who is running multiple 
different OSes (say, Mac and Windows or Linux) and has a COBOL compiler 
that only runs under a specific version of Windows, can then use it to 
compile COBOL from the other machines.

If there are no positive responses, I'll withdraw the offer and save 
myself some time... :-)

Pete.
-- 
I used to write COBOL; now I can do anything...
0
pete
12/12/2016 6:25:14 AM
On Mon, 12 Dec 2016 19:25:14 +1300, pete dashwood
<dashwood@enternet.co.nz> wrote:

>On 11/12/2016 10:07 p.m., Robert Wessel wrote:
>> On Sun, 11 Dec 2016 12:14:28 +1300, pete dashwood
>> <dashwood@enternet.co.nz> wrote:
>>
>>> I imagine a number of people here are using Micro Focus and Fujitsu
>>> versions of COBOL on a machine at home?
>>>
>>> One problem with this is that it is expensive and you need a copy for
>>> each machine on your LAN.
>>>
>>> A number of PRIMA products which generate COBOL, need access to a
>>> compiler and we have addressed this by using a single machine with COBOL
>>> on it as a "COBOL server" and letting other machines access this server
>>> remotely across the client LAN.
>>>
>>> (As an aside, you can understand why we would love to provide GNU COBOL
>>> as the COBOL server instance, but it has to support the Component Object
>>> Model (COM) and currently GNU COBOL doesn't do this. One of the main
>>> reasons we use and recommend Fujitsu NetCOBOL over other available
>>> options, is because they have outstanding support for COM component
>>> development and provide a *COM Class that removes most of the
>>> housekeeping and "fiddly stuff" that is required. It is also possible to
>>> batch compile COM components with Fujitsu and it is not, with some of
>>> the others. I have an inventory of over 200 COM components which are
>>> gradually being converted to C# but there are still many in COBOL and I
>>> NEED to batch compile them...)
>>>
>>> Most people using our products already have a registered copy of COBOL
>>> on at least one of their machines, so using the "COBOL server" concept
>>> is more a matter of convenience than saving on license costs. Our
>>> products are designed to run COBOL "locally" (on the machine where our
>>> software is running) or "remotely" (by accessing the "COBOL server"
>>> across the LAN)
>>>
>>> For my own use I have pushed this concept further by making the "COBOL
>>> server" a Virtual Machine. I currently use ORACLE Virtual BOX for this,
>>> and find it excellent; simple to use, and free.)
>>>
>>> For my home LAN this means I can run machines with different OSes and
>>> use NetCOBOL with all of them, whether the Fujitsu product is available
>>> for that OS or not.
>>>
>>> Obviously, I spent a great deal of time and effort to design and build
>>> the necessary mechanisms to make this happen, but it all runs
>>> faultlessly and we have had no complaints from clients regarding access
>>> to remote COBOL. (To be fair, most of them run COBOL locally anyway
>>> because they already have a bunch of COBOL licensed machines.)
>>>
>>> I was reviewing some of these mechanisms today and the thought occurred
>>> to me that there could be people who are not using PRIMA software, but
>>> who might still like to have remote access to a COBOL compiler.
>>>
>>> It would take me a few days to break out the currently integrated
>>> solution so it could be used free-standing (without running only from
>>> PRIMA software) but I would be prepared to do this if there is interest.
>>>
>>> For home or solo-developer use I'll make it free; for commercial use
>>> there would be a (small) charge.
>>>
>>> Register your interest by posting your thoughts here or by private mail
>>> to me.
>>
>>
>> You should carefully review the licensing terms for the compilers in
>> question.  They almost certainly will object to the creation of such a
>> publically available compilation server.
>
>Yes, that would certainly violate the intention at least of the license. 
>However, what I am doing is NOT PUBLICLY AVAILABLE, it is only available 
>privately to a user who has already licensed at least one copy of the 
>compiler.
>
>If GNU COBOL ever gets COM support it would then be feasible to base the 
>compiler in the cloud and make it then publicly available... (We have no 
>current plans to do that).
>
>
>   In fact, the license likely
>> forbids the internal usage you describe, unless you have (at least) a
>> license (perhaps not installed) for each user (or perhaps machine) on
>> the internal network that may access the compilation server.
>>
>Yes, I thought I covered that; our clients generally have multiple 
>licensed machines and generally run COBOL locally. But home users may 
>have a single Licence. (I certainly did...) I did check the Licence 
>terms some years back when I first wanted to do this (It was Fujitsu 
>NetCOBOL 7). There was no Fujitsu provided facility for multiple access 
>at the time, so the Licence did not cover it. The compiler ran (and was 
>licensed as) a single desktop installation for a single licensed 
>machine. (Licenses today are often sold for groups of say, 4 machines, 
>I'm not sure it is still possible to get a "single seat" Licence... 
>Possibly buying the software second-hand it might be possible; I don't 
>know. Certainly, I had a single machine Licence for a single desktop 
>application.
>
>However, there would be nothing to stop a number of users sitting down 
>at that machine (in turn) and using it. It is exactly the same 
>principle; one machine is licensed and ONE (licensed) machine is being 
>used. The USERs are not licensed because users come and go...


While discussing licensing terms is not one of my favorite pastimes, I
took a quick look at the Microfocus EULA - it would appear to license
usage to particular users (and so a compile server is legit, so long
as each specific user has a license, they even mention that
explicitly).  But the series of users sitting down at one machine
would appear to be disallowed.

I know we've had this discussion before: but whatever other issues
Cobol may have as a language, the licensing issues (both compiler and
runtime) with the small system implementations are enough to make most
developers run screaming in the other direction.


>Anyway, I didn't make the post as a way for people to avoid licensing;
>(although home users probably don't want to license 4 machines). The 
>main advantage is that you can run COBOL from machines that don't 
>support it (like Win 98...) and somebody who is running multiple 
>different OSes (say, Mac and Windows or Linux) and has a COBOL compiler 
>that only runs under a specific version of Windows, can then use it to 
>compile COBOL from the other machines.
>
>If there are no positive responses, I'll withdraw the offer and save 
>myself some time... :-)
>
>Pete.
0
Robert
12/12/2016 6:57:59 AM
On 12/12/2016 7:57 p.m., Robert Wessel wrote:
> On Mon, 12 Dec 2016 19:25:14 +1300, pete dashwood
> <dashwood@enternet.co.nz> wrote:
>
>> On 11/12/2016 10:07 p.m., Robert Wessel wrote:
>>> On Sun, 11 Dec 2016 12:14:28 +1300, pete dashwood
>>> <dashwood@enternet.co.nz> wrote:
>>>
>>>> I imagine a number of people here are using Micro Focus and Fujitsu
>>>> versions of COBOL on a machine at home?
>>>>
>>>> One problem with this is that it is expensive and you need a copy for
>>>> each machine on your LAN.
>>>>
>>>> A number of PRIMA products which generate COBOL, need access to a
>>>> compiler and we have addressed this by using a single machine with COBOL
>>>> on it as a "COBOL server" and letting other machines access this server
>>>> remotely across the client LAN.
>>>>
>>>> (As an aside, you can understand why we would love to provide GNU COBOL
>>>> as the COBOL server instance, but it has to support the Component Object
>>>> Model (COM) and currently GNU COBOL doesn't do this. One of the main
>>>> reasons we use and recommend Fujitsu NetCOBOL over other available
>>>> options, is because they have outstanding support for COM component
>>>> development and provide a *COM Class that removes most of the
>>>> housekeeping and "fiddly stuff" that is required. It is also possible to
>>>> batch compile COM components with Fujitsu and it is not, with some of
>>>> the others. I have an inventory of over 200 COM components which are
>>>> gradually being converted to C# but there are still many in COBOL and I
>>>> NEED to batch compile them...)
>>>>
>>>> Most people using our products already have a registered copy of COBOL
>>>> on at least one of their machines, so using the "COBOL server" concept
>>>> is more a matter of convenience than saving on license costs. Our
>>>> products are designed to run COBOL "locally" (on the machine where our
>>>> software is running) or "remotely" (by accessing the "COBOL server"
>>>> across the LAN)
>>>>
>>>> For my own use I have pushed this concept further by making the "COBOL
>>>> server" a Virtual Machine. I currently use ORACLE Virtual BOX for this,
>>>> and find it excellent; simple to use, and free.)
>>>>
>>>> For my home LAN this means I can run machines with different OSes and
>>>> use NetCOBOL with all of them, whether the Fujitsu product is available
>>>> for that OS or not.
>>>>
>>>> Obviously, I spent a great deal of time and effort to design and build
>>>> the necessary mechanisms to make this happen, but it all runs
>>>> faultlessly and we have had no complaints from clients regarding access
>>>> to remote COBOL. (To be fair, most of them run COBOL locally anyway
>>>> because they already have a bunch of COBOL licensed machines.)
>>>>
>>>> I was reviewing some of these mechanisms today and the thought occurred
>>>> to me that there could be people who are not using PRIMA software, but
>>>> who might still like to have remote access to a COBOL compiler.
>>>>
>>>> It would take me a few days to break out the currently integrated
>>>> solution so it could be used free-standing (without running only from
>>>> PRIMA software) but I would be prepared to do this if there is interest.
>>>>
>>>> For home or solo-developer use I'll make it free; for commercial use
>>>> there would be a (small) charge.
>>>>
>>>> Register your interest by posting your thoughts here or by private mail
>>>> to me.
>>>
>>>
>>> You should carefully review the licensing terms for the compilers in
>>> question.  They almost certainly will object to the creation of such a
>>> publically available compilation server.
>>
>> Yes, that would certainly violate the intention at least of the license.
>> However, what I am doing is NOT PUBLICLY AVAILABLE, it is only available
>> privately to a user who has already licensed at least one copy of the
>> compiler.
>>
>> If GNU COBOL ever gets COM support it would then be feasible to base the
>> compiler in the cloud and make it then publicly available... (We have no
>> current plans to do that).
>>
>>
>>   In fact, the license likely
>>> forbids the internal usage you describe, unless you have (at least) a
>>> license (perhaps not installed) for each user (or perhaps machine) on
>>> the internal network that may access the compilation server.
>>>
>> Yes, I thought I covered that; our clients generally have multiple
>> licensed machines and generally run COBOL locally. But home users may
>> have a single Licence. (I certainly did...) I did check the Licence
>> terms some years back when I first wanted to do this (It was Fujitsu
>> NetCOBOL 7). There was no Fujitsu provided facility for multiple access
>> at the time, so the Licence did not cover it. The compiler ran (and was
>> licensed as) a single desktop installation for a single licensed
>> machine. (Licenses today are often sold for groups of say, 4 machines,
>> I'm not sure it is still possible to get a "single seat" Licence...
>> Possibly buying the software second-hand it might be possible; I don't
>> know. Certainly, I had a single machine Licence for a single desktop
>> application.
>>
>> However, there would be nothing to stop a number of users sitting down
>> at that machine (in turn) and using it. It is exactly the same
>> principle; one machine is licensed and ONE (licensed) machine is being
>> used. The USERs are not licensed because users come and go...
>
>
> While discussing licensing terms is not one of my favorite pastimes, I
> took a quick look at the Microfocus EULA - it would appear to license
> usage to particular users (and so a compile server is legit, so long
> as each specific user has a license, they even mention that
> explicitly).  But the series of users sitting down at one machine
> would appear to be disallowed.

Why would it matter whether they used one machine or a number of 
machines if each user has to be licensed? What do they do when new 
people join the team or existing ones leave? It seems unwieldy to me, 
but, if that is what they do then I guess that's what they do...

>
> I know we've had this discussion before: but whatever other issues
> Cobol may have as a language, the licensing issues (both compiler and
> runtime) with the small system implementations are enough to make most
> developers run screaming in the other direction.
>
>
>> Anyway, I didn't make the post as a way for people to avoid licensing;
>> (although home users probably don't want to license 4 machines). The
>> main advantage is that you can run COBOL from machines that don't
>> support it (like Win 98...) and somebody who is running multiple
>> different OSes (say, Mac and Windows or Linux) and has a COBOL compiler
>> that only runs under a specific version of Windows, can then use it to
>> compile COBOL from the other machines.
>>
>> If there are no positive responses, I'll withdraw the offer and save
>> myself some time... :-)
>>
>> Pete.

Thanks for Checking Micro Focus, Robert. I have only used Net Express 
(apart from the very early 16 bit implementations) and I think they have 
a server facility as part of it, so there would be no problem and Micro 
Focus users would not need the PRIMA solution.

I have received private mail on this and I will try and do it during the 
"holidays" if I can.

Pete.
-- 
I used to write COBOL; now I can do anything...
0
pete
12/13/2016 1:30:09 AM
Reply: