Getting "caching is disabled" disk status via DCL

[Jack Trachtman]

I previously asked for help getting disk "Offline" status and am using the answers, but I don't understand enough about the UCB definitions that the answers pointed to for me to pick out how to get the "caching is disabled" status. Would someone be kind enough to show me which "sts" bit indicates this information? TIA

[Jon Pinkley]

Where are you seeing the "caching is disabled" message? In the "Volume Status:" portion of show device/full?

What version of VMS are you using?

I wasn't able to see anything that f$getdvi provided that was different when the volume was mount/cache vs. /nocache

This is a demo of a crude (kludge) method using Alpha VMS 7.3-2

Contents of CACHE_STAT.COM

$ this_pid = f$getjpi("","PID")
$ show device/full/out=sys$scratch:devfull.tmp 'p1'
$ search* sys$scratch:devfull.tmp; "caching is disabled"/noout/nowarn
$ if $status .eq. 1 ! found string
$ then
$ write sys$output "Found ""caching is disabled"" in show device/full ''p1'"
$ else
$ write sys$output "Didn't find ""caching is disabled"" in show device/full ''p1'"
$ endif
$ delete* sys$scratch:devfull.tmp;
$ exit

Demo

$ mou/ov=id/nocache $1$dga8410
%MOUNT-I-MOUNTED, DATASX mounted on _$1$DGA8410: (SIGMA)
$ @cache_stat $1$dga8410
Found "caching is disabled" in show device/full $1$DGA8410
$ dism $1$dga8410
$ mou/ov=id $1$dga8410
%MOUNT-I-MOUNTED, DATASX mounted on _$1$DGA8410: (SIGMA)
$ @cache_stat $1$dga8410
Didn't find "caching is disabled" in show device/full $1$DGA8410
$

Note there are no existence checks etc, just proof of concept.

There are probably better ways to do it.

Jon

[Jack Trachtman]

OpenVMS V7.3-2

A "SHOW DEVICE/FULL diskname" (at least on my systems) will show either the phrase "write-through caching enabled" or "caching is disabled".

I've got a kludgy PIPE cmd which will parse the output of SHOW DEV/FULL, but I'm worried that the formatting of the cmd output may wrap the phrase across two lines and so my PIPE cmd will miss it.

[Robert Brooks_1]

Are you talking about a disk or a tape?

Where in the $ SHOW DEVICE output are you seeing the "caching is disabled" message?

There is the item code dvi$_writethru_cache_enabled, but I don't think that's what you are looking for.

It *may* be that dvi$_nocache is what you want.

No, I don't know the distinction between the setting of vcb$v_nocache vs. the absence of
vcb$v_writethru_cache_enabled. The dvi item codes simply report the state of those two bits in the VCB.

V8.2 added a fair number of $GETDVI item codes that return volume-related information.
I think that those have all been backported to V7.3-2 some time ago, although that would be undocumented and unsupported.

-- Rob

[Jack Trachtman]

Here's an example of the output from SHOW DEV/FULL for a disk. I know that it will wrap here - just look at the last line.

$ sho dev/full dsa401:

Disk DSA401:, device type Generic SCSI disk, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled, device
supports bitmaps (bitmaps active).

Error count 0 Operations completed 317101513
Owner process "" Owner UIC [IDX,SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 23 Default buffer size 512
Total blocks 419430400 Sectors per track 128
Total cylinders 25600 Tracks per cylinder 128
Logical Volume Size 419430400 Expansion Size Limit 2240192512

Volume label "DB_01" Relative volume number 0
Cluster size 302 Transaction count 24
Free blocks 187820444 Maximum files allowed 519097
Extend quantity 5 Mount count 2
Mount status System Cache name "_DSA10:XQPCACHE"
Volume owner UIC [1,1] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

Volume Status: ODS-2, subject to mount verification, caching is disabled.
(rest of display deleted)

[Robert Brooks_1]

Volume Status: ODS-2, subject to mount verification, caching is disabled.

---
Yup.

DVI$_NOCACHE_ON_VOLUME returns TRUE and the "caching is disabled" message is displayed from $ SHOW DEVICE /FULL if vcb$v_nocache is set.

(my previous message may have referred to dvi$_nocache; the real name of the item code is dvi$_nocache_on_volume).

-- Rob

[Andreas Vollmer]

Hello Jack,
Do you know who is the disk server?
I know it sounds strange.
I experienced similar problems with HSJ, HSZ & HSG disks if the writeback cache battery is bad or due for proactive replacement (defined lifetime within the HSn controller).

The DSA401 indicates a shadowset. So you may have to check shadowset members instead.
Logon to the controller (HSn) and do a SHOW THIS FULL and a SHOW OTHER FULL.
The output will display the battery health state - maybe this is the cause of your trouble.
The other idea would be the attribute settings of the disks or storage sets on the HSn. There is a "switch" to enable or disable writeback caching.
One more possibility - older versions of the HSZ's, such as HSZ40, requires a license key in order to enable writeback cache. It could happend that the license key needs to be re-entered. Why it dropped out - don't ask - but it could happened.
Regards
Andreas

[Jack Trachtman]

Andreas,

Thanks for the comment, but I didn't mean to imply I'm having problems. I'm working on a script to dismount then, later, remount disks on our EVA5000s and I need to capture info about them. Fortunately there aren't many differences between the disk configs, but Caching is one (we turn off XFC caching on disks that are used by various DB products, Oracle, etc.)

Robert,

I'll see if I can figure out which bit returned by F$GETDVI(device,"STS") matches the symbol you found. Thanks

[Hoff · Accepted solution]

>>> I'll see if I can figure out which bit returned by F$GETDVI(device,"STS") matches the symbol you found. <<<

The cited bit is located in the Volume Control Block (VCB), and not in the Unit Control Block (UCB); the STS and DEVDEPEND and DEVDEPND2 stuff comes out from fields in the UCB. While there is a link from the UCB to the VCB (UCB$L_VCB, IIRC), I'd not want to try to follow pointers around through the OpenVMS kernel from within DCL. The $getdvi call is the path, if it has it available in your version.

Getting at the bit from kernel-mode code is pretty easy, but I'd also be tempted to follow the "parse the output" unsupported path, as -- if it breaks -- it's less likely to crash the system than the kernel-mode code that would be involved here, and probably easier to fix. At least until you can get the value via $getdvi or other documented interface.

[Jack Trachtman]

Thanks all