Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!news.compaq.com!news.cpqcorp.net!53ab2750!not-for-mail

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!newsfeed.stanford.edu!cyclone.bc.net!news-hog.berkeley.edu!ucberkeley!nntp-relay.ihug.net!ihug.co.nz!news.compaq.com!news.cpqcorp.net!53ab2750!not-for-mail
Newsgroups: comp.os.vms,comp.sys.dec,vmsnet.alpha,vmsnet.misc,comp.answers,news.
Distribution: world
X-Newsreader: mxrn 6.18-32C
Expires: 03 Jul 2004 00:00:00 GMT
Followup-To: poster
References: <[email protected]>
Approved: [email protected]
From: [email protected] (Hoff Hoffman)
Reply-To: [email protected]
Organization: HP
Subject: OpenVMS Frequently Asked Questions (FAQ), Part 3/9
Summary: This posting contains answers to frequently asked questions about
the OpenVMS operating system from HP, and the computer systems on
which it runs.
Lines: 2389
Message-ID: <[email protected]>
Date: Thu, 03 Jul 2003 17:12:10 GMT
NNTP-Posting-Host: 16.32.80.251
X-Complaints-To: [email protected]
X-Trace: news.cpqcorp.net 1057252330 16.32.80.251 (Thu, 03 Jul 2003 10:12:10 PDT)
NNTP-Posting-Date: Thu, 03 Jul 2003 10:12:10 PDT
Xref: senator-bedfellow.mit.edu comp.os.vms:389889 comp.sys.dec:98151 vmsnet.alpha:12768 vmsnet.misc:6467 comp.answers:54089

Time and Timekeeping

__________________________________________________________
4.4 Managing Timezones, Timekeeping, UTC, and Daylight Savings?

You will want to use the command procedure:

o SYS$MANAGER:UTC$TIME_SETUP.COM

to configure the OpenVMS Timezone Differential Factor
(TDF) on OpenVMS V6.0 and later. Select the BOTH
option. This configures the OpenVMS TDF settings,
though it may or may not configure the TDF and the
timezone rules needed or used by other software
packages. Please do NOT directly invoke the following
command procedures:

o SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly
use

o SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly
use

TCP/IP Services V5.0 and later use the OpenVMS TDF,
UTC, and timezone support. Earlier versions use a TDF
mechanism and timezone database that is internal to the
TCP/IP Services package. Also on the earlier versions,
the TDF must be manually configured within TCP/IP
Services, in addition to the OpenVMS configuration
of the TDF.

DECnet-Plus in V7.3 and later uses the OpenVMS TDF,
UTC, and timezone support, and displays its timezone
prompts using UTC$TIME_SETUP.COM. Earlier versions use
a TDF TDF mechanism, timezone database, and automatic
switch-over that is internal to the DECnet-Plus
package. Also on earlier versions, the TDF must be
configured within the DECnet-Plus DECdtss package, in
addition to the OpenVMS configuration of the TDF.

Application code using HP C (formerly Compaq C,
formerly DEC C) will use the OpenVMS UTC and TDF
mechanisms when the C code is compiled on OpenVMS V7.0
and later (and when the macro _VMS_V6_SOURCE is NOT
defined). HP C does NOT use the OpenVMS UTC and TDF
mechanisms when the C code is compiled on OpenVMS
releases prior to V7.0, or when the preprocessor
declaration _VMS_V6_SOURCE is declared.

4-13

Time and Timekeeping

DCE DTSS TDF details TDB.

In OpenVMS Alpha V6.1, V6.2, and V6.2-1Hx, the TDF
value is written to SYS$BASE_IMAGE.EXE. With OpenVMS
Alpha V7.0 and later and with OpenVMS VAX V6.0 and
later, SYS$SYSTEM:SYS$TIMEZONE.DAT contains the TDF.
This means that OpenVMS Alpha systems will need to have
the TDF value reset manually-usually within SYSTARTUP_
VMS.COM-on reboots prior to V7.0.

