=:The OpenVMS Frequently Asked Questions(FAQ)C

The OpenVMS Frequently Asked Questions(FAQ)



 r \ ^  
PreviousContentsIndex

f

5.17 How do I move the queue manager database?



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

To move the queue database:

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

     

    "
    $ mcr JBC$COMMAND JBC$COMMAND> DIAG 0 7 
    
    
    

  2. Stop the queue manager

     

    "
    $ STOP/QUEUE/MANAGER/CLUSTER 
    
    
    G

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

     

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

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

     

    "
    $ CREATE/DIR fast_disk:[qman] 
    
    
    H

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

     

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

  6. Delete the old queue database.

     

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

  7. Restart the queue manager pointing to the new location

     

    "
    '$ START/QUEUE/MANAGER fast_disk:[qman] 
    
    
    

x

5.18 How do I delete an undeletable/unstoppable (RWAST) process?



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

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

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

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

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

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

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



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

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

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

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

 

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




1Record the hexadecimal value 'hhhhhhhh' returned.

HYou 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 




COn both VAX and Alpha, the DELTA debugger will be invoked and will @ident- ify itself. On Alpha, there will be an Alpha instruction Hdecoded. For those unfamiliar with DELTA, it does not have a prompt and Fonly one error message---Eh? (Well, for sake of argument, there might Hbe 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

HThese 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

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

 

"
IPID:hhhhhhhh/ 




HFor 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 Hhhhhhhhh. This should be the error count (in hexadecimal) of the device Gin question. If it is not, you did something wrong and I'd suggest you Etype a carriage return and then enter the command EXIT to get out of 4DELTA. Regroup and see where your session went awry.

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

 

"
K00010001:80D9C6C8/0001                          ! output on VAX    1 error 




 

"
K00010001: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:

 

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




 

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




0Now type the command EXIT and a carriage return.

!Alternatively, reboot the system.v

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



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

 

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


t

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



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

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

Considerations:



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

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

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

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

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

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



WFor additional information, please see Section 3.9.f

5.22 How do I delete (timeout) idle processes?



EThere is no such command integrated within OpenVMS, though there are H(optional) timers available within certain terminal servers and similar Hdevices, and there is an integrated time-of-day mechanism that provides ,control over when a user can access OpenVMS.

CAs for available tools, there are DECUS, freeware, and third-party Btools known variously as "idle process killers" (IPK) or terminal Etimeout" programs. Examples include: Saiga Systems Hitman, Watchdog, HMadGoat Watcher (via the MadGoat site or the OpenVMS Freeware), Kblock, Athe Networking Dynamics tool known as Assassin, and the Zap tool.

9A related package (for DECwindows sessions) is xtermlock.

HIf the forgetful users are in an application menu environment, the menu 7can potentially be extended to provide this capability.p

5.23 Do I need a PAK for the DECevent (HP Analyze) tool?



HDECevent and HP (Compaq) Analyze are avalable to customers with support Bcontracts. The PAK is required only for the advanced functions of GDECevent, the basic bits-to-text translation of the error log does not Crequire a license PAK. Ignore the prompt, in other words. (The PAK Fshould be available to you if you have a hardware support contract or Fwarrantee, and the PAK enables the use of the advanced error analysis /and notification capabilities within DECevent.)

3Please see the DECevent FAQ for additional details:



FThe current version of the DECevent (HP (Compaq) Analyze) tool can be downloaded from:

k

5.24 INITIALIZE ACCVIO and ANSI tape label support?



CA change was made (back in 1988) to (as it was then known) VAX/VMS DV5.1-1 that added support for the then-new ANSI X3.27-1987 magnetic Etape label standard. Prior to the ANSI X3.27-1987 standard, the date Ffield in the ANSI HDR1 record permits dates only as far as the end of HYear 1999. With ANSI X3.27-1987, dates through Year 1999 and dates from !Years 2000 to 2099 are permitted.

BVersions of INIT.EXE and MTAACP.EXE from VAX/VMS releases prior toHV5.1-1 will potentially have problems properly processing ANSI magnetic tapes when Y2KFand later dates are involved---the DCL INITIALIZE command is known to +encounter access violation (ACCVIO) errors.

DThe available solutions include upgrades, or setting the date back. EDirect initialization of the tape with the new headers (via $qio) is Galso clearly possible, though the limitation within the old MTAACP.EXE 2magtape ACP image is not nearly so easy to bypass.d

5.25 How do I recover from INSVIRMEM errors?



=Prior to OpenVMS Alpha V7.0 and on all OpenVMS VAX releases, GVIRTUALPAGECNT and PGFLQUOTA limit the amount of virtual address space "that is available to each process.

CFurther limiting the amount of address space is the size of system Hspace (S0 and S1 space). On OpenVMS Alpha versions prior to V7.0 and on Dall OpenVMS VAX releases, VIRTUALPAGECNT and MAXPROCESSCNT together Gdetermine the size of the page table data structures that occupy large @tracts of system space. When no system virtual address space is Gavailable for the stuff that needs it---this includes the page tables, Bnon-paged pool, and various other structures---then the values of 5VIRTUALPAGECNT and MAXPROCESSCNT cannot be increased.

EIn OpenVMS Alpha V7.0 and later, the page table data structures have Hbeen moved out of S0 and S1 space and into page table space. In OpenVMS GAlpha V7.2 and later, certain large data structures found in non-paged Bpool (eg: lock management structures) have been moved into 64-bit Espace, thus freeing up room in non-paged pool and in S0 and S1 space F(where non-paged pool resides) while also permitting much larger data structures.~

5.26 How can I prevent a serial terminal line from initiating a login?



(In SYSTARTUP_VMS.COM, issue the command:

 

"
+$ SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu: 




DThis will prevent any unsolicited terminal input on ddcu:, and this Gunsolicited input is what triggers JOB_CONTROL to start up LOGINOUT on Fthe terminal. Once LOGINOUT starts up on the serial line, you can see Ginteresting behaviour (eg: audits, process creations, etc) as LOGINOUT Ftries to "chat" with whatever device is hooked onto the remote end of the serial terminal line.k

5.27 How does PCSI use the image BUILD_IDENT field?



FThe (undocumented) build ident field in an OpenVMS Alpha image header Eis 16 bytes long, and is used as a counted string of 0-15 characters A(ie, a an .ASCIC string with count in byte 0) and was originally Eintroduced to provide information for use by VMSINSTAL patch kits to 5determine whether an image should be replaced or not.

FStarting with OpenVMS Alpha V7.1-2, OpenVMS Engineering uses the PCSI Cutility to package and install ECO kits for OpenVMS. PCSI uses the Hgeneration attribute (a 32-bit unsigned integer) specified for files in Bthe product description file (PDF) of a PCSI kit as the basis for Eperforming file conflict detection and resolution. When a product is Finstalled, PCSI modifies the build ident field of Alpha image headers Hto store an encoded form of the generation number. It also looks at the ?build ident field of previously installed images to obtain the Egeneration information for those files as input to the file conflict ?processing algorithm. (Only images have this field, obviously.)

FPCSI interprets the build ident field of a previously installed image as follows:



DSo, what will you see in the image identification displayed via the ANALYZE/IMAGE command?

CFor an image that has been built as part of an OpenVMS Engineering Esystem build, you will generally see a build ID string in the format H"X6TE-SSB-0000"---X6TE is the build number for the OpenVMS Alpha V7.2-1 Erelease. This id format is used within the OpenVMS system build, and Dcan generally only be seen associated with images that have not yet been processed via PCSI.

HDuring the installation of V7.2-1, PCSI will modify the image header to Ghave a build ident string of "X6TE-0050120000". During installation of Gan ECO kit containing this image with a generation number of 50130052, @for example, PCSI would determine that 50130052 is greater than F50120000, and will replace the existing image on the target disk with 1the version of the image included in the ECO kit.u

5.28 How can I tell what software (and version) is installed?



AThere is unfortunately no consistent nor single way to make this ?determination---this is one of the reasons that a move to PCSI installations is underway.

AOn OpenVMS Alpha, you can use VMSINSTAL.HISTORY and PRODUCT SHOW ?PRODUCT to determine what packages have been installed via the 'VMSINSTAL and PCSI tools, respectively.

?To see which OpenVMS Alpha ECO kits have been applied, look in DVMSINSTAL.HISTORY on OpenVMS Alpha prior to V7.1-2, and use PRODUCT 4SHOW PRODUCT/FULL on OpenVMS Alpha V7.1-2 and later.

HOn OpenVMS VAX, you can use PRODUCT SHOW PRODUCT and (for software that Cis installed via VMSINSTAL on V7.3 and later) in VMSINSTAL.HISTORY.

EFor products installed on OpenVMS VAX prior to V7.3 using VMSINSTAL, >there is no reliable way to determine what products have been Finstalled. If the product provides a RELEASE_NOTES file (as many do), 7you can look for the list of these files via DIRECTORY ESYS$HELP:*.RELEASE_NOTES. Again, this approach is NOT reliable: some Ekits do not provide release notes, some system managers will install Honly the release notes, some system managers will delete release notes, 7and release notes for multiple versions can be present.

DOn most packages, you can generally use ANALYZE/IMAGE on one of the Ccore images, looking at the image identification area. Some of the *product-specific mechanisms available are:

p

5.29 What file checksum tools are available for OpenVMS?



GThe undocumented DCL command CHECKSUM is the usual means, and provides >a rather simple-minded checksum suitable to detect basic file Hcorruptions. For information and an OpenVMS version of the MD5 checksum tool, see:



AThe OpenVMS Alpha ECO (patch) kit checksums available at the ECO @website are determined using the following DCL command sequence:

 

"
#$ CHECKSUM kitname.pcsi-dcx_axpexe  $ SHOW SYMBOL CHECKSUM$CHECKSUM 




lSee Section 5.16 for information on acquiring OpenVMS ECO (patch) kits.p

5.30 What (and where) is the OpenVMS Management Station?



DFor information and current kits for the OpenVMS Management Station E(OMS), a PC-based tool that permits you to manage an OpenVMS system, please see:

o

5.31 How to determine current disk fragmentation level?



AThe HP OpenVMS Disk File Optimizer (DFO) defragmentation package <provides a fragmentation monitoring tool, and a DFO product Hauthorization key (PAK) is not required for the fragmentation reporting tool:

 

"
$ DEFRAG SHOW/VOLUME ddcu: 




HThe DFU tool available on the OpenVMS Freeware can generate a report on the disk fragmentation:

 

"
DFU> REPORT ddcu: 







 r Y \ ^  
PreviousNextContentsIndex