NVRAM failure can be a big problem. Doing a DBDOC Live Loop Annotation fetching the block specifications will fail if the NVRAM has failed. This could be useful information to you.
Details
A client reported that DBDOC Hyperview could not fetch the specs of a block. In fact, the specs could not be fetched in any block in that module. This is shown in this image. Live data could be fetched - only the reporting of the specifications was affected.
However, fetching specs worked fine in other modules. The example in a clone of the problem one, as you can see.
What could cause this problem?
The next two images show the difference between working and failing module status fetches.
Guess what? The problem module shows NVRAM failure status: Fail. The one that is working says: Good.
From the Client
"I believe a NVRAM failure will prevent looking at any of the configuration."
Subsequent Perspective
"The module will continue to operate with an NVRAM error because a copy of the configuration is held in SRAM and executes from there. The next time the module is reset it will not startup but will fail.
"This module had failed earlier and was hard initialized during an outage and did not show the errors, but has NVRAM failure now."
New INFI 90 "art" has been crafted. This is the first time we know of that the module status fetch we created has been used to solve a problem.
This one is indeed useful information, because I encountered the same phenomenon a few years ago, however the problem appeared to 'fix itself', following an online configuration: The online configuration process effectively made the module - N+1 (which was the back-up at the time I couldn't read the specs in a DBDOC Live loop annotation), the 'new' primary module - N. Therefore only one of the modules in the redundant pair (the original primary N, prior to online config) had the NVRAM error that DBDOC can identify by the 'tell-tale' symptoms of. (It cannot fetch specs of blocks in live loop annotations).
ReplyDeleteI didn't know at the time, that anything was wrong - the module still worked fine and even online configuration (using Composer 4.2) worked ok...
A subsequent online configuration change or even simply failing the online N over to the back-up N+1 would no doubt have returned the DBDOC Live-loop annotations to being unable to display block specs.
In other words: only ONE of the two modules had NVRAM Failure.
When the original N+1 module (the 'good' module) became the primary (N) it appeared to fix the problem. I now know it didn't: ONE of the modules had a failed NVRAM and probably still does to this day...
I cannot say whether or not I noticed anything unusual in the status report from Composer (mainly because, I must confess, I don't always check that). The NVRAM Status is also reported in a Composer module status snapshot (but it refers to it as EEPROM). I think DBDOC's status reports are more reliable and informative, as they are a continuously updated report rather than the snapshot offered by Composer, which often, in fact usually: misses things that are intermittently troublesome, such as Controlway bus failures...