"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.

> 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.

> 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. 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.

> 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.

> 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.

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

Walter

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