Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Shadowset Member Problem

 
Farooq Saleem
Frequent Advisor

Shadowset Member Problem

Reference to my previous post

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1391059

I successfully dismount the DKA0: disk and make it shadow set member again. Now the copying is in progress.

The problem is that, Error Count are continuously increasing. Can you please guide me that why are these error occurring, and how to overcome them.

See the attached document for the "sh dev d" command output, errors are mark in red.
4 REPLIES 4
Jim_McKinney
Honored Contributor

Re: Shadowset Member Problem

You have a hardware problem. Either the drive, cable, or SCSI adaptor is failing. Is PKA0 also logging errors? Depending upon what platorm and version of VMS you're running, you'll want to invoke ANALYZE/ERROR, DIAGNOSE (DECevent), or use WEBES to decode the entries that are being logged into SYS$ERRORLOG:ERRLOG.SYS.
Volker Halle
Honored Contributor

Re: Shadowset Member Problem

Faroog,

there is some hardware problem in the SCSI path to DKA0 or on the DKA0 disk itself. This hardware problem was also the cause for the error (0x8C = DRVERR) you've shown in your previous post (when trying to boot from DKA0).

On OpenVMS I64, you can only use SEA (System Event Analyzer, part of the WEBES tool set) for ERRLOG.SYS analysis. If you have an OpenVMS Alpha system, you could copy the ERRLOG.SYS file to that node and use DECevent ($ DIAGNOSE command).

Volker.
Hoff
Honored Contributor

Re: Shadowset Member Problem

Call your hardware service provider. Now.

Your SCSI bus is mis-terminated, your disk(s) is/are bad, your controller has failed, or some other low-level or hardware issue has arisen here.

If you've simply tried swapping the old disk back into this rx3600 series OpenVMS I64 box (as could be inferred from your notes), that's not a good strategy. And you do now know that there are problems with the disk or with the bus or with the controller here. Or with the server.

Depending on the specific details of the error(s) arising here, simply continuing to run this configuration could risk your data.

What follows is a write-up on the error analysis tools, but (bluntly) this is where you get your service provider spun up and moving first and foremost, and investigate details later...

http://labs.hoffmanlabs.com/node/295
Steve Reece_3
Trusted Contributor

Re: Shadowset Member Problem

Hiya Farooq,

You might like to bear in mind the recommendation that members of a system disk shadow set have different unit IDs (LUNs) unless you're doing dump off system disk. Having both disks with the same Unit ID can lead to the system not knowing what disk it is meant to be writing the crash dump to and potentially writing over it.
This won;t cause the problem that you have here, but it may cause others.

Steve