Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
GNU COBOL and PostgreSQL
1,387 views
Skip to first unread message
Bill Gunshannon
Apr 30, 2014, 3:58:38 PM4/30/14
to
Anybody (else) working on using this configuration? After playing with
the example given in the FAQ with limited success I wrote a new example
the actually did a select and processed the data returned. I was pleased
with that but still thoughtt he process to be rather cumber some, so....
I have started working on a COBOL library for accessing PostgreSQL.
It is going to be pretty much a set of COBOL wrappers around the PQlib
routines but will have the advantage that it will be a very clean way
of calling these routines from COBOL without having to worry about data
type differences in the two languages. I have 8 routines so far, the
ones I had used previously so I knew what to expect and had an example
program to exercise them. I will continue to work on the others, but
having no idea what they actually do, even when called from C, it will
be slow moving and hard to test. So, if there are people out there
doing more complex work than I am, I could probably use some testers.
Oh yeah, all my testing is being done with the bookbiz database. I plan
to write some programs to do the stuff done strictly with SQL in the book
it came from. It is a great little testing database, even if it was for
Sybase originally. :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
the example given in the FAQ with limited success I wrote a new example
the actually did a select and processed the data returned. I was pleased
with that but still thoughtt he process to be rather cumber some, so....
I have started working on a COBOL library for accessing PostgreSQL.
It is going to be pretty much a set of COBOL wrappers around the PQlib
routines but will have the advantage that it will be a very clean way
of calling these routines from COBOL without having to worry about data
type differences in the two languages. I have 8 routines so far, the
ones I had used previously so I knew what to expect and had an example
program to exercise them. I will continue to work on the others, but
having no idea what they actually do, even when called from C, it will
be slow moving and hard to test. So, if there are people out there
doing more complex work than I am, I could probably use some testers.
Oh yeah, all my testing is being done with the bookbiz database. I plan
to write some programs to do the stuff done strictly with SQL in the book
it came from. It is a great little testing database, even if it was for
Sybase originally. :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Alan Jump
Apr 30, 2014, 4:44:38 PM4/30/14
to
Just to make sure the bases are covered, did you review the work posted here?
http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1&post_id=4142
I'm not any kind of database guru, but that seems to be a reasonably-complete binding for PGSQL.
- -
73 de N5ILN
Alan
with at_gmail.com;
use givenName.surName;
http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1&post_id=4142
I'm not any kind of database guru, but that seems to be a reasonably-complete binding for PGSQL.
- -
73 de N5ILN
Alan
with at_gmail.com;
use givenName.surName;
Vince Coen
May 1, 2014, 9:47:02 AM5/1/14
to
Hello Bill!
30 Apr 14 20:58, Bill Gunshannon wrote to All:
> Anybody (else) working on using this configuration? After playing
> with the example given in the FAQ with limited success I wrote a new
> example the actually did a select and processed the data returned. I
> was pleased with that but still thoughtt he process to be rather
> cumber some, so....
> I have started working on a COBOL library for accessing PostgreSQL.
> It is going to be pretty much a set of COBOL wrappers around the PQlib
> routines but will have the advantage that it will be a very clean way
> of calling these routines from COBOL without having to worry about
> data type differences in the two languages. I have 8 routines so far,
> the ones I had used previously so I knew what to expect and had an
> example program to exercise them. I will continue to work on the
> others, but having no idea what they actually do, even when called
> from C, it will be slow moving and hard to test. So, if there are
> people out there doing more complex work than I am, I could probably
> use some testers.
> Oh yeah, all my testing is being done with the bookbiz database. I
> plan to write some programs to do the stuff done strictly with SQL in
> the book it came from. It is a great little testing database, even if
> it was for Sybase originally. :-)
I am not familiar with your suggested method but, have you looked at the
conventional way sql is processed (SQL standards) with a Cobol program with
other compilers, e.g., IBM, Micro Focus, Fujitsu etc?
They as others that I have not listed use a pre-compiler that converts
Cobol source containing EXEC SQL type statements into the correct calls
along with the right parameters. See the examples for DB2 and Oracle's
pro*Cobol and pro*C tools before the updated source is passed to the
compiler.
Also Jim Curry produced and supplied for OC v1.1 a non-standard
pre-compiler that used a variation on the EXEC SQL statement group.
You should take a look at that as well as the one also published for
Postgres on this list.
Vince
30 Apr 14 20:58, Bill Gunshannon wrote to All:
> Anybody (else) working on using this configuration? After playing
> with the example given in the FAQ with limited success I wrote a new
> example the actually did a select and processed the data returned. I
> was pleased with that but still thoughtt he process to be rather
> cumber some, so....
> I have started working on a COBOL library for accessing PostgreSQL.
> It is going to be pretty much a set of COBOL wrappers around the PQlib
> routines but will have the advantage that it will be a very clean way
> of calling these routines from COBOL without having to worry about
> data type differences in the two languages. I have 8 routines so far,
> the ones I had used previously so I knew what to expect and had an
> example program to exercise them. I will continue to work on the
> others, but having no idea what they actually do, even when called
> from C, it will be slow moving and hard to test. So, if there are
> people out there doing more complex work than I am, I could probably
> use some testers.
> Oh yeah, all my testing is being done with the bookbiz database. I
> plan to write some programs to do the stuff done strictly with SQL in
> the book it came from. It is a great little testing database, even if
> it was for Sybase originally. :-)
conventional way sql is processed (SQL standards) with a Cobol program with
other compilers, e.g., IBM, Micro Focus, Fujitsu etc?
They as others that I have not listed use a pre-compiler that converts
Cobol source containing EXEC SQL type statements into the correct calls
along with the right parameters. See the examples for DB2 and Oracle's
pro*Cobol and pro*C tools before the updated source is passed to the
compiler.
Also Jim Curry produced and supplied for OC v1.1 a non-standard
pre-compiler that used a variation on the EXEC SQL statement group.
You should take a look at that as well as the one also published for
Postgres on this list.
Vince
Bill Gunshannon
May 1, 2014, 10:05:55 AM5/1/14
to
In article <c6fad881-5068-424f...@googlegroups.com>,
all the Postgres calling stuff in any program you wrote. I am trying to
write a COBOL specific library so that one need not even understand the
underlying C code in order to use it.
Just something I thought might be useful. And it has been fun working
on so far. Won't be the first time I did something that was strictly
for my own warped pleasure.
Alan Jump <alan...@gmail.com> writes:
> Just to make sure the bases are covered, did you review the work posted here?
>
> http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1&post_id=4142
>
> I'm not any kind of database guru, but that seems to be a reasonably-complete binding for PGSQL.
I've seen it but as I understand it you would have to include a copy of
> Just to make sure the bases are covered, did you review the work posted here?
>
> http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1&post_id=4142
>
> I'm not any kind of database guru, but that seems to be a reasonably-complete binding for PGSQL.
all the Postgres calling stuff in any program you wrote. I am trying to
write a COBOL specific library so that one need not even understand the
underlying C code in order to use it.
Just something I thought might be useful. And it has been fun working
on so far. Won't be the first time I did something that was strictly
for my own warped pleasure.
Bill Gunshannon
May 1, 2014, 10:16:06 AM5/1/14
to
In article <13989...@f1.n250.z2.fidonet.ftn>,
Yeah, did a lot of Micro Focus a couple years back. I originally wanted
to look into doing an "EXEC SQL" precompiler specifically for GNU COBOL
and PostgreSQL but I see that taking a lot longer. I thought a COBOL
specific PQSL library might make a nice interim solution. I wrote my
original version of the program using the direct calls from libpq and
while it worked, I did run into some glitches due to the differences in
datatypes and how they are handled in the two languages. I thought a
COBOL specific library could elimiante that and make the API cleaner.
>
> They as others that I have not listed use a pre-compiler that converts
> Cobol source containing EXEC SQL type statements into the correct calls
> along with the right parameters. See the examples for DB2 and Oracle's
> pro*Cobol and pro*C tools before the updated source is passed to the
> compiler.
But, my understanding is that those are both commercial products and
definitely not free. They also don't run in a lot of the environments
that are likely to see desired GNU COBOL use, like any BSD.
>
>
>
> Also Jim Curry produced and supplied for OC v1.1 a non-standard
> pre-compiler that used a variation on the EXEC SQL statement group.
I have given up using OC v1.1 entirely. I am hoping much of the problems
I ran into there will be gone in v2.0. So far, so good. I have looked
for some of the stuff mentioned in the FAQ to handle this and found mostly
dead links.
>
> You should take a look at that as well as the one also published for
> Postgres on this list.
>
I have been looking at this stuff for quite some time. Most of what I find
is old and support stopped long ago. If this isn't the case maybe there
needs to be publicizing done. In any event, I will continue to work on
both my library and my pre-compiler idea. I will likely put up a link on
my University Web Page and people can try what I write or not, as they wish.
I will continue as liong as I am still having fun doing it. But then, I
always liked COBOL. I don;t see that changing anytime soon.
to look into doing an "EXEC SQL" precompiler specifically for GNU COBOL
and PostgreSQL but I see that taking a lot longer. I thought a COBOL
specific PQSL library might make a nice interim solution. I wrote my
original version of the program using the direct calls from libpq and
while it worked, I did run into some glitches due to the differences in
datatypes and how they are handled in the two languages. I thought a
COBOL specific library could elimiante that and make the API cleaner.
>
> They as others that I have not listed use a pre-compiler that converts
> Cobol source containing EXEC SQL type statements into the correct calls
> along with the right parameters. See the examples for DB2 and Oracle's
> pro*Cobol and pro*C tools before the updated source is passed to the
> compiler.
definitely not free. They also don't run in a lot of the environments
that are likely to see desired GNU COBOL use, like any BSD.
>
>
>
> Also Jim Curry produced and supplied for OC v1.1 a non-standard
> pre-compiler that used a variation on the EXEC SQL statement group.
I ran into there will be gone in v2.0. So far, so good. I have looked
for some of the stuff mentioned in the FAQ to handle this and found mostly
dead links.
>
> You should take a look at that as well as the one also published for
> Postgres on this list.
>
is old and support stopped long ago. If this isn't the case maybe there
needs to be publicizing done. In any event, I will continue to work on
both my library and my pre-compiler idea. I will likely put up a link on
my University Web Page and people can try what I write or not, as they wish.
I will continue as liong as I am still having fun doing it. But then, I
always liked COBOL. I don;t see that changing anytime soon.
Vince Coen
May 1, 2014, 1:28:04 PM5/1/14
to
<13989...@f1.n250.z2.fidonet.ftn> <bsf396...@mid.individual.net>
Hello Bill!
Thursday May 01 2014 15:16, Bill Gunshannon wrote to All:
> I have been looking at this stuff for quite some time. Most of what I
> find is old and support stopped long ago. If this isn't the case
> maybe there needs to be publicizing done. In any event, I will
> continue to work on both my library and my pre-compiler idea. I will
> likely put up a link on my University Web Page and people can try what
> I write or not, as they wish. I will continue as liong as I am still
> having fun doing it. But then, I always liked COBOL. I don;t see
> that changing anytime soon.
I will send you the code I have from Jim Curry for MySQL using his pre
compiler and C code for library call control etc. As soon as I find it:)
Note that is for v1.1 of the compiler so will need to be updated for v2.1
no doubt.
Vince
Hello Bill!
Thursday May 01 2014 15:16, Bill Gunshannon wrote to All:
> I have been looking at this stuff for quite some time. Most of what I
> find is old and support stopped long ago. If this isn't the case
> maybe there needs to be publicizing done. In any event, I will
> continue to work on both my library and my pre-compiler idea. I will
> likely put up a link on my University Web Page and people can try what
> I write or not, as they wish. I will continue as liong as I am still
> having fun doing it. But then, I always liked COBOL. I don;t see
> that changing anytime soon.
compiler and C code for library call control etc. As soon as I find it:)
Note that is for v1.1 of the compiler so will need to be updated for v2.1
no doubt.
Vince
Bill Gunshannon
May 1, 2014, 2:12:07 PM5/1/14
to
Actually, I should mention that with all versions I have used I have a
problem with regular file access on FreeBSD. Attempts to open a file
for either inout or output give me:
"libcob: Permanent file error (Status = 30) File : 'authors.csv'"
Not sure what a "permanent error" is but I would gladly trade it for a
temporary one. I don't know if it is relevant, but I should mention
that while this happens on the 64bit systems here at work it does not
happen on the 32 bit FreeBSD box I have running under VirtualBOX at home.
I just tested my library as a dynamically loadable module and it worked
great. Still think there is an advantage to this approach over the full
source code approach in the example you pointed me at.
Vince Coen
May 2, 2014, 5:40:01 PM5/2/14
to
Hello Bill!
Thursday May 01 2014 19:12, Bill Gunshannon wrote to All:
>> I will send you the code I have from Jim Curry for MySQL using his
>> pre compiler and C code for library call control etc. As soon as I
>> find it:)
>>
>>
>> Note that is for v1.1 of the compiler so will need to be updated for
>> v2.1 no doubt.
> There's a 2.1!!! :-) And here I am stuck at 2.0. But happy, mind
> you.
There has been an update to the code (v2.1) that causes the make check to
fail on thew RW tests, so I suggest you leave it for a week or so to get
fixed (as I have tested it just now).
> Actually, I should mention that with all versions I have used I have a
> problem with regular file access on FreeBSD. Attempts to open a file
> for either inout or output give me:
> "libcob: Permanent file error (Status = 30) File : 'authors.csv'"
Are you testing the status key as set in the file select for non zero after
every access/open/close etc?
> Not sure what a "permanent error" is but I would gladly trade it for a
> temporary one. I don't know if it is relevant, but I should mention
> that while this happens on the 64bit systems here at work it does not
> happen on the 32 bit FreeBSD box I have running under VirtualBOX at
> home.
File not found maybe, what is the operation you are executing that causes
the error?
It could also be, you are using the wrong version of DB library if its ISAM
or/and you have not installed one of the required libraries including
headers) that are needed see the README file
> I just tested my library as a dynamically loadable module and it
> worked great. Still think there is an advantage to this approach over
> the full source code approach in the example you pointed me at.
I should point out that depending on what is installed you may have some
headers in the /usr/include directory that is installed by default that
does NOT have the full libary installed.
Been nailed with that one in the past.
Vince
Thursday May 01 2014 19:12, Bill Gunshannon wrote to All:
>> I will send you the code I have from Jim Curry for MySQL using his
>> pre compiler and C code for library call control etc. As soon as I
>> find it:)
>>
>>
>> Note that is for v1.1 of the compiler so will need to be updated for
>> v2.1 no doubt.
> There's a 2.1!!! :-) And here I am stuck at 2.0. But happy, mind
> you.
fail on thew RW tests, so I suggest you leave it for a week or so to get
fixed (as I have tested it just now).
> Actually, I should mention that with all versions I have used I have a
> problem with regular file access on FreeBSD. Attempts to open a file
> for either inout or output give me:
> "libcob: Permanent file error (Status = 30) File : 'authors.csv'"
every access/open/close etc?
> Not sure what a "permanent error" is but I would gladly trade it for a
> temporary one. I don't know if it is relevant, but I should mention
> that while this happens on the 64bit systems here at work it does not
> happen on the 32 bit FreeBSD box I have running under VirtualBOX at
> home.
the error?
It could also be, you are using the wrong version of DB library if its ISAM
or/and you have not installed one of the required libraries including
headers) that are needed see the README file
> I just tested my library as a dynamically loadable module and it
> worked great. Still think there is an advantage to this approach over
> the full source code approach in the example you pointed me at.
headers in the /usr/include directory that is installed by default that
does NOT have the full libary installed.
Been nailed with that one in the past.
Vince
Bill Gunshannon
May 3, 2014, 10:53:55 AM5/3/14
to
In article <13990...@f1.n250.z2.fidonet.ftn>,
>
> > Actually, I should mention that with all versions I have used I have a
> > problem with regular file access on FreeBSD. Attempts to open a file
> > for either inout or output give me:
> > "libcob: Permanent file error (Status = 30) File : 'authors.csv'"
>
> Are you testing the status key as set in the file select for non zero after
> every access/open/close etc?
Well, if I don't, I get the message above and the program terminates, so,
yes, I am. :-)
>
> > Not sure what a "permanent error" is but I would gladly trade it for a
> > temporary one. I don't know if it is relevant, but I should mention
> > that while this happens on the 64bit systems here at work it does not
> > happen on the 32 bit FreeBSD box I have running under VirtualBOX at
> > home.
>
> File not found maybe, what is the operation you are executing that causes
> the error?
Happened on OPEN, and, of course, every command afterwards because the
OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for OUTPUT
with no pre-existing file and OPEN for I-O with both.
>
> It could also be, you are using the wrong version of DB library if its ISAM
> or/and you have not installed one of the required libraries including
> headers) that are needed see the README file
Nope, plain sequential file. Program works fine on my 32bit test system.
configure says everything is just fine as far as versions. Had to hand
install gmp and DB so I now they are the required versions.
>
>
> > I just tested my library as a dynamically loadable module and it
> > worked great. Still think there is an advantage to this approach over
> > the full source code approach in the example you pointed me at.
>
> I should point out that depending on what is installed you may have some
> headers in the /usr/include directory that is installed by default that
> does NOT have the full libary installed.
> Been nailed with that one in the past.
Which library are you talking about?
Next big step is to figure out how to get GNU COBOL to work on Windows.
I grabbed an installer but all it seemed to do was copy a bunch of files
into a directory in C:\. Any detailed explanations available? Planning
on doing my testing on Server2012. Already have PostgreSQL running there
nicely. I think there is more potential for longterm interest in running
on Windows rather than BSD or even Linux.
"Vince Coen" <VBC...@gmail.com> writes:
> Hello Bill!
>
> Thursday May 01 2014 19:12, Bill Gunshannon wrote to All:
>
> >> I will send you the code I have from Jim Curry for MySQL using his
> >> pre compiler and C code for library call control etc. As soon as I
> >> find it:)
> >>
> >>
> >> Note that is for v1.1 of the compiler so will need to be updated for
> >> v2.1 no doubt.
>
> > There's a 2.1!!! :-) And here I am stuck at 2.0. But happy, mind
> > you.
>
> There has been an update to the code (v2.1) that causes the make check to
> fail on thew RW tests, so I suggest you leave it for a week or so to get
> fixed (as I have tested it just now).
Oh, I wasn't ready to jump to 2.1. I am happy right now with 2.0.
> Hello Bill!
>
> Thursday May 01 2014 19:12, Bill Gunshannon wrote to All:
>
> >> I will send you the code I have from Jim Curry for MySQL using his
> >> pre compiler and C code for library call control etc. As soon as I
> >> find it:)
> >>
> >>
> >> Note that is for v1.1 of the compiler so will need to be updated for
> >> v2.1 no doubt.
>
> > There's a 2.1!!! :-) And here I am stuck at 2.0. But happy, mind
> > you.
>
> There has been an update to the code (v2.1) that causes the make check to
> fail on thew RW tests, so I suggest you leave it for a week or so to get
> fixed (as I have tested it just now).
>
> > Actually, I should mention that with all versions I have used I have a
> > problem with regular file access on FreeBSD. Attempts to open a file
> > for either inout or output give me:
> > "libcob: Permanent file error (Status = 30) File : 'authors.csv'"
>
> Are you testing the status key as set in the file select for non zero after
> every access/open/close etc?
yes, I am. :-)
>
> > Not sure what a "permanent error" is but I would gladly trade it for a
> > temporary one. I don't know if it is relevant, but I should mention
> > that while this happens on the 64bit systems here at work it does not
> > happen on the 32 bit FreeBSD box I have running under VirtualBOX at
> > home.
>
> File not found maybe, what is the operation you are executing that causes
> the error?
OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for OUTPUT
with no pre-existing file and OPEN for I-O with both.
>
> It could also be, you are using the wrong version of DB library if its ISAM
> or/and you have not installed one of the required libraries including
> headers) that are needed see the README file
configure says everything is just fine as far as versions. Had to hand
install gmp and DB so I now they are the required versions.
>
>
> > I just tested my library as a dynamically loadable module and it
> > worked great. Still think there is an advantage to this approach over
> > the full source code approach in the example you pointed me at.
>
> I should point out that depending on what is installed you may have some
> headers in the /usr/include directory that is installed by default that
> does NOT have the full libary installed.
> Been nailed with that one in the past.
Next big step is to figure out how to get GNU COBOL to work on Windows.
I grabbed an installer but all it seemed to do was copy a bunch of files
into a directory in C:\. Any detailed explanations available? Planning
on doing my testing on Server2012. Already have PostgreSQL running there
nicely. I think there is more potential for longterm interest in running
on Windows rather than BSD or even Linux.
Vince Coen
May 3, 2014, 12:42:43 PM5/3/14
to
Hello Bill!
Saturday May 03 2014 15:53, Bill Gunshannon wrote to All:
>> Are you testing the status key as set in the file select for non
>> zero after every access/open/close etc?
non zero code that is not expected close all other files and terminate the
process.
> Nope, plain sequential file. Program works fine on my 32bit test
> system. configure says everything is just fine as far as versions.
> Had to hand install gmp and DB so I now they are the required
> versions.
Also I set up the enviroment variables for Cobol and my apps.
See content of my .bashrc file (I have removed vars that are for my app)
-------------------------------------
# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
export COB_SET_TRACE=Y
# Next two are my Cobol copy libraries
#
export COBCPY=~/cobolsrc/ACAS/copybooks
export COB_COPY_DIR=~/cobolsrc/ACAS/copybooks
export COB_SCREEN_ESC=YES
export COB_SCREEN_EXCEPTIONS=YES
export COB_LIBRARY_PATH=~/bin
export
PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/games:/usr/lib64/
qt4/bin:/home/vince/bin
export TMPDIR=~/tmp
#export
COB_PRE_LOAD=irs010:irs020:irs030:irs040:irs050:irs055:irs060:irs065:irs070
:irs080:irs085:irs090:irsub1:irsub2:irsub3:irsub4:irsub5:irsubp
# above not needed but here as a reminder in case it needs to be installed
#
-------------------------------------
Should also point out that you MUST run ldconfig as root having set up the
cob lib paths in a file such as :
[vince@study ~]$ cat /etc/ld.so.conf.d/gnu-cobol.conf
---------------------------
/usr/local/lib/gnu-cobol
/usr/local/lib
---------------------------
> Next big step is to figure out how to get GNU COBOL to work on
> Windows. I grabbed an installer but all it seemed to do was copy a
> bunch of files into a directory in C:\. Any detailed explanations
> available? Planning on doing my testing on Server2012. Already have
> PostgreSQL running there nicely. I think there is more potential for
> longterm interest in running on Windows rather than BSD or even Linux.
Tried the standard way using a mini linux environment within Win but if I
have to do so again is to try and use MS Visual C to build the compiler,
however that said if I want to compile a Cobol system under Windows I will
more likely than not use MF Visual Cobol v2.2 Personal Edition.
However I only compile my OS release code to test it but not supply as
binary.
I suggest you create an account on sourceforge and login and then go to
http://sourceforge.net/p/open-cobol/discussion/?source=navbar and leave
details of any more issues there. There is a lot of GNU Cobol compiler
users that hang out who can help you more regarding using Windows.
Vince
Saturday May 03 2014 15:53, Bill Gunshannon wrote to All:
>> Are you testing the status key as set in the file select for non
>> zero after every access/open/close etc?
> Well, if I don't, I get the message above and the program terminates,
> so, yes, I am. :-)
> so, yes, I am. :-)
>> > Not sure what a "permanent error" is but I would gladly trade it
>> for a temporary one. I don't know if it is relevant, but I should
>> mention that while this happens on the 64bit systems here at work it
>> does not happen on the 32 bit FreeBSD box I have running under
>> VirtualBOX at home.
>>
>> File not found maybe, what is the operation you are executing that
>> causes the error?
>> for a temporary one. I don't know if it is relevant, but I should
>> mention that while this happens on the 64bit systems here at work it
>> does not happen on the 32 bit FreeBSD box I have running under
>> VirtualBOX at home.
>>
>> File not found maybe, what is the operation you are executing that
>> causes the error?
> Happened on OPEN, and, of course, every command afterwards because the
> OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for
> OUTPUT with no pre-existing file and OPEN for I-O with both.
You should test for the open and for that matter all accesses and you get a
> OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for
> OUTPUT with no pre-existing file and OPEN for I-O with both.
non zero code that is not expected close all other files and terminate the
process.
> Nope, plain sequential file. Program works fine on my 32bit test
> system. configure says everything is just fine as far as versions.
> Had to hand install gmp and DB so I now they are the required
> versions.
> Which library are you talking about?
Long forgotten but I now always install all that will or might be needed.
Also I set up the enviroment variables for Cobol and my apps.
See content of my .bashrc file (I have removed vars that are for my app)
-------------------------------------
# .bashrc
# User specific aliases and functions
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
export COB_SET_TRACE=Y
# Next two are my Cobol copy libraries
#
export COBCPY=~/cobolsrc/ACAS/copybooks
export COB_COPY_DIR=~/cobolsrc/ACAS/copybooks
export COB_SCREEN_ESC=YES
export COB_SCREEN_EXCEPTIONS=YES
export COB_LIBRARY_PATH=~/bin
export
PATH=~/bin:.:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/games:/usr/lib64/
qt4/bin:/home/vince/bin
export TMPDIR=~/tmp
#export
COB_PRE_LOAD=irs010:irs020:irs030:irs040:irs050:irs055:irs060:irs065:irs070
:irs080:irs085:irs090:irsub1:irsub2:irsub3:irsub4:irsub5:irsubp
# above not needed but here as a reminder in case it needs to be installed
#
-------------------------------------
Should also point out that you MUST run ldconfig as root having set up the
cob lib paths in a file such as :
[vince@study ~]$ cat /etc/ld.so.conf.d/gnu-cobol.conf
---------------------------
/usr/local/lib/gnu-cobol
/usr/local/lib
---------------------------
> Next big step is to figure out how to get GNU COBOL to work on
> Windows. I grabbed an installer but all it seemed to do was copy a
> bunch of files into a directory in C:\. Any detailed explanations
> available? Planning on doing my testing on Server2012. Already have
> PostgreSQL running there nicely. I think there is more potential for
> longterm interest in running on Windows rather than BSD or even Linux.
have to do so again is to try and use MS Visual C to build the compiler,
however that said if I want to compile a Cobol system under Windows I will
more likely than not use MF Visual Cobol v2.2 Personal Edition.
However I only compile my OS release code to test it but not supply as
binary.
I suggest you create an account on sourceforge and login and then go to
http://sourceforge.net/p/open-cobol/discussion/?source=navbar and leave
details of any more issues there. There is a lot of GNU Cobol compiler
users that hang out who can help you more regarding using Windows.
Vince
Bill Gunshannon
May 5, 2014, 9:14:27 AM5/5/14
to
In article <13991...@f1.n250.z2.fidonet.ftn>,
Result is 30 on OPEN, and then, naturally, on the subsequent WRITEs. The
interesting point is that even though the file was never successfully
OPENed CLOSEing it is sucessful. :-)
>
> > Nope, plain sequential file. Program works fine on my 32bit test
> > system. configure says everything is just fine as far as versions.
> > Had to hand install gmp and DB so I now they are the required
> > versions.
>
>
> > Which library are you talking about?
>
> Long forgotten but I now always install all that will or might be needed.
Isn't that the purpose of "configure"? How is the user supposed to know
what "will or might be needed" when they are installing a new package
unless the package tells them.
Well, considering that you have to be logged in as root to install anything,
should one not expect make to take care of that? In any event, after a
little massaging of includes and libraries to even get it to build (seems
even with configure it can't find GMP or DB on a FreeBSD system) cobc runs
just fine. But the generated code appears to have problems. And, just as
another datapoint, I copied all my work from here to my 32bit system at
home and everything works correctly. Seems the problems are with 64bit
builds on FreeBSD.
>
> [vince@study ~]$ cat /etc/ld.so.conf.d/gnu-cobol.conf
> ---------------------------
> /usr/local/lib/gnu-cobol
> /usr/local/lib
> ---------------------------
>
>
> > Next big step is to figure out how to get GNU COBOL to work on
> > Windows. I grabbed an installer but all it seemed to do was copy a
> > bunch of files into a directory in C:\. Any detailed explanations
> > available? Planning on doing my testing on Server2012. Already have
> > PostgreSQL running there nicely. I think there is more potential for
> > longterm interest in running on Windows rather than BSD or even Linux.
>
> Tried the standard way using a mini linux environment within Win but if I
> have to do so again is to try and use MS Visual C to build the compiler,
> however that said if I want to compile a Cobol system under Windows I will
> more likely than not use MF Visual Cobol v2.2 Personal Edition.
Doesn't the first kind of defeat the purpose of having an OpenSource COBOL
compiler? I expect a commercial license for MS Visual C is more than just
buying a commercial COBOL. And, of course, MF Visual Cobol v2.2 Personal
Edition is pertty much the antithesis of GNU COBOL.
>
> However I only compile my OS release code to test it but not supply as
> binary.
>
> I suggest you create an account on sourceforge and login and then go to
> http://sourceforge.net/p/open-cobol/discussion/?source=navbar and leave
> details of any more issues there. There is a lot of GNU Cobol compiler
> users that hang out who can help you more regarding using Windows.
Nice thought, but I am a COBOL end product developer, not a compiler
developer. And the tiem have to follow discussions is rather limited.
Maybe Pete is right and this package is just not ready for prime time
and may never be.
"Vince Coen" <VBC...@gmail.com> writes:
> Hello Bill!
>
> Saturday May 03 2014 15:53, Bill Gunshannon wrote to All:
>
> >> Are you testing the status key as set in the file select for non
> >> zero after every access/open/close etc?
>
> > Well, if I don't, I get the message above and the program terminates,
> > so, yes, I am. :-)
>
> >> > Not sure what a "permanent error" is but I would gladly trade it
> >> for a temporary one. I don't know if it is relevant, but I should
> >> mention that while this happens on the 64bit systems here at work it
> >> does not happen on the 32 bit FreeBSD box I have running under
> >> VirtualBOX at home.
> >>
> >> File not found maybe, what is the operation you are executing that
> >> causes the error?
>
>
>
> > Happened on OPEN, and, of course, every command afterwards because the
> > OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for
> > OUTPUT with no pre-existing file and OPEN for I-O with both.
>
> You should test for the open and for that matter all accesses and you get a
> non zero code that is not expected close all other files and terminate the
> process.
Testing doesn't change the result. Only keeps the program from crashing.
> Hello Bill!
>
> Saturday May 03 2014 15:53, Bill Gunshannon wrote to All:
>
> >> Are you testing the status key as set in the file select for non
> >> zero after every access/open/close etc?
>
> > Well, if I don't, I get the message above and the program terminates,
> > so, yes, I am. :-)
>
> >> > Not sure what a "permanent error" is but I would gladly trade it
> >> for a temporary one. I don't know if it is relevant, but I should
> >> mention that while this happens on the 64bit systems here at work it
> >> does not happen on the 32 bit FreeBSD box I have running under
> >> VirtualBOX at home.
> >>
> >> File not found maybe, what is the operation you are executing that
> >> causes the error?
>
>
>
> > Happened on OPEN, and, of course, every command afterwards because the
> > OPEN failed. Tried OPEN for INPUT with an existing file, OPEN for
> > OUTPUT with no pre-existing file and OPEN for I-O with both.
>
> You should test for the open and for that matter all accesses and you get a
> non zero code that is not expected close all other files and terminate the
> process.
Result is 30 on OPEN, and then, naturally, on the subsequent WRITEs. The
interesting point is that even though the file was never successfully
OPENed CLOSEing it is sucessful. :-)
>
> > Nope, plain sequential file. Program works fine on my 32bit test
> > system. configure says everything is just fine as far as versions.
> > Had to hand install gmp and DB so I now they are the required
> > versions.
>
>
> > Which library are you talking about?
>
> Long forgotten but I now always install all that will or might be needed.
what "will or might be needed" when they are installing a new package
unless the package tells them.
should one not expect make to take care of that? In any event, after a
little massaging of includes and libraries to even get it to build (seems
even with configure it can't find GMP or DB on a FreeBSD system) cobc runs
just fine. But the generated code appears to have problems. And, just as
another datapoint, I copied all my work from here to my 32bit system at
home and everything works correctly. Seems the problems are with 64bit
builds on FreeBSD.
>
> [vince@study ~]$ cat /etc/ld.so.conf.d/gnu-cobol.conf
> ---------------------------
> /usr/local/lib/gnu-cobol
> /usr/local/lib
> ---------------------------
>
>
> > Next big step is to figure out how to get GNU COBOL to work on
> > Windows. I grabbed an installer but all it seemed to do was copy a
> > bunch of files into a directory in C:\. Any detailed explanations
> > available? Planning on doing my testing on Server2012. Already have
> > PostgreSQL running there nicely. I think there is more potential for
> > longterm interest in running on Windows rather than BSD or even Linux.
>
> Tried the standard way using a mini linux environment within Win but if I
> have to do so again is to try and use MS Visual C to build the compiler,
> however that said if I want to compile a Cobol system under Windows I will
> more likely than not use MF Visual Cobol v2.2 Personal Edition.
compiler? I expect a commercial license for MS Visual C is more than just
buying a commercial COBOL. And, of course, MF Visual Cobol v2.2 Personal
Edition is pertty much the antithesis of GNU COBOL.
>
> However I only compile my OS release code to test it but not supply as
> binary.
>
> I suggest you create an account on sourceforge and login and then go to
> http://sourceforge.net/p/open-cobol/discussion/?source=navbar and leave
> details of any more issues there. There is a lot of GNU Cobol compiler
> users that hang out who can help you more regarding using Windows.
developer. And the tiem have to follow discussions is rather limited.
Maybe Pete is right and this package is just not ready for prime time
and may never be.
Vince Coen
May 5, 2014, 8:26:28 PM5/5/14
to
Hello Bill!
Monday May 05 2014 14:14, Bill Gunshannon wrote to All:
> Doesn't the first kind of defeat the purpose of having an OpenSource
> COBOL compiler? I expect a commercial license for MS Visual C is more
> than just buying a commercial COBOL. And, of course, MF Visual Cobol
> v2.2 Personal Edition is pertty much the antithesis of GNU COBOL.
What you wish to do is one thing, what I wish to do is test a suite of
applications on VC after using OC for my own development.
One area that I might well look at is creating a gui front end for OC
similar to VC but do not hold me to that as there seems to be many possible
solutions non of which I am impressed with.
As for using a commercial products yes VC is but the Personal Edition is
free to use for a programmer, just can't sell on the object code which I
have no wish to do.
>> I suggest you create an account on sourceforge and login and then go
>> to
>> http://sourceforge.net/p/open-cobol/discussion/?source=navbar and
>> leave details of any more issues there. There is a lot of GNU Cobol
>> compiler users that hang out who can help you more regarding using
>> Windows.
> Nice thought, but I am a COBOL end product developer, not a compiler
> developer. And the tiem have to follow discussions is rather limited.
> Maybe Pete is right and this package is just not ready for prime time
> and may never be.
The users in those areas are programmer who use the compiler. There are a
few who help improve the compiler itself but in the main 90% or higher are
Cobol programmers.
Prime time? well there are a lot of large organisations in the US and other
countries using it including some goverment departments eg, in Japan, Korea
, there are others I just don't keep track of them.
Now as for the sudo make install - it is up to the user if s/he needs to
run ldconfig to ensure that the newly built Cobol compiler libaries are
accessable during lib searches. In some cases you only want to explicitly
declare them e.g., if you run more than one version of the compiler or more
than one compiler. So no it does not automatically create the ldconf.conf.d
file and run ldconfig. It assumes the programmer knows what they want to
do.
I must admit I perfer it that way as against the Microfocus, Microsoft
way and you have to try and reverse it!
Vince
Monday May 05 2014 14:14, Bill Gunshannon wrote to All:
> Doesn't the first kind of defeat the purpose of having an OpenSource
> COBOL compiler? I expect a commercial license for MS Visual C is more
> than just buying a commercial COBOL. And, of course, MF Visual Cobol
> v2.2 Personal Edition is pertty much the antithesis of GNU COBOL.
applications on VC after using OC for my own development.
One area that I might well look at is creating a gui front end for OC
similar to VC but do not hold me to that as there seems to be many possible
solutions non of which I am impressed with.
As for using a commercial products yes VC is but the Personal Edition is
free to use for a programmer, just can't sell on the object code which I
have no wish to do.
>> I suggest you create an account on sourceforge and login and then go
>> to
>> http://sourceforge.net/p/open-cobol/discussion/?source=navbar and
>> leave details of any more issues there. There is a lot of GNU Cobol
>> compiler users that hang out who can help you more regarding using
>> Windows.
> Nice thought, but I am a COBOL end product developer, not a compiler
> developer. And the tiem have to follow discussions is rather limited.
> Maybe Pete is right and this package is just not ready for prime time
> and may never be.
few who help improve the compiler itself but in the main 90% or higher are
Cobol programmers.
Prime time? well there are a lot of large organisations in the US and other
countries using it including some goverment departments eg, in Japan, Korea
, there are others I just don't keep track of them.
Now as for the sudo make install - it is up to the user if s/he needs to
run ldconfig to ensure that the newly built Cobol compiler libaries are
accessable during lib searches. In some cases you only want to explicitly
declare them e.g., if you run more than one version of the compiler or more
than one compiler. So no it does not automatically create the ldconf.conf.d
file and run ldconfig. It assumes the programmer knows what they want to
do.
I must admit I perfer it that way as against the Microfocus, Microsoft
way and you have to try and reverse it!
Vince
Pete Dashwood
May 5, 2014, 9:29:48 PM5/5/14
to
Bill Gunshannon wrote:
>
> Isn't that the purpose of "configure"? How is the user supposed to
> know what "will or might be needed" when they are installing a new
> package unless the package tells them.
Why should a user need to know about libraries at all?
>
> Isn't that the purpose of "configure"? How is the user supposed to
> know what "will or might be needed" when they are installing a new
> package unless the package tells them.
There should be a series of check boxes for FUNCTIONALITY.
Tick the boxes, the installer gets and installs support for that facility.
intimidating?
I can install and use both Fujitsu and Micro Focus COBOL without any of this
nonsense.
What all of this says to me is that the installer needs work. Arnold posted
previously that he had built an INNO install for version 1.1. Maybe that
needs to be expanded for subsequent versions.
INNO is a very good package and allows interaction and checkboxes during
install.
>>
>>> Next big step is to figure out how to get GNU COBOL to work on
>>> Windows. I grabbed an installer but all it seemed to do was copy a
>>> bunch of files into a directory in C:\. Any detailed explanations
>>> available? Planning on doing my testing on Server2012. Already
>>> have PostgreSQL running there nicely. I think there is more
>>> potential for longterm interest in running on Windows rather than
>>> BSD or even Linux.
>>
>> Tried the standard way using a mini linux environment within Win but
>> if I have to do so again is to try and use MS Visual C to build the
>> compiler, however that said if I want to compile a Cobol system
>> under Windows I will more likely than not use MF Visual Cobol v2.2
>> Personal Edition.
>
> Doesn't the first kind of defeat the purpose of having an OpenSource
> COBOL compiler? I expect a commercial license for MS Visual C is
> more than just buying a commercial COBOL.
There is no "commercial license" for Visual C or any of the other MS "Visual
Languages" (VB.NET, C++, C#), unless you want a Microsoft Corporate support
agreement. (As there are extensive code samples, examples, and friendly user
forums for all of these products, you can easily do without Corporate
support. I have personally never needed it and I have found that the free
videos and support forums have been more than capapble of solving any
problems I have encountered.)
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
(NOTE that this page specifically states that these languages are FREE for
commercial development and distribution of software.)
You download Visual Studio Express and you can add ANY of the above
languages to it, for FREE.
One of the factors that drove me away from COBOL was that I wanted .NET and
the early .NET COBOLs were very expensive. (Some would argue that they are
still way too expensive, and if you factor in Run Time Licensing for Micro
Focus, it becomes non-viable for many small software houses and independent
developers.)
I wanted .NET but the COBOL route to it was costly. The realization soon
dawned that I could get there FOR FREE if I simply changed the development
language.
While you're all so busy bashing Microsoft and extolling how wonderful it is
to have free open software, you simply miss the fact that MS supports its
developers, and their .NET languages are also free.
(I am in favour of Open software because people should have a choice, but I
already experienced having my fingers burned when trying to use it in a
commercial environment, and finding no-one would be responsible for it.
(PostgreSQL ODBC driver). I am not saying I'd ever use open software
commercially again, but I'd need to know it was beyond "hobby software" and
there was a mechanism in place to provide support for it. It also needs to
provide the FUNCTIONALITY I require and I have been consistent on that for
some years now with regard to Open COBOL. If all these ducks were in a row.
I'd be happy to use it, help support it, and promote it to others. (Largely
because we have clients using COBOL; not because I need any variant of COBOL
for myself or PRIMA). Right now, all I can do is wish the project well.)
> And, of course, MF Visual
> Cobol v2.2 Personal Edition is pertty much the antithesis of GNU
> COBOL.
>
be the antithesis of each other? You could argue that neither of them is of
any real value in the modern commercial networked world, where the object
paradigm is king. (Although Micro Focus COBOL implements COM it does so
abysmally and Fujitsu creams it in this regard. Open COBOL does not yet
support objects, never mind COM...)
>>
>> However I only compile my OS release code to test it but not supply
>> as binary.
>>
>> I suggest you create an account on sourceforge and login and then go
>> to http://sourceforge.net/p/open-cobol/discussion/?source=navbar and
>> leave details of any more issues there. There is a lot of GNU Cobol
>> compiler users that hang out who can help you more regarding using
>> Windows.
>
> Nice thought, but I am a COBOL end product developer, not a compiler
> developer. And the tiem have to follow discussions is rather limited.
> Maybe Pete is right and this package is just not ready for prime time
> and may never be.
the passion and time and effort that is going into it, it would be good to
see it become a viable commercial product. (I understand some companies have
picked it up and that is encouraging) but, right now, for me, at least, it
is not a commercial product.
Pete.
--
"I used to write COBOL...now I can do anything."
Bill Gunshannon
May 6, 2014, 10:07:20 AM5/6/14
to
In article <bsqs86...@mid.individual.net>,
>
> There should be a series of check boxes for FUNCTIONALITY.
>
> Tick the boxes, the installer gets and installs support for that facility.
Or just install everything you know is needed and run all the commands
needed to make it work. Checking "tick boxes" is for people who actually
understand what happens underneath. None of the COBOL programmers I have
ever worked with knew or cared. I'm a geek, most COBOL programmers are
not.
Maybe I got the wrong thing, but when I followed the link I was given and
downloaded it, all it did was copy a bunch of files into a directory on
the C: drive. cobc still did nothing.
>
>
>>>
>>>> Next big step is to figure out how to get GNU COBOL to work on
>>>> Windows. I grabbed an installer but all it seemed to do was copy a
>>>> bunch of files into a directory in C:\. Any detailed explanations
>>>> available? Planning on doing my testing on Server2012. Already
>>>> have PostgreSQL running there nicely. I think there is more
>>>> potential for longterm interest in running on Windows rather than
>>>> BSD or even Linux.
>>>
>>> Tried the standard way using a mini linux environment within Win but
>>> if I have to do so again is to try and use MS Visual C to build the
>>> compiler, however that said if I want to compile a Cobol system
>>> under Windows I will more likely than not use MF Visual Cobol v2.2
>>> Personal Edition.
>>
>> Doesn't the first kind of defeat the purpose of having an OpenSource
>> COBOL compiler? I expect a commercial license for MS Visual C is
>> more than just buying a commercial COBOL.
>
> Your expectation is not only without foundation, it is just plain wrong.
>
> There is no "commercial license" for Visual C or any of the other MS "Visual
> Languages" (VB.NET, C++, C#), unless you want a Microsoft Corporate support
> agreement. (As there are extensive code samples, examples, and friendly user
> forums for all of these products, you can easily do without Corporate
> support. I have personally never needed it and I have found that the free
> videos and support forums have been more than capapble of solving any
> problems I have encountered.)
Well, guess I am just confused then. We pay a sizable fee to be MSDNAA
members inorder to get Visual Studio and to my knowledge, this does not
include things like COBOL and Fortran, they are separately licensable
(and I expect sold) products. We do get all the OSes, though. :-)
>
> http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
> (NOTE that this page specifically states that these languages are FREE for
> commercial development and distribution of software.)
Interesting. I wonder if my boss knows that.
>
> You download Visual Studio Express and you can add ANY of the above
> languages to it, for FREE.
Maybe I need to look at MS's COBOL, too. I have been sticking pretty
much with the OpenSource stuff because I always thought the commercial
stuff was over-priced.
>
> One of the factors that drove me away from COBOL was that I wanted .NET and
> the early .NET COBOLs were very expensive. (Some would argue that they are
> still way too expensive, and if you factor in Run Time Licensing for Micro
> Focus, it becomes non-viable for many small software houses and independent
> developers.)
>
> I wanted .NET but the COBOL route to it was costly. The realization soon
> dawned that I could get there FOR FREE if I simply changed the development
> language.
OK, now I am confused again. Is it free or not?
>
> While you're all so busy bashing Microsoft and extolling how wonderful it is
> to have free open software, you simply miss the fact that MS supports its
> developers, and their .NET languages are also free.
I don't bash MS. They have a place just like any other IT solution. My
datacenter rack is loaded with 2003 and 2012 Servers. All but 3 of my
current crop of BSD and Linux servers are Virtual on top of Server 2012
and Hyper-V. (And there are specific reasons why those 3 are not being
virtualized!)
>
> (I am in favour of Open software because people should have a choice, but I
> already experienced having my fingers burned when trying to use it in a
> commercial environment, and finding no-one would be responsible for it.
> (PostgreSQL ODBC driver). I am not saying I'd ever use open software
> commercially again, but I'd need to know it was beyond "hobby software" and
> there was a mechanism in place to provide support for it. It also needs to
> provide the FUNCTIONALITY I require and I have been consistent on that for
> some years now with regard to Open COBOL. If all these ducks were in a row.
> I'd be happy to use it, help support it, and promote it to others. (Largely
> because we have clients using COBOL; not because I need any variant of COBOL
> for myself or PRIMA). Right now, all I can do is wish the project well.)
Well, that's pretty much my opinion, too. I have seen a lot of crap under
the OpenSource banner, but I have seen a lot of quality stuff, too. And
most of the quality stuff has options available so that commercial users
can get equivalent support to proprietary software options. And commercial
software has its quirks, too. Had a problem with MicroFocus COBOL during
that last gig I did. Their solution was "You need to buy a newer version
of the compiler". We did. And it broke more code than it fixed. (That's
what led to my cleaning up the code in 14 different programs. As long as
I had to edit and recompile all of them anyway, figured I might as well
make the effort to clean them up. Good bye GOTO!!)
>
>
>> And, of course, MF Visual
>> Cobol v2.2 Personal Edition is pertty much the antithesis of GNU
>> COBOL.
>>
>
> I don't understand this. How can two implementations of an archaic language
> be the antithesis of each other? You could argue that neither of them is of
> any real value in the modern commercial networked world, where the object
> paradigm is king. (Although Micro Focus COBOL implements COM it does so
> abysmally and Fujitsu creams it in this regard. Open COBOL does not yet
> support objects, never mind COM...)
Had nothing to do with the language. I was refering to one being free
(in all senses of the word) and the other costing money, at least if you
plan to use it for commercial development.
>
>>>
>>> However I only compile my OS release code to test it but not supply
>>> as binary.
>>>
>>> I suggest you create an account on sourceforge and login and then go
>>> to http://sourceforge.net/p/open-cobol/discussion/?source=navbar and
>>> leave details of any more issues there. There is a lot of GNU Cobol
>>> compiler users that hang out who can help you more regarding using
>>> Windows.
>>
>> Nice thought, but I am a COBOL end product developer, not a compiler
>> developer. And the tiem have to follow discussions is rather limited.
>> Maybe Pete is right and this package is just not ready for prime time
>> and may never be.
>
> I never said it "may never be" (your statement is ambiguous); in fact, given
> the passion and time and effort that is going into it, it would be good to
> see it become a viable commercial product. (I understand some companies have
> picked it up and that is encouraging) but, right now, for me, at least, it
> is not a commercial product.
Based on what I am seeing, it is at least not viable on 64bit platforms
(I have not tried much with Linux as, with over 35 years of Unix experience,
I actually find it cunbersome and difficult to use. But when I take the
same program and get the problems I see just moving between 32 and 64 bit
systems, well, some real work needed there.
Oh, and it is not just COBOL. I find many packages that work well on 32
bit BSD that fall on their faces when moved to 64 bit.
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
>>
>> Isn't that the purpose of "configure"? How is the user supposed to
>> know what "will or might be needed" when they are installing a new
>> package unless the package tells them.
>
> Why should a user need to know about libraries at all?
Exactly.
> Bill Gunshannon wrote:
>>
>> Isn't that the purpose of "configure"? How is the user supposed to
>> know what "will or might be needed" when they are installing a new
>> package unless the package tells them.
>
> Why should a user need to know about libraries at all?
>
> There should be a series of check boxes for FUNCTIONALITY.
>
> Tick the boxes, the installer gets and installs support for that facility.
needed to make it work. Checking "tick boxes" is for people who actually
understand what happens underneath. None of the COBOL programmers I have
ever worked with knew or cared. I'm a geek, most COBOL programmers are
not.
downloaded it, all it did was copy a bunch of files into a directory on
the C: drive. cobc still did nothing.
>
>
>>>
>>>> Next big step is to figure out how to get GNU COBOL to work on
>>>> Windows. I grabbed an installer but all it seemed to do was copy a
>>>> bunch of files into a directory in C:\. Any detailed explanations
>>>> available? Planning on doing my testing on Server2012. Already
>>>> have PostgreSQL running there nicely. I think there is more
>>>> potential for longterm interest in running on Windows rather than
>>>> BSD or even Linux.
>>>
>>> Tried the standard way using a mini linux environment within Win but
>>> if I have to do so again is to try and use MS Visual C to build the
>>> compiler, however that said if I want to compile a Cobol system
>>> under Windows I will more likely than not use MF Visual Cobol v2.2
>>> Personal Edition.
>>
>> Doesn't the first kind of defeat the purpose of having an OpenSource
>> COBOL compiler? I expect a commercial license for MS Visual C is
>> more than just buying a commercial COBOL.
>
> Your expectation is not only without foundation, it is just plain wrong.
>
> There is no "commercial license" for Visual C or any of the other MS "Visual
> Languages" (VB.NET, C++, C#), unless you want a Microsoft Corporate support
> agreement. (As there are extensive code samples, examples, and friendly user
> forums for all of these products, you can easily do without Corporate
> support. I have personally never needed it and I have found that the free
> videos and support forums have been more than capapble of solving any
> problems I have encountered.)
members inorder to get Visual Studio and to my knowledge, this does not
include things like COBOL and Fortran, they are separately licensable
(and I expect sold) products. We do get all the OSes, though. :-)
>
> http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
> (NOTE that this page specifically states that these languages are FREE for
> commercial development and distribution of software.)
>
> You download Visual Studio Express and you can add ANY of the above
> languages to it, for FREE.
much with the OpenSource stuff because I always thought the commercial
stuff was over-priced.
>
> One of the factors that drove me away from COBOL was that I wanted .NET and
> the early .NET COBOLs were very expensive. (Some would argue that they are
> still way too expensive, and if you factor in Run Time Licensing for Micro
> Focus, it becomes non-viable for many small software houses and independent
> developers.)
>
> I wanted .NET but the COBOL route to it was costly. The realization soon
> dawned that I could get there FOR FREE if I simply changed the development
> language.
>
> While you're all so busy bashing Microsoft and extolling how wonderful it is
> to have free open software, you simply miss the fact that MS supports its
> developers, and their .NET languages are also free.
datacenter rack is loaded with 2003 and 2012 Servers. All but 3 of my
current crop of BSD and Linux servers are Virtual on top of Server 2012
and Hyper-V. (And there are specific reasons why those 3 are not being
virtualized!)
>
> (I am in favour of Open software because people should have a choice, but I
> already experienced having my fingers burned when trying to use it in a
> commercial environment, and finding no-one would be responsible for it.
> (PostgreSQL ODBC driver). I am not saying I'd ever use open software
> commercially again, but I'd need to know it was beyond "hobby software" and
> there was a mechanism in place to provide support for it. It also needs to
> provide the FUNCTIONALITY I require and I have been consistent on that for
> some years now with regard to Open COBOL. If all these ducks were in a row.
> I'd be happy to use it, help support it, and promote it to others. (Largely
> because we have clients using COBOL; not because I need any variant of COBOL
> for myself or PRIMA). Right now, all I can do is wish the project well.)
the OpenSource banner, but I have seen a lot of quality stuff, too. And
most of the quality stuff has options available so that commercial users
can get equivalent support to proprietary software options. And commercial
software has its quirks, too. Had a problem with MicroFocus COBOL during
that last gig I did. Their solution was "You need to buy a newer version
of the compiler". We did. And it broke more code than it fixed. (That's
what led to my cleaning up the code in 14 different programs. As long as
I had to edit and recompile all of them anyway, figured I might as well
make the effort to clean them up. Good bye GOTO!!)
>
>
>> And, of course, MF Visual
>> Cobol v2.2 Personal Edition is pertty much the antithesis of GNU
>> COBOL.
>>
>
> I don't understand this. How can two implementations of an archaic language
> be the antithesis of each other? You could argue that neither of them is of
> any real value in the modern commercial networked world, where the object
> paradigm is king. (Although Micro Focus COBOL implements COM it does so
> abysmally and Fujitsu creams it in this regard. Open COBOL does not yet
> support objects, never mind COM...)
(in all senses of the word) and the other costing money, at least if you
plan to use it for commercial development.
>
>>>
>>> However I only compile my OS release code to test it but not supply
>>> as binary.
>>>
>>> I suggest you create an account on sourceforge and login and then go
>>> to http://sourceforge.net/p/open-cobol/discussion/?source=navbar and
>>> leave details of any more issues there. There is a lot of GNU Cobol
>>> compiler users that hang out who can help you more regarding using
>>> Windows.
>>
>> Nice thought, but I am a COBOL end product developer, not a compiler
>> developer. And the tiem have to follow discussions is rather limited.
>> Maybe Pete is right and this package is just not ready for prime time
>> and may never be.
>
> I never said it "may never be" (your statement is ambiguous); in fact, given
> the passion and time and effort that is going into it, it would be good to
> see it become a viable commercial product. (I understand some companies have
> picked it up and that is encouraging) but, right now, for me, at least, it
> is not a commercial product.
(I have not tried much with Linux as, with over 35 years of Unix experience,
I actually find it cunbersome and difficult to use. But when I take the
same program and get the problems I see just moving between 32 and 64 bit
systems, well, some real work needed there.
Oh, and it is not just COBOL. I find many packages that work well on 32
bit BSD that fall on their faces when moved to 64 bit.
Vince Coen
May 6, 2014, 4:29:35 PM5/6/14
to
Hello Bill!
Tuesday May 06 2014 15:07, Bill Gunshannon wrote to All:
> Based on what I am seeing, it is at least not viable on 64bit
> platforms (I have not tried much with Linux as, with over 35 years of
> Unix experience, I actually find it cunbersome and difficult to use.
> But when I take the same program and get the problems I see just
> moving between 32 and 64 bit systems, well, some real work needed
> there.
> Oh, and it is not just COBOL. I find many packages that work well on
> 32 bit BSD that fall on their faces when moved to 64 bit.
GNU/Open Cobol works on both i64 and x64. Likewise my experience of moving
the data files between also works depending on the ISAM used.
The compiler source does not comes with all the possible libraries for some
very good reasons:
For ISAM you have a range of options as to what tool you wish to use for
it, e.g., VBISAM, Berkeley DB vn.y where n = 1 thru 5 and what one depends
on what is available in your distro OR the one you are prepared to install
from tar type archives. In addition for v2.0 of the compiler there is also
a revised version of the fileio code that allows you to use MySQL to act as
the ISAM handler. This code is new this year and has been contributed by a
user as many of the new functionality has including RW - see v2.1.
There are other libraries that can also be used for ISAM but I have kept
clear of them. Linking to RDBMS such as MySQL, Postgres, DB/2, Oracle etc.
Next we can use curses, ncurses and some others that start moving away from
Cobol standards but appear to work well.
The Arithmetic library seems to be a constant BUT by the nature of the way
source code can be installed it is possible that this (and for that matter
some of the library systems details above may well be already pre-installed
by your Linux distribution.
So in simple terms it is down to the programmer to work out what options
s/he wishes to use and install them while following the README install
requisites information.
Is this different to installing Micro Focus Visual Cobol no not really
there are a few options as to what you are going to use with it, e.g., MS
VS specific versions from 2010, 2012, 2013, 2014 (beta) then you can use
Eclipse on both Windows and Linux platforms. There are other options if I
remember correctly.
GNU/Open Cobol gives the programmer and therefore the development project
management total control of whatever linkage tools, libraries they want.
If you want the compiler to just work imediately without having to make
decisions I suggest you play with the Windows version v1.1 that is
available via the GNU/Open Cobol wensite and other sources.
Here is one compiled for MS VS Express:
http://www.kiska.net/opencobol/1.1/opencobol-1.1-win-vb-win32-bin.zip
and here more for the g.win systems:
http://opencobol.add1tocobol.com/gnucobol/#are-there-pre-built-gnu-cobol-pa
ckages
No doubt there are more but its getting late.
Take your pick ....
Vince
Tuesday May 06 2014 15:07, Bill Gunshannon wrote to All:
> Based on what I am seeing, it is at least not viable on 64bit
> platforms (I have not tried much with Linux as, with over 35 years of
> Unix experience, I actually find it cunbersome and difficult to use.
> But when I take the same program and get the problems I see just
> moving between 32 and 64 bit systems, well, some real work needed
> there.
> Oh, and it is not just COBOL. I find many packages that work well on
> 32 bit BSD that fall on their faces when moved to 64 bit.
the data files between also works depending on the ISAM used.
The compiler source does not comes with all the possible libraries for some
very good reasons:
For ISAM you have a range of options as to what tool you wish to use for
it, e.g., VBISAM, Berkeley DB vn.y where n = 1 thru 5 and what one depends
on what is available in your distro OR the one you are prepared to install
from tar type archives. In addition for v2.0 of the compiler there is also
a revised version of the fileio code that allows you to use MySQL to act as
the ISAM handler. This code is new this year and has been contributed by a
user as many of the new functionality has including RW - see v2.1.
There are other libraries that can also be used for ISAM but I have kept
clear of them. Linking to RDBMS such as MySQL, Postgres, DB/2, Oracle etc.
Next we can use curses, ncurses and some others that start moving away from
Cobol standards but appear to work well.
The Arithmetic library seems to be a constant BUT by the nature of the way
source code can be installed it is possible that this (and for that matter
some of the library systems details above may well be already pre-installed
by your Linux distribution.
So in simple terms it is down to the programmer to work out what options
s/he wishes to use and install them while following the README install
requisites information.
Is this different to installing Micro Focus Visual Cobol no not really
there are a few options as to what you are going to use with it, e.g., MS
VS specific versions from 2010, 2012, 2013, 2014 (beta) then you can use
Eclipse on both Windows and Linux platforms. There are other options if I
remember correctly.
GNU/Open Cobol gives the programmer and therefore the development project
management total control of whatever linkage tools, libraries they want.
If you want the compiler to just work imediately without having to make
decisions I suggest you play with the Windows version v1.1 that is
available via the GNU/Open Cobol wensite and other sources.
Here is one compiled for MS VS Express:
http://www.kiska.net/opencobol/1.1/opencobol-1.1-win-vb-win32-bin.zip
and here more for the g.win systems:
http://opencobol.add1tocobol.com/gnucobol/#are-there-pre-built-gnu-cobol-pa
ckages
No doubt there are more but its getting late.
Take your pick ....
Vince
Pete Dashwood
May 6, 2014, 8:14:27 PM5/6/14
to
Bill Gunshannon wrote:
> In article <bsqs86...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> Bill Gunshannon wrote:
>>>
>>> Isn't that the purpose of "configure"? How is the user supposed to
>>> know what "will or might be needed" when they are installing a new
>>> package unless the package tells them.
>>
>> Why should a user need to know about libraries at all?
>
> Exactly.
>
>>
>> There should be a series of check boxes for FUNCTIONALITY.
>>
>> Tick the boxes, the installer gets and installs support for that
>> facility.
>
> Or just install everything you know is needed and run all the commands
> needed to make it work. Checking "tick boxes" is for people who
> actually understand what happens underneath.
Not in the sense I was using it. I'm talking about FUNCTIONALITY, as
> In article <bsqs86...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> Bill Gunshannon wrote:
>>>
>>> Isn't that the purpose of "configure"? How is the user supposed to
>>> know what "will or might be needed" when they are installing a new
>>> package unless the package tells them.
>>
>> Why should a user need to know about libraries at all?
>
> Exactly.
>
>>
>> There should be a series of check boxes for FUNCTIONALITY.
>>
>> Tick the boxes, the installer gets and installs support for that
>> facility.
>
> Or just install everything you know is needed and run all the commands
> needed to make it work. Checking "tick boxes" is for people who
> actually understand what happens underneath.
options.
For example:
I want to install COBOL...
The installer knows I need all of the core facilities (including ISAM) so it
installs those by default.
BUT, I may also want:
1. Support for SQL (radio buttons for the RDBMS that are supported)
2. Support for Windows API calls
3.Support for Objects and COM
4. Support for Intrinsic Functions
5. Support for Collections
6 Support for Calling Java
7. Support for Micro Focus COBOL routines (Equivalent runtime modules that
support the same functionality as the routines provided by Micro Focus...
these have become a de facto COBOL feature over the years.)
8. Support for Building and deploying my COBOL applications
... just as examples. All of the above would be offered as check boxes by
the installer and the appropriate libraries, paths, and compiler options and
configuration would be set automatically "under the covers" by the install
process. You get what you asked for and if you want to change it you can do
so manually (but that DOES require more understanding of the compiler
options, configuration, and the COBOL development environment.)
> None of the COBOL
> programmers I have ever worked with knew or cared. I'm a geek, most
> COBOL programmers are not.
>
"geek" by someone who writes Kiddiescript...
comment.
Based on experiences related here, I wouldn't be encouraged to do so at the
moment.
virtually any MS software you want (or have ever wanted... :-)).
But you certainly don't need it in order to get Visual Studio (or anything
else, really). I started by using the Express version of VS and C#. (Free
download and no license fee) I was so impressed that I paid to upgrade to
the full version of VS 2008. But, if I was honest, the extra features were
far from essential (though good to have, especially if you are doing web
development as well as desktop, which I am). I could have done ALL of the
code development I have done (for both web and desktop) using the free
version of VS 2008. (although some of the additional tools were useful for
things like deployment). The latest versions (2012/2013) promise cross
platform support for mobile and phone development as well, and, when I'm
ready to move into that I'll certainly download the free version.
>
>>
>> http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
>> (NOTE that this page specifically states that these languages are
>> FREE for commercial development and distribution of software.)
>
> Interesting. I wonder if my boss knows that.
This is far from the truth. There are a number of options offered by MS to
independent developers and small businesses where they will give you free
software and support for three years (for example) while you build your
business, on the understanding that you will license whatever software you
need to license at the end of that time. This means you can have many of the
advantages of MSDN membership without the cost of MSDN membership, provided
you agree to use the software.
But even without such a scheme, you can still use all the free stuff for
.NET, including Visual Studio and the .NET languages (Express Vesions).
Don't think for one minute that the Express versions are "nobbled" or
limited. They are not. But the Professional (licensed) version of VS offers
additional tools and facilities that can be useful. (You can always get the
same functionality without the full version, but you have to do more
work...)
>
>>
>> You download Visual Studio Express and you can add ANY of the above
>> languages to it, for FREE.
>
> Maybe I need to look at MS's COBOL, too. I have been sticking pretty
> much with the OpenSource stuff because I always thought the commercial
> stuff was over-priced.
I am not familiar with a MS COBOL (apart from the one they bought from Micro
>>
>> You download Visual Studio Express and you can add ANY of the above
>> languages to it, for FREE.
>
> Maybe I need to look at MS's COBOL, too. I have been sticking pretty
> much with the OpenSource stuff because I always thought the commercial
> stuff was over-priced.
Focus and rebadged many years ago. I understood that was long gone, but I
could be wrong about that)
>
>>
>> One of the factors that drove me away from COBOL was that I wanted
>> .NET and the early .NET COBOLs were very expensive. (Some would
>> argue that they are still way too expensive, and if you factor in
>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>> small software houses and independent developers.)
>>
>> I wanted .NET but the COBOL route to it was costly. The realization
>> soon dawned that I could get there FOR FREE if I simply changed the
>> development language.
>
> OK, now I am confused again. Is it free or not?
Yes, it is free. I gave you the link; read it again, especially the terms
>>
>> One of the factors that drove me away from COBOL was that I wanted
>> .NET and the early .NET COBOLs were very expensive. (Some would
>> argue that they are still way too expensive, and if you factor in
>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>> small software houses and independent developers.)
>>
>> I wanted .NET but the COBOL route to it was costly. The realization
>> soon dawned that I could get there FOR FREE if I simply changed the
>> development language.
>
> OK, now I am confused again. Is it free or not?
and conditions. You can use the MS languages for .NET for COMMERCIAL
development, for free.
It has ALWAYS been that way and they don't look like they are about to
change it.
I remember dire warnings from people here when I first suggested this might
be a good route to go... ("Microsoft will suck you in then they'll charge a
fee" etc)
It hasn't happened and it won't. There have been over 40,000,000 downloads
of C#. MS has continued to develop and support new versions of it and the
language today is simply brilliant.
(I enjoy developing in C# every bit as much as I used to enjoy developing in
COBOL; it is more powerful, the tools are better, and it is very satisfying
to see my productivity improved at no cost to me.)
Support for the .NET framework is built into all modern versions of
Windows. In effect, the run time for the .NET languages is paid for when you
(or someone) buy the OS.
It is a very good and fair model which happens to favour developers.
>
>>
>> While you're all so busy bashing Microsoft and extolling how
>> wonderful it is to have free open software, you simply miss the fact
>> that MS supports its developers, and their .NET languages are also
>> free.
>
> I don't bash MS.
Fair enough. (I meant "you" plural, being many of the regulars here.)
>>
>> While you're all so busy bashing Microsoft and extolling how
>> wonderful it is to have free open software, you simply miss the fact
>> that MS supports its developers, and their .NET languages are also
>> free.
>
> I don't bash MS.
> They have a place just like any other IT solution.
> My datacenter rack is loaded with 2003 and 2012 Servers. All but 3
> of my current crop of BSD and Linux servers are Virtual on top of
> Server 2012
> and Hyper-V. (And there are specific reasons why those 3 are not
> being virtualized!)
>
testing and PRIMA. Historically, we used ORACLE Virtual Box and it has
continued to meet our needs so I have not made a switch to Hyper-V... yet.
>>
>> (I am in favour of Open software because people should have a
>> choice, but I already experienced having my fingers burned when
>> trying to use it in a commercial environment, and finding no-one
>> would be responsible for it. (PostgreSQL ODBC driver). I am not
>> saying I'd ever use open software commercially again, but I'd need
>> to know it was beyond "hobby software" and there was a mechanism in
>> place to provide support for it. It also needs to provide the
>> FUNCTIONALITY I require and I have been consistent on that for some
>> years now with regard to Open COBOL. If all these ducks were in a
>> row. I'd be happy to use it, help support it, and promote it to
>> others. (Largely because we have clients using COBOL; not because I
>> need any variant of COBOL for myself or PRIMA). Right now, all I can
>> do is wish the project well.)
>
> Well, that's pretty much my opinion, too. I have seen a lot of crap
> under the OpenSource banner, but I have seen a lot of quality stuff,
> too. And most of the quality stuff has options available so that
> commercial users can get equivalent support to proprietary software
> options. And commercial software has its quirks, too. Had a problem
> with MicroFocus COBOL during that last gig I did. Their solution was
> "You need to buy a newer version of the compiler". We did. And it
> broke more code than it fixed. (That's what led to my cleaning up
> the code in 14 different programs. As long as
> I had to edit and recompile all of them anyway, figured I might as
> well make the effort to clean them up. Good bye GOTO!!)
I like Micro Focus as a company and have always enjoyed a good relationship
>> (I am in favour of Open software because people should have a
>> choice, but I already experienced having my fingers burned when
>> trying to use it in a commercial environment, and finding no-one
>> would be responsible for it. (PostgreSQL ODBC driver). I am not
>> saying I'd ever use open software commercially again, but I'd need
>> to know it was beyond "hobby software" and there was a mechanism in
>> place to provide support for it. It also needs to provide the
>> FUNCTIONALITY I require and I have been consistent on that for some
>> years now with regard to Open COBOL. If all these ducks were in a
>> row. I'd be happy to use it, help support it, and promote it to
>> others. (Largely because we have clients using COBOL; not because I
>> need any variant of COBOL for myself or PRIMA). Right now, all I can
>> do is wish the project well.)
>
> Well, that's pretty much my opinion, too. I have seen a lot of crap
> under the OpenSource banner, but I have seen a lot of quality stuff,
> too. And most of the quality stuff has options available so that
> commercial users can get equivalent support to proprietary software
> options. And commercial software has its quirks, too. Had a problem
> with MicroFocus COBOL during that last gig I did. Their solution was
> "You need to buy a newer version of the compiler". We did. And it
> broke more code than it fixed. (That's what led to my cleaning up
> the code in 14 different programs. As long as
> I had to edit and recompile all of them anyway, figured I might as
> well make the effort to clean them up. Good bye GOTO!!)
with them, but the Fujitsu COBOL product, in my opinion, is better. Micro
Focus needs lower level work and, although many people enjoy that, for
myself, I want an easy life. I need to spend my time and energy solving
application problems and not grappling with development configurations. When
people come to us for migration now, the first thing we do is convert their
existing COBOL to Fujitsu (at no cost to them). It provides a standard
baseline for dialects like PR1ME and RM COBOL.
>
>>
>>
>>> And, of course, MF Visual
>>> Cobol v2.2 Personal Edition is pertty much the antithesis of GNU
>>> COBOL.
>>>
>>
>> I don't understand this. How can two implementations of an archaic
>> language be the antithesis of each other? You could argue that
>> neither of them is of any real value in the modern commercial
>> networked world, where the object paradigm is king. (Although Micro
>> Focus COBOL implements COM it does so abysmally and Fujitsu creams
>> it in this regard. Open COBOL does not yet support objects, never
>> mind COM...)
>
> Had nothing to do with the language. I was refering to one being free
> (in all senses of the word) and the other costing money, at least if
> you plan to use it for commercial development.
>
platform to target when we build in VS. The options are x32, x64, or Any.
Using "Any" can be problematic if the deployed application is using both 32
and 64 bit components, but it just needs a bit of care.
Arnold Trembley
May 7, 2014, 2:10:18 AM5/7/14
to
On 5/5/2014 8:29 PM, Pete Dashwood wrote:
> (snip)
the Gary Cutler's .zip file of OpenCOBOL 1.1 built with MinGW. I tried
out the zip file and it worked because it installed the MinGW
(Minimalist GNU for Windows) GCC compiler with OpenCOBOL. Gary Cutler's
OC 1.1 package had a specific folder name, directory structure, and
environment variables, and it works out of the box, with a few quirks
(Unix LF versus Windows CRLF, for example). It might be faster to
install Gary Cutler's zip file without using an installer. His
instructions were very thorough.
The problem from my point of view is: How can I build an installer for
OpenCOBOL/GNU COBOL for users who want to connect it to a different C
compiler for their back end, and don't want to alter their existing C
compiler implementation? OpenCOBOL needs its own run-time library
compiled in C, and generates intermediate code in C, and then invokes a
C compiler to build the executable program. Can cobc run with its own
MinGW or Cygwin or Visual C++ based run-time library and invoke a
different C compiler to translate the intermediate code into an
executable? I don't know how to do that. Maybe someone else knows.
It would be nice to have a native windows version of GNU Cobol using
some version of Microsoft Visual C++. Other people have built that.
But I don't think I can legally redistribute a free Microsoft C++
compiler inside a GNU Cobol installer in order to allow GNU Cobol to
invoke the C compiler the way it wants to. The INNO installer might be
sophisticated enough to allow installing OpenCOBOL onto a Windows box
that already has some version of Microsoft Visual C++ installed, and
connect them together, but I don't know how to make that work.
I'm just a COBOL programmer (not a compiler writer) who would like to
have a working COBOL compiler to play with on my own PC.
Kind regards,
>
> Pete.
>
--
http://www.arnoldtrembley.com/
> (snip)
>
> I understand Vince posting this as he is trying to help, but isn't it just
> intimidating?
>
> I can install and use both Fujitsu and Micro Focus COBOL without any of this
> nonsense.
>
> What all of this says to me is that the installer needs work. Arnold posted
> previously that he had built an INNO install for version 1.1. Maybe that
> needs to be expanded for subsequent versions.
>
> INNO is a very good package and allows interaction and checkboxes during
> install.
>
I didn't really do very much work with the INNO installer. I downloaded
> I understand Vince posting this as he is trying to help, but isn't it just
> intimidating?
>
> I can install and use both Fujitsu and Micro Focus COBOL without any of this
> nonsense.
>
> What all of this says to me is that the installer needs work. Arnold posted
> previously that he had built an INNO install for version 1.1. Maybe that
> needs to be expanded for subsequent versions.
>
> INNO is a very good package and allows interaction and checkboxes during
> install.
>
the Gary Cutler's .zip file of OpenCOBOL 1.1 built with MinGW. I tried
out the zip file and it worked because it installed the MinGW
(Minimalist GNU for Windows) GCC compiler with OpenCOBOL. Gary Cutler's
OC 1.1 package had a specific folder name, directory structure, and
environment variables, and it works out of the box, with a few quirks
(Unix LF versus Windows CRLF, for example). It might be faster to
install Gary Cutler's zip file without using an installer. His
instructions were very thorough.
The problem from my point of view is: How can I build an installer for
OpenCOBOL/GNU COBOL for users who want to connect it to a different C
compiler for their back end, and don't want to alter their existing C
compiler implementation? OpenCOBOL needs its own run-time library
compiled in C, and generates intermediate code in C, and then invokes a
C compiler to build the executable program. Can cobc run with its own
MinGW or Cygwin or Visual C++ based run-time library and invoke a
different C compiler to translate the intermediate code into an
executable? I don't know how to do that. Maybe someone else knows.
It would be nice to have a native windows version of GNU Cobol using
some version of Microsoft Visual C++. Other people have built that.
But I don't think I can legally redistribute a free Microsoft C++
compiler inside a GNU Cobol installer in order to allow GNU Cobol to
invoke the C compiler the way it wants to. The INNO installer might be
sophisticated enough to allow installing OpenCOBOL onto a Windows box
that already has some version of Microsoft Visual C++ installed, and
connect them together, but I don't know how to make that work.
I'm just a COBOL programmer (not a compiler writer) who would like to
have a working COBOL compiler to play with on my own PC.
Kind regards,
>
> Pete.
>
--
http://www.arnoldtrembley.com/
Bill Gunshannon
May 7, 2014, 7:51:45 AM5/7/14
to
In article <bstc74...@mid.individual.net>,
OK. That's another potential problem with Open Source. 5 of those 8 items
have nothing to do with a COBOL compiler and, if available at all, would
be the responsibility of different people/groups. Of course, the posibility
of someone putting together a package of all of it and offering package
support exists, but I expect there would need to be a business case first.
>
> ... just as examples. All of the above would be offered as check boxes by
> the installer and the appropriate libraries, paths, and compiler options and
> configuration would be set automatically "under the covers" by the install
> process. You get what you asked for and if you want to change it you can do
> so manually (but that DOES require more understanding of the compiler
> options, configuration, and the COBOL development environment.)
>
>> None of the COBOL
>> programmers I have ever worked with knew or cared. I'm a geek, most
>> COBOL programmers are not.
>>
>
> "Geek" is relative... somebody who programs in COBOL may be considered a
> "geek" by someone who writes Kiddiescript...
I have yet to meet a COBOL programmer who goes home after work and "relaxes"
by playing with computers (well, maybe an Xbox :-). Even among non-COBOL
people today, ggekdom is becoming a rarity. My son-in-law is an IT pro
for a very large hospital group. He gets his jollies by taking pictures
of the computer stuff in my house and sharing it with his workmates so they
can all have a good laugh.
Well, as I said, I'm a geek. And we tend to enjoy beating our heads against
the wall on a computer problem. :-)
We are MSDNAA, not the same thing as MSDN. We get OSes and development
tools, no Office products at all. Well, except for Project and Visio
which I guess they consider development tools, too.
>
> But you certainly don't need it in order to get Visual Studio (or anything
> else, really). I started by using the Express version of VS and C#. (Free
> download and no license fee) I was so impressed that I paid to upgrade to
> the full version of VS 2008. But, if I was honest, the extra features were
> far from essential (though good to have, especially if you are doing web
> development as well as desktop, which I am). I could have done ALL of the
> code development I have done (for both web and desktop) using the free
> version of VS 2008. (although some of the additional tools were useful for
> things like deployment). The latest versions (2012/2013) promise cross
> platform support for mobile and phone development as well, and, when I'm
> ready to move into that I'll certainly download the free version.
>
>>
>>>
>>> http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
>>> (NOTE that this page specifically states that these languages are
>>> FREE for commercial development and distribution of software.)
>>
>> Interesting. I wonder if my boss knows that.
>
> Unfortunately, people sometimes just assume that if it is MS it must cost.
Not so much here. The whole University is in the MS Camp. They do
all our email (not mine, my department still runs its own system) and
a lot of the cloud stuff.
> This is far from the truth. There are a number of options offered by MS to
> independent developers and small businesses where they will give you free
> software and support for three years (for example) while you build your
> business, on the understanding that you will license whatever software you
> need to license at the end of that time. This means you can have many of the
> advantages of MSDN membership without the cost of MSDN membership, provided
> you agree to use the software.
Once again, we are MSDNAA, different animal. We are expressly prohibited
from using any of the MS products we get from the program for any kind of
production. Strictly academic use.
>
> But even without such a scheme, you can still use all the free stuff for
> .NET, including Visual Studio and the .NET languages (Express Vesions).
>
> Don't think for one minute that the Express versions are "nobbled" or
> limited. They are not. But the Professional (licensed) version of VS offers
> additional tools and facilities that can be useful. (You can always get the
> same functionality without the full version, but you have to do more
> work...)
I'll have to make sure the students know that. They can get the stuff
we have under MSDNAA but the same rules apply to them. Academic use
only.
>>
>>>
>>> You download Visual Studio Express and you can add ANY of the above
>>> languages to it, for FREE.
>>
>> Maybe I need to look at MS's COBOL, too. I have been sticking pretty
>> much with the OpenSource stuff because I always thought the commercial
>> stuff was over-priced.
>
> I am not familiar with a MS COBOL (apart from the one they bought from Micro
> Focus and rebadged many years ago. I understood that was long gone, but I
> could be wrong about that)
Guess I got confused again. I thought you were talking about MS Visual
COBOL but you must mean some Micro Focus product. As a side note, I
thought MS still had a COBOL and Fortran product but that they did not
come as a part of the Base Studio Package.
>>
>>>
>>> One of the factors that drove me away from COBOL was that I wanted
>>> .NET and the early .NET COBOLs were very expensive. (Some would
>>> argue that they are still way too expensive, and if you factor in
>>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>>> small software houses and independent developers.)
>>>
>>> I wanted .NET but the COBOL route to it was costly. The realization
>>> soon dawned that I could get there FOR FREE if I simply changed the
>>> development language.
>>
>> OK, now I am confused again. Is it free or not?
>
> Yes, it is free. I gave you the link; read it again, especially the terms
> and conditions. You can use the MS languages for .NET for COMMERCIAL
> development, for free.
>
> It has ALWAYS been that way and they don't look like they are about to
> change it.
>
> I remember dire warnings from people here when I first suggested this might
> be a good route to go... ("Microsoft will suck you in then they'll charge a
> fee" etc)
No, they would never do that. Oh wait, that is exactly the way Office is
going to work now. :-)
>
> It hasn't happened and it won't. There have been over 40,000,000 downloads
> of C#. MS has continued to develop and support new versions of it and the
> language today is simply brilliant.
Matter of opinion, I guess. :-)
>
> (I enjoy developing in C# every bit as much as I used to enjoy developing in
> COBOL; it is more powerful, the tools are better, and it is very satisfying
> to see my productivity improved at no cost to me.)
>
> Support for the .NET framework is built into all modern versions of
> Windows. In effect, the run time for the .NET languages is paid for when you
> (or someone) buy the OS.
>
> It is a very good and fair model which happens to favour developers.
>>
>>>
>>> While you're all so busy bashing Microsoft and extolling how
>>> wonderful it is to have free open software, you simply miss the fact
>>> that MS supports its developers, and their .NET languages are also
>>> free.
>>
>> I don't bash MS.
> Fair enough. (I meant "you" plural, being many of the regulars here.)
>
>> They have a place just like any other IT solution.
>> My datacenter rack is loaded with 2003 and 2012 Servers. All but 3
>> of my current crop of BSD and Linux servers are Virtual on top of
>> Server 2012
>> and Hyper-V. (And there are specific reasons why those 3 are not
>> being virtualized!)
>>
>
> I like Virtual machines and we use them extensively for development and
> testing and PRIMA. Historically, we used ORACLE Virtual Box and it has
> continued to meet our needs so I have not made a switch to Hyper-V... yet.
I just looked at VirtualBox again at home. It still has one major flaw
that makes it unusable in a production environment without using separate
hacks from other vendors and that is not how I build production environments.
PR1ME, Ohmygod!!! You actually know what that is! Just out of curiosity,
do you know many people down there still running 50-series machines?
But the compiler handling 32 and 64 bit isn't the problems I am running
into. Is Open Source packages that have pieces of code that make serious
assumptions about the sizes of things. And while most compilers will
tell you about this they are often compiled with Warnings turned off.
Go figure.
have nothing to do with a COBOL compiler and, if available at all, would
be the responsibility of different people/groups. Of course, the posibility
of someone putting together a package of all of it and offering package
support exists, but I expect there would need to be a business case first.
>
> ... just as examples. All of the above would be offered as check boxes by
> the installer and the appropriate libraries, paths, and compiler options and
> configuration would be set automatically "under the covers" by the install
> process. You get what you asked for and if you want to change it you can do
> so manually (but that DOES require more understanding of the compiler
> options, configuration, and the COBOL development environment.)
>
>> None of the COBOL
>> programmers I have ever worked with knew or cared. I'm a geek, most
>> COBOL programmers are not.
>>
>
> "Geek" is relative... somebody who programs in COBOL may be considered a
> "geek" by someone who writes Kiddiescript...
by playing with computers (well, maybe an Xbox :-). Even among non-COBOL
people today, ggekdom is becoming a rarity. My son-in-law is an IT pro
for a very large hospital group. He gets his jollies by taking pictures
of the computer stuff in my house and sharing it with his workmates so they
can all have a good laugh.
the wall on a computer problem. :-)
tools, no Office products at all. Well, except for Project and Visio
which I guess they consider development tools, too.
>
> But you certainly don't need it in order to get Visual Studio (or anything
> else, really). I started by using the Express version of VS and C#. (Free
> download and no license fee) I was so impressed that I paid to upgrade to
> the full version of VS 2008. But, if I was honest, the extra features were
> far from essential (though good to have, especially if you are doing web
> development as well as desktop, which I am). I could have done ALL of the
> code development I have done (for both web and desktop) using the free
> version of VS 2008. (although some of the additional tools were useful for
> things like deployment). The latest versions (2012/2013) promise cross
> platform support for mobile and phone development as well, and, when I'm
> ready to move into that I'll certainly download the free version.
>
>>
>>>
>>> http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
>>> (NOTE that this page specifically states that these languages are
>>> FREE for commercial development and distribution of software.)
>>
>> Interesting. I wonder if my boss knows that.
>
> Unfortunately, people sometimes just assume that if it is MS it must cost.
all our email (not mine, my department still runs its own system) and
a lot of the cloud stuff.
> This is far from the truth. There are a number of options offered by MS to
> independent developers and small businesses where they will give you free
> software and support for three years (for example) while you build your
> business, on the understanding that you will license whatever software you
> need to license at the end of that time. This means you can have many of the
> advantages of MSDN membership without the cost of MSDN membership, provided
> you agree to use the software.
from using any of the MS products we get from the program for any kind of
production. Strictly academic use.
>
> But even without such a scheme, you can still use all the free stuff for
> .NET, including Visual Studio and the .NET languages (Express Vesions).
>
> Don't think for one minute that the Express versions are "nobbled" or
> limited. They are not. But the Professional (licensed) version of VS offers
> additional tools and facilities that can be useful. (You can always get the
> same functionality without the full version, but you have to do more
> work...)
we have under MSDNAA but the same rules apply to them. Academic use
only.
>>
>>>
>>> You download Visual Studio Express and you can add ANY of the above
>>> languages to it, for FREE.
>>
>> Maybe I need to look at MS's COBOL, too. I have been sticking pretty
>> much with the OpenSource stuff because I always thought the commercial
>> stuff was over-priced.
>
> I am not familiar with a MS COBOL (apart from the one they bought from Micro
> Focus and rebadged many years ago. I understood that was long gone, but I
> could be wrong about that)
COBOL but you must mean some Micro Focus product. As a side note, I
thought MS still had a COBOL and Fortran product but that they did not
come as a part of the Base Studio Package.
>>
>>>
>>> One of the factors that drove me away from COBOL was that I wanted
>>> .NET and the early .NET COBOLs were very expensive. (Some would
>>> argue that they are still way too expensive, and if you factor in
>>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>>> small software houses and independent developers.)
>>>
>>> I wanted .NET but the COBOL route to it was costly. The realization
>>> soon dawned that I could get there FOR FREE if I simply changed the
>>> development language.
>>
>> OK, now I am confused again. Is it free or not?
>
> Yes, it is free. I gave you the link; read it again, especially the terms
> and conditions. You can use the MS languages for .NET for COMMERCIAL
> development, for free.
>
> It has ALWAYS been that way and they don't look like they are about to
> change it.
>
> I remember dire warnings from people here when I first suggested this might
> be a good route to go... ("Microsoft will suck you in then they'll charge a
> fee" etc)
going to work now. :-)
>
> It hasn't happened and it won't. There have been over 40,000,000 downloads
> of C#. MS has continued to develop and support new versions of it and the
> language today is simply brilliant.
>
> (I enjoy developing in C# every bit as much as I used to enjoy developing in
> COBOL; it is more powerful, the tools are better, and it is very satisfying
> to see my productivity improved at no cost to me.)
>
> Support for the .NET framework is built into all modern versions of
> Windows. In effect, the run time for the .NET languages is paid for when you
> (or someone) buy the OS.
>
> It is a very good and fair model which happens to favour developers.
>>
>>>
>>> While you're all so busy bashing Microsoft and extolling how
>>> wonderful it is to have free open software, you simply miss the fact
>>> that MS supports its developers, and their .NET languages are also
>>> free.
>>
>> I don't bash MS.
> Fair enough. (I meant "you" plural, being many of the regulars here.)
>
>> They have a place just like any other IT solution.
>> My datacenter rack is loaded with 2003 and 2012 Servers. All but 3
>> of my current crop of BSD and Linux servers are Virtual on top of
>> Server 2012
>> and Hyper-V. (And there are specific reasons why those 3 are not
>> being virtualized!)
>>
>
> I like Virtual machines and we use them extensively for development and
> testing and PRIMA. Historically, we used ORACLE Virtual Box and it has
> continued to meet our needs so I have not made a switch to Hyper-V... yet.
that makes it unusable in a production environment without using separate
hacks from other vendors and that is not how I build production environments.
do you know many people down there still running 50-series machines?
into. Is Open Source packages that have pieces of code that make serious
assumptions about the sizes of things. And while most compilers will
tell you about this they are often compiled with Warnings turned off.
Go figure.
Bill Gunshannon
May 7, 2014, 10:20:01 AM5/7/14
to
In article <B5ednfKPS_rXU_TO...@giganews.com>,
really rather have v2.0 on any system I am trying. I think there
are probably major differences between v1.1 and v2.0.
>
> The problem from my point of view is: How can I build an installer for
> OpenCOBOL/GNU COBOL for users who want to connect it to a different C
> compiler for their back end, and don't want to alter their existing C
> compiler implementation? OpenCOBOL needs its own run-time library
> compiled in C, and generates intermediate code in C, and then invokes a
> C compiler to build the executable program. Can cobc run with its own
> MinGW or Cygwin or Visual C++ based run-time library and invoke a
> different C compiler to translate the intermediate code into an
> executable? I don't know how to do that. Maybe someone else knows.
I would assume any compiler that has a command line interface can be
worked into GNU COBOL. But I am not the one to do it. My interest
lies in making COBOL apps, not making COBOL Compilers. I work with
the innards of C and Pascal Compilers (and soon, PL/M as well) and that
is enough for any gluton for punishment.
>
> It would be nice to have a native windows version of GNU Cobol using
> some version of Microsoft Visual C++. Other people have built that.
> But I don't think I can legally redistribute a free Microsoft C++
> compiler inside a GNU Cobol installer in order to allow GNU Cobol to
> invoke the C compiler the way it wants to. The INNO installer might be
> sophisticated enough to allow installing OpenCOBOL onto a Windows box
> that already has some version of Microsoft Visual C++ installed, and
> connect them together, but I don't know how to make that work.
>
> I'm just a COBOL programmer (not a compiler writer) who would like to
> have a working COBOL compiler to play with on my own PC.
Me too.
>
> Kind regards,
>
All the best.
Arnold Trembley <arnold....@att.net> writes:
> On 5/5/2014 8:29 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I understand Vince posting this as he is trying to help, but isn't it just
>> intimidating?
>>
>> I can install and use both Fujitsu and Micro Focus COBOL without any of this
>> nonsense.
>>
>> What all of this says to me is that the installer needs work. Arnold posted
>> previously that he had built an INNO install for version 1.1. Maybe that
>> needs to be expanded for subsequent versions.
>>
>> INNO is a very good package and allows interaction and checkboxes during
>> install.
>>
>
> I didn't really do very much work with the INNO installer. I downloaded
> the Gary Cutler's .zip file of OpenCOBOL 1.1 built with MinGW. I tried
> out the zip file and it worked because it installed the MinGW
> (Minimalist GNU for Windows) GCC compiler with OpenCOBOL. Gary Cutler's
> OC 1.1 package had a specific folder name, directory structure, and
> environment variables, and it works out of the box, with a few quirks
> (Unix LF versus Windows CRLF, for example). It might be faster to
> install Gary Cutler's zip file without using an installer. His
> instructions were very thorough.
I'll have to give these another try, although at this point I would
> On 5/5/2014 8:29 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I understand Vince posting this as he is trying to help, but isn't it just
>> intimidating?
>>
>> I can install and use both Fujitsu and Micro Focus COBOL without any of this
>> nonsense.
>>
>> What all of this says to me is that the installer needs work. Arnold posted
>> previously that he had built an INNO install for version 1.1. Maybe that
>> needs to be expanded for subsequent versions.
>>
>> INNO is a very good package and allows interaction and checkboxes during
>> install.
>>
>
> I didn't really do very much work with the INNO installer. I downloaded
> the Gary Cutler's .zip file of OpenCOBOL 1.1 built with MinGW. I tried
> out the zip file and it worked because it installed the MinGW
> (Minimalist GNU for Windows) GCC compiler with OpenCOBOL. Gary Cutler's
> OC 1.1 package had a specific folder name, directory structure, and
> environment variables, and it works out of the box, with a few quirks
> (Unix LF versus Windows CRLF, for example). It might be faster to
> install Gary Cutler's zip file without using an installer. His
> instructions were very thorough.
really rather have v2.0 on any system I am trying. I think there
are probably major differences between v1.1 and v2.0.
>
> The problem from my point of view is: How can I build an installer for
> OpenCOBOL/GNU COBOL for users who want to connect it to a different C
> compiler for their back end, and don't want to alter their existing C
> compiler implementation? OpenCOBOL needs its own run-time library
> compiled in C, and generates intermediate code in C, and then invokes a
> C compiler to build the executable program. Can cobc run with its own
> MinGW or Cygwin or Visual C++ based run-time library and invoke a
> different C compiler to translate the intermediate code into an
> executable? I don't know how to do that. Maybe someone else knows.
worked into GNU COBOL. But I am not the one to do it. My interest
lies in making COBOL apps, not making COBOL Compilers. I work with
the innards of C and Pascal Compilers (and soon, PL/M as well) and that
is enough for any gluton for punishment.
>
> It would be nice to have a native windows version of GNU Cobol using
> some version of Microsoft Visual C++. Other people have built that.
> But I don't think I can legally redistribute a free Microsoft C++
> compiler inside a GNU Cobol installer in order to allow GNU Cobol to
> invoke the C compiler the way it wants to. The INNO installer might be
> sophisticated enough to allow installing OpenCOBOL onto a Windows box
> that already has some version of Microsoft Visual C++ installed, and
> connect them together, but I don't know how to make that work.
>
> I'm just a COBOL programmer (not a compiler writer) who would like to
> have a working COBOL compiler to play with on my own PC.
>
> Kind regards,
>
All the best.
Bill Gunshannon
May 7, 2014, 10:30:35 AM5/7/14
to
In article <13994...@f1.n250.z2.fidonet.ftn>,
> Likewise my experience of moving
> the data files between also works depending on the ISAM used.
Moving data files is a totally different problem.
>
> The compiler source does not comes with all the possible libraries for some
> very good reasons:
>
> For ISAM you have a range of options as to what tool you wish to use for
> it, e.g., VBISAM, Berkeley DB vn.y where n = 1 thru 5 and what one depends
> on what is available in your distro OR the one you are prepared to install
> from tar type archives. In addition for v2.0 of the compiler there is also
> a revised version of the fileio code that allows you to use MySQL to act as
> the ISAM handler. This code is new this year and has been contributed by a
> user as many of the new functionality has including RW - see v2.1.
>
> There are other libraries that can also be used for ISAM but I have kept
> clear of them. Linking to RDBMS such as MySQL, Postgres, DB/2, Oracle etc.
>
> Next we can use curses, ncurses and some others that start moving away from
> Cobol standards but appear to work well.
>
> The Arithmetic library seems to be a constant BUT by the nature of the way
> source code can be installed it is possible that this (and for that matter
> some of the library systems details above may well be already pre-installed
> by your Linux distribution.
>
> So in simple terms it is down to the programmer to work out what options
> s/he wishes to use and install them while following the README install
> requisites information.
My problem, as stated, was with the inability of GNU/Open COBOL handling
even simple sequential files on FreeBSD. Compiler builds and installs
with nary a complaint but any attempt to open a simple file fails with
a 30 error. I have no idea what I can do to try and figure out what in
the COBOL compiler is causing this. But I am open to suggestions as long
as they don't involve reading the source. I haven't the time to get that
deep into it and for the time being, at least, doing my work on a 32 bit
virtual machine is good enough.
>
> Is this different to installing Micro Focus Visual Cobol no not really
> there are a few options as to what you are going to use with it, e.g., MS
> VS specific versions from 2010, 2012, 2013, 2014 (beta) then you can use
> Eclipse on both Windows and Linux platforms. There are other options if I
> remember correctly.
I tried to get an Eclipse plugin for COBOL but it is ancient and there
is no simple install for it any more. You have to download the entire
develpment tree and then try to figure out what you have and what to
do with it yourself. Unless you know of a different one.
>
> GNU/Open Cobol gives the programmer and therefore the development project
> management total control of whatever linkage tools, libraries they want.
>
> If you want the compiler to just work imediately without having to make
> decisions I suggest you play with the Windows version v1.1 that is
> available via the GNU/Open Cobol wensite and other sources.
>
> Here is one compiled for MS VS Express:
> http://www.kiska.net/opencobol/1.1/opencobol-1.1-win-vb-win32-bin.zip
Got this one, wasn't sure what it was or did. Note it is a zip file,
not an installer. It contains a directory tree and does not install
like any Windows package.
>
> and here more for the g.win systems:
>
> http://opencobol.add1tocobol.com/gnucobol/#are-there-pre-built-gnu-cobol-pa
> ckages
I think I saw this but not sure that any of this contains more than just
compiled binaries. There is more required than just "cobc".
>
> No doubt there are more but its getting late.
>
> Take your pick ....
I'll keep looking.
"Vince Coen" <VBC...@gmail.com> writes:
> Hello Bill!
>
> Tuesday May 06 2014 15:07, Bill Gunshannon wrote to All:
>
> > Based on what I am seeing, it is at least not viable on 64bit
> > platforms (I have not tried much with Linux as, with over 35 years of
> > Unix experience, I actually find it cunbersome and difficult to use.
> > But when I take the same program and get the problems I see just
> > moving between 32 and 64 bit systems, well, some real work needed
> > there.
>
> > Oh, and it is not just COBOL. I find many packages that work well on
> > 32 bit BSD that fall on their faces when moved to 64 bit.
>
>
> GNU/Open Cobol works on both i64 and x64.
Apparently in most, but not all circumstances.
> Hello Bill!
>
> Tuesday May 06 2014 15:07, Bill Gunshannon wrote to All:
>
> > Based on what I am seeing, it is at least not viable on 64bit
> > platforms (I have not tried much with Linux as, with over 35 years of
> > Unix experience, I actually find it cunbersome and difficult to use.
> > But when I take the same program and get the problems I see just
> > moving between 32 and 64 bit systems, well, some real work needed
> > there.
>
> > Oh, and it is not just COBOL. I find many packages that work well on
> > 32 bit BSD that fall on their faces when moved to 64 bit.
>
>
> GNU/Open Cobol works on both i64 and x64.
> Likewise my experience of moving
> the data files between also works depending on the ISAM used.
>
> The compiler source does not comes with all the possible libraries for some
> very good reasons:
>
> For ISAM you have a range of options as to what tool you wish to use for
> it, e.g., VBISAM, Berkeley DB vn.y where n = 1 thru 5 and what one depends
> on what is available in your distro OR the one you are prepared to install
> from tar type archives. In addition for v2.0 of the compiler there is also
> a revised version of the fileio code that allows you to use MySQL to act as
> the ISAM handler. This code is new this year and has been contributed by a
> user as many of the new functionality has including RW - see v2.1.
>
> There are other libraries that can also be used for ISAM but I have kept
> clear of them. Linking to RDBMS such as MySQL, Postgres, DB/2, Oracle etc.
>
> Next we can use curses, ncurses and some others that start moving away from
> Cobol standards but appear to work well.
>
> The Arithmetic library seems to be a constant BUT by the nature of the way
> source code can be installed it is possible that this (and for that matter
> some of the library systems details above may well be already pre-installed
> by your Linux distribution.
>
> So in simple terms it is down to the programmer to work out what options
> s/he wishes to use and install them while following the README install
> requisites information.
even simple sequential files on FreeBSD. Compiler builds and installs
with nary a complaint but any attempt to open a simple file fails with
a 30 error. I have no idea what I can do to try and figure out what in
the COBOL compiler is causing this. But I am open to suggestions as long
as they don't involve reading the source. I haven't the time to get that
deep into it and for the time being, at least, doing my work on a 32 bit
virtual machine is good enough.
>
> Is this different to installing Micro Focus Visual Cobol no not really
> there are a few options as to what you are going to use with it, e.g., MS
> VS specific versions from 2010, 2012, 2013, 2014 (beta) then you can use
> Eclipse on both Windows and Linux platforms. There are other options if I
> remember correctly.
is no simple install for it any more. You have to download the entire
develpment tree and then try to figure out what you have and what to
do with it yourself. Unless you know of a different one.
>
> GNU/Open Cobol gives the programmer and therefore the development project
> management total control of whatever linkage tools, libraries they want.
>
> If you want the compiler to just work imediately without having to make
> decisions I suggest you play with the Windows version v1.1 that is
> available via the GNU/Open Cobol wensite and other sources.
>
> Here is one compiled for MS VS Express:
> http://www.kiska.net/opencobol/1.1/opencobol-1.1-win-vb-win32-bin.zip
not an installer. It contains a directory tree and does not install
like any Windows package.
>
> and here more for the g.win systems:
>
> http://opencobol.add1tocobol.com/gnucobol/#are-there-pre-built-gnu-cobol-pa
> ckages
compiled binaries. There is more required than just "cobc".
>
> No doubt there are more but its getting late.
>
> Take your pick ....
Pete Dashwood
May 7, 2014, 11:21:14 AM5/7/14
to
Bill Gunshannon wrote:
> In article <bstc74...@mid.individual.net>,
<snip>>
cases. Hence, most businesses don't use it.
<snip>>>
from dealing with actual real-world applications. The only good thing about
beating your head against a wall is that it's nice when you stop... :-)
>>>
>>> Well, guess I am just confused then. We pay a sizable fee to be
>>> MSDNAA members inorder to get Visual Studio and to my knowledge,
>>> this does not include things like COBOL and Fortran, they are
>>> separately licensable (and I expect sold) products. We do get all
>>> the OSes, though. :-)
>>
>> MSDN membership is an excellent option if you can afford it, as it
>> gives you virtually any MS software you want (or have ever wanted...
>> :-)).
>
> We are MSDNAA, not the same thing as MSDN. We get OSes and
> development tools, no Office products at all. Well, except for
> Project and Visio
> which I guess they consider development tools, too.
Sorry, I never heard of MSDNAA which I imagine is something like MSDN for
Academics?
(at their own expense) or taking advantage of some of the MS business
schemes I outlined, or even just downloading their own Express version of
the .NET development software they wanted?
>>
>> But even without such a scheme, you can still use all the free stuff
>> for .NET, including Visual Studio and the .NET languages (Express
>> Vesions).
>>
>> Don't think for one minute that the Express versions are "nobbled" or
>> limited. They are not. But the Professional (licensed) version of VS
>> offers additional tools and facilities that can be useful. (You can
>> always get the same functionality without the full version, but you
>> have to do more work...)
>
> I'll have to make sure the students know that. They can get the stuff
> we have under MSDNAA but the same rules apply to them. Academic use
> only.
Maybe they might use the MSDNAA version as an introduction to get a toe in
the water, then download their own copy if they like it and want to do
something they can sell.
>
>>>
<snip>>>
the CLI generating COBOL compiler for .NET development from Micro Focus.
This corresponds with the Fujitsu "NetCOBOL for .NET" which is also a CLI
generating COBOL compiler. (This is the worst name for a software product I
have ever seen and leads to a good degree of confusion when discussing COBOL
strategies).
Both of these compilers can interoperate with CLI generating compilers
(free) from Microsoft (C#, VB.NET, C++). .NET is the level playing field we
have been waiting for COBOL to be able to play on for decades.
Sadly, the point that was missed by most people, (and certainly never
suggested by either Micro Focus or Fujitsu) is that neither of these
compilers are necessary in order to move your existing COBOL (native code
generating) assets into the .NET environment. As part of the .NET Framework,
MS provide a facility called Interop Services which is designed to let
legacy native code (not just from COBOL but also from other languages)
execute in the .NET environment. (And it means your COBOL can interact with
(call and be called by) other .NET components written in any of the .NET
languages.)
If your long term plan is to move away from COBOL development, you don't
really want to be buying a very expensive CLI generating COBOL compiler,
especially when there is absolutely no need to...
Current COBOL vendors DO want you to make that investment so they don't
mention Interop Services in their literature.
The PRIMA solution DOES use Interop Services and means you DON'T have to buy
a .NET COBOL compiler.
I believe that Open COBOL could also use Interop Services (definitely could
if it supported COM) and that is why I'd have no problem using it for our
clients, if it supported objects and COM..
>As a side
> note, I
> thought MS still had a COBOL and Fortran product but that they did not
> come as a part of the Base Studio Package.
I haven't seen such products with a MS badge.
Visual studio initially supported the .NET languages, but is now (VS2013)
extended to also support Javascript and XAML for cross platform mobile and
tablet development. (C# also works across mobile and tablet devices - I
haven't tried using C++ or VB.NET)
doesn't suddenly stop...
>
<snip>
> I like Virtual machines and we use them extensively for development
>> and testing at PRIMA. Historically, we used ORACLE Virtual Box and
used VirtualBox for around 4 years (since ORACLE took it over) in our
production environments, running under Win XP, Win 7 and Win 8.1. It is a
truly essential part of the PRIMA development environment. (VM testing is
part of our SOP before we do deployment builds). It has never failed and we
have never had to "hack it" in any way. Works right out of the box for us. I
regularly clone VMs, assigning new GUIDs to them, (in fact I wrote a Windows
application to do it easily and have given it to a number of people). I
suspect Hyper-V may be more "industrial strength" but until Virtual Box lets
us down, I'm staying with it.
>
>
<snip>
have successfully migrated PR1ME users to .NET in the past.
>
<snip>
> In article <bstc74...@mid.individual.net>,
<snip>>
> OK. That's another potential problem with Open Source. 5 of those 8
> items have nothing to do with a COBOL compiler and, if available at
> all, would
> be the responsibility of different people/groups. Of course, the
> posibility of someone putting together a package of all of it and
> offering package support exists, but I expect there would need to be
> a business case first.
>
Open Source, generally, in my experience, is not concerned with business
> items have nothing to do with a COBOL compiler and, if available at
> all, would
> be the responsibility of different people/groups. Of course, the
> posibility of someone putting together a package of all of it and
> offering package support exists, but I expect there would need to be
> a business case first.
>
cases. Hence, most businesses don't use it.
<snip>>>
>> Based on experiences related here, I wouldn't be encouraged to do so
>> at the moment.
>
> Well, as I said, I'm a geek. And we tend to enjoy beating our heads
> against the wall on a computer problem. :-)
>
Not having the luxury of working in Acadaemia, I get enough head beating
>> at the moment.
>
> Well, as I said, I'm a geek. And we tend to enjoy beating our heads
> against the wall on a computer problem. :-)
>
from dealing with actual real-world applications. The only good thing about
beating your head against a wall is that it's nice when you stop... :-)
>>>
>>> Well, guess I am just confused then. We pay a sizable fee to be
>>> MSDNAA members inorder to get Visual Studio and to my knowledge,
>>> this does not include things like COBOL and Fortran, they are
>>> separately licensable (and I expect sold) products. We do get all
>>> the OSes, though. :-)
>>
>> MSDN membership is an excellent option if you can afford it, as it
>> gives you virtually any MS software you want (or have ever wanted...
>> :-)).
>
> We are MSDNAA, not the same thing as MSDN. We get OSes and
> development tools, no Office products at all. Well, except for
> Project and Visio
> which I guess they consider development tools, too.
Academics?
>
> Once again, we are MSDNAA, different animal. We are expressly
> prohibited from using any of the MS products we get from the program
> for any kind of production. Strictly academic use.
>
But presumabbly there is nothing to stop an individual signing up for MSDN
> Once again, we are MSDNAA, different animal. We are expressly
> prohibited from using any of the MS products we get from the program
> for any kind of production. Strictly academic use.
>
(at their own expense) or taking advantage of some of the MS business
schemes I outlined, or even just downloading their own Express version of
the .NET development software they wanted?
>>
>> But even without such a scheme, you can still use all the free stuff
>> for .NET, including Visual Studio and the .NET languages (Express
>> Vesions).
>>
>> Don't think for one minute that the Express versions are "nobbled" or
>> limited. They are not. But the Professional (licensed) version of VS
>> offers additional tools and facilities that can be useful. (You can
>> always get the same functionality without the full version, but you
>> have to do more work...)
>
> I'll have to make sure the students know that. They can get the stuff
> we have under MSDNAA but the same rules apply to them. Academic use
> only.
the water, then download their own copy if they like it and want to do
something they can sell.
>
>>>
<snip>>>
>> I am not familiar with a MS COBOL (apart from the one they bought
>> from Micro Focus and rebadged many years ago. I understood that was
>> long gone, but I could be wrong about that)
>
> Guess I got confused again. I thought you were talking about MS
> Visual COBOL but you must mean some Micro Focus product.
As far as I am aware there has never been a MS Visual COBOL. Visual COBOL is
>> from Micro Focus and rebadged many years ago. I understood that was
>> long gone, but I could be wrong about that)
>
> Guess I got confused again. I thought you were talking about MS
> Visual COBOL but you must mean some Micro Focus product.
the CLI generating COBOL compiler for .NET development from Micro Focus.
This corresponds with the Fujitsu "NetCOBOL for .NET" which is also a CLI
generating COBOL compiler. (This is the worst name for a software product I
have ever seen and leads to a good degree of confusion when discussing COBOL
strategies).
Both of these compilers can interoperate with CLI generating compilers
(free) from Microsoft (C#, VB.NET, C++). .NET is the level playing field we
have been waiting for COBOL to be able to play on for decades.
Sadly, the point that was missed by most people, (and certainly never
suggested by either Micro Focus or Fujitsu) is that neither of these
compilers are necessary in order to move your existing COBOL (native code
generating) assets into the .NET environment. As part of the .NET Framework,
MS provide a facility called Interop Services which is designed to let
legacy native code (not just from COBOL but also from other languages)
execute in the .NET environment. (And it means your COBOL can interact with
(call and be called by) other .NET components written in any of the .NET
languages.)
If your long term plan is to move away from COBOL development, you don't
really want to be buying a very expensive CLI generating COBOL compiler,
especially when there is absolutely no need to...
Current COBOL vendors DO want you to make that investment so they don't
mention Interop Services in their literature.
The PRIMA solution DOES use Interop Services and means you DON'T have to buy
a .NET COBOL compiler.
I believe that Open COBOL could also use Interop Services (definitely could
if it supported COM) and that is why I'd have no problem using it for our
clients, if it supported objects and COM..
>As a side
> note, I
> thought MS still had a COBOL and Fortran product but that they did not
> come as a part of the Base Studio Package.
Visual studio initially supported the .NET languages, but is now (VS2013)
extended to also support Javascript and XAML for cross platform mobile and
tablet development. (C# also works across mobile and tablet devices - I
haven't tried using C++ or VB.NET)
>
>>>
>>>>
>>>> One of the factors that drove me away from COBOL was that I wanted
>>>> .NET and the early .NET COBOLs were very expensive. (Some would
>>>> argue that they are still way too expensive, and if you factor in
>>>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>>>> small software houses and independent developers.)
>>>>
>>>> I wanted .NET but the COBOL route to it was costly. The realization
>>>> soon dawned that I could get there FOR FREE if I simply changed the
>>>> development language.
>>>
>>> OK, now I am confused again. Is it free or not?
>>
>> Yes, it is free. I gave you the link; read it again, especially the
>> terms and conditions. You can use the MS languages for .NET for
>> COMMERCIAL development, for free.
>>
>> It has ALWAYS been that way and they don't look like they are about
>> to change it.
>>
>> I remember dire warnings from people here when I first suggested
>> this might be a good route to go... ("Microsoft will suck you in
>> then they'll charge a fee" etc)
>
> No, they would never do that. Oh wait, that is exactly the way
> Office is going to work now. :-)
You don't HAVE to subscribe to Office 360... (I'm not...) Office 2007+
>>>
>>>>
>>>> One of the factors that drove me away from COBOL was that I wanted
>>>> .NET and the early .NET COBOLs were very expensive. (Some would
>>>> argue that they are still way too expensive, and if you factor in
>>>> Run Time Licensing for Micro Focus, it becomes non-viable for many
>>>> small software houses and independent developers.)
>>>>
>>>> I wanted .NET but the COBOL route to it was costly. The realization
>>>> soon dawned that I could get there FOR FREE if I simply changed the
>>>> development language.
>>>
>>> OK, now I am confused again. Is it free or not?
>>
>> Yes, it is free. I gave you the link; read it again, especially the
>> terms and conditions. You can use the MS languages for .NET for
>> COMMERCIAL development, for free.
>>
>> It has ALWAYS been that way and they don't look like they are about
>> to change it.
>>
>> I remember dire warnings from people here when I first suggested
>> this might be a good route to go... ("Microsoft will suck you in
>> then they'll charge a fee" etc)
>
> No, they would never do that. Oh wait, that is exactly the way
> Office is going to work now. :-)
doesn't suddenly stop...
>
<snip>
>>
>> Support for the .NET framework is built into all modern versions of
>> Windows. In effect, the run time for the .NET languages is paid for
>> when you (or someone) buy the OS.
>>
>> It is a very good and fair model which happens to favour developers.
>>>
<snip>
>> Support for the .NET framework is built into all modern versions of
>> Windows. In effect, the run time for the .NET languages is paid for
>> when you (or someone) buy the OS.
>>
>> It is a very good and fair model which happens to favour developers.
>>>
> I like Virtual machines and we use them extensively for development
>> it has continued to meet our needs so I have not made a switch to
>> Hyper-V... yet.
>
> I just looked at VirtualBox again at home. It still has one major
> flaw
> that makes it unusable in a production environment without using
> separate hacks from other vendors and that is not how I build
> production environments.
Really? I'd be very interested to know what you think that "flaw" is. We've
>> Hyper-V... yet.
>
> I just looked at VirtualBox again at home. It still has one major
> flaw
> that makes it unusable in a production environment without using
> separate hacks from other vendors and that is not how I build
> production environments.
used VirtualBox for around 4 years (since ORACLE took it over) in our
production environments, running under Win XP, Win 7 and Win 8.1. It is a
truly essential part of the PRIMA development environment. (VM testing is
part of our SOP before we do deployment builds). It has never failed and we
have never had to "hack it" in any way. Works right out of the box for us. I
regularly clone VMs, assigning new GUIDs to them, (in fact I wrote a Windows
application to do it easily and have given it to a number of people). I
suspect Hyper-V may be more "industrial strength" but until Virtual Box lets
us down, I'm staying with it.
>
>
<snip>
>> I like Micro Focus as a company and have always enjoyed a good
>> relationship with them, but the Fujitsu COBOL product, in my
>> opinion, is better. Micro Focus needs lower level work and, although
>> many people enjoy that, for myself, I want an easy life. I need to
>> spend my time and energy solving application problems and not
>> grappling with development configurations. When people come to us
>> for migration now, the first thing we do is convert their existing
>> COBOL to Fujitsu (at no cost to them). It provides a standard
>> baseline for dialects like PR1ME and RM COBOL.
>
> PR1ME, Ohmygod!!! You actually know what that is! Just out of
> curiosity, do you know many people down there still running 50-series
> machines?
No. We have no PR1ME clients in this part of the world, at the moment. We
>> relationship with them, but the Fujitsu COBOL product, in my
>> opinion, is better. Micro Focus needs lower level work and, although
>> many people enjoy that, for myself, I want an easy life. I need to
>> spend my time and energy solving application problems and not
>> grappling with development configurations. When people come to us
>> for migration now, the first thing we do is convert their existing
>> COBOL to Fujitsu (at no cost to them). It provides a standard
>> baseline for dialects like PR1ME and RM COBOL.
>
> PR1ME, Ohmygod!!! You actually know what that is! Just out of
> curiosity, do you know many people down there still running 50-series
> machines?
have successfully migrated PR1ME users to .NET in the past.
>
<snip>
Bill Gunshannon
May 7, 2014, 11:57:17 AM5/7/14
to
In article <bsv1as...@mid.individual.net>,
>
> <snip>>>
>>> Based on experiences related here, I wouldn't be encouraged to do so
>>> at the moment.
>>
>> Well, as I said, I'm a geek. And we tend to enjoy beating our heads
>> against the wall on a computer problem. :-)
>>
> Not having the luxury of working in Acadaemia, I get enough head beating
> from dealing with actual real-world applications.
Not all working in Academia is "luxury". I have production systems that
must be up 24/7. Academics have deadlines, too. :-)
> The only good thing about
> beating your head against a wall is that it's nice when you stop... :-)
Exactly...
>
>
>>>>
>>>> Well, guess I am just confused then. We pay a sizable fee to be
>>>> MSDNAA members inorder to get Visual Studio and to my knowledge,
>>>> this does not include things like COBOL and Fortran, they are
>>>> separately licensable (and I expect sold) products. We do get all
>>>> the OSes, though. :-)
>>>
>>> MSDN membership is an excellent option if you can afford it, as it
>>> gives you virtually any MS software you want (or have ever wanted...
>>> :-)).
>>
>> We are MSDNAA, not the same thing as MSDN. We get OSes and
>> development tools, no Office products at all. Well, except for
>> Project and Visio
>> which I guess they consider development tools, too.
>
> Sorry, I never heard of MSDNAA which I imagine is something like MSDN for
> Academics?
Academic Alliance
>>
>> Once again, we are MSDNAA, different animal. We are expressly
>> prohibited from using any of the MS products we get from the program
>> for any kind of production. Strictly academic use.
>>
>
> But presumabbly there is nothing to stop an individual signing up for MSDN
> (at their own expense) or taking advantage of some of the MS business
> schemes I outlined, or even just downloading their own Express version of
> the .NET development software they wanted?
>
Thus the reason I mentioned telling students. Sounds like a better deal
than they get from MSDNAA.
>
>
>>>
>>> But even without such a scheme, you can still use all the free stuff
>>> for .NET, including Visual Studio and the .NET languages (Express
>>> Vesions).
>>>
>>> Don't think for one minute that the Express versions are "nobbled" or
>>> limited. They are not. But the Professional (licensed) version of VS
>>> offers additional tools and facilities that can be useful. (You can
>>> always get the same functionality without the full version, but you
>>> have to do more work...)
>>
>> I'll have to make sure the students know that. They can get the stuff
>> we have under MSDNAA but the same rules apply to them. Academic use
>> only.
>
> Maybe they might use the MSDNAA version as an introduction to get a toe in
> the water, then download their own copy if they like it and want to do
> something they can sell.
Wel, they can get copies of all this tuff thru MSDNAA. But it seems like
the restrictions might be harsher.
>>
>>>>
> <snip>>>
>>> I am not familiar with a MS COBOL (apart from the one they bought
>>> from Micro Focus and rebadged many years ago. I understood that was
>>> long gone, but I could be wrong about that)
>>
>> Guess I got confused again. I thought you were talking about MS
>> Visual COBOL but you must mean some Micro Focus product.
>
> As far as I am aware there has never been a MS Visual COBOL. Visual COBOL is
> the CLI generating COBOL compiler for .NET development from Micro Focus.
All my Micro Focus was on AIX. Maybe I will take a look at this. But
I do really want to get GNU COBOL working.
>
> This corresponds with the Fujitsu "NetCOBOL for .NET" which is also a CLI
> generating COBOL compiler. (This is the worst name for a software product I
> have ever seen and leads to a good degree of confusion when discussing COBOL
> strategies).
>
> Both of these compilers can interoperate with CLI generating compilers
> (free) from Microsoft (C#, VB.NET, C++). .NET is the level playing field we
> have been waiting for COBOL to be able to play on for decades.
Hmmm... maybe a target for GNU COBOL. :-)
>
> Sadly, the point that was missed by most people, (and certainly never
> suggested by either Micro Focus or Fujitsu) is that neither of these
> compilers are necessary in order to move your existing COBOL (native code
> generating) assets into the .NET environment. As part of the .NET Framework,
> MS provide a facility called Interop Services which is designed to let
> legacy native code (not just from COBOL but also from other languages)
> execute in the .NET environment. (And it means your COBOL can interact with
> (call and be called by) other .NET components written in any of the .NET
> languages.)
Well, under ideal conditions the same would be true of GNU COBOL. Static
linked programs require no runtime. And getting back to my PostgrSQL
library work, I (theoretically) can compile it into a DLL that has no
external requirements and I can distribute it with any number of COBOL
compiled binaries that will use it.
>
> If your long term plan is to move away from COBOL development, you don't
> really want to be buying a very expensive CLI generating COBOL compiler,
> especially when there is absolutely no need to...
You are once again assuming everyone is moving away from COBOL. In the
past month I have read about more than a dozen large COBOL installations
that have no such plans in the foreseeable future and continue to develop
new code in COBOL as well. I see an Open Source COBOL with the necessary
support libraries (like the one I am working on) as offering an opportunity
to reduce costs without the, often overwhelming, cost and risk of writting
everything anew in something like Java or C#. In its current state GNU
COBOL could easily be used to replace Micro Focus at that last gig I did.
And I have no doubt that PostgreSQL could replace their Oracle database.
Base platform was AIX. Take your pick at a replacement for that one.
Neither did Office 98 but I can't see any business still being on it.
MS is well known for introducing incompatabilites to force upgrades.
I don't see this as being any different. When your business model is
keeping a constantly moving target for the customer to hit, you don't
survive long it you anchor the product.
How do you egt all your virtual machines to start back up on a reboot,
power fail or anything else that causes VirtualBox to stop?
>>
>>
> <snip>
>>> I like Micro Focus as a company and have always enjoyed a good
>>> relationship with them, but the Fujitsu COBOL product, in my
>>> opinion, is better. Micro Focus needs lower level work and, although
>>> many people enjoy that, for myself, I want an easy life. I need to
>>> spend my time and energy solving application problems and not
>>> grappling with development configurations. When people come to us
>>> for migration now, the first thing we do is convert their existing
>>> COBOL to Fujitsu (at no cost to them). It provides a standard
>>> baseline for dialects like PR1ME and RM COBOL.
>>
>> PR1ME, Ohmygod!!! You actually know what that is! Just out of
>> curiosity, do you know many people down there still running 50-series
>> machines?
>
> No. We have no PR1ME clients in this part of the world, at the moment. We
> have successfully migrated PR1ME users to .NET in the past.
I always liked working with PR1MEs. Another company that shot itself
in the foot.
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
>> In article <bstc74...@mid.individual.net>,
> <snip>>
>> OK. That's another potential problem with Open Source. 5 of those 8
>> items have nothing to do with a COBOL compiler and, if available at
>> all, would
>> be the responsibility of different people/groups. Of course, the
>> posibility of someone putting together a package of all of it and
>> offering package support exists, but I expect there would need to be
>> a business case first.
>>
>
> Open Source, generally, in my experience, is not concerned with business
> cases. Hence, most businesses don't use it.
Linux?
> Bill Gunshannon wrote:
>> In article <bstc74...@mid.individual.net>,
> <snip>>
>> OK. That's another potential problem with Open Source. 5 of those 8
>> items have nothing to do with a COBOL compiler and, if available at
>> all, would
>> be the responsibility of different people/groups. Of course, the
>> posibility of someone putting together a package of all of it and
>> offering package support exists, but I expect there would need to be
>> a business case first.
>>
>
> Open Source, generally, in my experience, is not concerned with business
> cases. Hence, most businesses don't use it.
>
> <snip>>>
>>> Based on experiences related here, I wouldn't be encouraged to do so
>>> at the moment.
>>
>> Well, as I said, I'm a geek. And we tend to enjoy beating our heads
>> against the wall on a computer problem. :-)
>>
> Not having the luxury of working in Acadaemia, I get enough head beating
> from dealing with actual real-world applications.
must be up 24/7. Academics have deadlines, too. :-)
> The only good thing about
> beating your head against a wall is that it's nice when you stop... :-)
>
>
>>>>
>>>> Well, guess I am just confused then. We pay a sizable fee to be
>>>> MSDNAA members inorder to get Visual Studio and to my knowledge,
>>>> this does not include things like COBOL and Fortran, they are
>>>> separately licensable (and I expect sold) products. We do get all
>>>> the OSes, though. :-)
>>>
>>> MSDN membership is an excellent option if you can afford it, as it
>>> gives you virtually any MS software you want (or have ever wanted...
>>> :-)).
>>
>> We are MSDNAA, not the same thing as MSDN. We get OSes and
>> development tools, no Office products at all. Well, except for
>> Project and Visio
>> which I guess they consider development tools, too.
>
> Sorry, I never heard of MSDNAA which I imagine is something like MSDN for
> Academics?
>>
>> Once again, we are MSDNAA, different animal. We are expressly
>> prohibited from using any of the MS products we get from the program
>> for any kind of production. Strictly academic use.
>>
>
> But presumabbly there is nothing to stop an individual signing up for MSDN
> (at their own expense) or taking advantage of some of the MS business
> schemes I outlined, or even just downloading their own Express version of
> the .NET development software they wanted?
>
than they get from MSDNAA.
>
>
>>>
>>> But even without such a scheme, you can still use all the free stuff
>>> for .NET, including Visual Studio and the .NET languages (Express
>>> Vesions).
>>>
>>> Don't think for one minute that the Express versions are "nobbled" or
>>> limited. They are not. But the Professional (licensed) version of VS
>>> offers additional tools and facilities that can be useful. (You can
>>> always get the same functionality without the full version, but you
>>> have to do more work...)
>>
>> I'll have to make sure the students know that. They can get the stuff
>> we have under MSDNAA but the same rules apply to them. Academic use
>> only.
>
> Maybe they might use the MSDNAA version as an introduction to get a toe in
> the water, then download their own copy if they like it and want to do
> something they can sell.
the restrictions might be harsher.
>>
>>>>
> <snip>>>
>>> I am not familiar with a MS COBOL (apart from the one they bought
>>> from Micro Focus and rebadged many years ago. I understood that was
>>> long gone, but I could be wrong about that)
>>
>> Guess I got confused again. I thought you were talking about MS
>> Visual COBOL but you must mean some Micro Focus product.
>
> As far as I am aware there has never been a MS Visual COBOL. Visual COBOL is
> the CLI generating COBOL compiler for .NET development from Micro Focus.
I do really want to get GNU COBOL working.
>
> This corresponds with the Fujitsu "NetCOBOL for .NET" which is also a CLI
> generating COBOL compiler. (This is the worst name for a software product I
> have ever seen and leads to a good degree of confusion when discussing COBOL
> strategies).
>
> Both of these compilers can interoperate with CLI generating compilers
> (free) from Microsoft (C#, VB.NET, C++). .NET is the level playing field we
> have been waiting for COBOL to be able to play on for decades.
>
> Sadly, the point that was missed by most people, (and certainly never
> suggested by either Micro Focus or Fujitsu) is that neither of these
> compilers are necessary in order to move your existing COBOL (native code
> generating) assets into the .NET environment. As part of the .NET Framework,
> MS provide a facility called Interop Services which is designed to let
> legacy native code (not just from COBOL but also from other languages)
> execute in the .NET environment. (And it means your COBOL can interact with
> (call and be called by) other .NET components written in any of the .NET
> languages.)
linked programs require no runtime. And getting back to my PostgrSQL
library work, I (theoretically) can compile it into a DLL that has no
external requirements and I can distribute it with any number of COBOL
compiled binaries that will use it.
>
> If your long term plan is to move away from COBOL development, you don't
> really want to be buying a very expensive CLI generating COBOL compiler,
> especially when there is absolutely no need to...
past month I have read about more than a dozen large COBOL installations
that have no such plans in the foreseeable future and continue to develop
new code in COBOL as well. I see an Open Source COBOL with the necessary
support libraries (like the one I am working on) as offering an opportunity
to reduce costs without the, often overwhelming, cost and risk of writting
everything anew in something like Java or C#. In its current state GNU
COBOL could easily be used to replace Micro Focus at that last gig I did.
And I have no doubt that PostgreSQL could replace their Oracle database.
Base platform was AIX. Take your pick at a replacement for that one.
MS is well known for introducing incompatabilites to force upgrades.
I don't see this as being any different. When your business model is
keeping a constantly moving target for the customer to hit, you don't
survive long it you anchor the product.
power fail or anything else that causes VirtualBox to stop?
>>
>>
> <snip>
>>> I like Micro Focus as a company and have always enjoyed a good
>>> relationship with them, but the Fujitsu COBOL product, in my
>>> opinion, is better. Micro Focus needs lower level work and, although
>>> many people enjoy that, for myself, I want an easy life. I need to
>>> spend my time and energy solving application problems and not
>>> grappling with development configurations. When people come to us
>>> for migration now, the first thing we do is convert their existing
>>> COBOL to Fujitsu (at no cost to them). It provides a standard
>>> baseline for dialects like PR1ME and RM COBOL.
>>
>> PR1ME, Ohmygod!!! You actually know what that is! Just out of
>> curiosity, do you know many people down there still running 50-series
>> machines?
>
> No. We have no PR1ME clients in this part of the world, at the moment. We
> have successfully migrated PR1ME users to .NET in the past.
in the foot.
Pete Dashwood
May 7, 2014, 1:05:23 PM5/7/14
to
Bill Gunshannon wrote:
>> Open Source, generally, in my experience, is not concerned with
>> business cases. Hence, most businesses don't use it.
>
> Linux?
Oh yes, it has 1.58% of desktop and laptop machines.
>> Open Source, generally, in my experience, is not concerned with
>> business cases. Hence, most businesses don't use it.
>
> Linux?
MOST businesses... :-)
You know, the REAL world where over 85% of the machines are running
Windows...?
(http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
>
>>
>> <snip>>>
<snip>>>
>> Sorry, I never heard of MSDNAA which I imagine is something like
>> MSDN for Academics?
>
> Academic Alliance
>
OK
>> MSDN for Academics?
>
> Academic Alliance
>
>> <snip>>>
>>>> I am not familiar with a MS COBOL (apart from the one they bought
>>>> from Micro Focus and rebadged many years ago. I understood that was
>>>> long gone, but I could be wrong about that)
>>>
>>> Guess I got confused again. I thought you were talking about MS
>>> Visual COBOL but you must mean some Micro Focus product.
>>
>> As far as I am aware there has never been a MS Visual COBOL. Visual
>> COBOL is the CLI generating COBOL compiler for .NET development from
>> Micro Focus.
>
> All my Micro Focus was on AIX. Maybe I will take a look at this. But
> I do really want to get GNU COBOL working.
>
I deal every day with people who want to modernize their COBOL and continue
using it, as well as people who want to move on from it. (The latter
category are the majority)
However, I don't think you would argue that general use of COBOL (at least
in the sense it was used in the last century), has NOT declined. and is NOT
continuing to do so.
This issue is covered very well (and fairly) here:
http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
When it comes to the decline of COBOL I don't have to "assume" everybody is
moving moving off it; it is a matter of record that many people are.
> In
> the past month I have read about more than a dozen large COBOL
> installations that have no such plans in the foreseeable future and
> continue to develop new code in COBOL as well.
have no intention of perpetuating development in COBOL and will get off it
as soon as it is practicable to do so, if they have not already done so.
>I see an Open Source
> COBOL with the necessary support libraries (like the one I am working
> on) as offering an opportunity to reduce costs without the, often
> overwhelming, cost and risk of writting everything anew in something
> like Java or C#.
option is to rewrite in Java or C#? COBOL can be phased out gently without
having to rewrite anything in a hurry. Existing COBOL can run for as long as
you want it to, but new development can be in the new languages. Frameworks
like .NET and MONO allow this to happen painlessly and seamlessly because
"old" and "new" can run together and share information.
>In its current state GNU COBOL could easily be used
> to replace Micro Focus at that last gig I did. And I have no doubt
> that PostgreSQL could replace their Oracle database. Base platform
> was AIX. Take your pick at a replacement for that one.
Why do you suppose they don't WANT to replace their ORACLE DB with
PostgreSQL?
>
>>
>> Current COBOL vendors DO want you to make that investment so they
>> don't mention Interop Services in their literature.
>>
>> The PRIMA solution DOES use Interop Services and means you DON'T
>> have to buy a .NET COBOL compiler.
>>
>> I believe that Open COBOL could also use Interop Services
>> (definitely could if it supported COM) and that is why I'd have no
>> problem using it for our clients, if it supported objects and COM..
>>
>> You don't HAVE to subscribe to Office 360... (I'm not...) Office
>> 2007+ doesn't suddenly stop...
>
> Neither did Office 98 but I can't see any business still being on it.
Not the same thing at all. There is no COMPULSION to upgrade and the
>> 2007+ doesn't suddenly stop...
>
> Neither did Office 98 but I can't see any business still being on it.
existing version doesn't stop working. Haven't seen everybody suddenly rush
to get off XP because it is no longer officially supported. They'll move
when they're ready.
> MS is well known for introducing incompatabilites to force upgrades.
Cite your evidence or retract it.
> I don't see this as being any different. When your business model is
> keeping a constantly moving target for the customer to hit, you don't
> survive long it you anchor the product.
hardship to start them from the Virtual Box console, but if I needed to have
certain machines always available I'd write a simple startup script. Check
if the machine is running and visible on the LAN and start and map it if it
isn't. It isn't rocket science. Configure it through the Registry with the
machines you always want to run. Very simple using WSH. (A shell EXEC, a
ping, and a NET USE with a registry fetch...)
<snip>>
> I always liked working with PR1MEs. Another company that shot itself
> in the foot.
I don't know. Never used them myself, but the COBOL was '85 compliant.
> in the foot.
Bill Gunshannon
May 7, 2014, 1:57:34 PM5/7/14
to
In article <bsv7e4...@mid.individual.net>,
Some very large operations have and are moving to Linux. When IBM
sells a z-System that is primarily providing virtual Linux systems
what do the stats say?
NYSE recently moved to Linux. More do everyday. RedHat isn't in business
because no one wants to buy it. :-) Of course, whenever you throw desktops
into the picture everything other than MicroSoft comes out as just a bit
player. And, of course, they now include cell phones in that stat. Oh
wait. You got that on Wikipedia. Then it must be true and accurate. :-)
And i read every day about yet another extremely large COBOL operation
over here that gets pushed in the direction of "modernization" (like
that is somehow a silver bullet for business) that finds upon actually
looking at it that a) it would be expensive, b) it would be time and labor
intensive, c) it would be very risky from a business standpoint and lastly
d) it is totally unneccessary. Too bad there are no statistics about how
many companies were ruined by being forced into this strategy by some
MBA with no real knowledge of business.
>
> However, I don't think you would argue that general use of COBOL (at least
> in the sense it was used in the last century), has NOT declined. and is NOT
> continuing to do so.
Wait, is this a typo? You highlighted "NOT". That is my standpoint. I
have long said it is not COBOL that is being reduced it is all the
new stuff that is being written in other languages that has reduced the
percentage. Even with the new development in COBOL, the development
for cell phones, smart TV's, car computers and all the other things
that have been foisted on the public is bound to be overwhelming.
But places like the IRS and Social Security, Banks, Insurance Companies,
Credit Card Companies and Hospitals still have and will continue to use
millions if not billions of lines of COBOL.
>
> This issue is covered very well (and fairly) here:
>
> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>
> When it comes to the decline of COBOL I don't have to "assume" everybody is
> moving moving off it; it is a matter of record that many people are.
OK, I read it. Hogwash. Well, maybe not in NZ, but over here. Even
my students discovered this (all on their own, not with any push from
me). There are COBOL jobs advertised over here every day. I saw two
just this morning. Long term, good paying. No wait, three. I put in
for one myself. But I doubt my wife will be willing to move. :-)
My guess would be only the smallest operations are actually replacing
their COBOL. Places with millions of lines of COBOL are just not going
to chaneg it without a real good reason and so far, this reason has not
reared its ugly head. At least, not over here. And this with people
both in business and academia doing their damndest to make it happen.
>
>
>> In
>> the past month I have read about more than a dozen large COBOL
>> installations that have no such plans in the foreseeable future and
>> continue to develop new code in COBOL as well.
>
> That would be fine if it weren't for the thousands of installations that
> have no intention of perpetuating development in COBOL and will get off it
> as soon as it is practicable to do so, if they have not already done so.
I keep hearing about these but never see any names. I can provide
(and have provided in the past) names of large operations that are not
moving now and have no plans to do so in the future.
>
>
>>I see an Open Source
>> COBOL with the necessary support libraries (like the one I am working
>> on) as offering an opportunity to reduce costs without the, often
>> overwhelming, cost and risk of writting everything anew in something
>> like Java or C#.
>
> Now it is you who is assuming. What makes you think that the only other
> option is to rewrite in Java or C#? COBOL can be phased out gently without
> having to rewrite anything in a hurry. Existing COBOL can run for as long as
> you want it to, but new development can be in the new languages. Frameworks
> like .NET and MONO allow this to happen painlessly and seamlessly because
> "old" and "new" can run together and share information.
Well, that is what I have seen. Other languages are being used to write
things like User Interfaces but the bulk of the work is done by the ever
invisible COBOL. So, you seem to be agreeing with me again. COBOL is
going nowhere. New stuff that was never done with COBOL (and for which
COBOL was not designed) is being done in other languages. But that would
mean the amount of COBOL is not declining. It may not be increasing at
much of a rate (It is increasing as I have read numerous articles by
people who are doing new COBOL development) but, at least in the big shops
(where 85% of the real work is being done :-) COBOL is still the breadwinner.
>
>>In its current state GNU COBOL could easily be used
>> to replace Micro Focus at that last gig I did. And I have no doubt
>> that PostgreSQL could replace their Oracle database. Base platform
>> was AIX. Take your pick at a replacement for that one.
>
> Why do you suppose the Micro Focus ISN'T being replaced by GNU COBOL?
Why isn't Windows 8 being replaced by K Linux Desktops? Why isn't
Microsoft Office being replaced by LibreOffice?
>
> Why do you suppose they don't WANT to replace their ORACLE DB with
> PostgreSQL?
Because in all these case the people who make the decisions respond
more to the drone of the salesman than to some blog. No one is out
there selling Linux, LibreOffice or PostgreSQL.
As long as we are throwing URLs around try this one:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
It makes for some very interesting reading. But then, the oracle salesman
isn't goingt o point you at it and the PostgreSQL salesman just never seems
to get that appointment to meet witht he CIO.
>
>>
>>>
>>> Current COBOL vendors DO want you to make that investment so they
>>> don't mention Interop Services in their literature.
>>>
>>> The PRIMA solution DOES use Interop Services and means you DON'T
>>> have to buy a .NET COBOL compiler.
>>>
>>> I believe that Open COBOL could also use Interop Services
>>> (definitely could if it supported COM) and that is why I'd have no
>>> problem using it for our clients, if it supported objects and COM..
>>>
> <snip>
>>> You don't HAVE to subscribe to Office 360... (I'm not...) Office
>>> 2007+ doesn't suddenly stop...
>>
>> Neither did Office 98 but I can't see any business still being on it.
> Not the same thing at all. There is no COMPULSION to upgrade and the
> existing version doesn't stop working. Haven't seen everybody suddenly rush
> to get off XP because it is no longer officially supported. They'll move
> when they're ready.
Well, MS tried to use the recent Explorer flaw to force a move, but that
seems to have backfired and now there is an update for Xp even after we
were assured there would be no such thing. :-)
>
>
>> MS is well known for introducing incompatabilites to force upgrades.
>
> That is simply urban myth and I'd expect better from you.
>
> Cite your evidence or retract it.
Sorry, I didn't document everytime someone came in with an old Word
document that could not be converted by a newer version of Word. I'm
the guy who always had to find a fix. Wasted a lot of time doing it.
And we probably shouldn't even go into the equivalent with versions
of Power Point. But some people will never accept that MS has a very
shady past. Or that they are unlikely to ever change.
>
>> I don't see this as being any different. When your business model is
>> keeping a constantly moving target for the customer to hit, you don't
>> survive long it you anchor the product.
>
> Your paranoia is showing.
Just because your paranoid doesn't mean every one isn't out to get you.
I have about 50 running at the moment. Access to the host machine consoles
from outside of the datacenter is not available and will never be.
> but if I needed to have
> certain machines always available I'd write a simple startup script.
And that was my point exactly. A hack. What should be a major part of
the overall system is not included as part of the product. It is one
thing running this stuff in a room in your home (where I do use VirtualBox)
and quite another in a production envireonment at your place of employement.
> Check
> if the machine is running and visible on the LAN and start and map it if it
> isn't. It isn't rocket science. Configure it through the Registry with the
> machines you always want to run. Very simple using WSH. (A shell EXEC, a
> ping, and a NET USE with a registry fetch...)
All hacks to get around a shortcoming of the product. Nowhere in all their
documentation do they recommend this. And what was it you were saying
about things like Linux and GNU COBOL not being ready for production
environments? :-)
>
> <snip>>
>> I always liked working with PR1MEs. Another company that shot itself
>> in the foot.
>
> I don't know. Never used them myself, but the COBOL was '85 compliant.
I used to maintain the system software (including compilers) on a cluster
and a bunch of standalone PR1MEs. I know they (like COBOL) are actually
still in use here in the US. I gave my home 2250 to the guy who still
maintains both hardware and software for a number of installations.
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
>>> Open Source, generally, in my experience, is not concerned with
>>> business cases. Hence, most businesses don't use it.
>>
>> Linux?
>
> Oh yes, it has 1.58% of desktop and laptop machines.
>
> MOST businesses... :-)
>
> You know, the REAL world where over 85% of the machines are running
> Windows...?
>
> (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
You know what they say about statistics....
> Bill Gunshannon wrote:
>>> Open Source, generally, in my experience, is not concerned with
>>> business cases. Hence, most businesses don't use it.
>>
>> Linux?
>
> Oh yes, it has 1.58% of desktop and laptop machines.
>
> MOST businesses... :-)
>
> You know, the REAL world where over 85% of the machines are running
> Windows...?
>
> (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
Some very large operations have and are moving to Linux. When IBM
sells a z-System that is primarily providing virtual Linux systems
what do the stats say?
NYSE recently moved to Linux. More do everyday. RedHat isn't in business
because no one wants to buy it. :-) Of course, whenever you throw desktops
into the picture everything other than MicroSoft comes out as just a bit
player. And, of course, they now include cell phones in that stat. Oh
wait. You got that on Wikipedia. Then it must be true and accurate. :-)
over here that gets pushed in the direction of "modernization" (like
that is somehow a silver bullet for business) that finds upon actually
looking at it that a) it would be expensive, b) it would be time and labor
intensive, c) it would be very risky from a business standpoint and lastly
d) it is totally unneccessary. Too bad there are no statistics about how
many companies were ruined by being forced into this strategy by some
MBA with no real knowledge of business.
>
> However, I don't think you would argue that general use of COBOL (at least
> in the sense it was used in the last century), has NOT declined. and is NOT
> continuing to do so.
have long said it is not COBOL that is being reduced it is all the
new stuff that is being written in other languages that has reduced the
percentage. Even with the new development in COBOL, the development
for cell phones, smart TV's, car computers and all the other things
that have been foisted on the public is bound to be overwhelming.
But places like the IRS and Social Security, Banks, Insurance Companies,
Credit Card Companies and Hospitals still have and will continue to use
millions if not billions of lines of COBOL.
>
> This issue is covered very well (and fairly) here:
>
> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>
> When it comes to the decline of COBOL I don't have to "assume" everybody is
> moving moving off it; it is a matter of record that many people are.
my students discovered this (all on their own, not with any push from
me). There are COBOL jobs advertised over here every day. I saw two
just this morning. Long term, good paying. No wait, three. I put in
for one myself. But I doubt my wife will be willing to move. :-)
My guess would be only the smallest operations are actually replacing
their COBOL. Places with millions of lines of COBOL are just not going
to chaneg it without a real good reason and so far, this reason has not
reared its ugly head. At least, not over here. And this with people
both in business and academia doing their damndest to make it happen.
>
>
>> In
>> the past month I have read about more than a dozen large COBOL
>> installations that have no such plans in the foreseeable future and
>> continue to develop new code in COBOL as well.
>
> That would be fine if it weren't for the thousands of installations that
> have no intention of perpetuating development in COBOL and will get off it
> as soon as it is practicable to do so, if they have not already done so.
(and have provided in the past) names of large operations that are not
moving now and have no plans to do so in the future.
>
>
>>I see an Open Source
>> COBOL with the necessary support libraries (like the one I am working
>> on) as offering an opportunity to reduce costs without the, often
>> overwhelming, cost and risk of writting everything anew in something
>> like Java or C#.
>
> Now it is you who is assuming. What makes you think that the only other
> option is to rewrite in Java or C#? COBOL can be phased out gently without
> having to rewrite anything in a hurry. Existing COBOL can run for as long as
> you want it to, but new development can be in the new languages. Frameworks
> like .NET and MONO allow this to happen painlessly and seamlessly because
> "old" and "new" can run together and share information.
things like User Interfaces but the bulk of the work is done by the ever
invisible COBOL. So, you seem to be agreeing with me again. COBOL is
going nowhere. New stuff that was never done with COBOL (and for which
COBOL was not designed) is being done in other languages. But that would
mean the amount of COBOL is not declining. It may not be increasing at
much of a rate (It is increasing as I have read numerous articles by
people who are doing new COBOL development) but, at least in the big shops
(where 85% of the real work is being done :-) COBOL is still the breadwinner.
>
>>In its current state GNU COBOL could easily be used
>> to replace Micro Focus at that last gig I did. And I have no doubt
>> that PostgreSQL could replace their Oracle database. Base platform
>> was AIX. Take your pick at a replacement for that one.
>
> Why do you suppose the Micro Focus ISN'T being replaced by GNU COBOL?
Microsoft Office being replaced by LibreOffice?
>
> Why do you suppose they don't WANT to replace their ORACLE DB with
> PostgreSQL?
more to the drone of the salesman than to some blog. No one is out
there selling Linux, LibreOffice or PostgreSQL.
As long as we are throwing URLs around try this one:
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
It makes for some very interesting reading. But then, the oracle salesman
isn't goingt o point you at it and the PostgreSQL salesman just never seems
to get that appointment to meet witht he CIO.
>
>>
>>>
>>> Current COBOL vendors DO want you to make that investment so they
>>> don't mention Interop Services in their literature.
>>>
>>> The PRIMA solution DOES use Interop Services and means you DON'T
>>> have to buy a .NET COBOL compiler.
>>>
>>> I believe that Open COBOL could also use Interop Services
>>> (definitely could if it supported COM) and that is why I'd have no
>>> problem using it for our clients, if it supported objects and COM..
>>>
> <snip>
>>> You don't HAVE to subscribe to Office 360... (I'm not...) Office
>>> 2007+ doesn't suddenly stop...
>>
>> Neither did Office 98 but I can't see any business still being on it.
> Not the same thing at all. There is no COMPULSION to upgrade and the
> existing version doesn't stop working. Haven't seen everybody suddenly rush
> to get off XP because it is no longer officially supported. They'll move
> when they're ready.
seems to have backfired and now there is an update for Xp even after we
were assured there would be no such thing. :-)
>
>
>> MS is well known for introducing incompatabilites to force upgrades.
>
> That is simply urban myth and I'd expect better from you.
>
> Cite your evidence or retract it.
document that could not be converted by a newer version of Word. I'm
the guy who always had to find a fix. Wasted a lot of time doing it.
And we probably shouldn't even go into the equivalent with versions
of Power Point. But some people will never accept that MS has a very
shady past. Or that they are unlikely to ever change.
>
>> I don't see this as being any different. When your business model is
>> keeping a constantly moving target for the customer to hit, you don't
>> survive long it you anchor the product.
>
> Your paranoia is showing.
from outside of the datacenter is not available and will never be.
> but if I needed to have
> certain machines always available I'd write a simple startup script.
the overall system is not included as part of the product. It is one
thing running this stuff in a room in your home (where I do use VirtualBox)
and quite another in a production envireonment at your place of employement.
> Check
> if the machine is running and visible on the LAN and start and map it if it
> isn't. It isn't rocket science. Configure it through the Registry with the
> machines you always want to run. Very simple using WSH. (A shell EXEC, a
> ping, and a NET USE with a registry fetch...)
documentation do they recommend this. And what was it you were saying
about things like Linux and GNU COBOL not being ready for production
environments? :-)
>
> <snip>>
>> I always liked working with PR1MEs. Another company that shot itself
>> in the foot.
>
> I don't know. Never used them myself, but the COBOL was '85 compliant.
and a bunch of standalone PR1MEs. I know they (like COBOL) are actually
still in use here in the US. I gave my home 2250 to the guy who still
maintains both hardware and software for a number of installations.
Clark F Morris
May 7, 2014, 3:07:28 PM5/7/14
to
On Thu, 8 May 2014 05:05:23 +1200, "Pete Dashwood"
<dash...@removethis.enternet.co.nz> wrote:
>Bill Gunshannon wrote:
>>> Open Source, generally, in my experience, is not concerned with
>>> business cases. Hence, most businesses don't use it.
>>
>> Linux?
>
> Oh yes, it has 1.58% of desktop and laptop machines.
>
>MOST businesses... :-)
>
>You know, the REAL world where over 85% of the machines are running
>Windows...?
On the server side, Linux is growing rapidly on various architectures.
<dash...@removethis.enternet.co.nz> wrote:
>Bill Gunshannon wrote:
>>> Open Source, generally, in my experience, is not concerned with
>>> business cases. Hence, most businesses don't use it.
>>
>> Linux?
>
> Oh yes, it has 1.58% of desktop and laptop machines.
>
>MOST businesses... :-)
>
>You know, the REAL world where over 85% of the machines are running
>Windows...?
The Heartbleed bug is in open source software. Public domain add on
software is use in many z series sites (see www.cbttape.org). While I
believe a lot of COBOL and other site written code is being replaced
with packages and packages may well not be written in COBOL, I see a
steady decline in in-house written code. For systems that are
Unix/Linux/Windows based the problem with COBOL is that these
environments do not provide a common record format (as opposed to
stream) i-o and do not have a keyed file system as part of the
operating system services. Just out of curiosity, how are the BUNCH
(Burroughs, Univac, NCR, Control Data, Honeywell) and their European
and Asian counterparts doing these days? I think Honeywell sold out
to Bull. Burroughs and Univac became Unisys. NCR seems to be
basically a data warehouse hardware company. Other than the IBM z and
i series, are there any major non-Unix/Linux/Windows providers out
there?
Clark Morris
Graham Hobbs
May 7, 2014, 4:34:57 PM5/7/14
to
Pete Dashwood
May 9, 2014, 7:04:44 PM5/9/14
to
Bill Gunshannon wrote:
<snip>>>
"postulate".
It is a standard use of English. Perhaps I understimated the education of
someone who works in a University.
> That is my standpoint.
No, it isn't. You continually refuse to accept that COBOL use in the world
in general has declined from the 'glory days" of the 1980s. It is really
stupid to argue this as it is a matter of record. (However, when I show you
the record, you dismiss it as "You can prove anything with statistics".)
<snip>>
You may also find it unpalatable that just because YOU say it is hogwash,
does not make it so...
>>
>>
<snip>
employed by and the stated goals of any given corporation can change in an
instant. Just as quickly as a new IT director is installed.
It is a simple fact that more and more corporations are being forced to trim
their exorbitant IT budgets because the world (and their Boards) is waking
up to the fact that cheaper options are available. It is economic necessity,
not fashion , that drives it. Resistance to change of the kind that you
exhibit is being eroded by economic necessity, not rhetoric from me.
The network is winning the battle for IT hearts and minds and
(consequently) the COBOL fortresses you are so proud of will fall. It is
simply a matter of time.
Personally, I don't care at all; I long ago realized what was happening and
adapted to it. Besides, the pressures which drive it are inexorable. It
really isn't about academics and business people doing their damnedest to
bring down COBOL out of spite or fashion consciousness, but you seem to
think it is.
<snip>>
rest of us are stupid fools who do whatever salespeople tell us?
"The people who make the decisions" are NOT all idiots. Some of them have
broader experience and training than your own.
Sales campaigns certainly do influence, but anyone who has been in IT for
any length of time has learned to be wary of sales pitches and spin. They
want to see benchmarks and demos.
The faculty members who resist teaching COBOL at your place are not
intransigent simple-minded clods.
The Business IT directors who want to move to networked solutions, even if
it means getting out of COBOL, aren't either.
> As long as we are throwing URLs around try this one:
>
> http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
It is interesting, but it needs updating.
What it DOESN'T tell you is that the OS a database runs under is irrelevant
if it is being used as a server... I have remote SQL Server databases
(running on a server farm in the USA) being accessed from both Linux and
Windows systems all around the World; and 20 years ago I was acessing
mainframe (DB2 and Datacomm) databases from a PC...
Neither does it tell you about the vagaries of different SQL implemented on
different platforms and the passionate arguments about what is standard and
what is "right". I've been in the game of database use for some time now and
I wouldn't mind a dollar for every time I have had to modify working SQL
because the client wanted a different RDBMS...
(Using LINQ solves this problem, apart from all the other advantages it
provides.)
I often get asked "Which is the BEST RDBMS?" (The answer is to be found in
years of experience and not in tables on Wikipedia)
within the parameters for selection which they devise. It isn't about
emotional attachment to proprietary or Open Source as a concept.
I prefer SQL Server because it is well supported and does everything I and
my clients need. But it is really no better (or worse) than anything else.
I have tried many RDBMS and coded SQL for all of them, right back to the
days of MS Access. RDBMS that DON'T meet the requirements of modern SQL
generally don't stay around very long. A perfect example is System 2000
which used inverted indexing and handled very large databases at a time when
all the RDBMS were really toddlers. Ford Motor Company managed their
inventory with it, to name just one major player. As RDBMS became more
established a SQL interface was written for System 2000 (very much like what
they did with ADABAS), but it was too late. The system remains one of the
most impressive DB inplementations I have ever seen, but today I believe it
is defunct.
In the same way that SQL became the de facto standard for RDBMS access, I
believe LINQ and Lambda functions will replace it. As far as I'm concerned,
SQL is already obsolete.
They deserve credit for providing an update that was a major inconvenience
for them, because they recognised it was the right thing to do, not
criticism because of an imagined paranoid policy to drive people to upgrade.
(I'm still running a couple of XP machines for desktop development and have
no plans to "upgrade" them. Should I expect the Microsoft thought police to
break down my door at any moment? I do use Win 8.1 for web development;
maybe they'll "let me off" for that...) According to you, they are damned if
they do ("they said they weren't going to") and they are damned if they
don't (just let people get exploited and then say: "Well, we TOLD you to
upgrade...")
Your bitterness towards them is sad. (And misplaced...)
versions of Word's documents, provided they are saved in Word format. (It is
backward compatible). Older versions of Word may not read documents produced
by a newer version but there is a free download to enable it. What is unfair
or unreasonable about that?
You can't cite your evidence and you won't retract, so there is no reason
for us to continue this correspondence.
> I'm
> the guy who always had to find a fix.
Oh, Boo hoo.... Just exactly why did you go to work in the morning...?
>Wasted a lot of time doing it.
> And we probably shouldn't even go into the equivalent with versions
> of Power Point.
> But some people will never accept that MS has a very
> shady past. Or that they are unlikely to ever change.
And some people believe that things can never get better and that the world
is an evil place just waiting to destroy the unwary.
I'm personally interested in what they do NOW (although my satisfied
experience with them extends over some years now) and I don't care (a lot)
about what they did in the past. I can quote you stories of misbehaviour in
the past by every major IT company in the world (IBM/BUNCH), some of whom
are now defunct. What does it prove? Caveat emptor.
>
<snip>
using JCL on a mainframe.
It's like "anything not written in COBOL is a hack".... I was stunned when I
first read this but after some reflection I see that I shouldn't have been.
It's pretty obvious to me that we live in different worlds and I really
don't like visiting yours, so I won't any more.
>
> All hacks to get around a shortcoming of the product. Nowhere in all
> their documentation do they recommend this. And what was it you were
> saying
> about things like Linux and GNU COBOL not being ready for production
> environments? :-)
This doesn't even warrant a response because it is so stupid.
I won't be responding further to you so please feel free to have the last
word.
<snip>>>
>> However, I don't think you would argue that general use of COBOL (at
>> least in the sense it was used in the last century), has NOT
>> declined. and is NOT continuing to do so.
>
> Wait, is this a typo? You highlighted "NOT".
No, it isn't a typo. "argue" is used in the sense of "posit" or
>> least in the sense it was used in the last century), has NOT
>> declined. and is NOT continuing to do so.
>
> Wait, is this a typo? You highlighted "NOT".
"postulate".
It is a standard use of English. Perhaps I understimated the education of
someone who works in a University.
> That is my standpoint.
No, it isn't. You continually refuse to accept that COBOL use in the world
in general has declined from the 'glory days" of the 1980s. It is really
stupid to argue this as it is a matter of record. (However, when I show you
the record, you dismiss it as "You can prove anything with statistics".)
<snip>>
>>
>> This issue is covered very well (and fairly) here:
>>
>> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>>
>> When it comes to the decline of COBOL I don't have to "assume"
>> everybody is moving moving off it; it is a matter of record that
>> many people are.
>
> OK, I read it. Hogwash.
Of course. It is unpalatable to you so it is dismissed as hogwash.
>> This issue is covered very well (and fairly) here:
>>
>> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>>
>> When it comes to the decline of COBOL I don't have to "assume"
>> everybody is moving moving off it; it is a matter of record that
>> many people are.
>
> OK, I read it. Hogwash.
You may also find it unpalatable that just because YOU say it is hogwash,
does not make it so...
>>
>>
<snip>
>
> I keep hearing about these but never see any names. I can provide
> (and have provided in the past) names of large operations that are not
> moving now and have no plans to do so in the future.
You are not privy to the strategic plans of any corporation you are not
> I keep hearing about these but never see any names. I can provide
> (and have provided in the past) names of large operations that are not
> moving now and have no plans to do so in the future.
employed by and the stated goals of any given corporation can change in an
instant. Just as quickly as a new IT director is installed.
It is a simple fact that more and more corporations are being forced to trim
their exorbitant IT budgets because the world (and their Boards) is waking
up to the fact that cheaper options are available. It is economic necessity,
not fashion , that drives it. Resistance to change of the kind that you
exhibit is being eroded by economic necessity, not rhetoric from me.
The network is winning the battle for IT hearts and minds and
(consequently) the COBOL fortresses you are so proud of will fall. It is
simply a matter of time.
Personally, I don't care at all; I long ago realized what was happening and
adapted to it. Besides, the pressures which drive it are inexorable. It
really isn't about academics and business people doing their damnedest to
bring down COBOL out of spite or fashion consciousness, but you seem to
think it is.
<snip>>
>>
>> Why do you suppose they don't WANT to replace their ORACLE DB with
>> PostgreSQL?
>
> Because in all these case the people who make the decisions respond
> more to the drone of the salesman than to some blog. No one is out
> there selling Linux, LibreOffice or PostgreSQL.
>
So the only person with a clear grasp of what is needed is you, and all the
>> Why do you suppose they don't WANT to replace their ORACLE DB with
>> PostgreSQL?
>
> Because in all these case the people who make the decisions respond
> more to the drone of the salesman than to some blog. No one is out
> there selling Linux, LibreOffice or PostgreSQL.
>
rest of us are stupid fools who do whatever salespeople tell us?
"The people who make the decisions" are NOT all idiots. Some of them have
broader experience and training than your own.
Sales campaigns certainly do influence, but anyone who has been in IT for
any length of time has learned to be wary of sales pitches and spin. They
want to see benchmarks and demos.
The faculty members who resist teaching COBOL at your place are not
intransigent simple-minded clods.
The Business IT directors who want to move to networked solutions, even if
it means getting out of COBOL, aren't either.
> As long as we are throwing URLs around try this one:
>
> http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
What it DOESN'T tell you is that the OS a database runs under is irrelevant
if it is being used as a server... I have remote SQL Server databases
(running on a server farm in the USA) being accessed from both Linux and
Windows systems all around the World; and 20 years ago I was acessing
mainframe (DB2 and Datacomm) databases from a PC...
Neither does it tell you about the vagaries of different SQL implemented on
different platforms and the passionate arguments about what is standard and
what is "right". I've been in the game of database use for some time now and
I wouldn't mind a dollar for every time I have had to modify working SQL
because the client wanted a different RDBMS...
(Using LINQ solves this problem, apart from all the other advantages it
provides.)
I often get asked "Which is the BEST RDBMS?" (The answer is to be found in
years of experience and not in tables on Wikipedia)
>
> It makes for some very interesting reading. But then, the oracle
> salesman isn't goingt o point you at it and the PostgreSQL salesman
> just never seems to get that appointment to meet witht he CIO.
Nonsense. CIOs want the product that will best meet their company's needs,
> It makes for some very interesting reading. But then, the oracle
> salesman isn't goingt o point you at it and the PostgreSQL salesman
> just never seems to get that appointment to meet witht he CIO.
within the parameters for selection which they devise. It isn't about
emotional attachment to proprietary or Open Source as a concept.
I prefer SQL Server because it is well supported and does everything I and
my clients need. But it is really no better (or worse) than anything else.
I have tried many RDBMS and coded SQL for all of them, right back to the
days of MS Access. RDBMS that DON'T meet the requirements of modern SQL
generally don't stay around very long. A perfect example is System 2000
which used inverted indexing and handled very large databases at a time when
all the RDBMS were really toddlers. Ford Motor Company managed their
inventory with it, to name just one major player. As RDBMS became more
established a SQL interface was written for System 2000 (very much like what
they did with ADABAS), but it was too late. The system remains one of the
most impressive DB inplementations I have ever seen, but today I believe it
is defunct.
In the same way that SQL became the de facto standard for RDBMS access, I
believe LINQ and Lambda functions will replace it. As far as I'm concerned,
SQL is already obsolete.
>
>
> Well, MS tried to use the recent Explorer flaw to force a move, but
> that seems to have backfired and now there is an update for Xp even
> after we
> were assured there would be no such thing. :-)
Another cyncial MS bash (which you claim you don't do...)
>
> Well, MS tried to use the recent Explorer flaw to force a move, but
> that seems to have backfired and now there is an update for Xp even
> after we
> were assured there would be no such thing. :-)
They deserve credit for providing an update that was a major inconvenience
for them, because they recognised it was the right thing to do, not
criticism because of an imagined paranoid policy to drive people to upgrade.
(I'm still running a couple of XP machines for desktop development and have
no plans to "upgrade" them. Should I expect the Microsoft thought police to
break down my door at any moment? I do use Win 8.1 for web development;
maybe they'll "let me off" for that...) According to you, they are damned if
they do ("they said they weren't going to") and they are damned if they
don't (just let people get exploited and then say: "Well, we TOLD you to
upgrade...")
Your bitterness towards them is sad. (And misplaced...)
>
>>
>>
>>> MS is well known for introducing incompatabilites to force upgrades.
>>
>> That is simply urban myth and I'd expect better from you.
>>
>> Cite your evidence or retract it.
>
> Sorry, I didn't document everytime someone came in with an old Word
> document that could not be converted by a newer version of Word.
And you didn't because you can't. Every version of Word will read previous
>>
>>
>>> MS is well known for introducing incompatabilites to force upgrades.
>>
>> That is simply urban myth and I'd expect better from you.
>>
>> Cite your evidence or retract it.
>
> Sorry, I didn't document everytime someone came in with an old Word
> document that could not be converted by a newer version of Word.
versions of Word's documents, provided they are saved in Word format. (It is
backward compatible). Older versions of Word may not read documents produced
by a newer version but there is a free download to enable it. What is unfair
or unreasonable about that?
You can't cite your evidence and you won't retract, so there is no reason
for us to continue this correspondence.
> I'm
> the guy who always had to find a fix.
>Wasted a lot of time doing it.
> And we probably shouldn't even go into the equivalent with versions
> of Power Point.
> But some people will never accept that MS has a very
> shady past. Or that they are unlikely to ever change.
is an evil place just waiting to destroy the unwary.
I'm personally interested in what they do NOW (although my satisfied
experience with them extends over some years now) and I don't care (a lot)
about what they did in the past. I can quote you stories of misbehaviour in
the past by every major IT company in the world (IBM/BUNCH), some of whom
are now defunct. What does it prove? Caveat emptor.
>
>>
>>> I don't see this as being any different. When your business model is
>>> keeping a constantly moving target for the customer to hit, you
>>> don't survive long it you anchor the product.
>>
>> Your paranoia is showing.
>
> Just because your paranoid doesn't mean every one isn't out to get
> you.
A cliche paraded as wit. I shouldn't be surprised.
>>
>>> I don't see this as being any different. When your business model is
>>> keeping a constantly moving target for the customer to hit, you
>>> don't survive long it you anchor the product.
>>
>> Your paranoia is showing.
>
> Just because your paranoid doesn't mean every one isn't out to get
> you.
>
<snip>
>> At any given moment there are probably only a couple in use so it is
>> no hardship to start them from the Virtual Box console,
>
> I have about 50 running at the moment. Access to the host machine
> consoles from outside of the datacenter is not available and will
> never be.
>
>> but if I needed
>> to have certain machines always available I'd write a simple startup
>> script.
>
> And that was my point exactly. A hack. What should be a major part
> of
> the overall system is not included as part of the product.
This is just unbelieveable. Using script with PCs is no more a "hack" than
>> no hardship to start them from the Virtual Box console,
>
> I have about 50 running at the moment. Access to the host machine
> consoles from outside of the datacenter is not available and will
> never be.
>
>> but if I needed
>> to have certain machines always available I'd write a simple startup
>> script.
>
> And that was my point exactly. A hack. What should be a major part
> of
> the overall system is not included as part of the product.
using JCL on a mainframe.
It's like "anything not written in COBOL is a hack".... I was stunned when I
first read this but after some reflection I see that I shouldn't have been.
It's pretty obvious to me that we live in different worlds and I really
don't like visiting yours, so I won't any more.
>
> All hacks to get around a shortcoming of the product. Nowhere in all
> their documentation do they recommend this. And what was it you were
> saying
> about things like Linux and GNU COBOL not being ready for production
> environments? :-)
I won't be responding further to you so please feel free to have the last
word.
Pete Dashwood
May 9, 2014, 7:11:06 PM5/9/14
to
Clark F Morris wrote:
> On Thu, 8 May 2014 05:05:23 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> Bill Gunshannon wrote:
>>>> Open Source, generally, in my experience, is not concerned with
>>>> business cases. Hence, most businesses don't use it.
>>>
>>> Linux?
>>
>> Oh yes, it has 1.58% of desktop and laptop machines.
>>
>> MOST businesses... :-)
>>
>> You know, the REAL world where over 85% of the machines are running
>> Windows...?
>
> On the server side, Linux is growing rapidly on various architectures.
> The Heartbleed bug is in open source software. Public domain add on
> software is use in many z series sites (see www.cbttape.org). While I
> believe a lot of COBOL and other site written code is being replaced
> with packages and packages may well not be written in COBOL, I see a
> steady decline in in-house written code.
I agree. I noticed and commented on the same to some IT managers recently.
> On Thu, 8 May 2014 05:05:23 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> Bill Gunshannon wrote:
>>>> Open Source, generally, in my experience, is not concerned with
>>>> business cases. Hence, most businesses don't use it.
>>>
>>> Linux?
>>
>> Oh yes, it has 1.58% of desktop and laptop machines.
>>
>> MOST businesses... :-)
>>
>> You know, the REAL world where over 85% of the machines are running
>> Windows...?
>
> On the server side, Linux is growing rapidly on various architectures.
> The Heartbleed bug is in open source software. Public domain add on
> software is use in many z series sites (see www.cbttape.org). While I
> believe a lot of COBOL and other site written code is being replaced
> with packages and packages may well not be written in COBOL, I see a
> steady decline in in-house written code.
For systems that are
> Unix/Linux/Windows based the problem with COBOL is that these
> environments do not provide a common record format (as opposed to
> stream) i-o and do not have a keyed file system as part of the
> operating system services. Just out of curiosity, how are the BUNCH
> (Burroughs, Univac, NCR, Control Data, Honeywell) and their European
> and Asian counterparts doing these days? I think Honeywell sold out
> to Bull. Burroughs and Univac became Unisys. NCR seems to be
> basically a data warehouse hardware company. Other than the IBM z and
> i series, are there any major non-Unix/Linux/Windows providers out
> there?
contract) is mostly defunct now. CDC (a really lovely company and I have
many happy memories from it), went down and was disbanded. The only
surviving part is Cray supercomputing which hangs on by the skin of its
teeth and Defense funding. IBM (being the most adaptable) is the best
survivor. Honeywell is still big in Europe (especially France).
Pete Dashwood
May 9, 2014, 7:15:36 PM5/9/14
to
Graham Hobbs wrote:
<snip>
is no longer generally available?
I use and like XP. I intend to continue using and liking it :-)
Withdrawal of support and updates is not a problem, especially when they
have shown that if something really serious comes up, they will respond to
it.
<snip>
<snip>
>> Cite your evidence or retract it.
>>
> .. MS causing planetary grief by withdrawing support for Win XP?
>
Everything has a time. Why wouldn't they stop spending money on an OS that
>>
> .. MS causing planetary grief by withdrawing support for Win XP?
>
is no longer generally available?
I use and like XP. I intend to continue using and liking it :-)
Withdrawal of support and updates is not a problem, especially when they
have shown that if something really serious comes up, they will respond to
it.
<snip>
Graham Hobbs
May 10, 2014, 10:55:01 AM5/10/14
to
On Sat, 10 May 2014 11:15:36 +1200, "Pete Dashwood"
<dash...@removethis.enternet.co.nz> wrote:
>Graham Hobbs wrote:
><snip>
>>> Cite your evidence or retract it.
>>>
>> .. MS causing planetary grief by withdrawing support for Win XP?
>>
>Everything has a time. Why wouldn't they stop spending money on an OS that
>is no longer generally available?
>
.. why to stopping spending .. no matter what you say and I'm sure
<dash...@removethis.enternet.co.nz> wrote:
>Graham Hobbs wrote:
><snip>
>>> Cite your evidence or retract it.
>>>
>> .. MS causing planetary grief by withdrawing support for Win XP?
>>
>Everything has a time. Why wouldn't they stop spending money on an OS that
>is no longer generally available?
>
you will, when a company pisses off millions upon millions and
millions of users as MS has done, is policywise, massively unclever.
.. 'Everything has a time' .. I don't see COBOL, CICS or DB2 going
anywhere too soon..
>I use and like XP. I intend to continue using and liking it :-)
>
>Withdrawal of support and updates is not a problem, especially when they
>have shown that if something really serious comes up, they will respond to
>it.
>
><snip>
>Pete.
Pete Dashwood
May 10, 2014, 10:24:17 PM5/10/14
to
Graham Hobbs wrote:
> On Sat, 10 May 2014 11:15:36 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> Graham Hobbs wrote:
>> <snip>
>>>> Cite your evidence or retract it.
>>>>
>>> .. MS causing planetary grief by withdrawing support for Win XP?
>>>
>> Everything has a time. Why wouldn't they stop spending money on an
>> OS that is no longer generally available?
>>
> .. why to stopping spending .. no matter what you say and I'm sure
> you will, when a company pisses off millions upon millions and
> millions of users as MS has done, is policywise, massively unclever.
Yes, there are millions of people who are sad to see the offical demise of
> On Sat, 10 May 2014 11:15:36 +1200, "Pete Dashwood"
> <dash...@removethis.enternet.co.nz> wrote:
>
>> Graham Hobbs wrote:
>> <snip>
>>>> Cite your evidence or retract it.
>>>>
>>> .. MS causing planetary grief by withdrawing support for Win XP?
>>>
>> Everything has a time. Why wouldn't they stop spending money on an
>> OS that is no longer generally available?
>>
> .. why to stopping spending .. no matter what you say and I'm sure
> you will, when a company pisses off millions upon millions and
> millions of users as MS has done, is policywise, massively unclever.
XP.
(I reckon it is the best PC OS that Microsoft ever produced, but I'm not
such a fan of Windows 7 and don't use it much for real work; more as a
testing platform to make sure our software runs on it. I am very impressed
by windows 8.1 (probably the only person on the planet who actually loves it
and has no problem with no start button... :-)) and use it for all web
development (to run later versions of Visual Studio for XAML, and C#
code-behind pages for ASP.NET), but I haven't had time yet to really delve
into this environment and make serious and significant changes oto the PRIMA
web site. I'm hoping to do that very soon when the LINQ DAL development is
complete.
But, as I mentioned elsewhere, Microsoft are damned if they do and damned if
they don't.
They invest billions in new and better software and can't get people to pick
it up because the old stuff is entrenched. It is costing them money to keep
providing fixes for the old stuff and there is little or no return on that
investment.
At some point, they HAVE to bite the bullet and say:"Enough! We cannot keep
supporting a product that is over 10 years old, when we have newer products
available that also have to be supported. Whether you upgrade and stay with
us, or you go to a different OS (and both these options will cost you
SOMETHING), we simply can't keep offering updates."
I'm not sure that trillions of users are pissed off, as you state, but I
would agree that most of us who love XP are sorry to see it go.
I'm not impressed by the Corporates who say they haven't had time to move
off XP; how long do you need?
Much of this particular furore is a storm in a teacup.
I'm still doing desktop development on an XP machine (an 8 year old VAIO
AR250G whose screen and hard drive I replaced) and the only noticeable
difference is that those annoying updates have stopped. I'm still running
COBOL under XP (only on Virtual Machines, now) and everything is still
working fine.
I've had a number of home users (friends) who were quite panicked at the
thought of no further support and asked me what they should do. The average
age of their machines is around 8.5 years...
My answer was: "If you are happy with what you have and it meets your needs,
do nothing. You'll be fine. BUT, be aware that the MTBF (Mean Time Between
Failure) on a hard drive is around 20,000 hours (this has nothing to do with
Microsoft) and for a home user that would be around 6 years. It doesn't mean
your disk will fail after 6 years, it just means there is an increasing
probability it will, so you might need to think about replacing it. Given
the dramatic fall in laptop prices, you might consider getting a
replacement. Ask them to image your existing system and, if you don't like
using the new machine, you can have the old one re-installed."
After spending a morning with four of these people and showing them the
seamless and easy way Windows 8.1 can switch between the desktop (which they
know) and the new surface style interface (previously Metro) where the
entire surface is a start button, nobody has opted to go back to XP.
They have also been unanimously impressed by the cold boot time on Windows
8.1 (around 20 seconds) as opposed to XP (around 4 minutes average).
BOTTOM LINE: If you want to slag off Microsoft, then XP is a great
opportunity to do so, but it doesn't alter the fact that ageing computers
need to be replaced ANYWAY.
>
> .. 'Everything has a time' .. I don't see COBOL, CICS or DB2 going
> anywhere too soon..
My quote that everything has a time, is from Zen Buddhism. While that alone
doesn't make it true, they have had a lot of experience at observing the
unverse and how it works.
I DO see a time when COBOL, CICS, and DB2 will no longer be around (just as
I can envisage a time when Windows, .NET, C# and Java won't be around
either.) It is a question of the frame you put on the time.
I agree with your use of "soon" as a qualifier.
There are two things that need to be considered for your statement:
1. The time frame. (We can both agree it won't be "soon")
2. The percentage of computing in the world that is using CICS COBOL and
DB2. I would argue that if it is less than 10% it isn't significant in the
scheme of things, but that one is very arguable. My point is that it doesn't
have to be zero before you can say they are "gone"...
(BTW, I believe that DB2 will outlast both COBOL and CICS, but that is also
an arguable proposition.)
However, the "rate of change" is accellerating, particularly with regard to
technology (See "The singularity is near" by Ray Kurzweil) and I believe
there are people alive today who will see the demise of all of the above,
including the stuff I mentioned in parentheses.
Kurzweil sees the future standing on a tripod of 3 technologies:
1. Robotics.
2 Nanotechnology.
3. CYBERNETICS (computing and AI)
He has very good credentials and has been right in the past, but, again,
that doesn't mean he will be right this time. Nevertheless, he makes a
compelling case in his book.
Imagine for a moment if we start implanting AI chips into humans and the
general intelligence of the race is raised. They then build smarter
computers which eventually don't need human programmers and can build even
smarter computers and so on.
If a computer was programming itself, it probably wouldn't use COBOL.
(In fact, it wouldn't use any kind of "HIGH LEVEL" language because these
were invented for the convenience of humans... The process could be similar
to the evolutionary process of gene development in the chromosome, except it
would be a very much quicker evolution.)
Science fiction? Not likely for hundreds of years (if ever)?
Research into the nanotechnology and cybernetics that would make this
possible is already happening. The timeframe for humans to merge with
"machines" (actually nanobots and memory chips) and become a single entity
where the organic functions would be indistinguishable from the hardware
functions is, according to Kurzweil, the year 2047. That's less than three
and a half decades from now...
(This number is not just "plucked out of the air"; read his book to see his
detailed explanation of how he arrives at it...)
However you slice it, this century will see some sea changes in technology
and it will affect the way that people use and interact with computers (or,
more correctly, "intelligent devices"). Storage devices and computing
devices will both undergo significant change as the "Internet of Things"
grows and permeates our lives. The way we do business will be significantly
different and the idea of going to a shop and buying something will be a
quaint shadow of a former time.
The approaches used by COBOL are rooted in the 1960s; how long did you
expect it to last?
Everything has a time.
Pete
Pete Dashwood
May 10, 2014, 10:37:42 PM5/10/14
to
Pete Dashwood wrote:
> Graham Hobbs wrote:
<snip>
> Graham Hobbs wrote:
<snip>
> I've had a number of home users (friends) who were quite panicked at
> the thought of no further support and asked me what they should do.
> The average age of their machines is around 8.5 years...
>
> My answer was: "If you are happy with what you have and it meets your
> needs, do nothing. You'll be fine. BUT, be aware that the MTBF (Mean
> Time Between Failure) on a hard drive is around 20,000 hours (this
> has nothing to do with Microsoft) and for a home user that would be
> around 6 years. It doesn't mean your disk will fail after 6 years, it
> just means there is an increasing probability it will, so you might
> need to think about replacing it. Given the dramatic fall in laptop
> prices, you might consider getting a replacement. Ask them to image
> your existing system and, if you don't like using the new machine,
> you can have the old one re-installed."
Six years seemed a bit short, after seeing it written down, although it is a
> the thought of no further support and asked me what they should do.
> The average age of their machines is around 8.5 years...
>
> My answer was: "If you are happy with what you have and it meets your
> needs, do nothing. You'll be fine. BUT, be aware that the MTBF (Mean
> Time Between Failure) on a hard drive is around 20,000 hours (this
> has nothing to do with Microsoft) and for a home user that would be
> around 6 years. It doesn't mean your disk will fail after 6 years, it
> just means there is an increasing probability it will, so you might
> need to think about replacing it. Given the dramatic fall in laptop
> prices, you might consider getting a replacement. Ask them to image
> your existing system and, if you don't like using the new machine,
> you can have the old one re-installed."
heuristic I have used for years and never really questioned.
I just recalculated using a figure of 4 hours per day for a home user and it
comes out at around 13 years...
By a spooky coincidence, this is about how long XP has been around... :-)
Pete.
Arnold Trembley
May 11, 2014, 4:08:45 AM5/11/14
to
On 5/10/2014 9:24 PM, Pete Dashwood wrote:
> (snip)
>
> (snip)
>
> I'm not sure that trillions of users are pissed off, as you state, but I
> would agree that most of us who love XP are sorry to see it go.
>
> I'm not impressed by the Corporates who say they haven't had time to move
> off XP; how long do you need?
There are thousands of PC's where I work and they like to get at least 4
> would agree that most of us who love XP are sorry to see it go.
>
> I'm not impressed by the Corporates who say they haven't had time to move
> off XP; how long do you need?
years out of one before junking it. They don't like to support two
different versions of Windows across the entire inventory if they can
avoid it. It took us two years to convert from XP to Win7 while
skipping Vista. Part of the problem was dependence on web applications
built for MSIE 6 that would not work with later versions of Internet
Explorer and had to be modified.
If a corporation says they haven't had time to move off XP it's because
they didn't start early enough.
> (snip)
>
> After spending a morning with four of these people and showing them the
> seamless and easy way Windows 8.1 can switch between the desktop (which they
> know) and the new surface style interface (previously Metro) where the
> entire surface is a start button, nobody has opted to go back to XP.
>
> They have also been unanimously impressed by the cold boot time on Windows
> 8.1 (around 20 seconds) as opposed to XP (around 4 minutes average).
While faster boot times are convenient and desirable, there are trade
> After spending a morning with four of these people and showing them the
> seamless and easy way Windows 8.1 can switch between the desktop (which they
> know) and the new surface style interface (previously Metro) where the
> entire surface is a start button, nobody has opted to go back to XP.
>
> They have also been unanimously impressed by the cold boot time on Windows
> 8.1 (around 20 seconds) as opposed to XP (around 4 minutes average).
offs with the way Microsoft does it. In order to enable faster reboots
Windows 8 normally will not shut down completely. If you need to shut
down completely it can be difficult force it, and the first boot after a
complete shutdown will take longer.
http://www.techsupportalert.com/freeware-forum/system/12944-method-of-shutdown-in-windows-8-1-makes-difference.html
>
> BOTTOM LINE: If you want to slag off Microsoft, then XP is a great
> opportunity to do so, but it doesn't alter the fact that ageing computers
> need to be replaced ANYWAY.
of XP, and it's still possible to buy PC's with XP preinstalled, if you
don't mind refurbs.
>
> Everything has a time.
>
> Pete
>
--
http://www.arnoldtrembley.com/
docd...@panix.com
May 11, 2014, 11:04:35 AM5/11/14
to
[postings group expanded]
In article <vtCdnZgjVsmTrfLO...@giganews.com>,
Arnold Trembley <arnold....@att.net> wrote:
>On 5/10/2014 9:24 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I'm not sure that trillions of users are pissed off, as you state, but I
>> would agree that most of us who love XP are sorry to see it go.
>>
>> I'm not impressed by the Corporates who say they haven't had time to move
>> off XP; how long do you need?
>
>There are thousands of PC's where I work and they like to get at least 4
>years out of one before junking it.
I am not an accountant but that sounds like the old 'three years for
>On 5/10/2014 9:24 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I'm not sure that trillions of users are pissed off, as you state, but I
>> would agree that most of us who love XP are sorry to see it go.
>>
>> I'm not impressed by the Corporates who say they haven't had time to move
>> off XP; how long do you need?
>
>There are thousands of PC's where I work and they like to get at least 4
>years out of one before junking it.
tax-write-off and one to grow on'.
[snip]
>It took us two years to convert from XP to Win7 while
>skipping Vista. Part of the problem was dependence on web applications
>built for MSIE 6 that would not work with later versions of Internet
>Explorer and had to be modified.
dependent on other applications over which one's organisation has no
control - remember what happened when all those new FILE STATUS values
caused programs diligently coded with 88 VALID-IO VALUE ZEROES to blow
up? - but there was also a bit of legal tapdancing going on about whether
Microsoft was favoring its own browser at the expense of others.
>
>If a corporation says they haven't had time to move off XP it's because
>they didn't start early enough.
a 30-year mortgage? Well, get DP working on it, it should should be easy
enough to fix.'
DD
Pete Dashwood
May 11, 2014, 8:27:11 PM5/11/14
to
Arnold Trembley wrote:
> On 5/10/2014 9:24 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I'm not sure that trillions of users are pissed off, as you state,
>> but I would agree that most of us who love XP are sorry to see it
>> go. I'm not impressed by the Corporates who say they haven't had time to
>> move off XP; how long do you need?
>
> There are thousands of PC's where I work and they like to get at
> least 4 years out of one before junking it.
XP has been around for 13 years. Plenty of time for a 4 year window.
> On 5/10/2014 9:24 PM, Pete Dashwood wrote:
>> (snip)
>>
>> I'm not sure that trillions of users are pissed off, as you state,
>> but I would agree that most of us who love XP are sorry to see it
>> go. I'm not impressed by the Corporates who say they haven't had time to
>> move off XP; how long do you need?
>
> There are thousands of PC's where I work and they like to get at
> least 4 years out of one before junking it.
>They don't like to
> support two different versions of Windows across the entire inventory
> if they can avoid it. It took us two years to convert from XP to
> Win7 while skipping Vista. Part of the problem was dependence on web
> applications built for MSIE 6 that would not work with later versions
> of Internet Explorer and had to be modified.
Still, that is realy a problem with web development and ot the fault of XP.
One of the major things that forced me to move to Win 8.1 is that IE 10
won't run under XP. I have now standardized on Chrome as the default Browser
and it runs under anything.
>
> If a corporation says they haven't had time to move off XP it's
> because they didn't start early enough.
See my 13 year note above.
> If a corporation says they haven't had time to move off XP it's
> because they didn't start early enough.
>
>
>> (snip)
>>
>> After spending a morning with four of these people and showing them
>> the seamless and easy way Windows 8.1 can switch between the desktop
>> (which they know) and the new surface style interface (previously
>> Metro) where the entire surface is a start button, nobody has opted
>> to go back to XP. They have also been unanimously impressed by the cold
>> boot time on
>> Windows 8.1 (around 20 seconds) as opposed to XP (around 4 minutes
>> average).
>
> While faster boot times are convenient and desirable, there are trade
> offs with the way Microsoft does it. In order to enable faster
> reboots Windows 8 normally will not shut down completely.
Sorry, that is absolutely untrue. (At least for 8.1, which I use)
>
>> (snip)
>>
>> After spending a morning with four of these people and showing them
>> the seamless and easy way Windows 8.1 can switch between the desktop
>> (which they know) and the new surface style interface (previously
>> Metro) where the entire surface is a start button, nobody has opted
>> to go back to XP. They have also been unanimously impressed by the cold
>> boot time on
>> Windows 8.1 (around 20 seconds) as opposed to XP (around 4 minutes
>> average).
>
> While faster boot times are convenient and desirable, there are trade
> offs with the way Microsoft does it. In order to enable faster
> reboots Windows 8 normally will not shut down completely.
I can close down, disconnect power, and that is what I call a "cold boot".
Certainly, We use Hibernation on both XP and Win 8.1 but at least once a
week it is good to do a cold boot.
> If you
> need to shut down completely it can be difficult force it, and the
> first boot after a complete shutdown will take longer.
it... :-)
>
> http://www.techsupportalert.com/freeware-forum/system/12944-method-of-shutdown-in-windows-8-1-makes-difference.html
I read this with interest. I have never used the new start button so I
wouldn't be aware of the reported difference. I have closed the system and
disconnected power then reconnected and re-booted as reported. The link
above is talking about a 30 second reboot as opposed to several minutes for
XP, and that was my point.
>
>>
>> BOTTOM LINE: If you want to slag off Microsoft, then XP is a great
>> opportunity to do so, but it doesn't alter the fact that ageing
>> computers need to be replaced ANYWAY.
>
> True enough, but it's still possible to get a few more years service
> out of XP, and it's still possible to buy PC's with XP preinstalled,
> if you don't mind refurbs.
Having refurbished several of my own systems, in particular my beloved
>>
>> BOTTOM LINE: If you want to slag off Microsoft, then XP is a great
>> opportunity to do so, but it doesn't alter the fact that ageing
>> computers need to be replaced ANYWAY.
>
> True enough, but it's still possible to get a few more years service
> out of XP, and it's still possible to buy PC's with XP preinstalled,
> if you don't mind refurbs.
ancient VAIO, I am not opposed to refurbished computers, but I couldn't, in
conscience, recommend people to do it when we are seeing rock bottom prices
on new laptops here. (A machine which a year ago cost $1000 is now $540...)
Refurnished machines are not generally available here and I suspect it is
because the savings between refurbished and new are not enough to make it
worthwhile.
As for getting more service out of XP, I intend to use it indefinitely as
long as I can keep the VAIO running.
Graham Hobbs
May 11, 2014, 10:33:16 PM5/11/14
to
I read that of MS users 27%-30% are XP (50% in China). Does that sound
right?
What might be a realistic percentage.and then translate into 10, 50,
100 million, whatever?
What percent would be corporate, what percent John Does'.
Graham Hobbs
Bill Gunshannon
May 12, 2014, 9:53:49 AM5/12/14
to
In article <bt558b...@mid.individual.net>,
is opposite what one reads it to be. :-)
In a ny event, no, I don't think COBOL use has declined. Percentage-wise,
certainly, but that is due to the advent of all the other crap and the fact
that the IT world is now several orders of magnitude larger than it was "in
the last century". I think most of the COBOL is still as it was in the last
century with many new systems (not new locations, additional systems in
places that continue to use COBOL) offsetting the ones that have gone away.
In case your interested, my resume just got refered to for another COBOL
job with a major nationwide system that is not being re-written in some
"more modern" language.
>
>> That is my standpoint.
>
> No, it isn't. You continually refuse to accept that COBOL use in the world
> in general has declined from the 'glory days" of the 1980s. It is really
> stupid to argue this as it is a matter of record. (However, when I show you
> the record, you dismiss it as "You can prove anything with statistics".)
It hasn't declined by any noticable amount. The government (over here, at
least), hospitals (that aren't on an even more ogscure system call Mumps),
insurance, credit cards, bank, other financials (that aren't on an even more
obscure language called APL), etc. Maybe NZ has abandoned all use of COBOL,
but that does not reflect the reality of the rest of the IT world.
>
> <snip>>
>>>
>>> This issue is covered very well (and fairly) here:
>>>
>>> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>>>
>>> When it comes to the decline of COBOL I don't have to "assume"
>>> everybody is moving moving off it; it is a matter of record that
>>> many people are.
>>
>> OK, I read it. Hogwash.
>
> Of course. It is unpalatable to you so it is dismissed as hogwash.
I have personal experience to the contrary. That's what makes it hogwash.
It reads like the garbage being spouted at college undergrads that even
they can esaily find information tot he contrary.
>
> You may also find it unpalatable that just because YOU say it is hogwash,
> does not make it so...
Well, I would not bet my farm on that kind of garbage. It's alot like
Agile. I had to take a course in that when I was working for the Navy.
The instructor started the course with a description of "how things used
to be done" that was totally bogus. And then based the reasoning for
Agile on that erroneous premise. I see much o f the argumetns against
COBOL as the same. They are not reality, they are wishful thinking and
a desire to steer the bus away from COBOL rather than admit that COBOL
people are still needed.
>>>
>>>
> <snip>
>>
>> I keep hearing about these but never see any names. I can provide
>> (and have provided in the past) names of large operations that are not
>> moving now and have no plans to do so in the future.
>
> You are not privy to the strategic plans of any corporation you are not
> employed by and the stated goals of any given corporation can change in an
> instant. Just as quickly as a new IT director is installed.
So, tell me, why is it the companiest that are not getting rid of COBOL
have no problem admitting it while the companies that are keep mum?
And your comment above works both ways.
>
> It is a simple fact that more and more corporations are being forced to trim
> their exorbitant IT budgets because the world (and their Boards) is waking
> up to the fact that cheaper options are available. It is economic necessity,
> not fashion , that drives it. Resistance to change of the kind that you
> exhibit is being eroded by economic necessity, not rhetoric from me.
So then, how does taking on a multi-million dollar project to replace a
working system meet those economic goals?
>
> The network is winning the battle for IT hearts and minds and
> (consequently) the COBOL fortresses you are so proud of will fall. It is
> simply a matter of time.
COBOL works just fine on a network. How do you see it not doing it? I
have a web application I personally wrote to replace a PHP application
that broke and was so obfuscated no one could fix it. (no one could even
figure out how it worked int he first place!!) I have just recently
done a COBOL library that allows database access over a network. Worse
case scenario would be having to write a wrapper in another language to
create an interface between COBOL and some outside systems. But what
COBOL has done well for decades it still does well.
>
> Personally, I don't care at all; I long ago realized what was happening and
> adapted to it. Besides, the pressures which drive it are inexorable. It
> really isn't about academics and business people doing their damnedest to
> bring down COBOL out of spite or fashion consciousness, but you seem to
> think it is.
I see the academic side first hand. Computing languages courses that talk
about Smalltalk, Lisp, Scheme, Oberon, Prolog and yet fail to mention COBOL
at all. Not even for its historical significance.
>
> <snip>>
>>>
>>> Why do you suppose they don't WANT to replace their ORACLE DB with
>>> PostgreSQL?
>>
>> Because in all these case the people who make the decisions respond
>> more to the drone of the salesman than to some blog. No one is out
>> there selling Linux, LibreOffice or PostgreSQL.
>>
> So the only person with a clear grasp of what is needed is you, and all the
> rest of us are stupid fools who do whatever salespeople tell us?
Oh, I didn't know you were a CIO. We people in the trenches have little if
any influence on these decisions. SAP advertises on all the golf TV cover-
ages over here. And HP, an CA, etc. Never saw a single ad for Linux.
Execs read the Wall Street Journal over here, not The Linux Journal.
Microsoft pays millions to keep the ear of the government, RedHat, not a
dime. Hype sells.
>
> "The people who make the decisions" are NOT all idiots.
Jury is still out on that one.
> Some of them have
> broader experience and training than your own.
Maybe in NZ. :-) I have worked with OSes (major OSes!) that most of the
current crop of CIOs have never heard of. But then, they weren't even born
when I started in the IT biz. And, having an MBA hardly counts as better
training than I have. :-)
>
> Sales campaigns certainly do influence, but anyone who has been in IT for
> any length of time has learned to be wary of sales pitches and spin. They
> want to see benchmarks and demos.
What part of the MBA program taught them that? Not that this is
anything new. Anecdote time: I used to work for Martin Marietta
(now Lockheed Martin). (See, I haven't always been in academia!!!)
We set out to bid on a minicomputer system for a college in the
Northeast US. There were only two serious bidders for this. Us and
Digital. We bid a Prime 50-Series (this was back when they were still
a very promising computer company.) A benchmark was provided. We ran
the benchmark and showed up with an entire box of fanfold paper with
our results on it. DEC showed up with an envelope. The envelope
stated that the computer they were bidding didn't actually exist yet
but if it did the benchmark resulst would be....... No Joke. Care
to wager on who won? The person from the college who was running the
RFP stood up in front of the bidding conference and blatantly stated,
"I don;t care who wins as long as the computer says VAX on the front."
Now, tell me again how benchmarks trump hype...
>
> The faculty members who resist teaching COBOL at your place are not
> intransigent simple-minded clods.
Didn't say they were. But, they have their own agenda. And it is not
necessarily preparing students to meet the needs of the industry. There
are still a lot of people in academia who are fighting the idea that all
Colleges are are trades schools whose purpose is to help students get
good paying jobs. (There was recently a lot of flack over an interview
with the head of Google when he said that!!)
>
> The Business IT directors who want to move to networked solutions, even if
> it means getting out of COBOL, aren't either.
Except that "getting out of COBOL" has nothing to do with "move to
networked solutions". The two are not mutually exclusive.
>
>
>
>
>> As long as we are throwing URLs around try this one:
>>
>> http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
>
> It is interesting, but it needs updating.
>
> What it DOESN'T tell you is that the OS a database runs under is irrelevant
> if it is being used as a server... I have remote SQL Server databases
> (running on a server farm in the USA) being accessed from both Linux and
> Windows systems all around the World; and 20 years ago I was acessing
> mainframe (DB2 and Datacomm) databases from a PC...
>
> Neither does it tell you about the vagaries of different SQL implemented on
> different platforms and the passionate arguments about what is standard and
> what is "right". I've been in the game of database use for some time now and
> I wouldn't mind a dollar for every time I have had to modify working SQL
> because the client wanted a different RDBMS...
>
> (Using LINQ solves this problem, apart from all the other advantages it
> provides.)
>
> I often get asked "Which is the BEST RDBMS?" (The answer is to be found in
> years of experience and not in tables on Wikipedia)
So the numbers on COBOL usage on the INTERNET are gospel but when it comes
to Databases the INTERNET is not a valid source? Interesting.
>>
>> It makes for some very interesting reading. But then, the oracle
>> salesman isn't goingt o point you at it and the PostgreSQL salesman
>> just never seems to get that appointment to meet witht he CIO.
>
> Nonsense. CIOs want the product that will best meet their company's needs,
No. the CIO wants to make as few waves as possible so as not to risk his
golden parachute.
> within the parameters for selection which they devise. It isn't about
> emotional attachment to proprietary or Open Source as a concept.
Well, I see being totally hype driven as being pretty much emotional.
>
> I prefer SQL Server because it is well supported and does everything I and
> my clients need. But it is really no better (or worse) than anything else.
> I have tried many RDBMS and coded SQL for all of them, right back to the
> days of MS Access. RDBMS that DON'T meet the requirements of modern SQL
> generally don't stay around very long. A perfect example is System 2000
> which used inverted indexing and handled very large databases at a time when
> all the RDBMS were really toddlers. Ford Motor Company managed their
> inventory with it, to name just one major player. As RDBMS became more
> established a SQL interface was written for System 2000 (very much like what
> they did with ADABAS), but it was too late. The system remains one of the
> most impressive DB inplementations I have ever seen, but today I believe it
> is defunct.
Don't know it, so I can't really comment.
>
> In the same way that SQL became the de facto standard for RDBMS access, I
> believe LINQ and Lambda functions will replace it. As far as I'm concerned,
> SQL is already obsolete.
We shall see. One of the most popular DB's on the INTERNET today does
neither LINQ or Standard SQL. :-)
>>
>>
>> Well, MS tried to use the recent Explorer flaw to force a move, but
>> that seems to have backfired and now there is an update for Xp even
>> after we
>> were assured there would be no such thing. :-)
>
> Another cyncial MS bash (which you claim you don't do...)
Merely a statement of fact. Which, backfired as they were forced to
fix IE on XP even after stating they would not do so.
>
> They deserve credit for providing an update that was a major inconvenience
> for them, because they recognised it was the right thing to do, not
> criticism because of an imagined paranoid policy to drive people to upgrade.
Damn, yiou really are well entrenched in their camp. They couldn't
care less about inconvenience. Bad press was what drove them.
> (I'm still running a couple of XP machines for desktop development and have
> no plans to "upgrade" them. Should I expect the Microsoft thought police to
> break down my door at any moment? I do use Win 8.1 for web development;
> maybe they'll "let me off" for that...) According to you, they are damned if
> they do ("they said they weren't going to") and they are damned if they
> don't (just let people get exploited and then say: "Well, we TOLD you to
> upgrade...")
>
> Your bitterness towards them is sad. (And misplaced...)
Pete, do you not even read what I type? I have over a dozen Windows
Servers here. All of my virtualization is done on MS products. And
I am the one who recommended these products. Hyper-V over VMWare!! No
bitterness here. I just am not blinded by their facade and tend to
actually look at what companies do rather than what they say. (I'm
not an Apple fanboy, either!!)
>>
>>>
>>>
>>>> MS is well known for introducing incompatabilites to force upgrades.
>>>
>>> That is simply urban myth and I'd expect better from you.
>>>
>>> Cite your evidence or retract it.
>>
>> Sorry, I didn't document everytime someone came in with an old Word
>> document that could not be converted by a newer version of Word.
>
> And you didn't because you can't. Every version of Word will read previous
> versions of Word's documents, provided they are saved in Word format.
And that is pure hogwash. They have often deliberately abandoned backwards
compatability. Don't get me wrong, unlimited backwards compatability is
both impossible and, in the long run, bad business. But to claim they have
always maintained it is just plain ridiculous. And it was even worse with
the government than academia as they tended to stick with outdated products
in one department wahile others clung to the bleeding edge which brought
these incompatabilites to the forefront.
> (It is
> backward compatible). Older versions of Word may not read documents produced
> by a newer version but there is a free download to enable it. What is unfair
> or unreasonable about that?
>
> You can't cite your evidence and you won't retract, so there is no reason
> for us to continue this correspondence.
Whatever.
>
>
>> I'm
>> the guy who always had to find a fix.
>
> Oh, Boo hoo.... Just exactly why did you go to work in the morning...?
You just won't accept that experiences in other places differ from yours, huh!
>
>>Wasted a lot of time doing it.
>> And we probably shouldn't even go into the equivalent with versions
>> of Power Point.
>> But some people will never accept that MS has a very
>> shady past. Or that they are unlikely to ever change.
>
> And some people believe that things can never get better and that the world
> is an evil place just waiting to destroy the unwary.
And some of us accept that newer is not necessarily better. It can be,
but just being newer does not guarantee that.
>
> I'm personally interested in what they do NOW (although my satisfied
> experience with them extends over some years now) and I don't care (a lot)
> about what they did in the past. I can quote you stories of misbehaviour in
> the past by every major IT company in the world (IBM/BUNCH), some of whom
> are now defunct. What does it prove? Caveat emptor.
No one has the record MS has.
>>
>>>
>>>> I don't see this as being any different. When your business model is
>>>> keeping a constantly moving target for the customer to hit, you
>>>> don't survive long it you anchor the product.
>>>
>>> Your paranoia is showing.
>>
>> Just because your paranoid doesn't mean every one isn't out to get
>> you.
>
> A cliche paraded as wit. I shouldn't be surprised.
Your the one who threrw out paranoia as a factor. I was just making light
of it as that is all it deserved.
>>
> <snip>
>>> At any given moment there are probably only a couple in use so it is
>>> no hardship to start them from the Virtual Box console,
>>
>> I have about 50 running at the moment. Access to the host machine
>> consoles from outside of the datacenter is not available and will
>> never be.
>>
>>> but if I needed
>>> to have certain machines always available I'd write a simple startup
>>> script.
>>
>> And that was my point exactly. A hack. What should be a major part
>> of
>> the overall system is not included as part of the product.
>
> This is just unbelieveable. Using script with PCs is no more a "hack" than
> using JCL on a mainframe.
When you have to use somthing external to the product to do what all the
equivalent products thought to make an internal function it's a hack.
Where in the VirtualBox documentation is this explained? Apparently
they didn't even give it a thought even though it is obviously an
operational necessity.
>
> It's like "anything not written in COBOL is a hack".... I was stunned when I
> first read this but after some reflection I see that I shouldn't have been.
Where did you see that? I program in dozens of languages and on close
to a dozen different OSes. I have never said it was "COBOL or nothing".
Quite the contrary, it is the anti-COBOL people with that opinion.
>
> It's pretty obvious to me that we live in different worlds and I really
> don't like visiting yours, so I won't any more.
>
OK Pete, it's been fun. I will expect one more post from you to announce
that the last COBOL program inthe world has been shut down, but I, at least,
know that neither of us will still be above ground at that point.
>
>
>>
>> All hacks to get around a shortcoming of the product. Nowhere in all
>> their documentation do they recommend this. And what was it you were
>> saying
>> about things like Linux and GNU COBOL not being ready for production
>> environments? :-)
>
> This doesn't even warrant a response because it is so stupid.
>
> I won't be responding further to you so please feel free to have the last
> word.
>
All the best.
"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
> <snip>>>
>>> However, I don't think you would argue that general use of COBOL (at
>>> least in the sense it was used in the last century), has NOT
>>> declined. and is NOT continuing to do so.
>>
>> Wait, is this a typo? You highlighted "NOT".
>
> No, it isn't a typo. "argue" is used in the sense of "posit" or
> "postulate".
>
> It is a standard use of English. Perhaps I understimated the education of
> someone who works in a University.
Well, this seems to be one of those typical English thngs where the meaning
> Bill Gunshannon wrote:
> <snip>>>
>>> However, I don't think you would argue that general use of COBOL (at
>>> least in the sense it was used in the last century), has NOT
>>> declined. and is NOT continuing to do so.
>>
>> Wait, is this a typo? You highlighted "NOT".
>
> No, it isn't a typo. "argue" is used in the sense of "posit" or
> "postulate".
>
> It is a standard use of English. Perhaps I understimated the education of
> someone who works in a University.
is opposite what one reads it to be. :-)
In a ny event, no, I don't think COBOL use has declined. Percentage-wise,
certainly, but that is due to the advent of all the other crap and the fact
that the IT world is now several orders of magnitude larger than it was "in
the last century". I think most of the COBOL is still as it was in the last
century with many new systems (not new locations, additional systems in
places that continue to use COBOL) offsetting the ones that have gone away.
In case your interested, my resume just got refered to for another COBOL
job with a major nationwide system that is not being re-written in some
"more modern" language.
>
>> That is my standpoint.
>
> No, it isn't. You continually refuse to accept that COBOL use in the world
> in general has declined from the 'glory days" of the 1980s. It is really
> stupid to argue this as it is a matter of record. (However, when I show you
> the record, you dismiss it as "You can prove anything with statistics".)
least), hospitals (that aren't on an even more ogscure system call Mumps),
insurance, credit cards, bank, other financials (that aren't on an even more
obscure language called APL), etc. Maybe NZ has abandoned all use of COBOL,
but that does not reflect the reality of the rest of the IT world.
>
> <snip>>
>>>
>>> This issue is covered very well (and fairly) here:
>>>
>>> http://fabfuture.blogspot.co.nz/2014/01/where-has-all-cobol-gone.html
>>>
>>> When it comes to the decline of COBOL I don't have to "assume"
>>> everybody is moving moving off it; it is a matter of record that
>>> many people are.
>>
>> OK, I read it. Hogwash.
>
> Of course. It is unpalatable to you so it is dismissed as hogwash.
It reads like the garbage being spouted at college undergrads that even
they can esaily find information tot he contrary.
>
> You may also find it unpalatable that just because YOU say it is hogwash,
> does not make it so...
Agile. I had to take a course in that when I was working for the Navy.
The instructor started the course with a description of "how things used
to be done" that was totally bogus. And then based the reasoning for
Agile on that erroneous premise. I see much o f the argumetns against
COBOL as the same. They are not reality, they are wishful thinking and
a desire to steer the bus away from COBOL rather than admit that COBOL
people are still needed.
>>>
>>>
> <snip>
>>
>> I keep hearing about these but never see any names. I can provide
>> (and have provided in the past) names of large operations that are not
>> moving now and have no plans to do so in the future.
>
> You are not privy to the strategic plans of any corporation you are not
> employed by and the stated goals of any given corporation can change in an
> instant. Just as quickly as a new IT director is installed.
have no problem admitting it while the companies that are keep mum?
And your comment above works both ways.
>
> It is a simple fact that more and more corporations are being forced to trim
> their exorbitant IT budgets because the world (and their Boards) is waking
> up to the fact that cheaper options are available. It is economic necessity,
> not fashion , that drives it. Resistance to change of the kind that you
> exhibit is being eroded by economic necessity, not rhetoric from me.
working system meet those economic goals?
>
> The network is winning the battle for IT hearts and minds and
> (consequently) the COBOL fortresses you are so proud of will fall. It is
> simply a matter of time.
have a web application I personally wrote to replace a PHP application
that broke and was so obfuscated no one could fix it. (no one could even
figure out how it worked int he first place!!) I have just recently
done a COBOL library that allows database access over a network. Worse
case scenario would be having to write a wrapper in another language to
create an interface between COBOL and some outside systems. But what
COBOL has done well for decades it still does well.
>
> Personally, I don't care at all; I long ago realized what was happening and
> adapted to it. Besides, the pressures which drive it are inexorable. It
> really isn't about academics and business people doing their damnedest to
> bring down COBOL out of spite or fashion consciousness, but you seem to
> think it is.
about Smalltalk, Lisp, Scheme, Oberon, Prolog and yet fail to mention COBOL
at all. Not even for its historical significance.
>
> <snip>>
>>>
>>> Why do you suppose they don't WANT to replace their ORACLE DB with
>>> PostgreSQL?
>>
>> Because in all these case the people who make the decisions respond
>> more to the drone of the salesman than to some blog. No one is out
>> there selling Linux, LibreOffice or PostgreSQL.
>>
> So the only person with a clear grasp of what is needed is you, and all the
> rest of us are stupid fools who do whatever salespeople tell us?
any influence on these decisions. SAP advertises on all the golf TV cover-
ages over here. And HP, an CA, etc. Never saw a single ad for Linux.
Execs read the Wall Street Journal over here, not The Linux Journal.
Microsoft pays millions to keep the ear of the government, RedHat, not a
dime. Hype sells.
>
> "The people who make the decisions" are NOT all idiots.
> Some of them have
> broader experience and training than your own.
current crop of CIOs have never heard of. But then, they weren't even born
when I started in the IT biz. And, having an MBA hardly counts as better
training than I have. :-)
>
> Sales campaigns certainly do influence, but anyone who has been in IT for
> any length of time has learned to be wary of sales pitches and spin. They
> want to see benchmarks and demos.
anything new. Anecdote time: I used to work for Martin Marietta
(now Lockheed Martin). (See, I haven't always been in academia!!!)
We set out to bid on a minicomputer system for a college in the
Northeast US. There were only two serious bidders for this. Us and
Digital. We bid a Prime 50-Series (this was back when they were still
a very promising computer company.) A benchmark was provided. We ran
the benchmark and showed up with an entire box of fanfold paper with
our results on it. DEC showed up with an envelope. The envelope
stated that the computer they were bidding didn't actually exist yet
but if it did the benchmark resulst would be....... No Joke. Care
to wager on who won? The person from the college who was running the
RFP stood up in front of the bidding conference and blatantly stated,
"I don;t care who wins as long as the computer says VAX on the front."
Now, tell me again how benchmarks trump hype...
>
> The faculty members who resist teaching COBOL at your place are not
> intransigent simple-minded clods.
necessarily preparing students to meet the needs of the industry. There
are still a lot of people in academia who are fighting the idea that all
Colleges are are trades schools whose purpose is to help students get
good paying jobs. (There was recently a lot of flack over an interview
with the head of Google when he said that!!)
>
> The Business IT directors who want to move to networked solutions, even if
> it means getting out of COBOL, aren't either.
networked solutions". The two are not mutually exclusive.
>
>
>
>
>> As long as we are throwing URLs around try this one:
>>
>> http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
>
> It is interesting, but it needs updating.
>
> What it DOESN'T tell you is that the OS a database runs under is irrelevant
> if it is being used as a server... I have remote SQL Server databases
> (running on a server farm in the USA) being accessed from both Linux and
> Windows systems all around the World; and 20 years ago I was acessing
> mainframe (DB2 and Datacomm) databases from a PC...
>
> Neither does it tell you about the vagaries of different SQL implemented on
> different platforms and the passionate arguments about what is standard and
> what is "right". I've been in the game of database use for some time now and
> I wouldn't mind a dollar for every time I have had to modify working SQL
> because the client wanted a different RDBMS...
>
> (Using LINQ solves this problem, apart from all the other advantages it
> provides.)
>
> I often get asked "Which is the BEST RDBMS?" (The answer is to be found in
> years of experience and not in tables on Wikipedia)
to Databases the INTERNET is not a valid source? Interesting.
>>
>> It makes for some very interesting reading. But then, the oracle
>> salesman isn't goingt o point you at it and the PostgreSQL salesman
>> just never seems to get that appointment to meet witht he CIO.
>
> Nonsense. CIOs want the product that will best meet their company's needs,
golden parachute.
> within the parameters for selection which they devise. It isn't about
> emotional attachment to proprietary or Open Source as a concept.
>
> I prefer SQL Server because it is well supported and does everything I and
> my clients need. But it is really no better (or worse) than anything else.
> I have tried many RDBMS and coded SQL for all of them, right back to the
> days of MS Access. RDBMS that DON'T meet the requirements of modern SQL
> generally don't stay around very long. A perfect example is System 2000
> which used inverted indexing and handled very large databases at a time when
> all the RDBMS were really toddlers. Ford Motor Company managed their
> inventory with it, to name just one major player. As RDBMS became more
> established a SQL interface was written for System 2000 (very much like what
> they did with ADABAS), but it was too late. The system remains one of the
> most impressive DB inplementations I have ever seen, but today I believe it
> is defunct.
>
> In the same way that SQL became the de facto standard for RDBMS access, I
> believe LINQ and Lambda functions will replace it. As far as I'm concerned,
> SQL is already obsolete.
neither LINQ or Standard SQL. :-)
>>
>>
>> Well, MS tried to use the recent Explorer flaw to force a move, but
>> that seems to have backfired and now there is an update for Xp even
>> after we
>> were assured there would be no such thing. :-)
>
> Another cyncial MS bash (which you claim you don't do...)
fix IE on XP even after stating they would not do so.
>
> They deserve credit for providing an update that was a major inconvenience
> for them, because they recognised it was the right thing to do, not
> criticism because of an imagined paranoid policy to drive people to upgrade.
care less about inconvenience. Bad press was what drove them.
> (I'm still running a couple of XP machines for desktop development and have
> no plans to "upgrade" them. Should I expect the Microsoft thought police to
> break down my door at any moment? I do use Win 8.1 for web development;
> maybe they'll "let me off" for that...) According to you, they are damned if
> they do ("they said they weren't going to") and they are damned if they
> don't (just let people get exploited and then say: "Well, we TOLD you to
> upgrade...")
>
> Your bitterness towards them is sad. (And misplaced...)
Servers here. All of my virtualization is done on MS products. And
I am the one who recommended these products. Hyper-V over VMWare!! No
bitterness here. I just am not blinded by their facade and tend to
actually look at what companies do rather than what they say. (I'm
not an Apple fanboy, either!!)
>>
>>>
>>>
>>>> MS is well known for introducing incompatabilites to force upgrades.
>>>
>>> That is simply urban myth and I'd expect better from you.
>>>
>>> Cite your evidence or retract it.
>>
>> Sorry, I didn't document everytime someone came in with an old Word
>> document that could not be converted by a newer version of Word.
>
> And you didn't because you can't. Every version of Word will read previous
> versions of Word's documents, provided they are saved in Word format.
compatability. Don't get me wrong, unlimited backwards compatability is
both impossible and, in the long run, bad business. But to claim they have
always maintained it is just plain ridiculous. And it was even worse with
the government than academia as they tended to stick with outdated products
in one department wahile others clung to the bleeding edge which brought
these incompatabilites to the forefront.
> (It is
> backward compatible). Older versions of Word may not read documents produced
> by a newer version but there is a free download to enable it. What is unfair
> or unreasonable about that?
>
> You can't cite your evidence and you won't retract, so there is no reason
> for us to continue this correspondence.
>
>
>> I'm
>> the guy who always had to find a fix.
>
> Oh, Boo hoo.... Just exactly why did you go to work in the morning...?
>
>>Wasted a lot of time doing it.
>> And we probably shouldn't even go into the equivalent with versions
>> of Power Point.
>> But some people will never accept that MS has a very
>> shady past. Or that they are unlikely to ever change.
>
> And some people believe that things can never get better and that the world
> is an evil place just waiting to destroy the unwary.
but just being newer does not guarantee that.
>
> I'm personally interested in what they do NOW (although my satisfied
> experience with them extends over some years now) and I don't care (a lot)
> about what they did in the past. I can quote you stories of misbehaviour in
> the past by every major IT company in the world (IBM/BUNCH), some of whom
> are now defunct. What does it prove? Caveat emptor.
>>
>>>
>>>> I don't see this as being any different. When your business model is
>>>> keeping a constantly moving target for the customer to hit, you
>>>> don't survive long it you anchor the product.
>>>
>>> Your paranoia is showing.
>>
>> Just because your paranoid doesn't mean every one isn't out to get
>> you.
>
> A cliche paraded as wit. I shouldn't be surprised.
of it as that is all it deserved.
>>
> <snip>
>>> At any given moment there are probably only a couple in use so it is
>>> no hardship to start them from the Virtual Box console,
>>
>> I have about 50 running at the moment. Access to the host machine
>> consoles from outside of the datacenter is not available and will
>> never be.
>>
>>> but if I needed
>>> to have certain machines always available I'd write a simple startup
>>> script.
>>
>> And that was my point exactly. A hack. What should be a major part
>> of
>> the overall system is not included as part of the product.
>
> This is just unbelieveable. Using script with PCs is no more a "hack" than
> using JCL on a mainframe.
equivalent products thought to make an internal function it's a hack.
Where in the VirtualBox documentation is this explained? Apparently
they didn't even give it a thought even though it is obviously an
operational necessity.
>
> It's like "anything not written in COBOL is a hack".... I was stunned when I
> first read this but after some reflection I see that I shouldn't have been.
to a dozen different OSes. I have never said it was "COBOL or nothing".
Quite the contrary, it is the anti-COBOL people with that opinion.
>
> It's pretty obvious to me that we live in different worlds and I really
> don't like visiting yours, so I won't any more.
>
that the last COBOL program inthe world has been shut down, but I, at least,
know that neither of us will still be above ground at that point.
>
>
>>
>> All hacks to get around a shortcoming of the product. Nowhere in all
>> their documentation do they recommend this. And what was it you were
>> saying
>> about things like Linux and GNU COBOL not being ready for production
>> environments? :-)
>
> This doesn't even warrant a response because it is so stupid.
>
> I won't be responding further to you so please feel free to have the last
> word.
>
Richard
May 12, 2014, 4:59:48 PM5/12/14
to
On Saturday, May 10, 2014 11:04:44 AM UTC+12, Pete Dashwood wrote:
> And you didn't because you can't. Every version of Word will read previous
> versions of Word's documents,
"""In Service Pack 3 for Office 2003, Microsoft disabled support for many older file formats.If you have old Word ... documents, watch out! """
> And you didn't because you can't. Every version of Word will read previous
> versions of Word's documents,
Pete Dashwood
May 12, 2014, 6:43:51 PM5/12/14
to
doesn't guarantee compatibility for those "other" formats (.rtf, .html,
etc.)
I should have been careful to make my statement explicit: Backward
compatibility extends to documents in WORD (.doc or .docx) format.
I bought and used Word 2003 until I replaced it with Word 2007. I never had
it fail to read any documents produced before I bought it (including
documents originally created using Word Perfect).
I haven't tried Word 360 so I don't know how compatible that is, but I'd be
very surprised if it can't read .doc or .docx documents produced by earlier
versions of Word.
Pete Dashwood
May 12, 2014, 7:19:04 PM5/12/14
to
Graham Hobbs wrote:
> On Sun, 11 May 2014 03:08:45 -0500, Arnold Trembley
<snip>
> On Sun, 11 May 2014 03:08:45 -0500, Arnold Trembley
> I read that of MS users 27%-30% are XP (50% in China). Does that sound
> right?
China is interesting.
I intend to look at it and will be contacting the Chinese Trade Centre here
in NZ.
I'm planning a trip, (hopefully in July this year, but it may be postponed
due to pressure of work) to Hong Kong and Shenzen (in mainland China).
You may remember some years back they were talking about training a million
COBOL programmers in China... I'd like to know how far they got with that
and how much use they are making of COBOL.
There have traditionally been two problems with selling software in China:
1. The language barrier.
2. The perceived increased risk of piracy.
Trade commissions can help with the language problem and we now have
anti-piracy measures in place at PRIMA which are running live and have
proven to be very effective with some of our own and our clients' software,
so I'm more confident about talking to China.
http://primacomputing.co.nz/PRIMAMetro/RAV.aspx
I'll happily post here whatever COBOL pertinent information comes out of
this.
I'd very much like to have a Chinese agent for our COBOL migration Toolset.
>
> What might be a realistic percentage.and then translate into 10, 50,
> 100 million, whatever?
>
> What percent would be corporate, what percent John Does'.
Pete.
Richard
May 13, 2014, 3:17:56 PM5/13/14
to
"""All Word files that have a version number that is less than but not equal to Word 6.0 for Windows are blocked from opening. This includes the following file versions: ..."""
Robert Wessel
May 13, 2014, 5:52:36 PM5/13/14
to
conversions.
0 new messages