OpenCOBOL/GNUCobol

[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


--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Luuk]

On 20-4-2014 03:18, Bill Gunshannon wrote:
> 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]

Hello Bill!

20 Apr 14 02:18, Bill Gunshannon wrote to All:

> Is GNU COBOL supposed to work on 64bit machines?

Yes since v1 but I use v2.1 (with rwcs) as X64.

> 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]

In article <13980...@f1.n250.z2.fidonet.ftn>,

"Vince Coen" <VBC...@gmail.com> writes:
> Hello Bill!
>
> 20 Apr 14 02:18, Bill Gunshannon wrote to All:
>
> > Is GNU COBOL supposed to work on 64bit machines?
>
> Yes since v1 but I use v2.1 (with rwcs) as X64.
>
> > 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 ro...@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 ro...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64


Before connect:00000
After connect: 59872
Segmentation fault (core dumped)

>
> 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.

[Vince Coen]

Hello Bill!

20 Apr 14 18:44, Bill Gunshannon wrote to All:

>> 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]

In article <13980...@f1.n250.z2.fidonet.ftn>,
"Vince Coen" <VBC...@gmail.com> writes:

> Hello Bill!
>
> 20 Apr 14 18:44, Bill Gunshannon wrote to All:
>
> >> 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.

>
> 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.

[Vince Coen]

Hello Bill!

20 Apr 14 18:44, Bill Gunshannon wrote to All:

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:

-----------------------------------------
[vince@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"

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

[vince@study ~]$ cobc -x -lpq test-4-bill.cbl
[vince@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
[vince@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

[Vince Coen]

Hello Bill!

20 Apr 14 21:04, Bill Gunshannon wrote to All:

> 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'!

>>
>> 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.

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]

In article <13980...@f1.n250.z2.fidonet.ftn>,
"Vince Coen" <VBC...@gmail.com> writes:

> Hello Bill!
>
> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>
> > 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'!
>
> >>
> >> 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.
>
> 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?

>
> 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? :-)

>
> 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 Gunshannon]

In article <13980...@f1.n250.z2.fidonet.ftn>,
"Vince Coen" <VBC...@gmail.com> writes:

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.

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. :-)

[Pete Dashwood]

Bill Gunshannon wrote:
> In article <13980...@f1.n250.z2.fidonet.ftn>,
> "Vince Coen" <VBC...@gmail.com> writes:
>> Hello Bill!
>>
>> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>>

<snip>>

> 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.

>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.

>
>>
>> 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]

In article <brlo2o...@mid.individual.net>,

"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> Bill Gunshannon wrote:
>> In article <13980...@f1.n250.z2.fidonet.ftn>,
>> "Vince Coen" <VBC...@gmail.com> writes:
>>> Hello Bill!
>>>
>>> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>>>
> <snip>>
>> 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:

As stated, FreeBSD. Haven't really tried any of this under Windows Server
but might be fun to see what happens.

>
> 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.

>
> 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!!!)

>
> 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. :-)

>
> 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.
>
>>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?

>
> 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 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.

>
> 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.

>
>
>>
>>>
>>> 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 Gunshannon]

In article <13980...@f1.n250.z2.fidonet.ftn>,
"Vince Coen" <VBC...@gmail.com> writes:

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 Gunshannon]

In article <brnj3l...@mid.individual.net>,

bi...@server3.cs.scranton.edu (Bill Gunshannon) writes:
> In article <13980...@f1.n250.z2.fidonet.ftn>,
> "Vince Coen" <VBC...@gmail.com> writes:
>> Hello Bill!
>>
>> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>>
>> > 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'!
>>
>> >>
>> >> 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.
>>
>> 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.

[Pete Dashwood]

Bill Gunshannon wrote:
> In article <13980...@f1.n250.z2.fidonet.ftn>,
> "Vince Coen" <VBC...@gmail.com> writes:
>> Hello Bill!
>>
>> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>>
>>> 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'!
>>
>>>>
>>>> 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.
>>
>> 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

[bwmt...@gmail.com]

On Saturday, April 19, 2014 9:18:52 PM UTC-4, Bill Gunshannon wrote:
> 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

[Pete Dashwood]

Bill Gunshannon wrote:
> In article <brlo2o...@mid.individual.net>,
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>> Bill Gunshannon wrote:
>>> In article <13980...@f1.n250.z2.fidonet.ftn>,
>>> "Vince Coen" <VBC...@gmail.com> writes:
>>>> Hello Bill!
>>>>
>>>> 20 Apr 14 21:04, Bill Gunshannon wrote to All:
>>>>
>> <snip>>
>>> 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:
>
> As stated, FreeBSD. Haven't really tried any of this under Windows
> Server but might be fun to see what happens.
>
>>
>> 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.

>
>>
>> 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.

>
>>
>> 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.

>>
>> 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.

>>
>>> 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.

>
>>
>> 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.

>
>>
>> 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.

>
>>
>> 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.

>
>>
>>
>>>
>>>>
>>>> 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...



> 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.

>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.

>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.

>
> 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.

> 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.

[bwmt...@gmail.com]

>
> 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...

[bwmt...@gmail.com]

> > 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

[bwmt...@gmail.com]

> 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.

> 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

[bwmt...@gmail.com]

> 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.

> 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.

>
>
>
> 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.
>
>
>
>
>
> >
>
> >>
>
> >> 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.

>
> >
>
> > 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

[bwmt...@gmail.com]

