SEARCH comparison issue on OS/390

[cobp]

Hi guys,

I've got a problem with SEARCH ALL. But this problem is specific to OS/390. On VA COBOL compiler, I got correct result.

consider the following code,

SEARCH ALL VALID-VERB-TABLE
WHEN VERB-ENTRY (INDX) = VERB-WORD
MOVE TRUU TO VERB-FOUND-SW.

VERB-ENTRY IS LENGTH 10( X(10)) and VERB-WORD is of length 35.
When a table entry of length 10 say 'INITIALIZE' is encountered, this entry matches with VERB-WORD that contains INITIALIZE-XZYH. i.e., only 10 characters were used for the comparison.
This problem occurs only for SEARCH, IF gives correct comparison results.

Is there exists any solution or compiler option to get rid of this issue.

Regards,
cobp

 

[Crox]

Hi,

I am surprised about this. But you can always compare with VERB-WORD (1:35) to have a bypass.

Are you sure that it isn't a different sort sequence problem?

Regards,

Crox

 

[NinaToo]

I think that the spaces/low values which exist in the extra storage room in VERB-WORD is making the processing think that there is no match.

I would move VERB-WORD(1:10) to another variable, say VERB-WORD-10. Then code it thusly:

SEARCH ALL VALID-VERB-TABLE
WHEN VERB-ENTRY (INDX) = VERB-WORD-10
MOVE TRUU TO VERB-FOUND-SW.

This should get around this problem in any environment.

Hope this helps, Nina Too

 

[cobp]

Hi Crox, Nina,

Thanks for the reply.
I have compared with 1:35, but still it matches. Sort sequence is correct, it is strictly in sorted order. But as I mentioned earlier, this is only a problem with SEARCH. This problem won't occur for IF.

SEARCH ALL VALID-VERB-TABLE
WHEN VERB-ENTRY (INDX) = VERB-WORD
IF VERB-ENTRY (INDX) = VERB-WORD
MOVE TRUU TO VERB-FOUND-SW
ELSE
DISPLAY 'PROBLEM OCCURS WITH THIS WORD****'
END-IF.

From the above example, I got the match for this special casein WHEN condition but not in the IF condition and that implies that SEARCH compares only the field length of table entry.

Note that if VERB-ENTRY (INDX) contains some other word say 'TERMINATE' and
VERB-WORD contains 'TERMINATE ', comparison is O.K as expected.

Hi Nina,
the problem here is entry matches, that shouldn't. So if I use a redefined variable, of course this will match, but that is not wanted.

Solution that I found are
1.Include an additional IF condition as mentioned above
2. increase the size of table entry. But this will affect a copy book variable and will cause further impacts.

But I would like to know how this problem occurs only OS/390 platform.

Regards,
cobp

 

[NinaToo]

Hi! Thanks for replying.

You wrote:
---------------
"the problem here is entry matches, that shouldn't. So if I use a redefined variable, of course this will match, but that is not wanted."
---------------

So you do want the spaces/low-values at the end of the 35-byte variable VERB-WORD to make it not match. Is this correct?

Hmmmm. Unfortunately, I don't know a whole lot about compiler options in different environments.

But what you could do is replace each of the low-values/spaces in VERB-WORD with a character such as '@'.

I did this in an application where I wanted to make the online input more "user friendly" in that they were to enter digits in an imput field, and then a search was made to look for a match. But the users wanted to be able to enter the digits anywhere in the four-byte input field i.e. "___25" would be the same as "25___" or even "2_5_".

I did an INSPECT REPLACE statement which changed the low-value bytes to '@' then was able to move the digits around to a uniform field before doing the search for a match.

So in your application, to make the match not work when there are the empty bytes containing spaces/low-values in VERB-WORD, when these spaces/low-values exist, replace them each with '@' then do the match.

Believe me, '234@@@' will not match with '234'

I'm not sure that this is what you want. If the way you did it works, then use it. But if it causes copybook problems, then it's not a viable solution.

Hope this helps. Nina Too

 

[Crox]

Hi,

the code you show us:

quote:
SEARCH ALL VALID-VERB-TABLE
WHEN VERB-ENTRY (INDX) = VERB-WORD
IF VERB-ENTRY (INDX) = VERB-WORD
MOVE TRUU TO VERB-FOUND-SW
ELSE
DISPLAY 'PROBLEM OCCURS WITH THIS WORD****'
END-IF.
end-quote

In this case the ELSE clause will never be true because of the WHEN clause, we are sure that VERB-ENTRY (INDX) = VERB-WORD.