During OpenVMS Bootstrap, the SYSINIT module reads
SYS$TIMEZONE.DAT to acquire the TDF for use in the
system global cell EXE$GQ_TDF. This is done to ensure
that the system boots with a valid TDF (a value which
may be zero). The UTC system services get the TDF
from this cell. These services, as well as the HP C
RTL, must have a valid TDF. (Prior to OpenVMS V7.3,
if either DECnet-Plus or DECnet/VAX Extensions is
configured and run, the image DTSS$SET_TIMEZONE.EXE
is invoked and can override the TDF and timezone rule
settings from SYSINIT or from UTC$TIME_SETUP.COM-
this image runs even if DTSS is disabled. If the
settings do not match (due to inconsistencies in
timezone specification in UTC$TIME_SETUP.COM and
NET$CONFIGURE.COM), DTSS will reset the values to match
its definitions.)

Prior to OpenVMS V7.3, daylight savings time switchover
is handled automatically only when DCE DTSS or DECnet-
Plus DTSS is in use. In V7.3, OpenVMS can be configured
to automatically switch over to daylight savings
time, and also generates an event that interested
applications can use to detect the switch-over between
standard time and daylight time.

The manual switchover between daylight savings time
and standard time is correctly accomplished via the
SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure
procedure.

Note: NTP (alone) does NOT provide automatic switch-
over.

Note: The DST switch-over does NOT drift the time
value; the switch-over applies the entire difference as
a unit.

4-14

Time and Timekeeping

If you switch the TDF or daylight savings time setting,
you will also want to restart or reconfigure any time-
sensitive applications (those not using the time
differential factor (TDF) change event available in
V7.3 and later). Examples of these applications include
the need to restart the NFS client and (yes) NTP. (NTP
will want to try to "drift" the time (see Section 4.3),
and will find the daylight savings time switch-over to
be far too large to "drift". Hence the NTP restart.)
You can also use the (undocumented) TCP/IP Services
(prior to V5.0) commands:

SET TIME/DIFF=[positive or negative TDF integer]
GENERATE TIME

to reset the value of the logical name UCX$TDF.

Prior to V7.3, the command:

$ SETTZ :== $SYS$SYSTEM:DTSS$SET_TIMEZONE
$ SETTZ MODIFY

can be used to modify the settings of the SYS$TIMEZONE_
DAYLIGHT_SAVING, SYS$TIMEZONE_DIFFERENTIAL, and
SYS$TIMEZONE_NAME system logical names based on the
SYS$TIMEZONE_RULE.

The following are other TDF-related logical names
used/available on OpenVMS systems, with typical
Daylight Savings and Standard Settings for the US
Eastern Time (ET) timezone.

$daylight_time:
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EDT
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0400 EDT"
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P true ! Not 'EDT'
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant
$
$standard_time:
$ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EST
$ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0500 EST"
$ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P false ! Not 'EST'
$ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant
$
$ DEFINE/SYSTEM/EXECUTIVE UCX$NFS_TIME_DIFFERENTIAL -
'f$integer(f$element(0," ",f$logical("notes$timezone"))/-100)'

4-15

Time and Timekeeping

For information on ZIC and related tools used to manage
the OpenVMS Timezone database, please see the DEC C
Run-time Library Utilities Reference Manual-though the
title would imply otherwise, this particular manual
is part of the OpenVMS documentation set, and not
part of the HP C (formerly Compaq C, formerly DEC C)
documentation set.

_____________________________
4.4.1 How to troubleshoot TDF problems on OpenVMS?

This is an OpenVMS Alpha system prior to V7.0 and the
startup is not invoking the procedure:

SYS$MANAGER:UTC$TIME_SETUP.COM

This is an OpenVMS system prior to V6.0, where there is
no OpenVMS TDF nor UTC available.

The version of the application does not use the OpenVMS
TDF. This includes TCP/IP Services prior to V5.0,
applications using HP C built on or targeting OpenVMS
prior to V7.0, and systems using the DECnet-Plus DTSS
mechanisms prior to the release associated with OpenVMS
V7.3. (DCE TDF TBD.)

If you should find either of the following two
timezone-related database files located in
SYS$SPECIFIC:[SYSEXE]:

o SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE.DAT

o SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE_SRC.DAT

These two files are in an erroneous location and must
be recreated in the correct directory:

SYS$COMMON:[SYSEXE]

If the DCL command:

$ DIRECTORY SYS$SYSTEM:SYS$TIMEZONE*.DAT

