Discussion:
OpenCOBOL/GNUCobol
(too old to reply)
Bill Gunshannon
2014-04-20 01:18:52 UTC
Permalink
I don;t belong to any of their mailinglists/blogs or wahtever they are
but I am pretty sure ther are people here from the developers, so here's
one for you.

Is GNU COBOL supposed to work on 64bit machines? I tried some stuff
this morning that used CALL and needed to take in a pointer on the
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs at
all. I tracked it down to what looked like a problem taking in the
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.

So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Luuk
2014-04-20 13:24:23 UTC
Permalink
Post by Bill Gunshannon
I don;t belong to any of their mailinglists/blogs or wahtever they are
but I am pretty sure ther are people here from the developers, so here's
one for you.
Is GNU COBOL supposed to work on 64bit machines? I tried some stuff
this morning that used CALL and needed to take in a pointer on the
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs at
all. I tracked it down to what looked like a problem taking in the
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
bill
Google for:
'gnu cobol 64 bits'

second link:
http://www.mycobol.net/downloads/index.php?id=file_529205d3dcc31

I dont think it is......

;-)
Vince Coen
2014-04-20 16:57:15 UTC
Permalink
Hello Bill!
Post by Bill Gunshannon
Is GNU COBOL supposed to work on 64bit machines?
Yes since v1 but I use v2.1 (with rwcs) as X64.
Post by Bill Gunshannon
I tried some stuff
this morning that used CALL and needed to take in a pointer on the
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs at
all. I tracked it down to what looked like a problem taking in the
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can try it
on my box. You can send it as a file attach to my email address above ort
srop me a direct email and I will pass on my normal address for any file
attachment if gmail blows.

If it shows up here I will issues a bug report for it.

Anyone can do this, you just need to have an account on sourceforge and use
the bug report function on the site but I am more than happy to do that for
you.



Vince
Bill Gunshannon
2014-04-20 17:44:31 UTC
Permalink
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Is GNU COBOL supposed to work on 64bit machines?
Yes since v1 but I use v2.1 (with rwcs) as X64.
Post by Bill Gunshannon
I tried some stuff
this morning that used CALL and needed to take in a pointer on the
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs at
all. I tracked it down to what looked like a problem taking in the
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can try it
on my box. You can send it as a file attach to my email address above ort
srop me a direct email and I will pass on my normal address for any file
attachment if gmail blows.
Or, you can grab a copy yourself. :-) It's the Postgresql interface
program written by Brian Tiffin that is in the FAQ.

-------------------------------------------------------------
FreeBSD OC 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 01:46:25 UTC 2014 ***@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386


Before connect:0x00000000
After connect: 0x28c03580
Status: +0000000000
User: bill
call PQexec
0x28c730c0
Version: PostgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled by GCC FreeBSD clang ver
After finish: 0x28c03580
Status: +0000000001
User after: billgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled by GCC FreeBSD clang ver


----------------------------------------------------------------
FreeBSD devel.myhome.westell.com 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 ***@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64


Before connect:00000
After connect: 59872
Segmentation fault (core dumped)
Post by Vince Coen
If it shows up here I will issues a bug report for it.
Anyone can do this, you just need to have an account on sourceforge and use
the bug report function on the site but I am more than happy to do that for
you.
Looking forward to your results. I really don't see much sense in doing
work on 32bit machines any more as I expect they won't be around much
longer.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Vince Coen
2014-04-20 19:23:37 UTC
Permalink
Hello Bill!
Post by Bill Gunshannon
Post by Vince Coen
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can
try it on my box. You can send it as a file attach to my email
address above ort srop me a direct email and I will pass on my
normal address for any file attachment if gmail blows.
Or, you can grab a copy yourself. :-) It's the Postgresql interface
program written by Brian Tiffin that is in the FAQ.
Sorry there is more than one. You will need to send it.

I am assuming here that I do not need to install postgres to test this as
I do not use it!



Vince
Bill Gunshannon
2014-04-20 20:04:52 UTC
Permalink
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Post by Vince Coen
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can
try it on my box. You can send it as a file attach to my email
address above ort srop me a direct email and I will pass on my
normal address for any file attachment if gmail blows.
Or, you can grab a copy yourself. :-) It's the Postgresql interface
program written by Brian Tiffin that is in the FAQ.
Sorry there is more than one. You will need to send it.
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample

I'll email you what I got.
Post by Vince Coen
I am assuming here that I do not need to install postgres to test this as
I do not use it!
I think you would if you plan to compile and run it. I could be wrong,
but I traced the problem to:

call "PQstatus" using by value pgconn returning result end-call

I think the value of pgconn is bogus, maybe truncated to 32bits.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Vince Coen
2014-04-21 12:06:20 UTC
Permalink
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that code
is fairly old and no doubt has changed as has Postgres.

That the problem with the FAQ it is not updated unless someone reports
such and provides an updated text etc.

I am still waiting for one for Mysql/Mariadb for OC v2.

Vince
Bill Gunshannon
2014-04-21 12:41:38 UTC
Permalink
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that code
is fairly old and no doubt has changed as has Postgres.
I find the above confusing. What makes sense? Is the return value
from a COBOL CALL 32 or 64 bits on a 64 bit machine? Is it possible
that the pointer gets truncated when it gets passed back to the calling
COBOL routine?
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone reports
such and provides an updated text etc.
I guess I am confused. I don't see it as problem with the program in
the FAQ. That should work as written regardless of the wordsize of the
host cpu. Isn't that supposed to be one of the strengths of COBOL? :-)
Post by Vince Coen
I am still waiting for one for Mysql/Mariadb for OC v2.
Is theere something different about v2 over v1.1? All my work so far is
with v1.1 as v2 is not in the FreeBSD ports tree yet. If what you want
is an equivalent program for MySQL I can take a look at it. Can't be all
that hard to do assuming there is a library for MySQL.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Pete Dashwood
2014-04-21 23:31:35 UTC
Permalink
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
<snip>>
Post by Bill Gunshannon
I find the above confusing. What makes sense? Is the return value
from a COBOL CALL 32 or 64 bits on a 64 bit machine?
If you are running under Windows:

It depends what is being returned. If it is an object reference it will be 8
bytes, UNLESS the code has been built for a 32 bit CPU, in which case it
will be 4.

If you built the code using a 32 bit implementation of the C libraries then
it will be 4 bytes.

But it should run fine, as long as it is installed in the "right" libraries
on the 64 bit machine. (Too much to go into here but check out WOW64 and
"Program Files (x86)")

64 bit components can call 32 bit ones, but not vice versa, so if your 32
bit COBOL tries to call 64 bit PostgreSQL, you can expect problems.
Post by Bill Gunshannon
Is it possible
that the pointer gets truncated when it gets passed back to the
calling COBOL routine?
Very possible. But there's a lot more to it than that.

I noticed that your PostgreSQL call is passing the connection by value
(unusual for COBOL which normally passes references by reference, although
other languages (like C...) can pass a reference type by value. ) The only
way I know of to fix this is to run an Object Browser on the component you
are calling and check the properties and the method signature. That will
tell you what it expects and what it returns so you can make sure you give
it what it needs. (If you have Microsoft Office on the machine there is a
good Object Browser provided with VBA...)

I suspect your 64 bit machine has a 64 bit implementation of PostgreSQL and
that is why it all goes pear shaped. Either rebuild the COBOL for 64 bit (if
that is available) or download a 32 bit implementation of PostgreSQL to your
64 bit machine.

That's why it runs fine on your 32 bit VM.
Post by Bill Gunshannon
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I guess I am confused. I don't see it as problem with the program in
the FAQ. That should work as written regardless of the wordsize of
the host cpu. Isn't that supposed to be one of the strengths of
COBOL? :-)
It is platform acrhitecture, not COBOL, that needs to be carefully complied
with.

<snip>

HTH,

Pete.
--
I used to write COBOL...now I can do anything."
Bill Gunshannon
2014-04-22 14:55:42 UTC
Permalink
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
<snip>>
Post by Bill Gunshannon
I find the above confusing. What makes sense? Is the return value
from a COBOL CALL 32 or 64 bits on a 64 bit machine?
As stated, FreeBSD. Haven't really tried any of this under Windows Server
but might be fun to see what happens.
Post by Pete Dashwood
It depends what is being returned. If it is an object reference it will be 8
bytes, UNLESS the code has been built for a 32 bit CPU, in which case it
will be 4.
Sorry Pete. It's real COBOL, not an object in sight.
Post by Pete Dashwood
If you built the code using a 32 bit implementation of the C libraries then
it will be 4 bytes.
Both systems were built on the same machines using the default Makefiles.
One would have hoped the developers would have gotten it right. (I know,
rather naive of me!!!)
Post by Pete Dashwood
But it should run fine, as long as it is installed in the "right" libraries
on the 64 bit machine. (Too much to go into here but check out WOW64 and
"Program Files (x86)")
Not on FreeBSD. :-)
Post by Pete Dashwood
64 bit components can call 32 bit ones, but not vice versa, so if your 32
bit COBOL tries to call 64 bit PostgreSQL, you can expect problems.
Post by Bill Gunshannon
Is it possible
that the pointer gets truncated when it gets passed back to the
calling COBOL routine?
Very possible. But there's a lot more to it than that.
Not really. If the library passes back a 64 bit pointer and the calling
procedure only has 32 bits of room, what would you expect to happen?
Post by Pete Dashwood
I noticed that your PostgreSQL call is passing the connection by value
(unusual for COBOL which normally passes references by reference, although
other languages (like C...) can pass a reference type by value. )
I didn't right the compiler. That is the method they give for calling
this procedure. And the fact that it does work on 32 bit machines
pretty much guarantees it's right.
Post by Pete Dashwood
The only
way I know of to fix this is to run an Object Browser on the component you
are calling and check the properties and the method signature. That will
tell you what it expects and what it returns so you can make sure you give
it what it needs. (If you have Microsoft Office on the machine there is a
good Object Browser provided with VBA...)
Pete, the whole world isn't a Windows box.
Post by Pete Dashwood
I suspect your 64 bit machine has a 64 bit implementation of PostgreSQL and
that is why it all goes pear shaped. Either rebuild the COBOL for 64 bit (if
that is available) or download a 32 bit implementation of PostgreSQL to your
64 bit machine.
That's why it runs fine on your 32 bit VM.
Both systems were built on both machines with default settings. If the
developers got to wrong, I am unlikely to be able to fix it.
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I guess I am confused. I don't see it as problem with the program in
the FAQ. That should work as written regardless of the wordsize of
the host cpu. Isn't that supposed to be one of the strengths of
COBOL? :-)
It is platform acrhitecture, not COBOL, that needs to be carefully complied
with.
Not necessarily. I have seen a lot iof Open Source code that was
developed on 32 bit machines that are assumed to be 64bit safe.
This is not necessarily true. Especially if there is anything
like pointer arithmetic involved. Maybe if people didn't turn off
warnings and instead fixed the cause a lot of these kinds of problems
would go away.

I am not criticizing the Open/GNU COBOL people. i think the compiler is
nice but I also know there is very little documentation on using this
COBOL with databases. That likely means not many people have tried or
figured it out yet. That means there may be latent bugs in the methods
used to do this. Having done a bit of this kind of programming (recently
even!!!) using commercial systems I have an interest in seeing it get more
widespread use in the Open Source world. I am even looking into the
possibility of writting a pre-compiler to make it easier. But first, I
have t make it work. For now, it looks like I will be doing most of my
work on the 32 bit system as once I am done everything I do should be
portable to 64 bits assuming there are not interface problems in the
underlying packages. We will see.

And because I would like to try the newer version of the compiler and it
won't work on FreeBSD I think it is time to set up another couple of VM 's
and put Server 2012 on them. Could be a real blast.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Pete Dashwood
2014-04-23 04:15:30 UTC
Permalink
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
<snip>>
Post by Bill Gunshannon
I find the above confusing. What makes sense? Is the return value
from a COBOL CALL 32 or 64 bits on a 64 bit machine?
As stated, FreeBSD. Haven't really tried any of this under Windows
Server but might be fun to see what happens.
Post by Pete Dashwood
It depends what is being returned. If it is an object reference it
will be 8 bytes, UNLESS the code has been built for a 32 bit CPU, in
which case it will be 4.
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to PostgreSQL is an
object reference inasmuch as it points to an object. (An instance of
PostgreSQL)

You are invoking a method of PostgreSQL (whether you like it or not) because
the real world runs on objects.

http://www.postgresql.org/docs/9.1/static/libpq-connect.html

The above docs expalin it quite clearly. You can see the definition of
PQStatus and the values it is expected to hold.

You could reasonably expect this will be a 64 bit pointer on a 64 bit system
(where you have a 64 bit implementation of PostgreSQL), or a 32 bit one on
32 bit systems.
Post by Bill Gunshannon
Post by Pete Dashwood
If you built the code using a 32 bit implementation of the C
libraries then it will be 4 bytes.
Both systems were built on the same machines using the default
Makefiles. One would have hoped the developers would have gotten it
right. (I know, rather naive of me!!!)
The Open COBOL developers have no control over the build of PostgreSQL.
Post by Bill Gunshannon
Post by Pete Dashwood
But it should run fine, as long as it is installed in the "right"
libraries on the 64 bit machine. (Too much to go into here but check
out WOW64 and "Program Files (x86)")
Not on FreeBSD. :-)
Fair enough.
Post by Bill Gunshannon
Post by Pete Dashwood
64 bit components can call 32 bit ones, but not vice versa, so if
your 32 bit COBOL tries to call 64 bit PostgreSQL, you can expect
problems.
I believe this is the nub of your actual problem.
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Is it possible
that the pointer gets truncated when it gets passed back to the
calling COBOL routine?
Very possible. But there's a lot more to it than that.
Not really. If the library passes back a 64 bit pointer and the
calling procedure only has 32 bits of room, what would you expect to
happen?
In your case, you have a 32 bit COBOL trying to access a 64 bit PostgreSQL.
(when it is running on a 64 bit platform). It's pretty clear that the
pointers will give trouble. It will run fine until it gets to the point
where it tries to load and execute 64 bit code within the 32 bit process.
Post by Bill Gunshannon
Post by Pete Dashwood
I noticed that your PostgreSQL call is passing the connection by
value (unusual for COBOL which normally passes references by
reference, although other languages (like C...) can pass a reference
type by value. )
I didn't right the compiler. That is the method they give for calling
this procedure. And the fact that it does work on 32 bit machines
pretty much guarantees it's right.
The problem doesn't arise if both PostgreSQL and COBOL are built for 32 bit
(or for 64 bit and running on a 64 bit platform). In all other cases, it
cannot work.
Post by Bill Gunshannon
Post by Pete Dashwood
The only way I know of to fix this is to run an Object Browser on
the component you are calling and check the properties and the
method signature. That will tell you what it expects and what it
returns so you can make sure you give it what it needs. (If you have
Microsoft Office on the machine there is a good Object Browser
provided with VBA...)
Pete, the whole world isn't a Windows box.
Jeez, man, it is a suggestion. And I prefaced the whole post by saying it
applies to Windows. If you can't figure out why links and references are not
working then you need an Object Browser (or a Typelib) to see what the
actual object code is expecting. Whether it is on Windows or anywhere
else...

I'll spell it out...

COBOL PG BOX RESULT

32 bit 32 bit 32 bit
OK
32 bit 64 bit 32 bit PG
won't run, so not possible
32 bit 32 bit 64 bit
OK
32 bit 64 bit 64 bit
pointer crash when 64 bit code is called from COBOL
64 bit 32 bit 32 bit
COBOL code won't run, so impossible
64 bit 64 bit 32 bit
Neither COBOL nor PostgreSQL will run, so impossible
64 bit 32 bit 64 bit
OK
64 bit 64 bit 64 bit
OK

In this case it isn't even that hard... your database system is predicated
on a different architecture from your COBOL system. I already told you what
you need to do.

Use 64 bit COBOL or 32 bit PostgreSQL on your 64 bit platform.. 32 bit
PostgreSQL will run on either 32 or 64 bit platforms; 64 bit PostgreSQL
won't.
Post by Bill Gunshannon
Post by Pete Dashwood
I suspect your 64 bit machine has a 64 bit implementation of
PostgreSQL and that is why it all goes pear shaped. Either rebuild
the COBOL for 64 bit (if that is available) or download a 32 bit
implementation of PostgreSQL to your 64 bit machine.
That's why it runs fine on your 32 bit VM.
Both systems were built on both machines with default settings. If
the developers got to wrong, I am unlikely to be able to fix it.
Sure, blame the developers... why not? Everyone else does. The developers
are not responsible for you trying to make 32 bit code call 64 bit code.
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I guess I am confused. I don't see it as problem with the program
in the FAQ. That should work as written regardless of the wordsize
of the host cpu. Isn't that supposed to be one of the strengths of
COBOL? :-)
It is platform acrhitecture, not COBOL, that needs to be carefully
complied with.
Not necessarily.
Yes, necessarily. 32 bit code physically cannot call 64 bit code unless some
very esoteric options are in place (both at build and run times) and these
are not the norm. (Even then it is severely limited in what it can do.) I
speak as one with considerable experience in this field and with the hair
loss to prove it...
Post by Bill Gunshannon
I have seen a lot of Open Source code that was
developed on 32 bit machines that are assumed to be 64bit safe.
This is not necessarily true.
Not necessarily, but generally so. Normally, 32 bit code IS 64 bit safe and
will run fine on 64 bit platforms. The converse is NOT true.
Post by Bill Gunshannon
Especially if there is anything
like pointer arithmetic involved.
Problems with pointer arithmetic are going to happen on any platform unless
proper care is taken. That is nothing to do with 32/64 bit compatibility.
Post by Bill Gunshannon
Maybe if people didn't turn off
warnings and instead fixed the cause a lot of these kinds of problems
would go away.
Maybe if people didn't use pointer arithmetic there would be no pointer
arithmetic problems.
Post by Bill Gunshannon
I am not criticizing the Open/GNU COBOL people. i think the compiler
is nice but I also know there is very little documentation on using
this COBOL with databases. That likely means not many people have
tried or figured it out yet. That means there may be latent bugs in
the methods used to do this. Having done a bit of this kind of
programming (recently even!!!) using commercial systems I have an
interest in seeing it get more widespread use in the Open Source
world.
Yeah... good luck with that.
Post by Bill Gunshannon
I am even looking into the possibility of writting a
pre-compiler to make it easier. But first, I have t make it work.
For now, it looks like I will be doing most of my work on the 32 bit
system as once I am done everything I do should be portable to 64
bits assuming there are not interface problems in the underlying
packages. We will see.
It still won't work if you try and use it with 64 bit code that is built as
64 bit.

I'm done.

