Партнёры:
Хостинг:
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
[email protected]).
[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
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |