Backup, Copy, RMS Errors (OpenVMS 7.3-2)

[Cass Witkowski]

Are you using an LD disk? If so it need to be mounted with /NOCACHE

[GuentherF]

Unless it has been changed, BACKUP does not re-order QIOs by VBN unless /IMAGE or /FAST is used.

Cheers,
Guenther

[GuentherF]

I doubt that if a disk block is in the XFC cache that any "virtual" read would bypass the cache. As far as I remember the IO$M_NOVCACHE was for writes only.

But I don't have the resources to confirm that this is truely the case.

Cheers,
Guenther

[Cass Witkowski]

All I know is that when we tried to use backup to copy a directory tree on an LD disk to another tree on the same disk it would not error but it would not work correctly. A sear of Google pointed to the fact that the LD devices should not be mounted with Cache.

I don't know why but there seems to be some interaction or lack there of with XFC.

That is why I was asking if you were using an LD device.

[Hein van den Heuvel]

Cass, I realize you are trying to help, but IMHO you are needlessly and dangerously muddling the waters.

Kindly give is explicit data instead of handwaving.

Are you perhaps referring to:
http://h71000.www7.hp.com/doc/732final/6668/6668pro_005.html
"4.11 Logical Disk (LD) Utility: Error when Using RMS V7.3-2"
(included below)

That is explicit about using the LD device from 'two angles', as a file and as a container file systems. That is not the general usage.
And it mentions that the file used as a container should not be cached which is rather (completely) different from mounting an LD device with or without (xqp) cache.

I would go as far as saying that is there was (still) a known, or suspect issues then Jur would mention that on his site (http://www.digiater.nl/lddriver). Since he doesn't there must not be an issue :-).

Doug Gordon also mentions this in : http://de.openvms.org/TUD2005/20_VMS_Hints_and_Kinks_Doug_Gordon.pdf.
It suggests this is an old, resolved issue, only to be mentioned while mentioning the exact versions used, but admittedly it is not explicit about that.
(I happened to have lunch with Doug today! :- Szechuan Chef! :-)

Cheers,
Hein




4.11 Logical Disk (LD) Utility: Error when Using RMS
V7.3-2

A feature of the Logical Disk (LD) utility can cause problems for end users who are using logical disks. This problem can occur on any version of OpenVMS that uses the LD utility.

The LD utility bypasses the cache for the container file when it is operating on the disk. If RMS is used to read or write to the container file, RMS will have stale data if the LD utility is used to connect to the file and subsequently to the logical disk that is being written.

This problem occurs mainly when the LD utility is used to create disk images that are to be burned onto a CD-ROM.

To work around the problem, execute the following DCL command to turn caching off for any file that will be used as a container file for the LD utility:


$ SET FILE/CACHING_ATTRIBUTE=NO_CACHING CONTAINER_FILE.DSK.
This DCL command is not executed as part of the CDRECORD.COM command procedure. Therefore, if you reuse a container file for a logical disk created by CDRECORD.COM, be sure to turn off the caching using this command.

[Cass Witkowski]

Hein,

Definitely do not want to muddy any waters.

After re reading this post, my case doesn't apply. I have to confirm, it but I think my issue was that the container file was not set /nocache.

As to the problem in this post...

From what I know OpenVMS tends to be rather robust as far as error detection goes.

It it was a hardware error in the disk subsystem, you think that the copy command would exhibit errors as well. The disk subsystem does not know whether backup or copy command was doing the IO.

I'm assuming that the firmware on the MSA1000 is at the latest version. Also that all the connections profiles on the MSA1000 are set to OpenVMS. We had issues on system after we replaced a Fibre Channel HBA on a node but forgot to update the connection profile to OpenVMS.

If the MSA1000 is not active/active, then
it could have been an issue with the MSA1000 controller and when the system rebooted it forced a switch of the FC path over to the other MSA1000 controller.

If the MSA1000 is active/active then we have to look at the system. It is not clear that this test was done from both systems in the cluster. If both systems show the same issue then it is not hardware related to any one system.

If you still had the BACKUP-FILE it would be interesting to dump the file around the errors to see what is written compared to what is supposed to be there. Is the data random? Is it zero? Is it similar to other data in the file? I would look if the errors occur at where the file is fragmented.

Do the EA40s have Elsa Gloria graphics cards? If so see. http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1285819675885+28353475&threadId=1251038