Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SEARCH ALL question. 4

Status
Not open for further replies.

wolves

Programmer
Jan 26, 2001
130
US
Question, when I do a SEARCH ALL, I pass a file which I load into and internal table, it's 35,000 rows, I am looking for a match in this table with an input file, I get no matches.

Now, when I take the same exact input file, except delete the last 15K rows, so now my internal table is 20K rows, I run the program, nothing changed, but now I do get my matches?

is there a limit on the SEARCH ALL?

My internal table is defined as such:

Code:
05  WS-TBL-TBL
        OCCURS  1 TO 40000  TIMES
        DEPENDING  ON  WS-TBL-ENTRIES
        ASCENDING KEY  IS  WS-TABLE-NUM, WS-TABLE-SUFF
        INDEXED  BY  WS-TBL-INDX   WS-TBL-MAX.
    10  WS-TABLE-NUM                PIC X(12) VALUE SPACES.
    10  WS-TABLE-IN                 PIC X(02) VALUE SPACES.
    10  WS-TABLE-IT                 PIC X(04) VALUE SPACES.
    10  WS-TABLE-DATE               PIC X(08) VALUE SPACES.

So I know it works for looking for my match because I do get a match with the smaller file?????
 
To follow up, would not my WS-TBL-ENTRIES is an S9(4) COMP field be large enough to hold my internal table?

Would not S9(4) COMP be some where around 'ffff' which would be 65535, it would be large enough to hold the data in my internal table, with is only 35K rows?
 
A S9(4) COMP hold a value between -32768 and +32767

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ181-2886
 
The statement

S9(4) COMP hold a value between -32768 and +32767

is NOT true for Standard COBOL and is only true on IBM mainframes (and some other compatible environments) depending upon the TRUNC compiler option.

What is true in STANDARD COBOL IS

S9(4) COMP hold a value between -9999 and +9999

Althought the STORAGE may be available for larger (smaller) values, "results are unpredictable" when such values are used - unless the vendor provides an non-conforming mote- such as the IBM TRUNC(BIN) or Micro Focus NOTRUNC directive.

Bill Klein
 
Bill, you're right.
My meaning was:
A S9(4) COMP can't hold a value outside the range -32768 to +32767
 
