OpenVMS %INIT-F-DATACHECK, write check error

[Francesco Russo]

Good morning,
I need help regarding OpenVMS V7.3-2 (COMPAQ AlphaServer DS10 466 MHz- HBA KGPSA-C), when I try to initializate new LUNS (visible from "sh dev dg") i receive the following error message:%INIT-F-DATACHECK, write check error. The latest patch kit has been installed DEC AXPVMS VMS732_UPDATE V8.0, but I still have the same problem.

Thanks very much for your time.

regards
Francesco

[Cass Witkowski]

What type of disk subsystem are you using? HSG80, MSA1000, EVA?

Are the connections on the disk subsystem set to profile or connection type of OpenVMS?

Did you perform an init on the lun on the disk subsystem? On HSG80s you need to init the unit

HSG80> INIT D101

Regards
Cass

[Francesco Russo]

Hello Cass,
Thanks for the replay.
I am using an HDS AMS200. Sorry but I do not understand your second question. (I am not an OpenVMS guy), if you refer to SAN connection, this server is connected to a cisco 9210 FC-AL (no zoninig). I performed the init on the disks visible from "sh dev dg".
-----------------
$>init $1$dga0
_Label: vol0
%INIT-F-DATACHECK, write check error
-----------------
$>init $1$dga0 vol0
%INIT-F-DATACHECK, write check error
-----------------------------------
Thanks
Francesco

[Petr Spisek]

Hi,
is posible mount this disk? (mount/ov=id $1$dga0:)
- If yes, try to use command "set volume $1$dga0: /data=nowrite" (disk must be mounted)
- dismount $1$dga0:
- initialize/system $1$dga0: label

Petr
BTW: Returns something command "show symbol init" ?

[Francesco Russo]

Hi Petr.
Thanks for your info, eventually I managed to init some device after trying 70 times to do so:
$> mount/ov=id $1$dga0: %MOUNT-F-NOHOMEBLK, Files-11 home block not found on volume
-MOUNT-I-VOLIDENT, label = 'VOL0 ', owner = ' ', format = 'DECFILE11B '
------------------------------------
$> initialize/system $1$dga1: vol1
%INIT-F-DATACHECK, write check error
------------------------------------
After few error I managed to init successfully:
$> initialize/system $1$dga1: vol1
$> mou $1$dga1:/ov=id
%MOUNT-I-MOUNTED, VOL1 mounted on _$1$DGA1: (ELI2TO)
set volume $1$dga1:/data=nowrite
$> dism $1$dga1:
------------------------------------
But when I tried again...

$> initialize/system $1$dga1: vol1
%INIT-F-DATACHECK, write check error
$> mou $1$dga1:/ov=id
%MOUNT-W-ALHOMINV, invalid alternate home block on _$1$DGA1:
%MOUNT-F-FILESTRUCT, unsupported file structure level

I do not know what is wrong with this. Can be the firmware on the HBA (DS-KGPSA-CA).

Thanks again.
Francesco

[Petr Spisek]

Hm,
if I understand right - after the building a new disk unit on your disk-controller, you can do only one init on vms, the second attempt does fail, doesn't it?
HDS AMS200? - I don't know this controller. Is it supported with vms?
How looks the unit on the controller? (POLICY, NOWRITE_PROTECT, other flags...)

Try to check the last supported version of firmwre on your controller and DS10.

Petr

[Volker Halle]

Francesco,

the HDS AMS200 seems to be a third-party (i.e. non-HP) SAN controller. Did you ever get any LUNs initialized successfully on that controller from OpenVMS ?

You will need to contact the vendor or support for the AMS200 and/or read the manual to find out, whether you need to do any special setup on that controller to be able to use the LUNs from OpenVMS.

By default, OpenVMS only does a write-check on file-system (XQP) QIOs. A DATACHECK error normally indicates, that the data written to a disk block could not be verified (read back and compared) correctly.

Volker.

[Francesco Russo]

Hi All,
Thanks very much for your time.
I am sorry but I called the Hitachi Data System Tagmastore DF700S as AMS200 (we call it like that where I work). The AMS200 or DF700S is subsystem and it seems been supported from both side (Subsystem to server and vice versa).
I have a quick question:
Does OpenVMS have this type of problem when try to init/mount disks used in past for different OS? I am saying this because probably those LUNs I am trying to init/mount had been used before from a different OS. Can I force this mount/init command?

Thanks again
Francesco

[Volker Halle]

Francesco,

it seems like there is a severe problem when writing/reading/comparing data to LUNs on this controller. OpenVMS sees a disk as a series of logical blocks, it does not care about the previous contents, if you do an INIT.

Did you ever successfully INIT any LUNs on this controller from OpenVMS ? One success out of 70 retries does not count as 'successful' !

Please take into account, that the connection type on the SAN controller needs to be defined to OpenVMS - at least this needs to be done on the HP SAN controllers (HSG, MSA, EVA).

Volker.

[Petr Spisek]

I never seen the similar problem. When the first init was OK, next reinit was successful every time. (On supported HW for vms).
Petr

[Francesco Russo]