Pete.
--
"I used to write COBOL...now I can do anything."
b***@gmail.com
2014-04-23 07:51:34 UTC
Permalink
Post by Pete Dashwood
Post by Bill Gunshannon
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to PostgreSQL is an
object reference inasmuch as it points to an object. (An instance of
PostgreSQL)
You are invoking a method of PostgreSQL (whether you like it or not) because
the real world runs on objects.
I'm sorry, but I have to disagree with that sentiment. The "real" world runs on stacks inside numerically addressed memory cells, supported by registers, gates and wires. The conceptual, virtual world runs on higher level objects. .o and .so Dynamically Shared Object files are not OO objects (unless of course, you write up a linker Class, that happens to hold instances of .o file objects - but again, that whole chain will still run in a von neumann numerically addressed mode in today's real world).

Either way, still a lot of fun developing in the 3rd millennium. Perhaps too much fun. GNU/Linux, Fossil, GNU Cobol, vi, emacs, emacs-evil and org-mode?, black text on a white background? Where was that when I was little? Other people enjoying Eclipse and IDEs, the all in frameworks, and the immensely powerful toolkits; good time to be a programmer. Spoilt for choice. :-)

(meandering again)
Oh, and for being old, COBOL is way behind on just about every internet front. We can, and should, try to change that now.
Post by Pete Dashwood
http://www.postgresql.org/docs/9.1/static/libpq-connect.html
The above docs expalin it quite clearly. You can see the definition of
PQStatus and the values it is expected to hold.
You could reasonably expect this will be a 64 bit pointer on a 64 bit system
(where you have a 64 bit implementation of PostgreSQL), or a 32 bit one on
32 bit systems.
Post by Bill Gunshannon
Post by Pete Dashwood
If you built the code using a 32 bit implementation of the C
libraries then it will be 4 bytes.
Both systems were built on the same machines using the default
Makefiles. One would have hoped the developers would have gotten it
right. (I know, rather naive of me!!!)
This will be addressed on the GNU Cobol side, but to be honest, it hasn't come up on our builds. Roger did world class excellent work, but the 2.0 tree is work in progress, there are a fair number of tagged code lines that need inspection and completion. That will happen.

Until then, the COBOL 85 features of GNU Cobol are intact, the newer 20xx draft features need work. In general, it all works grand, but before it is tagged reliable, the edges need grouting (and more cross-platforming). BY VALUE with duck typing literals, for instance. What is BY VALUE 3.141. on a call stack for foreign functions? float? double? SIZE IS was added, and that needs work too.

There is scaffolding in place for this support, but there are some rather delicate codegen issues. (The Bison/Flex graph emitter for the GNU Cobol parser has somewhere in the range of 2,000,000 edges, and uncounted code flow generation possibilities, and for the now, some of them are wrong.

Very unlikely to ever "look" like it's working, when it isn't. These stack misalignment issues flame out instead, and workarounds will exist. I had to wrestle with some of that this evening, while getting a PLplot sample coded up. Passing float-long intermingled with int stack framing. Took a few tries, but it works nicely using intermediate fields for some of the literals and tricks with the sometimes nulls. Umm, on my test machine with its bit-edness.

(Works nicely, but the PLplot developers ... and laser red on black...not my first choice of colour palette - especially when the goal is financial plotting; so the first mod is to set laser green instead.) :-)

COBOL keeps up, and GNU Cobol will improve as we go.

Cheers,
Brian
Pete Dashwood
2014-04-23 09:47:12 UTC
Permalink
Post by b***@gmail.com
Post by Pete Dashwood
Post by Bill Gunshannon
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to
PostgreSQL is an
object reference inasmuch as it points to an object. (An instance of
PostgreSQL)
You are invoking a method of PostgreSQL (whether you like it or not) because
the real world runs on objects.
I'm sorry, but I have to disagree with that sentiment. The "real"
world runs on stacks inside numerically addressed memory cells,
supported by registers, gates and wires.
Yes, I would aree that is a valid "world view" but it is far too low level
for most people...
Post by b***@gmail.com
The conceptual, virtual
world runs on higher level objects. .o and .so Dynamically Shared
Object files are not OO objects (unless of course, you write up a
linker Class, that happens to hold instances of .o file objects - but
again, that whole chain will still run in a von neumann numerically
addressed mode in today's real world).
Agreed. But, for development it is the conceptual world that matters. If a
virtual view gives a basis that is easily comprehensible and can be expanded
on to develop stuff, then that is more practical (in my opinion) than using
a view that has so many details you keep tripping over them.

However, I don't believe there is a "right" or a "wrong" here. People should
view their world in a way that is comfortable for them and has at least a
passing analog of "reality" (whatever that is...)

I find it easier to think of classes and objects than I do to visualize the
same entities as locations in storage connected by wires. That isn't wrong.
Neither is it wrong to visualize storage locations connected by wires...
Post by b***@gmail.com
Either way, still a lot of fun developing in the 3rd millennium.
Perhaps too much fun. GNU/Linux, Fossil, GNU Cobol, vi, emacs,
emacs-evil and org-mode?, black text on a white background? Where
was that when I was little? Other people enjoying Eclipse and IDEs,
the all in frameworks, and the immensely powerful toolkits; good time
to be a programmer. Spoilt for choice. :-)
(meandering again)
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?

Are you going to develop for web servers, phones, pads, and mobile devices
in COBOL?

Whilst I agree this is (or can be made...) possible, I have to ask: Why?

Everything needed to do this is available right now and for free. (C#, XAML,
Javascript, CSS, JSON)

Do you seriously think that "COBOL programmers" are going to embrace this?

(Given they are the same guys who rejected OO COBOL, good luck with that...)


<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get to work
on it when you can, it is a labour of love, the result will be fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't. These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.

Pete.
--
"I used to write COBOL...now I can do anything."
b***@gmail.com
2014-04-23 14:27:02 UTC
Permalink
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Post by Bill Gunshannon
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to
PostgreSQL is an
object reference inasmuch as it points to an object. (An instance of
PostgreSQL)
You are invoking a method of PostgreSQL (whether you like it or not)
because
the real world runs on objects.
I'm sorry, but I have to disagree with that sentiment. The "real"
world runs on stacks inside numerically addressed memory cells,
supported by registers, gates and wires.
Yes, I would aree that is a valid "world view" but it is far too low level
for most people...
Post by b***@gmail.com
The conceptual, virtual
world runs on higher level objects. .o and .so Dynamically Shared
Object files are not OO objects (unless of course, you write up a
linker Class, that happens to hold instances of .o file objects - but
again, that whole chain will still run in a von neumann numerically
addressed mode in today's real world).
Agreed. But, for development it is the conceptual world that matters. If a
virtual view gives a basis that is easily comprehensible and can be expanded
on to develop stuff, then that is more practical (in my opinion) than using
a view that has so many details you keep tripping over them.
However, I don't believe there is a "right" or a "wrong" here. People should
view their world in a way that is comfortable for them and has at least a
passing analog of "reality" (whatever that is...)
I find it easier to think of classes and objects than I do to visualize the
same entities as locations in storage connected by wires. That isn't wrong.
Neither is it wrong to visualize storage locations connected by wires...
Post by b***@gmail.com
Either way, still a lot of fun developing in the 3rd millennium.
Perhaps too much fun. GNU/Linux, Fossil, GNU Cobol, vi, emacs,
emacs-evil and org-mode?, black text on a white background? Where
was that when I was little? Other people enjoying Eclipse and IDEs,
the all in frameworks, and the immensely powerful toolkits; good time
to be a programmer. Spoilt for choice. :-)
(meandering again)
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile devices
in COBOL?
Yes.
Post by Pete Dashwood
Whilst I agree this is (or can be made...) possible, I have to ask: Why?
Why not? We are only just starting free and open COBOL sharing; watch, it'll turtle on growing for a long time now, coming out of surprising corners.
Post by Pete Dashwood
Everything needed to do this is available right now and for free. (C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...

So back to mobile and new domains,

cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui, and server in a single application. Prototype was 300 lines of COBOL, with a plugin architecture that came "for free" with the GNU Cobol CALL implementation. It allows for http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a CALL "reportmodule-06" END-CALL. The sample was a Report Writer program, used for a Hercules mainframe emulator tutorial. Worked with a single external file definition tweak. cobweb uses a mapped linker name as reflective as you'd like it to be, or as inconveniently secure as it may need to be. Compiled but capable of on the fly replacement of RESTful targets or query parsers.

Now part of Canonical's Juju Charm demonstrations. In the cloud.

Part of that 300 lines was a GTK interface, simple, a calendar, just to prove the data passing, and to work around lack of COBOL's general inability to generate subprograms that have void return signatures. There is no PROCEDURE DIVISION RETURNING OMITTED (yet). meandering...

So, a little layer of C is added, not a biggy in terms of the tectonics and linkage, just add a .c file to the cobc command line. voidcall.c is a two liner that wraps COBOL subprograms so that they can take part in callbacks to and from GTK.

Application programmers need only worry about COBOL if so desired. But it's a lot more fun embedding the JSON (done - using FUNCTION-ID, code can read as

MOVE load-json(read-url("http://site.moc/rest/thing", curl-status), json-status) TO json-block

Real soon now. Application friendly function repositories.

Javascript (two engines so far - node.js on the horizon)

CSS plays well with the fossil based cobweb idea.

C#, nah, Vala for that angle. XAML (I had to look up - and then nah, .NET is not my area of bliss, don't care really, but I'll help anyone that tries to link it in with the GNU Cobol ecosystem.

Oh, yeah, back to the GTK and the calendar test. GDK_BACKEND=broadway. GUI on the web for free.

Leading up to...

Federico Priolo has an Object COBOL inspired pre-processor using

invoke gtk-form "createform"
move "red" to "forecolor" of button1

etc, (with Glade support for full on XML design sheets)

Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace this?
Yes, now that it is free, freedom free, yes I do. In droves? Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with that...)
Thanks. :-)

But deep down, I reject most OO too. I prefer thinking in stacks, and addresses and contents of addresses. A zebra is not a zebra inside RAM but it's a pointer to an address that when jumped to, exhibits conceptual zebra behaviour, by changing the state of some electronics, manipulating a stack frame and coming back to the address it is supposed to.
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get to work
on it when you can, it is a labour of love, the result will be fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST test suite. Ready for production.

The COBOL 20xx features are generally reliable, and if not, you will know immediately.

It may be a turtle race, but GNU Cobol is in for the long haul.
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't. These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)

I get the impression you believe, as in believe, we'd be better off in CLR .NET space. I could be wrong in the impression, electronic text being what it is.

I believe, as in believe, we'd be better off in GNU/Linux space and coding to POSIX. I'm probably going to enter and exit a death bed believing that.

I'll also opine, that both beliefs are sound and right, the spheres of influence separate when need be and intersecting when need be. Both viable (along with other spheres) and capable of self supporting spans of relevance with interested and engaged practitioners.

I've studied quite a few programming environments, and have come to the conclusion that none are best. All are good, some excel in some areas, some lag. I've also come to the conclusion that if you have C you can glue any other A and B together with any other X,Y,Z, for the better, approaching best.

For many real world problems, COBOL in the mix slides things up the curve of good. COBOL at the centre is intriguing, and worthy of exploration. New angles of opportunity every day.

Cheers,
Brian
Post by Pete Dashwood
Pete.
--
"I used to write COBOL...now I can do anything."
Pete Dashwood
2014-04-23 23:51:20 UTC
Permalink
<snip>
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile devices
in COBOL?
Yes.
Post by Pete Dashwood
Whilst I agree this is (or can be made...) possible, I have to ask: Why?
Why not?
Because there is already a better mousetrap and the wheel doesn't need
re-inventing, basically.

BUT, if you are doing it for fun (and that is a really good reason to do
anything) then you can certainly offer another alternative and the world is
a richer place for it.
Post by b***@gmail.com
We are only just starting free and open COBOL sharing;
watch, it'll turtle on growing for a long time now, coming out of
surprising corners.
That's a fair response. I believe in enthusiasm and yours is commendable.

I commented already on the non-commercial nature of what you're doing, but
that is actually a plus point in this case. You are not being driven by a
commercial schedule, rather by your own passion to do it. As you say, it can
turtle on for as long as you (plural) want to keep doing it.

I believe you (plural) will produce something of very good quality and it
will be useful. (In fact what has been produced already is very good...)

But will it be "COBOL" in the sense that the people who use this forum
understand that term?

That was what I meant when I asked: Why?

If the "COBOL community" are expecting something that is familiar and
comfortable and what they actually get is something that requires a
knowledge of the alphabet soup of acronyms sprinkled through your post,
there may be resistance to embracing it because it isn't "COBOL", as COBOL
is perceived by most people.

Nevertheless, for those who are prepared to do some homework and learn about
the facilities it provides, it may well be a route forward. However, it
seems to me that the people who are prepared to do that, can do it without
COBOL and that was why I asked: Why?
Post by b***@gmail.com
Post by Pete Dashwood
Everything needed to do this is available right now and for free. (C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...
Yes, it is, thanks to guys like you and Roger and the others who indulged
their desire to make it so.

I don't think anyone at Micro Focus or Fujitsu is losing sleep over GNU
COBOL at the moment, though.

There is still a ways to go before the product can be viable for "industrial
strength" use (You know the facilities I would need before we could move to
it).
Post by b***@gmail.com
So back to mobile and new domains,
cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui,
and server in a single application. Prototype was 300 lines of
COBOL, with a plugin architecture that came "for free" with the GNU
Cobol CALL implementation. It allows for
http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a
CALL "reportmodule-06" END-CALL. The sample was a Report Writer
program, used for a Hercules mainframe emulator tutorial. Worked
with a single external file definition tweak. cobweb uses a mapped
linker name as reflective as you'd like it to be, or as
inconveniently secure as it may need to be. Compiled but capable of
on the fly replacement of RESTful targets or query parsers.
Yes... quite so.... Hang on while I find my Swahili dictionary... :-)
Post by b***@gmail.com
Now part of Canonical's Juju Charm demonstrations. In the cloud.
Part of that 300 lines was a GTK interface, simple, a calendar, just
to prove the data passing, and to work around lack of COBOL's general
inability to generate subprograms that have void return signatures.
There is no PROCEDURE DIVISION RETURNING OMITTED (yet).
meandering...
So, a little layer of C is added, not a biggy in terms of the
tectonics and linkage, just add a .c file to the cobc command line.
voidcall.c is a two liner that wraps COBOL subprograms so that they
can take part in callbacks to and from GTK.
This is a foreign world to me (and, I suspect, to many others...)

I can't relate to it unless I make a considerable effort to leave the world
I know and spend time in this one.

If I were to do that I would want some reward for doing so. I'm too old to
go exploring just because I like adventure... :-)

The reward being offered is that I can use COBOL to program my phone... (but
I need to go back to using command lines and parameters and low level
knowledge of all kinds of packages and libraries and, while I COULD do that,
I'd really rather not...)

I already moved on from COBOL and don't need it any more.

(I'd still use GNU COBOL in my business because our clients are still using
COBOL, but I don't personally use it any more and all of our software
development is now in C#.)

I already have excellent (free) tools that let me program my phone should I
so desire. And I don't have to leave my comfort zone to use them.

That comes back to my "Why?"
Post by b***@gmail.com
Application programmers need only worry about COBOL if so desired.
But it's a lot more fun embedding the JSON (done - using FUNCTION-ID,
code can read as
MOVE load-json(read-url("http://site.moc/rest/thing", curl-status),
json-status) TO json-block
That's quite cool... :-)

But having the IDE do it for me is even cooler...
Post by b***@gmail.com
Real soon now. Application friendly function repositories.
Javascript (two engines so far - node.js on the horizon)
CSS plays well with the fossil based cobweb idea.
C#, nah, Vala for that angle. XAML (I had to look up - and then nah,
.NET is not my area of bliss, don't care really, but I'll help anyone
that tries to link it in with the GNU Cobol ecosystem.
Well, .NET IS my area of bliss (and I suspect I am not the only one on the
planet who loves it...) so I guess we diverge at that point.
Post by b***@gmail.com
Oh, yeah, back to the GTK and the calendar test.
GDK_BACKEND=broadway. GUI on the web for free.
Leading up to...
Federico Priolo has an Object COBOL inspired pre-processor using
invoke gtk-form "createform"
move "red" to "forecolor" of button1
etc, (with Glade support for full on XML design sheets)
Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace this?
Yes, now that it is free, freedom free, yes I do. In droves?
Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Yes. I agree. Actually, even if NOBODY embraced it (and I don't believe that
will be the case) it is still worthwhile from your point of view because the
exercise of doing it is a real challenge.

That's why I support what you (plural) are doing and give all of you
respect.
Post by b***@gmail.com
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with that...)
Thanks. :-)
But deep down, I reject most OO too. I prefer thinking in stacks,
and addresses and contents of addresses. A zebra is not a zebra
inside RAM but it's a pointer to an address that when jumped to,
exhibits conceptual zebra behaviour, by changing the state of some
electronics, manipulating a stack frame and coming back to the
address it is supposed to.
We already discussed world views.

As long as we both agree it is a zebra, we are on safe ground.
Post by b***@gmail.com
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get to work
on it when you can, it is a labour of love, the result will be fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST
test suite. Ready for production.
The COBOL 20xx features are generally reliable, and if not, you will know immediately.
It may be a turtle race, but GNU Cobol is in for the long haul.
Unfortunately, some of us are not getting any younger... Long haul races may
not be our forte... :-)

I hope I live to see you deliver the final product.
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't.
These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)
I get the impression you believe, as in believe, we'd be better off
in CLR .NET space. I could be wrong in the impression, electronic
text being what it is.
No, I'd like it if you were in that space, but I don't think you are wrong
for going the route you are.

Obviously, I run a business where all of the customers use Microsoft
software (particularly .NET which is now part of the OS install). When I
made a decision to provide software and services I had to look where the
marketplace is and that's why I'm into .NET. For any business to succeed
you need to go where the people are...

When I started, I wasn't particularly impressed by MS as a company or even
their products. However, during the ensuing years I have seen them actually
try to be better and today I have no complaints. The recent (say, from
2007...) implementations of SQL Server, Visual Studio, MS Office, .NET, C#
are all really good in my opinion. On the (infrequent) occasions when I have
needed to talk to them they have been helpful and courteous and problems
have always been resolved. They stand behind their products and that has not
been my experience with Open Software (I had a terrible time trying to get
the PostgreSQL ODBC driver fixed). So, yes, I'm a fan of those nice people
at Microsoft :-) But that doesn't mean I don't care about the alternatives.
One of these days, I have promised myself to install Linux and get into the
LAMP world but so far, I simply haven't had time. (I did a foray some years
back where I wrote a C# program and ran it under Mono on a friend's machine.
... to my surprise it worked perfectly in both .NET and Mono, but I simply
haven't had time to pursue that). I'm currently working on writing factories
to generate C# code for LINQ access in the Data Access Layer provided by
our Toolset. I don't get time out to indulge myself...(apart from coming
here occasionally ) :-)

