tiny-cobol-users

[Tiny-cobol-users] Re: [Cobolforgcc-devel] Re: COBOL utilities project

[Tim J. <te...@me...>]

> What I would to see is an OpenISAM project with the following criteria.
> - XOpen ISAM standard conformity.
> - Low level concurrence file locking.
> 
> If there are any volunteers who would like to work on this project, then
> the project is all your.
> 
> David Essex
> 

I agree. 

This is a technically interesting and challenging project, but it does not
require people to learn gcc or assembler or other horrors.

Building a reliable fast multi-user indexed file system is non trivial.

A good sort utility would be another good discrete project, the unix sort
utility not quite being up to it.

Tim Josling

[Tiny-cobol-users] RE: [Cobolforgcc-devel] Re: COBOL utilities project

[vze3y7w8 <bor...@ve...>]

PMFJI,

Did anyone notice the Cobolic project that was open around 2002/04/26?
The primary intent seems to be to create libraries for numeric
processing.  I do not think there has been any activity, but it may be a
useful place to discuss these topics.

bo...@ko...
http://www.boriskortiak.com/

[Tiny-cobol-users] Re: COBOL utilities project

[David E. <de...@ar...>]

At 10:03 PM 14/06/02 -0400, David A. Cobb wrote:

> Tim Josling wrote:
>
>> David Essex wrote:
>> ...  
>>> How is COBOL4GCC going to deal with indexed files ? 
>>> Will it also be using DB ?
>>
>> Probably. I will probably reuse whatever you guys are doing. 
>> Maybe later on we might do a custom piece but I think DB is 
>> good enough to start.
>
> Isn't DB (Berkeley, IIRC) rather overkill?  Some of their code, maybe, 
> but there's a lot more in a DB than is needed for COBOL ISAM.  A COBOL 
> indexed file has an unsurprising similarity to an IBM VS*M file system. 
> Other than how it manages space allocation and lock management, there's 
> nothing very sophisticated about VSAM, it's still a 1970's concept.  In 
> contrast, even the simple xBase indexed structure "knows" more about the 
> structure of the data.  In fact, the only thing required of an indexed 
> file is that the key be the same sequential character positions in every 
> record -- the records need not even be the same otherwise.  That would 
> drive a DB system bonkers.

Berkeley DB maybe overkill, and ISAM maybe a 1970's concept, but
unfortunately there are no free nor open source implementation of ISAM.

This has been one of the killer problems in many open source COBOL projects.

MySQL used a version of ISAM, but recently they converted to DB for the low
level structures.

So AFIK, DB is the only choice available.

The closest implementation of VS*M on UN*X is C-IS*M, which by the way is
now owned by I*M.

What I would to see is an OpenISAM project with the following criteria.
- XOpen ISAM standard conformity.
- Low level concurrence file locking.

If there are any volunteers who would like to work on this project, then
the project is all your.




David Essex

Re: [Tiny-cobol-users] Re: [open-cobol-list] Re: [Cobolforgcc-devel]COBOL utilities project(was: open-cobol-0.9.6)

[Tim J. <te...@me...>]

Rildo Pragana wrote:
> ..
> I don't understand what you mean with "bust".

Rildo,

Sorry it means go bankrupt (in Australian). For someone buying proprietary
sofwtare, the chance that the vendor will go out of business is a real
problem. The failure rate of software companies is high. Products get dropped,
prices get put up, etc.

But whatever happens to Rildo, Tiny COBOL and free COBOL generally will go on. 

Tim Josling

[Tiny-cobol-users] Re: [open-cobol-list] Re: [Cobolforgcc-devel] COBOL utilities project(was: open-cobol-0.9.6)

[Tim J. <te...@me...>]

"David A. Cobb" wrote:

> Isn't DB (Berkeley, IIRC) rather overkill? ...
> David A. Cobb, Software Engineer, Public Access Advocate

Possibly. I knew I shouldn't have expressed a view. In general I would be
happy to use it as long as the surplus function does not get in the way. 

I work as a software architect. We have this problem all the time. A package
has at the same time more and less function that we need. 

