Tracy,

as I am just finding out, HP Cobol did many things that were not Cobol
standard. Now I pay the price.
They worked with HP-Cobol but no longer with Microfocus Cobol and HP-UX.
Ksam-Files, Ksam-Keys, Flat-Files, automatic closing of print-files at STOP
RUN
just to name some.
They all cause trouble/problems.

Wish HP had a HP Cobol running under UNIX and of course a decent file-
system. Wonder where all the good folks/developers from MPE went.

Michael




On Tue, 17 Feb 2004 08:11:50 -0800, Tracy Pierce <[log in to unmask]>
wrote:

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