Getting back to GNU COBOL... Commercially, I think you'd probably be better
off in the CLR .NET space, but what you are doing ISN'T commercial. (At
least, not at the moment...) If you produce a COBOL product that won't run
under Windows, then I think that would be a pity. But that isn't your
intention is it?
Post by b***@gmail.com
I believe, as in believe, we'd be better off in GNU/Linux space and
coding to POSIX. I'm probably going to enter and exit a death bed
believing that.
I don't think you are wrong.
Post by b***@gmail.com
I'll also opine, that both beliefs are sound and right, the spheres
of influence separate when need be and intersecting when need be.
Both viable (along with other spheres) and capable of self supporting
spans of relevance with interested and engaged practitioners.
I've studied quite a few programming environments, and have come to
the conclusion that none are best.
I agree. There are some environments that meet your defined criteria for
specifc developments, better than others.
Post by b***@gmail.com
All are good, some excel in some
areas, some lag. I've also come to the conclusion that if you have C
you can glue any other A and B together with any other X,Y,Z, for the
better, approaching best.
Yes, I see a resurgence in C (largely driven by Acadaemia) and I understand
why it is happening.

But, as I noted elsewhere, this is at a lower level than most people really
want to work.

I enjoy using Visual Studio to write C#, every bit as much as I enjoyed
writing COBOL in mainframe and PC environments for around 30 years. My
knowledge is expanding and that empowers me to do more in less time, it is
very satisfying. The original COBOL SQL DAL development for the PRIMA
Migration Toolset took a bit over 2 years to design and implement; the new
C# LINQ DAL is taking around 4 months and I'm hoping to have it ready by mid
June...
Post by b***@gmail.com
For many real world problems, COBOL in the mix slides things up the
curve of good. COBOL at the centre is intriguing, and worthy of
exploration. New angles of opportunity every day.
"COBOL" in the sense that you are using it, maybe.

In the traditional (COBOL '85) sense... not so much.

Cheers,

Pete
--
"I used to write COBOL...now I can do anything."
Bill Gunshannon
2014-04-24 14:38:18 UTC
Permalink
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile devices
in COBOL?
Yes.
Post by Pete Dashwood
Whilst I agree this is (or can be made...) possible, I have to ask: Why?
Why not?
Because there is already a better mousetrap and the wheel doesn't need
re-inventing, basically.
Except for those caes where there is existing COBOL code that is not going
away and could use cleaner, more efficient ways to interface with the
outside world.
Post by Pete Dashwood
BUT, if you are doing it for fun (and that is a really good reason to do
anything) then you can certainly offer another alternative and the world is
a richer place for it.
There are a lot of programs in use today that had no real commercial
need at the time of their creation, and yet, they have had tremendous
commercial success. Like Linux.
Post by Pete Dashwood
Post by b***@gmail.com
We are only just starting free and open COBOL sharing;
watch, it'll turtle on growing for a long time now, coming out of
surprising corners.
That's a fair response. I believe in enthusiasm and yours is commendable.
I commented already on the non-commercial nature of what you're doing, but
that is actually a plus point in this case. You are not being driven by a
commercial schedule, rather by your own passion to do it. As you say, it can
turtle on for as long as you (plural) want to keep doing it.
See comment above. That COBOL gig I did back in 2012 could easily be
replaced with Open COBOL and PostgreSQL on Linux or BSD. What would
you estimate the savings would be considering that they currently use
Oracle, MicroFocus and AIX? And before you say "but the rest of the
world doesn't use Open COBOL and PostgreSQL on Linux or BSD" note that
this is a closed system that with two (possibly threee) sites accessing
one central database using what are really simple COBOL programs.
Post by Pete Dashwood
I believe you (plural) will produce something of very good quality and it
will be useful. (In fact what has been produced already is very good...)
But will it be "COBOL" in the sense that the people who use this forum
understand that term?
That was what I meant when I asked: Why?
If the "COBOL community" are expecting something that is familiar and
comfortable and what they actually get is something that requires a
knowledge of the alphabet soup of acronyms sprinkled through your post,
there may be resistance to embracing it because it isn't "COBOL", as COBOL
is perceived by most people.
So then, are you saying that IBM COBOL that uses calls to CICS is not
really COBOL? Seems it has been accepted readily by the COBOL community
and probably makes up a major part of the massive existing COBOL base
out there.
Post by Pete Dashwood
Nevertheless, for those who are prepared to do some homework and learn about
the facilities it provides, it may well be a route forward. However, it
seems to me that the people who are prepared to do that, can do it without
COBOL and that was why I asked: Why?
Because all kinds of COBOL is still out there. Even with strong desires
to re-write it in "a more modern langauge" it is often found to be untenable
for a number of reasons. I have done CGI in COBOL. Works really well.
And is a damn sight easier to maintain than the PHP it was intended to
replace. Many places with large COBOL backends are currently writing
"wrappers" in things like Java and PHP to make the data web accessable.
IBM put Web hooks in CICS. A more general impementation of something
like this could make Open COBOL much more commercially viable than I
expect you are willing to accept.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Everything needed to do this is available right now and for free. (C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...
Yes, it is, thanks to guys like you and Roger and the others who indulged
their desire to make it so.
I don't think anyone at Micro Focus or Fujitsu is losing sleep over GNU
COBOL at the moment, though.
At the moment, probably not. But they should be.
Post by Pete Dashwood
There is still a ways to go before the product can be viable for "industrial
strength" use (You know the facilities I would need before we could move to
it).
I don't agree. As I said, the systems at my last COBOL gig from 2012 could
easily be replaced with OpenCOBOL as it exists today. And, even though
they were talking about replacing it when I was there, it's still there,
it's still COBOL and if it changes at all it is still years down the road.
Post by Pete Dashwood
Post by b***@gmail.com
So back to mobile and new domains,
cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui,
and server in a single application. Prototype was 300 lines of
COBOL, with a plugin architecture that came "for free" with the GNU
Cobol CALL implementation. It allows for
http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a
CALL "reportmodule-06" END-CALL. The sample was a Report Writer
program, used for a Hercules mainframe emulator tutorial. Worked
with a single external file definition tweak. cobweb uses a mapped
linker name as reflective as you'd like it to be, or as
inconveniently secure as it may need to be. Compiled but capable of
on the fly replacement of RESTful targets or query parsers.
Yes... quite so.... Hang on while I find my Swahili dictionary... :-)
Post by b***@gmail.com
Now part of Canonical's Juju Charm demonstrations. In the cloud.
Part of that 300 lines was a GTK interface, simple, a calendar, just
to prove the data passing, and to work around lack of COBOL's general
inability to generate subprograms that have void return signatures.
There is no PROCEDURE DIVISION RETURNING OMITTED (yet).
meandering...
So, a little layer of C is added, not a biggy in terms of the
tectonics and linkage, just add a .c file to the cobc command line.
voidcall.c is a two liner that wraps COBOL subprograms so that they
can take part in callbacks to and from GTK.
This is a foreign world to me (and, I suspect, to many others...)
I can't relate to it unless I make a considerable effort to leave the world
I know and spend time in this one.
If I were to do that I would want some reward for doing so. I'm too old to
go exploring just because I like adventure... :-)
The reward being offered is that I can use COBOL to program my phone... (but
I need to go back to using command lines and parameters and low level
knowledge of all kinds of packages and libraries and, while I COULD do that,
I'd really rather not...)
I already moved on from COBOL and don't need it any more.
We all know that. But lots of people have not and are not going to.
What I see Brian, et al. doing is adding functionality that the COBOL
world can actually use. As opposed to the OO stuff that no one wanted
anyway.
Post by Pete Dashwood
(I'd still use GNU COBOL in my business because our clients are still using
COBOL, but I don't personally use it any more and all of our software
development is now in C#.)
I already have excellent (free) tools that let me program my phone should I
so desire. And I don't have to leave my comfort zone to use them.
That comes back to my "Why?"
Because you see only a world devoid of COBOL, you would probably never
understand anyway.
Post by Pete Dashwood
Post by b***@gmail.com
Application programmers need only worry about COBOL if so desired.
But it's a lot more fun embedding the JSON (done - using FUNCTION-ID,
code can read as
MOVE load-json(read-url("http://site.moc/rest/thing", curl-status),
json-status) TO json-block
That's quite cool... :-)
But having the IDE do it for me is even cooler...
And an IDE could not provide the above for you? What an IDE does
and what the code above does are apples and oranges.
Post by Pete Dashwood
Post by b***@gmail.com
Real soon now. Application friendly function repositories.
Javascript (two engines so far - node.js on the horizon)
CSS plays well with the fossil based cobweb idea.
C#, nah, Vala for that angle. XAML (I had to look up - and then nah,
.NET is not my area of bliss, don't care really, but I'll help anyone
that tries to link it in with the GNU Cobol ecosystem.
Well, .NET IS my area of bliss (and I suspect I am not the only one on the
planet who loves it...) so I guess we diverge at that point.
Some of us still anticipate (and pray for) the day when MS's dominance of
the market with inferior products ends.
Post by Pete Dashwood
Post by b***@gmail.com
Oh, yeah, back to the GTK and the calendar test.
GDK_BACKEND=broadway. GUI on the web for free.
Leading up to...
Federico Priolo has an Object COBOL inspired pre-processor using
invoke gtk-form "createform"
move "red" to "forecolor" of button1
etc, (with Glade support for full on XML design sheets)
Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace this?
Yes, now that it is free, freedom free, yes I do. In droves?
Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Yes. I agree. Actually, even if NOBODY embraced it (and I don't believe that
will be the case) it is still worthwhile from your point of view because the
exercise of doing it is a real challenge.
Is that the same NOBODY that uses COBOL today?
Post by Pete Dashwood
That's why I support what you (plural) are doing and give all of you
respect.
Post by b***@gmail.com
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with that...)
Thanks. :-)
But deep down, I reject most OO too.
A man after my own heart!!!
Post by Pete Dashwood
Post by b***@gmail.com
I prefer thinking in stacks,
and addresses and contents of addresses. A zebra is not a zebra
inside RAM but it's a pointer to an address that when jumped to,
exhibits conceptual zebra behaviour, by changing the state of some
electronics, manipulating a stack frame and coming back to the
address it is supposed to.
We already discussed world views.
As long as we both agree it is a zebra, we are on safe ground.
Post by b***@gmail.com
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get to work
on it when you can, it is a labour of love, the result will be fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST
test suite. Ready for production.
The COBOL 20xx features are generally reliable, and if not, you will know immediately.
It may be a turtle race, but GNU Cobol is in for the long haul.
Unfortunately, some of us are not getting any younger... Long haul races may
not be our forte... :-)
Be intersting to know which of us is actually older. :-) I still see
myself in for the long haul. Even if I actually retire (again) I expect
to keep at this at least part-time.
Post by Pete Dashwood
I hope I live to see you deliver the final product.
One would hope there never is a "final product". Let's just keep improving
and meeting the needs of the user base as they evolve along with the IT
technology.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't.
These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)
I get the impression you believe, as in believe, we'd be better off
in CLR .NET space. I could be wrong in the impression, electronic
text being what it is.
No, I'd like it if you were in that space, but I don't think you are wrong
for going the route you are.
Obviously, I run a business where all of the customers use Microsoft
software (particularly .NET which is now part of the OS install). When I
made a decision to provide software and services I had to look where the
marketplace is and that's why I'm into .NET. For any business to succeed
you need to go where the people are...
That's what I have been saying. :-) And like it or not a lot of those
people are still (and will remain) in the COBOL world. While I have
little luck getting faculty to take me seriously I have had conversations
with students who, after hearing some of what I say, have done their own
research. And often are amazed at what they find. So, if students who
have never learned COBOL, would not even know of its existence if the
faculty had their way, can find all these references to it, what does that
tell you? Maybe, if you don;t see any of this your just using the wrong
Google search terms. :-)
Post by Pete Dashwood
When I started, I wasn't particularly impressed by MS as a company or even
their products. However, during the ensuing years I have seen them actually
try to be better and today I have no complaints. The recent (say, from
2007...) implementations of SQL Server, Visual Studio, MS Office, .NET, C#
are all really good in my opinion. On the (infrequent) occasions when I have
needed to talk to them they have been helpful and courteous and problems
have always been resolved. They stand behind their products and that has not
been my experience with Open Software (I had a terrible time trying to get
the PostgreSQL ODBC driver fixed). So, yes, I'm a fan of those nice people
at Microsoft :-) But that doesn't mean I don't care about the alternatives.
One of these days, I have promised myself to install Linux and get into the
LAMP world but so far, I simply haven't had time. (I did a foray some years
back where I wrote a C# program and ran it under Mono on a friend's machine.
... to my surprise it worked perfectly in both .NET and Mono, but I simply
haven't had time to pursue that). I'm currently working on writing factories
to generate C# code for LINQ access in the Data Access Layer provided by
our Toolset. I don't get time out to indulge myself...(apart from coming
here occasionally ) :-)
Getting back to GNU COBOL... Commercially, I think you'd probably be better
off in the CLR .NET space, but what you are doing ISN'T commercial. (At
least, not at the moment...) If you produce a COBOL product that won't run
under Windows, then I think that would be a pity. But that isn't your
intention is it?
Most of the COBOL out there doesn't run under Windows now. All GNU COBOL
needs to do is match the current COBOL environment in order to become
commercially viable. And, considering where most of it is running today,
they already are.
Post by Pete Dashwood
Post by b***@gmail.com
I believe, as in believe, we'd be better off in GNU/Linux space and
coding to POSIX. I'm probably going to enter and exit a death bed
believing that.
I don't think you are wrong.
Post by b***@gmail.com
I'll also opine, that both beliefs are sound and right, the spheres
of influence separate when need be and intersecting when need be.
Both viable (along with other spheres) and capable of self supporting
spans of relevance with interested and engaged practitioners.
I've studied quite a few programming environments, and have come to
the conclusion that none are best.
I agree. There are some environments that meet your defined criteria for
specifc developments, better than others.
Post by b***@gmail.com
All are good, some excel in some
areas, some lag. I've also come to the conclusion that if you have C
you can glue any other A and B together with any other X,Y,Z, for the
better, approaching best.
Yes, I see a resurgence in C (largely driven by Acadaemia) and I understand
why it is happening.
But, as I noted elsewhere, this is at a lower level than most people really
want to work.
I enjoy using Visual Studio to write C#, every bit as much as I enjoyed
writing COBOL in mainframe and PC environments for around 30 years. My
knowledge is expanding and that empowers me to do more in less time, it is
very satisfying. The original COBOL SQL DAL development for the PRIMA
Migration Toolset took a bit over 2 years to design and implement; the new
C# LINQ DAL is taking around 4 months and I'm hoping to have it ready by mid
June...
Post by b***@gmail.com
For many real world problems, COBOL in the mix slides things up the
curve of good. COBOL at the centre is intriguing, and worthy of
exploration. New angles of opportunity every day.
"COBOL" in the sense that you are using it, maybe.
In the traditional (COBOL '85) sense... not so much.
Unless you think that CICS Calls make it non-COBOL, I would definitely
disagree with you. The millions and millions of lines of COBOL running
serious businesses every day are very traditional COBOL. Right now they
are being wrapped in other languages in order to provide pointy-clicky
access for users (except maybe on CICS systems :-). It would be a vast
improvement it this changed. It would definitely extend the life of
COBOL far beyond my or your meager existence.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@gmail.com
2014-04-26 05:55:59 UTC
Permalink
Post by Bill Gunshannon
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile
devices
in COBOL?
Yes.
Post by Pete Dashwood
Why?
Why not?
Because there is already a better mousetrap and the wheel doesn't need
re-inventing, basically.
Except for those caes where there is existing COBOL code that is not going
away and could use cleaner, more efficient ways to interface with the
outside world.
Post by Pete Dashwood
BUT, if you are doing it for fun (and that is a really good reason to do
anything) then you can certainly offer another alternative and the world is
a richer place for it.
There are a lot of programs in use today that had no real commercial
need at the time of their creation, and yet, they have had tremendous
commercial success. Like Linux.
Post by Pete Dashwood
Post by b***@gmail.com
We are only just starting free and open COBOL sharing;
watch, it'll turtle on growing for a long time now, coming out of
surprising corners.
That's a fair response. I believe in enthusiasm and yours is commendable.
I commented already on the non-commercial nature of what you're doing, but
that is actually a plus point in this case. You are not being driven by a
commercial schedule, rather by your own passion to do it. As you say, it can
turtle on for as long as you (plural) want to keep doing it.
See comment above. That COBOL gig I did back in 2012 could easily be
replaced with Open COBOL and PostgreSQL on Linux or BSD. What would
you estimate the savings would be considering that they currently use
Oracle, MicroFocus and AIX? And before you say "but the rest of the
world doesn't use Open COBOL and PostgreSQL on Linux or BSD" note that
this is a closed system that with two (possibly threee) sites accessing
one central database using what are really simple COBOL programs.
Post by Pete Dashwood
I believe you (plural) will produce something of very good quality and it
will be useful. (In fact what has been produced already is very good...)
But will it be "COBOL" in the sense that the people who use this forum
understand that term?
That was what I meant when I asked: Why?
If the "COBOL community" are expecting something that is familiar and
comfortable and what they actually get is something that requires a
knowledge of the alphabet soup of acronyms sprinkled through your post,
there may be resistance to embracing it because it isn't "COBOL", as COBOL
is perceived by most people.
So then, are you saying that IBM COBOL that uses calls to CICS is not
really COBOL? Seems it has been accepted readily by the COBOL community
and probably makes up a major part of the massive existing COBOL base
out there.
Post by Pete Dashwood
Nevertheless, for those who are prepared to do some homework and learn about
the facilities it provides, it may well be a route forward. However, it
seems to me that the people who are prepared to do that, can do it without
COBOL and that was why I asked: Why?
Because all kinds of COBOL is still out there. Even with strong desires
to re-write it in "a more modern langauge" it is often found to be untenable
for a number of reasons. I have done CGI in COBOL. Works really well.
And is a damn sight easier to maintain than the PHP it was intended to
replace. Many places with large COBOL backends are currently writing
"wrappers" in things like Java and PHP to make the data web accessable.
IBM put Web hooks in CICS. A more general impementation of something
like this could make Open COBOL much more commercially viable than I
expect you are willing to accept.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Everything needed to do this is available right now and for free.
(C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...
Yes, it is, thanks to guys like you and Roger and the others who indulged
their desire to make it so.
I don't think anyone at Micro Focus or Fujitsu is losing sleep over GNU
COBOL at the moment, though.
At the moment, probably not. But they should be.
Post by Pete Dashwood
There is still a ways to go before the product can be viable for "industrial
strength" use (You know the facilities I would need before we could move to
it).
I don't agree. As I said, the systems at my last COBOL gig from 2012 could
easily be replaced with OpenCOBOL as it exists today. And, even though
they were talking about replacing it when I was there, it's still there,
it's still COBOL and if it changes at all it is still years down the road.
Post by Pete Dashwood
Post by b***@gmail.com
So back to mobile and new domains,
cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui,
and server in a single application. Prototype was 300 lines of
COBOL, with a plugin architecture that came "for free" with the GNU
Cobol CALL implementation. It allows for
http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a
CALL "reportmodule-06" END-CALL. The sample was a Report Writer
program, used for a Hercules mainframe emulator tutorial. Worked
with a single external file definition tweak. cobweb uses a mapped
linker name as reflective as you'd like it to be, or as
inconveniently secure as it may need to be. Compiled but capable of
on the fly replacement of RESTful targets or query parsers.
Yes... quite so.... Hang on while I find my Swahili dictionary... :-)
Post by b***@gmail.com
Now part of Canonical's Juju Charm demonstrations. In the cloud.
Part of that 300 lines was a GTK interface, simple, a calendar, just
to prove the data passing, and to work around lack of COBOL's general
inability to generate subprograms that have void return signatures.
There is no PROCEDURE DIVISION RETURNING OMITTED (yet).
meandering...
So, a little layer of C is added, not a biggy in terms of the
tectonics and linkage, just add a .c file to the cobc command line.
voidcall.c is a two liner that wraps COBOL subprograms so that they
can take part in callbacks to and from GTK.
This is a foreign world to me (and, I suspect, to many others...)
I can't relate to it unless I make a considerable effort to leave the world
I know and spend time in this one.
If I were to do that I would want some reward for doing so. I'm too old to
go exploring just because I like adventure... :-)
The reward being offered is that I can use COBOL to program my phone... (but
I need to go back to using command lines and parameters and low level
knowledge of all kinds of packages and libraries and, while I COULD do that,
I'd really rather not...)
I already moved on from COBOL and don't need it any more.
We all know that. But lots of people have not and are not going to.
What I see Brian, et al. doing is adding functionality that the COBOL
world can actually use. As opposed to the OO stuff that no one wanted
anyway.
Post by Pete Dashwood
(I'd still use GNU COBOL in my business because our clients are still using
COBOL, but I don't personally use it any more and all of our software
development is now in C#.)
I already have excellent (free) tools that let me program my phone should I
so desire. And I don't have to leave my comfort zone to use them.
That comes back to my "Why?"
Because you see only a world devoid of COBOL, you would probably never
understand anyway.
Post by Pete Dashwood
Post by b***@gmail.com
Application programmers need only worry about COBOL if so desired.
But it's a lot more fun embedding the JSON (done - using FUNCTION-ID,
code can read as
MOVE load-json(read-url("http://site.moc/rest/thing", curl-status),
json-status) TO json-block
That's quite cool... :-)
But having the IDE do it for me is even cooler...
And an IDE could not provide the above for you? What an IDE does
and what the code above does are apples and oranges.
Post by Pete Dashwood
Post by b***@gmail.com
Real soon now. Application friendly function repositories.
Javascript (two engines so far - node.js on the horizon)
CSS plays well with the fossil based cobweb idea.
C#, nah, Vala for that angle. XAML (I had to look up - and then nah,
.NET is not my area of bliss, don't care really, but I'll help anyone
that tries to link it in with the GNU Cobol ecosystem.
Well, .NET IS my area of bliss (and I suspect I am not the only one on the
planet who loves it...) so I guess we diverge at that point.
Some of us still anticipate (and pray for) the day when MS's dominance of
the market with inferior products ends.
Post by Pete Dashwood
Post by b***@gmail.com
Oh, yeah, back to the GTK and the calendar test.
GDK_BACKEND=broadway. GUI on the web for free.
Leading up to...
Federico Priolo has an Object COBOL inspired pre-processor using
invoke gtk-form "createform"
move "red" to "forecolor" of button1
etc, (with Glade support for full on XML design sheets)
Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace
this?
Yes, now that it is free, freedom free, yes I do. In droves?
Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Yes. I agree. Actually, even if NOBODY embraced it (and I don't believe that
will be the case) it is still worthwhile from your point of view because the
exercise of doing it is a real challenge.
Is that the same NOBODY that uses COBOL today?
Post by Pete Dashwood
That's why I support what you (plural) are doing and give all of you
respect.
Post by b***@gmail.com
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with
that...)
Thanks. :-)
But deep down, I reject most OO too.
A man after my own heart!!!
Post by Pete Dashwood
Post by b***@gmail.com
I prefer thinking in stacks,
and addresses and contents of addresses. A zebra is not a zebra
inside RAM but it's a pointer to an address that when jumped to,
exhibits conceptual zebra behaviour, by changing the state of some
electronics, manipulating a stack frame and coming back to the
address it is supposed to.
We already discussed world views.
As long as we both agree it is a zebra, we are on safe ground.
Post by b***@gmail.com
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it
because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get
to work
on it when you can, it is a labour of love, the result will be
fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST
test suite. Ready for production.
The COBOL 20xx features are generally reliable, and if not, you will
know immediately.
It may be a turtle race, but GNU Cobol is in for the long haul.
Unfortunately, some of us are not getting any younger... Long haul races may
not be our forte... :-)
Be intersting to know which of us is actually older. :-) I still see
myself in for the long haul. Even if I actually retire (again) I expect
to keep at this at least part-time.
Post by Pete Dashwood
I hope I live to see you deliver the final product.
One would hope there never is a "final product". Let's just keep improving
and meeting the needs of the user base as they evolve along with the IT
technology.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for
the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't.
These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)
I get the impression you believe, as in believe, we'd be better off
in CLR .NET space. I could be wrong in the impression, electronic
text being what it is.
No, I'd like it if you were in that space, but I don't think you are wrong
for going the route you are.
Obviously, I run a business where all of the customers use Microsoft
software (particularly .NET which is now part of the OS install). When I
made a decision to provide software and services I had to look where the
marketplace is and that's why I'm into .NET. For any business to succeed
you need to go where the people are...
That's what I have been saying. :-) And like it or not a lot of those
people are still (and will remain) in the COBOL world. While I have
little luck getting faculty to take me seriously I have had conversations
with students who, after hearing some of what I say, have done their own
research. And often are amazed at what they find. So, if students who
have never learned COBOL, would not even know of its existence if the
faculty had their way, can find all these references to it, what does that
tell you? Maybe, if you don;t see any of this your just using the wrong
Google search terms. :-)
Post by Pete Dashwood
When I started, I wasn't particularly impressed by MS as a company or even
their products. However, during the ensuing years I have seen them actually
try to be better and today I have no complaints. The recent (say, from
2007...) implementations of SQL Server, Visual Studio, MS Office, .NET, C#
are all really good in my opinion. On the (infrequent) occasions when I have
needed to talk to them they have been helpful and courteous and problems
have always been resolved. They stand behind their products and that has not
been my experience with Open Software (I had a terrible time trying to get
the PostgreSQL ODBC driver fixed). So, yes, I'm a fan of those nice people
at Microsoft :-) But that doesn't mean I don't care about the alternatives.
One of these days, I have promised myself to install Linux and get into the
LAMP world but so far, I simply haven't had time. (I did a foray some years
back where I wrote a C# program and ran it under Mono on a friend's machine.
... to my surprise it worked perfectly in both .NET and Mono, but I simply
haven't had time to pursue that). I'm currently working on writing factories
to generate C# code for LINQ access in the Data Access Layer provided by
our Toolset. I don't get time out to indulge myself...(apart from coming
here occasionally ) :-)
Getting back to GNU COBOL... Commercially, I think you'd probably be better
off in the CLR .NET space, but what you are doing ISN'T commercial. (At
least, not at the moment...) If you produce a COBOL product that won't run
under Windows, then I think that would be a pity. But that isn't your
intention is it?
Most of the COBOL out there doesn't run under Windows now. All GNU COBOL
needs to do is match the current COBOL environment in order to become
commercially viable. And, considering where most of it is running today,
they already are.
Post by Pete Dashwood
Post by b***@gmail.com
I believe, as in believe, we'd be better off in GNU/Linux space and
coding to POSIX. I'm probably going to enter and exit a death bed
believing that.
I don't think you are wrong.
Post by b***@gmail.com
I'll also opine, that both beliefs are sound and right, the spheres
of influence separate when need be and intersecting when need be.
Both viable (along with other spheres) and capable of self supporting
spans of relevance with interested and engaged practitioners.
I've studied quite a few programming environments, and have come to
the conclusion that none are best.
I agree. There are some environments that meet your defined criteria for
specifc developments, better than others.
Post by b***@gmail.com
All are good, some excel in some
areas, some lag. I've also come to the conclusion that if you have C
you can glue any other A and B together with any other X,Y,Z, for the
better, approaching best.
Yes, I see a resurgence in C (largely driven by Acadaemia) and I understand
why it is happening.
But, as I noted elsewhere, this is at a lower level than most people really
want to work.
I enjoy using Visual Studio to write C#, every bit as much as I enjoyed
writing COBOL in mainframe and PC environments for around 30 years. My
knowledge is expanding and that empowers me to do more in less time, it is
very satisfying. The original COBOL SQL DAL development for the PRIMA
Migration Toolset took a bit over 2 years to design and implement; the new
C# LINQ DAL is taking around 4 months and I'm hoping to have it ready by mid
June...
Post by b***@gmail.com
For many real world problems, COBOL in the mix slides things up the
curve of good. COBOL at the centre is intriguing, and worthy of
exploration. New angles of opportunity every day.
"COBOL" in the sense that you are using it, maybe.
In the traditional (COBOL '85) sense... not so much.
Unless you think that CICS Calls make it non-COBOL, I would definitely
disagree with you. The millions and millions of lines of COBOL running
serious businesses every day are very traditional COBOL. Right now they
are being wrapped in other languages in order to provide pointy-clicky
access for users (except maybe on CICS systems :-). It would be a vast
improvement it this changed. It would definitely extend the life of
COBOL far beyond my or your meager existence.
This is a first post, out of order. It seems I have some reading to catch up on, but; Jay Moseley posted a Hercules emulator, (old school MVS from 1970), Report Writer tutorial. Really well done.

http://www.jaymoseley.com/hercules/compiling/cobolrw.htm

Code from 2008, 2011, written to compile with Hercules UCOB COBOL. Changed the FD file-name to SYSOUT, report output to standard out, pre-formatted stdout, CGI friendly for pre block html. cobc -m to get a link library, and good to go with the Report Writer programs.

This is early, first cut, the real cobweb code is up in Juju Charm demo space.

But, a RESTful interface started with

if (name-string(name-index) = "PATH_INFO")
and (value-string = "/report")
display "</table><pre>" end-display
call "RWEX06"
on exception
display "no RWEX06 found" end-display
end-call
display "</pre><table>" end-display
end-if

later cuts map strings, hard or soft config, and allows for super simple

browse cloudsite.moc/reports/6 or cloudsite.moc/reports/weekly
etcetera. Calling up old reports to the web, in one line of config (again, secure in code or less so from text config files), and a report output redirection to standard out. With the text files, new programs can be added on the fly, no recompile required for the Fast CGI loop. or the command parser.

Proven. Instantiates from Cloud OS of choice, Ubuntu based. Tested here on Fedora, invoking a Ubuntu libvirt qemu VM for builds, which spawns out new virtual machines as a local Juju Cloud instance. Builds GNU Cobol from source, compiles the reports, presents to web with a nice CSS template.

And jokes, lames ones, the reference implementation of cobweb is the joke server.

browse cloudsite.moc/pirate

is a good one. so is /batman

It's all in the open, free.

https://sourceforge.net/p/open-cobol/discussion/cobol/thread/c7e60d1b/?limit=25#567a

Some 400 lines of COBOL that delivers CGI, a GUI, and a command parser. Turns out the GTK gui displays on the web, for free.

Try out the technology with the Gnome editor, gedit.

GNU/Linux, and GTK+ 3 (three and up).

$ broadwayd :1 &
$ BROADWAY_DISPLAY=:1 GDK_BACKEND=broadway gedit

browse to localhost port 8080, and use the Gnome editor in your browser. Try it, surfin' the web like you own the place. GNU Cobol will be part of this ecosystem. So far cobweb just shows off a calendar, but the call backs are clicks from the browser to COBOL for processing. Super co^b^ol, where the b is silent. For free (including effort in this case), with the nifty Broadway backend to HTML5 and web socket transforms. The same calendar is a straight up desktop GUI as well.

There is a preprocessor Object COBOL inspired

invoke "command" with "parameters"
move "red" to "forecolor" of button-alert

interfaces with GTK, ready for GTK 3, and working with Broadway.

libmicrohttpd just went into cobweb dev, as is libharu for PDF generation.

The core is still well under 1000 lines. Grab any old legacy code and fling it to the web with pre block CGI, add forms and query parsing as need, and go.

If this encourages management to look a little further, any new graphical development in good old COBOL, (on a C binding level - vast, wide, free - a level playing field) is web ready. I'm finding GTK programming is about 3 to 1 for source lines compared to C. So much more readable though, and this ratio can/will improve as the framework builds. FUNCTION-ID repositories are next up.


Off to read more of the channel posts,

but it might be TL;DR for one sitting. :-)

