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

[David Essex]

Robert Moenck wrote:

> This conversation seems to have tailed off so I
> thought I would give it another stir.
>
> I took a look at CSORT and a further look at the GNU sort.
> My feeling is that the GNU sort is a much better platform
> to build out from.
> It contains a lot of very useful infrastructure,
> e.g. code for memory buffer management, process management,
> intermediate sort file management, an efficient sort algorithm,
> sort, merge or check capability, etc.
>
> Agreed, it is targeted at LF(CR) delimited variable length records,
> but that corresponds to LINE SEQUENTIAL in the Open-Cobol environment.
> I think it would be straight forward to enhance it to support
> Open-Cobol SEQUENTIAL (i.e. records prefixed with record length
> in binary)or RELATIVE files.
>
> Agreed, it is designed for variable length records and delimited
> keys,but that is a more difficult problem than fixed offset fixed
> size keys.
> UN*X sort has to scan through each record looking for the keys.
> Again I think it would be straight forward to enhance it to support
> fixed offset fixed sized keys for the Open Cobol data types.

Well, the question is, is it worth it ?
I think that removing the redundant code, and re-working the rest is
more work in the long run.

Currently, I do not have any free time to dedicate to this project.
So, other than the SORT syntax, I have no plans to contribute to this
project.


> ...
> I am still leaning towards Open Cobol's "-std=<dialect>"
> mechanism to specify different forms of sort parameters.
> I don't know much about IP issues, but Open Cobol seems
> to get away with this approach.
> One of the <dialect>s could be 'unix' to continue with
> the existing capabilities.

Dealing with IP issues tends to be VERY expensive.
In my view, the best approach is to avoid IP issues as much as possible.


> You say you have a YACC grammar for SORT syntax.
> If you want to post it somewhere that I can pick up,
> then I will take a look at how much can be easily implemented.

Yes, I have a working proto-type for the SORT syntax, and only the syntax.

It requires BtYacc (a) to work with the following syntax, but there may
be a YACC(1) (byacc/bison) work-around.

SORT FIELDS=(1,2,CH,A,59,4,CH,D)
MERGE FIELDS=(1,2,A,59,4,D),FORMAT=CH
and
SUM FIELDS=(1,2,PD,59,4,BI,5,2,ZD)
SUM FIELDS=(1,2,59,4,5,2),FORMAT=BI

Since I have no where to post the source code, I will e-mail a copy to
any one, upon request.

A full implementation of the grammar, would require the following.
- SORT/MERGE - field compare
- SUM - field conversion and sum
- INPUT record reformat
- OUTPUT record reformat

BTW, a while back, I have sent a copy of the SORT grammar to Roger 
While, but to date have received no reply.
Roger may (or NOT) have an improved version.


Cheers,

a) BtYacc: Back-Tracking Yacc
Use C (not C++) version (2.1 I think).
http://www.siber.com/btyacc/