Cobol - Table SORT and normal SORT

Author

Table SORT and normal SORT

Roger While

2007-10-24, 6:55 pm

"Howard Brazee" <howard@brazee.net> schrieb im Newsbeitrag
news:5hiph3pbncf0cd0ul75f2e6obtqd3kjkeh@
4ax.com...
> On Mon, 22 Oct 2007 09:08:50 -0500, "Judson McClendon"
> <judmc@sunvaley0.com> wrote:
>
>
> If the table is short enough (days of the w

), I don't even sort.
>
> But if I want a simple, efficient sort - I tend to look at comb sorts
> first.

For a table sort, OC does a qsort with expected parameters
whereas a SORT is done as a list/merge with appropiate params
(including COLLATING, and espexially EBCDIC for MF fans;-)).
Normal SORT's eg.
Feed in the ANSI85 line sequential file (size 28210031)
Feed out an equivalent line sequential file.
Do a SORT .. USING .. GIVING ...
Time it :-)

Roger

Howard Brazee

2007-10-24, 6:55 pm

On Wed, 24 Oct 2007 19:44:47 +0200, "Roger While" <simrw@sim-basis.de>
wrote:

>For a table sort, OC does a qsort with expected parameters
>whereas a SORT is done as a list/merge with appropiate params
>(including COLLATING, and espexially EBCDIC for MF fans;-)).
>Normal SORT's eg.
>Feed in the ANSI85 line sequential file (size 28210031)
>Feed out an equivalent line sequential file.
>Do a SORT .. USING .. GIVING ...
>Time it :-)

What is OC? My only options for a table sort are to code it myself
or let CoBOL call DFSORT to sort externally.

William M. Klein

2007-10-24, 6:55 pm

It may or may not be worth noting that the '02 Standard has some problems (i.e.
is INCONSISTENT) with its definition of how to specify a TABLE SORT when the
table to be sorted is not the "top" or only level of the table. MF implemented
the CCC JOD definition. (I wrote the original J4 proposal that added this to
the '02 Standard). J4 and WG4 then made some changes - allowing and/or
requiring the ALL subscript and other levels of subscripting.

There is currently a "work assignment" at J4 to figure out how to fix this.
Originally (when I was recently representing MF), I took on the assignment but
it is now unassigned.

I don't think that MOST programmers are very interested in sorting one instance
of a "sub-table" - but if you are and you want to do it in a "Standard" method
(or if you - like Roger - are working on a compiler) then I think you look at my
comment 9 in

http://www.cobolstandard.info/j4/files/06-0121.pdf

--
Bill Klein
wmklein <at> ix.netcom.com
"Roger While" <simrw@sim-basis.de> wrote in message
news:ffo2ju$krh$03$1@news.t-online.com...
> "Howard Brazee" <howard@brazee.net> schrieb im Newsbeitrag
> news:5hiph3pbncf0cd0ul75f2e6obtqd3kjkeh@
4ax.com...
>
> For a table sort, OC does a qsort with expected parameters
> whereas a SORT is done as a list/merge with appropiate params
> (including COLLATING, and espexially EBCDIC for MF fans;-)).
> Normal SORT's eg.
> Feed in the ANSI85 line sequential file (size 28210031)
> Feed out an equivalent line sequential file.
> Do a SORT .. USING .. GIVING ...
> Time it :-)
>
> Roger
>
>

Robert

2007-10-24, 9:55 pm

On Wed, 24 Oct 2007 20:45:18 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>It may or may not be worth noting that the '02 Standard has some problems (i.e.
>is INCONSISTENT) with its definition of how to specify a TABLE SORT when the
>table to be sorted is not the "top" or only level of the table. MF implemented
>the CCC JOD definition. (I wrote the original J4 proposal that added this to
>the '02 Standard). J4 and WG4 then made some changes - allowing and/or
>requiring the ALL subscript and other levels of subscripting.
>
>There is currently a "work assignment" at J4 to figure out how to fix this.
>Originally (when I was recently representing MF), I took on the assignment but
>it is now unassigned.
>
>I don't think that MOST programmers are very interested in sorting one instance
>of a "sub-table" - but if you are and you want to do it in a "Standard" method
>(or if you - like Roger - are working on a compiler) then I think you look at my
>comment 9 in
>
> http://www.cobolstandard.info/j4/files/06-0121.pdf

I don't like either of the proposed syntaxes. A SORT and SEARCH on a single level table
requires zero subscripts on the table name, one fewer than required on other references.
To be logically consistent, SORT and SEARCH on multi-level tables should also require one
subscript fewer.

01 group-item.
05 tabl1 occurs 10 indexed t1-ind
Ascending Key Key1.
10 Key1 Pic x(1).
10 tabl2 occurs 10 Indexed t2-Ind
Ascending Key Key2.
15 Key2 Pic X(1).
15 Tabl3 occurs 10 Indexed t3-Ind
Ascending Key Key3.
20 Key3 Pic X(1).
20 Store-Name Pic X(70).
....
Sort Tabl1
Search ALL Tabl1
When Key1 (T1-Ind) = '6'
Sort Tabl2 (T1-Ind -1)
Search ALL Tabl2 (T1-Ind -1)
When Key2 (T1-Ind -1, T2-Ind) = '6'
Sort Tabl3 (T1-Ind -1, T2-Ind -1)
Search ALL Tabl3 (T1-Ind -1, T2-Ind -1)
When Key3 (T1-Ind -1, T2-Ind -1, T3-Ind) = '6'
Display 'The median store is '
Key1 (T1-Ind -1)
Key2 (T1-Ind -1, T2-Ind -1)
Key3 (T1-Ind -1, T2-Ind -1, T3-Ind -1)
space
Store-Name (T1-Ind -1, T2-Ind -1, T3-Ind -1)
...

The proposals would have us write either no subscripts, giving the appearance we're not
specifying which sub-table, or use the word ALL for the last subscript. Since there is no
proposal to change the existing SEARCH to require (ALL), apparently either would be valid.
Moreover, two uses of the word ALL in a single SEARCH would appear equivocal to neophytes.

"Equivocation is the misleading use of a word with more than one meaning (by glossing over
which meaning is intended at a particular time). "

Sponsored Links