Cheers,
Brian
Post by Bill Gunshannon
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@gmail.com
2014-04-26 06:56:18 UTC
Permalink
Post by Bill Gunshannon
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile
devices
in COBOL?
Yes.
Post by Pete Dashwood
Why?
Why not?
Because there is already a better mousetrap and the wheel doesn't need
re-inventing, basically.
Except for those caes where there is existing COBOL code that is not going
away and could use cleaner, more efficient ways to interface with the
outside world.
Post by Pete Dashwood
BUT, if you are doing it for fun (and that is a really good reason to do
anything) then you can certainly offer another alternative and the world is
a richer place for it.
There are a lot of programs in use today that had no real commercial
need at the time of their creation, and yet, they have had tremendous
commercial success. Like Linux.
Post by Pete Dashwood
Post by b***@gmail.com
We are only just starting free and open COBOL sharing;
watch, it'll turtle on growing for a long time now, coming out of
surprising corners.
That's a fair response. I believe in enthusiasm and yours is commendable.
I commented already on the non-commercial nature of what you're doing, but
that is actually a plus point in this case. You are not being driven by a
commercial schedule, rather by your own passion to do it. As you say, it can
turtle on for as long as you (plural) want to keep doing it.
See comment above. That COBOL gig I did back in 2012 could easily be
replaced with Open COBOL and PostgreSQL on Linux or BSD. What would
you estimate the savings would be considering that they currently use
Oracle, MicroFocus and AIX? And before you say "but the rest of the
world doesn't use Open COBOL and PostgreSQL on Linux or BSD" note that
this is a closed system that with two (possibly threee) sites accessing
one central database using what are really simple COBOL programs.
Post by Pete Dashwood
I believe you (plural) will produce something of very good quality and it
will be useful. (In fact what has been produced already is very good...)
But will it be "COBOL" in the sense that the people who use this forum
understand that term?
That was what I meant when I asked: Why?
If the "COBOL community" are expecting something that is familiar and
comfortable and what they actually get is something that requires a
knowledge of the alphabet soup of acronyms sprinkled through your post,
there may be resistance to embracing it because it isn't "COBOL", as COBOL
is perceived by most people.
So then, are you saying that IBM COBOL that uses calls to CICS is not
really COBOL? Seems it has been accepted readily by the COBOL community
and probably makes up a major part of the massive existing COBOL base
out there.
Post by Pete Dashwood
Nevertheless, for those who are prepared to do some homework and learn about
the facilities it provides, it may well be a route forward. However, it
seems to me that the people who are prepared to do that, can do it without
COBOL and that was why I asked: Why?
Because all kinds of COBOL is still out there. Even with strong desires
to re-write it in "a more modern langauge" it is often found to be untenable
for a number of reasons. I have done CGI in COBOL. Works really well.
And is a damn sight easier to maintain than the PHP it was intended to
replace. Many places with large COBOL backends are currently writing
"wrappers" in things like Java and PHP to make the data web accessable.
IBM put Web hooks in CICS. A more general impementation of something
like this could make Open COBOL much more commercially viable than I
expect you are willing to accept.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Everything needed to do this is available right now and for free.
(C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...
Yes, it is, thanks to guys like you and Roger and the others who indulged
their desire to make it so.
I don't think anyone at Micro Focus or Fujitsu is losing sleep over GNU
COBOL at the moment, though.
At the moment, probably not. But they should be.
Post by Pete Dashwood
There is still a ways to go before the product can be viable for "industrial
strength" use (You know the facilities I would need before we could move to
it).
I don't agree. As I said, the systems at my last COBOL gig from 2012 could
easily be replaced with OpenCOBOL as it exists today. And, even though
they were talking about replacing it when I was there, it's still there,
it's still COBOL and if it changes at all it is still years down the road.
Post by Pete Dashwood
Post by b***@gmail.com
So back to mobile and new domains,
cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui,
and server in a single application. Prototype was 300 lines of
COBOL, with a plugin architecture that came "for free" with the GNU
Cobol CALL implementation. It allows for
http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a
CALL "reportmodule-06" END-CALL. The sample was a Report Writer
program, used for a Hercules mainframe emulator tutorial. Worked
with a single external file definition tweak. cobweb uses a mapped
linker name as reflective as you'd like it to be, or as
inconveniently secure as it may need to be. Compiled but capable of
on the fly replacement of RESTful targets or query parsers.
Yes... quite so.... Hang on while I find my Swahili dictionary... :-)
Post by b***@gmail.com
Now part of Canonical's Juju Charm demonstrations. In the cloud.
Part of that 300 lines was a GTK interface, simple, a calendar, just
to prove the data passing, and to work around lack of COBOL's general
inability to generate subprograms that have void return signatures.
There is no PROCEDURE DIVISION RETURNING OMITTED (yet).
meandering...
So, a little layer of C is added, not a biggy in terms of the
tectonics and linkage, just add a .c file to the cobc command line.
voidcall.c is a two liner that wraps COBOL subprograms so that they
can take part in callbacks to and from GTK.
This is a foreign world to me (and, I suspect, to many others...)
I can't relate to it unless I make a considerable effort to leave the world
I know and spend time in this one.
If I were to do that I would want some reward for doing so. I'm too old to
go exploring just because I like adventure... :-)
The reward being offered is that I can use COBOL to program my phone... (but
I need to go back to using command lines and parameters and low level
knowledge of all kinds of packages and libraries and, while I COULD do that,
I'd really rather not...)
I already moved on from COBOL and don't need it any more.
We all know that. But lots of people have not and are not going to.
What I see Brian, et al. doing is adding functionality that the COBOL
world can actually use. As opposed to the OO stuff that no one wanted
anyway.
Post by Pete Dashwood
(I'd still use GNU COBOL in my business because our clients are still using
COBOL, but I don't personally use it any more and all of our software
development is now in C#.)
I already have excellent (free) tools that let me program my phone should I
so desire. And I don't have to leave my comfort zone to use them.
That comes back to my "Why?"
Because you see only a world devoid of COBOL, you would probably never
understand anyway.
Post by Pete Dashwood
Post by b***@gmail.com
Application programmers need only worry about COBOL if so desired.
But it's a lot more fun embedding the JSON (done - using FUNCTION-ID,
code can read as
MOVE load-json(read-url("http://site.moc/rest/thing", curl-status),
json-status) TO json-block
That's quite cool... :-)
But having the IDE do it for me is even cooler...
And an IDE could not provide the above for you? What an IDE does
and what the code above does are apples and oranges.
Post by Pete Dashwood
Post by b***@gmail.com
Real soon now. Application friendly function repositories.
Javascript (two engines so far - node.js on the horizon)
CSS plays well with the fossil based cobweb idea.
C#, nah, Vala for that angle. XAML (I had to look up - and then nah,
.NET is not my area of bliss, don't care really, but I'll help anyone
that tries to link it in with the GNU Cobol ecosystem.
Well, .NET IS my area of bliss (and I suspect I am not the only one on the
planet who loves it...) so I guess we diverge at that point.
Some of us still anticipate (and pray for) the day when MS's dominance of
the market with inferior products ends.
Post by Pete Dashwood
Post by b***@gmail.com
Oh, yeah, back to the GTK and the calendar test.
GDK_BACKEND=broadway. GUI on the web for free.
Leading up to...
Federico Priolo has an Object COBOL inspired pre-processor using
invoke gtk-form "createform"
move "red" to "forecolor" of button1
etc, (with Glade support for full on XML design sheets)
Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace
this?
Yes, now that it is free, freedom free, yes I do. In droves?
Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Yes. I agree. Actually, even if NOBODY embraced it (and I don't believe that
will be the case) it is still worthwhile from your point of view because the
exercise of doing it is a real challenge.
Is that the same NOBODY that uses COBOL today?
Post by Pete Dashwood
That's why I support what you (plural) are doing and give all of you
respect.
Post by b***@gmail.com
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with
that...)
Thanks. :-)
But deep down, I reject most OO too.
A man after my own heart!!!
Post by Pete Dashwood
Post by b***@gmail.com
I prefer thinking in stacks,
and addresses and contents of addresses. A zebra is not a zebra
inside RAM but it's a pointer to an address that when jumped to,
exhibits conceptual zebra behaviour, by changing the state of some
electronics, manipulating a stack frame and coming back to the
address it is supposed to.
We already discussed world views.
As long as we both agree it is a zebra, we are on safe ground.
Post by b***@gmail.com
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it
because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get
to work
on it when you can, it is a labour of love, the result will be
fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST
test suite. Ready for production.
The COBOL 20xx features are generally reliable, and if not, you will
know immediately.
It may be a turtle race, but GNU Cobol is in for the long haul.
Unfortunately, some of us are not getting any younger... Long haul races may
not be our forte... :-)
Be intersting to know which of us is actually older. :-) I still see
myself in for the long haul. Even if I actually retire (again) I expect
to keep at this at least part-time.
1963, on the shores (and middle) of Georgian Bay, commercial fishing. First COBOL exposure in 1982, University of Waterloo. Page break problem sets, sans Report Writer. First (and last) paid COBOL was 1984, federal systems, (unless you count Forth interfacing to OpenVMS COBOL, but I never got to compile, just read, advise, and interface through DECNet and VMS Record management system files. Bumped into OpenCOBOL in 1998, started writing and waving pom poms.

We hang out on SourceForge. Smallish group so far, but we average some 750 GNU Cobol source kit downloads a week, and that's above and beyond the GNU/Linux package installs, (uncounted, as most repositories have open-cobol, gnu-cobol just getting into the hands of the package builders). Binary installers for Windows are gaining some traction as well.

http://sourceforge.net/p/open-cobol/discussion/

Cheers Bill, and all
Brian
Post by Bill Gunshannon
Post by Pete Dashwood
I hope I live to see you deliver the final product.
One would hope there never is a "final product". Let's just keep improving
and meeting the needs of the user base as they evolve along with the IT
technology.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for
the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't.
These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)
I get the impression you believe, as in believe, we'd be better off
in CLR .NET space. I could be wrong in the impression, electronic
text being what it is.
No, I'd like it if you were in that space, but I don't think you are wrong
for going the route you are.
Obviously, I run a business where all of the customers use Microsoft
software (particularly .NET which is now part of the OS install). When I
made a decision to provide software and services I had to look where the
marketplace is and that's why I'm into .NET. For any business to succeed
you need to go where the people are...
That's what I have been saying. :-) And like it or not a lot of those
people are still (and will remain) in the COBOL world. While I have
little luck getting faculty to take me seriously I have had conversations
with students who, after hearing some of what I say, have done their own
research. And often are amazed at what they find. So, if students who
have never learned COBOL, would not even know of its existence if the
faculty had their way, can find all these references to it, what does that
tell you? Maybe, if you don;t see any of this your just using the wrong
Google search terms. :-)
Post by Pete Dashwood
When I started, I wasn't particularly impressed by MS as a company or even
their products. However, during the ensuing years I have seen them actually
try to be better and today I have no complaints. The recent (say, from
2007...) implementations of SQL Server, Visual Studio, MS Office, .NET, C#
are all really good in my opinion. On the (infrequent) occasions when I have
needed to talk to them they have been helpful and courteous and problems
have always been resolved. They stand behind their products and that has not
been my experience with Open Software (I had a terrible time trying to get
the PostgreSQL ODBC driver fixed). So, yes, I'm a fan of those nice people
at Microsoft :-) But that doesn't mean I don't care about the alternatives.
One of these days, I have promised myself to install Linux and get into the
LAMP world but so far, I simply haven't had time. (I did a foray some years
back where I wrote a C# program and ran it under Mono on a friend's machine.
... to my surprise it worked perfectly in both .NET and Mono, but I simply
haven't had time to pursue that). I'm currently working on writing factories
to generate C# code for LINQ access in the Data Access Layer provided by
our Toolset. I don't get time out to indulge myself...(apart from coming
here occasionally ) :-)
Getting back to GNU COBOL... Commercially, I think you'd probably be better
off in the CLR .NET space, but what you are doing ISN'T commercial. (At
least, not at the moment...) If you produce a COBOL product that won't run
under Windows, then I think that would be a pity. But that isn't your
intention is it?
Most of the COBOL out there doesn't run under Windows now. All GNU COBOL
needs to do is match the current COBOL environment in order to become
commercially viable. And, considering where most of it is running today,
they already are.
Post by Pete Dashwood
Post by b***@gmail.com
I believe, as in believe, we'd be better off in GNU/Linux space and
coding to POSIX. I'm probably going to enter and exit a death bed
believing that.
I don't think you are wrong.
Post by b***@gmail.com
I'll also opine, that both beliefs are sound and right, the spheres
of influence separate when need be and intersecting when need be.
Both viable (along with other spheres) and capable of self supporting
spans of relevance with interested and engaged practitioners.
I've studied quite a few programming environments, and have come to
the conclusion that none are best.
I agree. There are some environments that meet your defined criteria for
specifc developments, better than others.
Post by b***@gmail.com
All are good, some excel in some
areas, some lag. I've also come to the conclusion that if you have C
you can glue any other A and B together with any other X,Y,Z, for the
better, approaching best.
Yes, I see a resurgence in C (largely driven by Acadaemia) and I understand
why it is happening.
But, as I noted elsewhere, this is at a lower level than most people really
want to work.
I enjoy using Visual Studio to write C#, every bit as much as I enjoyed
writing COBOL in mainframe and PC environments for around 30 years. My
knowledge is expanding and that empowers me to do more in less time, it is
very satisfying. The original COBOL SQL DAL development for the PRIMA
Migration Toolset took a bit over 2 years to design and implement; the new
C# LINQ DAL is taking around 4 months and I'm hoping to have it ready by mid
June...
Post by b***@gmail.com
For many real world problems, COBOL in the mix slides things up the
curve of good. COBOL at the centre is intriguing, and worthy of
exploration. New angles of opportunity every day.
"COBOL" in the sense that you are using it, maybe.
In the traditional (COBOL '85) sense... not so much.
Unless you think that CICS Calls make it non-COBOL, I would definitely
disagree with you. The millions and millions of lines of COBOL running
serious businesses every day are very traditional COBOL. Right now they
are being wrapped in other languages in order to provide pointy-clicky
access for users (except maybe on CICS systems :-). It would be a vast
improvement it this changed. It would definitely extend the life of
COBOL far beyond my or your meager existence.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@gmail.com
2014-04-26 07:01:01 UTC
Permalink
Post by b***@gmail.com
Post by Bill Gunshannon
to keep at this at least part-time.
1963, on the shores (and middle) of Georgian Bay, commercial fishing. First COBOL exposure in 1982, University of Waterloo. Page break problem sets, sans Report Writer. First (and last) paid COBOL was 1984, federal systems, (unless you count Forth interfacing to OpenVMS COBOL, but I never got to compile, just read, advise, and interface through DECNet and VMS Record management system files. Bumped into OpenCOBOL in 1998, started writing and waving pom poms.
That's a typo / bold faced lie, bumped into OpenCOBOL in 2008, and then skipped a decade. ;-)

Cheers,
Brian
Post by b***@gmail.com
We hang out on SourceForge. Smallish group so far, but we average some 750 GNU Cobol source kit downloads a week, and that's above and beyond the GNU/Linux package installs, (uncounted, as most repositories have open-cobol, gnu-cobol just getting into the hands of the package builders). Binary installers for Windows are gaining some traction as well.
http://sourceforge.net/p/open-cobol/discussion/
Cheers Bill, and all
Brian
b***@gmail.com
2014-04-26 10:46:41 UTC
Permalink
Post by Bill Gunshannon
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I think "should" is a bit strong. It requires me to ask: Why?
Are you going to develop for web servers, phones, pads, and mobile
devices
in COBOL?
Yes.
Post by Pete Dashwood
Why?
Why not?
Because there is already a better mousetrap and the wheel doesn't need
re-inventing, basically.
Except for those caes where there is existing COBOL code that is not going
away and could use cleaner, more efficient ways to interface with the
outside world.
Building something that will assist some, I hope. Pretty easy to put old reports on the web, and the potential for this Fossil SCM inspired project is, as yet, undiscovered.
Post by Bill Gunshannon
Post by Pete Dashwood
BUT, if you are doing it for fun (and that is a really good reason to do
anything) then you can certainly offer another alternative and the world is
a richer place for it.
There are a lot of programs in use today that had no real commercial
need at the time of their creation, and yet, they have had tremendous
commercial success. Like Linux.
Post by Pete Dashwood
Post by b***@gmail.com
We are only just starting free and open COBOL sharing;
watch, it'll turtle on growing for a long time now, coming out of
surprising corners.
That's a fair response. I believe in enthusiasm and yours is commendable.
I commented already on the non-commercial nature of what you're doing, but
that is actually a plus point in this case. You are not being driven by a
commercial schedule, rather by your own passion to do it. As you say, it can
turtle on for as long as you (plural) want to keep doing it.
See comment above. That COBOL gig I did back in 2012 could easily be
replaced with Open COBOL and PostgreSQL on Linux or BSD. What would
you estimate the savings would be considering that they currently use
Oracle, MicroFocus and AIX? And before you say "but the rest of the
world doesn't use Open COBOL and PostgreSQL on Linux or BSD" note that
this is a closed system that with two (possibly threee) sites accessing
one central database using what are really simple COBOL programs.
Post by Pete Dashwood
I believe you (plural) will produce something of very good quality and it
will be useful. (In fact what has been produced already is very good...)
But will it be "COBOL" in the sense that the people who use this forum
understand that term?
That was what I meant when I asked: Why?
If the "COBOL community" are expecting something that is familiar and
comfortable and what they actually get is something that requires a
knowledge of the alphabet soup of acronyms sprinkled through your post,
there may be resistance to embracing it because it isn't "COBOL", as COBOL
is perceived by most people.
I'm up to explain any of my particular brand of nerd speak Peter, and apologies for a lot of the domain specific speech. Big domain though, POSIX.
Post by Bill Gunshannon
So then, are you saying that IBM COBOL that uses calls to CICS is not
really COBOL? Seems it has been accepted readily by the COBOL community
and probably makes up a major part of the massive existing COBOL base
out there.
Post by Pete Dashwood
Nevertheless, for those who are prepared to do some homework and learn about
the facilities it provides, it may well be a route forward. However, it
seems to me that the people who are prepared to do that, can do it without
COBOL and that was why I asked: Why?
Peter,

Ummm, why toss 50 years of built up assets? Shiny new? Why? When the existing assets can play in the fields of today, just like the 12,000 other systems being put to entertaining use as we speak. (I say entertaining on purpose).

I'll lay down bets with future nerd-cred that COBOL outlasts

IBM, .NET, Microsoft; or at the least, it'll outlast me, and after that I won't really care. :-)
Post by Bill Gunshannon
Because all kinds of COBOL is still out there. Even with strong desires
to re-write it in "a more modern langauge" it is often found to be untenable
for a number of reasons. I have done CGI in COBOL. Works really well.
And is a damn sight easier to maintain than the PHP it was intended to
replace. Many places with large COBOL backends are currently writing
"wrappers" in things like Java and PHP to make the data web accessable.
IBM put Web hooks in CICS. A more general impementation of something
like this could make Open COBOL much more commercially viable than I
expect you are willing to accept.
Bill,

I think so too, but freedom is more a concern for most of us GNU maintainers, where one of the freedoms is commercial viability, but it only one of the aspects of freedom.

Peter,

(And all; this is with a smiley, as are all my posts, and I'll admit to not really being in sync with google's take on usenet. I'm getting a little lost as to where to respond to things while keeping context. Please excuse if any of this sounds like fightin' words, it's never the intent).

I see it as

Live free and die trying, or Live easy, and die pwned.
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Everything needed to do this is available right now and for free.
(C#, XAML,
Javascript, CSS, JSON)
And COBOL is free now too...
Yes, it is, thanks to guys like you and Roger and the others who indulged
their desire to make it so.
I don't think anyone at Micro Focus or Fujitsu is losing sleep over GNU
COBOL at the moment, though.
Peter,

I like to play nice with vendors. They deserve mention for some great products.
Post by Bill Gunshannon
At the moment, probably not. But they should be.
Bill,

Probably are. "Are" is the wrong word. Losing sleep? I'm assuming day to day workloads keep everyone busy. Ignoring developments? I'm assuming some day to day workloads include being diligent and watchful. GNU Cobol is a freed system, with lots and lots of COBOL internals exposed for anyone to learn from. That can't hurt the practitioners.

The bison -g graph is fascinating.

Just in case; Bison (together with Flex) perform the lexical and semantic analysis phases of the compiler build chain. So, the bison pass figures out that PROCEDURE is the start of the code section, sometimes, but part of a SORT subclause in context. Flex is the lexical part. Putting the P with the R and the O, and C... to build up a PROCEDURE token for bison to chew on (bison is based on Yet Another Compiler Compiler, yacc).

Anyway, pre Report Writer, the graph is some 2 million edges, that's graph lines connecting source code tokens, reserved words and symbols like plus and parentheses.

Over 2 million code paths to generating COBOL binaries. That makes for a boatload of possible COBOL programs. ;-) More programmers should know about this stuff, regardless of favourite language and system of bliss.
Post by Bill Gunshannon
Post by Pete Dashwood
There is still a ways to go before the product can be viable for "industrial
strength" use (You know the facilities I would need before we could move to
it).
They'll come. Movements afoot, but it's COBOL, unstoppable turtle speed.
Post by Bill Gunshannon
I don't agree. As I said, the systems at my last COBOL gig from 2012 could
easily be replaced with OpenCOBOL as it exists today. And, even though
they were talking about replacing it when I was there, it's still there,
it's still COBOL and if it changes at all it is still years down the road.
Post by Pete Dashwood
Post by b***@gmail.com
So back to mobile and new domains,
cobweb. Idea based on Fossil. command line, cgi (fast), gui, tui,
and server in a single application. Prototype was 300 lines of
COBOL, with a plugin architecture that came "for free" with the GNU
Cobol CALL implementation. It allows for
http://site.moc/reports/monthly to wrap (moded for Console, or CGI) a
CALL "reportmodule-06" END-CALL. The sample was a Report Writer
program, used for a Hercules mainframe emulator tutorial. Worked
with a single external file definition tweak. cobweb uses a mapped
linker name as reflective as you'd like it to be, or as
inconveniently secure as it may need to be. Compiled but capable of
on the fly replacement of RESTful targets or query parsers.
Yes... quite so.... Hang on while I find my Swahili dictionary... :-)
cobweb, made up name for a COBOL web engine, based on Fossil SCM

