Thread: [Cobolforgcc-devel] Re: [Tiny-cobol-users] open-cobol-0.9.6
Status: Pre-Alpha
Brought to you by:
timjosling
Menu
▾
▴
cobolforgcc-devel
|
From: David E. <de...@ar...> - 2002-06-12 19:44:23
|
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 |
|
From: Keisuke N. <kni...@ne...> - 2002-06-13 04:46:26
|
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 |
|
From: Bernard G. <bg...@fr...> - 2002-06-15 14:26:59
|
Keisuke Nishida a écrit : > 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? > Yes, I think that it should definitely be another project. > > > 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? > I agree that ODBC should be a prime issue: availability first, performance next if needed. > > Keisuke > > _______________________________________________________________ > > 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 Bernard |
|
From: David E. <de...@ar...> - 2002-06-13 21:17:04
|
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 |
|
From: David E. <de...@ar...> - 2002-06-14 19:00:25
|
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 |
|
From: Tim J. <te...@me...> - 2002-06-14 22:01:33
|
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 |
|
From: David A. C. <sup...@co...> - 2002-06-15 02:04:03
|
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. . |
|
From: Tim J. <te...@me...> - 2002-06-15 02:32:47
|
"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 |
|
From: David A. C. <sup...@co...> - 2002-06-16 21:35:05
|
Tim Josling wrote: >"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. > What'chu mean, "can *you*"? Anyway, I will look at the problem. Because things like Berkeley (and other) DB's are OpenSource, I imagine we can extract a relevant part of the code as a starting point, at least. No reason these days for any of us to "start from scratch." -- 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. The SuperBiskit is starring at R.A. 20h 57m 02.15s, Decl -06deg 28' 13.5" |
|
From: David E. <de...@ar...> - 2002-06-15 03:19:59
|
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 |
|
From: vze3y7w8 <bor...@ve...> - 2002-06-15 03:29:08
|
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/ |
|
From: Keisuke N. <kni...@ne...> - 2002-06-15 09:07:57
|
At Fri, 14 Jun 2002 23:28:29 -0400, vze3y7w8 wrote: > > 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. Do you mean this project? http://sourceforge.net/projects/cobolic/ Yes, it is a good idea to have a common place as soon as possible.. Keisuke |
|
From: David E. <de...@ar...> - 2002-06-15 18:40:16
|
At 11:28 PM 14/06/02 -0400, Boris Kortiak wrote: > 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. Actually the project registered in April 2001. I have downloaded from CVS the sources, but the configuration is not working. There are several COBOL related projects on SF. Unfortunately none appear active. There even one called Legacy Tcl (1), which uses Tcl and COBOL. 1) Legacy Tcl http://sourceforge.net/projects/legacytcl/ David Essex |
|
From: Stephen B. <st...@cf...> - 2002-06-17 01:33:06
|
On June 15, 2002 1:16 PM "David Essex" <de...@ar...> wrote: <snip> > > 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 MyISAM is still the standard filesystem used with MySQL. I use myisam extensively in my Cobol interface. It is fast and multi-user. I see only these difficulties with myisam: 1. The only documentation is what I wrote. It is not complete. 2. It does not support row-level locking. Instead, when rewriting, you provide a copy of the before buffer, and it checks the record has not been changed since then. 3. I found a couple of bugs in my usage. Either there are some bugs, or I was not using it properly - but see #1. 4. Monty Widenius is the only programmer who fully understands myisam. I am seeking a reliable, affordable Cobol. It is very encouraging to me that these three Cobol compiler teams are cooperating. Stephen, Sydney |
|
From: Keisuke N. <kni...@ne...> - 2002-06-15 09:02:05
|
Hi, I have somehow arranged my NIST-test supporting tools for TinyCOBOL: http://www.nurs.or.jp/~knishida/cobol-testsuite.tar.gz See README in the subdirectory `cobol85' for usage. If you run the test, test reports will be stored in report.txt for each test module. Would you like it? At Sat, 15 Jun 2002 07:52:25 +1000, Tim Josling wrote: > > > 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. Their test archive is not self-extracting by itself. We need some supporting scripts that help extracting, as well as scripts that summarize the test results. By the way, NIST also distributes Embedded SQL Test Suite for various languages, including COBOL: http://www.itl.nist.gov/div897/ctg/sql_form.htm Did anyone try it? Keisuke |
|
From: David E. <de...@ar...> - 2002-06-15 18:40:18
|
At 06:03 PM 15/06/02 +0900, Keisuke Nishida wrote: > I have somehow arranged my NIST-test supporting tools for TinyCOBOL: > ... > Would you like it? I ran some test with the OC NIST test suite from OC-0.9.6 and TC CVS version. It seams to work OK. Unfortunately there are some problems with the TC DISPLAY/ACCEPT syntax so I could not complete the tests. I think the OC NIST test suite could be used for all COBOL projects. I would like to suggest that a shell script be added so the test suite can be configured for each COBOL project (ex: setup.sh OC or TC or CG). Also I would like to see the Makefile changed so only specific modules can be tested (ex: make SM). Other wise I would like that the NIST test suite be the first entry in the COBOL utilities project. David Essex |
|
From: <bg...@fr...> - 2002-06-17 15:44:52
|
En réponse à David Essex <de...@ar...>: > At 06:03 PM 15/06/02 +0900, Keisuke Nishida wrote: > > > I have somehow arranged my NIST-test supporting tools for TinyCOBOL: > > ... > > Would you like it? > > I ran some test with the OC NIST test suite from OC-0.9.6 and TC CVS > version. > > It seams to work OK. > > Unfortunately there are some problems with the TC DISPLAY/ACCEPT syntax > so > I could not complete the tests. > > I think the OC NIST test suite could be used for all COBOL projects. > > I would like to suggest that a shell script be added so the test suite > can > be configured for each COBOL project (ex: setup.sh OC or TC or CG). > And the location of the compiler (i.e. installed or in development). Unless you prefer to play with the path?! > Also I would like to see the Makefile changed so only specific modules > can > be tested (ex: make SM). > I would even recommend that we be able to test individual programs, or at least, to be able not to run all programs before a given one; that's why I started coding Makefile's instead of one big script. Another issue is to take care of "manual" runs like NC109M. > Other wise I would like that the NIST test suite be the first entry in > the > COBOL utilities project. > > David Essex Practically, I think we should first start the new project, donate what is needed, and when ok, suppress tools from our specific projects. So, who registers the cobol-utils project? Bernard |
|
From: Keisuke N. <kni...@ne...> - 2002-06-18 03:26:24
|
At Mon, 17 Jun 2002 17:44:49 +0200 (MEST), bg...@fr... wrote: > > > I would like to suggest that a shell script be added so the test > > suite can be configured for each COBOL project (ex: setup.sh OC or > > TC or CG). > > And the location of the compiler (i.e. installed or in development). > Unless you prefer to play with the path?! I'll do it. > > Also I would like to see the Makefile changed so only specific > > modules can be tested (ex: make SM). What about "cd SM && make"? This is the way I do now. Changing the current directory eases you to open the source. > Another issue is to take care of "manual" runs like NC109M. It can be run as follows: ./NC109M < NC109M.DAT Note you still need to check some of the result manually, which is not automatically done by my scripts yet. Keisuke |
|
From: Keisuke N. <kni...@ne...> - 2002-06-15 09:40:07
|
At Fri, 14 Jun 2002 14:54:02 -0400, David Essex wrote: > > > License? LGPL would be good. > > The programs could be released under the GPL and libraries under the LGPL. I agree. > > Can we make the code > > > > A) front-end agnostic. > > No 'int display_number (struct tiny_cobol_number *n);' types of things > > B) ANSI C? It should be, in the same sense that DB or GMP is. > > What coding standards would you propose, if any? I prefer GNU's indent style, just because I have been used to it. I do not care much about commenting, at least when the project is evolving like now. Writing a readable code is more important than having a comment, I think. Keisuke |
|
From: Tim J. <te...@me...> - 2002-06-14 10:39:15
|
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 |
|
From: Tim J. <te...@me...> - 2002-06-15 03:30:14
|
> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X