Syntax of the search all:

    ___ Format 2--binary search ______________________________________________________________________
   |                                                                                                  |
   | >>__SEARCH ALL__identifier-1__ _____________________________________ __________________________> |
   |                               |_ ____ __END__imperative-statement-1_|                            |
   |                                 |_AT_|                                                           |
   |                                                                                                  |
   | >__WHEN__ _data-name-1__ ____ __ _EQUAL__ ____ _ __ _identifier-3____________ _ _______________> |
   |          |              |_IS_|  |        |_TO_| |  |_literal-1_______________| |                 |
   |          |                      |_=_____________|  |_arithmetic-expression-1_| |                 |
   |          |_condition-name-1____________________________________________________|                 |
   |                                                                                                  |
   |    <__________________________________________________________________________________           |
   | >____ ______________________________________________________________________________ _|________> |
   |      |_AND__ _data-name-2__ ____ __ _EQUAL__ ____ _ __ _identifier-4____________ _ _|            |
   |             |              |_IS_|  |        |_TO_| |  |_literal-2_______________| |              |
   |             |                      |_=_____________|  |_arithmetic-expression-2_| |              |
   |             |_condition-name-2____________________________________________________|              |
   |                                                                                                  |
   | >__ _imperative-statement-2_ __ ____________ _________________________________________________>< |
   |    |_NEXT SENTENCE__________|  |_END-SEARCH_|                                                    |
   |                                                                                                  |
   |__________________________________________________________________________________________________|

So the else-situation has to be evaluated after the search all statement. In the when-clause you can do an action on which you can test in the next statement.

Regards,

Crox

 

[cobp]

Hi Crox,

I just quoted this code to show the unexpected behaviour of SEARCH when this special case is encountered.

Once again I remind you that the problem occurs only when
for searchword like
INITIALIZE-XYZ.
Here I think that only first 10 characters were used searching(As the table entries are of length 10). So here it matches(UNexpected behaviour !!! This was evident from the debug statements, see the original code given in the first question).

BUT MOVE statement compares normal way and mismatch occurs, that's ELSE part is executed.

Hi Nina,

My problem is different one, as mentioned above(really an unexpected behaviour)

Regards,
cobp

 

[Crox]

Hi,

can you give the smallest complete source which has this wrong behaviour?

I like to try it myself.

Thanks in advance!

Regards,

Crox

 

[cobp]

Hi Crox,

Finally I found out the the issue in the documentation. This issue was mentioned in the IBM documnetation.

6.2.32.8 WHEN phrase(Binary Search)

if when relation condition is specified, compare is based on the length and if the length of dataname is shorter than search argument then searchargument is truncated.......

But I think that this problem occurs only for WHEN condition related with BINARY SEARCH only(SEARCH ALL). But why didn't it behave the same way on VA COBOL. May be because, VA Compiler specification is not in the same way.

Thanks Crox, Nina


Regards,
CobP

 

[Crox]

Yeah! Now I know again why I am never using indexes again...

I tried it myself with this:

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. SRCHALL.
000300 ENVIRONMENT DIVISION.
000400 CONFIGURATION SECTION.
000500 SOURCE-COMPUTER. IBM-PC.
000600 OBJECT-COMPUTER. IBM-PC.
000700 SPECIAL-NAMES.
000800     DECIMAL-POINT IS COMMA.
000900 INPUT-OUTPUT SECTION.
001000 FILE-CONTROL.
001100 DATA DIVISION.
001200 FILE SECTION.
001300 WORKING-STORAGE SECTION.
001400 01  SEARCH-ALL-TEST.
001500     03  SAT-INFO                    PIC X(10) VALUE '----+----1'.
001600 01  REDEFINES SEARCH-ALL-TEST.
001800     03  SAT-ELEMENT OCCURS 1        ASCENDING KEY SAT-ELEMENT
001810                                     INDEXED BY SAT-IDX
001900                                     PIC X(10).
002000 PROCEDURE DIVISION.
002100 MAIN SECTION.
002200 MAI-0001.
002300     SEARCH ALL SAT-ELEMENT
002400        WHEN SAT-ELEMENT (SAT-IDX) = '----+----1-'
002500           DISPLAY 'TEST 1 = OK'
002600     END-SEARCH.
002700     SEARCH ALL SAT-ELEMENT
002800        WHEN SAT-ELEMENT (SAT-IDX) = '----+----1'
002900           DISPLAY 'TEST 2 = OK'
003000     END-SEARCH.
003100     SEARCH ALL SAT-ELEMENT
003200        WHEN SAT-ELEMENT (SAT-IDX) = '----+----'
003300           DISPLAY 'TEST 3 = OK'
003400     END-SEARCH.
003500 MAI-9999.
003600     GOBACK.

So you know now what the one-line output of the program is...

Regards and thanks for this interesting problem!

Crox

 

[Crox]

So on the mainframe you get the output:

TEST 1 = OK
TEST 2 = OK

with my pc compiler normaly compiled I get:

TEST 2 = OK

Even when I use the dialect VS2 (with CA-REALIA) it is different!

Now I am curious whom is wrong here. Does IBM follows the COBOL standards in this???????

I don't think so....

Regards and thanks again!

Crox

 

[NinaToo]

Just out of sheer curiosity. And because I know little about how COBOL works on PC's.

It looks as though the mainframe sees

----+----1-

as being the same as

----+----1

because the mainframe truncates the final '-' from the string in the WHEN statement.

And I'm wondering why the PC doesn't do this. It seems to see the final '-' as part of the string, and thus it doesn't come up with a match.

Interesting problem, I do agree.

Nina Too

 

[Crox]

I think the PC doesn't because it is not a COBOL standard to compare only for a certain length.

In COBOL compares with unequal lengths are the same as if the shortest field was filled with spaces for the part it is shorter if you understand what I mean.

I guess the IBM implementation of the search-all is different from the standard... I guess.

One of the ANS COBOL people can perhaps answer this question.

Regards,

Crox