Fossil SCM, a distributed software management system. Designed by Dr. Richard Hipp, author of SQLite. Very well planned and implemented piece of technology.

cgi, http Common Gateway Interface

fast cgi, preloads and loops the process avoiding process starts for each request. Very efficient for heavy hit pages.

gui, Graphical User Interface, currently for GNU Cobol, that is GTK+ based.

tui, Terminal User Interface, SCREEN SECTION and extended ACCEPT/DISPLAY. tui sucks with the web currently, so best avoided. Getting at stdscr is too tricky. That may change someday, with HTML5 properties attached to the SCREEN definitions, and a redirect to stdout when appropriate for the web.

Hercules, is a System 390 emulator, but the hobby OS is MVS from 1970. Works pretty well, once a 3270 terminal emulator is attached. COBOL, ALGOL, 360 assembler (370? I only ever play with the UCOB cobclg JCL streams (clg, compile-link-go)), and great huge, many Kilobyte, working sets.

server, in this context is libmicrohttp, an embedded http server, other choices are available.

ummm, not sure what other foreign nerd speak is at play here. Reflective link names are run-time link library names mapped to human friendly RESTful (REpresentational State Transfer) strings. I always just think url-shortener, but RESTful is quite a bit deeper web technology than that, and COBOL is quite happy in the space.

