Index and subscript in Arrays

ankita.maheswari11 · New User Joined: 20 Aug 2011 Posts: 10 Location: India

In which scenarios do we use Index and in which scenarios do we use subscript. Can you please help me with the scenarios?

I know only one: We use Index when we need a faster access to data.

vj.kbay · New User Joined: 03 Apr 2010 Posts: 5 Location: India

This should help,

ibmmainframes.com/viewtopic.php?t=6746&highlight=subscripts%5B/url%5D

ankita.maheswari11 · New User Joined: 20 Aug 2011 Posts: 10 Location: India

That is ok... i myself have seen that, but i wanted to know in case of some real life example, i mean any business requirement anyone would have see. To be precise a business example for the significance of using a subscript or an index.

vj.kbay · New User Joined: 03 Apr 2010 Posts: 5 Location: India

As per my exposure, I have mostly seen subscripts being used. But, there are a couple of instances I remember where index has been used. Eg.:

a. There is a table of 10 occurences. Design is such that table content will never exceed 9 occurences. I need to replace the contents of the table with a new set of values based on certain condition. I store these new values in the tenth occurence. Then I PERFORM VARYING from 1 THRU 9 and compare the WS-TBL(X-WST) with WS-TBL(10) for the given condition. Note, that this can be achieved thru a set of WS variables too. No need for a 10th occurence. But, I have seen this being done.

b. A table stores demographic details for the primary & secondary account holders. It has only 2 occurences. An indicator on the file tells whether a secondary owner exists or not. Now,

IF ONLY PRIMARY
MOVE ADDR-LINE (1) TO REPORT-LINE-1
MOVE SPACES TO REPORT-LINE-2
ELSE
MOVE ADDR-LINE (1) TO REPORT-LINE-1
MOVE ADDR-LINE (2) TO REPORT-LINE-2
END-IF
I'm not saying that this is the right way of doing it. But, I have seen this happening.

Bill Woodger · Posted: Sat Aug 20, 2011 4:36 pm

Generally your local site standards will dictate whether you use subcripts or indexes.

Indexes are generally considered more difficult to understand, so many sites say "subscripts only".

To my mind it is not a good idea to mix them in the same program or system.

There is no business requirement which would dictate one or the other. If your site uses indexes, you should exclusively use indexes. If your site uses subscripts, you should exclusively use subscripts.

It is a good idea to be thoroughly familiar with both. Hit the manuals (link at the top of the page) and try some simple examples. Hit the manuals again, go back to more advanced examples.

dbzTHEdinosauer · Posted: Sat Aug 20, 2011 4:42 pm

Arrays in COBOL are DB2 Host Variables.

otherwise,

you have COBOL Internal Tables.

If one wants to use the SEARCH or SEARCH ALL statements,
the COBOL Internal Table has to be defined with the INDEXED BY ...
phrase
and reference the indexes.

use is based on if you are a lazy coder or are interested in resource usage.

as far as compiler generated code:

Literal subscripts generate the least amount of code, thus are most effecient.

next are indexes:
when used in conjunction with

SET UP BY
SET DOWN BY
VARYING FROM .. TO .. BY
SET TO index
SET TO Literal

generates the least amount of code.

when used in conjunction with SET TO variable generates a little more

last are SUBSCRIPTs which generate the most amount of code.

Literal SUBSCRIPTs and INDEXes (after a SET) contain the offset within the table.

variables used as SUBSCRIPTs, contain an occurance (item) number,
so when referenced, the compiler generates code to convert the occurance to an offset.

All the above information is contained in the Application Programmers Guide, links to the appropiate COBOL version are at the top of every page - MANUALS.

You can also create a small test program using all the methodologies
for referring to an item within a COBOL Internal Table
and then look at the assembler code generated for you Statements.

ankita.maheswari11 · New User Joined: 20 Aug 2011 Posts: 10 Location: India

Thanks to all for sharing the knowledge, i'll try some examples as suggested.

Bill Woodger · Posted: Sat Aug 20, 2011 5:22 pm

I'm not sure that the topic chosen from 2005 was the best to clarify things.

If you use subscripts, always define them as binary, with either 4 or 8 digits (depending on the size of the table).

USAGE IS INDEX to my mind is for preserving a value of an index, not for use as an index.

Whichever you use - make the datanames meaningful. None of this INX-A, SUB1 rubbish.

If you stick to short names you'll make problems for yourself and others, you'll use the wrong subscript/index, which will be much less easy to do with meaningful names.

Phrzby Phil · Posted: Sat Aug 20, 2011 6:06 pm

How could a "business" requirement dictate indexes vs. subscripts?

Bill Woodger · Posted: Sat Aug 20, 2011 6:26 pm

dbz makes a good point about the SEARCH/SEARCH ALL.

If you use subscripts, you have to code your own equivalents of these. Which then means you are coding something which the compiler could do for you, and which the compiler gets right every time.

On the other hand, having to code them yourself is not intrinsically a bad thing. Makes you think about the data (or it should) rather than lazily using SEARCH... :-)

Because indexes/subscripts will often be used for searching, in one way or another, here's a little tip. This tip can be applied to files/databases as well, but think about things if there can be updates (online/db).

On any sort of "looking-for-it" task, consider checking your current key against the previous key, and using the previous value (including not-found) before bothering with the "looking-for-it" part.

On large files with widely-spread "hits", probably not worth it. On small files or with "grouped" "hits", this will save a lot of "looking-for-it" processing. Know your data.

If you code your own "binary chop" (in place of SEARCH ALL) you can get a jump-start on finding your key in the table, by relying on the previous key value and the location it was found/not found. How far you want to take that, depends on your data. Know your data.

If you have a large file with a majority of "hits" on a small number of keys, consider a serial search (your own or plain SEARCH) on a table that you have previously sequenced on frequency of "hits" (say from the previous run). Whether it is worth doing this, depends on your file sizes and knowing about the frequency of "hits". Know your data.

I really don't care which of Indexes or Subscripts anyone uses. Whichever, use it properly, don't confuse it with the other, don't mix their use, give them meaningful names. Usually you will be presented with a fait acompli due to local standards anyway (in my experience, always).

It is much more important to know your data, know how to represent business functionality as tables, know how to use specific techniques for particular requirements, make your code understandable and easily maintainable.

Enough from me for now, unless anything is unclear.