From: Peter Abbott [peter@pahpc.freeserve.co.uk]
Sent: Wednesday, December 08, 1999 4:12 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: how do i reset error couter

Thanks Brian,
    I appear to be having some trouble posting - at least attachments to
this news group so i will try including the txt itself. I was sent the
following as a result of a similar question I posted a couple of weeks ago -
appologies for the bandwidth used. And a warning to the inexperienced, dont
try this on a production system without first having built and tried it on a
system that doesn't matter, and dont try it with the VMS debugger - it will
crash your system if you do not know what you are doing ! You cannot use the
VMS debugger to debug Kernel code
!*********************************************************************
Command Procedure: reset_errors.com

$       macro reset_errors
$!
$       if (f$getsyi("arch_name") .eqs. "VAX")
$       then
$          link reset_errors,sys$system:sys.stb/selective
$       else
$          link/sysexe reset_errors
$       endif
$!
$       exit

*********************************************************************
Macro Program: reset_errors.mar

       .TITLE RESET_ERRORS - Clear all device errors
;
;       Issue: aug vax
;       Author: jeff jancula
;       Editor's Note: Use this procedure at your own risk. Professional
Press
;       is not liable for any damage that a utility of this nature might do
to
;       your system.
;
; This program will reset the error counts in the unit control blocks for
each
; device known to this system.
;
; Written by Jeff Jancula, Charlotte, NC, October 6, 1987
; Updated for VMS version 5, May 20, 1988
;
; This program is distributed free of charge. No guarantees or warranties as
; to suitability or reliability of this program are expressed or implied.

; To build:
;
;      $ MACRO RESET_ERRORS
;      $ LINK RESET_ERRORS,SYS$SYSTEM:SYS.STB/SELECTIVE
;
; (You should get NO errors or warnings.)
;
; To use:
;      $ RUN RESET_ERRORS
;
; You MUST have CMKRNL privilege to use this program.
;
; This program is known to work with VMS versions 4.5 through 5.1 and will
; probably work with future versions of VMS. It might need to be rebuilt
with
; each new VMS version.

       .library "sys$library:lib"
       $ucbdef       ; Define unit control block offsets
       $ssdef        ; System status codes

.entry reset_errors,^m<>           ; Program start address
       $cmkrnl_s -                 ; Switch to Kernel mode
              routin=ucb_zapper
       ret                         ; Exit to DCL

; The following code runs in Kernel mode. It scans the I/O database for all
; device unit control blocks (UCBs) and zeros their error counts.

.entry ucb_zapper,^m<r4,r10,r11>
       movaw  dont_crash,(fp)      ; Keep improper link from crashing VMS

; Gain exclusive (write) ownership of the I/O database MUTEX

       movl   ctl$gl_pcb,r4        ; Point R4 to our PCB
       jsb    g^sch$iolockw        ; Lock the I/O database, IPL=2

; Loop through the I/O database and reset all error counts

       clrl   r11                  ; Set first call flag
10$:   jsb    g^ioc$scan_iodb      ; Get next UCB
       blbc   r0,20$               ; Br if no more
;       clrw   ucb$w_errcnt(r10)    ; Clear error count  pre V7.0
       clrl   ucb$l_errcnt(r10)    ; Clear error count   post v7.0
       brb    10$
20$:

; Release the MUTEX and go back to caller

       clrl   @#exe$gl_mchkerrs    ; Clear machine check errors
       clrl   @#exe$gl_memerrs     ; Clear memory errors
       movl   ctl$gl_pcb,r4        ; Get back our PCB (is this necessary?)
       jsb    g^sch$iounlock       ; Free the I/O database MUTEX
       setipl #0                   ; Drop IPL back to normal process level
       movl   #ss$_normal,r0       ; Set success code
       ret                         ; Leave Kernel mode

; If you get an exception, you probably forgot to link with SYS.STB.
; It doesn't crash the system, just this process.

.entry dont_crash,^m<>
       $exit_s                     ; Just make our process go away

.end   reset_errors
!!


