IBM Mainframe Forum

Hi,

There is a SOC7 abend while running the COBOL code pasted below.

01 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000


Existing code:
=============

PERFORM
WITH TEST AFTER
VARYING TRS-INDX FROM 1 BY 1
UNTIL TRS-FOUND
OR TRS-INDX = +5000

Changed code (SOC7 ABEND ENCOUNTERED):
======================================

PERFORM
WITH TEST AFTER
VARYING TRS-INDX FROM 1 BY 1
UNTIL TRS-FOUND
TRS-INDX = TRS-TRANS-MAX-COUNT

The problem identified after analysing the compile listing is higlighted.

Is it becasue the variable TRS-TRANS-MAX-COUNT has been defined as a PIC S9(05).
Should it be a COMP variable?

Could someone help me clear this doubt?

Thanks,
David

You did not tell us how TRS-INDX is defined, so there's no way we can answer for sure.

Changing TRS-TRANS-MAX-COUNT to COMP probably won't change the abend.

You did not tell us how TRS-INDX is defined, so there's no way we can answer for sure.

Nope, he/she did give the variable definition (although in cyan....) : 01 TRS-TRANS-MAX-COUNT PIC S9(05) VALUE +10000

Defining a variable you're going to use for subscripting as COMP (or COMP-5 or BINARY) is always a good idea, because it will speed up your code. Defining it as "DISPLAY" implies that the variable has got to be converted to packed first and then to binary (unless IBM introduced a direct conversion from zoned to binary in assembler). However, this is not the cause of your S0C7.

IF (and only IF)
a) the new variable is defined AFTER the array
b) the code you're performing is moving stuff into the array
then my guess is that you've "blown" past the array boundary and overwritten your TRS-TRANS-MAX-COUNT with something that is not a zoned number.
(Note that WITH TEST AFTER your code may be executed 10001 times....)

With "test after" you'll also go through the loop when you have zero items. If you want "test after" I'd say you should have the latest state of whatever you have in the test as the last thing in the perform itself, otherwise it makes no sense (to me).

If you are using indexes, make yourself thoroughly aware of their use from the manuals, including storing and comparing them.

djprakash1ml wrote:

Select all

PERFORM
WITH TEST AFTER
VARYING TRS-INDX FROM 1 BY 1
UNTIL TRS-FOUND
TRS-INDX = TRS-TRANS-MAX-COUNT

Firstly, I'll assume you just missed out the "OR" when putting it on the forum.

If you are looking up something in a table (TRS-FOUND seems to say you are) and the table has up to 5000 or 10000 items, then your run times per record could be pretty poor (depending on your data). Best to sequence the table. Then either use SEARCH (look it up and understand it thoroughly if you don't know it) which will do a "binary chop" to find/not find an item in the table or, if you want to stick with your serial search, stop the search and set for not found when the "key" you are looking for is higher than the "key" in the table.

Zio69 wrote:(Note that WITH TEST AFTER your code may be executed 10001 times....)

I don't see that. Increment to 10000 at the start of the loop, but the test at the end of the loop is for equal, so will stop on the 10,000th.

In the original working version the loop limit was set to 5000. In the new version, the constant value of TRS-TRANS-MAX-COUNT is 10000. You did make the actual array bigger as well, right? Perhaps the simplest thing to do is to look at the dump, which will give you the information you need about exactly which field has the bad data in it, and the point in the program where it is failing?

I'd echo BillyBoyo's observations about the expected performance when doing a serial search of such a large array. You can expect to search on average half the array on any lookup. Beefing it up from 5000 to 10000 looks like a knee-jerk reaction to reaching the 5000 limit one day and wondering what to do next. If you really want to speed this thing up rather than just bodging it up so it works, I would suggest the following:

1. Define the array with OCCURS DEPENDING ON TRS-TRANS-MAX-COUNT and INDEXED BY, so when you only have 5002 entries, you don't search the whole thing
2. Sort the data you use to populate the lookup array into ascending key sequence (preferably with DFSORT in the previous step)
3. Read it into the array, incrementing TRS-TRANS-MAX-COUNT as you go, so you know the size of the array
4. Once the array is loaded, use SEARCH ALL to do a binary search. Instead of searching half the array on every lookup, it will examine a maximum of 14 entries on each lookup for a table with 10000 entries.

Also, from a style perspective, I treat any code that needs WITH TEST AFTER with the same degree of suspicion as anything that uses GO TO, but that is just a personal preference...

Hello,

Once you decide which way you will do the table lookup(personally, i prefer loading a large array in sequence and then using SEARCH ALL), i suggest one more bit of code:

When it is time to do the lookup, compare if the value about to be used is the same as the previous lookup. If it is the same, there should be no need to actually do the lookup again. Depending on the data content, this may save a little or very much processing.

Good call, Dick. A little bit of laziness in the lookup could go a long way in some instances, for very little extra cost.

I don't see that. Increment to 10000 at the start of the loop, but the test at the end of the loop is for equal, so will stop on the 10,000th.

You're right.... when I was a kid my older colleagues thaught me never to code those kind of loops testing for EQUAL but to test for GREATER (at those times there wasn't the TEST AFTER option), so I (wrongly) assumed the original code was for GREATER, ignoring the fact it wasn't..... habits are hard to give up!

I guess I can only agree with stevexff (high-value??)..... that's what I do in my everyday routine and what I try to teach to other folks in shop. Those are the little things that make a huge difference at execution time. (and BTW although I've used WITH TEST AFTER a couple of times myself, usually that isn't necessary)

Although I'm a little worried we might have lost djprakash1ml somewhere along the way, I think this thread is a good example of how difficult it often is to answer questions from very limited information. djprakash1ml wan't even asking about potential performance problems, but it was there to be seen, so we kind of had to say something about it.

Steve's look-up with Dick's check-for-same-as-last is an excellent general-purpose solution (remember Dick's suggestion also when doing file look-ups).

If you are not able to use SEARCH ALL (some site "ban" the use of INDEXes), then you can implement the binary-chop yourself. If you do this, extend Dick's suggestion a little. Having excluded those that are equal to the previous search, start you binary search relative to the previous search (if you current key is less than previous, calculate half the value of zero to number of previous entry, otherwise, half the value of total number of entries minue previous entry).

But, to know whether a general-purpose solution is best (most of the time it will be) you have to know your own data. How many times are you going to be doing the look-up (million records on the input file, maybe look for the optimal solution (which may be the same as the general-purpose anyway, but look).

For instance, if 95% of the data is covered by a handfull of codes, a sequential search on a table ordered by frequency of occurence will be best for a table search.

Of course, if you could sort your input file on the match key (and remembering Dick's suggestion) then you'll do a maxium of one search (so, average 7 attempts on the SEARCH ALL) for each code, for the whole file.

If you have time, djprakash1ml, you might be able to play with some different solutions and get a "feel" for some of the situations you'll meet in the future.