ftp.pasteur.org/FAQ/

home *** CD-ROM | disk | FTP | other *** search

/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / dec-faq / vms / part2 < prev next >

Wrap

Text File | 2001-10-03 | 96.6 KB | 2,225 lines

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!paloalto-snf1.gtei.net!news.gtei.net!news.compaq.com!news.cpqcorp.net!not-for-mail Newsgroups: comp.os.vms,comp.sys.dec,vmsnet.alpha,vmsnet.misc,comp.answers,news.answers Distribution: world X-Newsreader: mxrn 6.18-32B References: <pkqu7.957$YP.25608@news.cpqcorp.net> From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Reply-To: hoffman@xdelta.zko.dec.nospam Followup-To: poster Approved: news-answers-request@mit.edu Expires: 2 Dec 2001 00:00:00 GMT References: <92irts$f4j$1@mailint03.im.hou.compaq.com> Subject: OpenVMS Frequently Asked Questions (FAQ), Part 2/5 Summary: This posting contains answers to frequently asked questions about the OpenVMS operating system from Compaq Computer Corporation, and the computer systems on which it runs. Lines: 2202 Message-ID: <qmqu7.958$YP.25685@news.cpqcorp.net> Date: Tue, 02 Oct 2001 21:31:02 GMT NNTP-Posting-Host: 16.32.80.251 X-Complaints-To: abuse@Compaq.com X-Trace: news.cpqcorp.net 1002058262 16.32.80.251 (Tue, 02 Oct 2001 14:31:02 PDT) NNTP-Posting-Date: Tue, 02 Oct 2001 14:31:02 PDT Organization: Compaq Computer Corporation Xref: senator-bedfellow.mit.edu comp.os.vms:311562 comp.sys.dec:89397 vmsnet.alpha:11482 vmsnet.misc:6280 comp.answers:47271 news.answers:216434 Archive-name: dec-faq/vms/part2 Posting-Frequency: quarterly Last-modified: 2 Oct 2001 Version: VMS-FAQ-2.TXT(7) This is the OpenVMS Frequently Asked Questions Part 2/5. Please see Part 1/5 for administrivia, indexing, archiving, etc. ------------------------------------------------------------ MGMT1. What is an installed image? The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here. The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function. The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.) It's important to note that there is no such thing as "installing a shareable image with privileges". The INSTALL utility will let you do it, but the privileges you specify will be ignored. To have a callable routine run with enhanced privileges that are not available to its caller, you must construct your routines as "user-written system services" and install the shareable image with the /PROTECT qualifier. See the OpenVMS Programming Concepts Manual for more information on user-written system services. Note also that in many cases the need to grant privileges to an image can be replaced with the use of the "Protected Subsystems" feature that grants a rights identifier to an image. See the OpenVMS Guide to System Security for information on Protected Subsystems. ------------------------------------------------------------ MGMT2. Are there any known viruses for OpenVMS? Viruses are very common on PCs because the PC operating systems such as MS-DOS and MacOS do not implement any sort of scheme to protect the operating system or the file system against hostile action by programs. On these operating systems, any running program can subvert the operating system and take over the hardware, at which point it can do anything it wishes, including hiding copies of itself in other programs or in the file system. This is unlikely on OpenVMS, Unix, and MVS for three reasons. First, the operating system runs in a privileged mode in memory that is protected against modification by normal user programs. Any old program cannot take over the hardware as it can on PC operating systems. Secondly, OpenVMS, Unix, and MVS have file systems that can be set up so that non-privileged programs cannot modify system programs and files on disk. Both of these protection schemes mean that traditional PC virus schemes don't work on these OSes. Third, typical applications and configurations tend to prevent the uncontrolled execution of untrusted code as part of email messages or web access. It is possible for OpenVMS, etc., to be infected by viruses, but to do so, the program containing the virus must be run from a user account that has amplified privileges. As long as the system administrator is careful that only trusted applications are run from such accounts (and this is generally the case), there is no danger from viruses. [Paul Winalski] [Stephen Hoffman] To protect against viruses and other attempts at system interference or misuse, follow the recommendations in the "OpenVMS Guide to System Security". You may also want to consider optional software products which can monitor your system for intrusion or infection attempts. Computer Associates (CA) offers various products in this area. Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com). [Contributions to this list welcomed] ------------------------------------------------------------ MGMT3. How do I mount an ISO-9660 CD on OpenVMS? ISO-9660 support was added in the following releases: OpenVMS VAX V6.0 OpenVMS AXP V1.5 An add-on ISO-9960 kit was also available for OpenVMS VAX V5.5, V5.5-1, V5.5-2, and V5.5-2H4. This requires the installation of the F11CD kit from the InfoServer CD, from the Consolidated Distribution CD under the InfoServer area, Customer Support Center kit CSCPAT #1071012, or the F11CD ECO kit. (Upgrades to V6 and later are strongly recommended.) By default, OpenVMS senses the specific type of media. If you are working with dual-format media -- media that uses both the ODS-2 and ISO-9660 formats on the same CD-ROM -- then MOUNT will first detect and then default to the ODS-2 format. If you wish to override this and explicitly mount the media using ISO-9660, use the command: $ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label] In most circumstances, you will not need nor will you want to include an explicit /MEDIA_FORMAT specification. For further information, please refer to the OpenVMS MOUNT Utility Manual. Particularly note the information on the MOUNT /MEDIA_FORMAT and /UNDEFINED_FAT qualifiers. The MOUNT /UNDEFINED_FAT qualifier is of interest because ISO-9660 media can be mastered on a wide variety of operating system platforms, and these platforms do not necessarily support the semantics needed for files containing predefined record formats. The /UNDEFINED_FAT allows you to specify the default attributes for files accessed from volumes using the ISO-9660 format. An example which works for most CD-ROMs is: $ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE This particular MOUNT command forces access to the CD-ROM media using the ISO-9660 volume structure, and the use of the MOUNT /UNDEFINED_FAT qualifier causes any file whose file attributes are "undefined" to be returned with "stream" attributes with a maximum record length 2048. On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS. [Jim Dunham] [Stephen Hoffman] For details on ODS-1 and ODS-2 file specifications, see Kirby McCoy's VMS File System Internals Manual (published by Digital Press, but potentially out of print), and see: http://pdp-11.trailing-edge.com/www/ods1.txt http://www.openvms.compaq.com/freeware/freeware50/ods2/ ------------------------------------------------------------ MGMT4. How do I extract the contents of a PCSI kit? A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits. If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command: $ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCE A PCSI kit file has a file specification of the following form: DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI In this example, "FORTRAN" is the "prodname". PCSI will expand the kit files into the directory you specify and subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the eventual destination of files found there. Most of the actual product files (images, etc.) will be in the subdirectories. In the top-level directory will be a file with the file type PCSI$DESCRIPTION that specifies where various files should go. For more details, see the POLYCENTER Software Installation Developer's Guide for OpenVMS, which can be found in the OpenVMS documentation on the Consolidated Online Documentation CD-ROM. ------------------------------------------------------------ MGMT5. I've forgotten the SYSTEM password - what can I do? If you need to break into an OpenVMS system because you do not have access to any privileged passwords, such as the password to the SYSTEM username, you will need physical access to the system console, and you will need to perform a conversational reboot. Here are the steps: 1. Halt the system. Exactly how this is done depends on the specific system model: Depending on the model, this can involve pressing the <HALT> button, entering <CTRL/P> on the console, or pressing the <BREAK> key on the console. 2. At the >>> console prompt, use a console command to boot into the SYSBOOT> utility. (SYSBOOT allows conversational changes to system parameters.) The syntax for the conversational bootstrap varies by system model -- this typically involves specifying a flag of 1, for example: VAX: B/1 B/R5:1 @GENBOO Alpha: b -flags 0,1 If your system has a non-zero system root (such as root SYSE, shown here), you will have to use a console command such as the following: VAX: B/E0000001 B/R5:E0000001 @<console media procedure name varies widely> Alpha: b -flags e,1 If your system has a hardware password (various systems support a password that prevents unauthorized access to the console), you will need to know theis password and will need to enter it using the LOGIN command at the console. If you get an "Inv Cmd" error trying to perform a conversational bootstrap, and you do not have the hardware console password for the console LOGIN command, you are stuck -- you will need to call for hardware service in order to reset the hardware console password. The syntax used for the console password mechanism varies. 3. Once at the SYSBOOT> prompt, request that OpenVMS read the system startup commands directly from the system console, that the window system (if any) not be started, and that OpenVMS not record these particular parameter changes for subsequent system reboots: SET/STARTUP OPA0: SET WINDOW_SYSTEM 0 SET WRITESYSPARAMS 0 CONTINUE 4. At the $ prompt, the system will now be accepting startup commands directly from the console. Type the following two DCL commands: SPAWN @SYS$SYSTEM:STARTUP The result of these two commands will be the normal system startup, but you will be left logged in on the console, running under a privileged username. Without the use of the SPAWN command, you would be logged out when the startup completes. If necessary, you can skip the invocation of the system startup temporarily, and perform tasks such as egistering license PAKs or various other "single-user" maintenance operations. 5. Use the following commands to reset the SYSTEM password: SET DEFAULT SYS$SYSTEM: ! or wherever SYSUAF.DAT resides RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT These steps will change the SYSTEM password to the specified new newpassword password value. Reboot the system normally -- the SYSTEM password should now be set to the value you specified in Step 5. Some people will suggest a method using the UAFALTERNATE SYSGEN parameter. This approach is not always reliable and is not recommended, as there can easily be an alternate user authorization file configured on the system. For further information on emergency startup and shutdown, as well as for the official OpenVMS documentation on how to change the SYSTEM password from the console in an emergency, please see the OpenVMS System Manager's Manual in the OpenVMS documentation set. You can also use the conversational bootstrap technique shown above (the steps through Step 3) to alter various system parameters. At the SYSBOOT> prompt, you can enter new parameters values: SHOW MAXPROCESSCNT SET . 64 CONTINUE The "." is a shorthand notation used for the last parameter examined. [Stephen Hoffman] ------------------------------------------------------------ MGMT6. How do I connect a PostScript printer via TCP/IP? Using UCX as the TCP/IP stack, it is possible to setup queues using the UCX$TELNETSYM in order to print to postscript printers. This assumes however that the printer itself can convert whatever is passed to it into something intelligible. As an example, if the printer has an IP address of 123.456.789.101 and jobs should be passed to port 9100 then : $ INITIALIZE/QUEUE/ON="123.456.789.101:9100"/PROCESSOR=UCX$TELNETSYM - my_ip_queue The port number of 9100 is typical of HP JetDirect cards but may be different for other manufacturers cards. As a better alternative, DCPS Version 1.4 and later support IP queues using either Compaq TCP/IP Services for OpenVMS software or Cisco Multinet for OpenVMS. The usage of this type of interface is documented in the Release Notes and the DCPS$STARTUP.TEMPLATE file. For general and additional (non-Postscript) IP printing information, see: http://www.openvms.compaq.com/wizard/ topic (1020) http://www.wotsit.org/ [Steve Reece] [Arne Vajh°j] ------------------------------------------------------------ MGMT7 moved to TIME10. ------------------------------------------------------------ MGMT8 removed. superceded by TIME section ------------------------------------------------------------ MGMT9. How do I change the node name of an OpenVMS System? The first step is to get a BACKUP of the system disk before making any changes -- use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk. Changing the node name involves a number of steps -- the node name tends to be imbedded in a number of different data files around the system. Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.) Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.) Modify the IP node name. (The TCP/IP Services tool is UCX$CONFIG prior to V5.0, and is TCPIP$CONFIG in V5.0 and later releases.) Modify the host node name on the various queues in the queue database. (each queue has a host name, and it defaults to the SCS node name of the queue's host system. See the command INIT/QUEUE/ON=node for information.) Modify the node name saved in any application databases, or any local node-conditional operations present in the site-specific system startup, etc. (SEARCH for the node name, specifying all types of files.) Rename the SYS$NODE_oldnodename rightslist identifier to match the new name. (Do not change the binary value of this identifier.) Reset any license PAKs that are restricted to the old node name to the new node name. If the node name is part of a disk volume label, see MGMT19. Reboot the node or -- if in a VMScluster -- reboot the whole VMScluster. (This tends to catch any errors immediately.) There are likely a few other areas where the nodename will be stored. If the system is configured in a VMScluster and you change *either* the SCSNODE or the SCSSYSTEMID -- but *not* both values -- then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.) To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478) I expect I may have missed one or two configuration tools (or more!) that are needed at your site -- the node name tends to get stored all over the place, in layered products, and in local software... [Stephen Hoffman] ------------------------------------------------------------ MGMT10. What is the correct value for EXPECTED_VOTES in a VMScluster? The VMScluster connection manager uses the concept of votes and quorum to prevent disk and memory data corruptions -- when sufficient votes are present for quorum, then access to resources is permitted. When sufficient votes are not present, user activity will be blocked. The act of blocking user activity is called a "quorum hang", and is better thought of as a "user data integrity interlock". This mechanism is designed to prevent a partitioned VMScluster, and the resultant massive disk data corruptions. On each OpenVMS node in a VMScluster, one sets two values in SYSGEN: VOTES, and EXPECTED_VOTES. The former is how many votes the node contributes to the VMScluster. The latter is the total number of votes expected when the full VMScluster is bootstrapped. Some sites erroneously attempt to set EXPECTED_VOTES too low, believing this will allow when only a subset of voting nodes are present in a VMScluster. It does not. Further, an erroneous setting in EXPECTED_VOTES is automatically corrected once VMScluster connections to other nodes are established, meaning user data is at risk of severe corruption only during the initial system bootstrap. One can operate a VMScluster with one, two, or many voting nodes. With any but the two-node configuration, keeping a subset of the nodes active when some nodes fail can be easily configured. With the two-node configuration, one must use a primary-secondary configuration (where the primary has all the votes), a peer configuration (where when either node is down, the other hangs), or (preferable) a shared quorum disk. Use of a quorum disk does slow down VMScluster transitions somewhat -- the addition of a third voting node that contributes the vote(s) that would be assigned to the quorum disk makes for faster transitions -- but the use of a quorum disk does mean that either node in a two-node VMScluster configuration can operate when the other node is down. If you choose to use a quoum disk, a QUORUM.DAT file will be automatically created when OpenVMS first boots and when a quorum disk is specified -- well, the QUORUM.DAT file will be created when OpenVMS is booted without also needing the votes from the quorum disk. In a two-node VMScluster with a shared storage interconnect, typically each node has one vote, and the quorum disk also has one vote. EXPECTED_VOTES is set to three. Using a quorum disk on a non-shared interconnect is unnecessary -- the use of a quorum disk does not provide any value, and the votes assigned to the quorum disk should be assigned to the OpenVMS host serving access to the disk. For information on quorum hangs, see the OpenVMS documentation. For information on changing the EXPECTED_VOTES value on a running system, see the SET CLUSTER/EXPECTED_VOTES command, and see the OpenVMS system console documentation for the processor-specific console commands used to trigger the IPC (Interrrupt Priority Level %x0C; IPL C) handler. The IPC handler can be used to clear a quorum hang, and to clear disk mount verification hangs. The quorum scheme is a set of "blade guards" deliberately implemented by OpenVMS Engineering to provide data integrity -- remove these blade guards at your peril. OpenVMS Engineering did not implement the quorum mechanism to make your life more difficult -- quorum was implemented to keep your data from getting scrambled. [Stephen Hoffman] ------------------------------------------------------------ MGMT11. Why doesn't OpenVMS see the new memory I just added? When adding memory to an OpenVMS system, one should check for an existing definition of the PHYSICALPAGES (OpenVMS VAX) or PHYSICAL_MEMORY (OpenVMS Alpha) parameter in the SYS$SYSTEM:MODPARAMS.DAT parameter database, use a text editor to reset the value in the file to the new correct value as required, and then perform the following command: $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK This AUTOGEN command will reset various system parameters based on recent system usage (FEEDBACK), and it will reset the value for the PHYSICALPAGES parameter to the new value. It will also reboot the OpenVMS system. PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately lower the amount of memory available for use by OpenVMS. This ability can be useful in a few specific circumstances, such as testing the behaviour of an application in a system environment with a particular (lower) amount of system memory available. PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1 (on OpenVMS Alpha) or (better and simpler) the entry can be removed from the MODPARAMS.DAT file, to indicate that all available memory should be used. [Stephen Hoffman] ------------------------------------------------------------ MGMT12. How do I write a BACKUP saveset to a remote tape? How to do this correctly was described at DECUS a long time ago. On the node with the tape drive, create SAVE-SET.FDL: RECORD FORMAT fixed SIZE 8192 Then create BACKUP_SERVER.COM: $ ! $ ! BACKUP_SERVER.COM - provide remote tape service for BACKUP. $ ! $ set noon $ set rms/network=16 $ allocate mka500 tapedev $ mount/nounload/over:id/block=8192/assist tapedev $ convert/fdl=SAVE-SET sys$net tapedev:save-set. $ dismount/unload tapedev $ stop/id=0 On the node where you want to do the backup, use the DCL command: $ backup - srcfilespec - node"user pwd"::"task=backup_server"/block=8192/save The only thing that doesn't completely work here is multi-reel savesets. Since the tape is being written through RMS and the magtape ACP, BACKUP won't see the reel switch and will split an XOR group across the reel boundary. As far as I remember, BACKUP will be willing to read such a multi-reel save set (directly, not over the net) since the XOR blocks are simply ignored on read, but it definitely wouldn't be able to do a recovery across the reel boundary. Unfortunately BACKUP can't read tapes over the network because the RMS file attributes on a network task access look wrong (variable length records). [Stephen Hoffman] ------------------------------------------------------------ MGMT13. Tell me about SET HOST/DUP and SET HOST/HSC The OpenVMS DCL commands SET HOST/DUP and SET HOST/HSC are used to connect to storage controllers via the Diagnostics and Utility Protocol (DUP). These commands require that the FYDRIVER device driver be connected. This device driver connection is typically performed by adding the following command(s) into the system startup command procedure: On OpenVMS Alpha: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> IO CONNECT FYA0/NOADAPTER/DRIVER=SYS$FYDRIVER On OpenVMS VAX: $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT FYA0/NOADAPTER Alternatives to the DCL SET HOST/DUP command include the console >>> SET HOST command available on various mid- to recent-vintage VAX consoles: Access to Parameters on an Embedded DSSI controller: >>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number PARAMS Access to Directory of tools on an Embedded DSSI controller: >>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number DIRECT Access to Parameters on a KFQSA DSSI controller: >>> SHOW UQSSP ! to get port_controller_number PARAMS >>> SET HOST/DUP/UQSSP port_controller_number PARAMS These console commands are available on most MicroVAX and VAXstation 3xxx series systems, and most (all?) VAX 4xxx series systems. For further information, see the system documentation and -- on most VAX systems -- see the console HELP text. EK-410AB-MG, _DSSI VAXcluster Installation and Troubleshooting_, is a good resource for setting up a DSSI VMScluster on OpenVMS VAX nodes. (This manual predates coverage of OpenVMS Alpha systems, but gives good coverage to all hardware and software aspects of setting up a DSSI-based VMScluster -- and most of the concepts covered are directly applicable to OpenVMS Alpha systems. This manual specifically covers the hardware, which is something not covered by the standard OpenVMS VMScluster documentation.) Also see MGMT58. [Stephen Hoffman] ------------------------------------------------------------ MGMT14. How do I install DECnet Phase IV on VMS 7.1? On OpenVMS V7.1, all DECnet binaries were relocated into separate installation kits -- you can selectively install the appropriate network: DECnet-Plus (formerly known as DECnet OSI), DECnet Phase IV, and Compaq TCP/IP Services (often known as UCX). On OpenVMS versions prior to V7.1, DECnet Phase IV was integrated, and there was no installation question. You had to install the DECnet-Plus (DECnet OSI) package on the system, after the OpenVMS upgrade or installation completed. During an OpenVMS V7.1 installation or upgrade, the installation procedure will query you to learn if DECnet-Plus should be installed. If you are upgrading to V7.1 from an earlier release or are installing V7.1 from a distribution kit, simply answer "NO" to the question asking you if you want DECnet-Plus. Then -- after the OpenVMS upgrade or installation completes -- use the PCSI PRODUCT INSTALL command to install the DECnet Phase IV binaries from the kit provided on the OpenVMS software distribution kit. If you already have DECnet-Plus installed and wish to revert, you must reconfigure OpenVMS. You cannot reconfigure the "live" system, hence you must reboot the system using the V7.1 distribution CD-ROM. Then select the DCL ($$$ prompt) option. Then issue the commands: $$$ DEFINE/SYSTEM PCSI$SYSDEVICE DKA0: $$$ DEFINE/SYSTEM PCSI$SPECIFIC DKA0:[SYS0.] $$$ PRODUCT RECONFIGURE VMS /REMOTE/SOURCE=DKA0:[VMS$COMMON] The above commands assume that the target system device and system root are "DKA0:[SYS0.]". Replace this with the actual target device and root, as appropriate. The RECONFIGURE command will then issue a series of prompts. You will want to reconfigure DECnet-Plus off the system, obviously. You will then want to use the PCSI command PRODUCT INSTALL to install the DECnet Phase IV kit from the OpenVMS distribution media. Information on DECnet support, and on the kit names, is included in the OpenVMS V7.1 installation and upgrade documentation. [Stephen Hoffman] ------------------------------------------------------------ MGMT15. How do I change the text in a user's UIC identifier? The text translations of the numeric User Identification Code (UIC) are based on identifiers present in the OpenVMS rightslist. Documentation on this area is included in the _Guide to OpenVMS System Security_ manual. To control the identifiers shown for a user's UIC, you use AUTHORIZE. Each user has an associated group identifier, and an identifier specific to the user. And each user should have a unique UIC. To alter the text of a user or group identifier, use commands such as: $ RUN SYS$SYSTEM:AUTHORIZE UAF> rename/ident oldgroupid newgroupid UAF> rename/ident olduserid newuserid If you should find yourself missing an identifier for a particular user, you can add one for the user's UIC using a command such as: UAF> add/ident/value=uic=[group,user] newuserid The UIC user identifier text is assigned when the username is created, and is the text of the username. The UIC group group identifier is assigned when the first username is created in the UIC group, and the text is based on the account name specified for the first user created in the group. The value of this identifier is [groupnumber, 177777]. To add a missing group identifier, use an asterisk as follows: UAF> add/ident/value=uic=[group,*] newgroupid You may find cases where an identifier is missing from time to time, as there are cases where the creation of a UIC group name identifier might conflict with an existing username, or a user identifier might conflict with an existing group identifier. When these conflicts arise, the AUTHORIZE utility will not create the conflicting group and/or user identifier when the username is created. You can can add and remove user-specified identifiers, but you should avoid changing the numeric values associated with any existing identifiers. You should also avoid reusing UICs or identifiers when you add new users, as any existing identifiers that might be present on objects in the system from the old user will grant the same access to the new user. Please see the security manual for details. ------------------------------------------------------------ MGMT16. What are the OpenVMS version upgrade paths? Note: See "OpenVMS Alpha Terminology" section, below. OpenVMS Alpha release upgrade (or update) paths: From V1.0, one can upgrade to V1.5. From V1.5, or V1.5-1H1, one can upgrade to V6.1. From V6.1, one can upgrade to V6.2. From V6.1, or V6.2, one can upgrade to V7.0. From V6.1, V6.2, V6.2-1H(1,2,3), or V7.0, one can upgrade to V7.1. From V6.2, one can update to V6.2-1H1, V6.2-1H2, or V6.2-1H3. From V6.2, V6.2-1H(1,2,3), V7.1, V7.1-1H(1,2), or V7.2, to V7.2-1 From V6.2, ... or V7.2, to V7.2-1H1, to 7.3 From V7.1, one can update to V7.1-1H(1,2), ... to V7.2-1H1, to 7.3 Some typical OpenVMS Alpha upgrade (or update) paths are: V1.0 -> V1.5 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3) V1.5-1H1 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3) V6.2 -> V6.2-1H3 V6.2 -> V7.2-1 V6.2 -> V7.3 V6.2-1H(1,2,3) -> V7.1 V6.2-1H(1,2,3) -> V7.2-1 V7.1 -> V7.1-2 V7.1 -> V7.2-1 V7.1-1H(1,2) -> V7.1-2 V7.1-1H(1,2) -> V7.2-1 V7.2 -> V7.2-1H1 V7.2 -> V7.3 Note that OpenVMS Alpha V7.0 does not include support for hardware and/or configurations first supported in OpenVMS Alpha V6.2-1H1, V6.2-1H2, or V6.2-1H3; one must upgrade to OpenVMS VAX V7.1. One cannot update directly to a V6.2-1Hx Limited Hardware Release (LHR) from any release prior to the baseline V6.2 release. The same prohibition holds for performing updates directly to V7.1-1Hx from any release prior to V7.1 -- this is not supported, and does not produce the expected results. The LHR kits can, however, be directly booted and can be directly installed, without regard to any operating system that might be present on the target disk. OpenVMS Alpha updates for LHRs (through V7.1-1Hx) require the use of VMSINSTAL for the update. These LHR releases use PCSI for the installation, but not for the update. Non-LHR releases use PCSI for installs and upgrades. OpenVMS Alpha V7.1-2 and later use PCSI for LHRs and for OpenVMS upgrades and for all OpenVMS ECO kit installations. VMSINSTAL OpenVMS ECO kits are not used on OpenVMS Alpha V7.1-2 and later. Prior to V7.1-2, VMSINSTAL-based ECO kits are used for OpenVMS. OpenVMS VAX release upgrade paths: From V5.0 through V5.4-3 inclusive, one can upgrade to V5.5. From V5.5, V5.5-1, or V5.5-2HW, one can upgrade to V5.5-2. From V5.5, V5.5-1, or V5.5-2, one can upgrade to V6.0. From V5.5-2, V5.5-2H4, or V6.0, one can upgrade to V6.1. From V6.0, or V6.1, one can upgrade to V6.2. From V6.1, or V6.2, one can upgrade to V7.0. From V6.1, V6.2, or V7.0, one can upgrade to V7.1. From V6.1, one can upgrade to V7.3 (with VAXBACK ECO for V6.1). Some typical OpenVMS VAX upgrade paths are: V5.x -> V5.5 -> V6.0 -> V6.2 -> (V7.1, V7.2, V7.3) V5.5-2HW -> V5.5-2 V5.5-2, or V5.5-2H4 -> V6.1 -> (V6.2, V7.0, or V7.1) V6.1 -> V6.1 with VAXBACK ECO -> (V7.2, V7.3) V6.2 -> V7.2 V6.2 -> V7.3 Note that OpenVMS VAX V6.0 does not include support for hardware and/or configurations first added in OpenVMS VAX V5.5-2H4, one must upgrade to OpenVMS VAX V6.1. Note that OpenVMS VAX V5.5-2HW is a pre-release version of V5.5-2. Any system running it should be upgraded to V5.5-2, or later. If you attempt a direct upgrade from OpenVMS VAX V6.1 to V7.2 or later without having first applied the VAXBACK ECO kit to your V6.1 system, you will receive an error message: %BACKUP-E-INVRECTYP, invalid record type in save set and the upgrade will fail. Acquire and apply the VAXBACK ECO kit for OpenVMS VAX V6.1. OpenVMS VAX V6.2 and later do not require an application of an ECO for an upgrade to V7.2 and later. OpenVMS Cluster Rolling Upgrades: Rolling Upgrades require multiple system disks. Rolling upgrades permit the OpenVMS Cluster to remain available while individual systems are being upgraded to a new OpenVMS release. OpenVMS Cluster rolling upgrades for both OpenVMS VAX and OpenVMS Alpha may (will) have different, or additional upgrade requirements, and have requirements around which versions of OpenVMS can coexist in a OpenVMS Cluster than what is listed here. See the _OpenVMS <platform> Version <Version> Upgrade and Installation Manual_, and the OpenVMS Software Product Descriptions http://www.compaq.com/info/spd/ OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx. for further details on the rolling upgrade, and for support information. The documentation for older releases of OpenVMS VAX includes various platform-specific manuals, manuals that include instructions that are specific to installing and upgrading on the platform. OpenVMS and Layered Products -- Support Information: For information on Prior Version Support (PVS) and Mature Product Support (including information on support end dates for OpenVMS and various layered products), please see: http://www.compaq.com/services/software/ss_mature.html http://www.compaq.com/services/software/ss_pvs_se_amap.html http://www.compaq.com/services/software/ss_mps_pvs_eur.html For information on supported versions of layered products, and minimum required layered product versions, see: http://www.openvms.compaq.com/openvms/os/swroll/index.html For information on the release history of OpenVMS, including information on the code names of various releases and the major features: http://www.openvms.compaq.com/openvms/os/openvms-release-history.html Additional release history information, as well as a variety of other trivia, is available in the VAX 20th anniversary book: http://www.openvms.compaq.com/openvms/20th/vmsbook.pdf OpenVMS Alpha Terminology: update: Typically used for Limited Hardware Releases (LHR) releases. Performed via VMSINSTAL. Applies only to the OpenVMS release that the LHR is based on, or to an intermediate LHR. (eg: V7.1-1H2 applies only to V7.1-1H1 and to V7.1, not to any other releases.) LHRs within a series are cumulative, containing all files and features of previous LHRs in the same series. upgrade: Performed via PCSI. Upgrades can typically be applied to a release-specific (and documented) range of prior OpenVMS releases. install: Performed via PCSI. With an installation, no existing version of the operating system is assumed present, nor are any files from any copy of the operating system might be present preserved, and the entire contents of the target disk are destroyed via a disk initialization. preserve: Performed via PCSI. Otherwise similar to an installation, this option skips the disk reinitialization. User files on the target disk are preserved. Any existing operating system files on the target disk are clobbered. LHR: Limited Hardware Release. LHRs are specific to and are targeted at new hardware configurations, and are not shipped to customers with support contracts. At least one LHR kit must be specifically acquired when purchasing new hardware, new hardware that is not (yet) supported by any mainline (non-LHR) release. LHRs have an "H" in the OpenVMS version string, indicating a "Hardware" release. For minimum OpenVMS versions for various platforms, see VMS13. ------------------------------------------------------------ MGMT17. Why do I have negative number in the pagefile reservable pages? Seeing a negative number in the reservable pages portion of the SHOW MEMORY/FULL command can be normal and expected, and is (even) documented behaviour. A pagefile with a negative number of reservable pages is overcommitted, which is generally goodness assuming that every process with reserved pages does not try to occupy all of the reserved pagefile space at the same time. To understand how the pagefile reservation process works, think about how a traditional bank operates when accepting customer deposits and making loans. It's the same idea with the pagefile space. There is less money in the bank vault than the total deposits, because much of the money has been loaned out to other customers of the bank. And the behaviour parallels that of the pagefile down to the problems that a "run on the bank" can cause for banking customers. (Though there is no deposit insurance available for pagefile users.) If all of the running applications try to use the reserved space, the system manager will need to enlarge the pagefile or add one or more additional pagefules. To determine if the pagefile is excessively overcommitted, watch for "double overcommitment" -- when the reservable space approaches the negatation of the available total space -- and watch that the total amount of free space available in the pagefile remains adequate. If either of these situations arises, additional pagefile storage is required. Additional pagefile information: Additional pagefiles can typically be created and connected on a running OpenVMS system. New processes and new applications will tend to use the new pagefile, and existing applications can be restarted to migrate out of the more congested pagefiles. Pagefiles are generally named PAGEFILE.SYS, and multiple pagefiles are generally configured on separate disk spindles to spread the paging I/O load across the available disk storage. When multiple pagefiles are present on recent OpenVMS versions, each pagefile file should be configured to be approximately the same total size as the other pagefiles. For additional information on pagefile operations and related commands, see the system management and performance management manuals in the OpenVMS documentation set. [Stephen Hoffman] ------------------------------------------------------------ MGMT18. Do I have to update layered products when updating OpenVMS? The Software Public Rollout Reports for OpenVMS list the current and future availability of Compaq's software products shipping on the Software Products Library kits (CDROM consolidations) for OpenVMS Alpha and OpenVMS VAX. Specifically, the required minimum versions for product support are listed. Comprehensive Public Rollout Information, listing previous product versions as well as currently shipping versions, has been compiled into a separate set of reports. The product information is grouped to show Operating System support. You may or may not be able to use older versions of local applications, third-party products, and various Compaq layered products with more recent versions of OpenVMS. User-mode code is expected to be upward compatible. Code executing in a privileged processor mode -- typically either executive or kernel mode -- may or may not be compatible with more recent OpenVMS versions. These reports are updated monthly. Please see: http://www.openvms.compaq.com/openvms/os/swroll/index.html [Stephen Hoffman] ------------------------------------------------------------ MGMT19. How do I change the volume label of a disk? 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: $ PRODUCT REGISTER VOLUME <old-label> <device> To reset the label information stored in the PCSI database to reflect the new disk volume label. 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. Remount the disk appropriately. [Stephen Hoffman] [John E. Malmberg] ------------------------------------------------------------ MGMT20. How do I fix a corrupt BACKUP saveset? BACKUP savesets can be corrupted by FTP file transfers and by tools such as zip (particularly when the zip tool has not been asked to save and restore OpenVMS file attributes or when it does not support OpenVMS file attributes), as well as via other means of corruptions. If you have problems with the BACKUP savesets after unzipping them or after an FTP file transfer, you can try restoring the appropriate saveset attributes using the tool: $ @RESET_BACKUP_SAVESET_ATTRIBUTES.COM This tool is available on the OpenVMS Freeware (in the [000TOOLS] directory). The Freeware is available at various sites -- see the Freeware location listings elsewhere in the FAQ -- and other similar tools are also available from various sources. In various cases, a SET FILE/ATTRIBUTES command can also be used. As the parameters of this command must be varied as the target BACKUP saveset attributes vary, this approach is not recommended. Also see the "SITE VMS", /FDL, and various other file-attributes options available in various FTP tools. (Not all available FTP tools support any or all of these options.) Browser downloads (via FTP) and incorrect (binary or ascii FTP transfer modes) are notorious for causing RMS file corruptions and particularly BACKUP saveset corruptions. You can sometimes help encourage the browser to select the correct FTP transfer type code (via RFC1738): ftp://host/urlname.ext;type=i ! request ftp image/binary transfer ftp://host/urlname.ext;type=a ! request ftp ascii/text transfer You can also often configure the particular web browser to choose the appropriate transfer mode by default, based on the particular file extensions, using a customization menu available in most web browsers. You can select that the specific file extentions involved use the FTP binary transfer mode, which will reduce the number of corruptions seen. [Stephen Hoffman] ------------------------------------------------------------ MGMT21. How can I set up a shared directory? To set up a shared directory -- where all files created in the directory are accessable 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 AUTHORIZE: 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. ------------------------------------------------------------ MGMT22 relocated to SUPP3 ------------------------------------------------------------ MGMT23. 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.openvms.compaq.com/wizard/ There are a variety of discussions of this and of related printing topics in the Ask The Wizard area. Also see MGMT51. [Stephen Hoffman] ------------------------------------------------------------ MGMT24. Configure ELSA GLoria Synergy or PowerStorm 300/350 graphics? 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. 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-1H1 and later should directly support the controller. Additional information: http://www.openvms.compaq.com/wizard/ topics (3419), (5448). ---- PowerStorm 300 : PBXGD-AC PowerStorm 350 : 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 ---- PowerStorm 3D30, PowerStorm 4D20: http://www.openvms.compaq.com/wizard/ topic (2041). ---- Support for the ELSA GLoria Synergy and the PowerStorm 300 and 350 controllers is expected to be integrated in the OpenVMS Alpha V7.3 and later releases. [Stephen Hoffman] ------------------------------------------------------------ MGMT25. How do I acquire OpenVMS patches, fixes, and ECOs? You can acquire and download kits containing OpenVMS fixes (ECOs) for various releases via: http://search.service.digital.com/ ftp://ftp.support.compaq.com/public/vms/ (formerly ftp://ftp.service.digital.com/public/vms/) http://ftp.digital.com.au/pub/ecoinfo/ http://ftp/digital.com.au/cgi-bin/grep/ You can subscribe to an email notification list at: http://www.support.compaq.com/patches/mailing-list.shtml A quarterly distribution is also available on CD-ROM: QT-3CQAA-C8 OpenVMS Alpha QT-3CRAA-C8 OpenVMS VAX 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 Compaq 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: ftp://ftp.service.digital.com/public/vms/axp/... ftp://ftp.service.digital.com/public/vms/vax/... 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 MGMT46 for information on ECO kit checksums. [Stephen Hoffman] ------------------------------------------------------------ MGMT26. How do I rename a DSSI disk (or tape?) If you want to renumber or rename DSSI disks or DSSI tapes, it's easy -- if you know the secret incantation... From OpenVMS: $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT FYA0/NOADAPTER SYSGEN> ^Z $ SET HOST/DUP/SERV=MSCP$DUP/TASK=PARAMS <DSSI-NODE-NAME> ... PARAMS> STAT CONF <The software version is normally near the top of the display.> PARAMS> EXIT ... From the console on most 3000- and 4000-class VAX system consoles... (Obviously, the system must be halted for these commands...) Integrated DSSI: >>> SET HOST/DUP/DSSI[/BUS:[0:1]] dssi_node_number PARAMS KFQSA: >>> SET HOST/DUP/UQSSP port_controller_number PARAMS For information on how to get out into the PARAMS subsystem, also see the >>> HELP at the console prompt for the SET HOST syntax, or see the HELP on SET HOST /DUP (once you've connected FYDRIVER under OpenVMS). Once you are out into the PARAMS subsystem, you can use the FORCEUNI option to force the use of the UNITNUM value and then set a unique UNITNUM inside each DSSI ISE -- this causes each DSSI ISE to use the specfied unit number and not use the DSSI node as the unit number. Other parameters of interest are NODENAME and ALLCLASS, the node name and the (disk or tape) cluster allocation class. Ensure that all disk unit numbers used within an OpenVMS Cluster disk allocation class are unique, and all tape unit numbers used within an OpenVMS Cluster tape allocation class are also unique. [Stephen Hoffman] ------------------------------------------------------------ MGMT27. 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: 0. 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 1. Stop the queue manager $STOP/QUEUE/MANAGER/CLUSTER 2. Backup the .QMAN$QUEUES and .QMAN$JOURNAL files from the present location for safety. $ backup SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* DISK:[DIR] 3. 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] 4. Copy the .QMAN$QUEUES and .QMAN$JOURNAL files to the new directory $ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* fast_disk:[qman] 5. Delete the old queue database. $DELETE SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* 6. Restart the queue manager pointing to the new location $START/QUEUE/MANAGER fast_disk:[qman] [Dave Sweeney] ------------------------------------------------------------ MGMT28. How do I set a default IP route or gateway on OpenVMS? If you have TCP/IP Services, then use the command: For TCP/IP Services V5.0 and later: $ TCPIP SET ROUTE/GATE=x.x.x.x/DEFAULT/PERMANENT For earlier TCP/IP Services versions: $ UCX SET ROUTE/GATE=x.x.x.x/DEFAULT/PERMANENT ------------------------------------------------------------ MGMT29 relocated to ALPHA21 ------------------------------------------------------------ MGMT30. How do I delete an undeletable/unstoppable (RWAST) process? "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 relevent 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 process quota recommendations for operator BACKUP accounts. 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 it 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... [Stephen Hoffman] ------------------------------------------------------------ MGMT31. 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're 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<cr> ! output on VAX 1 error 00010001:80D9C6C8/00000001 0<cr> ! output on Alpha 1 error Now type the command EXIT and a carriage return. [Brian Schenkenberger] ------------------------------------------------------------ MGMT32. 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" ------------------------------------------------------------ MGMT33. 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: o applications often hold SYSUAF or RIGHTSLIST open, meaning a system reboot is often the best way to activate new files. o the meanings of the RESTRICTED and CAPTIVE flags settings on the UAF entries have changed over time. o 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. o 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: http://www.openvms.compaq.com/wizard/ topics (203), (767), (915). [Stephen Hoffman] ------------------------------------------------------------ MGMT34. 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. 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. 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. ------------------------------------------------------------ MGMT35. Why isn't BACKUP/SINCE=BACKUP working? If you are seeing more files backed up than previously, you are seeing the result of a change that was made to ensure BACKUP can perform an incrementation restoration of the files. In particular, if a directory file modification date changes, all files underneath it are included in the BACKUP, in order to permit incremental restoration should a directory file get renamed. Why has OpenVMS gone through the agony of this change? When a directory is renamed, the modified date is changed. When the restoration needs to restore the directory and its contents, and the restoration should not result in the restoration of the older directory name when a series of incremental BACKUPs are restored. Thus an incremental BACKUP operation needs to pick up all of the changes. What can you do to improve BACKUP performance? Use the documented commands in the manual for performing incremental BACKUPs. Use the documented incremental procedures. Don't try to use incremental commands in a non-incremental context. Also consider understanding and then using /NOALIAS, which will likely be a bigger win than will anything to do with the incremental BACKUPs, particularly on system disks and any other disks with directory aliases. Can you get the old BACKUP behaviour back? Yes, please see the /NOINCREMENTAL qualifier available on recent OpenVMS versions (and ECO kits). Use of this qualifier informs BACKUP that you are aware of the limitations of the old BACKUP behaviour around incremental disk restorations. Consider performing an incremental restoration, to test the procedures. Attempting this is how we found out about the problem that was latent with the old scheme -- the old incremental BACKUP scheme would have missed restoring any files under a renamed directory. Hence the change. See the OpenVMS V6.2 release notes for additional details. ------------------------------------------------------------ MGMT36. How can I set up reverse telnet (like reverse LAT)? Though it may seem obvious, Telnet and LAT are quite different -- with differing capabilities and design goals. Please see the documentation around the TCP/IP Services for OpenVMS TELNET command CREATE_SESSION. This command is the equivilent of the operations performed in LTLOAD.COM or LAT$SYSTARTUP.COM. There is no TELNET equivilent to the sys$qio[w] control interface for LTDRIVER (as documented in the I/O User's Reference Manual) available, though standard sys$qio[w] calls referencing the created TN device would likely operate as expected. ------------------------------------------------------------ MGMT37. Do I need a PAK for the DECevent (Compaq Analyze) tool? DECevent and Compaq Analyze are avalable 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 DECevent FAQ for additional details: http://www.support.compaq.com/svctools/decevent/DECevent_FAQ.html The current version of the DECevent (Compaq Analyze) tool can be downloaded from: http://www.support.compaq.com/svctools/st-download.html ------------------------------------------------------------ MGMT38. INITIALIZE ACCVIO and ANSI tape label support? 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. [Hoffman, Dachtera] ------------------------------------------------------------ MGMT39. 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. ------------------------------------------------------------ MGMT40. How can I prevent a serial terminal line from initiating a login? In SYSTARTUP_VMS.COM, issue the command: SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu: This will prevent any unsolicited terminal input on ddcu:, and this unsolicited input is what triggers JOB_CONTROL to start up LOGINOUT on the terminal. Once LOGINOUT starts up on the serial line, you can see interesting behaviour (eg: audits, process creations, etc) as LOGINOUT tries to "chat" with whatever device is hooked onto the remote end of the serial terminal line. ------------------------------------------------------------ MGMT41. How does PCSI use the image BUILD_IDENT field? The (undocumented) build ident field in an OpenVMS Alpha image header is 16 bytes long, and is used as a counted string of 0-15 characters (ie, a an .ASCIC string with count in byte 0) and was originally introduced to provide information for use by VMSINSTAL patch kits to determine whether an image should be replaced or not. Starting with OpenVMS Alpha V7.1-2, OpenVMS Engineering uses the PCSI utility to package and install ECO kits for OpenVMS. PCSI uses the generation attribute (a 32-bit unsigned integer) specified for files in the product description file (PDF) of a PCSI kit as the basis for performing file conflict detection and resolution. When a product is installed, PCSI modifies the build ident field of Alpha image headers to store an encoded form of the generation number. It also looks at the build ident field of previously installed images to obtain the generation information for those files as input to the file conflict processing algorithm. (Only images have this field, obviously.) PCSI interprets the build ident field of a previously installed image as follows: - if the string length is 15, the 5th character is a hyphen, and the last ten characters are a ten digit number with leading zeros, then the last ten characters are treated as a valid generation number. - for V7.1-2 through V7.2-1, inclusive, if the above test fails, the information is obtained from the PCSI product database. - in releases after V7.2-1 and with current PCSI ECO kits, if the above test fails, an invalid generation number is treated as 0000000000 so that the ECO kit will simply replace the image rather than assuming á the PCSI database is in error. So, what will you see in the image identification displayed via the ANALYZE/IMAGE command? For an image that has been built as part of an OpenVMS Engineering system build, you will generally see a build ID string in the format "X6TE-SSB-0000" -- X6TE is the build number for the OpenVMS Alpha V7.2-1 release. This id format is used within the OpenVMS system build, and can generally only be seen associated with images that have not yet been processed via PCSI. During the installation of V7.2-1, PCSI will modify the image header to have a build ident string of "X6TE-0050120000". During installation of an ECO kit containing this image with a generation number of 50130052, for example, PCSI would determine that 50130052 is greater than 50120000, and will replace the existing image on the target disk with the version of the image included in the ECO kit. ------------------------------------------------------------ MGMT42. How to configure allocation classes and Multi-Path SCSI? The HSZ allocation class is applied to devices, starting with OpenVMS V7.2. It is considered a port allocation class (PAC), and all device names with a PAC have their controller letter forced to "A". (You might infer from the the text in the "Guidelines for OpenVMS Cluster Configurations" that this is something you have to do, though OpenVMS will thoughtfully handle this renaming for you.) You can force the device names back to DKB by setting the HSZ allocation class to zero, and setting the PKB PAC to -1. This will use the host allocation class, and will leave the controller letter alone (that is, the DK controller letter will be the same as the SCSI port (PK) controller). Note that this won't work if the HSZ is configured in multibus failover mode. In this case, OpenVMS requires that you use an allocation class for the HSZ. When your configuration gets even moderately complex, you must pay careful attention to how you assign the three kinds of allocation class: node, port and HSZ/HSJ, as otherwise you could wind up with device naming conflicts that can be painful to resolve. The display-able path information is for SCSI multi-path, and permits the multi-path software to distinguish between different paths to the same device. If you have two paths to $1$DKA100, for example by having two KZPBA controllers and two SCSI buses to the HSZ, you would have two UCBs in a multi-path set. The path information is used by the multi-path software to distinguish between these two UCBs. The display-able path information describes the path; in this case, the SCSI port. If port is PKB, that's the path name you get. The device name is no longer completely tied to the port name; the device name now depends on the various allocation class settings of the controller, SCSI port or node. The reason the device name's controller letter is forced to "A" when you use PACs is because a shared SCSI bus may be configured via different ports on the various nodes connected to the bus. The port may be PKB on one node, and PKC on the other. Rather obviously, you will want to have the shared devices use the same device names on all nodes. To establish this, you will assign the same PAC on each node, and OpenVMS will force the controller letter to be the same on each node. Simply choosing "A" was easier and more deterministic than negotiating the controller letter between the nodes, and also parallels the solution used for this situation when DSSI or SDI/STI storage was used. This information is also described in the Cluster Systems and Guidelines for OpenVMS Cluster Configurations manuals. [John Croll] ------------------------------------------------------------ MGMT43. How can I tell what software (and version) is installed? There is unfortunatly no consistent nor single way to make this determination -- this is one of the reasons that a move to PCSI installations is underway. On 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 VMSINSTAL.HISTORY on OpenVMS Alpha prior to V7.1-2, and use PRODUCT SHOW PRODUCT/FULL on OpenVMS Alpha V7.1-2 and later. On OpenVMS VAX, you can use PRODUCT SHOW PRODUCT and (for software that is installed via VMSINSTAL on V7.3 and later) in VMSINSTAL.HISTORY. For products installed on OpenVMS VAX prior to V7.3 using VMSINSTAL, there is no reliable way to determine what products have been installed. If the product provides a RELEASE_NOTES file (as many do), you can look for the list of these files via DIRECTORY SYS$HELP:*.RELEASE_NOTES. Again, this approach is NOT reliable: some kits do not provide release notes, some system managers will install only the release notes, some system managers will delete release notes, and release notes for multiple versions can be present. On most packages, you can generally use ANALYZE/IMAGE on one of the core images, looking at the image identification area. Some of the product-specific mechanisms available are: DQS DQS$VERSION logical name C CC/VERSION C++ CXX/VERSION ------------------------------------------------------------ MGMT44. Where can I get Fibre Channel Storage (SAN) information? http://www.openvms.compaq.com/openvms/fibre/index.html ------------------------------------------------------------ MGMT45. How can I split up an OpenVMS Cluster? Review the VMScluster documentation, and the System Management documentation. The following are the key points, but are likely not the only things you will need to change. OpenVMS Cluster support is directly integrated into the operating system, and there is no way to remove it. You can, however, remote site-specific tailoring that was added for a particular cluster configuration. First: Create restorable image BACKUPs of each of the current system disks. If something gets messed up, you want a way to recover, right? Create standalone BACKUP kits for the OpenVMS VAX systems, and create or acquire bootable BACKUP kits for the OpenVMS Alpha systems. Use CLUSTER_CONFIG or CLUSTER_CONFIG_LAN to remove the various system roots and to shut off boot services and VMScluster settings. Create as many architecture-specific copies of the system disks as required. Realize that the new systems will all likely be booting through root SYS0 -- if you have any system-specific files in any other roots, save them. Relocate the copies of the VMScluster common files onto each of the new system disks. Reset the console parameters and boot flags on each system for use on a standalone node. Reset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN and in MODPARAMS.DAT. Clobber the VMScluster group ID and password using SYSMAN. Reboot the systems seperately, and run AUTOGEN on each. Shut off MOP services via NCP or LANCP on the boot server nodes. Permanent seperation also requires the duplication of shared files. The following files are typically shared within a cluster: Filename: default directory (in common root) and file type: SYSUAF SYS$SYSTEM:.DAT SYSUAFALT SYS$SYSTEM:.DAT SYSALF SYS$SYSTEM:.DAT RIGHTSLIST SYS$SYSTEM:.DAT NETPROXY SYS$SYSTEM:.DAT NET$PROXY SYS$SYSTEM:.DAT NETOBJECT SYS$SYSTEM:.DAT NETNODE_REMOTE SYS$SYSTEM:.DAT QMAN$MASTER SYS$SYSTEM: (this is a set of related files) LMF$LICENSE SYS$SYSTEM:.LDB VMSMAIL_PROFILE SYS$SYSTEM:.DATA VMS$OBJECTS SYS$SYSTEM:.DAT VMS$AUDIT_SERVER SYS$MANAGER:.DAT VMS$PASSWORD_HISTORY SYS$SYSTEM:.DATA NETNODE_UPDATE SYS$MANAGER:.COM VMS$PASSWORD_POLICY SYS$LIBRARY:.EXE LAN$NODE_DATABASE SYS$SYSTEM:LAN$NODE_DATABASE.DAT Information on changing node names is included in MGMT9. ------------------------------------------------------------ MGMT46. What file checksum tools are available for OpenVMS? The undocumented DCL command CHECKSUM is the usual means, and provides a rather simple-minded checksum suitable to detect basic file corruptions. For information and an OpenVMS version of the MD5 checksum tool, see: http://www.service.digital.com/svctools/decevent/md5-instructions.html The 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 See MGMT25 for information on acquiring OpenVMS ECO (patch) kits. ------------------------------------------------------------ MGMT47. Configuring Cluster SCS for path load balancing? SCS: Systems Communication Services. The protocol used to communicate between VMSCluster systems and between OpenVMS systems and SCS-based storage controllers. (SCSI-based storage controllers do not use SCS.) PORT: A communications device, such as DSSI, CI, Ethernet or FDDI. Each CI or DSSI bus is a different local port, named PAA0, PAB0, PAC0 etc. All Ethernet and FDDI busses make up a single PEA0 port. VIRTUAL CIRCUIT: A reliable communications path established between a pair of ports. Each port in a VMScluster establishes a virtual circuit with every other port in that cluster. All systems and storage controllers establish "Virtual Circuits" to enable communications between all available pairs of ports. SYSAP: A "system application" that communicates using SCS. Each SYSAP communicates with a particular remote SYSAP. Example SYSAPs include: VMS$DISK_CL_DRIVER connects to MSCP$DISK The disk class driver is on every VMSCluster system. MSCP$DISK is on all disk controllers and all VMSCluster systems that have SYSGEN parameter MSCP_LOAD set to 1 VMS$TAPE_CL_DRIVER connects to MSCP$TAPE The tape class driver is on every VMSCluster system. MSCP$TAPE is on all tape controllers and all VMSCluster systems that have SYSGEN parameter TMSCP_LOAD set to 1 VMS$VAXCLUSTER connects to VMS$VAXCLUSTER This SYSAP contains the connection manager, which manages cluster connectivity, runs the cluster state transition algorithm, and implements the cluster quorum algorithm. This SYSAP also handles lock traffic, and various other cluster communications functions. SCS$DIR_LOOKUP connects to SCS$DIRECTORY This SYSAP is used to find SYSAPs on remote systems MSCP and TMSCP The Mass Storage Control Protocol and the Tape MSCP servers are SYSAPs that provide access to disk and tape storage, typically operating over SCS protocols. MSCP and TMSCP SYSAPs exist within OpenVMS (for OpenVMS hosts serving disks and tapes), within CI- and DSSI-based storage controllers, and within host-based MSCP- or TMSCP storage controllers. MSCP and TMSCP can be used to serve MSCP and TMSCP storage devices, and can also be used to serve SCSI and other non-MSCP/non-TMSCP storage devices. SCS CONNECTION: A SYSAP on one node establishes an SCS connection to its counterpart on another node. This connection will be on ONE AND ONLY ONE of the available virtual circuits. ---- When there are multiple virtual circuits between two OpenVMS systems it is possible for the VMS$VAXCLUSTER to VMS$VAXCLUSTER connection to use any one of these circuits. All lock traffic between the two systems will then travel on the selected virtual circuit. Each port has a "LOAD CLASS" associated with it. This load class helps to determine which virtual circuit a connection will use. If one port has a higher load class than all others then this port will be used. If two or more ports have equally high load classes then the connection will use the first of these that it finds. Normally all CI and DSSI ports have a load class of 14(hex), the Ethernet/FDDI port has a load class of A(hex). For instance, if you have multiple DSSI busses and an FDDI, the VMS$VAXCLUSTER connection will chose the DSSI bus as this path has the system disk, and thus will always be the first DSSI bus discovered when the OpenVMS system boots. To force all lock traffic off the DSSI and on to the FDDI, an adjustment to the load class value is required, or the SCS port must be disabled. Note that with PE ports, you can typically immediately re-enable the path, permitting failover to occur should congestion or a problem arise -- a running average of the path latency is checked when the virtual circuit is formed, and at periodic intervals (circa every three seconds), and when a problem with a virtual circuit arises. In the case of PEDRIVER, the driver handles load balancing among the available Ethernet and FDDI connections based on the lowest latency path available to it. Traffic will be routed through that path until an event occurs that requires a fail-over. In all OpenVMS versions, you can use the tools: SYS$EXAMPLES:LAVC$STOP_BUS SYS$EXAMPLES:LAVC$START_BUS These tools permit you to disable or enable all SCS traffic on the on the specified paths. You can also use a prefered path mechanism that tells the local MSCP disk driver (DUDRIVER) which path to a disk should be used. Generally, this is used with dual-pathed disks, forcing I/O traffic through one of the controllers instead of the other. This can be used to implement a crude form of I/O load balancing at the disk I/O level. Prior to V7.2, the prefered path feature uses the tool: SYS$EXAMPLES:PREFER.MAR In OpenVMS V7.2 and later, you can use the following DCL command: SET PREFERED_PATH The prefered path mechanism does not disable nor affect SCS operations on the non-prefered path. [Kevin Jenkins, Verell Boaen, John Croll] ------------------------------------------------------------ MGMT48. What (and where) is the OpenVMS Management Station? For information and current kits for the OpenVMS Management Station (OMS), a PC-based tool that permits you to manage an OpenVMS system, please see: http://www.openvms.compaq.com/openvms/products/argus/ ------------------------------------------------------------ MGMT49. How to determine current disk fragmentation level? The Compaq OpenVMS Disk File Optimizer (DFO) defragmentation package provides a fragmentation monitoring tool, and a DFO product authorization key (PAK) is not required for the fragmentation reporting tool: $ DEFRAG SHOW/VOLUME ddcu: The DFU tool available on the OpenVMS Freeware can generate a report on the disk fragmentation: DFU> REPORT ddcu: ------------------------------------------------------------ MGMT50. SYSBOOT-I-FILENOTLOC, Unable to locate SYS$CPU_ROUTINES? A message at the OpenVMS bootstrap such as the following: %SYSBOOT-I-FILENOTLOC, Unable to locate SYS$CPU_ROUTINES_1C02.EXE %SYSBOOT-E-LDFAIL, failed to load execlet, status = 00000910 indicates that the particular OpenVMS release does not contain support for the target platform. In this case, OpenVMS does not recognize Alpha family 1C member 02 as a supported platform. A later version of OpenVMS might support the platform, or there might be no support on any release. The execlet load failure and other similar bootstrap status values can often be decoded using either of the following techniques: $ exit %x910 %SYSTEM-W-NOSUCHFILE, no such file $ $ x = f$message(%x910) $ show symbol x X = "%SYSTEM-W-NOSUCHFILE, no such file" $ ------------------------------------------------------------ MGMT51. How can I customize the DCPS device control for a new printer? To customize DCPS for an otherwise unsupported printer, you can try the following sequence: o Extract the most closely-associated setup modules from the existing device control library, DCPS$DEVCTL.TLB. (For instance, you can probably extract and use the HP LaserJet 4000 series definitions for the HP LaserJet 4050 series. Each printer will vary, please consult the printer documentation for specifics and requirements.) o rename each extracted setup module to a corresponding: LPS$$UNRECOGNIZED_* o Insert all of the above-renamed setup modules into a newly-created device control library specific to the new printer: $ LIBRARY/TEXT/CREATE - SYS$COMMON:[SYSLIB]HP4050_DEVCTL.TLB LPS$$UNRECOGNIZED* The above assumes the filename HP4050_DEVCTL.TLB, alter as required. o Set up your DCPS startup procedures to include a search-list logical name such as: $ DEFINE/SYSTEM/EXECUTIVE DCPS_HP4050_LIB - SYS$LIBRARY:HP4050_DEVCTL.TLB, - SYS$LIBRARY:DCPS$DEVCTL.TLB o Supply DCPS_HP4050_LIB as the library parameter in the queue startup for this printer, this is the P3 parameter to the command procedure SYS$STARTUP:DCPS$EXECUTION_QUEUE.COM. o The HP4050_DEVCTL library may/will need to be recreated and modules re-edited and replaced with each DCPS upgrade, particularly if any modules are updated in the original library. You will also want to determine if the upgraded version of DCPS directly supports the particular printer. o To customize the processing of file extensions within DCPS (to enable or disable graybar output, for instance), use the information available in: SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT_DEFAULT to create your own site-specific: SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT Also see MGMT23. [Ken Fairfield, with typos introduced by Stephen Hoffman] ------------------------------------------------------------ MGMT52. Why do $GETDEV MOUNTCNT and SHOW DEVICE mount counts differ? MOUNTCNT returns the local mount count, while SHOW DEVICE returns the cluster-wide mount count. [Stephen Hoffman] ------------------------------------------------------------ MGMT53. What software is needed for Postscript printers? The NorthLake PrintKit (http://www.nls.com/) and DECprint Supervisor (DCPS; http://www.openvms.compaq.com/openvms/Print/print_sw_prods.html) are common choices for support of Postscript printers on OpenVMS. ------------------------------------------------------------ MGMT54. Does volume shadowing require a non-zero allocation classes? Yes, use of host-based volume shadowing requires that the disk(s) involved be configured in a non-zero allocation class. Edit SYS$SYSTEM:MODPARAMS.DAT to include a declaration of an non-zero allocation class, such as setting the host allocation class to the value 7: ALLOCLASS = 7 Then AUTOGEN the system, and reboot. You should now be able to form the shadow set via a command such as the following: MOUNT dsa1007: /SHADOW=($7$dkb300:,$7$dkb500:) volumelabel When operating in an OpenVMS Cluster, this sequence will typically change the disk names from the SCSNODE prefix (scsnode$dkann) to the allocation-class prefix ($7$dkannn). This may provide you with the opportunity to move to a device-independent scheme using logical name constructs such as the DISK$volumelabel logical names in your startup and application environments; an opportunity to weed out physical device references. [Veli Korkko] ------------------------------------------------------------ MGMT55. section duplicated MGMT28 ------------------------------------------------------------ MGMT56. How do I remove a PCSI-installed patch (ECO) kit? You cannot PRODUCT REMOVE a PCSI patch (ECO) kit. In order to do this, PCSI would have to have copies of all the other version of the files from all other patches and products that previously were installed. This can clearly involve a large number of files and a large archive of old file versions and a substantial quantity of disk space. While removal is clearly theoretically possible, it is not currently implemented. The following is the supported mechanism to remove a PCSI patch kit. (1) Execute a PRODUCT SHOW PRODUCE <product-name. /FULL command. The "MAINTENANCE" column (132 col width) shows the patches that have been installed. Keep a copy of this. (2) Re-install the prior FULL version of the product. This will remove all patch kits, setting to product back to "original" condition. (3) Re-install all the patches in the list from step 1, *EXCEPT* those which you have determined you do not want. The above information also applies to PCSI PARTIAL kits. ------------------------------------------------------------ MGMT57. SYSINIT-E, error mounting system device, status=0072832C This message can arise during an OpenVMS system bootstrap... %MOUNT-F-DIFVOLMNT, different volume already mounted on this device For details and further information, use the DCL command: $ HELP/MESSAGE /STATUS=%X72832C ------------------------------------------------------------ MGMT58. Performing SET HOST/MOP in DECnet-Plus? First, do MCR NCL SHOW MOP CIRCUIT * Let's say you have a circuit known as FDDI-0. Here is an example of the SET HOST/MOP command syntax: $ SET HOST/MOP/ADDRESS=08-00-2B-2C-5A-23/CIRCUIT=FDDI-0 Also see MGMT13. ------------------------------------------------------------ MGMT59. Resolving License PAK Problems? The PAK release date, the PAK termination date, and the PAK version are the usual culprits when a license product authorization key (PAK) check failure occurs. The PAK termination date is the date when the license PAK will expire. The PAK release date is the date of the most recent release date of the software package that will be permitted by the particular license PAK. (The release date check is analogous to a product version check.) The PAK version indicates the most recent product version that is permitted by the license. Having multiple license PAKs registered (and active) can also cause problems if an expired PAK gets loaded. You will want to DISABLE license PAKs you do not wish to have loaded. Other problems include a failure to register each PAK in all license databases throughout a multiple-system-disk cluster, with a consistent set of /INCLUDE lists specified across each of the duplicated PAKs. Additionally, you could have an invalid LMF$LICENSE logical name defined. (If no LMF$LICENSE logical name is defined, the standard license database named SYS$SYSTEM:LMF$LICENSE.LDB will be used.) You can display license failures by defining the following logical name: DEFINE/SYS/EXEC LMF$DISPLAY_OPCOM_MESSAGE TRUE Enable your terminal as a license operator (REPLY/ENABLE=LICENSE), define the LMF$DISPLAY_OPCOM_MESSAGE logical name, and then try the failing operation again. You should see one or more OPCOM messages displayed. If you have the LMF$DISPLAY_OPCOM_MESSAGE logical name defined, you can (will?) see spurious license check failures -- various products will check for multiple licenses, and a few products will check for PAKs that either have not yet been or will not be issued. Once you figure out which license has failed, you will want to deassign this logical name. Note: that there is no license check failure does NOT indicate that the particular product or operation is permissible per the license. To register a license PAK on a DECwindows system when DECwindows cannot start (because of an expired license or other licensing problem), follow the steps outlined in section MGMT5 up through step 4 (inclusive). Using the console -- analogous to what is done in step 5 to access the OpenVMS AUTHORIZE utility -- use the console to register the license PAKs. [End of Part 2/5] --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoffman#xdelta.zko.dec.com