Let say we have INDEX defined for the above array.
Then I do SEARCH in the array for a given WS-NUM , say I got the succesful match for some INDEX value. But after coming out of COBOL SEARCH verb, I want to know the corresponding subscript , where the SEARCH has been succesfull. (Really, I went to use INDEX only because SEARCH cannot use subscript!.)
After doing SEARCH I want to know the subscript of the 'Matched array element' so that in subsequent portion of program I can use this subscript for PERFORMS etc, with out bothering about INDEX.
Joined: 02 Dec 2002 Posts: 2 Topics: 1 Location: UK
Posted: Tue Feb 25, 2003 6:26 am Post subject:
I am indeed using INDEX as you mentioned. But after that I
want to get the corresponding susbscript. Because, we are
doing hell a lot of processing to call another program, some
TSQ processing etc etc. For all these I would prefer to use
the subscript corresponding to the INDEX where my Search
was succesfull! (though I can use INDEX I dont want!)
In otherwords, I think I am looking for a formula to relate
INDEX and SUBSCRIPT for a given array which can be
expressed probably as function of 'n' - where 'n' is the bytes
in each array instance. So mathematically I need
s = f(i,n)
Where
s- subscript,
i - index from search,
n- size of a single array instance. Question is what is 'f'?
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Tue Feb 25, 2003 6:59 am Post subject:
SRAMAN,
Index represent displacement value of the table entry from the beginning of the table, subscript - occurrence # of the table entry.
For example if you have a list of month names each occupying 9 bytes, then the value of a subscript for the month of FEB would be 2, but the index would be 9. A formula to calculate index value when the occurrance and item length are known is:
Usually on a set statement, the memory displacement value represented by index is converted into the subscript appropriate for the table in question.
However, keep in mind INDEX is always more efficient than subscript if you have a situation where accessing the tables don't require the conversion each time anyway for some reason....
One of my annoyances with COBOL is how inflexible indexes really are in the natural logic - you really have to manipulate the index at the memory level, like for a calculated subscript...
Kolusu illustrated the basic idea, but I'll go into it a little more deeper and specifically...
You have to start with the memory displacement that the table is at in memory. This is essentially done by assigning a pointer to the address of the whole table. This corresponds to the location of the first element. So if we use a little algebra:
Code:
L(1) = D
where L = location of element
and D = memory displacement of the table
We have to remember that memory is all linear in memory, and the table is stored in continguous bytes in memory, so we can continually add the size of the memory block, as Kolusu explains... to extend it out and create a formula...
Code:
L(1) = D + S * 0
L(2) = D + S * 1
L(3) = D + S * 2...
So
L(x) = D + S(x-1)...
where L = location of element
and D = memory displacement of the table
and S = size of the table element
and x = desired element of the table
Unfortunately with the vagaries of COBOL you have to define the pointer value and then redefine the pointer to S9(8) BINARY when you do this...unfortunately I've had very not good success with doing this to indexes defined with tables (think TABLE1 OCCURS 50 TIMES INDEXED BY TABLE1-NDX).
Didn't try to equate the indexes back and forth, when this came up I didn't try too hard - better to get the job done than get it completely efficient if you can deliver it within specs - so subscript ends up easier unless there's a case where it really is less efficient to do so. I remember a case I read about where a 24 hr (and still running) job was cut down to 3 hrs from converting subscript use to indexes...so it does matter at some point...
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
