| Previous | Contents | Index |
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.15.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:
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.3.1 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:
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.15.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:
For OpenVMS Alpha V7.2-1:
Support for the PowerStorm 300 and PowerStorm 350 series graphics
controllers is integrated into current OpenVMS Alpha releases.
5.15.3 PowerStorm 3D30, PowerStorm 4D20
PowerStorm 3D30 (PBXGB-AA), PowerStorm 4D20 (PBXGB-CA) information is available in Ask The Wizard topics including topic (2041):
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.15.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.16 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:
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:: |
Older sites:
The http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/ URL can be particularly useful, as it includes a search engine capable of returning the mandatory ECO kits for each release. Also see the information on required ECOs available from the support database, accessible via http://askq.compaq.com/. Specifically, search for articles with the words "incorporated" and "need to install" in the title.
You can subscribe to an email notification list at:
A quarterly distribution is also available on CD-ROM:
For a list of OpenVMS ECO kits recently released, you can use:
You can also sign up for ECO kit email notifications (Digest or individual notifications) directly from HP at:
Examples and ECO kit installation instructions are included in the cover letter. For available ECO kits, cover letters and other associated documentation, look in:
For additional information, please see Section 5.16.
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.29 for information on ECO kit checksums.
5.17 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:
$ RUN SYS$SYSTEM:JBC$COMMAND JBC$COMMAND> DIAG 0 7 |
$ STOP/QUEUE/MANAGER/CLUSTER |
$ backup SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* DISK:[DIR] |
$ CREATE/DIR fast_disk:[qman] |
$ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* fast_disk:[qman] |
$ DELETE SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$*;* |
$ 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.19 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.20 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"
|
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:
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:
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.22 How do I delete (timeout) idle processes?
There is no such command integrated within OpenVMS, though there are (optional) timers available within certain terminal servers and similar devices, and there is an integrated time-of-day mechanism that provides control over when a user can access OpenVMS.
As for available tools, there are DECUS, freeware, and third-party tools known variously as "idle process killers" (IPK) or "terminal timeout" programs, as well as various other names. Examples include: Saiga Systems Hitman, Watchdog, MadGoat Watcher (via the MadGoat site or the OpenVMS Freeware), Kblock, the Networking Dynamics tool known as Assassin, and the Zap tool. Also available is the XLNperformance system management utility, from XLNsystems.
A related package (for DECwindows sessions) is xtermlock.
If the forgetful users are in an application menu environment, the menu
can potentially be extended to provide this capability.
5.23 Do I need a PAK for the DECevent (HP Analyze) tool?
DECevent and HP (Compaq) Analyze are available to customers with support contracts. The PAK is required only for the advanced functions of DECevent, the basic bits-to-text translation of the error log does not require a license PAK. Ignore the prompt, in other words. (The PAK should be available to you if you have a hardware support contract or warrantee, and the PAK enables the use of the advanced error analysis and notification capabilities within DECevent.)
Please see the following website for details and downloads: Analyze)
A change was made (back in 1988) to (as it was then known) VAX/VMS V5.1-1 that added support for the then-new ANSI X3.27-1987 magnetic tape label standard. Prior to the ANSI X3.27-1987 standard, the date field in the ANSI HDR1 record permits dates only as far as the end of Year 1999. With ANSI X3.27-1987, dates through Year 1999 and dates from Years 2000 to 2099 are permitted.
Versions of INIT.EXE and MTAACP.EXE from VAX/VMS releases prior to V5.1-1 will potentially have problems properly processing ANSI magnetic tapes when Y2K and later dates are involved---the DCL INITIALIZE command is known to encounter access violation (ACCVIO) errors.
The available solutions include upgrades, or setting the date back.
Direct initialization of the tape with the new headers (via $qio) is
also clearly possible, though the limitation within the old MTAACP.EXE
magtape ACP image is not nearly so easy to bypass.
5.25 How do I recover from INSVIRMEM errors?
Prior to OpenVMS Alpha V7.0 and on all OpenVMS VAX releases, VIRTUALPAGECNT and PGFLQUOTA limit the amount of virtual address space that is available to each process.
Further limiting the amount of address space is the size of system space (S0 and S1 space). On OpenVMS Alpha versions prior to V7.0 and on all OpenVMS VAX releases, VIRTUALPAGECNT and MAXPROCESSCNT together determine the size of the page table data structures that occupy large tracts of system space. When no system virtual address space is available for the stuff that needs it---this includes the page tables, non-paged pool, and various other structures---then the values of VIRTUALPAGECNT and MAXPROCESSCNT cannot be increased.
In OpenVMS Alpha V7.0 and later, the page table data structures have been moved out of S0 and S1 space and into page table space. In OpenVMS Alpha V7.2 and later, certain large data structures found in non-paged pool (eg: lock management structures) have been moved into 64-bit space, thus freeing up room in non-paged pool and in S0 and S1 space (where non-paged pool resides) while also permitting much larger data structures.
| Previous | Next | Contents | Index |