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 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- wrote in message news:009E24D7.0148115B@SendSpamHere.ORG... > In article <82k3hr$27o$2@newsg3.svr.pol.co.uk>, "Peter Abbott" writes: > >test > >Hoff Hoffman 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 ! 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: > > :/ > > 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 ! output on VAX 1 error > > 00010001:80D9C6C8/00000001 0 ! 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