Hi All,
I have just find out on a .pdf took from the HP web-site that the HBA I have needs the following patch "OVMS721_FIBRECHAN_V0200", but I cannot find it anywhere on the HP web-site. Does anyone knows if this patch has been superseded with a new one maybe with a different name?

Best regards
Francesco

[Petr Spisek]

Hi,
the latest is VMS721_FIBRE_SCSI-V0600

http://www5.itrc.hp.com/service/patch/patchDetail.do?patchid=VMS721_FIBRE_SCSI-V0600&sel={openvms:alpha:7.2-1,}&BC=main|search|

Petr

[Andy Bustamante]

Francesco,

You're running OpenVMS 7.3-2, the patches referenced above are for OpenVMS 7.2-1, which is years out of support. You can check for patches here on ITRC under "Maintenance and support for Compaq products" or http://www1.itrc.hp.com/service/patch/search.do?BC=main|&pageOsid=openvms.

The installtion utility should keep you from installing the older patches successfully, unlike some lesser operating systems.


Andy

[Jur van der Burg]

I've seen this before a year ago when I worked for VMS engineering. This is for 99.9% sure a problem with the disk subsystem, and not a VMS issue.

Some comments from an old case (where I created a diagnostic driver to catch the problem:

The problem does not appear to be within VMS. A databuffer of 127 pages
is written to disk, and read back immediately. The data is then compared
in chunks, and the second chunk of data fails after 1040 (hex) bytes with
data which appears to be old data from the same type as what's in the file.
There's no crossing of page boundaries, the difference is in the middle
of a page.

All buffer mapping is for contiguous pages in memory, the fibrechannel
buffer descriptors are valid. Here we can see that the last request was
a scsi read command with the FUA bit set (this means that the controller
must go out to disk to fetch the data from disk, and is not allowed to
satisfy the read from cache). Both the write to disk and the read command
show no error.

So it appears that the data we've been writing to disk did not make it
to the disk, or that the data read back did not come from disk. In short,
this is not something VMS can do anyhing about. The problem could be
bad hardware. Since the adapter of the system has already been exchanged
with the adapter from another system without result it's fairly safe to say
that the adapter is not at fault. This leaves the problem to the fibre
switches or the disk controller. The fact that another system has no problem
with this does not exclude the controller or the switches.

Talk to the vendor of the disk subsystem.

Jur van der Burg
(Ex- fibrechannel/scsi/vms kernel)

[Francesco Russo]

Jur,
thanks for your very good explanation. It funny but I am working for the vendor!!! the subsystem has not problem at all (analyzed the subsystem trace, nothing there). I will raccommed to upgrade the HBA fw maybe it will help.

Thanks very much for your time.

Francesco

[Volker Halle]

Francesco,

you can check the Firmware of the KGPSA in the running system with:

$ ANAL/SYS
SDA> FC SHOW DEV FGA

The most recent Firmware for the DS10 is V7.2, it includes the following FC adapter versions:

o DS-KGPSA-CA (LP8000) - Firmware Revision 3.93A0
o DS-KGPSA-DA (LP9002) - Firmware Revision 3.93A0
o DS-KGPSA-EA (LP9802) - Firmware Revision 1.91X6

For further troubleshooting this probelm, you could:

- MOUNT/FOR the disk and DUMP various blocks with DUMP/BLOCK=(count:n,START:n) and see whether you get the same results, if you repeat that operation for the same blocks.

- write a little program to write blocks to the disk using QIO and the IO$M_DATACHECK function modifier. This would allow you to find out, if this problem is related to certain LBNs or areas on the disk.

- Use LDDRIVER in REPLACE mode and tracing to capture all IOs to the disk during INIT. If the problem is reproducable for a specific LBN, you could then use the LD WATCH command to cause a crash and you may be able to find the 2 buffers in the dump.

You can find information about LDDRIVER at:

http://www.digiater.nl/lddriver.html

Volker.

[Francesco Russo]

Hello Volker,

Thanks very much for your update.
We tried to mount the disk using the option FOR and it seems it is working. The only problem we have is the dga0:
$>mou/for $1$dga0:
%MOUNT-W-ALHOMINV, invalid alternate home block on _$1$DGA0:
%MOUNT-I-MOUNTED, TEST mounted on _$1$DGA0:

P.S. The HBA firmware was already up-to-date.

[Volker Halle]

Francesco,

MOUNT/FOR mounts the disk from OpenVMS without using the file system. It tries to check, whether the disk has a valid file system and thus warns you, that the alternate home block has an invalid format. This disk is probably one of those, where your INIT failed with a DATACHECK error, so it didn't finish initializing the file system data structures.

There is the DISKBLOCK utility on the OpenVMS Freeware CDs, which allows you to poke around in the file system metadata. You can download this utility from:

http://h71000.www7.hp.com/freeware/freeware80/diskblock/

Looks like it's possible to do a MOUNT/FOR/DATA=WRITE - this should cause all WRITE-IOs to be issued with a writecheck IO modifier. With the DISKBLOCK utility, you can select a foreign-mounted disk and read and re-write individual disk blocks. If you take one of your disk, which failed the INIT command, you could test writing blocks to that disk without destroying any data files on that disk.

This way, you may be able to demonstrate a DATACHECK error when writing certain blocks on the disk.

Volker.