From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: Ingres-Error (Read from peer process failed...)
Organization: 
Date: Mon, 28 Sep 1992 22:26:30 GMT

In article <2181@oss1.abg.psi.DE>, lonews@.abg (lonews) writes:
> In the errorlog of our ingres (Version 6.4 on HP-UX - A.08.00 D 9000/845)
> the following two error-messages can be found :
>
> E_CLFE07_BS_READ    Read from peer process failed; it may have exited
> E_SC022F_BAD_CGA_READ   SCF was unable to read GCF block
>
> These two messages are generated always together with about 10 to
> 15 minutes between each pair. This also occured in the previous
> Ingres release 6.3.

There was a previous exchange about these messages.  I've attached
extracts of the original messages and replies.

--Mark Jaeger				internet: cs_mj@gsbvax.uchicago.edu
Graduate School of Business		yellnet:  (312) 702-0328
University of Chicago			faxnet:   (312) 702-0233
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.

================================================================================
Date: 03 Sep 1992 16:14:08 +0000 (GMT)
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Subject: E_CLFE07 and E_SC022F and E_LQ002E
Message-id: <1992Sep3.161408.8517@news.columbia.edu>
Organization: Columbia University

I keep seeing this errors under 6.3 and 6.4.  Anybody know that they
really mean if anything?

      ::[4026            , 00846860]: Thu Sep  3 04:02:17 1992
E_CLFE07_BS_READ_
ERR     Read from peer process failed; it may have exited.

      ::[4026            , 00846860]: Thu Sep  3 04:02:17 1992
E_SC022F_BAD_GCA_
READ    SCF was unable to read a GCF block.

================================================================================
Date: 03 Sep 1992 22:56:56 +0000 (GMT)
From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)

I mostly know VMS, but maybe this will help.  It looks like the front
end went away, and the server tried to look for the next query from it,
but couldn't.  It doesn't look like cause for concern.  In the last few
months, this is the only similar thing we've seen:

      ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29
E_GC0001_ASSOC_FAIL Association failure: partner abruptly released association
      ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29
E_SC022F_BAD_GCA_READ SCF was unable to read a GCF block.
      ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29
E_SC0123_SESSION_INITIATE Error initiating session.
      ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:39
E_GC0001_ASSOC_FAIL Association failure: partner abruptly released association

Your E_CL error comes out of the compatibility library, which is like
the server's kernel and provides a set of system calls (for server code)
that are common across all platforms.  The E_SC error comes out of the
SCF (session control?), which is like the dbms's scheduler and
coordinates all activities associated with a session.  It says it
couldn't read a GCF block, which is a communication block between the
front end and the back end.  It looks like the SCF tried to read a GCF
block by making a read call to the CL.  The CL couldn't satisfy the read
because the front end process was gone.  The CL logged the error and
returned an error code to the SCF, which also logged an error.

You might try to reproduce this by starting up a front end and then
killing it in various ways: ^C, ^\, kill -9, kill -HUP, etc.  See what
gets logged.  Try giving the interrupt in the middle of a select loop or
cursor fetch loop, or after a cursor open but before the first fetch.

================================================================================
Date: 04 Sep 1992 07:51:22 +0000 (GMT)
From: eric@brolga.cc.uq.oz.au (Eric Halil)
Message-id: <eric.715593082@brolga>
Organization: Prentice Centre, University of Queensland

From the release notes for 6.4/02/00
------------------------------------
KNOWN PROBLEMS IN THE 6.4/02/00 RELEASE
       The bugs  listed  below  are  known  problems  in  the  6.4/02/00
       release.

         o Bug 42284

           Sometimes normal exits from INGRES  frontends  (i.e.  tm/sql)
           and user applications will cause spurious errors to be logged
           to the dbms error log file (errlog.log).  The errors are:

                 E_CLFE_07_BS_READ_ERR  Read from peer process failed;
                       it may have exited.
                 E_SC022F_BAD_GCA_READ  SCF was unable to read a GCF block.

Eric Halil                           |Internet/CSnet:         eric@cc.uq.oz.au
Prentice Centre                      |Bitnet:    eric%cc.uq.oz.au@uunet.uu.net
University of Queensland    4072     |UUCP:        uunet!munnari!cc.uq.oz!eric
AUSTRALIA --   Phone: +61 7 365 3610 |JANET:        eric%cc.uq.oz.au@uk.ac.ukc

================================================================================
Date: 08 Sep 1992 13:37:39 +0000 (GMT)
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Subject: E_CLFE07 and E_SC022F and E_LQ002E (CONCLUSIONS)
Message-id: <1992Sep8.133739.29651@news.columbia.edu>

Thanks to all the responders.  The short answers are:

E_CLFE07 and E_SC022F are spurious noise caused, for example, by
front-ends exiting without doing an exec sql disconnect first (e.g.
because they were interrupted with a control-C).