using Index other than subscript

This is a Mainframe COBOL forum - you can post your queries on Mainframe COBOL, VS COBOL II, COBOL/370 , Enterprise COBOL

Moderators: dbzTHEdinosauer, Moderator Group

Post Reply
venkatreddy.com
Member
Posts: 3
Joined: Sat Nov 24, 2007 11:21 am

using Index other than subscript

Post by venkatreddy.com » Sat Nov 24, 2007 2:20 pm

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

Shivankoo
Member
Posts: 14
Joined: Mon Dec 13, 2010 4:15 pm

Post by Shivankoo » Sat Sep 29, 2012 8:35 am

Did you find your answer?
Thanks and Regards
Shivankoo Sharma

//EMPIRE EXEC PGM=WIFE
//SYSIN DD DSN=VARSHA.ME.HOME,DISP=SHR
//SYSOUT DD DUMMY

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Sat Sep 29, 2012 12:58 pm

After four years and 11 months (or so) I think they are no longer waiting on "tenter hooks" :-)

I'd go for

Code: Select all

SET index-name TO +1
Can't do that with a subscript. Probably not the answer the TS wanted.

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Sun Dec 30, 2012 8:21 am

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.
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Sun Dec 30, 2012 3:05 pm

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)?

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Tue Jan 01, 2013 12:00 am

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
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

DikDude
Moderator
Posts: 1001
Joined: Fri Jul 22, 2011 8:39 am
Location: usa

Post by DikDude » Tue Jan 01, 2013 1:18 am

Hi Chuck,

WC has done as you suggest multiple times over. . .

I believe there is some picking of nits going on 8)

d

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Tue Jan 01, 2013 5:15 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?

chaat
Member
Posts: 19
Joined: Sun Apr 18, 2010 11:51 pm
Location: St. Cloud, Minnesota, USA

Post by chaat » Tue Jan 01, 2013 1:13 pm

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
Chuck Haatvedt

email --> clastnameatcharterdotnet

(replace lastname, at, dot with appropriate
characters)

William Collins
Active Member
Posts: 732
Joined: Thu May 24, 2012 4:07 am

Post by William Collins » Tue Jan 01, 2013 1:31 pm

Leaving the other stuff for now then, we at least have a quantity for "MUCH". The 40% that you quote. With the halfword subscripts not "much" slower indexes?

academyindia4

Topic deleted by Admin

Post by academyindia4 » Fri Jan 15, 2016 8:55 pm

<< Content deleted By Admin >>

lnpdavid
Member
Posts: 11
Joined: Tue Apr 28, 2009 8:48 pm
Location: Missouri USA

Post by lnpdavid » Fri Jan 22, 2016 9:54 pm

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.
David Earhart

academyindia4

Topic deleted by Admin

Post by academyindia4 » Sun Jan 24, 2016 12:05 am

<< Content deleted By Admin >>

Post Reply

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



Other References
Mainframe Tools and others