gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [open-cobol-list] Sort utility within OC


From: David Essex
Subject: Re: [open-cobol-list] Sort utility within OC
Date: Sat, 26 May 2007 16:30:53 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Roger While wrote:

> Can you throw over what you have please.
> Sure I will e-mail you a copy.
>
> Some thoughts -
> 1)
> I don't think we should clutter the command line.
>
> MF's mfsort has precisely 2 calling sequences :
> mfsort <instructions>
> and
> mfsort take <filename>
>
> ie. All input/output file(s) are in the instructions.

The SU I had envisioned was modeled on main-frame methods.
Thus the actual input/output file(s) names are defined externally.

This could be achieved by using predefined environment variables, and
command line overrides.
The command line interface would only consist of about 3 options.

In my view this approach would result in a cleaner SORT grammar.


> 2)
> We need to define a (preferably compatible) grammar
> for the instructions.
>
> 3)
> Given the above, we could take MF's syntax as a start point.

I have written a grammar which is based on main-frame SORT utilities.

Due to IP considerations, I do not think we should base the SORT grammar
on any specific vendor.

> 4)
> Note that mfsort does not offer conditional evaluation
> as Cris's examples.
> (I am not sure we would want to support this)

These SORT utilities became popular because of these EXTRA features,
such as omit-include conditionals.
In many cases, it is eisier and faster, to write a SORT script than to
write a COBOL (or other) program.

I don't think it is in the interest of any COBOL vendor, to create a
product which would duplicate features, and compete with the main product.

In my view, I think that omit-include conditionals are an important
feature to have in a SORT utility program.


> 5)
> Given the above, it should be possible to "flex" a grammar.
> We could then define a standard API for what the flexxer
> produces. This would be the specific hooks into the
> Cobol runtime of OC/TC.
> Dependant on how the flexxer works out, then David and I can
> agree on a common API.

Perhaps first we should agree on what this SORT utility should be able
to do.

I think it should perform the following tasks.

1)
Sort ASCII char-sets on descending/ascending fields,
with the ability to remove duplicates.
2)
Reformat input records (before sort).
Reformat output records (after sort).
3)
Sum numeric fields (packed, binary, zone decimals { EBCDIC binary ?})
4)
Some form of omit-include conditionals.


Cheers.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]