MVSFORUMS.com

Glenn · Beginner Joined: 23 Mar 2003 Posts: 56 Topics: 3

I'm writing this to try and describe one of the problems I have with how index handling is done in COBOL...the indexes and the subscripts aren't very interchangable...

The indexes are only good IMO really for sequential movement through a table. Anything beyond that almost requires subscripts, unless you write some code that handles the index changes (find address for first element, add size of element to get address of second element and so on).

To wit, index processing falls flat when you have code that is dependent on something OTHER than sequential movement through a table. Examples are the coded binary search (SEARCH ALL handles with an index just fine, why do you have to be "clever" to manipulate the index otherwise?), and that quicksort in the other thread.

Maybe I'm just unsure of the best way to handle these situations using the index processing afforded COBOL. But I've tried a lot too and don't see a way of doing things other than copying indexes back and forth as you manipulate them (indexes defined with tables are tied to those tables so you can't directly manipulate them unless you use the set statements or the compiler complains with a severe error) or maintaining a subscript along with the index (which I've done a few times in programs where simple testing occurs against the actual subscripted address of the table).

So how does everybody else handle these cases? Do the index/address cludge? Or is there some other more elegant way that I'm not aware of?

Like for example, is there a real elegant way to do this one (at least the basic idea of the code being dependent on the subscripted address?) Do we duplicate the processing and handle the index as well as the subscript?:

Bithead · Posted: Wed May 21, 2003 1:27 pm Post subject:

Indexes are offsets based on the element length wheras subscripts are based on occurrences. Indexes are very much more efficient for sequential type processing.

Glenn · Beginner Joined: 23 Mar 2003 Posts: 56 Topics: 3

I understand the difference between a subscript and an index. I'm just basically ranting on the difference showing up in COBOL and not in another language, and the difficulty in most situations of coding tables to use indexed access. The table indexes I've found are hard to carry across on production programs - as you said the indexes are best for sequential processing of tables, but I find in lots of programs sequential processing doesn't happen with tables.

Bithead · Posted: Wed May 21, 2003 1:58 pm Post subject:

Glenn,

I don't think that there indexes or subscripts in assembler - these get converted to offsets by the compiler. The languages that I have dealt with other than COBOL have tended to be slower when handling large tables. I guess that the COBOL developers needed to add some more efficient code so they added indexes and binary searches. I tend not to use indexes on smaller tables but I have seen some major performance improvements by adding them to large ones. Many of the programs in our shop are processed in a sequentail manner so it must depend on the type of business.

If you are hitting performance problems with your table handling routines, you may want to convert your subscript variables to COMP-3 otherwise the generated assembler code has to do this for you every time you use them.

R.Nickel · Posted: Wed May 21, 2003 11:16 pm Post subject:

Subscripts MUST be comp/binary - otherwise they will converted to binary.
Indexes are used to access arrays SEQUENTIALLY in a defined sequence by 1,2 etc either forward or backward.
The compiler will convert subscripts to index values at execution time.
Table size IS NOT relevant in deciding wether to use an index or subscript, the usage is, index for sequential processing subscript for 'random' lookups.
You can use an index AND a subscript for one array
_________________
Rainer