If we can
- add the missing bits without too much angst AND
- ignore the surplus (often this is not easy)
then we will use it.

The question is, can you do better by starting from scratch? Others would have
the basis for a more informed view than I would.

Ignoring other issues from the commercial world such as vendor viability which
are not such an issue with free software. If Rildo goes bust Tiny COBOL will
live.

Tim Josling

[Tiny-cobol-users] Re: [open-cobol-list] Re: [Cobolforgcc-devel] COBOL utilities project (was: open-cobol-0.9.6)

[David A. C. <sup...@co...>]

Tim Josling wrote:

>David Essex wrote:
>  
>
>>Tim, just a few questions regarding COBOL4GCC.
>>
>>    
>>
>>How is COBOL4GCC going to deal with indexed files ? Will it also be using DB ?
>>
>>    
>>
>
>Probably. I will probably reuse whatever you guys are doing. Maybe later on we
>might do a custom piece but I think db is good enough to start.
>
Isn't DB (Berkeley, IIRC) rather overkill?  Some of their code, maybe, 
but there's a lot more in a DB than is needed for COBOL ISAM.  A COBOL 
indexed file has an unsurprising similarity to an IBM VSAM filesystem. 
 Other than how it manages space allocation and lock management, there's 
nothing very sophisticated about VSAM, it's still a 1970's concept.  In 
contrast, even the simple xBase indexed structure "knows" more about the 
structure of the data.  In fact, the only thing required of an indexed 
file is that the key be the same sequential character positions in every 
record -- the records need not even be the same otherwise.  That would 
drive a DB system bonkers.

-- 
David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.
.

[Tiny-cobol-users] Re: [Cobolforgcc-devel] COBOL utilities project (was: open-cobol-0.9.6)

[Tim J. <te...@me...>]

David Essex wrote:
> Tim, just a few questions regarding COBOL4GCC.
> 
> How is COBOL4GCC going to deal with large numbers, specifically
> intermediate variables which require 33 digits, according to the COBOL 2002
> draft standard.
> 

David Sadler is working on an implementation of Knuth's algorithms. I looked
at gmp and had the same issue of size. Also the use of dynamically allocated
storage would be a pain to manage, especially in the GCC environment.

> How is COBOL4GCC going to deal with indexed files ? Will it also be using DB ?
> 

Probably. I will probably reuse whatever you guys are doing. Maybe later on we
might do a custom piece but I think db is good enough to start.

> The first project will probably be the NIST test suite. Currently there are
> two versions, one for TC and one for OC. Do you have any comments
> suggestions on this ?
> 

I don't know enough to comment. I thought the NIST was supposed to be self
extracting, so there should not be an issue. Just shows how much I don't know
about this, I guess.

>  ..
> David Essex
> 

Regards,
Tim Josling

[Tiny-cobol-users] COBOL utilities project (was: open-cobol-0.9.6)

[David E. <de...@ar...>]

At 08:30 PM 14/06/02 +1000, Tim Josling wrote:

> ...
> A few questions:
>
> License? LGPL would be good.

The programs could be released under the GPL and libraries under the LGPL.

> Can we make the code 
>
> A) front-end agnostic. 
> No 'int display_number (struct tiny_cobol_number *n);' types of things
> B) ANSI C?
>
> What coding standards would you propose, if any? I am used to gcc where they
> are very fussy about fullstops on comments and all. Maybe that is over
the top
> but I do find it very useful to have a comment at top of file and before a
> function saying what it is for.

I have no preference with coding standards, as long you start and stick
with one.

The only criteria I have is that sources should configure, compile and run
on all supported platforms, from old libc5 Linux to native Win32 (MinGW).


Tim, just a few questions regarding COBOL4GCC.

How is COBOL4GCC going to deal with large numbers, specifically
intermediate variables which require 33 digits, according to the COBOL 2002
draft standard.

How is COBOL4GCC going to deal with indexed files ? Will it also be using DB ?

The first project will probably be the NIST test suite. Currently there are
two versions, one for TC and one for OC. Do you have any comments
suggestions on this ?


Does nay else have any comments and or suggestions ? 