shows these files in SYS$SPECIFIC:[SYSEXE], then delete
them and use SYS$MANAGER:UTC$TIME_SETUP.COM to recreate
them.

4-16

Time and Timekeeping

On OpenVMS versions prior to V7.3, if the file:

$ SYS$STARTUP:DTSS$UTC_STARTUP.COM

is present on your system, then you may need to invoke:

$ @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM

to recreate the timezone files correctly. Invoke
this command immediately after [re]executing
SYS$MANAGER:UTC$TIME_SETUP.COM.)

If SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM is not
present on your system, then you may need to execute
the following commands:

$ DELETE SYS$STARTUP:DTSS$UTC_STARTUP.COM
$ DEASSIGN/SYSTEM/EXEC SYS$TIMEZONE_RULE.

If your system time is being reported as being off by
one hour (or whatever the local DST change), please see
sections Section 4.1, Section 4.4 and Section 10.24.1.

_____________________________
4.4.2 Customizing your TDF (Timezone) Setting?

Individual, local, and regional differences on the use
(or the lack of use) of Daylight Savings Time (DST) are
quite common.

If you need to add (or remove) daylight savings
time for your area or otherwise alter the rules for
your local area, you will probably end up creating a
variation to an existing timezone rule.

The necessary zone line to add for WhereEverLand will
probably look something like this:

# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL]
Zone WhereEver 2:00 - WhereEver

The OpenVMS source file for the timezone rules here:

SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]

You'll then want to ZIC this to create your own
timezone definiton.

4-17

Time and Timekeeping

ZIC is documented in the OpenVMS Documentation Set, in
the HP C Run-Time Library Reference Manual. (Despite
the name of the manual, it is part of the OpenVMS
documentation set and not the C manuals.)

Once you have created the new rule, use
SYS$MANAGER:UTC$TIME_SETUP.COM to select the new
timezone-with V7.3 and later, this tool will notice the
new timezone and will offer it, on earlier releases,
you may/will have to hack the tool somewhat. (Don't
even think of trying to define the TZ or other time-
related logical names directly yourself.)

For various timezone rules, see the tar.gz files (these
are gzipped tar archives) available at:

o ftp://elsie.nci.nih.gov/pub/

__________________________________________________________
4.5 Why does the SET TIME command fail? Help managing DTSS?

If you try to set the system time with the SET TIME
command, and see one of the following messages:

%SET-E-NOTSET, error modifying time
-SYSTEM-F-IVSSRQ, invalid system service request

%SET-E-NOTSET, error modifying time
-SYSTEM-E-TIMENOTSET, time service enabled; enter a time service command to update the time

This occurs if the time on the local system is
controlled by a time service software, for example
the distributed time service software (DTSS) provided
as part of the DECnet-Plus installation. The DTSS
software communicates with one or more time servers
to obtain the current time. It entirely controls the
local system time (for DECnet-Plus, there is a process
named DTSS$CLERK for this); therefore, the usage of
the SET TIME command (and the underlying $SETTIM system
service) is disabled.

The first message is displayed on systems running
DECnet-Plus V6.1 and earlier. On systems with newer
DECnet-Plus software, the second (and more informative)
message is given.

4-18

Time and Timekeeping

You shouldn't have to change the time manually - you
should be doing this through the time server - but if
you insist... you'll have to shutdown DTSS:

$ RUN SYS$SYSTEM:NCL
DISABLE DTSS
DELETE DTSS

This will shutdown DTSS$CLERK. You may then change the
system time as usual. To restart the DTSS software,
type

$ @SYS$STARTUP:DTSS$STARTUP

You will need a number of privileges to ussue this
command, and you must also be granted the NET$MANAGE
identifer to shutdown and to restart DTSS.

If you wish to "permanently" disable DTSS on a system
running DECnet-Plus, the above NCL sequence must be
performed each time the system is bootstrapped. (On
DECnet-Plus V7.3 and later, you can define the logical
name NET$DISABLE_DTSS to disable the DTSS startup. This
logical name must be defined in the command procedure
SYLOGICALS.COM, as this logical name must be present
and defined sufficiently early in the OpenVMS system
bootstrap sequence for it to function.)

If DTSS is running and no time servers are configured,
you can (and will) see the following messages at
regular intervals:

%%%%%%%%%%% OPCOM 2-SEP-1999 19:41:20.29 %%%%%%%%%%%
Message from user SYSTEM on UNHEDI
Event: Too Few Servers Detected from: Node LOCAL:.mynode DTSS,
at: 1999-09-02-19:41:20.296-04:00Iinf
Number Detected=0,
Number Required=1
eventUid 5FA70F4F-616E-11D3-A80E-08002BBEDB0F
entityUid DE9E97DE-6135-11D3-8004-AA000400BD1B
streamUid D6513A46-6135-11D3-8003-AA000400BD1B

You can either configure the appropriate number of time
servers, or you can disable DTSS, or you can ignore it
and (if OPCOM is set to write to the log via via the
logical names in SYLOGICALS.COM/SYLOGICALS.TEMPLATE)
clean out OPERATOR.LOG regularly.

4-19

Time and Timekeeping

You can also simply disable the display of these
messages:

$ run sys$system:ncl
block event dispatcher outbound stream local_stream global filter -
((Node, DTSS), Too Few Servers Detected)

If you wish to disable the automatic TDF adjustment
for daylight savings time (on OpenVMS versions prior to
V7.3), you can use the command:

$ run sys$system:ncl
set dtss automatic TDF change = false

or alternatively, you can set the local timezone to one
that does not include the automatic daylight savings
time change-over.

OpenVMS V7.3 and later simplify time and timezone
management.

4-20

_______________________________________________________

5 System Management Information

__________________________________________________________
5.1 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

5-1

System Management Information

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.

__________________________________________________________
5.2 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.

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

5-2

System Management Information

attempts. Computer Associates (CA) offers various
products in this area.

Rocksoft offers the Veracity data integrity tool (for
info, send mail to [email protected]).

__________________________________________________________
5.3 How do I mount an ISO-9660 CD on OpenVMS?

ISO-9660 support was added in the following releases:

o OpenVMS VAX V6.0

o 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

5-3

System Management Information

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.

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:

o http://pdp-11.trailing-edge.com/www/ods1.txt

o http://www.openvms.compaq.com/freeware/freeware50/ods2/

__________________________________________________________
5.4 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

5-4

System Management Information

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.

__________________________________________________________
5.5 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:

On VAX, use one of the following three commands
depending on the particular model of VAX system
involved:

5-5

System Management Information

B/R5:1
B/1
@GENBOO

On 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:

On VAX:

B/E0000001
B/R5:E0000001
@<console media procedure name varies widely>

On 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

5-6

System Management Information

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 is
now set to the specified value.

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.

5-7

System Management Information

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.

__________________________________________________________
5.6 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.

o Update the SCSNODE in MODPARAMS.DAT, and then run
AUTOGEN as far as the SETPARAMS phase. (Do not
reboot yet.)

o Modify the DECnet node name. (NETCONFIG is the
DECnet Phase IV tool, and NET$CONFIGURE is the
DECnet-Plus tool.)

o 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.)

o 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.)

o 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.)

5-8

System Management Information

o Use the AUTHORIZE utility command RENAME/IDENTIFIER
to rename the SYS$NODE_oldnodename rightslist
identifier to match the new node name. (Do not
change the binary value of this identifier, and
do not delete the identifier.)

If you have erroneously deleted or duplicate the
identifier, you can locate existing references to
the binary identifier value using the Freeware DFU
package, and specifically the commands SEARCH/ACE
and /OWNER. You must (re)create the correctly-named
identifier using the binary value that is often
stored in various Access Control List Entry (ACE)
structures and object owner fields associated with
files and objects present in the OpenVMS system.

o Reset any license PAKs that are restricted to the
old node name to the new node name.

o If the node name is part of a disk volume label, see
Section 5.12.

o 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)

5-9

System Management Information

This may well 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...

Also see Section 15.6.3 and Section 15.6.4.

__________________________________________________________
5.7 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.

__________________________________________________________
5.8 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.

5-10

System Management Information

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.

5-11

System Management Information

__________________________________________________________
5.9__What_are_the_OpenVMS_version upgrade paths?

5.9.1 OpenVMS Alpha Upgrade (or Update) Paths