If there are other acronyms I use without thinking, please feel free to ask for clarification. I get pretty excited discussing the potentials of the COBOL and POSIX mix, and my particular brand of nerd speak slips out.
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
Now part of Canonical's Juju Charm demonstrations. In the cloud.
Part of that 300 lines was a GTK interface, simple, a calendar, just
to prove the data passing, and to work around lack of COBOL's general
inability to generate subprograms that have void return signatures.
There is no PROCEDURE DIVISION RETURNING OMITTED (yet).
meandering...
So, a little layer of C is added, not a biggy in terms of the
tectonics and linkage, just add a .c file to the cobc command line.
voidcall.c is a two liner that wraps COBOL subprograms so that they
can take part in callbacks to and from GTK.
This is a foreign world to me (and, I suspect, to many others...)
Nope, not foreign. It's the internet.
Post by Bill Gunshannon
Post by Pete Dashwood
I can't relate to it unless I make a considerable effort to leave the world
I know and spend time in this one.
Yep. The computing field is so vast now, that no one, (no one), is going to see it all, let alone program in it.
Post by Bill Gunshannon
Post by Pete Dashwood
If I were to do that I would want some reward for doing so. I'm too old to
go exploring just because I like adventure... :-)
Nope. No you are not.
Post by Bill Gunshannon
Post by Pete Dashwood
The reward being offered is that I can use COBOL to program my phone... (but
I need to go back to using command lines and parameters and low level
knowledge of all kinds of packages and libraries and, while I COULD do that,
I'd really rather not...)
I already moved on from COBOL and don't need it any more.
Then COBOL may sneak up behind you. :-)
Post by Bill Gunshannon
We all know that. But lots of people have not and are not going to.
What I see Brian, et al. doing is adding functionality that the COBOL
world can actually use. As opposed to the OO stuff that no one wanted
anyway.
Well, some want it, find it blissful, and we'll try and get those features in. FUNCTION-ID was a big step and still needs a little shaking out. The stack frames are fairly complicated. Now with the C++ emitter, turtle steps, sometimes unnoticeable day over day turtle steps.
Post by Bill Gunshannon
Post by Pete Dashwood
(I'd still use GNU COBOL in my business because our clients are still using
COBOL, but I don't personally use it any more and all of our software
development is now in C#.)
I'm a fan of GNU Cobol for hobbying, REBOL for interactive brain dumping, C for work (building GNU/Linux systems for in room hotel use)

I find C# to be a path to pwned (slang for owned, based on a typo of own to pwn from some internet meme generating day), but that's me. It's a good design, and looks to be easy to wield, but so is Python, and REBOL, and Perl, and Vala, and D, and gforth and ..., and from where I'm sitting, COBOL acts as hub to all of it. Master of all it surveys, embedding engines as it needs, and controlling the show. As the universe should be (and will be, once the counter hits 42).

COBOL can wield huge data sets, passing them back and forth to things like ROOT/CINT the framework used for high energy particle physics visualization and analysis. COBOL links directly to CINT, the C++ interpreter part of ROOT. I'd like to see it take part in a search for the super novae that exploded, many billion of years ago, splattering all the higher order, life sustaining, elements we enjoy here on good old earth (like gold, life sustaining gold). We should find where in space that star was, and send it a rocket thank you note. A COBOL managed rocket if needs warrant, or at least a picture of Admiral Grace Hopper along with the thanks.

(By the way, I've been told that the galaxy has rotated completely, more than once, since the life element source exploded (if it is indeed, just one source), and it may be like looking for a molecule of water in a moving river. Well, I think COBOL is up for the job, with CERN's high energy physics teams, and it would be respectful to start the search calculations soon) ;-)
Post by Bill Gunshannon
Post by Pete Dashwood
I already have excellent (free) tools that let me program my phone should I
so desire. And I don't have to leave my comfort zone to use them.
That comes back to my "Why?"
Because you see only a world devoid of COBOL, you would probably never
understand anyway.
Post by Pete Dashwood
Post by b***@gmail.com
Application programmers need only worry about COBOL if so desired.
But it's a lot more fun embedding the JSON (done - using FUNCTION-ID,
code can read as
MOVE load-json(read-url("http://site.moc/rest/thing", curl-status),
json-status) TO json-block
That's quite cool... :-)
But having the IDE do it for me is even cooler...
A COBOL global FUNCTION and PROGRAM repository is being built, and will be published for any and all to peruse, use, reject, as needs warrant. As I stated, COBOL is so far behind in publicly available power tools. This is not a fault of COBOL, but a side effect of the domain of strength. The power tools are powering the world, and aren't for hobbyist consumption. Completely fair and reasonable. That is changing, and the public COBOL source code pile will grow and turtle on up the hill, making the next job easier, more flexible.

Along with the surprises, like GDK (low level graphics engine part of the GTK gui system) and the HTML5, websocket layer in Broadway. Being C application binary interface, GNU Cobol is on a level playing field with this development environment.
Post by Bill Gunshannon
And an IDE could not provide the above for you? What an IDE does
and what the code above does are apples and oranges.
Post by Pete Dashwood
Post by b***@gmail.com
Real soon now. Application friendly function repositories.
Javascript (two engines so far - node.js on the horizon)
CSS plays well with the fossil based cobweb idea.
C#, nah, Vala for that angle. XAML (I had to look up - and then nah,
.NET is not my area of bliss, don't care really, but I'll help anyone
that tries to link it in with the GNU Cobol ecosystem.
Well, .NET IS my area of bliss (and I suspect I am not the only one on the
planet who loves it...) so I guess we diverge at that point.
Some of us still anticipate (and pray for) the day when MS's dominance of
the market with inferior products ends.
Post by Pete Dashwood
Post by b***@gmail.com
Oh, yeah, back to the GTK and the calendar test.
GDK_BACKEND=broadway. GUI on the web for free.
Leading up to...
Federico Priolo has an Object COBOL inspired pre-processor using
invoke gtk-form "createform"
move "red" to "forecolor" of button1
etc, (with Glade support for full on XML design sheets)
Turns out this works fine with Broadway, nice bonus.
Post by Pete Dashwood
Do you seriously think that "COBOL programmers" are going to embrace
this?
Yes, now that it is free, freedom free, yes I do. In droves?
Unlikely. In ones? Ok. Still worthwhile (and fun). :-)
Yes. I agree. Actually, even if NOBODY embraced it (and I don't believe that
will be the case) it is still worthwhile from your point of view because the
exercise of doing it is a real challenge.
Yep, way too much fun. Playing with MathGL tonight, plotting.
Post by Bill Gunshannon
Is that the same NOBODY that uses COBOL today?
Post by Pete Dashwood
That's why I support what you (plural) are doing and give all of you
respect.
Again, yep Peter, there is some really good work going on, and a fair amount of flailing of arms. ;-)
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
(Given they are the same guys who rejected OO COBOL, good luck with
that...)
Thanks. :-)
But deep down, I reject most OO too.
A man after my own heart!!!
Post by Pete Dashwood
Post by b***@gmail.com
I prefer thinking in stacks,
and addresses and contents of addresses. A zebra is not a zebra
inside RAM but it's a pointer to an address that when jumped to,
exhibits conceptual zebra behaviour, by changing the state of some
electronics, manipulating a stack frame and coming back to the
address it is supposed to.
We already discussed world views.
As long as we both agree it is a zebra, we are on safe ground.
Nothing is safe Peter. :-) We'll likely miscommunicate a few more times, the belief system bias filters built into human brains being what they are.
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
<snip>
Post by b***@gmail.com
This will be addressed on the GNU Cobol side, but to be honest, it
hasn't come up on our builds. Roger did world class excellent work,
but the 2.0 tree is work in progress, there are a fair number of
tagged code lines that need inspection and completion. That will
happen.
Until then, the COBOL 85 features of GNU Cobol are intact, the newer
20xx draft features need work.
That is a fair statement. But you can't put a time frame on it
because you
don't know what resources will be available or how they can best be
deployed. It's a bit like building a hot rod in your garage. You get
to work
on it when you can, it is a labour of love, the result will be
fabulous, but
in the meantime you have to walk to the shops because there is no car
available.
The COBOL 85 features of GNU Cobol are stable. At least to the NIST
test suite. Ready for production.
The COBOL 20xx features are generally reliable, and if not, you will
know immediately.
It may be a turtle race, but GNU Cobol is in for the long haul.
Unfortunately, some of us are not getting any younger... Long haul races may
not be our forte... :-)
Be intersting to know which of us is actually older. :-) I still see
myself in for the long haul. Even if I actually retire (again) I expect
to keep at this at least part-time.
Post by Pete Dashwood
I hope I live to see you deliver the final product.
One would hope there never is a "final product". Let's just keep improving
and meeting the needs of the user base as they evolve along with the IT
technology.
Post by Pete Dashwood
Post by b***@gmail.com
Post by Pete Dashwood
Post by b***@gmail.com
In general, it all works grand, but
before it is tagged reliable, the edges need grouting (and more
cross-platforming). BY VALUE with duck typing literals, for
instance. What is BY VALUE 3.141. on a call stack for foreign
functions? float? double? SIZE IS was added, and that needs work
too.
There is scaffolding in place for this support, but there are some
rather delicate codegen issues. (The Bison/Flex graph emitter for
the
GNU Cobol parser has somewhere in the range of 2,000,000 edges, and
uncounted code flow generation possibilities, and for the now, some
of them are wrong.
Very unlikely to ever "look" like it's working, when it isn't.
These
stack misalignment issues flame out instead, and workarounds will
exist. I had to wrestle with some of that this evening, while
getting a PLplot sample coded up. Passing float-long intermingled
with int stack framing. Took a few tries, but it works nicely using
intermediate fields for some of the literals and tricks with the
sometimes nulls. Umm, on my test machine with its bit-edness.
(Works nicely, but the PLplot developers ... and laser red on
black...not my first choice of colour palette - especially when the
goal is financial plotting; so the first mod is to set laser green
instead.) :-)
COBOL keeps up, and GNU Cobol will improve as we go.
Cheers,
Brian
I sincerely wish you well with it, Brian.
Thanks one more time. :-)
I get the impression you believe, as in believe, we'd be better off
in CLR .NET space. I could be wrong in the impression, electronic
text being what it is.
No, I'd like it if you were in that space, but I don't think you are wrong
for going the route you are.
Obviously, I run a business where all of the customers use Microsoft
software (particularly .NET which is now part of the OS install). When I
made a decision to provide software and services I had to look where the
marketplace is and that's why I'm into .NET. For any business to succeed
you need to go where the people are...
That's what I have been saying. :-) And like it or not a lot of those
people are still (and will remain) in the COBOL world. While I have
little luck getting faculty to take me seriously I have had conversations
with students who, after hearing some of what I say, have done their own
research. And often are amazed at what they find. So, if students who
I'm all for that sentiment. Nice.
Post by Bill Gunshannon
have never learned COBOL, would not even know of its existence if the
faculty had their way, can find all these references to it, what does that
tell you? Maybe, if you don;t see any of this your just using the wrong
Google search terms. :-)
Post by Pete Dashwood
When I started, I wasn't particularly impressed by MS as a company or even
their products. However, during the ensuing years I have seen them actually
try to be better and today I have no complaints. The recent (say, from
2007...) implementations of SQL Server, Visual Studio, MS Office, .NET, C#
are all really good in my opinion. On the (infrequent) occasions when I have
needed to talk to them they have been helpful and courteous and problems
have always been resolved. They stand behind their products and that has not
been my experience with Open Software (I had a terrible time trying to get
the PostgreSQL ODBC driver fixed). So, yes, I'm a fan of those nice people
at Microsoft :-) But that doesn't mean I don't care about the alternatives.
One of these days, I have promised myself to install Linux and get into the
LAMP world but so far, I simply haven't had time. (I did a foray some years
back where I wrote a C# program and ran it under Mono on a friend's machine.
... to my surprise it worked perfectly in both .NET and Mono, but I simply
haven't had time to pursue that). I'm currently working on writing factories
to generate C# code for LINQ access in the Data Access Layer provided by
our Toolset. I don't get time out to indulge myself...(apart from coming
here occasionally ) :-)
Getting back to GNU COBOL... Commercially, I think you'd probably be better
off in the CLR .NET space, but what you are doing ISN'T commercial. (At
least, not at the moment...) If you produce a COBOL product that won't run
under Windows, then I think that would be a pity. But that isn't your
intention is it?
Nope, not the intent at all. The core GNU Cobol compiler source code is Windows aware, and nothing goes in unless there is Windows runtime support. I'm just not the guy to write up instructions on how to install a compiler that uses a native C compiler on Windows, other people will do that. An INNO installer is making the rounds, MinGW (MINimum GNU on Windows), but the project does need, and will get, an msi file someday for Control panel access to install/and uninstall, with appropriate settings for Visual Studio use. Another turtle will have to carry that load up the hill, and I have no doubt that someone will. Regardless of motive, most times, computers are a lot of fun, highly engaging and entertaining, even when serious time sensitive work is at hand. (Well, during a time crisis, maybe exciting would be a better term than entertaining). Windows support is another excuse to say turtle. Sorry. ;-)
Post by Bill Gunshannon
Most of the COBOL out there doesn't run under Windows now. All GNU COBOL
needs to do is match the current COBOL environment in order to become
commercially viable. And, considering where most of it is running today,
they already are.
Bill?, (I'm now deep lost as to who owns what indentation. Sorry if wrong.)

Sometimes, yep, I hear about the odd, bumpy to start, then successful ports, and haven't heard any yelling or quit rage. It's hard to install under some setups, but we are progressing, as each platform gets a build, ... one down, more to go.

Usually the COBOL port is no worse than any port from compiler to compiler would be. Extensions can be problems, standard COBOL will not be. The stories I've heard are limited in number, but rarely negative, (never personally read or heard, but I'm sure someone has cussed and cursed).
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
I believe, as in believe, we'd be better off in GNU/Linux space and
coding to POSIX. I'm probably going to enter and exit a death bed
believing that.
I don't think you are wrong.
Post by b***@gmail.com
I'll also opine, that both beliefs are sound and right, the spheres
of influence separate when need be and intersecting when need be.
Both viable (along with other spheres) and capable of self supporting
spans of relevance with interested and engaged practitioners.
I've studied quite a few programming environments, and have come to
the conclusion that none are best.
I agree. There are some environments that meet your defined criteria for
specifc developments, better than others.
Post by b***@gmail.com
All are good, some excel in some
areas, some lag. I've also come to the conclusion that if you have C
you can glue any other A and B together with any other X,Y,Z, for the
better, approaching best.
Yes, I see a resurgence in C (largely driven by Acadaemia) and I understand
why it is happening.
But, as I noted elsewhere, this is at a lower level than most people really
want to work.
Disagree there, Peter. Look at StackOverflow, young (and old) professionals are asking and answering some pretty complex questions, with involved solutions, and most responses are "thanks for the sharing, that helped"

Yes there are questions that look unprofessional and trivial, but everyone started new and unaware.

Are the masses coding in COBOL? Ummm, 600? questions out of 7 million (7?) on the site. So, on StackOverflow, the answer in no. But I don't think internet era programmers are afraid of low level digital thinking, along with the higher level conceptual purpose of the particular data structure.

As Joel on Software said, huge boons in productivity can be had with managed memory. C is tricky, without doubt. COBOL can be tricky, but doesn't have to be; working storage can be laid out, fixed. But it is going to be an issue with GNU Cobol and foreign interfaces, at the C application binary layer. There are memory management issues, burdened on the interface developer. And we don't have a critical mass of helper layers written and available yet. Can I say turtle? without a usenet drumming by the crowds?
Post by Bill Gunshannon
Post by Pete Dashwood
I enjoy using Visual Studio to write C#, every bit as much as I enjoyed
writing COBOL in mainframe and PC environments for around 30 years. My
knowledge is expanding and that empowers me to do more in less time, it is
very satisfying. The original COBOL SQL DAL development for the PRIMA
Migration Toolset took a bit over 2 years to design and implement; the new
C# LINQ DAL is taking around 4 months and I'm hoping to have it ready by mid
June...
Whereas I just found out about emacs-evil and then org-mode. Consoles and command lines are the place to be. LINQ DAL is Swahili to me, and excuse if I scanned past clues. (Although, in my hometown, growing up, we said "It's all Dutch to me", not sure why)
Post by Bill Gunshannon
Post by Pete Dashwood
Post by b***@gmail.com
For many real world problems, COBOL in the mix slides things up the
curve of good. COBOL at the centre is intriguing, and worthy of
exploration. New angles of opportunity every day.
"COBOL" in the sense that you are using it, maybe.
In the traditional (COBOL '85) sense... not so much.
Unless you think that CICS Calls make it non-COBOL, I would definitely
disagree with you. The millions and millions of lines of COBOL running
serious businesses every day are very traditional COBOL. Right now they
are being wrapped in other languages in order to provide pointy-clicky
access for users (except maybe on CICS systems :-). It would be a vast
improvement it this changed. It would definitely extend the life of
COBOL far beyond my or your meager existence.
bill
Cheers,
Brian
Post by Bill Gunshannon
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Richard
2014-04-24 03:06:46 UTC
Permalink
Post by Pete Dashwood
Yes, I would aree that is a valid "world view" but it is far too low level
for most people...
It is not too 'low level' for the machines, which is where the 'real world' actually runs.
Post by Pete Dashwood
Agreed. But, for development it is the conceptual world that matters. If a
virtual view gives a basis that is easily comprehensible and can be expanded
on to develop stuff, then that is more practical (in my opinion) than using
a view that has so many details you keep tripping over them.
The 'conceptual world' not being the 'real world' that you originally referred to.
Post by Pete Dashwood
Are you going to develop for web servers, ... in COBOL?
I developed for web servers in COBOL 20 years ago: running on Windows 3.11, OS/2 and SCO Unix.
Bill Gunshannon
2014-04-23 11:56:52 UTC
Permalink
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
<snip>>
Post by Bill Gunshannon
I find the above confusing. What makes sense? Is the return value
from a COBOL CALL 32 or 64 bits on a 64 bit machine?
As stated, FreeBSD. Haven't really tried any of this under Windows
Server but might be fun to see what happens.
Post by Pete Dashwood
It depends what is being returned. If it is an object reference it
will be 8 bytes, UNLESS the code has been built for a 32 bit CPU, in
which case it will be 4.
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to PostgreSQL is an
object reference inasmuch as it points to an object. (An instance of
PostgreSQL)
You are invoking a method of PostgreSQL (whether you like it or not) because
the real world runs on objects.
http://www.postgresql.org/docs/9.1/static/libpq-connect.html
The above docs expalin it quite clearly. You can see the definition of
PQStatus and the values it is expected to hold.
Once again, Pete, we will have to agree to disagree. To me that is all
OO gobledygook and has no bearing on doing real work with COBOL.
Post by Pete Dashwood
You could reasonably expect this will be a 64 bit pointer on a 64 bit system
(where you have a 64 bit implementation of PostgreSQL), or a 32 bit one on
32 bit systems.
And, of course, this was my point. The above is a reasonable assumption.
What I seemed to observe was that on my amd64:
1) Postgres compiled with 64bit pointers
2) OpenCOBOL 1.1 appeared to be assuming 32 bit pointers

thus truncating the pointer passed back by Postgres.

