Walter Murray wrote:
>  "Michael Baier" wrote:
> > anybody experience problems with comp or comp-3 fields in KSAM or Flat-
> > Files when migrating from MPE to UNIX?.
> > Seems to create a problem when sorting the file or using a S9(05) field
as
> > a record-key.
> > Also on MPE I could have a record Key with Duplicates which seems to
make
> > problems using UNIX.
> > Any further experience with COBOL-HP and Microfocus on the HP-UX.
>
> Standard [1985] COBOL does not allow duplicates on the prime key of an
> indexed file.  It also doesn't allow COMP or COMP-3 data items as record
> keys.

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.

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.  While it's not
unreasonable for a Cobol to decide it can't handle certain file properties,
IIRC it doesn't really care whether a KSAM file has RDUP or not.    I can't
remember ever having trouble opening an RDUP KSAM file with Cobol, but I
sure never tried using COMP-3 as a key.

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.

The problem I'd expect to see in these files is an anomaly HP (I think)
introduced to COMP-3, at slight odds with IBM's de facto standard COMP-3
data.  I don't recall the exact details, but it involved the sign nibble,
which had at least 3 values, one of which was for 'unsigned', and vs which
all sorts of problems cropped up.

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

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.

Tracy Pierce





Are you using the Microfocus compiler?  Maybe it is
> enforcing these
> restrictions.  Maybe there's an option to allow these extensions.  The
> Response Center should be able to help.
>
> Sorting on COMP and COMP-3 items should not be a problem, but
> the internal
> representation of those data types might be different.
>
> Walter
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>

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