From: Walter Murray [mailto:[log in to unmask]]
>"Tracy Pierce" wrote:
>> Are these really true?  I can't speak for the standard, but HP Cobol
makes a
>> point of telling you to be careful with duplicate keys.  Again I can't
speak
>> to the standard ANSI85 Cobol, but re HP Cobol, no such COMP or COMP-3
>> caveats are mentioned.

> Check the documentation of the RECORD KEY clause in the HP COBOL reference
> manual (page 6-47 if you have the July 1991 edition).  It's quite clear
that
> allowing duplicates on the prime key of an indexed file is an HP
extension.
> It also mentions that allowing a COMPUTATIONAL-3 data item as a record key
> is an HP extension.

Walter's 100% correct; my bad.  Sorry if I misled anyone.

>> COMP & COMP-3 are indeed Cobol terms, but I believe the KSAM flavor of
>> indexed file doesn't know or care what the actual content of the key
field
>> is - it's treated as characters for the purpose of indexing.

> Actually, KSAM does very much care about the data types of the keys.
That's
> why you specify the key type in the BUILD command for a KSAM file.  It
does
> not just treat the contents as characters.

Once again, my bad; of course if COMP/COMP-3 are allowed as keys, KSAM has
to be a lot smarter (and kludgier) than I ever gave it credit.  COMP-3 key?
Sounds like an invitation for trouble!

>> So MB _might_ be up against a cobol 'standard', but I can't imagine why
such
>> a restriction would be emplaced - dealing with troubles like dup keys is
a
>> programmer problem, not a compiler problem.

> It makes things hard on the compiler writer if the underlying file system
> doesn't provide the necessary support for things like duplicate keys.
Um, isn't that the other way around?  Quite nice that the filesys allows dup
keys; why should Cobol care?  They either work or they don't; the compiler
can't make ksam do the dirty deed if ksam won't do it.

> HP's KSAM was designed with the requirements of the COBOL standard in
mind.  It
> went beyond the standard by allowing things like duplicate prime keys and
> non-alphanumeric key types.

I'll buy that.

>> In my experience, MPE Sort's always done quite nicely with COMP binary
data
>> (it doesn't need to know; the only 'oddity' is that negative numbers
(stored
>> as twos-complement) sort 'bigger' than positive values).  Again following
>> ASCII collating sequence, it 'screws up' when encountering signs at the
>> almost-least-significant nibble in COMP-3.  Consider 12C3 (+123) and 12D4
>> (-124) - which comes first?  now toss 12D3 & 12C4 into the salad, then
add
>> a dollop of unsigned (F in the sign nibble?)

> I have to disagree again.  Like KSAM, SORT does care about the data types
of
> the sort keys.  Assuming you define the keys correctly to SORT (whether
you
> run SORT standalone, call the SORT intrinsics yourself, or use the COBOL
> SORT statement), SORT handles numbers just fine.  Negative binary numbers
> don't sort higher than positive numbers.

Again, you're absolutely correct (though declaring the keys as X will
produce the results I describe; you can easily do that in Cobol by putting a
group-item umbrella over your special-format data, ie 01 SREC. 05 GRPITEM.
10 SSN PIC S9(7) COMP-3. ...SORT SFILE KEY GRPITEM).

>> So to MB's original question, I'd suggest taking a look at the real
contents
>> of your COMP-3 fields' signs, which really should be C or D I think.  If
>> your Sort is screwing up on binary data, it's too smart for itself imho -
>> redefine as X for Sort.

Actually one of the reasons for my simpleton approach: always use char, and
you always know what you'll get, and you know you're not overworking some
kludge code that's a workaround in the first place, or even a built-in bug.

> SORT should handle COMP-3 just fine.  Any standard-conforming COBOL
compiler
> should be able to handle packed-decimal data items.
But Cobol <> Sort.

> Walter

Thanks for setting me straight, Walter.  Redface on 3 accounts, I've been
getting away with my always-X method for years (partly due to running into
troubles with anything else!).

Tracy KISS Pierce

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *