Dismount the disk, and mount it privately. If the disk is mounted by more than one node in an OpenVMS Cluster, dismount it from all other nodes. If this disk is an OpenVMS system disk, shut down all other nodes that are bootstrapped from this disk.

Issue the SET VOLUME/LABEL command, specifying the new label.

On OpenVMS V6.0 and later, issue the following PCSI command to reset the label information stored within the PCSI database to reflect the new disk volume label:

$ PRODUCT REGISTER VOLUME old-label device

Locate any references in the system startup (typically including the disk MOUNT commands) and any DISK$label references in application files, and change the references appropriately.

If this is a system disk (for the host or for a satellite), also check the DECnet MOP or LANCP boot database, as well as any references to the disk created by CLUSTER_CONFIG*.COM.

If Compaq Analyze is in use, check the system startup procedures for the Compaq Analyze tool. Certain versions of Compaq Analyze will record specific disk volume labels within the startup procedures.

Remount the disk appropriately.

5.14 How can I set up a shared directory?

To set up a shared directory---where all files created in the directory are accessible to the members of specified group of users---you can use an access control list (ACL) and an identifier.

The following also shows how to set up a resource identifier, which further allows the disk resources to be charged to the specified identifier rather than each individual user. (If you don't want this, then omit the attributes option on the identifier creation and omit the entry added in the disk quota database.

Add an identifier using the AUTHORIZE utility:

ADD/IDENTIFER/ATTRIBUTES=RESOURCE groupidentifier

Grant the identifier to each user in the group using AUTHORIZE:

GRANT/IDENTIFIER groupidentifier username

If disk quotas are in use, add an entry via SYSMAN for each disk:

DISKQUOTA ADD groupidentifier/PERMQUOTA=pq/OVERDRAFT=od/DEVICE=ddcu:

Set the shared directory to have an ACL similar to the following using the SET SECURITY (V6.0 and later) or SET ACL (versions prior to V6.0) command:

(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W) (IDENTIFIER=groupidentifier,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=groupidentifier,ACCESS=READ+WRITE+EXECUTE+DELETE) (CREATOR,ACCESS=READ+WRITE+ACCESS+DELETE)

If there are files already resident in the directory, set their protections similarly. (The OPTIONS=DEFAULT, DEFAULT_PROTECTION, and CREATOR ACEs apply to directories.)

The default protection mask is used to establish the default file protection mask, this mask does not prevent the users holding the specified groupidentifier from accessing the file(s), as they can access the file via the explicit identifier granting access that is present in the ACL.

For further information, see the OpenVMS Guide to System Security Manual, specifically the sections on ACLs and identifiers, and resource identifiers.

5.15 Why do I get extra blank pages on my HP Printer?

For information on configuring telnet print symbiont, on device control libraries such as SYSDEVCTL.TLB, and for ways of dealing with the extra blank pages that can arise on various HP printers, please see the OpenVMS Ask The Wizard area, starting particularly with topic (1020):

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.

There are a variety of discussions of this and of related printing topics in the Ask The Wizard area, in addition to topic (1020).

Also see Section 5.34.

5.16 Drivers and Configuration of New Graphics Controllers?

This section contains information on various graphics controllers supported by OpenVMS Alpha, and specifically information on where and how to obtain device drivers for specific early OpenVMS releases--- device drivers for controllers are integrated into and shipped with OpenVMS Alpha, but versions of these device drivers are sometimes made available for specific earlier OpenVMS releases.

5.16.1 The ELSA GLoria Synergy

On OpenVMS Alpha V7.1-2, V7.2, and V7.2-1, acquire the appropriate GRAPHICS PCSI kit, and all prerequisite OpenVMS ECO kits:

• VMS712_GRAPHICS-V0300 or later
• VMS72_GRAPHICS-V0100 or later
• VMS712_GRAPHICS-V0300 or later

The ELSA GLoria Synergy is the PBXGK-BB; the PowerStorm 3D10T. Please ensure you have the most current ECOs for this and other graphics controllers installed; check for and install the current GRAPHICS kit. (See Section 4.2.2 for some unexpectedly related details.)

On OpenVMS Alpha V7.2-1, the files necessary for this graphics controller are located in the distribution CD-ROM directory:

DISK$ALPHA0721:[ELSA.KIT]

Also check for any available (later) ECO kits.

An earlier kit (ALP4D20T01_071) (for V7.1, V7.1-1H1, and V7.1-1H2) was once available, but has been superceded and is not recommended. Use of V7.1-2 or later (and use of one the above GRAPHICS kits as required) is typically the best approach.

OpenVMS V7.2-2 and later mainline releases directly support the controller.

Additional information is available in topics (3419) and (5448) in the Ask The Wizard area:

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.

Support for the ELSA GLoria Synergy is integrated into all current OpenVMS Alpha releases.

5.16.2 PowerStorm 300, PowerStorm 350

The PowerStorm 300 is the PBXGD-AC, while the PowerStorm 350 is the PBXGD-AE.

For support of the PowerStorm 300 and PowerStorm 350 graphics controllers, acquire and install the following available ECO kits:

For OpenVMS Alpha V7.1-2:

• DEC-AXPVMS-VMS712_P350-V0100--4 or later
• DEC-AXPVMS-VMS712_GRAPHICS-V0300--4 or later

For OpenVMS Alpha V7.2-1:

• DEC-AXPVMS-VMS721_P350-V0100--4 or later
• DEC-AXPVMS-VMS721_GRAPHICS-V0300--4 or later

Support for the PowerStorm 300 and PowerStorm 350 series graphics controllers is integrated into current OpenVMS Alpha releases.

5.16.3 PowerStorm 3D30, PowerStorm 4D20

PowerStorm 3D30 (PBXGB-AA), PowerStorm 4D20 (PBXGB-CA) information is available in Ask The Wizard topics including topic (2041):

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.

5.16.4 Radeon 7500

Install the current GRAPHICS ECO kit for OpenVMS Alpha V7.2-2 or V7.3-1 for support of the Radeon 7500 series PCI and AGP graphics controllers.

Support for this controller (without an ECO kit) is first integrated into and available in OpenVMS Alpha V7.3-2. (Please do always install the most current GRAPHICS ECO kit whenever one is available, however.)

5.17 How can I acquire OpenVMS patches, fixes, and ECOs?

You can acquire and download kits containing OpenVMS fixes (ECOs) for various releases, as well as related support information, via:

• http://www.itrc.hp.com/
• ftp://ftp.itrc.hp.com/openvms_patches/

Some systems with Internet firewalls may/will have to use passive mode FTP to access the above sites. Assuming recent/current versions of the TCP/IP Services package, the DCL FTP command necessary is:

$ DIRECTORY/FTP/ANONYMOUS/PASSIVE ftp.itrc.hp.com::

You can subscribe to an email notification list at the ITRC site.

For a list of OpenVMS ECO kits recently released, you can use:

• http://Eisner.DECUS.org/conferences/OpenVMS-patches_new_1.HTML

You can also sign up for ECO kit email notifications (Digest or individual notifications) directly from HP at:

• http://www1.service.digital.com/patches/mailing-list.html

Examples and ECO kit installation instructions are included in the cover letter. For available ECO kits, cover letters and other associated documentation, look in:

• http://www.itrc.hp.com/
• ftp://ftp.itrc.hp.com/openvms_patches/

For additional information, please see Section 5.17.

Do NOT attempt to install a VMSINSTAL-based OpenVMS ECO kit on OpenVMS Alpha V7.1-2 and later. While VMSINSTAL itself remains available, it is not used for OpenVMS Alpha ECO kits starting in OpenVMS Alpha V7.1-2. OpenVMS Alpha V7.1-2 and later use PCSI for OpenVMS ECO kits.

See Section 5.30 for information on ECO kit checksums.

5.18 How do I move the queue manager database?

To move the location of the queue database, the SYS$QUEUE_MANAGER.QMAN$QUEUES and SYS$QUEUE_MANAGER.QMAN$JOURNAL files, to a disk that is fast(er), has plenty of free space, and that is not heavily used. If the queue database is on a (busy) OpenVMS system disk, you can and probably should move it off the system disk to another disk spindle.

To move the queue database:

1. Checkpoint the journal file. This reduces the file size to the in-memory database size. This will cause the noted delay.

   $ RUN SYS$SYSTEM:JBC$COMMAND JBC$COMMAND> DIAG 0 7

2. Stop the queue manager

   $ STOP/QUEUE/MANAGER/CLUSTER

3. Backup the .QMAN$QUEUES and .QMAN$JOURNAL files from the present location for safety.

   $ backup SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* DISK:[DIR]

4. Create a new directory for the queue database. Insure that this disk is accessible to all nodes that can run the queue manager. If the /ON list for the queue manager is "/ON=(*)", the disk must be available to all nodes in the cluster

   $ CREATE/DIR fast_disk:[qman]

5. Copy the .QMAN$QUEUES and .QMAN$JOURNAL files to the new directory

   $ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* fast_disk:[qman]

6. Delete the old queue database.

   $ DELETE SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$*;*

7. Restart the queue manager pointing to the new location

   $ START/QUEUE/MANAGER fast_disk:[qman]

"Undeleteable" jobs are usually "undeleteable" for a reason---this can track back to insufficient process quotas, to a kernel-mode error in OpenVMS or a third-party device driver, or to other odd problems.

These undeletable jobs typically become of interest because they are holding onto a particular resource (eg: tape drive, disk drive, communications widget) that you need to use... If the particular device supports firmware, ensure that the device firmware is current -- TQK50 controllers are known for this when working with old firmware. (That, and the infamous "MUA4224" firmware bug.) If this device has a driver ECO kit available, acquire and apply it... If the particular relevant host component has an ECO, acquire and apply it.

Useful tools include SDA (to see what might be going on) and DECamds (which increase and thus potentially fix quota-related problems). (nb: Applications with quota leaks will obviously not stay fixed.)

If the stuck application is BACKUP, ensure you have the current BACKUP ECO and are directly following the V7.1 or (better) V7.2 or later process quota recommendations for operator BACKUP accounts. Quota details are in the OpenVMS System Manager's Manual.

If the firmware and ECO levels are current, the best approach is to take a system crashdump, and pass a copy of the dump file along to whomever is maintaining the device driver for the particular device/widget/driver involved, with any details on how you got into this situation. (The reboot involved with taking the crashdump will obviously clear the problem.)

There was some kernel-mode code (typically for OpenVMS VAX) that can reset the device ownership field, but that is rather obviously only an interim solution---the real fix is avoiding the loss of the IRP, the process quota leak, or whatever else is "jamming up" this particular process...

5.20 How do I reset the error count(s)?

The system reboot is the only supported approach, but it is obviously undesirable in various situations---there is presently no supported mechanism to reset error counts once the error(s) have been logged.

As for an unsupported approach---and be aware of the potential for causing a system crash...

To reset the error count, one needs to determine the system address of the error count field. For a device, this is at an offset within the device's UCB structure. On VAX, the field is at an offset symbolically defined as UCB$W_ERRCNT. On Alpha, this field's offset is symbolically defined as UCB$L_ERRCNT. The former is a word in size; the latter is a longword. (Could it be that Alpha devices are more error prone? ;)

You now need to locate the system address of the UCB$%_ERRCNT field of the device you wish to reset. Enter SDA. In the following, you will see designations in {} separated by a /. The first item in braces is to be used on the VAX and the second item should be used on an Alpha. (ie. {VAX/Alpha})

$ ANALYZE/SYSTEM SDA> READ SYS${SYSTEM/LOADABLE_IMAGES}:SYSDEF.STB SDA> SHOW DEVICE <ddnc:> ! device designation of device with error SDA> EVALUATE UCB+UCB${W/L}_ERRCNT Hex = hhhhhhhh Decimal = -dddddddddd UCB+offset

Record the hexadecimal value 'hhhhhhhh' returned.

You can now exit from SDA and $ RUN SYS$SHARE:DELTA or do what I prefer to do, issue the following:

SDA> SPAWN RUN SYS$SHARE:DELTA

On both VAX and Alpha, the DELTA debugger will be invoked and will ident- ify itself. On Alpha, there will be an Alpha instruction decoded. For those unfamiliar with DELTA, it does not have a prompt and only one error message---Eh? (Well, for sake of argument, there might be another error produced on the console if you're not careful---aka. a system crash!)

If you are on a VAX, enter the command: [W

If you are on Alpha, enter the command: [L

These set the prevailing mode to word and longword respectively. Remem- ber the UCB${W/L)_ERRCNT differences?

Now issue the command 1;M

DELTA will respond with 00000001

You are now poised to ZAP the error count field. To do so you need to en- ter the system address and view its contents. The format of the command to do this is of the form:

IPID:hhhhhhhh/

For an IPID, use the IPID of the SWAPPER process. It is always: 00010001

Thus, to ZAP the error count, you would enter:

00010001:hhhhhhhh/

When you enter the / SDA will return the content of the address hhhhhhhh. This should be the error count (in hexadecimal) of the device in question. If it is not, you did something wrong and I'd suggest you type a carriage return and then enter the command EXIT to get out of DELTA. Regroup and see where your session went awry.

If you entered your address correctly and the error count was returned as in the following example, you can proceed.

00010001:80D9C6C8/0001 ! output on VAX 1 error

00010001:80D9C6C8/00000001 ! output on Alpha 1 error

You can now ZAP the error count by entering a zero and typing a carriage return. For example:

00010001:80D9C6C8/0001 0[return] ! output on VAX 1 error

00010001:80D9C6C8/00000001 0[return] ! output on Alpha 1 error

Now type the command EXIT and a carriage return.

Alternatively, reboot the system.

5.21 How do I find out if the tape drive supports compression?

For various SCSI-based MK-class magnetic tape devices:

$ Devdepend2 = F$GETDVI("$n$MKcxxx:","DEVDEPEND2") $ Comp_sup = %X00200000 $ Comp_ena = %X00400000 $ IF (Devdepend2.AND.Comp_sup).EQ.Comp_sup THEN - WRITE SYS$OUTPUT "Compression supported" $ IF (Devdepend2.AND.Comp_ena).EQ.Comp_ena THEN - WRITE SYS$OUTPUT "Compression enabled"

5.22 Can I copy SYSUAF to another version? To VAX? To Alpha?

The format of the SYSUAF.DAT, RIGHTSLIST, and associated files are upward-compatible, and compatible across OpenVMS VAX and OpenVMS Alpha systems. (This compatibility is a a basic requirement of mixed-version OpenVMS Cluster configurations and OpenVMS upgrades---for specific support information, please see the OpenVMS Cluster rolling upgrade and mixed-version requirements.) That said, it's the contents of the SYSUAF and RIGHTSLIST files that will make this more interesting.

The same basic steps necessary for moving RIGHTSLIST and SYSUAF files to another node are rather similar to the steps involved in merging these files in an OpenVMS Cluster---see the appendix of the OpenVMS Cluster documentation for details of merging files. (You might not be merging the contents of two (or more) files, but you are effectively merging the contents of the files into the target system environment.)

Considerations:

• applications often hold SYSUAF or RIGHTSLIST open, meaning a system reboot is often the best way to activate new files.
• the meanings of the RESTRICTED and CAPTIVE flags settings on the UAF entries have changed over time.
• the new NET$PROXY.DAT file that is initially created based on the contents of the NETPROXY.DAT during the OpenVMS VAX V6.1 upgrade and during the OpenVMS Alpha V6.2 upgrade. This file is maintained in parallel with NETPROXY.DAT.
• the RIGHTSLIST identifier values and UIC values that end up scattered around the target system must be rationalized with the contents of the new RIGHTSLIST and SYSUAF files.

The lattermost case---resolving the identifier values---is often the most interesting and difficult part. If you find that an identifier value (or identifier name) from the source RIGHTSLIST collides with that of an identifier existing on the target system, you must first determine if the two identifiers perform the same function. In most cases, they will not. As such, you will have to find and chance all references to the identifier value(s) (or name(s)) to resolve the "collision".

If you encounter a collision, changing both of the identifier binary values (or names) involved in the collision to new and unique values can prevent security problems if you should miss a couple of identifiers embedded somewhere on the target system during the whole conversion process---rather than the wrong alphanumeric value for the identifier being displayed, you'll simply see the binary format for the identifier displayed, and no particular access will be granted. And any DCL commands or such that reference the old alphanumeric name will fail, rather than silently (and potentially erroneously) succeeding.

Similar requirements exist for UIC values, as these too tend to be scattered all over the system environment. Like the binary identifier values, you will find UIC values associated with disks, ACLs, queues, and various other structures.

For a list of the various files shared in an OpenVMS Cluster and that can be involved when relocating an environment from one node to another (or merging environments into an OpenVMS Cluster), please see the SYLOGICALS.TEMPLATE file included in OpenVMS V7.2 and later releases.

Procedures to extract the contents of a (potentially corrupt) queue database are provided on the OpenVMS Freeware (V5) and can be used to combine two queue databases together while shuffling files between OpenVMS Cluster hosts.

For related discussions of splitting a cluster into two or for removing a node from cluster (political divorce, etc), see topics (203), (767), (915) and others in the Ask The Wizard area:

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.9.