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