Has anyone been able to install cediag 1.3.2 (DIMM Management tools)?

Question

Document ID:     205430
http://sunsolve.sun.com/search/document.do?assetkey=1-61-205430-1
I receive the below error when trying to pkgadd SUNWcest. I've tried it on 2 different boxes including a SB1K running Solaris 10. The file in question exists, permissions look O.K., etc. Nothing unusual in the README. Any thoughts? Can someone try reproducing this on your server? Is anyone using the cediag tools? Thanks.
# pkgadd -d . SUNWcest
Processing package instance <SUNWcest> from </var/tmp/cediag>
DIMM Management and Correctable Error DIMM Statistics
(sparc) 1.3.2,REV=0.0.0
Copyright 2007 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
/var/tmp/cediag/SUNWcest/install/request: /var/tmp/cediag/SUNWcest/install/request: cannot open
pkgadd: ERROR: request script did not complete successfully
Installation of <SUNWcest> failed.
No changes were made to the system.
# ls -ld /var/tmp/cediag/SUNWcest/install/request
-rwxrwxrwx 1 root other 848 Dec 21 2004 /var/tmp/cediag/SUNWcest/install/request
(Note: I changed essentially every file in the tree to 777 to make sure it wasn't some weird permissions problem.)

Answer 1

Actually I want to use cediag on a v880 (8 CPU, 16GB RAM) running Solaris 8 (can't upgrade due to bureaucratic B.S.) but I wanted to test it first in a non-production environment. I don't have a spare 880 but I have tried it under both Solaris 8 and Solaris 10 on test boxes and get the same pkgadd installation error. I'm assuming this is a pkgadd error and has nothing to do with the actual cediag software itself since I can't even get the cediag software installed. I don't know if the pkgadd error is being caused by something in our environment here or is a fundamental flaw in the cediag installation package itself. I've never seen this particular error from pkgadd before.
The v880 started reporting sticky bit ECC errors recently but kept running. Although it was running, Solaris was "sickly" and running in a nondeterministic manner that made it very difficult to troubleshoot. I was really expecting it to either keep running normally while correcting that memory bit from parity until we replaced the faulty DIMM, or to panic and halt if it couldn't correct that bit. But that wasn't what happened and the result was considerable down time and troubleshooting until we replaced that DIMM. I would like to avoid that possibility in the future.
FYI. From "Solution 215045 : Sun Enhanced Memory DIMM Replacement Policy":
"Replace a DIMM when:
1. POST (when run at a level which actually tests memory) fails it.
2. For systems with Predictive Self-Healing (Solaris[TM] 10 Operating System(OS) and later, except on UltraSPARC II-based platforms), when the system tells you to."
So apparently even with Solaris 10, if you are running it on US2 platforms cediag is still relevant.
Q: Is Predictive Self-Healing an integral part of Solaris 10 or an optional package / add on?
Thanks again