On a related topic:

Given that a record has binary data, regardless of the field defination,
what will happen when (due to bad luck) 2 bytes of binary data just happens
to equate to a record termination byte sequence of line feed, carriage
return?

What about the remaining data past the 2 bytes to the true end of record
termination sequence?


----- Original Message -----
From: "Tracy Pierce" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, February 17, 2004 10:11 AM
Subject: Re: [HP3000-L] Migration: COMP-Fields in KSAM and Flat-files


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

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