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.
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.
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.
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) aYes, I thought I covered that; our clients generally have multiple
license (perhaps not installed) for each user (or perhaps machine) on
the internal network that may access the compilation server.
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.
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) aYes, I thought I covered that; our clients generally have multiple
license (perhaps not installed) for each user (or perhaps machine) on
the internal network that may access the compilation server.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,004 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 221:45:47 |
| Calls: | 13,080 |
| Calls today: | 1 |
| Files: | 186,574 |
| Messages: | 3,300,365 |