tiny-cobol-users

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

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

At 11:41 AM 17/06/02 +0900, Keisuke Nishida wrote:

> ...
> I originally used the one written for TC, which only extracted
> `NC' tests at that time.  Later I hacked the test suite and
> wrote new scripts that extract all tests (i.e., CM, DB, IC, IF,
> IX, NC, OB, RL, RW, SG, SM, SQ, and ST).

Bernard Giroud did the original investigation, created the original
CONTROL-CARD-FILE and wrote the test report program in awk.

I wrote most of the Perl scripts.

> But I have not understood the test suite completely, especially
> how to write CONTROL-CARD-FILE, and those scripts and the control
> file still need to be improved.

Unfortunately there is no information on how to use the CONTROL-CARD-FILE
in the NIST source,  
other than trail and error, and what information can be derived from the
source code.

So it definitely needs improvement.

There seams to be some differences between the TC and OC versions, perhaps
Bernard and Keisuke should compare notes on this.

At 05:44 PM 17/06/02 +0200, Bernard Giroud wrote:
> So, who registers the cobol-utils project?

While I would like to contribute to the project, I would not like to manage
it.




David Essex

Re: [Tiny-cobol-users] cancel statement

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

bg...@fr... wrote:

>En réponse à Ferran Pegueroles Forcadell <fer...@re...>:
>
>  
>
>>A implementation of the cancel statement and a restore for values when
>>returnong from a called program is implemented.
>>
>>Information of each run element is kept. When a program calls a
>>routine,
>>and returns all the configuration  values of the run element are
>>restored in the runtime.
>>
>>When cancelling a program, all the files opened by the program are
>>closed.
>>
>>Now we need to restore all the veriables of the routine to its initial
>>values. Any ideas of how do this ?
>>
>>    
>>
>
>Currently, the init code is a series of moves done only the
>first time the control reaches the top of the module.
>
>I intended one of these days (when I have a bit of time!!),
>to initialize directly in the psect.
>
>I consequently propose the following:
>
>   - add an internal entry point named something like
>     tcob_init_xxxxx where xxxxx is the original module name
>   - modify the current code to call the routine above
>     on the first call; we could still suppress the call
>     when we finalize the values in the psect.
>
>The only drawback with this method is that we might end up
>with names truncated, if the original name is very long.
>
>Bernard
>  
>
I think it is a good idea, but we still have the problem of 
reinitializing all the variables when we cancel the routine (now only 
the files are closed).

Perharps we should save a pointer to a variable holding the flag that 
indicates if we sholud initialize the variables and if we cancel the 
routine we can unset that flag.

I don't know if it is possible to make a real cancel and force the 
system to unload the routine (this will be the best solution).

I think we also have to close all the files on exit if the routine is 
initial, completing the initial implmentation.

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

[<bg...@fr...>]

En réponse à Ferran Pegueroles Forcadell <fer...@re...>:

> A implementation of the cancel statement and a restore for values when
> returnong from a called program is implemented.
> 
> Information of each run element is kept. When a program calls a
> routine,
> and returns all the configuration  values of the run element are
> restored in the runtime.
> 
> When cancelling a program, all the files opened by the program are
> closed.
> 
> Now we need to restore all the veriables of the routine to its initial
> values. Any ideas of how do this ?
> 

Currently, the init code is a series of moves done only the
first time the control reaches the top of the module.

I intended one of these days (when I have a bit of time!!),
to initialize directly in the psect.

I consequently propose the following:

   - add an internal entry point named something like
     tcob_init_xxxxx where xxxxx is the original module name
   - modify the current code to call the routine above
     on the first call; we could still suppress the call
     when we finalize the values in the psect.

The only drawback with this method is that we might end up
with names truncated, if the original name is very long.

Bernard

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

[Jeff S. <why...@ya...>]

On the subject of the NIST scripts...
  I have not seen how the OpenCobol scripts differ, but the
control card file in TinyCobol, make_pop_linux.txt,
currently is only set up to work with one module at a time.
  For those that do not know, it can be set up for multiple
modules by copying the first line and changing the module
name for each line appropriately.  Note that the names must
appear in the same order as in the big NIST file, i.e.
alphabetically.

*SELECT-MODULE IX
*SELECT-MODULE NC
*SELECT-MODULE SM

  I have not tested this extensively to see if it produces
identical results as if they were handled one at a time,
but
it at least seems to extract all the same files.

  - Jeff Smith


--- Keisuke Nishida <kni...@ne...> wrote:
> At Sat, 15 Jun 2002 15:41:41 -0400,
> David Essex wrote:
> > 
> > There is only one version of the NIST COBOL test suite.
> > However it requires scripts to extract, run the tests
> and create reports
> > on the tests.
> > 
> > Originally these scripts were added to the TC
> distribution, so any one
> > could run the NIST tests.
> > Then OC then created their own scripts which basically
> do the same thing..
> 
> I originally used the one written for TC, which only
> extracted
> `NC' tests at that time.  Later I hacked the test suite
> and
> wrote new scripts that extract all tests (i.e., CM, DB,
> IC, IF,
> IX, NC, OB, RL, RW, SG, SM, SQ, and ST).
> 
> But I have not understood the test suite completely,
> especially
> how to write CONTROL-CARD-FILE, and those scripts and the
> control
> file still need to be improved.
> 
> Keisuke

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: [Tiny-cobol-users] Re: NIST Test Suite