From V1.0,
you can upgrade to V1.5.
From V1.5, or V1.5-1H1,
you can upgrade to V6.1.
From V6.1,
you can upgrade to V6.2.
From V6.1, or V6.2,
you can upgrade to V7.0.
From V6.1, V6.2, V6.2-1H(1,2,3), or V7.0,
you can upgrade to V7.1.
From V6.2,
you 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
From V7.3, V7.2-2, V7.2-1H1, V7.2-1, and V7.1-2,
you can update to V7.3-1

Some typical OpenVMS Alpha upgrade (or update) paths
are:

5-12

System Management Information

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.1-2 -> V7.3-1
V7.2 -> V7.2-1H1
V7.2 -> V7.3 -> V7.3-1
V7.2-1 -> V7.3-1
V7.2-2 -> V7.3
V7.3 -> V7.3-1
V7.2-2 -> V7.3-1

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.

5-13

System Management Information

_____________________________
5.9.2 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.

5-14

System Management Information

_____________________________
5.9.3 OpenVMS Cluster Rolling Upgrade Paths

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 Upgrade and Installation Manual for the
particular release, and the OpenVMS Software Product
Descriptions for OpenVMS and for OpenVMS Cluster
software:

o 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.

_____________________________
5.9.4 OpenVMS Product Version and 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:

o http://www.compaq.com/services/software/ss_
mature.html

o http://www.compaq.com/services/software/ss_pvs_se_
amap.html

o http://www.compaq.com/services/software/ss_mps_pvs_
eur.html

5-15

System Management Information

For information on supported versions of layered
products, and minimum required layered product
versions, see:

o 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:

o 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:

o http://www.openvms.compaq.com/openvms/20th/vmsbook.pdf

_____________________________
5.9.5 OpenVMS Alpha Terminology

The following terms apply to OpenVMS Alpha upgrades and
installations.

o 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.

o Upgrade
Performed via PCSI. Upgrades can typically be
applied to a release-specific (and documented) range
of prior OpenVMS releases.

o 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.

5-16

System Management Information

o 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.

o 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
Section 2.11.

__________________________________________________________
5.10 Why do I have a 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.)

5-17

System Management Information

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.

With OpenVMS V7.3 and later, the displays have been
changed and these negative values are no longer
visible.

__________________________________________________________
5.11 Do I have to update layered products when updating
OpenVMS?

The Software Public Rollout Reports for OpenVMS list
the current and future availability of HP software
products shipping on the OpenVMS Software Products
Library kits (CDROM consolidations) for OpenVMS Alpha
and/or OpenVMS VAX. Specifically, the required minimum
versions for product support are listed.

5-18

System Management Information

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
HP OpenVMS 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 regularly. Please see:

o http://www.openvms.compaq.com/openvms/os/swroll/index.html

__________________________________________________________
5.12 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 to reset the label information stored within
the PCSI database to reflect the new disk volume label:

$ PRODUCT REGISTER VOLUME old-label device

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

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

5-19

System Management Information

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

Remount the disk appropriately.

__________________________________________________________
5.13 How can I set up a shared directory?

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

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

Add an identifier using the AUTHORIZE utility:

ADD/IDENTIFER/ATTRIBUTES=RESOURCE groupidentifier

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

GRANT/IDENTIFIER groupidentifier username

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

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

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

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

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

5-20

System Management Information

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

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

__________________________________________________________
5.14 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):

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

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

Also see Section 5.33.

__________________________________________________________
5.15 Drivers and Configuration of New Graphics Controllers?

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

5-21

System Management Information

_____________________________
5.15.1 The ELSA GLoria Synergy

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

o VMS712_GRAPHICS-V0300 or later

o VMS72_GRAPHICS-V0100 or later

o VMS712_GRAPHICS-V0300 or later

The ELSA GLoria Synergy is the PBXGK-BB; the PowerStorm
3D10T.

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

DISK$ALPHA0721:[ELSA.KIT]

Also check for any available (later) ECO kits.

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

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

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

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

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

5-22

System Management Information

_____________________________
5.15.2 PowerStorm 300, PowerStorm 350

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

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

For OpenVMS Alpha V7.1-2:

o DEC-AXPVMS-VMS712_P350-V0100-4 or later

o DEC-AXPVMS-VMS712_GRAPHICS-V0300-4 or later

For OpenVMS Alpha V7.2-1:

