Here is an attempt to resend just the portion that was cut off from
the previous message:
> pragma/locale.t 129 33024 116 18 15.52% 99-116
>
> Suspect the machine ...
I suspect the C RTL. Here for what it is worth is a response to a post I
made on the MVS-OE list by Fred Bohle:
!-------------------------8<--------------------
>From [EMAIL PROTECTED] Wed Mar 28 12:17:11 2001
>Date: Wed, 7 Feb 2001 15:19:42 -0600
>From: Fred Bohle <[EMAIL PROTECTED]>
>Reply-To: MVS OpenEdition <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Anyone seen this error before or know what it is?
This is a failure in HEAPCHK, which seems to run at
termination.
The manual suggests rerunning with the run-time option HEAPCHK(ON),
which will check the eyecatcher after every heap-related function
call.
Storage has been overlaid, destroying the eyecatcher on some
HEAP control block. If this is all IBM code, it sounds like a PMR
is in order.
Fred
From: Peter Prymmer <[EMAIL PROTECTED]> on 02/07/2001 03:07 PM
Please respond to MVS OpenEdition
<[EMAIL PROTECTED]>@SMTP@Exchange
To: [EMAIL PROTECTED]@SMTP@Exchange
cc:
Subject: Re: Anyone seen this error before or know what it
is?
On Tue, 6 Feb 2001, Ralph Goers wrote:
> Interesting. I am getting the same first two messages when I do
cp -B
> copying an object module into a PDSE as a new member. But it only
happens
> when cp is called from a REXX exec from gnu make. The same cp
command works
> fine issued from the command line.
>
> I recommend you open a PMR with IBM. You can reference mine if you
like
> although they may not be related: PMR 54674 Branch 122.
BTW On R2.5 if you write a C program to call setlocale() for various
locales in the /usr/lib/nls/locale directory you can obtain "Eye
Catcher
is damaged" error messages.
As far as I know this might require that there be a lot of locales.
On
one system in particular:
$ ls -1 /usr/lib/nls/locale | wc -l
152
You can take an awk or perl script to convert the output of `ls -1`
into
a C program that looks a bit like so:
% head testlocale.c
#include <stdio.h>
#include <locale.h>
char *string;
int main(void) {
string = setlocale(LC_ALL,"Bg_BG");
printf(" %s \n",string);
string = setlocale(LC_ALL,"Bg_BG.IBM-1025");
printf(" %s \n",string);
and the tail may look like:
$ tail testlocale.c
printf(" %s \n",string);
string = setlocale(LC_ALL,"Zh_TW");
printf(" %s \n",string);
string = setlocale(LC_ALL,"Zh_TW.IBM-937");
printf(" %s \n",string);
string = setlocale(LC_ALL,"th_TH");
printf(" %s \n",string);
string = setlocale(LC_ALL,"th_TH.IBM-838");
printf(" %s \n", string);
}
Now compile and run (note some long lines have been truncated by cut
and
pasting the output into this email message):
$ c89 -o testlocale testlocale.c
$ ./testlocale
/usr/lib/nls/locale/Bg_BG
/usr/lib/nls/locale/Bg_BG.IBM-1025
C
/usr/lib/nls/locale/Cs_CZ
/usr/lib/nls/locale/Cs_CZ.IBM-870
[snip]
Zh_TW
Zh_TW.IBM-937
th_TH
CEE3703I In HPCB Control Block, the Eye Catcher is damaged.
CEE3704I Expected data at 00000001 : HPCB
CEE0802C Heap storage control information was damaged.
From entry point main at compile unit offset +000025DA at
address 1A54.
CEE3703I In HPCB Control Block, the Eye Catcher is damaged.
CEE3704I Expected data at 00000001 : HPCB
CEE0802C Heap storage control information was damaged.
The traceback information could not be determined.
[1] + Done(137) ./testlocale
1375731751 Killed ./testlocale
I think that it would be nice if calling setlocale() repeatedly did
not
damage the Eye Catcher.
Peter Prymmer
> ----- Original Message -----
> From: "Paul Faulkner" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, February 06, 2001 2:34 PM
> Subject: Anyone seen this error before or know what it is?
>
>
> > Anyone seen this error before or know what it is?
> >
> > I seem to get it at the end of my Java program after it has
executed all
> the
> > statements.
> >
> >
> >
> > CEE3703I In HPCB Control Block, the Eye Catcher is damaged.
> > CEE3704I Expected data at 00000001 : HPCB.
> > CEE0802C Heap storage control information was damaged.
> > The traceback information could not be determined.
> > <> LEAID ENTERED (LEVEL 05/27/2000 AT 19.25)
> > <> LEAID ABENDAID DD ALLOCATED BY CWBMAKDD DYNALLOC RC =00000
> > [1] + Done(137) java TestReg
> > 83886933 Killed /usr/lpp/java/J1.1/bin/java
> >
> >
> >
> >
> > Paul Faulkner
> > Worldcom
> > [EMAIL PROTECTED]
> >
>
!------------------------->8--------------------
>
> pragma/warnings.t 421 1 0.24% 73
> 13 tests and 95 subtests skipped.
>
> use warnings 'once' report is stash key order, that is different
> when $x and $z have EBCDIC x and z.
One might suspect that sorting expected and returned results on EBCDIC
machines might help here - for some reason I thought that there was more
to it than that though.
Here is my summary:
comp/require..........FAILED at test 21
op/append.............FAILED at test 7
op/bop................FAILED at test 36
op/pat................FAILED at test 234
op/tr.................FAILED at test 50
op/vec................FAILED at test 27
op/ver................FAILED at test 19
pragma/locale.........FAILED at test 99
op/taint..............ok
no warnings 'once' ;
FAILED at test 73
lib/charnames.........FAILED at test 4
lib/digest............FAILED at test 1
lib/glob-basic........FAILED at test 10
lib/io_unix...........Can't call method "getline" on an undefined value at
lib/io_unix.t line 65.
FAILED at test 3
lib/md5-file..........FAILED at test 1
lib/mimeqp............FAILED at test 2
camel-III/vstring.....ok
Failed 15 test scripts out of 320, 95.31% okay.
u=17.91 s=5.97 cu=399.63 cs=133.21 scripts=320 tests=23049
just checking the wall clock time (as opposed to running under `time make
test`) it seems that the heap allocation speeds things up _tremendously_
(enough such that we ought to consider changing miniperl.c in
5.6.1-trial3).
More later...
Peter Prymmer