[<bg...@fr...>]

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

[Tiny-cobol-users] esql and error reporting

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

Is it possible to view the correct line numbers (from the original ecob 
file) of the error messagesz when compiling a file generated by the 
firebird preprocesor (gpre ) ?

-- 
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] Re: COBOL utilities project

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

At Sat, 15 Jun 2002 15:41:41 -0400,
David Essex wrote:
> 
> There is only one version of the NIST COBOL test suite.
> However it requires scripts to extract, run the tests and create reports
> on the tests.
> 
> Originally these scripts were added to the TC distribution, so any one
> could run the NIST tests.
> Then OC then created their own scripts which basically do the same thing..

I originally used the one written for TC, which only extracted
`NC' tests at that time.  Later I hacked the test suite and
wrote new scripts that extract all tests (i.e., CM, DB, IC, IF,
IX, NC, OB, RL, RW, SG, SM, SQ, and ST).

But I have not understood the test suite completely, especially
how to write CONTROL-CARD-FILE, and those scripts and the control
file still need to be improved.

Keisuke

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

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

At 11:02 PM 16/06/02 +0200, Ferran Pegueroles Forcadell wrote:

> On 2002-06-16, David Essex wrote:
> ...
>> Following some changes to the grammar, the DISPLAY/ACCEPT are working
>> again as expected. 
>
> Which were those problems ? 

Most of the test.code applications with DISPLAY/ACCEPT did compile.

The tests from the NIST test suite did not compile or when they did compile
they did not run properly.

In short the functionality required for COBOL 85 conformity failed.


> With your last modifications, now I must specify the line 
> and position before other display options and I have to
> specify the line before the position.

First of all, the DISPLAY/ACCEPT line/position clauses are not part of the
COBOL 85 standard specifications.

Yes they are a nice feature to have, and a preferred method of programming
style by some users. 

In any case I modeled the DISPLAY/ACCEPT line/position clauses on an old MF
manual I have. It has the following grammar.

DISPLAY/ACCEPT var... [[line position] [options]]

While the line/position must be first, the options can be in any sequence. 

All these features have added substantial complexity to the DISPLAY/ACCEPT
statements, and to what the parser will need to handle. 

Reversing the [line position] clause to accept [position line] should not
be difficult, however I think the full functionality you seek will be
difficult to achieve without creating reduce/reduce conflicts, and not
requiring the curses library for a simple DISPLAY/ACCEPT statement. 

In my view, the above grammar is reasonable compromise, given the
limitations of the parser.

However, if some one else can do better, he or she is more than welcomed to
try.




David Essex

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

[Stephen B. <st...@cf...>]

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

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

[Tiny-cobol-users] cancel statement

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

A implementation of the cancel statement and a restore for values when
returnong from a called program is implemented.

Information of each run element is kept. When a program calls a routine,
and returns all the configuration  values of the run element are
restored in the runtime.

When cancelling a program, all the files opened by the program are
closed.

Now we need to restore all the veriables of the routine to its initial
values. Any ideas of how do this ?

[Tiny-cobol-users] NUMVAL intrinsic functions

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

The NUMVAL intrinsic function is now implemented. Now the only intrinsic
function left (for the Cobol 85 standard ) is the NUMVAL-C.

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

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

On dg, 2002-06-16 at 08:52, David Essex wrote:
> Ferran Pegueroles wrote:
> > 
> > Rildo Pragana wrote:
> >  ...
> > > Please, who made that changes in our parser, remove that
> > > screen_io_enable++ statements where appropriate.
> > ...
> > This is my fault, I missed something on my last changes. I will commit
> > the solution today.
> 
> Following some changes to the grammar, the DISPLAY/ACCEPT are working
> again as expected. 
> 

Which were those problems ? With your last modifications, now I must
specify the line and position before other display options and I have to
specify the line before the position.


> 
> David Essex
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Tin...@li...
> https://lists.sourceforge.net/lists/listinfo/tiny-cobol-users

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

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

Ferran Pegueroles wrote:
> 
> Rildo Pragana wrote:
>  ...
> > Please, who made that changes in our parser, remove that
> > screen_io_enable++ statements where appropriate.
> ...
> This is my fault, I missed something on my last changes. I will commit
> the solution today.

Following some changes to the grammar, the DISPLAY/ACCEPT are working
again as expected. 


David Essex

[Tiny-cobol-users] 33 digit intermediate variables (was: open-cobol-0.9.6)

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

David Essex a écrit :
> ...
> > 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.

Tim Josling wrote:
 
> David Essex wrote:
>
> > 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.

Bernard Giroud wrote:
>  
> What about the routines used in CobolforGCC? Are they good enough?

I do not know what the status of this is.

None the less, I think this is a solution that TC should consider.


David Essex

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

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

Rildo Pragana wrote:
 
> On Fri, 14 Jun 2002, David Essex 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 understand why there are _two_ versions of the same NIST
> test suite. Do you mean the perl scripts? Or there is something
> changed at the NIST's cobol source (that would void the test!).

There is only one version of the NIST COBOL test suite.

However it requires scripts to extract, run the tests and create reports
on the tests.

Originally these scripts were added to the TC distribution, so any one
could run the NIST tests.

Then OC then created their own scripts which basically do the same
thing..



David Essex

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

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

Rildo Pragana wrote:
 
> On Fri, 14 Jun 2002, David Essex 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 understand why there are _two_ versions of the same NIST
> test suite. Do you mean the perl scripts? Or there is something
> changed at the NIST's cobol source (that would void the test!).

There is only one version of the NIST COBOL test suite.

However it requires scripts to extract, run the tests and create reports
on the tests.

Originally these scripts were added to the TC distribution, so any one
could run the NIST tests.

Then OC then created their own scripts which basically do the same
thing..



David Essex

[Tiny-cobol-users] Re: NIST Test Suite

[David E. <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). 

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

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

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

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

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

[Bernard G. <bg...@fr...>]

David Essex a écrit :

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

What about the routines used in CobolforGCC? Are they good enough?

>
> David Essex
>
> _______________________________________________________________
>
> 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

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

[Bernard G. <bg...@fr...>]

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

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

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

Hi David,

On Fri, 14 Jun 2002, David Essex wrote:

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

In my opinion, the compiler should generate calls for more than
one alternative, checked and decided at compile time. If the 
calculations don't require large precision, we do it with integers 
and scaling. Otherwise, we may have a multiple-precision library 
for the (seldom found) large precision calculation.

To implement in a hurry, even GMP is a good candidate. Suppose a
cobol program with only 18 or less digits used for calculations. 
In that case, no gmp library call would be generated. Only in
those more stringent cases, that request for large precision
numbers (decided from the PIC clauses), gmp library would be
linked in.

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

This is the easy way...

> 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 understand why there are _two_ versions of the same NIST
test suite. Do you mean the perl scripts? Or there is something
changed at the NIST's cobol source (that would void the test!).

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-list] COBOL utilities project (was: open-cobol-0.9.6)

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

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

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

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

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

[Tiny-cobol-users] NIST Test Suite

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

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