From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
Subject: Re: E_CLFE07 and E_SC022F and E_LQ002E
Organization: 
Date: Thu, 3 Sep 1992 22:56:56 GMT

In article <1992Sep3.161408.8517@news.columbia.edu>, 
alan@curta.cc.columbia.edu (Alan Crosswell) writes:
> 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.

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.

> Also, for the first time ever on a SQL program that we run regularly, this
> one came out:
> 
> E_LQ002E _NODB  The 'open ' query has been issued outside of a DBMS
>     session
> 
> (and the saved query text was "xec..e ..e.y (c.f1) '19923BUSI6015B02'")
> 
> However, there is no other useful indication in errlog to correlate this
> to, other than those frequent E_CLFE07/E_SC022F errors.

It looks like an "open cursor" statement was issued, but after the front
end and back end lost contact somehow.  Looks weird.  In VMS, the front
end and back end communicate over 4 different channels (I think).  Each
end gets two mailboxes to write to (for interprocess communication), one
for queries/data and the other for status information.  In your case, it
looks like maybe the query/data channel got hosed, but the status
channel was still there so the server could report this error message
back to the front end.

What is the saved query text after a normally executed "open"?  What was
the name of the cursor that you were opening, and what is its associated
"select"?

I'm shooting in the dark here, but maybe some of this will help.

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

Newsgroups: comp.databases.ingres