PHV, your statement is true (because it is a subset of Bill's statement), but Bill's is more exact.

If you describe an item with PIC S9(4) then you should expect that item not to store any value the absolute value of which exceeds 9999. To expect any other result may result in tempermental and unmaintainable code.

Back in the days of COBOL Compiler Validation tests, a compiler which did not produce a SIZE ERROR when storing a value with an absolute value larger than 9999 into an item described S9(4) COMP would fail to validate.

Tom Morrison
 
Back to wolves question. You were thinking that 'FFFF' should be in the largest possible value in your 2 byte binary field of S9(04). You have to remember that in binary, the sign is stored in the first bit. 0 is positive and 1 is negative. Therefore, '7FFF' is the largest possible value that you can get in that binary field. That translates to decimal 32,767. Again, the assumption is that you have compiler options set properly to have this value rather than the maximum 4 digits defined in the PICTURE.
 
COMP is binary normally.

If you do not like my post feel free to point out your opinion or my errors.
 
What COMP "is" really does vary.

For example, on IBM's OS/400 it is equivalent to Packed-Decimal.

For some intel compilers it is "big-endian" on others it is "little-endian" and others this is selectable.

As Tom mentioned above, in order to pass the '85 Standard "validation suite" - a compiler MUST pay attention to the PICTURE clause - and not to "available storage" (for binary data). Although many (I think most - but am not certain) compilers have an option for using the "maximum" storable value and (more or less) ignoring the PICTURE clause.

Bill Klein
 
Bill, if that's your description of "comp" fields, how would you describe "comp-5"?
I'd say that you descripion fit's comp-5, because that's binary native. The "native" stands for the CPU architicture..... and intel was little endian en power-pc was big-endian. One of us specified the wrong way around.
 
COMP-5 is a common - but not universal EXTERNSION to the ANSI/ISO Standard that MAY work the way you describe. (and does for some compilers).

The point is that COMP is *not* a defined "encoding" scheme and how EACH compiler handles it (and this may vary for the same vendor from platform to platform) is

IMPLEMENTOR DEFINED

Bill Klein
 
Any COMP-n is an extension, not part of the standard in any way. Therefore, the use of COMP-2, COMP-3, COMP-4, COMP-5 and COMP-6 is subject to the whims of the compiler vendor; you should expect no portability of the code or the data whatsoever. Only tradition and commercial realities have these data descriptions behaving in any similar manner.

BTW Bill is absolutely correct about COMP (without -n). The standard allows vendors to comply in virtually any manner they see fit.

Tom Morrison
 
is NOT true for Standard COBOL and is only true on IBM mainframes (and some other compatible environments) depending upon the TRUNC compiler option.

That is true but.... many compiler builders implemented COMP-5 as a native field with the maximum value behaviour. I know some of them:

- IBM
- CA-REALIA
- Micro Focus

So that is the biggest part of the market. So it will become a standard some day I guess.... [shadeshappy]
 
However, Micro Focus *also* has directives to treat COMP the same as COMP-5.

When you say "IBM" you mean PC, AIX, and z/OS - IBM OS/400 does NOT have COMP-5 (I beleive) and they are the place that has COMP = Packed-Decimal.

Bill Klein
 
Yeap iSeries (AS400) COBOL (both COBOL/400 and ILE-COBOL) do not have COMP-5.

RM/COBOL and ACUCOBOL both have it, and also Fujitsu COBOL.


I think that at the moment all PC vendors have COMP-5, some later to implement it than others.

Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Crox,

I do not think that any USAGE that does not maintain reasonably consistent behaviour across all platforms will be standardized. COMP-5 ('native' binary) clearly does not meet this test.

But...that's just me....

Tom Morrison
 
Further about the USAGE COMP-5:

The new (2002) standard does standardize BINARY much as it traditionally has standardized COMP, allowing the implementor to specify "the precise effect of the USAGE BINARY clause upon the alignment and representation of the data item in the storage of the computer, including the representation of any algebraic sign. Sufficient computer storage shall be allocated by the implementor to contain the maximum range of values implied by the associated decimal picture character-string."

So one could reasonably use [tt]REPLACE ==COMP-5== BY ==BINARY==[/tt] and expect similar or identical results, while eliminating a nonconforming USAGE.

The 2002 standard also standardizes BINARY-CHAR, BINARY-SHORT, BINARY-LONG, and BINARY-DOUBLE. Unlike BINARY, these new USAGEs have standardized meanings including specific ranges of values that may be stored within elementary items so defined. Also interesting to note is that PICTURE clause is not permitted with these USAGE types, thereby obviating the need for rules regarding decimal based truncation/size error.

Tom Morrison
 
Tom,
I do NOT think that the '02 Standard would allow for
Binary = COMP-5
but would allow for
Binary-Long/short = COMP-5

BINARY *still* uses the PICTURE clause, the BINARY-xxxx USAGES do not.

Bill Klein
 
Yes, Bill, you are correct. Even though I mentioned the decimal truncation in the very next paragraph, I had forgotten that COMP-5 does not permit a PICTURE clause.

Tom Morrison
 
COMP-5 does not permit a PICTURE clause

???

I guess you mean binary-long and binary-short.

Also options as TRUNC(STD) versus TRUNC(OPT) or TRUNC(BIN) do influence BINARY and not COMP-5 in IBM environments. COMP-5 is very important because site management of several companies do often chance the TRUNC option into STD. In IMS environments with S9(4) COMP fields to define the length of segements, it is very wrong to do so but try to convince those people that don't have the knowledge to take those decisions. To avoid trouble - as being hired - it is better to use COMP-5. BINARY is certainly not equal to COMP-5!
 
OK - let's try and get this discussion divided between "ANSI/ISO Standard" (syntax and behavior) vs "implementor defined behavior" with and without extensions.

COMP-5 (like all COMP-n) USAGEs is an extension. This means that the implementor may define ALL the rules about it.

For most of the implementations that I know of (and this may be true for all) that have a COMP-5 USAGE, it is a "binary" format, stored in "operating system-specific" bit order (i.e. big-/little-endian) and it has NO truncation; the PICURE clause is used to determine how much storage is allocated - and an S (or no-S) determines whether it is signed. Also, a "V" is allowed (for implied decimal point).

Similarly, most implementations that I know of have some sort of "TRUNC" compiler option/directive. One *must* specify "TRUNC" (or TRUNC(STD) or something similar) to run in ANSI/ISO conformance mode. HOWEVER, if you do not specify this, binary data is handled (more-or-less) like COMP-5 listed above. (IBM, for example talks about when it does and does not use the "maximum" binary storage). This applies to COMP and BINARY usages - but NOT to COMP-5 or other COMP-n formats.

***

The '02 Standard indroduces NEW "portable" USAGEs of
BINARY-CHAR, -SHORT, -LONG
which have an optional SIGNED phrase. These work very much like COMP-5 described above. HOWEVER, it is the USAGE that tells how much storage is allocated, not a PICTURE. Also the exact "storage size" is NOT specified in the Standard. These usages do NOT include implied decimal points (V) - so everything is processed as an "integer".

*NO* Standard (past or present) has actually specified how "binary" data is stored, much less COMP. This means that 2's compliment binary may or may not be used. Similarly, big-endian or little-endian may be used (and for COMP - it may be the same as BINARY, PACKED-DECIMAL *or EVEN* DISPLAY - and various vendors have used all of these at different times).

Bill Klein
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top