home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / ingres / 1303 < prev    next >
Encoding:
Text File  |  1992-09-03  |  4.1 KB  |  87 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!sol.ctr.columbia.edu!eff!news.oc.com!spssig.spss.com!uchinews!gsbacd.uchicago.edu!cs_mj
  3. From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
  4. Subject: Re: E_CLFE07 and E_SC022F and E_LQ002E
  5. Message-ID: <1992Sep3.165656.1@gsbacd.uchicago.edu>
  6. Lines: 75
  7. Sender: news@uchinews.uchicago.edu (News System)
  8. Organization:     
  9. References: <1992Sep3.161408.8517@news.columbia.edu>
  10. Date: Thu, 3 Sep 1992 22:56:56 GMT
  11.  
  12. In article <1992Sep3.161408.8517@news.columbia.edu>, 
  13. alan@curta.cc.columbia.edu (Alan Crosswell) writes:
  14. > I keep seeing this errors under 6.3 and 6.4.  Anybody know that they
  15. > really mean if anything? 
  16. > 
  17. >       ::[4026            , 00846860]: Thu Sep  3 04:02:17 1992  
  18. > E_CLFE07_BS_READ_
  19. > ERR     Read from peer process failed; it may have exited.
  20. > 
  21. >       ::[4026            , 00846860]: Thu Sep  3 04:02:17 1992  
  22. > E_SC022F_BAD_GCA_
  23. > READ    SCF was unable to read a GCF block.
  24.  
  25. I mostly know VMS, but maybe this will help.  It looks like the front
  26. end went away, and the server tried to look for the next query from it,
  27. but couldn't.  It doesn't look like cause for concern.  In the last few
  28. months, this is the only similar thing we've seen:
  29.  
  30.       ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29 
  31. E_GC0001_ASSOC_FAIL Association failure: partner abruptly released association
  32.       ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29 
  33. E_SC022F_BAD_GCA_READ SCF was unable to read a GCF block.
  34.       ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:29 
  35. E_SC0123_SESSION_INITIATE Error initiating session.
  36.       ::[II_DBMS_12D     , 005FB140]:  6-AUG-1992 11:19:39 
  37. E_GC0001_ASSOC_FAIL Association failure: partner abruptly released association
  38.  
  39. Your E_CL error comes out of the compatibility library, which is like
  40. the server's kernel and provides a set of system calls (for server code)
  41. that are common across all platforms.  The E_SC error comes out of the
  42. SCF (session control?), which is like the dbms's scheduler and
  43. coordinates all activities associated with a session.  It says it
  44. couldn't read a GCF block, which is a communication block between the
  45. front end and the back end.  It looks like the SCF tried to read a GCF
  46. block by making a read call to the CL.  The CL couldn't satisfy the read
  47. because the front end process was gone.  The CL logged the error and
  48. returned an error code to the SCF, which also logged an error.
  49.  
  50. You might try to reproduce this by starting up a front end and then
  51. killing it in various ways: ^C, ^\, kill -9, kill -HUP, etc.  See what
  52. gets logged.  Try giving the interrupt in the middle of a select loop or
  53. cursor fetch loop, or after a cursor open but before the first fetch.
  54.  
  55. > Also, for the first time ever on a SQL program that we run regularly, this
  56. > one came out:
  57. > 
  58. > E_LQ002E _NODB  The 'open ' query has been issued outside of a DBMS
  59. >     session
  60. > 
  61. > (and the saved query text was "xec..e ..e.y (c.f1) '19923BUSI6015B02'")
  62. > 
  63. > However, there is no other useful indication in errlog to correlate this
  64. > to, other than those frequent E_CLFE07/E_SC022F errors.
  65.  
  66. It looks like an "open cursor" statement was issued, but after the front
  67. end and back end lost contact somehow.  Looks weird.  In VMS, the front
  68. end and back end communicate over 4 different channels (I think).  Each
  69. end gets two mailboxes to write to (for interprocess communication), one
  70. for queries/data and the other for status information.  In your case, it
  71. looks like maybe the query/data channel got hosed, but the status
  72. channel was still there so the server could report this error message
  73. back to the front end.
  74.  
  75. What is the saved query text after a normally executed "open"?  What was
  76. the name of the cursor that you were opening, and what is its associated
  77. "select"?
  78.  
  79. I'm shooting in the dark here, but maybe some of this will help.
  80.  
  81. --Mark Jaeger                internet: cs_mj@gsbvax.uchicago.edu
  82. Graduate School of Business        yellnet:  (312) 702-0328
  83. University of Chicago            faxnet:   (312) 702-0233
  84. Disclaimer: My opinions are my own and not those of my employer.
  85. Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.
  86.  
  87.