"Tracy Pierce" wrote:
> From: Walter Murray [mailto:[log in to unmask]]
> > 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.

I guess it depends on how you look at it.  What I meant was, COBOL has to
allow duplicates on the secondary keys.  If the underlying file system
doesn't provide an access method that supports that feature, then the
compiler writer has to write one himself.  He can't just say, "KSAM (or
whatever) doesn't support it, so my COBOL implementation won't support it
either."

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

That's true.  You can tell the sort subsystem, either directly or through
your COBOL record description, that the key fields are just plain
characters, and it will happily treat them as such, and your signed numeric
fields may sort in strange ways.

Walter "I'd like an unlisted ZIP code and a negative SSN, please" Murray

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