From:	MERC::"uunet!WKUVX1.BITNET!MacroMan" 23-JAN-1993 21:29:48.67
To:	MACRO32@WKUVX1.BITNET
CC:	
Subj:	Re: Programmatically determining memory error count

In article <1jjtf6INNep5@usenet.pa.dec.com>, stark@dwovax.enet.dec.com (Todd I.
 Stark) writes:
>
> [question was asked about retrieving memory errors]
>
>>       I'm trying to retrieve the error count associated with a CPU
>>       or memory boards. $GETDVI allows an error count to be
>
> [information was supplied regarding accessing EXE$GL_MEMERRS]
>
> It might also avoid some future confusion to know that this field is not
 updated
> on every occurance of a correctable memory error in some of the newer
> VAXes.  You might get errors logged just before a crash, for example, yet
> EXE$GL_MEMERRS will still contain zero upon analyzing the crash dump, having
> never been updated (as expected behavior).

  This is exactly the situation we encountered, and are trying to develop
  a monitor to detect. As Todd says, monitoring EXE$GL_MEMERRS will not
  guarantee that every memory error that makes it into the error log file
  will be detected. However, products like VAXsim do seem to keep track
  of all errors: memory, CPU or devices. It seems the mechanism used here
  is the undocumented system service (described in the IDSM - does that
  make it documented?) $DERLMB. Using this service (it takes one argument -
  the unit number of a mailbox, passed by value), I have been able to
  capture a buffer full of information when forcing an error logger event
  (mounting and dismounting a disk). As of this point, however, I have not
  been able to decipher the information contained in this buffer. Has anyone
  here played with this service to the point of understanding what fields
  the I/O buffer should be broken into, and where their definitions are?
  I've been trying to use the $E*DEF symbolics, but as yet haven't been
  able to come up with a Rosetta stone. Any help would be appreciated!

>
> The program would therefore not neccessarily have been able to
> programmatically 'predict' the crash due to memory errors, if that had been
> the intention.  More of the memory error handling is being handled
 'internally'
> without updating the user accessible location.
>
> Also, I've heard that EXE$GL_MEMERRS might no longer be used in future
> versions of VMS and future VAXes.
>
>                                               kind regards,
>
>                                               todd
>
 +-----------------------------------------------------------------------------+
> | Todd I. Stark                                 stark@dwovax.enet.dec.com
      |
> | Digital Equipment Corporation                            (215) 354-1273
      |
> | Philadelphia, Pa. USA
 |
> |                   "Sic transit gloria mundi"     <gulp>
 |
>
 +-----------------------------------------------------------------------------+

  Send email to address below - replies to this message will bounce.

                                                        -- Matt


  ****************************************************************************
   Matt Robertson              I have been urged by earnest violins
   Boeing Computer Services     And drunk their mellow sorrows to the slake
   Bellevue, Washington          Of all my sorrows and thirsting sins.
   mr2461@shamu.ca.boeing.com     My heart has beaten for a brave drum's sake.
  ****************************************************************************