This all being default behaviour as I just built the packages from the
FreeBSD Ports Tree.
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
If you built the code using a 32 bit implementation of the C
libraries then it will be 4 bytes.
Both systems were built on the same machines using the default
Makefiles. One would have hoped the developers would have gotten it
right. (I know, rather naive of me!!!)
The Open COBOL developers have no control over the build of PostgreSQL.
Never said they did. I was pointing at somethign I saw as a problem
with Open COBOL, not Postgres.
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
But it should run fine, as long as it is installed in the "right"
libraries on the 64 bit machine. (Too much to go into here but check
out WOW64 and "Program Files (x86)")
Not on FreeBSD. :-)
Fair enough.
Post by Bill Gunshannon
Post by Pete Dashwood
64 bit components can call 32 bit ones, but not vice versa, so if
your 32 bit COBOL tries to call 64 bit PostgreSQL, you can expect
problems.
I believe this is the nub of your actual problem.
Yes, but my point was why did Open COBOL build itself, from source, with
32 bit pointers on a 64 bit architecture?
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Is it possible
that the pointer gets truncated when it gets passed back to the
calling COBOL routine?
Very possible. But there's a lot more to it than that.
Not really. If the library passes back a 64 bit pointer and the
calling procedure only has 32 bits of room, what would you expect to
happen?
In your case, you have a 32 bit COBOL trying to access a 64 bit PostgreSQL.
(when it is running on a 64 bit platform). It's pretty clear that the
pointers will give trouble. It will run fine until it gets to the point
where it tries to load and execute 64 bit code within the 32 bit process.
No, actually it never tries to execute 64 bit code in a 32 bit process
because there is no 32 bit process. The OS is 64 bit. The problem is
that a pointer is passed back to COBOL from Postgres. It starts life
as a 64 bit pointer but Open COBOL appears to only take 32 of thise bits.
Needless to say, when it tries to pass that pointer back to access the
info (or in your case, the object :-) because it has lost half of the
bits it points off into never-never land and thus results in the SEGV.
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
I noticed that your PostgreSQL call is passing the connection by
value (unusual for COBOL which normally passes references by
reference, although other languages (like C...) can pass a reference
type by value. )
I didn't right the compiler. That is the method they give for calling
this procedure. And the fact that it does work on 32 bit machines
pretty much guarantees it's right.
The problem doesn't arise if both PostgreSQL and COBOL are built for 32 bit
(or for 64 bit and running on a 64 bit platform). In all other cases, it
cannot work.
Exactly. My point being why would Open COBOL build assuming 32 bit pointers
on a 64 bit system?
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
The only way I know of to fix this is to run an Object Browser on
the component you are calling and check the properties and the
method signature. That will tell you what it expects and what it
returns so you can make sure you give it what it needs. (If you have
Microsoft Office on the machine there is a good Object Browser
provided with VBA...)
Pete, the whole world isn't a Windows box.
Jeez, man, it is a suggestion. And I prefaced the whole post by saying it
applies to Windows. If you can't figure out why links and references are not
working then you need an Object Browser (or a Typelib) to see what the
actual object code is expecting. Whether it is on Windows or anywhere
else...
I'll spell it out...
COBOL PG BOX RESULT
32 bit 32 bit 32 bit
OK
32 bit 64 bit 32 bit PG
won't run, so not possible
32 bit 32 bit 64 bit
OK
32 bit 64 bit 64 bit
pointer crash when 64 bit code is called from COBOL
64 bit 32 bit 32 bit
COBOL code won't run, so impossible
64 bit 64 bit 32 bit
Neither COBOL nor PostgreSQL will run, so impossible
64 bit 32 bit 64 bit
OK
64 bit 64 bit 64 bit
OK
In this case it isn't even that hard... your database system is predicated
on a different architecture from your COBOL system. I already told you what
you need to do.
I already knew all that and did, in fact, state as much in the original
message. I am not an Open COBOL developer and so I can do nothing but
report what i see as aberrant behaviour.
Post by Pete Dashwood
Use 64 bit COBOL or 32 bit PostgreSQL on your 64 bit platform.. 32 bit
PostgreSQL will run on either 32 or 64 bit platforms; 64 bit PostgreSQL
won't.
Post by Bill Gunshannon
Post by Pete Dashwood
I suspect your 64 bit machine has a 64 bit implementation of
PostgreSQL and that is why it all goes pear shaped. Either rebuild
the COBOL for 64 bit (if that is available) or download a 32 bit
implementation of PostgreSQL to your 64 bit machine.
That's why it runs fine on your 32 bit VM.
Both systems were built on both machines with default settings. If
the developers got to wrong, I am unlikely to be able to fix it.
Sure, blame the developers... why not? Everyone else does. The developers
are not responsible for you trying to make 32 bit code call 64 bit code.
You still seem to have missed the most important point. Open COBOL was
compiled from source on a 64 bit machine giving:

/usr/local/bin/cobc: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.1, stripped

Note, it is a 64 bit ELF executable. But, the CALL interface appears to
be expecting to receive back a 32 bit pointer. That's the problem, as I
see it. It is not a cse of trying to run 32 bit code on a 64 bit machine.
It is an internals problem in the compiler.
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I guess I am confused. I don't see it as problem with the program
in the FAQ. That should work as written regardless of the wordsize
of the host cpu. Isn't that supposed to be one of the strengths of
COBOL? :-)
It is platform acrhitecture, not COBOL, that needs to be carefully
complied with.
Not necessarily.
Yes, necessarily. 32 bit code physically cannot call 64 bit code unless some
very esoteric options are in place (both at build and run times) and these
are not the norm. (Even then it is severely limited in what it can do.) I
speak as one with considerable experience in this field and with the hair
loss to prove it...
Post by Bill Gunshannon
I have seen a lot of Open Source code that was
developed on 32 bit machines that are assumed to be 64bit safe.
This is not necessarily true.
Not necessarily, but generally so. Normally, 32 bit code IS 64 bit safe and
will run fine on 64 bit platforms. The converse is NOT true.
Post by Bill Gunshannon
Especially if there is anything
like pointer arithmetic involved.
Problems with pointer arithmetic are going to happen on any platform unless
proper care is taken. That is nothing to do with 32/64 bit compatibility.
That's true, but they are more like when you move code between machines
where the sizes of data types change and rather than verifying the developer
just assumes if it ran on one it will run on another.
Post by Pete Dashwood
Post by Bill Gunshannon
Maybe if people didn't turn off
warnings and instead fixed the cause a lot of these kinds of problems
would go away.
Maybe if people didn't use pointer arithmetic there would be no pointer
arithmetic problems.
And if cars had square wheels there wold be a lot less highway accidents.
Don't blame the tool.
Post by Pete Dashwood
Post by Bill Gunshannon
I am not criticizing the Open/GNU COBOL people. i think the compiler
is nice but I also know there is very little documentation on using
this COBOL with databases. That likely means not many people have
tried or figured it out yet. That means there may be latent bugs in
the methods used to do this. Having done a bit of this kind of
programming (recently even!!!) using commercial systems I have an
interest in seeing it get more widespread use in the Open Source
world.
Yeah... good luck with that.
Yeah, I know where you stand on that. We have discussed this before.
Here's another data point for you. US Social Security Administration.
Core system is 36 million lines of COBOL. It was suggested to re-write
it into "a more modern language" several time over the past decade. In
every case the decision was that it would be "too expensive, too complex
a problem and too risky" to do it. They basicly did the same thing as
the Insurance companies. But a layer between the real computers and the
fluffy web world and continued to march.
Post by Pete Dashwood
Post by Bill Gunshannon
I am even looking into the possibility of writting a
pre-compiler to make it easier. But first, I have t make it work.
For now, it looks like I will be doing most of my work on the 32 bit
system as once I am done everything I do should be portable to 64
bits assuming there are not interface problems in the underlying
packages. We will see.
It still won't work if you try and use it with 64 bit code that is built as
64 bit.
I'm done.
Undoubtedly...

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Richard
2014-04-24 02:48:49 UTC
Permalink
Post by Pete Dashwood
Post by Bill Gunshannon
Sorry Pete. It's real COBOL, not an object in sight.
That's just because you can't see them. Your connection to
PostgreSQL is an object reference inasmuch as it points to
an object. (An instance of PostgreSQL)
No. You are wrong. The data that represents the connection
to PostgreSQL is buried in the libpq library. What is returned
is a pointer into that library.
Post by Pete Dashwood
You are invoking a method of PostgreSQL (whether you like it
or not) because the real world runs on objects.
No. You are wrong because the program is calling functions and
procedures in the libpq library (or similar).

The 'real world' runs on machine code. _Source_ code may be
written in a style that is OO, but the machine code is just
machine code.
Post by Pete Dashwood
You could reasonably expect this will be a 64 bit pointer
on a 64 bit system where you have a 64 bit implementation
of PostgreSQL), or a 32 bit one on 32 bit systems.
The implementation of PostgreSQL (the server) is irrelevant,
both libraries can be used on a 64bit system.
Post by Pete Dashwood
In your case, you have a 32 bit COBOL trying to access a
64 bit PostgreSQL. (when it is running on a 64 bit platform).
It's pretty clear that the pointers will give trouble. It
will run fine until it gets to the point where it tries to
load and execute 64 bit code within the 32 bit process.
PostgreSQL runs as a separate process, even on a different
machine.
Post by Pete Dashwood
The problem doesn't arise if both PostgreSQL and COBOL
are built for 32 bit (or for 64 bit and running on a 64 bit
platform). In all other cases, it cannot work.
Wrong again.
Post by Pete Dashwood
I'll spell it out...
Yes, necessarily. 32 bit code physically cannot call 64 bit
code unless some very esoteric options are in place (both
at build and run times) and these are not the norm. (Even
then it is severely limited in what it can do.) I speak
as one with considerable experience in this field and with
the hair loss to prove it...
Yeah, but you use Windows.
Post by Pete Dashwood
Maybe if people didn't use pointer arithmetic there would
be no pointer arithmetic problems.
Pointer arithmetic was created to overcome problems with 8088
and MS-DOS programs.
b***@gmail.com
2014-04-23 06:18:21 UTC
Permalink
Post by Pete Dashwood
I noticed that your PostgreSQL call is passing the connection by value
(unusual for COBOL which normally passes references by reference, although
other languages (like C...) can pass a reference type by value. )
Nope. This is on purpose. COBOL passes a reference for the RETURNING clause in PQconnectdb, to get a write from C. That handle is then passed back to C, BY VALUE from COBOL (which just happens to be a C address in the COBOL pointer). C knows nothing about COBOL reference addresses, it wants to use the handle value it set during init.

C functions expecting char ** can be POINTER BY REFERENCE, but normally it's POINTER BY VALUE when passing addresses and handles back to C (or most any other foreign function interface). We kinda luck out that COBOL expects cell sized return values, so functions of type char * fit nicely in a RETURNING to POINTER.
Post by Pete Dashwood
The only
way I know of to fix this is to run an Object Browser on the component you
are calling and check the properties and the method signature. That will
tell you what it expects and what it returns so you can make sure you give
it what it needs. (If you have Microsoft Office on the machine there is a
good Object Browser provided with VBA...)
Peter, you know I'd defend you in front of strangers, but I have a completely different view of development. :-)

IDE's blow. Right now in this browser, I have some 100 different little visual pieces of crap in my eyes. Red buttons, four green ones, square blues ones, round blue ones, bells, arrows, numbers, and on and on... ALL OF IT but three (the edit window, Post & Cancel), useless to the task at hand of writing a post to comp.lang.cobol. Slowing it down actually. Eyeballs flittering back and forth in response to peripheral vision detectors. But, for browsing, a gui is prettier than a console. For working, 80x25 is more than enough information for focus. (two or three 132x50s being better for tracking perhaps, and cross referencing) But why 8000 different features per screen? Oh yeah, no command line. Have to. Blows. In my humble, grew up working on water (distractions get you drowned), then in Forth block editors (there is very little distraction in 64x16), based opinion.

<smiley> views are views and taste is taste, COBOL developers are fortunate in the breadth of options.
Post by Pete Dashwood
I suspect your 64 bit machine has a 64 bit implementation of PostgreSQL and
that is why it all goes pear shaped. Either rebuild the COBOL for 64 bit (if
that is available) or download a 32 bit implementation of PostgreSQL to your
64 bit machine.
That's why it runs fine on your 32 bit VM.
Post by Bill Gunshannon
Post by Vince Coen
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
(Meandering now)
Hmm, perhaps a wiki version, ala the PostgreSQL docs. With and without comment.
Post by Pete Dashwood
Post by Bill Gunshannon
I guess I am confused. I don't see it as problem with the program in
the FAQ. That should work as written regardless of the wordsize of
the host cpu. Isn't that supposed to be one of the strengths of
COBOL? :-)
It is platform acrhitecture, not COBOL, that needs to be carefully complied
with.
<snip>
HTH,
Pete.
--
I used to write COBOL...now I can do anything."
Cheers,
Brian
Pete Dashwood
2014-04-23 09:24:54 UTC
Permalink
Post by b***@gmail.com
Post by Pete Dashwood
I noticed that your PostgreSQL call is passing the connection by value
(unusual for COBOL which normally passes references by reference, although
other languages (like C...) can pass a reference type by value. )
Nope. This is on purpose. COBOL passes a reference for the
RETURNING clause in PQconnectdb, to get a write from C. That handle
is then passed back to C, BY VALUE from COBOL (which just happens to
be a C address in the COBOL pointer). C knows nothing about COBOL
reference addresses, it wants to use the handle value it set during
init.
C functions expecting char ** can be POINTER BY REFERENCE, but
normally it's POINTER BY VALUE when passing addresses and handles
back to C (or most any other foreign function interface). We kinda
luck out that COBOL expects cell sized return values, so functions of
type char * fit nicely in a RETURNING to POINTER.
Post by Pete Dashwood
The only
way I know of to fix this is to run an Object Browser on the
component you
are calling and check the properties and the method signature. That will
tell you what it expects and what it returns so you can make sure you give
it what it needs. (If you have Microsoft Office on the machine there is a
good Object Browser provided with VBA...)
Peter, you know I'd defend you in front of strangers, but I have a
completely different view of development. :-)
Sure, I know. And I respect your view. I can agree to differ on this.

I work in a world where people are paying me to deliver. It isn't about
"noble causes" it is about getting working applications onto Windows
platforms.

Personally, I would LOVE to use Open software (for many of the same reasons
you are doing what you do...people should have choices, etc...) but I simply
can't justify it.

It's too high a risk. I had my fingers burned with Open Software many years
ago when I found no-one would take responsibility for it. I needed to have
bugs in an ODBC driver for PostgreSQL fixed and nobody would accept it. As a
result, MS SQL Server is the preferred database for our company and our
clients.

As far as Open COBOL goes, I'd be very happy to give it a shot but it
doesn't have the facilities I need. Is there a mechanism where feedback from
the "marketplace" is listened to? I don't know. I've been asking for the
same facilities for at least six years now and there is no progress on it.
Don't get me wrong; I completely respect the right of the people doing it to
do whatever they want and prioritize however they want, but that is "hobby"
programming, not commerce.
Post by b***@gmail.com
IDE's blow.
I disagree. I LOVE Visual Studio and Eclipse is also pretty good. But I
already agreed to differ on development approaches... :-)

<snip>

Pete.
--
"I used to write COBOL...now I can do anything."
Richard
2014-04-24 02:21:21 UTC
Permalink
Post by Pete Dashwood
64 bit components can call 32 bit ones, but not vice versa,
so if your 32 bit COBOL tries to call 64 bit PostgreSQL,
you can expect problems.
The program does not call 'PostgreSQL' it calls libpq. Libpq has
code that talks to PostgreSQL using sockets or TCP/IP. There are
both 32bit and 64bit versions of libpq, the bittedness of
PostgreSQL server is irrelevant.
Post by Pete Dashwood
It is platform acrhitecture, not COBOL, that needs to be carefully complied
with.
Linux 64bit runs 32 bit software very well and copes with handling both well.
b***@gmail.com
2014-04-23 05:32:16 UTC
Permalink
Post by Bill Gunshannon
Is theere something different about v2 over v1.1?
Lots and lots and lots when it comes to stack frame, and 2.1 is out, but not released yet. What was released is a work in progress, but it still leaks and valgrind complains.

Adding FUNCTION-ID gutted the CALL verb and stack handling in general. There are issues with FLOAT-LONG, missed duck typing of literals, and BY VALUE needs work.
Post by Bill Gunshannon
All my work so far is
with v1.1 as v2 is not in the FreeBSD ports tree yet. If what you want
is an equivalent program for MySQL I can take a look at it. Can't be all
that hard to do assuming there is a library for MySQL.
bill
If you do write up something Bill, and you let me, I'll post it in the FAQ.

Free COBOL source is still pretty much in it's infancy, and most of the FAQ samples were written for fun. Maybe some of listing need to be pulled or corrected before too much of the world is exposed to slacker incorrect "COBOL" :-)

I'm open to drummings if it makes for future-better COBOL

And, ummm, Gerald Chudyk already outdid the FAQ sample, but bounds and leaps.

http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1#forumpost4142

There is a lot more to learn from his source (two things need to change, one ZERO for a NULL (pointers can't be tested for zero anymore) and one BY VALUE for BY CONTENT, umm it's a warning of assumed BY CONTENT, but better changed than not)

OR,

OCESQL out of Japan, or eqslOC, or the DB2 pre processor, or FireBird, or the Oracle, or... :-)

But I'll fix the listing in the FAQ to bail with message on failed connections for future-better COBOL's sake.

Cheers,
Brian
Bill Gunshannon
2014-04-23 12:44:24 UTC
Permalink
Post by b***@gmail.com
Post by Bill Gunshannon
Is theere something different about v2 over v1.1?
Lots and lots and lots when it comes to stack frame, and 2.1 is out, but not released yet. What was released is a work in progress, but it still leaks and valgrind complains.
Well, I found 2.0 and I am setting up a Server2012 box to try it on.
Haven't done much COBOL on Windows boxes before (not since my Ryan-
McFarland days which go all the way back to the Z80 micros) so it will
prove interesting.
Post by b***@gmail.com
Adding FUNCTION-ID gutted the CALL verb and stack handling in general. There are issues with FLOAT-LONG, missed duck typing of literals, and BY VALUE needs work.
I'll keep my eyes out for any quirks.
Post by b***@gmail.com
Post by Bill Gunshannon
All my work so far is
with v1.1 as v2 is not in the FreeBSD ports tree yet. If what you want
is an equivalent program for MySQL I can take a look at it. Can't be all
that hard to do assuming there is a library for MySQL.
bill
If you do write up something Bill, and you let me, I'll post it in the FAQ.
Well, one of the reasons I am doing what I am doing, at the moment, is
trather than just displaying vesions and usernames I thought there should
be a demo that did actual SQL, you know, SELECT, INSERT, JOIN. :-)
And anything I do for Postgres (my prefered DB) should be doable in a
similar manner on MySQL.
Post by b***@gmail.com
Free COBOL source is still pretty much in it's infancy, and most of the FAQ samples were written for fun. Maybe some of listing need to be pulled or corrected before too much of the world is exposed to slacker incorrect "COBOL" :-)
That's probably because COBOL is used primarily for real work and my real
work is unlikely to duplicate your real work. Most of us date back to a
time when programs were written to meet the needs of users rather than
todays model which requires users to change their way of doing things to
fit the model presented by the program.
Post by b***@gmail.com
I'm open to drummings if it makes for future-better COBOL
And, ummm, Gerald Chudyk already outdid the FAQ sample, but bounds and leaps.
http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=868&forum=1#forumpost4142
I'll take a look at that as I have been finding the example in the
FAQ functional but of little intrinsic value.
Post by b***@gmail.com
There is a lot more to learn from his source (two things need to change, one ZERO for a NULL (pointers can't be tested for zero anymore) and one BY VALUE for BY CONTENT, umm it's a warning of assumed BY CONTENT, but better changed than not)
OR,
OCESQL out of Japan, or eqslOC, or the DB2 pre processor, or FireBird, or the Oracle, or... :-)
I have heard about all these pre-processors. I have yet to find one that
can actually be used. Some are commercial and others imposible to locate
or very system specific. I would write mine in COBOL. :-) At least we
know there will be a compiler for it. :-)
Post by b***@gmail.com
But I'll fix the listing in the FAQ to bail with message on failed connections for future-better COBOL's sake.
Oh, and for being old, COBOL is way behind on just about every
internet front. We can, and should, try to change that now.
I definitely agree with this. I have done CGI with OpenCOBOL. It is
not elegant, but it works. And the PHP crap it was written to replace
was considerably harder maintain.