Rildo, what do you think of this proposal ?





David Essex

Re: [Tiny-cobol-users] About the bug in DISPLAY/ACCEPT.

[Ferran P. <fer...@re...>]

This is my fault, I missed something on my last changes. I will commit 
the solution today.

Rildo Pragana wrote:

>Hi,
>
>Looking into the code of our parser, I found what is wrong. Bingo!
>The trouble is with the ACCEPT statement (at htcobol.y).
>The variable screen_io_enable must be set (screen_io_enable++) if
>and only if one of the following hold:
>(1) LINE...POSITION... clauses are in use;
>(2) a SCREEN SECTION is detected;
>(3) some other clause that position the cursor somewhere in the screen
>    is found (any new clauses added? I don't know...)
>
>But in all actions for the "accept_screen:" non-terminal (where regular
>ACCEPTs are now parsed) set that flag on.
>
>The code generator check that flag to call either "accept_std" or
>"accept_curses".
>
>Please, who made that changes in our parser, remove that
>screen_io_enable++ statements where appropriate. 
>Thank you!  
>(Well, I'm really too lazy to try to understand everything,
>including the new syntax added, to make the changes myself.
>So, I'm giving the hints here ;)
>
>Anyway, the bugs hunting season are on again!
>
>best regards,
>Rildo
> ----------------------------------------------------------------
> Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
> P.O. Box 721 Camaragibe PE    http://www.pragana.net
> Brazil 54792-990              +55-81-3223-5694
>
>
>_______________________________________________________________
>
>Don't miss the 2002 Sprint PCS Application Developer's Conference
>August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
>_______________________________________________
>Tin...@li...
>https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users
>  
>


-- 
Salutacions / Regards
+---------------------------------------------------------------+
| Ferran Pegueroles Forcadell                                   |
| mailto:fer...@re...                          |
| Tels (+34)937252106 - (+34)667658535                          |
| C/Unió 44 2n 2a 08201 Sabadell (BCN)                          |
+---------------------------------------------------------------+

[Tiny-cobol-users] Re: [Cobolforgcc-devel] Re: open-cobol-0.9.6

[Tim J. <te...@me...>]

David Essex wrote:
> 
> At 01:47 PM 13/06/02 +0900, Keisuke Nishida wrote:
> 
> > At Wed, 12 Jun 2002 15:40:17 -0400, David Essex wrote:
> > ...
> >> In my view the above are relatively independent projects which could easily
> >> be shared between projects.
> > ...
> > Right.  Should we start a new project, like cobol-utils, which
> > shares common utilities, libraries, and test suites?
> 
> Sounds OK to me.
> 

Sounds great to me. 

I was intending to steal your runtime later on anyway so this makes it formal.
A few questions:

Licence? LGPL would be good.

Can we make the code 

A) front-end agnostgic. No 'int display_number (struct tiny_cobol_number *
n);' types of things
B) ANSI C?

What coding standards would you propose, if any? I am used to gcc where they
are very fussy about fullstops on comments and all. Maybe that is over the top
but I do find it very useful to have a comment at top of file and before a
function saying what it is for.

I subscribe to tiny-cobol so no need to reply beyond there...

Tim Josling

[Tiny-cobol-users] About the bug in DISPLAY/ACCEPT.

[Rildo P. <ri...@pr...>]

Hi,

