using Index other than subscript
Moderators: dbzTHEdinosauer, Moderator Group
-
- Member
- Posts: 3
- Joined: Sat Nov 24, 2007 11:21 am
using Index other than subscript
Hi All,
while handling Arrays/tables in cobol, we can either use subscript or Index. more over we can do Search or search ALL(which needs index) using subscript too using perform verbs. but will you please tell me that something for which we have to use Index and cannot be done using subscript. ( not relating to any performance issues)
thanks,
Venkat
while handling Arrays/tables in cobol, we can either use subscript or Index. more over we can do Search or search ALL(which needs index) using subscript too using perform verbs. but will you please tell me that something for which we have to use Index and cannot be done using subscript. ( not relating to any performance issues)
thanks,
Venkat
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
After four years and 11 months (or so) I think they are no longer waiting on "tenter hooks"
I'd go for
Can't do that with a subscript. Probably not the answer the TS wanted.
I'd go for
Code: Select all
SET index-name TO +1
Venkatreddy,
I believe that the SEARCH ALL verb requires the use of an INDEX on the array to be searched.
Also indexes are MUCH more efficient than subscripts in all but some very limited situations dealing with arrays with only single byte entries.
Chuck H.
I believe that the SEARCH ALL verb requires the use of an INDEX on the array to be searched.
Also indexes are MUCH more efficient than subscripts in all but some very limited situations dealing with arrays with only single byte entries.
Chuck H.
Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
Venkatreddy point that out about the index for SEARCH ALL.
Define "MUCH", this is computing, after all. Only with single bytes? Can you show that?
I have a 9,999 entry table (which is what I assume you mean by "array"). Each entry in the table is 30 bytes long, accessed as three separate fields. Which do you determine would be "more efficient" to access this, an index or a subscript defined as COMP PIC 9(4)/S9(4)?
Define "MUCH", this is computing, after all. Only with single bytes? Can you show that?
I have a 9,999 entry table (which is what I assume you mean by "array"). Each entry in the table is 30 bytes long, accessed as three separate fields. Which do you determine would be "more efficient" to access this, an index or a subscript defined as COMP PIC 9(4)/S9(4)?
William,
on an IBM Mainframe system using the Enterprise COBOL V4.2 compiler, the use of an index will generate more efficient code.
it should be pretty easy to create two small programs which each loop thru the array a million times and then compare the cpu time of the two.
see this manual...
http://www-01.ibm.com/support/docview.w ... wg27018287
look at page 36
on an IBM Mainframe system using the Enterprise COBOL V4.2 compiler, the use of an index will generate more efficient code.
it should be pretty easy to create two small programs which each loop thru the array a million times and then compare the cpu time of the two.
see this manual...
http://www-01.ibm.com/support/docview.w ... wg27018287
look at page 36
Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
It may be nits
But still, how "MUCH" is "MUCH"? The quote you give, shorn of its specific context, just says "more efficient". It's context, which I know without having to look, is of PIC S9(8) binary, plus packed-decimal, plus DISPLAY.
What about the "single bytes"?
And the other specific question? I was wondering about your answer, Chuck - how "much"? Now we can access the entire table with a binary halfword. Three instructions for the subscript, two for the index, but the subscript is halfword, the index always fullword. You still going for "MUCH" faster?
But still, how "MUCH" is "MUCH"? The quote you give, shorn of its specific context, just says "more efficient". It's context, which I know without having to look, is of PIC S9(8) binary, plus packed-decimal, plus DISPLAY.
What about the "single bytes"?
And the other specific question? I was wondering about your answer, Chuck - how "much"? Now we can access the entire table with a binary halfword. Three instructions for the subscript, two for the index, but the subscript is halfword, the index always fullword. You still going for "MUCH" faster?
from the Enterprise COBOL performance manual i quoted above. One of the factors which affect these results is how many times subscripted / indexed items are referenced in the code. The more references, the greater the savings. Also muliple dimensioned arrays will also show a greater savings.
ps.. the rationale behind the array with entries which are only 1 byte long is that when the compiler is calculating the displacement, it doesn't have to multiply the subscript times the entry length so effectively it functions very similar to an index.
Indexes vs Subscripts
Using indexes to address a table is more efficient than using subscripts since the index already contains the
displacement from the start of the table and does not have to be calculated at run time. Indexes are defined
using the INDEXED BY phrase of the OCCURS clause for the data item. Subscripts, on the other hand,
contain an occurrence number that must be converted to a displacement value at run time before it can be
used. When using subscripts to address a table, use a binary (COMP) signed data item with eight or fewer
digits (for example, using PICTURE S9(8) COMP for the data item). This will allow fullword arithmetic to
be used during the calculations. Additionally, in some cases, using four or fewer digits for the data item may
also offer some added reduction in CPU time since halfword arithmetic can be used.
Performance considerations for indexes vs subscripts (PIC S9(8)):
|
Using binary data items (COMP) to address a table is 40% slower than using indexes
|
Using packed decimal data items (COMP-3) to address a table is 220% slower than using indexes
|
Using DISPLAY data items to address a table is 300% slower than using indexes
ps.. the rationale behind the array with entries which are only 1 byte long is that when the compiler is calculating the displacement, it doesn't have to multiply the subscript times the entry length so effectively it functions very similar to an index.
Indexes vs Subscripts
Using indexes to address a table is more efficient than using subscripts since the index already contains the
displacement from the start of the table and does not have to be calculated at run time. Indexes are defined
using the INDEXED BY phrase of the OCCURS clause for the data item. Subscripts, on the other hand,
contain an occurrence number that must be converted to a displacement value at run time before it can be
used. When using subscripts to address a table, use a binary (COMP) signed data item with eight or fewer
digits (for example, using PICTURE S9(8) COMP for the data item). This will allow fullword arithmetic to
be used during the calculations. Additionally, in some cases, using four or fewer digits for the data item may
also offer some added reduction in CPU time since halfword arithmetic can be used.
Performance considerations for indexes vs subscripts (PIC S9(8)):
|
Using binary data items (COMP) to address a table is 40% slower than using indexes
|
Using packed decimal data items (COMP-3) to address a table is 220% slower than using indexes
|
Using DISPLAY data items to address a table is 300% slower than using indexes
Chuck Haatvedt
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
email --> clastnameatcharterdotnet
(replace lastname, at, dot with appropriate
characters)
-
- Active Member
- Posts: 732
- Joined: Thu May 24, 2012 4:07 am
Let me add to the "much" answer.
If you have a table that is indexed and the key to the table is in sequence you will be able to do a SEARCH ALL on the table. Assume, for that the table contains 1,000,000 entries. (yes, that might unreasonable, but go with it for a minute) Doing a SEARCH ALL on the table will only look at 20 entries to determine if what you're looking up in the table is there or not. You've only coded one verb (the SEARCH).
If you're using subscripting you'll have to code your own routine to do the same binary search, with the possibility of making coding mistakes.
If you just do a sequential search on the same table you'll have to do an average of 500,000 comparisons to find, or not find, what you're looking for. Let's see 20 vs 500,000??? I'd say that would be MUCH faster.
If you have a table that is indexed and the key to the table is in sequence you will be able to do a SEARCH ALL on the table. Assume, for that the table contains 1,000,000 entries. (yes, that might unreasonable, but go with it for a minute) Doing a SEARCH ALL on the table will only look at 20 entries to determine if what you're looking up in the table is there or not. You've only coded one verb (the SEARCH).
If you're using subscripting you'll have to code your own routine to do the same binary search, with the possibility of making coding mistakes.
If you just do a sequential search on the same table you'll have to do an average of 500,000 comparisons to find, or not find, what you're looking for. Let's see 20 vs 500,000??? I'd say that would be MUCH faster.
David Earhart
FREE TUTORIALS
Tutorials
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts. - Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3. - DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming. - SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples - CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Interview
Mainframe Interview questions
- Cobol Interview Questions
50+ Interview Questions - JCL Interview Questions
50+ Interview Questions - DB2 Interview Questions
100+ Interview Questions - CICS Interview Questions
70+ Interview Questions - VSAM Interview Questions
27 Interview Questions
Other References
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program - FILEAID Reference
Explains how to browse , edit and delete datasets - Change Man Reference
Quick Start tutorial on Changeman - Abend Reference
Important Abend codes explained - FaceBook Page
MainframeGurukul FaceBook Page - LinkedIn Page
MainframeGurkul Linkedin Page