What might be useful if there are other people interested would be for
someone to work on something like a library to emulate CICS functionality.
Now, I am not an expert by any stretch of the imagination (OK, my last
IBM big iron COBOL was before CICS was even a gleam in the designers eye)
but looking at the reference manual I have, just one facet of it is web
support. Like you, just meandering.

All the best.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
2014-04-22 16:19:01 UTC
Permalink
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that code
is fairly old and no doubt has changed as has Postgres.
That the problem with the FAQ it is not updated unless someone reports
such and provides an updated text etc.
I am still waiting for one for Mysql/Mariadb for OC v2.
Wheer does one find OC v2? I went to sourceforge but there is nothing
under files for v2.

In the meantime, I guess I can go ahead with my plans for Windows Server
2012 using 1.1.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
2014-04-22 16:21:32 UTC
Permalink
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that code
is fairly old and no doubt has changed as has Postgres.
That the problem with the FAQ it is not updated unless someone reports
such and provides an updated text etc.
I am still waiting for one for Mysql/Mariadb for OC v2.
Wheer does one find OC v2? I went to sourceforge but there is nothing
under files for v2.
In the meantime, I guess I can go ahead with my plans for Windows Server
2012 using 1.1.
Never mind. Found them.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Pete Dashwood
2014-04-23 02:22:26 UTC
Permalink
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that
code is fairly old and no doubt has changed as has Postgres.
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I am still waiting for one for Mysql/Mariadb for OC v2.
Wheer does one find OC v2? I went to sourceforge but there is nothing
under files for v2.
In the meantime, I guess I can go ahead with my plans for Windows
Server 2012 using 1.1.
But the world isn't a Windows box...

Pete
--
"I used to write COBOL...now I can do anything."
Bill Gunshannon
2014-04-23 12:47:20 UTC
Permalink
Post by Pete Dashwood
Post by Bill Gunshannon
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Hmmm... I only see one. Is there another FAQ I don't know about?
5.4.5 PostgreSQL Sample
Only one under that heading but I would have been guessing it was the
correct one you refered to and I do not do 'assuming'!
Post by Bill Gunshannon
Post by Vince Coen
I am assuming here that I do not need to install postgres to test
this as I do not use it!
I think you would if you plan to compile and run it. I could be
call "PQstatus" using by value pgconn returning result end-call
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that
code is fairly old and no doubt has changed as has Postgres.
That the problem with the FAQ it is not updated unless someone
reports such and provides an updated text etc.
I am still waiting for one for Mysql/Mariadb for OC v2.
Wheer does one find OC v2? I went to sourceforge but there is nothing
under files for v2.
In the meantime, I guess I can go ahead with my plans for Windows
Server 2012 using 1.1.
But the world isn't a Windows box...
Now, where did I hear that before? :-)

No, it's not, but Windows is just one of the other options and contrary
to what some people might think, I am not a technology snob. I believe
one should choose all the pieces that fit a particular task. Not just
the right language, but the right platform as well. One should not just
engineer a program, one should engineer the whole system.

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@gmail.com
2014-04-23 06:30:06 UTC
Permalink
Post by Bill Gunshannon
Wheer does one find OC v2? I went to sourceforge but there is nothing
under files for v2.
Not yet nope, no official tarball.

Under SVN, top bar menu Code (GNU/OC 1.1, 1.1CE, 2.x, C++)

Sadly, the default advice is

svn checkout svn://svn.code.sf.net/p/open-cobol/code/trunk open-cobol-code

But that only gets you trunk.

Use

svn checkout svn://svn.code.sf.net/p/open-cobol/code/ gnu-cobol

Under branches,

- gnu-cobol-cpp (C++ emitter - a thing to watch and Object COBOL will start here)
- gnu-cobol-2.0 will be superseded by Ron Normans's
- reportwriter (GNU Cobol 2.1 - the place to be right now - 2.1 will elevate to trunk shortly, but we'll still have to tag it as pre-release, there is too much new stuff to send out to the unwary).

SourceForge Allura just added snapshot links, so if you don't feel like going with revision control, surf to

http://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/reportwriter/

and click, Download Snapshot. Odds of getting an in-flight snapshot is non-zero, but negligible.

Cheers,
Brian
Post by Bill Gunshannon
In the meantime, I guess I can go ahead with my plans for Windows Server
2012 using 1.1.
b***@gmail.com
2014-04-23 04:53:47 UTC
Permalink
Post by Vince Coen
Post by Bill Gunshannon
I think the value of pgconn is bogus, maybe truncated to 32bits.
That makes sense. Looking like the interface needs changing but that code
is fairly old and no doubt has changed as has Postgres.
That the problem with the FAQ it is not updated unless someone reports
such and provides an updated text etc.
I am still waiting for one for Mysql/Mariadb for OC v2.
Vince
I'll update the FAQ with more defensive programming in the sample. Vince, that'll fix the segfault when trying to retrieve a value after a failed connect. Bill, I have no idea yet what the 5 character pointer displays are. Weird. :-)

Vince; if you don't mind ODBC, http://opencobol.add1tocobol.com/gnucobol/#getting-started-with-esqloc lists success with Sergey's esqlOC pre processor and MySQL. (Unless you've already tried it, and this is redundant.)

Cheers,
Brian
Vince Coen
2014-04-20 22:14:59 UTC
Permalink
Hello Bill!
Post by Bill Gunshannon
Post by Vince Coen
Yes since v1 but I use v2.1 (with rwcs) as X64.
Post by Bill Gunshannon
I tried some stuff
this morning that used CALL and needed to take in a pointer on
the
Post by Bill Gunshannon
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs
at
Post by Bill Gunshannon
all. I tracked it down to what looked like a problem taking in
the
Post by Bill Gunshannon
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can
try it on my box. You can send it as a file attach to my email
address above ort srop me a direct email and I will pass on my
normal address for any file attachment if gmail blows.
Or, you can grab a copy yourself. :-) It's the Postgresql interface
program written by Brian Tiffin that is in the FAQ.
-------------------------------------------------------------
FreeBSD OC 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17
01:46:25 UTC 2014
Before connect:0x00000000
After connect: 0x28c03580
Status: +0000000000
User: bill
call PQexec
0x28c730c0
Version: PostgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled
by GCC FreeBSD clang ver After finish: 0x28c03580
Status: +0000000001
User after: billgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled
by GCC FreeBSD clang ver
----------------------------------------------------------------
Thu Feb 17 02:41:51 UTC 2011
Before connect:00000
After connect: 59872
Segmentation fault (core dumped)
I seem to get a different result which can be related to the fact that I
have installed and configured postgres but this is what I get:

-----------------------------------------
[***@study ~]$ cobc -V
cobc (GNU Cobol) 2.1.0
Copyright (C) 2001,2002,2003,2004,2005,2006,2007 Keisuke Nishida
Copyright (C) 2006-2012 Roger While
Copyright (C) 2013 Ron Norman

Copyright (C) 2009,2010,2012,2014 Simon Sobisch

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Apr 08 2014 18:44:28
Packaged Nov 23 2013 07:02:31 UTC
C version "4.8.2"

++++++++++++++++++++++++++++++++++++++++

[***@study ~]$ cobc -x -lpq test-4-bill.cbl
[***@study ~]$ ./test-4-bill
Before connect:0x0000000000000000
After connect: 0x00000000009c85a0
Status: +0000000001
User: vince
call PQexec
0x0000000000000000

Attempt to reference unallocated memory (Signal SIGSEGV)
Abnormal termination - File contents may be incorrect
[***@study ~]$
-----------------------------------------

A few point though:

Did you compile the compiler AND run make check

Now in my case with v2.1 get 440 tests completed ok
and then do (as taken from the README in test/cobol85):

b) Download the test archive `newcob.val.Z' from
http://www.itl.nist.gov/div897/ctg/cobol_form.htm
Uncompress it:
uncompress newcob.val.Z

2. Move the file newcob.val to the tests/cobol85 directory

3. Run the test suite:

cd tests/cobol85
make test

and get full and valid results with no error messages e.g.,:
-----------------------------------
------ Directory Information ------- --- Total Tests Information ---
Module Programs Executed Error Crash Pass Fail Deleted Inspect Total
------ -------- -------- ----- ----- ----- ---- ------- ------- -----
NC 95 95 0 0 4371 0 4 26 4401
SM 17 17 0 0 293 0 2 1 296
IC 25 25 0 0 247 0 4 0 251
SQ 85 85 0 0 521 0 0 89 610
RL 35 35 0 0 1830 0 5 0 1835
IX 42 42 0 0 510 0 1 0 511
ST 40 40 0 0 289 0 0 0 289
SG 13 13 0 0 313 0 0 0 313
OB 7 7 0 0 34 0 0 0 34
IF 45 45 0 0 735 0 0 0 735
RW 6 6 0 0 42 0 0 0 42
DB 14 14 0 0 404 0 4 27 435
------ -------- -------- ----- ----- ----- ---- ------- ------- -----
Total 424 424 0 0 9589 0 20 143 9752
-----------------------------------

These tests confirm the package was built correctly with all needed modules
however you must also have installed the extra componenets such as:

-----------------------------------
o GNU MP (libgmp) 4.1.2 or later
http://gmplib.org

BOTH runtime AND development components required.

libgmp is used to implement decimal arithmetic.

GNU Cobol MAY require the following external library to be installed:

***
NOTE - libltdl is NOT needed when installing on Linux,
SUN Solaris, MAC OS, CentOS or Windows
(including Cygwin, MingW and native windows).
It is also NOT needed with later versions of AIX and HP-UX.
(AIX >= 5.1 and HP-UX >= 11.1 are known to NOT require this).
(Check if you have the "dlopen" function).
***

o GNU Libtool (libltdl)
http://www.gnu.org/software/libtool/libtool.html

libltdl is used to implement dynamic CALL statements.

YOU may need to install on BSD!

The following libraries ARE required WHEN :

1) Indexed-Sequential file I/O (ISAM) is used

o Berkeley DB (libdb) 4.1 or later
http://www.oracle.com/
http://www.oracle.com/technology/products/berkeley-db/db/index.html

BOTH runtime AND development components required.

libdb is used to implement indexed file I/O.


2) SCREEN I/O is used or extended ACCEPT/DISPLAY is used

BOTH runtime AND development components required.

One of the following:

o Ncurses (ncurses) 5.2 or later
http://www.gnu.org/software/ncurses/ncurses.html

--------------------------------------

Apologies if I am teaching you to suck eggs but you will be amazed at the
number of people who forget these steps and extra elements and they are
vital for a functional GNU/Open Cobol compiler.



Vince
Bill Gunshannon
2014-04-21 12:59:57 UTC
Permalink
Post by Vince Coen
Hello Bill!
Post by Bill Gunshannon
Post by Vince Coen
Yes since v1 but I use v2.1 (with rwcs) as X64.
Post by Bill Gunshannon
I tried some stuff
this morning that used CALL and needed to take in a pointer on
the
Post by Bill Gunshannon
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs
at
Post by Bill Gunshannon
all. I tracked it down to what looked like a problem taking in
the
Post by Bill Gunshannon
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
I am not aware of any such (reported) problem.
Do you have a copy of a sample program that shows this up so I can
try it on my box. You can send it as a file attach to my email
address above ort srop me a direct email and I will pass on my
normal address for any file attachment if gmail blows.
Or, you can grab a copy yourself. :-) It's the Postgresql interface
program written by Brian Tiffin that is in the FAQ.
-------------------------------------------------------------
FreeBSD OC 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17
01:46:25 UTC 2014
Before connect:0x00000000
After connect: 0x28c03580
Status: +0000000000
User: bill
call PQexec
0x28c730c0
Version: PostgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled
by GCC FreeBSD clang ver After finish: 0x28c03580
Status: +0000000001
User after: billgreSQL 9.0.15 on i386-portbld-freebsd10.0, compiled
by GCC FreeBSD clang ver
----------------------------------------------------------------
Thu Feb 17 02:41:51 UTC 2011
Before connect:00000
After connect: 59872
Segmentation fault (core dumped)
I seem to get a different result which can be related to the fact that I
-----------------------------------------
cobc (GNU Cobol) 2.1.0
Copyright (C) 2001,2002,2003,2004,2005,2006,2007 Keisuke Nishida
Copyright (C) 2006-2012 Roger While
Copyright (C) 2013 Ron Norman
Copyright (C) 2009,2010,2012,2014 Simon Sobisch
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Built Apr 08 2014 18:44:28
Packaged Nov 23 2013 07:02:31 UTC
C version "4.8.2"
++++++++++++++++++++++++++++++++++++++++
Before connect:0x0000000000000000
After connect: 0x00000000009c85a0
Status: +0000000001
User: vince
call PQexec
0x0000000000000000
Attempt to reference unallocated memory (Signal SIGSEGV)
Abnormal termination - File contents may be incorrect
-----------------------------------------
Did you compile the compiler AND run make check
Maybe that's the problem. I am using FreeBSD and the newest version
of OpeCOBOL in the ports tree is 1.1. I use this because I have had
no luck getting OpenCOBOL running when installed from scratch. There
are too many dependencies that require specific versions of other
packages and it can never seem to resolve all the conflicts. Thus
the reason I have stuck with what is in the ports. They are the
only packages you can be sure will run on any particular version
of FreeBSD.
Post by Vince Coen
Now in my case with v2.1 get 440 tests completed ok
b) Download the test archive `newcob.val.Z' from
http://www.itl.nist.gov/div897/ctg/cobol_form.htm
uncompress newcob.val.Z
2. Move the file newcob.val to the tests/cobol85 directory
cd tests/cobol85
make test
-----------------------------------
------ Directory Information ------- --- Total Tests Information ---
Module Programs Executed Error Crash Pass Fail Deleted Inspect Total
------ -------- -------- ----- ----- ----- ---- ------- ------- -----
NC 95 95 0 0 4371 0 4 26 4401
SM 17 17 0 0 293 0 2 1 296
IC 25 25 0 0 247 0 4 0 251
SQ 85 85 0 0 521 0 0 89 610
RL 35 35 0 0 1830 0 5 0 1835
IX 42 42 0 0 510 0 1 0 511
ST 40 40 0 0 289 0 0 0 289
SG 13 13 0 0 313 0 0 0 313
OB 7 7 0 0 34 0 0 0 34
IF 45 45 0 0 735 0 0 0 735
RW 6 6 0 0 42 0 0 0 42
DB 14 14 0 0 404 0 4 27 435
------ -------- -------- ----- ----- ----- ---- ------- ------- -----
Total 424 424 0 0 9589 0 20 143 9752
-----------------------------------
These tests confirm the package was built correctly with all needed modules
-----------------------------------
o GNU MP (libgmp) 4.1.2 or later
http://gmplib.org
BOTH runtime AND development components required.
libgmp is used to implement decimal arithmetic.
***
NOTE - libltdl is NOT needed when installing on Linux,
SUN Solaris, MAC OS, CentOS or Windows
(including Cygwin, MingW and native windows).
It is also NOT needed with later versions of AIX and HP-UX.
(AIX >= 5.1 and HP-UX >= 11.1 are known to NOT require this).
(Check if you have the "dlopen" function).
***
o GNU Libtool (libltdl)
http://www.gnu.org/software/libtool/libtool.html
libltdl is used to implement dynamic CALL statements.
YOU may need to install on BSD!
1) Indexed-Sequential file I/O (ISAM) is used
o Berkeley DB (libdb) 4.1 or later
http://www.oracle.com/
http://www.oracle.com/technology/products/berkeley-db/db/index.html
BOTH runtime AND development components required.
libdb is used to implement indexed file I/O.
2) SCREEN I/O is used or extended ACCEPT/DISPLAY is used
BOTH runtime AND development components required.
o Ncurses (ncurses) 5.2 or later
http://www.gnu.org/software/ncurses/ncurses.html
--------------------------------------
Apologies if I am teaching you to suck eggs but you will be amazed at the
number of people who forget these steps and extra elements and they are
vital for a functional GNU/Open Cobol compiler.
All of which is OK if you are doing everything from scratch, by hand.
But when you have to have a number of other packages running on a
system sometimes this just isn't possible. Oh Well, it's still fun
working with COBOL even if it still isn't quite ready for prime time. :-)

bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
b***@gmail.com
2014-04-23 04:46:25 UTC
Permalink
Post by Bill Gunshannon
Before connect:00000
After connect: 59872
Segmentation fault (core dumped)
That looks really weird.

Something is borked with that build. If this persists Bill, we'll hunt it down, but there is no known systemic problem with GNU Cobol on 8 byte hardware. Nothing like that result, anyway.

Cheers,
Brian

More reading...
b***@gmail.com
2014-04-23 04:07:48 UTC
Permalink
Post by Bill Gunshannon
I don;t belong to any of their mailinglists/blogs or wahtever they are
but I am pretty sure ther are people here from the developers, so here's
one for you.
Is GNU COBOL supposed to work on 64bit machines? I tried some stuff
this morning that used CALL and needed to take in a pointer on the
return. On my 64bit machine I kept getting a "bad MOVE" command,
which was interesting in itself as the program has no MOVE verbs at
all. I tracked it down to what looked like a problem taking in the
pointer returned to the CALL statement. I built a whole new 32bit
system on VirtualBOX and tried the same program. It works fine.
So, is there a problem handling 64bit pointers? Anybody already
aware of this? Any fix on the way?
bill
Short answer, yes, GNU Cobol is designed to work on 64-bit.

Bug free in all cases? We'll get there. :-)

I'll read the rest of the thread before responding more, but for the now...

Try:

identification division.
program-id. pointer-size.
data division.
working-storage section.
01 a-pointer usage pointer.
procedure division.
display function byte-length(a-pointer) end-display
goback.
end program pointer-size.

cobc -free -x pointer-size.cob
./pointer-size

You should get a 000000008 if all is well with a 64 build. The Work In Progress for GNU Cobol 2.1+ is fairly riddled with new data types, and unlike 1.1, there are still some leaks.

One scenario I've bumped into that can generate a bad move is with the NULL keyword, instead of a warning or error message, misuse of the figurative constant can generate bad code instead. (not code that could cause surprises and unknowns - code that just hard crashes, so you'll know). It'll be fixed as we stabilize the 2.1 branch and get to detailed debugging (which lasts until valgrind is happy, both with a debug enabled compiler and then with all debug and non-debug generated executables, and then some more testing).

Off to read more of the thread now...

Cheers,
Brian
Continue reading on narkive:
Loading...