Here is the last response from IBM.
I have called my developer/architect about this issue. There are
several remedies discussed, like PSP bucket update, web DCF publish,
DOC apar....etc. We need to think about this, hopefully prevent others
from getting this problem. He likes to hear more from our customers in
Europe during Share meeting next month before final decision is made.
And we certainly understand where you're coming from. Anyway let me
quote some of the internal text we put out recently about this issue.
"..........
3) This is a problem even if the table is correctly filled with high or
low keys in unused slots.
4)This item only addresses a change in SEARCH ALL with an alphameric
key.
PROBLEM DISCUSSION:
The program is coded:
. SEARCH ALL MY-TABLE
. WHEN MY-KEY6 (MY-INDEX) = MATCH-NUMBER24
. MOVE 'Y' TO FOUND-IT
. END-SEARCH
The DATA DIVISION contains:
. 01 MATCH-NUMBER24 PIC X(24)
. and 01 BIG-TABLE.
. 05 MY-TABLE OCCURS 255 TIMES
. ASCENDING KEY MY-KEY6
. INDEXED BY MY-INDEX.
. 10 MY-ENTRY.
. 15 MY-KEY6 PIC X(6).
. ....and others........
Prior to PQ95214, it was possible to match an alphameric key and a
longer argument even if the extra bytes were not spaces (X'40').
The Enterprise COBOL Language Reference Manual
(SC27-1408-00, -01, -02) in the Binary Search, WHEN statement topic
says:
"If the WHEN relation-condition is specified, the compare is based on
the length and sign of data-name. For example, if the length of
data-name is shorter than the length of the search argument, the search
argument is truncated to the length of data-name before the compare is
done. If the search argument is signed and data-name is unsigned, the
sign is removed from the search argument before the compare is done."
The statement above is no longer in the Enterprise COBOL Language
Reference Manual V3R4 (SC27-1408-03) and has been replaced with:
' If a relation condition is specified in the WHEN phrase, the
evaluation of the relation is based on the attributes of the data item
referenced by
data-name-1. The search argument is moved to a temporary data item with
the same data description attributes as data-name-1, and this temporary
data item is used for the compare operations associated with the SEARCH.
In particular, if the search argument is a signed numeric item and
data-name-1 is an unsigned numeric item, the sign is removed from the
search argument before the compare is done. '
To explain fully what is happening, the SEARCH...WHEN now works like a
regular IF compare with extra bytes in an alphameric operand as
documented in the Ent COBOL LRM under Conditional expressions;....
Comparing alphanumeric operands:
" Operands of unequal size -
If the operands are of unequal size, the comparison is made as though
the shorter operand were extended to the right with enough spaces to
make the operands equal in size. "
********************************
SOME WORKAROUNDS ARE:
- Move the relevant bytes from the argument to a field of the same size
as the key and use that.
- Limited the range of the compare with reference-modification to
WHEN MY-KEY6 (MY-INDEX) = MATCH-NUMBER24(1:6)
- Fill the argument bytes that are beyond the key length with spaces."
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
