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.
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
MOVE ADDR-LINE (1) TO REPORT-LINE-1
MOVE ADDR-LINE (2) TO REPORT-LINE-2
I'm not saying that this is the right way of doing it. But, I have seen this happening.
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.
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.