Looking into the code of our parser, I found what is wrong. Bingo!
The trouble is with the ACCEPT statement (at htcobol.y).
The variable screen_io_enable must be set (screen_io_enable++) if
and only if one of the following hold:
(1) LINE...POSITION... clauses are in use;
(2) a SCREEN SECTION is detected;
(3) some other clause that position the cursor somewhere in the screen
    is found (any new clauses added? I don't know...)

But in all actions for the "accept_screen:" non-terminal (where regular
ACCEPTs are now parsed) set that flag on.

The code generator check that flag to call either "accept_std" or
"accept_curses".

Please, who made that changes in our parser, remove that
screen_io_enable++ statements where appropriate. 
Thank you!  
(Well, I'm really too lazy to try to understand everything,
including the new syntax added, to make the changes myself.
So, I'm giving the hints here ;)

Anyway, the bugs hunting season are on again!

best regards,
Rildo
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://www.pragana.net
 Brazil 54792-990              +55-81-3223-5694

[Tiny-cobol-users] Bugs in DISPLAY compiler/library.

[Rildo P. <ri...@pr...>]

Hi,

Someone changed the compiling of DISPLAY statements so now we only have
the (n)curses version.  The intent is to have a curses version is to
handle SCREEN SECTION, but _not_ for regular DISPLAY/ACCEPTs.
Any program with DISPLAY/ACCEPT now _require_ being linked with -lncurses,
what is definitely wrong.
Lots of previously working programs now don't work anymore!

May someone please tell me what was changed, while I was away from the
project?  Is there a special reason to change the behaviour of
DISPLAY/ACCEPT ?

best regards,
Rildo
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://www.pragana.net
 Brazil 54792-990              +55-81-3223-5694

[Tiny-cobol-users] Re: open-cobol-0.9.6

[David E. <de...@ar...>]

At 01:47 PM 13/06/02 +0900, Keisuke Nishida wrote:

> At Wed, 12 Jun 2002 15:40:17 -0400, David Essex wrote:
> ... 
>> In my view the above are relatively independent projects which could easily
>> be shared between projects.
> ...
> Right.  Should we start a new project, like cobol-utils, which
> shares common utilities, libraries, and test suites?

Sounds OK to me.

Perhaps one could think of this as a group of projects under the same banner.

If no one objects, I think the first utility should be the NIST test suite.

And the second should be some kind of Indexed/Relative file utility and
library.


>> As for the embedded SQL pre-processor for COBOL, this is also a separate
>> project, a rather large project.
>> 
>> The problem here is that each database has a different internal API. So to
>> create a generic SQL pre-processor in my view is not realistic. 
>> 
>> Yes, one could use ODBC, but there some performance issues there.
>
> I do not think performance is a big issue at this moment.
> Having a generic interface that works is better than nothing.
> We can improve the interface when performance really become
> an issue.
>
> Many databases seem to support ODBC on Linux already.  What
> about having a preprocessor and a run-time library that
> support ODBC?

There are at least 2 ODBC projects distributed under the GPL. So part of
the work is done.

But that still leaves the SQL parser/scanner, no small project.

Perhaps it would be easier to adapt an existing open source C SQL
preprocessor to COBOL. 

The only one I know of is PostgreSQL, but it is distributed under the
Berkeley license.





David Essex

Re: [Tiny-cobol-users] open-cobol-0.9.6

[David E. <de...@ar...>]

At 11:13 AM 13/06/02 +0200, Ferran Pegueroles wrote:
> ...
> Apart from the problems we are having with the indexed files, I think we 
> can borrow some code from OpenCOBOL from the math with big numbers, I 
> think it shouldn't be difficult to adapt to TC.

I agree the use of the GMP library is an option.

However later versions of this library, versions 3 and 4, are not a
available for the native Win32 platform (MinGW). At least I have not be
able to find any binaries nor information.

Also the size of this library is relatively large, larger than TC itself.
And I do not think TC really needs the kind of functionality provided by GMP.




David Essex

[Tiny-cobol-users] TinyCOBOL hanked high in Kartoo

[Rildo P. <ri...@pr...>]

Hi,

If you search for "linux programming" at http://www.kartoo.com
(a cool new search engine, bookmark it!) you will find
TC website hanked high, on the second map.

If you search for "cobol" (yes, just cobol), TC's link is the biggest
in the first map. Amazing, isn't it?

This is a strong indication that we are reaching mainstream.

best regards,
Rildo
 ----------------------------------------------------------------
 Rildo Pragana                 FPGA/uControllers * Linux * tcl/tk
 P.O. Box 721 Camaragibe PE    http://www.pragana.net
 Brazil 54792-990              +55-81-3223-5694

[Tiny-cobol-users] File status for correct reads

[Ferran P. <fer...@re...>]

The file status for a correct read from the file should be 00 but 
instead it is spaces (and the field is a pic 99).

In this modified versions of test18 you can see this.

-- 
Salutacions / Regards
+---------------------------------------------------------------+
| Ferran Pegueroles Forcadell                                   |
| mailto:fer...@re...                          |
| Tels (+34)937252106 - (+34)667658535                          |
| C/Unió 44 2n 2a 08201 Sabadell (BCN)                          |
+---------------------------------------------------------------+

Re: [Tiny-cobol-users] open-cobol-0.9.6

[Ferran P. <fer...@re...>]

David Essex wrote:

>Yes, I agree there should be more cooperation not only between open-COBOL
>and TC, but with cobol4gcc also.
>
>Unfortunately this is easier said than done.
>
>Some areas where I would like to see more cooperation are the following.
>
>- The NIST test suite
>- SORT/MERGE utility
>  (Some thing like CA-So*t, Syncs*rt, ...)
>- Indexed/Relative file utility 
>  (ISAM, C-IS*M to the Xopen standard with file locks etc.)
>
>In my view the above are relatively independent projects which could easily
>be shared between projects.
>
>For example both the SORT/MERGE and indexed/Relative file utilities could
>be used as a stand alone program or as a library used by any of the
>projects run-time.
>
>  
>
Apart from the problems we are having with the indexed files, I think we 
can borrow some code from Open Cobol from the math with big numbers, I 
think it shouldn't be dificult to adapt to TC.

-- 
Salutacions / Regards
+---------------------------------------------------------------+
| Ferran Pegueroles Forcadell                                   |
| mailto:fer...@re...                          |
| Tels (+34)937252106 - (+34)667658535                          |
| C/Unió 44 2n 2a 08201 Sabadell (BCN)                          |
+---------------------------------------------------------------+

Re: [Tiny-cobol-users] open-cobol-0.9.6

[Keisuke N. <kni...@ne...>]

At Wed, 12 Jun 2002 15:40:17 -0400,
David Essex wrote:
> 
> Some areas where I would like to see more cooperation are the following.
> 
> - The NIST test suite
> - SORT/MERGE utility
>   (Some thing like CA-So*t, Syncs*rt, ...)
> - Indexed/Relative file utility 
>   (ISAM, C-IS*M to the Xopen standard with file locks etc.)
> 
> In my view the above are relatively independent projects which could easily
> be shared between projects.
> 
> For example both the SORT/MERGE and indexed/Relative file utilities could
> be used as a stand alone program or as a library used by any of the
> projects run-time.

Right.  Should we start a new project, like cobol-utils, which
shares common utilities, libraries, and test suites?

> As for the embedded SQL pre-processor for COBOL, this is also a separate
> project, a rather large project.
> 
> The problem here is that each database has a different internal API. So to
> create a generic SQL pre-processor in my view is not realistic. 
> 
> Yes, one could use ODBC, but there some performance issues there.

I do not think performance is a big issue at this moment.
Having a generic interface that works is better than nothing.
We can improve the interface when performance really become
an issue.

Many databases seem to support ODBC on Linux already.  What
about having a preprocessor and a run-time library that
support ODBC?

Keisuke

Re: [Tiny-cobol-users] open-cobol-0.9.6

[David E. <de...@ar...>]

At 09:45 PM 12/06/02 +0900, Keisuke Nishida wrote:

> ...
> At the moment, OpenCOBOL lacks many facilities that TinyCOBOL
> has, including SORT/MERGE statements, intrinsic functions,
> SCREEN SECTION, embedded SQL, and GDB supports.  
> ...
> Still I think it would be great if we could share some 
> ideas and resources (like test suite), as we both have 
> the same goal: implementing an open-source COBOL compiler.
> ....

Yes, I agree there should be more cooperation not only between open-COBOL
and TC, but with cobol4gcc also.

Unfortunately this is easier said than done.

Some areas where I would like to see more cooperation are the following.

- The NIST test suite
- SORT/MERGE utility
  (Some thing like CA-So*t, Syncs*rt, ...)
- Indexed/Relative file utility 
  (ISAM, C-IS*M to the Xopen standard with file locks etc.)

In my view the above are relatively independent projects which could easily
be shared between projects.

For example both the SORT/MERGE and indexed/Relative file utilities could
be used as a stand alone program or as a library used by any of the
projects run-time.

As for the embedded SQL pre-processor for COBOL, this is also a separate
project, a rather large project.

The problem here is that each database has a different internal API. So to
create a generic SQL pre-processor in my view is not realistic. 

Yes, one could use ODBC, but there some performance issues there.

Also most commercial database vendors do include a SQL pre-processor with
the database.

As for open source database, to my knowledge Firebird it is the only one
which has a COBOL SQL pre-processor.

PostgreSQL has C SQL pre-processor, which could be used as a starting point
to create one for COBOL.

MySQL does not have any SQL pre-processors, so embedded SQL is not
supported. Unless some one made one as an add on product.

Anyway my 2 cents worth.






David Essex

RE: [Tiny-cobol-users] Compile errors in test.code/tdb03

[David E. <de...@ar...>]

At 11:57 AM 12/06/02 -0400, bkortiak wrote:
 
> David Essex wrote:
>> ...
>> DISPLAY
>> { identifier | literal } ...  
>> [ UPON name-1 ]  
>> [ WITH NO ADVANCING ]    
>> ...
>
> Actually he does have correct syntax.  
>
> He is using the DISPLAY { literal } form of the verb.
> The UPON and WITH clauses are optional; but there must 
> be an {identifier} or a {literal}.  
>
> So after the indicated modification to Line 71 (which 
> corrects the syntax error) why is he getting a segfault 
> on the make?

I also mentioned to do a clean build (make clean; make) in the 'compiler/'
directory.

On my system, the TC compiler no longer seg fualts, after the changes and a
clean build.  





David Essex

[Tiny-cobol-users] Bug on compiler solved

[Ferran P. <fer...@re...>]

Threr was a bug on the compiler introduced by me on the last commit. I 
deleted by error 4 lines.
This error caused a Seg Fault when reporting some kinds of errors.

 This now is solved on CVS.

-- 
Salutacions / Regards
+---------------------------------------------------------------+
| Ferran Pegueroles Forcadell                                   |
| mailto:fer...@re...                          |
| Tels (+34)937252106 - (+34)667658535                          |
| C/Unió 44 2n 2a 08201 Sabadell (BCN)                          |
+---------------------------------------------------------------+

RE: [Tiny-cobol-users] Compile errors in test.code/tdb03

[<bko...@ma...>]

-----Original Message-----
From: David Essex [mailto:de...@ar...]
Sent: Wednesday, June 12, 2002 11:36 AM
To: tiny-cobol-users
Subject: Re: [Tiny-cobol-users] Compile errors in test.code/tdb03


<snip />
>> In the file 'tdb03.cob' change the following.
>>=20
>> Line 71:
>> display
>> to
>> display " "
>>=20
>> The program should now compile normally.
>
> Ok, but If I modify the line 71 to use display " ",=20
> in compilation it shows the following errors:
> ...
> htcobol -c  -P -D -I../copybooks -I. tdb03.cob
> make: *** [tdb03.o] Falha de segmenta=E7=E3o
> ...
> If I remove the display " ", it compile with no errors.
>
> Is this a bug?

Yes and no. The required syntax is as follows.

DISPLAY { identifier | literal } ...=20
 [ UPON name-1 ]=20
 [ WITH NO ADVANCING ]=20

So just a display with no parameter is technically a syntax error.
<snip />

Actually he does have correct syntax.  He is using the DISPLAY { =
literal }
form of the verb.  The UPON and WITH clauses are optional; but there =
must be
an {identifier} or a {literal}.  So after the indicated modification to =
Line
71 (which corrects the syntax error) why is he getting a segfault on =
the
make?

Re: [Tiny-cobol-users] Compile errors in test.code/tdb03

[David E. <de...@ar...>]

At 12:36 AM 12/06/02 -0300, Hudson Reis wrote:
>
>> The errors are YY debug error trace.
>>=20
>> In file 'htcobol.y' change the following.
>>=20
>> #define YYDEBUG 1
>> to
>> /* #define YYDEBUG 1 */
>
> Ok, but if I only modify this, it shows the following=20
> message in compilation:
> ...
> bison -dv -b htcobol htcobol.y =20
> htcobol.y contains 722 shift/reduce conflicts.
> gcc -I/usr/include -I../lib -I../  -c htcobol.tab.c
> htcobol.y: In function `yyparse':
> htcobol.y:1499: `yydebug' undeclared (first use in this function)
> make: ** [htcobol.tab.o] Erro 1
> ...
> Then, I modify the line 1499 from htcobol.y    =20
> original
>  gen_marklabel(); yydebug=3D1;
> modified
> gen_marklabel(); /* yydebug=3D1; */
>
> and compile with no errors.=20
> However, I'm not a YACC programmer.. This is ok?

Yes that is correct.

But it good form to do a 'make clean', then 'make' in the compiler
directory, to ensure a clean compile.

This problem did not show up with YACC193.


>> In the file 'tdb03.cob' change the following.
>>=20
>> Line 71:
>> display
>> to
>> display " "
>>=20
>> The program should now compile normally.
>
> Ok, but If I modify the line 71 to use display " ",=20
> in compilation it shows the following errors:
> ...
> htcobol -c  -P -D -I../copybooks -I. tdb03.cob
> make: *** [tdb03.o] Falha de segmenta=E7=E3o
> ...
> If I remove the display " ", it compile with no errors.
>
> Is this a bug?

Yes and no. The required syntax is as follows.

DISPLAY { identifier | literal } ...=20
 [ UPON name-1 ]=20
 [ WITH NO ADVANCING ]=20

So just a display with no parameter is technically a syntax error.

In any case when I make the changes to 'htcobol.y' and compile with Bison,
htcobol compiles with no errors. I can also compile 'tdb03.cob' with no
problems.




David Essex

[Tiny-cobol-users] open-cobol-0.9.6

[Keisuke N. <kni...@ne...>]

Hi,

I have released OpenCOBOL 0.9.6, an open-source COBOL compiler
forked from TinyCOBOL.

  http://www.open-cobol.org/

As some of you might know, I originally started my project
because I was more comfortable with modifying the compiler
as I feel like.

After a long period of time, I have completely reimplemented
the compiler, the preprocessor, and the run-time library, and
OpenCOBOL has now become a totally different COBOL compiler
than TinyCOBOL.

A major difference between OpenCOBOL and TinyCOBOL is that
OpenCOBOL translates COBOL into C and uses GCC to build an
executable.  This means that OpenCOBOL can be ported wherever
GCC works (in theory).  Some people are using it on MacOS X,
for example.

At the moment, OpenCOBOL lacks many facilities that TinyCOBOL
has, including SORT/MERGE statements, intrinsic functions,
SCREEN SECTION, embedded SQL, and GDB supports.  On the other
hand, OpenCOBOL scores better points in the NIST's COBOL core
testsuite (NC module).

For now, I am trying to make OpenCOBOL more stable and easy
to use rather than adding lots of facilities.  After it has
become sufficiently stable for production use in my work, I am
going to implement further functionalities, like embedded SQL
with ODBC support.

I think I am going to concentrate on OpenCOBOL rather than
contributing to TinyCOBOL any more.  Still I think it would
be great if we could share some ideas and resources (like
test suite), as we both have the same goal: implementing an
open-source COBOL compiler.

I guess there are some people who are interested in OpenCOBOL,
so I have announced it here.  Any comments are welcome.

Thank you for reading.

Best regards,
Keisuke Nishida

[Tiny-cobol-users] TinyCOBOL Brazilian manfiles

[Hudson R. <hud...@so...>]

Hi all,

A Portuguese version of TinyCOBOL manfiles is avaliable.

If you interested on it, go to the TinyCOBOL Brazilian webpage(1) or download the latest version of CVS.

Thanks to Jordana Reis, my darling sister for verify and fix the translation, from english to portuguese.

Hudson Reis.

1) TinyCOBOL Brazilian webpage
   http://br.tinycobol.org