<snip> But the configuration data (NED et al.) is stored in a control block that has not been publicly documented. I believe that it, too, can be displayed by an operator command. If an in-storage NED is hosed, a vary online or reIPL may be necessary. Also a PTF may need to be applied. <snip>
As I understand it, last four digits in "SCP DEVICE NED" identify CU logical address and device UA. Are the good and bad device in the same logical CU? What does the DEVSERV QDASD command returns for both devices? Are the SCU-SERIAL and DEVICE-SERIAL the same in both cases or you see the anomaly there too? Have you tried the VALIDATE parameter of the DEVSERV command (I don't know if it can help, we used it when moving to new devices without an IPL): DS QDASD,<bad dev>,validate -- Zaromil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