Brian Schenkenberger, VAXman- <system@SendSpamHere.ORG> wrote in message
news:009E24D7.0148115B@SendSpamHere.ORG...
> In article <82k3hr$27o$2@newsg3.svr.pol.co.uk>, "Peter Abbott"
<peter@pahpc.freeserve.co.uk> writes:
> >test
> >Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in message
> >news:82hn20$mgr$1@mailint03.im.hou.compaq.com...
> >>
> >> In article <8E948AF79joeyahoocom@news.supernews.com>,
joecarlos@yahoo.com
> >(Joe) writes:
> >> :hi guys this is a laim question but you quys have been so help full
that
> >> :i stop thinking thanks, ...
> >>
> >>   Either through an unsupported and architecture- and version-specific
> >>   kernel hack -- and no, I don't know where a customer could get this
> >>   tool -- or through a system reboot.  The latter is the only supported
> >>   approach, but is obviously undesirable in various situations...
> >>
> >>   An integrated and supported way to clear the error counter might show
> >>   up in a future OpenVMS release after V7.2-1 -- this one is under some
> >>   discussion here in engineering.  (It's relatively easy code, but so
are
> >>   the zillions of other simple projects...)
> >>
> >>   For chuckles, some of the kernel hacks can also set non-zero error
> >>   counts -- try setting a non-zero error count on the null device. :-)
> >>
> >>   Time to add this question to the OpenVMS FAQ -- I've been seeing this
> >>   question far too often of late.  If anyone has a pointer to the hack
> >>   -- which will be version dependent and might just crash the system
> >>   should something go wrong -- please let me know via email and I'll
add
> >>   that information to the FAQ...
> >>
> >> --
> >>
> >>   Please remember to include the OpenVMS version and platform when
posting
> >>   questions.  Thanks.
> >>
> >>
> >>  --------------------------- pure personal
> >opinion ---------------------------
> >>    Hoff (Stephen) Hoffman   OpenVMS Engineering
> >hoffman#xdelta.zko.dec.com
> >>
>
> There is one 'supported' way to do this if you consider the SYSTEM DUMP
> ANALYZER (SDA) and the DELTA debugger to be supported!  ;)  Of course,
> the use, in this fashion, of these utilities is likely to be considered
> unsupported.
>
> To reset the error count, one needs to determine the system address of
> the error count field.  For a device, this is at an offset within the
> device's UCB structure.  On VAX, the field is at an offset symbolically
> defined as UCB$W_ERRCNT.  On Alpha, this field's offset is symbolically
> defined as UCB$L_ERRCNT.  The former is a word in size; the latter is
> a longword.  (Could it be that Alpha devices are more error prone? ;)
>
> You now need to locate the system address of the UCB$%_ERRCNT field of
> the device you wish to reset.  Enter SDA.  In the following, you will
> see designations in {} separated by a /.  The first item in braces is
> to be used on the VAX and the second item should be used on an Alpha.
> (ie.  {VAX/Alpha})
>
> $ ANALYZE/SYSTEM
> SDA>  READ SYS${SYSTEM/LOADABLE_IMAGES}:SYSDEF.STB
> SDA>  SHOW DEVICE <ddnc:>    ! device designation of device with error
> SDA>  EVALUATE UCB+UCB${W/L}_ERRCNT
> Hex = hhhhhhhh   Decimal = -dddddddddd         UCB+offset
>
>
> Record the hexadecimal value 'hhhhhhhh' returned.
>
> You can now exit from SDA and $ RUN SYS$SHARE:DELTA or do what I prefer
> to do, issue the following:
>
> SDA> SPAWN RUN SYS$SHARE:DELTA
>
> On both VAX and Alpha, the DELTA debugger will be invoked and will ident-
> ify itself.  On Alpha, there will be an Alpha instruction decoded.  For
> those unfamiliar with DELTA, it does not have a prompt and only one error
> message -- Eh?  (Well, for sake of argument, there might be another error
> produced on the console if you're not careful -- aka. a system crash!)
>
> If you are on a VAX, enter the command: [W
> If you are on Alpha, enter the command: [L
>
> These set the prevailing mode to word and longword respectively.  Remem-
> ber the UCB${W/L)_ERRCNT differences?
>
> You're now poised to ZAP the error count field.  To do so you need to en-
> ter the system address and view its contents.  The format of the command
> to do this is of the form:
>
> <IPID>:<hhhhhhhh>/
>
> For an IPID, use the IPID of the SWAPPER process.  It is always: 00010001
>
> Thus, to ZAP the error count, you would enter:
>
> 00010001:hhhhhhhh/
>
> When you enter the / SDA will return the content of the address hhhhhhhh.
> This should be the error count (in hexadecimal) of the device in question.
> If it is not, you did something wrong and I'd suggest you type a carriage
> return and then enter the command EXIT to get out of DELTA.  Regroup and
> see where your session went awry.
>
> If you entered your address correctly and the error count was returned as
> in the following example, you can proceed.
>
> 00010001:80D9C6C8/0001                          ! output on VAX    1 error
>
> 00010001:80D9C6C8/00000001                      ! output on Alpha  1 error
>
>
> You can now ZAP the error count by entering a zero and typing a carriage
> return.  For example:
>
>
> 00010001:80D9C6C8/0001 0<cr>                    ! output on VAX    1 error
>
> 00010001:80D9C6C8/00000001 0<cr>                ! output on Alpha  1 error
>
> Now type the command EXIT and a carriage return.
>
>
> >>   For chuckles, some of the kernel hacks can also set non-zero error
> >>   counts -- try setting a non-zero error count on the null device. :-)
>
> So can the above!  Just type in some value other than zero.
>
> >>   Time to add this question to the OpenVMS FAQ -- I've been seeing this
> >>   question far too often of late.  If anyone has a pointer to the hack
> >>   -- which will be version dependent and might just crash the system
> >>   should something go wrong -- please let me know via email and I'll
add
> >>   that information to the FAQ...
>
> I've forwarded this technique to 'Hoff' for the FAQ.
>
> --
> VAXman- OpenVMS APE certification number: AAA-0001
VAXman@TMESIS.COM