o DEC-AXPVMS-VMS721_P350-V0100-4 or later

o DEC-AXPVMS-VMS721_GRAPHICS-V0300-4 or later

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

_____________________________
5.15.3 PowerStorm 3D30, PowerStorm 4D20

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

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

_____________________________
5.15.4 Radeon 7500

Install the current GRAPHICS ECO kit for OpenVMS Alpha
V7.2-2 or V7.3-1 for support of the Radeon 7500 series
controller.

Support for this controller (without an ECO kit) is
expected to be first integrated into and available in
OpenVMS Alpha V7.3-2.

5-23

System Management Information

__________________________________________________________
5.16 How can I acquire OpenVMS patches, fixes, and ECOs?

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

o http://search.service.digital.com/

o ftp://ftp.support.compaq.com/public/vms/

o http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/

o http://ftp/digital.com.au/cgi-bin/grep/

o http://askq.compaq.com/

The
http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/
URL can be particularly useful, as it includes a search
engine capable of returning the mandatory ECO kits
for each release. Also see the information on required
ECOs available from the support database, accessible
via http://askq.compaq.com/. Specifically, search for
articles with the words "incorporated" and "need to
install" in the title.

You can subscribe to an email notification list at:

o http://www.support.compaq.com/patches/mailing-
list.shtml

A quarterly distribution is also available on CD-ROM:

o QT-3CQAA-C8 OpenVMS Alpha

o QT-3CRAA-C8 OpenVMS VAX

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

o http://Eisner.DECUS.org/conferences/OpenVMS-patches_
new_1.HTML

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

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

5-24

System Management Information

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

o ftp://ftp.support.compaq.com/public/vms/

o http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/

For additional information, please see Section 5.16.

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

See Section 5.29 for information on ECO kit checksums.

__________________________________________________________
5.17 How do I move the queue manager database?

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

To move the queue database:

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

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

2 Stop the queue manager

$ STOP/QUEUE/MANAGER/CLUSTER

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

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

5-25

System Management Information

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

$ CREATE/DIR fast_disk:[qman]

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

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

6 Delete the old queue database.

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

7 Restart the queue manager pointing to the new
location

$ START/QUEUE/MANAGER fast_disk:[qman]

__________________________________________________________
5.18 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 relevant host component has an ECO, acquire
and apply it.

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

5-26

System Management Information

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

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

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

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

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

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

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

You now need to locate the system address of the UCB$%_
ERRCNT field of the device you wish to reset. Enter
SDA. In the following, you will see designations in
{} separated by a /. The first item in braces is to be

5-27

System Management Information

used on the VAX and the second item should be used on
an Alpha. (ie. {VAX/Alpha})

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

Record the hexadecimal value 'hhhhhhhh' returned.

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

SDA> SPAWN RUN SYS$SHARE:DELTA

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

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

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

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

Now issue the command 1;M

DELTA will respond with 00000001

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

IPID:hhhhhhhh/

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

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

00010001:hhhhhhhh/

5-28

System Management Information

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

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

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

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

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

00010001:80D9C6C8/0001 0<return> ! output on VAX 1 error

00010001:80D9C6C8/00000001 0<return> ! output on Alpha 1 error

Now type the command EXIT and a carriage return.

Alternatively, reboot the system.

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

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

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

__________________________________________________________
5.21 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

5-29

System Management Information

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".

5-30

System Management Information

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

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

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

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

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

o http://www.openvms.compaq.com/wizard/

o http://www.openvms.compaq.com/wizard/wizard.zip

For additional information, please see Section 3.9.

5-31

System Management Information

__________________________________________________________
5.22 How do I delete (timeout) idle processes?

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

As for available tools, there are DECUS, freeware,
and third-party tools known variously as "idle process
killers" (IPK) or "terminal timeout" programs, as well
as various other names. Examples include: Saiga Systems
Hitman, Watchdog, MadGoat Watcher (via the MadGoat
site or the OpenVMS Freeware), Kblock, the Networking
Dynamics tool known as Assassin, and the Zap tool.
Also available is the XLNperformance system management
utility, from XLNsystems.

A related package (for DECwindows sessions) is
xtermlock.

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

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

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

Please see the following website for details and
downloads: Analyze)

o http://www.compaq.com/support/svctools/

5-32

---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com