>
> 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

[bwmt...@gmail.com]

>
> > 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.

>
>
>
> 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.
>
> >
>
> >>
>
> >> 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]

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.


>
> 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 Dashwood]

bwmt...@gmail.com wrote:
>>> 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...

>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...

>
> 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>

> 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.

I sincerely wish you well with it, Brian.

[Bill Gunshannon]

In article <brot34...@mid.individual.net>,

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.

>
> 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.

>>
>>>
>>> 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.

>
>>
>>>
>>> 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.
>
>>>
>>> 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?

>>>
>>>> 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.

>>
>>>
>>> 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?

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.

>
> 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.
>>
>>>
>>> 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.

>
>>
>>>
>>>
>>>>
>>>>>
>>>>> 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...
>
>
>
>> 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.
>
>>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.

>
>>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.

>
>
>>
>> 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.

>
>
>> 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 Gunshannon]

In article <61500a1e-98eb-453c...@googlegroups.com>,

bwmt...@gmail.com writes:
>
>> 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.

> 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.

>> 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.

>
> 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.

> 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.

> 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. :-)

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

One last thing. Earlier you said:

> 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 Gunshannon]

In article <bromf3...@mid.individual.net>,

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.

[bwmt...@gmail.com]

Yes.

>
>
>
> 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.

>
>
> 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.

>
>
>
> 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). :-)

>
>
>
> (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.

>
>
>
>
>
> <snip>
>
> > 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.

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

[Pete Dashwood]

bwmt...@gmail.com wrote:
> On Wednesday, April 23, 2014 5:47:12 AM UTC-4, Pete Dashwood wrote:
>>

<snip>

>>> 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.
>

>> 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.

>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?

>
>>
>>
>> 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).

>
> 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... :-)

>
> 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?"

>
> 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...

>
> 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.

>
> 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.
>
>>
>>
>>
>> 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.

>
>>
>>
>>
>> (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.

>
>>
>>
>>
>>
>>
>> <snip>
>>
>>> 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.

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?

>
> 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.

>
> 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.

>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...

>
> 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

[Richard]

On Tuesday, April 22, 2014 11:31:35 AM UTC+12, Pete Dashwood wrote:

> 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.

> 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.

[Richard]

On Wednesday, April 23, 2014 4:15:30 PM UTC+12, Pete Dashwood wrote:



>> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

[Richard]

On Wednesday, April 23, 2014 9:47:12 PM UTC+12, Pete Dashwood wrote:
>
> 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.

> 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.

> 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]

In article <brr1vp...@mid.individual.net>,

"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> bwmt...@gmail.com wrote:
>> On Wednesday, April 23, 2014 5:47:12 AM UTC-4, Pete Dashwood wrote:
>>>
> <snip>
>
>>>> 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.
>>
>
>>> 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.

>
> 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.

>
>
>>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.

>
> 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.

>
> 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.

>
>>
>>>
>>>
>>> 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.

>
> 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.

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.

>
> (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.

>
>
>
>>
>> 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.

>>
>> 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.

>
>>
>> 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.
>>
>>>
>>>
>>>
>>> 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?

>
> That's why I support what you (plural) are doing and give all of you
> respect.
>
>>
>>>
>>>
>>>
>>> (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!!!

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.

>
> 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.

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. :-)

>
> 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.

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.

[bwmt...@gmail.com]

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

[bwmt...@gmail.com]

On Thursday, April 24, 2014 10:38:18 AM UTC-4, Bill Gunshannon wrote:

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

[bwmt...@gmail.com]

>
> > 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

[bwmt...@gmail.com]

On Thursday, April 24, 2014 10:38:18 AM UTC-4, Bill Gunshannon wrote:

> In article <brr1vp...@mid.individual.net>,
>
> "Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
>
> > bwmt...@gmail.com wrote:
>
> >> On Wednesday, April 23, 2014 5:47:12 AM UTC-4, Pete Dashwood wrote:
>
> >>>
>
> > <snip>
>
> >
>
> >>>> 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.
>
> >>
>
> >
>
> >>> 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.

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.

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.

>
>
>
> 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.
>
>
>
> >
>
> > 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. :-)

>
>
>
> 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.

>
>
>
> >
>
> >>
>
> >>>
>
> >>>
>
> >>> 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.

>
>
>
> 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.

>
>
>
> >
>
> > 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.

>
>
>
> 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.
>
>
>
> >
>
> >>
>
> >> 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.

> >
>
> >
>
> >>
>
> >> 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.

> >
>
> > 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.

> >
>
> > 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.

>
> >
>
> > 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. :-)

>
>
>
> 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.

>
>
>
> >
>
> > (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) ;-)

>
> >
>
> > 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.
>
>
>
> >
>
> >
>
> >
>
> >>
>
> >> 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.

Yep, way too much fun. Playing with MathGL tonight, plotting.

>
>
>
> Is that the same NOBODY that uses COBOL today?
>
>
>
> >
>
> > 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. ;-)

>
> >
>
> >>
>
> >>>
>
> >>>
>
> >>>
>
> >>> (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!!!
>
>
>
> >> 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.

I'm all for that sentiment. Nice.

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. ;-)

>
>
>
> 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).

>
>
>
> >
>
> >>
>
> >> 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.
>
> >>
>
> >> 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.
>
> >
>
> >>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?

>
> >
>
> > 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)

>
> >
>
> >
>
> >>
>
> >> 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