Open Vmss

HP Technology Forum 2006
Advanced OpenVMS
System Management
Techniques, Tools,
and Tricks
DJE Systems - http://www.djesys.com/
David J. Dachtera - djesys@earthlink.net
GET CONNECTED
People. Training. Technology.
2006 DJE Systems, All rights reserved

The information contained herein is subject to change without notice
This presentation is intended to be displayed or

printed in the Notes View so it reads like a text
book.
If you are viewing this as a Slide View .PDF
(Adobe Acrobat file), download the .PPT
(PowerPoint presentation) from:
http://www.djesys.com/vms/support/1065.ppt
When published with the Symposium Session

notes, this presentation might be converted to
.PDF in the slide view only. Go to the URL
shown to get the final PowerPoint presentation,
then view it the way that works best for you.
Agenda
Logical names
Logical name tables
Logical name table search order
Modifying the search order
Logical name types

Single Translation
Search list
Rooted (Concealed) logical names
Lexical Function Caveat

F$TRNLNM() differs from F$LOGICAL()
Since much of the way the VMS environment works is driven by the use
of logical names, well spend a good bit of time talking about them.
Questions in real time are encouraged during this discussion, and we
can always refer back to it as we proceed into those areas where logical
names are used. This will provide an opportunity for reinforcement
through practical examples.
Well also discuss a few gotchas regarding DCL lexical functions as
they relate to OpenVMS and system management.
Agenda
Logical names, contd
Cluster-wide logical names
Caveats
SYS$COMMON Notes
Caveats (VMS$COMMON)
Site-Specific Paths
Organizing local system management code
In the newer versions of OpenVMS, Cluster-wide logical name tables

were introduced. While these did not introduce any new complexity,
working with them is not as straight-forward as it might appear at first
glance.
Well take a look at some practical examples of why the VMS$COMMON
directory is rarely - if ever - used in the many logical names that the
familiar OpenVMS environment depends on.
Agenda
Network Topics
TCP/IP
TCP/IP Services (fka UCX)
Multinet
TCPware
CMU/IP (VAX only)
DECnet
Access control
FAL logging
TCP/IP Services (fka UCX)

Access control
Continuing our discussion of the essential elements of the system and

system management, well take a look at a brief overview of OpenVMS
and networking.
Well look at the various TCP/IP stacks available for OpenVMS: three
commercial products for VAX and Alpha and a freeware piece for
OpenVMS VAX only.
Well look at DECnet as well, and take a look at Access Control and
logging as well as some undocumented logical names can that be used
to modify the behavior of FAL logging.
Agenda
Network Topics, contd
LAT
MOP
Remote Access
Remote procedures
Types
Security concerns
Network Alerts
OPCOM alerts for DECnet network access
OPCOM alerts for FTP network access
Relevant to the discussion of networking is network access to OpenVMS.

Well look at some of the types and methods of remote access offered by
the TCP/IP stacks, discuss some of he security concerns surrounding
them.
Then, well look at ways to to provide expanded logging for DECnet
access and access via FTP.
Agenda
System Startup
STARTUP phases
STARTUP parameters
Site-Specific startups
Logging SYSTARTUP_VMS.COM
Node-specific startups
Saving a crash dump at start-up time
DEFINE-ing Group Logicals
Soft-coding # of logins allowed at startup
SYSMAN and STARTUP

Conversational Boot, Minimal Startup
Having reviewed some of the essential elements of OpenVMS Systems

and system management, well start to look a bit deeper into the process
of starting the OpenVMS operating environment.
Well look at how the OpenVMS-supplied procedures work so we can
understand how to function within that framework. Well examine the
various phases of the STARTUP procedure and the parameters it uses
and observes.
In our discussion of site-specific startups, well look at some tips and
tricks for retaining a log of the site-specific startup, suggest some ways to
manage startups specific to a single node or group of nodes in a cluster,
well look at how to save crash dump information at system startup time
and well at a method of soft-coding the number of logins allowed at
system startup time.
In recent versions of VMS, the SYSMAN utility has acquired an interface
to the OpenVMS-supplied system startup procedure which allows for
some customization. Well look into that in some detail, as well.
Agenda
System Shutdown
SHUTDOWN parameters
SHUTDOWN$xxxx logical names
AUTOGEN Shutdowns
AGEN$SHUTDOWN_TIME logical name
Cluster Shutdown
REMOVE_NODE, CLUSTER_SHUTDOWN
Being able to startup the system is only half of the story. So, well look
into the system shutdown procedures as well.
Well look at the various parameters and options of the OpenVMSsupplied SHUTDOWN procedure, and some logical names that can be
used to provide default values to certain SHUTDOWN parameters,
including one that is used specifically by the AUTOGEN procedure.
OpenVMS clusters introduce some additional shutdown-time
considerations. So, well look into those as well. The SYSMAN utility
provides some functionality for system and cluster shutdown. Well look
at that as well.
Agenda
AUTOGEN
MODPARAMS.DAT
Reports and outputs
Useful Tips and Tricks

An UPTIME command
Enhanced HELP/PAGE
Show logins (limit, current)
A more command for VMS
VMS disk partitions Logical Disks
The system STARTUP procedure harks back to the early days of VMS, a
venerable and trusted facility. As such, it contains some artifacts of its
heritage that are worthy of attention. Well take a look at those, since they
could lead to some confusion if used as a current-version example of how
to program DCL procedures.
AUTOGEN is a useful tool for helping to keep OpenVMS systems in tune
and performing well. Well look at using AUTOGEN, setting values for
system parameters in he MODPARAMS.DAT file, and well look at the
reports and outputs of AUTOGEN and how to use them.
Agenda
OpenVMS Security
Essentials
UICs and File/Directory Protection
Access Control Lists (ACLs)
Access Control Entries (ACEs)
Rights Identifiers and ACEs
Propagating ACEs and Default Protections
Closing Comments, Q & A

Sources of Freeware for VMS
Disclaimer
Finally, if time permits, well take a look at the essentials of OpenVMS

System security and the various elements that make it work.
Additionally, well look at third-party software and freeware that can be
used to help secure your systems and access to them.
Well conclude with lists of sources for free- and open-source software for
OpenVMS where one might find useful extensions for secure access to
OpenVMS systems, as well as utilities and other helpful items.
10
Session 1065
OpenVMS
Logical Names
11
Logical Names
A form of symbol with limited or system-wide scope.

$ show logical sys$sysroot
"SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE)
= "SYS$COMMON:"
1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]"
(LNM$SYSTEM_TABLE)
A feature that is more or less unique to OpenVMS is the concept of

logical names. Similar features may be present in some mainframe
operating systems, also.
Simply stated, logical names provide a way to represent a device name, a
device name and a path name or even a device name and part of a path
name in a simple way so that software, files, etc. can be easily used on
and moved from one system to another, to pass data to programs and
procedures or just for convenience.
12
Logical Name Tables

LNM$SYSTEM_DIRECTORY
LNM$JOB_xxxxxxxx
LNM$GROUP_xxxxxx
LNM$SYSTEM_TABLE
DECW$LOGICAL_NAMES
LNM$PROCESS_DIRECTORY
Logical names are organized in logical name tables.

Logical name tables exist in hierarchies, with logical name table
directories at the highest or root levels.
As supplied, VMS has two primary logical name table hierarchies. Most
logical name tables are found under the LNM$SYSTEM_DIRECTORY,
as shown in he example in the slide. The LNM$PROCESS_DIRECTORY
is private to each process on the system and cannot be viewed from
another process except by accessing data structures via routines which
require privilege. This affords a degree of security for sensitive
information since it cannot be easily viewed by other users.
13
Logical Name Tables

Search Order:
$ sh log/tab=* lnm$file_dev
"LNM$FILE_DEV" = "LNM$PROCESS"
(LNM$SYSTEM_DIRECTORY)
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"
= "DECW$LOGICAL_NAMES"
VMS provides that logical name tables can be searched by providing a

search list which is itself a logical name. The LNM$FILE_DEV logical
name indicates which logical names should be searched when the
SHOW LOGICAL command is issued without the /TABLE qualifier or
when a file is being opened or sought.
14
Logical Name Tables

Modifying the search order:
$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY LNM$FILE_DEV LNM$PROCESS,LNM_PRIVATE,LNM$GROUP,LNM$SYSTEM,DECW$LOGICAL_NAMES
Defines a new search list in supervisor mode.

Some software will only use trusted logical names in certain directories or
those DEFINEd in an inner (more privileged) mode.
It is possible to modify the search order specified in the LNM$FILE_DEV

logical name. This can be done for individual processes, for entire UIC
groups (requires GRPNAM privilege) or across the entire system (may
require SYSPRV, SYSNAM and CMEXEC privilege).
Note, however, that some software will only use logical names that
appear in certain logical name table directories or logical name tables or
are DEFINEd in a privileged access mode. It is assumed that privileged
programs and procedures are trusted, and thus that logical names they
may establish are similarly trust worthy.
15
Logical Names
Single translation
$ DEFINE lnm value
Search List
$ DEFINE lnm value,value[,]
Concealed Logical Names

$ DEFINE lnm value/TRANS=CONCEAL
Rooted Logical Names

$ DEFINE lnm ddcu:[dir.]/TRANS=CONCEAL
Here we see examples of the various forms of logical names.

Single translation logical names have only one equivalence string.
Search lists can have multiple equivalence strings.
Concealed logical names are used in cases where it is desired that nonprivileged programs and procedures should not display the equivalence
string associated with concealed logical names.
Rooted logical names are used in a manner very similar to device names.
The top level directory in a path indicated by a rooted logical is referred
to as [000000], just as is the Master File Directory (MFD) of a disk
volume. The actual device name and root path are not displayed by nonprivileged programs and procedures.
Some folks refer to rooted logicals as pseudo disks for that reason. See
also discussion of Logical Disks later on in this presentation.
16
Logical Names
Creating
$ DEFINE lnm value
$ ASSIGN value lnm
Deleting
$ DEASSIGN lnm
There are two DCL commands for creating logical names.

The DEFINE command has the logical name as its first parameter and
the equivalence string(s) as the second parameter.
The ASSIGN command reverses the order of the parameters: the
equivalence string(s) as the first parameter, and the logical name as the
second parameter.
There is one DCL command for deleting logical names. The DEASSIGN
command is used to delete logical names.
17
Logical Names
Access Modes
User
DEFINE/USER
SupervisorDEFINE (/SUPER is default)
Executive DEFINE/EXECUTIVE,
requires CMEXEC privilege.
Kernel
Can only be created by using
the $CRELNM system service,
requires CMKRNL privilege.
Executive and Kernel mode logical names are trusted since
privilege is required to create them.
Logical names are DEFINEd is one of four access modes. More

privileged access modes are sometimes referred to as inner modes.
User mode logical names are the lowest and least privileged level. User
mode logical names are deleted when an image (a program) is run down
(exits).
Supervisor mode is the default access mode for both DEFINE and
ASSIGN. Supervisor mode is also a low privilege level; however,
supervisor mode logical names persist and are not deleted when an
image (a program) is run down (exits).
Executive mode is similar to Supervisor mode, but requires CMEXEC
privilege.
Kernel mode is the most privileged access mode. Kernel mode logical
names can only be established by invoking the $CRELNM system service
which is only accessible within a program. There is no /KERNEL qualifier
for either the DEFINE or ASSIGN commands.
18
Logical Names
Single Translation
$ DEFINE lnm value
Examples:
"LNM$PROCESS" = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY)
"LNM$JOB" = "LNM$JOB_80D27B00" (LNM$PROCESS_DIRECTORY)
"LNM$GROUP" = "LNM$GROUP_000030" (LNM$PROCESS_DIRECTORY)
"LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY)
SYS$LOGIN" = "DKA0:[DDACHTERA]" (LNM$JOB_80D27B00)
Here we see a few examples of common single-translation logical names

that may be encountered on a running OpenVMS system.
19
Logical Names
Search Lists
$ DEFINE lnm value,value[,]
Examples:
$ sh log sys$sysroot
= "SYS$COMMON:"
1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
$ sh log user_exe
! Presenters environment, not provided by VMS.
"USER_EXE" = "USER_IMG:" (LNM$JOB_80D27B00)
= "USER_COM:"
= "SYS$SPECIFIC:[SYSEXE]"
= "SYS$COMMON:[SYSEXE]"
1 "USER_IMG" = "USER_ROOT:[EXE.ALPHA]" (LNM$JOB_80D27B00)
1 "USER_COM" = "USER_ROOT:[EXE]" (LNM$JOB_80D27B00)
Here we see some examples of logical names which are set up as search
lists.
Under the translation of SYS$SYSROOT, we also see the translation of
one of its elements: SYS$COMMON. SYS$COMMON is a rooted logical
as is the first translation of SYS$SYSROOT.
The second example, USER_EXE is a search list that is set up in the
environment of a specific users process. Under USER_EXE we see the
translations of two of its elements, USER_IMG and USER_COM.
20
Logical Names
Concealed Logical Names
$ DEFINE lnm value/TRANS=CONCEAL
Example:
$ sh log sys$sysdevice
"SYS$SYSDEVICE" = "DJAS01$DKA300:" (LNM$SYSTEM_TABLE)
$ sh log sys$sysdevice/full
"SYS$SYSDEVICE" [exec] = "DJAS01$DKA300:" [concealed,terminal]
(LNM$SYSTEM_TABLE)
Here we see an example of a commonly encountered system-wide logical

name.
SYS$SYSDEVICE is a concealed logical name created in executive
mode.
SYS$SYSDEVICE also has the Terminal attribute which means that
after translating SYS$SYSDEVICE no further translation be attempted
beyond the equivalence string of SYS$SYSDEVICE (in this example,
DJAS01$DKA300:).
21
Logical Names
Rooted Logical Names
$ DEFINE lnm ddcu:[dir.]/TRANS=CONCEAL
Examples:
$ show logical sys$specific,sys$common,user_root
"SYS$SPECIFIC" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE)
"SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
"USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00)
Here we see two examples of commonly encountered rooted logical

names.
The equivalence string of SYS$SPECIFIC includes the physical name of
the system disk device and the nodes boot root ([SYS0.]).
The equivalence string of SYS$COMMON includes the physical name of
the system disk device, the nodes boot root ([SYS0.) and the rootspecific alias for the VMS$COMMON directory (SYSCOMMON]).
22
Logical Names
Using rooted logical names
Examples:
$ show logical sys$sysroot,user_root,user_com,user_img
= "SYS$COMMON:"
1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
"USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00)
"USER_COM" = "USER_ROOT:[EXE]" (LNM$JOB_80D27B00)
"USER_IMG" = "USER_ROOT:[EXE.ALPHA]" (LNM$JOB_80D27B00)
Here we see examples of system and user level uses of rooted logical
names.
SYS$SYROOT we saw in an earlier slide.
USER_ROOT weve seen before, also. Here we see how it is DEFINEd.
The USER_COM and USER_IMG logical names both use the rooted
logical name USER_ROOT.
23
Logical Names & Lexicals

Beware:
F$LOGICAL() (deprecated) differs from
F$TRNLNM().
F$LOGICAL() uses hard-coded search list
internally: Process, Job, Group, System.
F$TRNLNM() uses LNM$FILE_DEV
Something to watch out for here:

Some of the older DCL procedures supplied with the system by
OpenVMS use the F$LOGICAL() lexical function. F$LOGICAL() has been
deprecated (made obsolete) and is no longer documented.
However, OpenVMS always attempts to maintain compatibility across
versions as much as possible. So, while F$LOGICAL() is no longer
documented, it remains present in the system.
Any new procedures that are developed should use the newer,
documented F$TRNLNM() lexical function.
24
Cluster-Wide Logical Names
New in V7.2.
Defined in table LNM$SYSCLUSTER
LNM$SYSTEM is now a search list:
$ show log/tab=* lnm$system

"LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY)
= "LNM$SYSCLUSTER"
1 "LNM$SYSCLUSTER" = "LNM$SYSCLUSTER_TABLE" (LNM$SYSTEM_DIRECTORY)
A new feature in OpenVMS V7.2 is the concept of cluster-wide logical

names. These are logical names that once DEFINEd on a node of the
cluster are propagated to the LNM$SYSCLUSTER_TABLE of all of the
nodes participating in the cluster.
To facilitate this without breaking any existing code, the LNM$SYSTEM
logical name was made a search list pointing first to the local systemwide logical name table (LNM$SYSTEM_TABLE) and then to the clusterwide logical name table. Note that LNM$SYSCLUSTER is a logical name
pointing to the table of cluster-wide logical names.
25

Caveat (pre-V8.2):
There is no /CLUSTER qualifier for DEFINE,

ASSIGN or DEASSIGN.
Use /TABLE=LNM$SYSCLUSTER
Note, however, that there is no additional qualifier provided for the

DEFINE, ASSIGN and DEASSIGN commands.
To create, maintain or delete cluster-wide logical names, specify
/TABLE=LNM$SYSCLUSTER in the command.
26

Caveat (all versions):
The LNM$SYSCLUSTER table is synchronized

across cluster nodes by a process which may or
may not have been started by the time the
LNM$SYSCLUSTER table is needed.
See the notes in SYLOGICALS.COM
The LNM$SYSCLUSTER table depends on inter-node communication for

synchronization.
The process which manages this synchronization may or may not be
started and functioning when you need to use the LNM$SYSCLUSTER
table in your system startup procedures.
See the notes in SYS$SYARTUP:SYLOGICALS.TEMPLATE for how to
determine whether the needed synchronization has completed before
attempting to use the LNM$SYSCLUSTER table at system startup time.
27
Logical Names
Notes:
VMS$COMMON usually not found in system logical
names.
It IS possible to have a system with a missing or
corrupted VMS$COMMON.
OpenVMS upgrades will fail.
Difficult to recover.
Running in this condition is not supported.
Note that the VMS$COMMON directory does not appear in the systemwide logical names setup and used by OpenVMS.
In fact it is possible to have a missing or corrupted VMS$COMMON
directory. The author of this presentation observed it in a running nonclustered system.
While the system will boot and run, OpenVMS upgrades will fail.
This situation is difficult to recover. Your best bet is to build a new system
disk and copy over the system-specific files as needed. This is a tedious
and time-consuming task, but it can be used as a last resort if
ANALYZE/DISK/NOREPAIR doesnt turn up the missing directory as a
lost file.
Running a system in this condition is probably not supported by
OpenVMS Support.
28
Logical Names
Leave OpenVMS-provided logical names alone.
ReDEFINE-ing things like SYS$SYSROOT can
jeopardize support position or system certification
(Healthcare, etc.)
If any of these are reDEFINEd, do it at the /PROCESS
level, not system-wide. Make sure to leave the system
account pristine.
In the abstract for this seminar, mention was made of adding a translation
to the SYS$SYSROOT search list. This is not a good idea, and the
author of this presentation does not advocate making any changes to
logical names provided by OpenVMS. It could cause problems with
OpenVMS support if a question comes up involving any such logical
names or any software that uses them. Also, from the perspective of the
healthcare world, this would constitute a significant change to the
operating environment and could raise questions regarding the
environments continued certification.
If reDEFINE-ing any of theses logical names could be helpful, be sure to
only do this at the /PROCESS level, not system-wide. Make sure to keep
the system accounts user environment as pristine as possible so as not
to raise any questions of supportability or certified environment
specifications.
29
Logical Names
Leave OpenVMS-provided logical names alone.
Probably okay to do this in a privileged account other
than SYSTEM.
If these are needed at SYSTARTUP_VMS time, invoke a
proc. to do the DEFINEs, invoke the proc.s that need the
local logical names, then clean up using
DEASSIGN/PROCESS.
Using DEFINE (/PROCESS is the default) in your own privileged account

to provide process-private logicals with the same name as those at the
system level would probably not raise any questions or problems.
However, should any support issues arise, you will likely be asked to try
to do without the private logical names by OpenVMS support.
You could use your private logical names at system startup time by first
invoking a procedure to create the process-private logical names, perform
whatever procedures require those logical names, then clean them up
using DEASSIGN (/PROCESS is the default).
OpenVMS provides certain logical names for its own use. It is best, in the
authors opinion, to operate within that framework and not try to bend the
rules. Such actions invariably come back to haunt you.
30
Logical Names
It is possible to organize your site-specific
procedures and keep them separated from the
OpenVMS files without reDEFINE-ing any logical
names provided by OpenVMS.
It is possible to organize your site-specific system management and/or

operational procedures and still keep them separated from those files
supplied by/with OpenVMS, without reDEFINE-ing any logical names that
OpenVMS provides.
Keeping your your site-specific system management and/or operational
procedures organized separately from the OpenVMS files is a very good
idea. This virtually guarantees that they will not be disturbed during a
system upgrade.
31
Logical Names
OpenVMS Logical Names:
Usually contain a $ (dollar sign).
User (Site-Specific) Logical Names

Avoid $ use underscore:
SYS_MANAGER
SYS_BACKUP
SYS_OPERATOR
SYS_HELP
SYS_ROOT
In logical names, symbol names, file names, etc., use of the dollar sign
($) is reserved to OpenVMS. User supplied names should use only
underscores as punctutaion.
Shown are some examples of user-supplied logical names that might
prove useful.
For example:
SYS_MANAGER
SYS_BACKUP
SYS_OPERATOR
SYS_HELP
Management procedures, software

startups, etc.
Backup procedures and files they use
Menus, VMSmail, etc.
Site-specific help libraries, documentation
Any of these logical names can be made search lists, and probably
should. For example, SYS_MANAGER could point first to the directory
where the local site-specific files reside, then to SYS$MANAGER.
Likewise, SYS_HELP could point first to the local site-specific help, then
to SYS$HELP.
32
Logical Names
$ sho log sys_*
(LNM$PROCESS_TABLE)
(LNM$JOB_80D128C0)
(LNM$GROUP_000030)
(LNM$SYSTEM_TABLE)
"SYS_BACKUP" = "SYS_ROOT:[BACKUP]"
"SYS_HELP" = SYS_ROOT:[SYSHLP]"
"SYS_MANAGER" = "SYS_ROOT:[SYSMGR]"
"SYS_OPERATOR" = "SYS_ROOT:[OPERATOR]
SYS_ROOT = SYS$SYSDEVICE:[XYZCORP.]
= SYS$SYSROOT:
As mentioned in the previous slide, any of these example site-specific

logical names can be made search lists.
In the example, SYS_MANAGER points first to the directory where the
local site-specific files reside, then to SYS$MANAGER. Likewise,
SYS_HELP points first to the local site-specific help, then to SYS$HELP.
In these cases, the local files will be found first, if their names duplicate
the name of a file found in the system directories. When the system is
searching for a file, as when you invoke or edit a procedure, the system
files will be found if no site-specific file matches the requested file
specification.
Notice that SHOW LOGICAL allows the use of wildcards. Since any
logical name table can have a lot of entries, this makes things a bit easier
to find.
33
Logical Names
Site-specific logical names for system
management can be organized in their own logical
name tables.
User Logical name table can be added to
LNM$FILE_DEV, but dont do that system-wide
DEFINE things /PROCESS.
See the earlier example of how to modify the LNM$FILE_DEV
search list for a process.
/PROCESS is the default for DEFINE and ASSIGN if not
specified.
While SHOW LOGICAL does support the use of wildcarded logical

names as we saw in the previous slide, you may still want to isolate sitespecific logical names for system management in their own logical name
table. One reason to do this might be that you can then set the protection
and/or ACL of the site-specific logical name table to deny access to
unprivileged users. This helps keep your environment secure.
In those privileged accounts that need access to these logical names, you
can reDEFINE the LNM$FILE_DEV search list as mentioned in an earlier
slide.
Again, as recommended in an earlier slide, do this at the process level, or
no higher than the group level if all of your privileged users have he same
group number in their UIC, and that group includes only privileged users
doing system management.
34
Logical Names
None of us is immortal.
Remember to document your customizations
THOROUGHLY!
If you get hit by a bus today, will someone else be able to come in
and understand what youve done?
Whatever system management scheme you come up with, consider the

plight of someone who may come after you. If you inherited an
operating environment from a previous SysAdmin, remember how you felt
when you had to figure out what had been done in the past.
Remember that none of us will be around forever, either biologically or
professionally. Not only are we mortal, but in these layoff-crazy days, any
of us can be turned out into the job market at the whim of management
on zero notice.
Remember to document your system management procedures
thoroughly. This may even be required by the local IS Auditors. When
you are away on holiday, out sick or otherwise not around, someone else
should be able to pick your notes and figure it out without having to spend
a lot of time exploring the system.
35
Session 1065
OpenVMS
Networking
36
Networking
Network stacks for OpenVMS:
TCP/IP
DECnet
Phase IV
Phase V (DECnet/OSI)
Utilities:
LANCP (works without DECnet)
SET HOST/MOP (Phase V - NET$CCR)
Lets switch gears here and start to look at networking on OpenVMS.

Originally, OpenVMS (it was called VAX/VMS at the time) provided only
DECnet, LAT and MOP. As the need to support TCP/IP evolved, Digital
provided the Ultrix Connection software we now know as UCX and
which has come to be known as TCP/IP Services for OpenVMS.
By that time, DECnet had evolved into its fourth major phase which is
why we call it DECnet Phase-IV.
About the same time as Digital was developing its early TCP/IP offerings,
it was also developing a new version of DECnet called DECnet/OSI for
Open Systems Interconnect, also known as DECnet Phase-V, now
known as DECnet-Plus.
DECnet-Plus was built around the OSI seven layer model and did not
include specifications for support of the proprietary LAT and MOP
protocols, nor did it provide extensive low-level (Layer 1) support. So
LANCP was developed to fill the MOP and low-level support niche.
37
Networking - TCP/IP
TCP/IP Services for OpenVMS
Formerly known as UCX (Ultrix Connection)
Developed, sold and supported by HP, shared code base
with Tru64 TCP/IP
Management interface somewhat weak.
Some features (like adding secondary name server and setting up
NTP) require editing config. files manually. Access to non-volatile
Database is inconsistent: sometimes SET CONFIG, sometimes
SET/PERMANENT.
TCP/IP Services for OpenVMS is the new official name for the software
that had come to be known as UCX. TCP/IP Services was renamed and
redeveloped so as to share a common code base with the TCP/IP stack
for Tru64.
While TCP/IP Services is developed and supported by the same
company produces OpenVMS, it does have some weaknesses.
TCP/IP Services management interface is somewhat inconsistent when
it comes to setting characteristics in the permanent database.
Sometimes the command form uses SET CONFIG (as contrasted with
just SET that effects only the volatile database) and sometimes the
command form requires a /PERMANENT qualifier to indicate that
something is being set in the non-volatile database.
Also, adding a secondary name server requires manually editing the
configuration files, since the management interface does not provide for
this.
38
Networking - TCP/IP
TCP/IP Services for OpenVMS
V5.4 High Performance Kernel was optional optimized
for SMP.
V5.5 uses this exclusively.
TCP/IP Services for OpenVMS V5.4 introduced the performance kernel

a set of images optimized for system with high CPU counts (optimized
for SMP). These were optional and were made available through a TIMA
kit.
V5.5 offers only the SMP optimized kernel images.
39
Networking TCP/IP
TCPware
Native to and developed on OpenVMS (originally on
VAX/VMS, ported to Alpha).
Developed, sold and supported by Process Software,
Inc.
Proprietary Management Interface, now similar to
Multinet in some ways.
Slightly more functionality than (UCX), performs better
than Multinet and UCX).
The TCPware product from Process Software was developed natively to

VAX/VMS and then ported to Alpha.
The TCPware management interface is proprietary and unlike DECnet.
Since Process Software now also owns the Multinet product, TCPwares
management interface is becoming more like that of Multinet.
TCPware provides some functionality that is not found in TCP/IP
services. However, discussion of the differences is outside the scope of
this presentation.
40
Networking - TCP/IP
Multinet
Developed from BSD V4.3 code by TGV, Inc. on
VAX/VMS, ported to Alpha. Now developed, sold and
supported by Process Software, Inc.
Proprietary Management Interface.
Functionality similar to TCPware.
The Multinet TCP/IP product is descended from 4.3BSD code and was
developed by a company called TGV on VAX/VMS. It was later ported to
Alpha. TGV sold Multinet to Cisco Systems, and Cisco sold it to Process
Software.
Multinets management interface is proprietary, but consistent. In general,
most functionality of the software is available through the management
interface without manually editing configuration files.
In general, Multinet enjoys feature parity with TCPware since the two
products are now owned and developed by the same company.
Multinet performance is somewhat better than that of UCX. However,
since TCPware is native to OpenVMS its performance is somewhat better
than that of Multinet or UCX.
41
Networking - TCP/IP
Multinet
Performance is less than TCPware.
Uses Direct I/O generates a lot of Interrupts. By
contrast, current UCX uses Buffered I/O.
Sites with high transaction volumes may need to
consider this.
Multinet performance is somewhat better than that of UCX in many

respects. However, since TCPware is native to OpenVMS its
performance is somewhat better than that of Multinet or UCX.
Sites with high transaction volumes should carefully analyze their
processing loads. Multinet uses Direct I/O which generates a great deal
of interrupts. This may pose a challenge in high-volume environments if
not managed carefully.
UCX uses Buffered I/O which does not generate hardware interrupts. It
may perform better in some environments. The SMP-optimized kernel
images help reduce MP-Synch loading, also. The two together may yield
significant benefits at the expense of functionality and manageability.
42
Networking - TCP/IP
CMU/IP
Freeware, a bit old.
Originally developed by TEK, released to Carnegie
Mellon Univ. C.S. department - became freeware.
VAX only - no known Alpha port.
TCP/IP-V4 only.
CMU/IP is a freeware TCP/IP stack for OpenVMS-VAX. It has never

been ported to Alpha.
CMU/IP is a bit old and does not provide much beyond the basic TCP/IP
end node functionality. Also, it is TCP/IP V4 only.
As of the date this presentation was prepared, CMU/IP was available on
the web at ftp://ftp.csus.edu/pub/cmuip. There may be other sources.
Search the Google archives of the comp.os.vms newsgroup for CMUIP,
CMU-IP or CMU/IP for more information.
43
Networking - DECnet
Developed by Digital for PDP-11, migrated to VAX,
ported to Alpha and I64.
Phase-IV is in use widely.
Phase V used where it is needed. Also known as
DECnet-Plus or DECnet/OSI.
DECnet is the original network stack available for OpenVMS. Its roots go
back to the days of the PDP/11 operating systems.
DECnet Phase-IV is still widely used, even though it has gone into mature
product support. DECnet-IV is very reliable and simple to manage. Just
set it and forget it, for the most part.
DECnet-V, known as DECnet-OSI and DECnet-Plus is used where the
functionality it provides is needed.
In general though, TCP/IP co-existence has been mandated due to the
need to consolidate onto a single network infrastructure and support
system.
44
Networking - DECnet
DECnet Phase IV
Very SysAdmin friendly, but takes some getting used to.
Set it and forget it - easily configured, does not issue a
lot of OPCOM messages unless there is trouble on the
line(s).
Specification was published, still publicly available on the
web. Google is your friend.
DECnet phase-IV has a fairly simple and straight-forward management

interface. The Network Control Program (NCP) uses SET commands to
modify the volatile database (in-memory database or the running
software) and DEFINE commands to modify the permanent database
(on-disk information used when the software is started).
Generally, DECnet-IV does not require a lot of daily attention. Line and
circuit counters can be zeroed daily if needed to track network issues, but
the software will run quite happily for extended periods without doing so.
DECnet-IV is very conservative about issuing OPCOM messages,
generally only on line and circuit transitions, adjacency transitions and
other noteworthy events.
The DECnet-IV specification was available from the old Digital web site
until recently. The open source community used it to develop a freeware
DECnet stack for Linux and *BSD. It no longer appears at the old URL.
45
Networking - DECnet
DECnet Phase IV
Permanent database
DEFINE commands in NCP
Volatile database
SET commands in NCP
DECnet-IVs management interface is simple and consistent. Information

pertaining to the executor (the DECnet kernel), network nodes, line,
circuits and DECnet objects is stored on disk and managed using
DEFINE and PURGE commands. The permanent data used when
starting up the DECnet software.
The running DECnet software, or the volatile database is modified using
SET and CLEAR commands. Generally, anything that can be DEFINEd
can also be SET. Even the on-line HELP for NCP reflects this.
46
Networking - DECnet
DECnet Phase IV
Provides MOP Remote Console
CONNECT command in NCP
Provides MOP downline load, upline dump

LOAD and TRIGGER commands in NCP
Provides for remote management of other nodes.

SET EXECUTOR NODE command in NCP, requires privilege and
remote password.
In DECnet-IV, you can connect to the remote console of devices

supporting MOP Remote Console using the CONNECT command in
NCP.
DECnet-IV also provides support for MOP downline load requests and
upline dump requests from terminal servers, remote VMS satellite nodes,
etc. Nodes supporting it can be TRiGGERed to request an downline load.
There is also a LOAD command available for those remote nodes that
support it.
DECnet-IV even provides for remote management of other DECnet
executors, within certain limits. The SET EXECUTOR NODE command
can be used to tell NCP that subsequent commands issued at he
command line should be sent to a remote node for execution. This allows
some management of remote DECnet nodes that support this function.
47
Networking - DECnet
DECnet Phase V (DECnet-Plus)
More complicated to manage - management paradigm
follows the OSI seven-layer model.
Circuits are built from the bottom up, following the OSI
seven-layer model.
Management is performed using NCL (Network Control
Language).
Non-volatile database is .NCL files - no permanent
database.
DECnet-V, also known as DECnet-Plus and DECnet-OSI takes a more

from the ground up approach to network management. It follows the
paradigm of the OSI seven-layer model for building the network by
configuring the software one layer at a time.
The DECnet-V management interface is the Network Control Language
(NCL) program.
Unlike DECnet-V, NCL has no permanent database - everything is done
in memory. DECnet-Vs permanent database consists of the NCL files
that are used at DECnet-V startup time to configure and start the
software.
Unlike DECnet-IV, DECnet-V is designed to handle a much broader
spectrum of objects. Hence, the NCL on-line HELP can be a bit confusing
and cryptic to those accustomed to NCP.
48
Networking - DECnet
DECnet Phase V (DECnet-Plus)
OPCOM messages are more plentiful and more verbose
than Phase IV.
Allows for diagnosis of trouble in each layer.
Provides some features not available in Phase IV.
Complete specification is not published.
DECnet-V issues a lot more OPCOM messages than DECnet-IV. Almost

all network events trigger an OPCOM message from starting the software
to configuring the software to normal network events like bursts of
collisions, and so on.
Because DECnet-V is designed around the seven layer model, the
messages issued can be used to diagnose trouble down to a specific
layer. So troubleshooting efforts can be more targetted.
There are some features and functionality in DECnet-V that are not
available in DECnet-IV. Most notably, DECnet-V is better suited to
DECnet -over-TCP/IP.
The complete Decnet-V specification has never been published, to the
knowledge of the author of this presentation.
49
Networking - DECnet
Access Control
Set up proxy records in
SYS$SYSTEM:NET$PROXY.DAT using the
AUTHORIZE program.
Enable proxy access in NCP (Phase-IV): incoming,
outgoing.
Incoming proxy access, if disabled, defaults to the access control
info of the target object instead of the source node/user.
DECnet Access Control focuses mostly on network proxies and object

security.
Decnet proxy records are maintained using the OpenVMS AUTHORIZE
program.
Remote access by proxy is configured in the NCP program for DECnetIV. If incoming proxy access is disabled, inbound access is instead
controlled by the access control information of the target object.
50
Networking - DECnet
Access Control
Create the proxy database if it doesnt already exist. Use
AUTHORIZE, CREATE/PROXY
Set up proxy records in Authorize.
Enable proxy access in NCL (Phase-V): See the SET
SESSION CONTROL statements.
In DECnet-V, as in DECnet-IV, you must first create the proxy database if

it doesnt already exist. This is done with the AUTORIZE program using
the CREATE/PROXY command. Then use AUTHORIZE to populate the
proxy database
Incoming and outgoing proxy access is controlled using SET SESSION
CONTROL statements in NCL.
See the DECnet-V Advanced Configuration documentation for
information concerning your specific needs. DECnet-V configuration is
outside the scope of this presentation.
51
Networking - DECnet
FAL Logging
Two Logical Names:

FAL$LOG
FAL$OUTPUT
FAL is the DECnet File Access Listener object. It gets started whenever a
remote DECnet node (or the local node) requests network access to a file
for any reason.
There are two undocumented logical names that can be used to expand
the logging information that comes out of the FAL process (FAL$LOG)
and to record that information someplace other than the default file
destination (FAL$OUTPUT).
52
Networking - DECnet
FAL Logging
FAL$LOG
In SYLOGIN or the DECnet object file:
$ DEFINE FAL$LOG 1/disable=8
This is an unsupported feature
1: file name and file type access information
disable=8 disables Poor Mans Routing:
$ dir node1::node2::node3::
The FAL logical name FAL$LOG should be setup in the SYS$SYLOGIN

procedure or in the DECnet object file, SYS$SYSTEM:FAL.COM
The value shown for this logical name has two functional parts.
The digit before the slash tells FAL what level of information logging to
use.
The string after the slash tells FAL to disable poor mans routing, where
a request is routed through multiple systems to achieve the same end as
having routing nodes where node exist (hence the name, since DECnetIV licenses greater than end-node are tarditionally more expensive than
end-node licenses).
53
Networking - DECnet
FAL Logging
FAL$LOG, contd
Produces copious output - use with discretion.
FAL$OUTPUT
Can be used to specify the name of the log file to create
in place of SYS$OUTPUT
$ DEFINE FAL$OUTPUT FAL.LOG
Depending upon the level of logging requested, FAL$LOG can produce

copious amounts of output and should be used with discretion to avoid
filling up a disk over weekend.
The other undocumented FAL logical name is FAL$OUTPUT. This one
can be used to specify that the output of FAL should go someplace other
than to the SYS$OUTPUT stream. Here again, DEFINE this logical name
in SYS$SYLOGIN or in the object file for FAL.
Note that the FAL object is typically just the FAL.EXE image. To utilize
these logical names without putting them in SYS$SYLOGIN, you can
make a FAL.COM procedure in the SYS$SYSTEM path to define the
logical names and then invoke FAL.
Another approach might be to put these logical names into the login script
of one or more accounts used for remote FAL access where you want
extended logging information for whatever reason.
54
Networking - UCX
Access Control
Trusted Relationships
Enable R services between nodes without having
passwords traverse the network as clear text.
Should be used between nodes on inside networks only
(inside the firewall), and then very judiciously.
Trusted relationships between nodes can be used to enable R (Remote)

services like RSHELL, REXEC, RCP, etc. without the need to have
passwords appear in programs or scripts, or traverse the network in clear
text.
This should, of course, only be used on systems which are behind the
firewall and not exposed directly to the internet or the DMZ.
55
Networking - UCX
Access Control
Trusted Relationships
No .RHOSTS or HOSTS.EQUIV files.
Use the ADD PROXY command in TCPIP$UCP.
Not well documented:
To make new proxies take effect, issue this command to
TCPIP$UCP:
$ TCPIP
TCPIP> SET TCP/SIGNAL
When setting up trusted relationships between OpenVMS nodes running

UCX (a.k.a. TCP/IP Services), use the ADD PROXY command in
TCPIP$UCP. UCX has no equivalent to either the .rhosts file or
hosts.equiv file found on some UN*X platforms.
See the on-line HELP for how to use the ADD PROXY command.
To activate recently entered proxies or deactivate recently deleted
proxies without rebooting and without bouncing UCX, use the SET
TCP/SIGNAL command in TCPIP$UCP, as shown.
This command does not appear to be documented. The information was
obtained from UCX Support after a call was opened inquiring as to why
entered proxies did not take effect.
56
Networking - LAT
LAT - Local Area Transport
Robust, Efficient
Can package data for multiple sessions at the same
MAC address into common packets.
Not routable
No routable info in the network layer
DEC-proprietary (licensed)
Specification published under license
LAT was commonly used for terminal server access prior to the rise of
TCP/IP and TELNET.
LAT is a very efficient and robust protocol. Data for multiple sessions at a
specific MAC address can be packed into a single packet to reduce
network overhead and make better use of the packet size.
LAT is not routable, however, as the packets contain no useful
information that would make routing useful or efficient.
LAT is a DEC-proprietary protocol. The specification is available only
under license. The Open Source community has made efforts to reverseengineer it.
57
Networking - LAT
LAT Control Program (LATCP)
Management interface for LAT
Controls services broadcast by an OpenVMS node

Used to create, manage and delete LTA devices
on OpenVMS nodes.
The program for managing LAT on OpenVMS is called LATCP. It is used

for setting up and controlling services broadcast by the node, as well to
setup and configure LTA devices which are used for reverse-LAT outbound connections to remote services or ports on servers for printers,
modems, terminals, etc.
58
Networking MOP
Maintenance Operation Protocol
Not routable
No routable info in the network layer
DEC-proprietary (licensed)
Specification published under license
Remote Console facility

Downline load, upline dump.
A service originally provide by the DECnet-IV executor and managed

using NCP is MOP, the Maintenance Operation Protocol.
Like LAT, MOP cannot be routed.
Like LAT, MOP is DEC-proprietary and the specification is subject to
license.
MOP provides for remote console capabilities, but also provides that
remote systems can receive their operating software from as a downline
load from a load host, or dump their memory up to an upline dump host.
59
Networking MOP
User interfaces - Remote Console:

NCP (DECnet Phase IV)
CONNECT NODE
CONNECT VIA circuit_id PHYS ADDR mac_addr
LANCP
CONNECT NODE name/DEVICE=enet_dev:
SET HOST/MOP (DECnet Phase V)

SET HOST/MOP node_name
SET HOST/MOP/ADDR=mac_addr/CIRC=xxxx
MOP now has three user interface programs at the DCL level:
In DECnet-IV, the NCP program still provides for remote console using
the CONNECT NODE and CONNECT VIA commands.
Even when DECnet is not installed, the LANCP and LANACP programs
are available.
DECnet-V provides for downline loading and upline dumping just like
DECnet-IV. However, remote console is provided by an extension to the
SET HOST command by way of an additional qualifier, /MOP. SET
HOST/MOP can use a known remote node name if the node is set up in
DECnet-V or it supports connecting using the MAC (/PHYSICAL) address
over a specified DECnet-V circuit.
60
Networking MOP
User interfaces - Downline Load, Upline dump:

NCP (DECnet Phase IV)
DEFINE/SET NODE name
ADDRESS xx.xxxxHARDWARE ADDRESS xx-xx-xx-xx-xx-xx
SERVICE CIRCUIT xxx-n
LOAD FILE filespec
SECONDARY LOADER filespec
DUMP FILE filespec
In DECnet-IV, downline load and upline dump are configured using the
DEFINE or SET NODE command.
As shown in the slide, the system needs to know the devices physical or
MAC address, the circuit over which service will be provided, and the
file(s) that should be sent if the device does not request a specific file.
Note also that for devices requesting a specific load file, any potential
load host which has the requested software and has service enabled can
service the load request. MOP does not provide for loading from only a
specific host.
61
Networking MOP
User interfaces - Downline Load:

LANCP
DEFINE NODE name /ADDRESS=xx-xx-xx-xx-xx-xx/FILE=filespec
Mostly for use in booting LAVc nodes
LANCP does not provide for upline dump
LANCP also provides for downline loading. This is mostly intended for
Local Area VMS cluster (LAVc) nodes. The LANCP terminology is DLL
(Down Line Load).
Upline dump is not provided.
Note that unlike the DECnet-IV executor, the LANACP will only answer
load requests for nodes that are in the node database. By contrast, the
DECnet-IV executor will answer any load request if the requested load file
is available.
LANCP is documented in the System Management Utilities A-L manual.
62
Networking - Remote Access

Types of remote Access:
DECnet
SET HOST (CTERM)
Remote File Access (FAL)
NML (NCP SET EXECUTOR NODE)
LAT
Connect (from terminal server or PC w/LAT)
SET HOST/LAT
There are many ways to access the system remotely. Outside of dial-up
access to a physical terminal port on the machine itself, DECnet provides
for remote terminal access via the CTERM protocol (SET HOST, no
qualifiers) and provides for remote access to files via the File Access
Listener (FAL). In NCP, you can access the DECnet-IV executor on
another node using the SET EXECUTOR NODE command. The portion
of DECnet used is called the Network Management Layer (NML).
LAT provides for remote connections from terminal servers, PCs that
have an LAT stack and other nodes running LAT. From an OpenVMS
system, you can connect to other systems and nodes that support LAT
using the SET HOST/LAT command. (Note that unlike SET HOST 0, you
cannot SET HOST/LAT to the local node.)
63
Networking - Remote Access

Types of remote Access, contd:
TCP/IP:
TELNET
Rshell / Rexec
Rlogin
RCP
SSH, SFTP, etc.
The Various TCP/IP stacks also provide for some common modes of
remote access, including Telnet, Remote Shell (RSHELL), Remote Login
(RLOGIN) and in the case of some of the newer versions of he TCP/IP
stacks for OpenVMS, Secure Shell, Secure FTP (SFTP) and Secure
Socket Layer are provided for along with Kerberos.
See the documentation or the vendor for your TCP/IP stack to see what
is currently available as this tends to change frequently as products
develop and evolve.
64
Networking - Remote Proc.s

Types of Remote Procedures:
DECnet
DECnet objects
SUBMIT/REMOTE, PRINT/REMOTE
TCP/IP
RPC (Remote Procedure Call)
Secure Socket Layer (SSL)
For remote procedure executon, DECnet provides objects that are

remotely accessible. The most notorious of these is the TASK object,
which is generally considered best left disabled unless absolutely
necessary. It represents an opportunity for some serious security risks.
Disabling the default DECNET account goes along way toward securing a
DECnet system.
Also on DECnet systems, the SUBMIT/REMOTE and PRINT/REMOTE
command provided for some remote access as well. These are very
restricted in their functionality in order to preserve security as much as
possible.
TCP/IP provides for Remote Procedure Call (RPC) and Secure Socket
Layer connections for various purposes. Refer to the documentation for
or the vendor of your TCP/IP stack(s) to determine the current states of
support and availability. Such information is beyond the scope of this
presentation.
65
Networking - Remote Proc.s

Security Concerns
DECnet objects like TASK
Unsecured accounts by any access method.

(This is not a security presentation.)
Again, the DECnet TASK object is best left out or disabled for security
reasons. If needed, care should be taken to keep your system as secure
as possible.
Regardless of how the system is accessed, unsecured accounts (no
password, weak passwords) represent a significant risk. Good system
management must include vigilance in this area.
In-depth security discussion is beyond the scope of this presentation,
although elements of OpenVMS security will be examined near the end of
this presentation.
66
Network Alerts
OPCOM Alerts for network access
SET AUDIT/ENABLE=CONNECTION
DECnet (Phase IV)
$IPC
SYSMAN
SET AUDIT/ENABLE=LOGIN=
ALL, BATCH, DETACHED, DIALUP, LOCAL,
NETWORK, REMOTE, SUBPROCESS
Simple things that can help alert the OpenVMS System Manager to
security issues include enabling Security Audits of incoming connections
via Telnet, CTERM, DECnet, etc.
In addition to login failures (LOGFAIL), successful logins can likewise be
audited to help ensure that everyones tracks can be followed, so to
speak. Here again, care must be taken to not audit too much so that disk
space and processing resources are not overly dedicated to security
issues, unless that is the purpose of the system.
67
Network Alerts
Additional OPCOM Alerts for FTP
Add commands to the DCL proc. associated with

the FTP service.
Example: MULTINET:FTP_SERVER.COM
Can be as general or specific needed.

See the documentation and example code for your
TCP/IP stack.
Additional OPCOM alerts can be set up for FTP using the service
procedures supplied with TCP/IP stack or by building your own wrapper
around the vendors scripts.
These can be as general or as specific as deemed necessary and/or
appropriate for each situation.
The best source of information is the vendor of your TCP/IP stack or FTP
server software.
68
Session 1065
System Startup
Procedure
69
System Startup
Default /STARTUP procedure:
SYS$SYSTEM:STARTUP.COM
Set using SYSBOOT, SYSGEN or SYSMAN.
Here we begin our discussion of the system startup procedures.

The procedure run as the STARTUP process on OpenVMS is the
procedure associated with the /STARTUP qualifier in SYSGEN, SYSMAN
or SYSBOOT.
For example, the command in SYSGEN or SYSBOOT would look like
this: SET/STARTUP filespec
In SYSMAN, the command is preceded by the PARAMETERS keyword:
SYSMAN> PARA SET/STARTUP filespec
70
System Startup
STARTUP Phases:
In SYS$STARTUP:VMS$VMS.DAT
RMS Indexed file
Changes to this area of the startup are *NOT* supported
by HP.
The OpenVMS startup procedure, SYS$SYSTEM:STARTUP.COM runs

in phases. These phases are setup in the VMS$VMS.DAT file.
This is an ordinary RMS indexed file.
Do NOT change this file as such changes may jeopardize your support
agreements.
71
System Startup
STARTUP Phases:
$ TY SYS$STARTUP:VMS$VMS.DAT
BASEENVIRON DVMS$BASEENVIRON-050_VMS.COM
E*BASEENVIRON DVMS$BASEENVIRON-050_SMISERVER.COM
E*BASEENVIRON DVMS$BASEENVIRON-050_LIB.COM
E*BASEENVIRON DDECDTM$STARTUP.COM
E*BASEENVIRON DLICENSE_CHECK.EXE
E*CONFIG
DVMS$CONFIG-050_VMS.COM
E*CONFIG
DVMS$CONFIG-050_ERRFMT.COM
E*CONFIG
DVMS$CONFIG-050_CACHE_SERVER.COM
E*CONFIG
DVMS$CONFIG-050_CSP.COM
E*CONFIG
DVMS$CONFIG-050_OPCOM.COM
E*CONFIG
DVMS$CONFIG-050_AUDIT_SERVER.COM
E*CONFIG
DVMS$CONFIG-050_JOBCTL.COM
E*CONFIG
DVMS$CONFIG-050_LMF.COM
E*CONFIG
DVMS$CONFIG-050_SHADOW_SERVER.COM
E*CONFIG
DVMS$CONFIG-050_SECURITY_SERVER.COM
E*DEVICES
DVMS$DEVICE_STARTUP.COM
E*INITIAL
DVMS$INITIAL-050_VMS.COM
E*INITIAL
DVMS$INITIAL-050_LIB.COM
E*INITIAL
CVMS$INITIAL-050_CONFIGURE.COM
E*LPBEGIN
DVMS$LPBEGIN-050_STARTUP.COM
E*PRECONFIG
DIPC$STARTUP.COM
E*PRECONFIG
DVMS$SPIRALOG_STARTUP.COM
E*
Heres a look at the contents of VMS$VMS.DAT.

You can see which procedures are executed and in what sequence - the
file is read sequentially.
72
System Startup Phases, Files

INITIAL
DEVICES
SYCONFIG
SYLOGICALS
SYPAGSWPFILES
PRECONFIG
CONFIG
SYSECURITY
BASEENVIRON
LPBEGIN
SYSTARTUP_VMS
LPMAIN
LPBETA
END
Heres a little more plain English presentation of how the startup

procedure progresses. The file names are indented from the phase
names in an effort to clarify the sequence of events.
73
System Startup Phases, Files

INITIAL
DEVICES
SYCONFIG
SYLOGICALS
SYPAGSWPFILES
These files are always

executed, even during a
MIN-imum boot.
PRECONFIG
CONFIG
SYSECURITY
BASEENVIRON
LPBEGIN
SYSTARTUP_VMS
LPMAIN
LPBETA
END
Note that even during a minimum boot, some procedures are always a
part of the startup sequence. It is best not to MOUNT disks in these
procedures unless it will always be okay to do so, even in a minimal
startup.
74
System Startup
Site-Specific STARTUPs:
In SYS$MANAGER path
SYSTARTUP_VMS.COM in V6 and later
SYSTARTUP_V5.COM in V5.x
SYSTARTUP.COM in V4 and earlier.
The site-specific startup procedure is executed during the LPBEGIN

phase of STARTUP.
For OpenVMS V6 and later, the site-specific system startup procedure is
SYS$MANAGER:SYSTARUP_VMS.COM.
For OpenVMS V5.5-2 and or VAX/VMS v5.x, the site-specific system
startup procedure is SYS$MANAGER:SYSTARTUP_V5.COM.
For VAX/VMS V4 and earlier, site-specific system startup procedure is
SYS$MANAGER:SYSTARTUP.COM.
Some folks simply use @SYS$MANAGER:SYSTARTUP in their
SYSTARTUP_VMS or SYSTARTUP_V5 procedure if the system has
been upgraded or migrated from earlier versions and/or architectures.
75
System Startup
STARTUP Parameters:
STARTUP_P1
blank - Normal System Startup
MIN - Minimal Startup
No SYSTARTUP_VMS but
Most of the other SY*.COM proc.s will still be run.
The STARTUP procedure accepts a couple of parameters. These are

derived from the values of the system parameters STARTUP_P1 through
STARTUP_P8. Currently, only P1 and P2 are used. The other are
reserved to OpenVMS engineering.
For a normal system startup, STARTUP_P1 is empty or blank. For
mininum startup, set STARTUP_P1 to MIN. Other values are available,
but reserved to OpenVMS enginerring for updates and such.
76
System Startup
STARTUP Parameters:
STARTUP_P2
blank - Normal System Startup
1, YES or TRUE - Verify on
STARTUP_P3 thru _P8

Reserved for future use
STARTUP_P2 is used to control DCL command verification during the

startup process. If STARTUP_P2 is empty or blank, verify is off or
false. If STARTUP_P2 is 1 or TRUE, verify is on.
STARTUP_P3 through STARTUP_P8 are reserved to OpenVMS
engineering for future use.
77
System Startup
SYSTARTUP_VMS :
Author prefers to keep procedure modular for

easier maintenance, invoke modules from
SYSTARTUP_VMS:
$ SET NOON
.
.
.
$ @MOUNT_DISKS
$ @DEFINE_GROUP_LOGICALS
The author of this presentation prefers to keep redundant, cut-andpaste code down to a bare minimum, and so advocates keeping the
system startup procedures modular.
This has multiple advantages.
Individual startup procedures can be run manually at anytime without
having to run the entire site-specific startup procedure.
Maintenance of individual procedures is eased by having less code to
wade through. Changes typically need to be done in only one place rather
than many.
Startups that differ between nodes can be separated by exploiting the
SYS$SYSROOT search list. Node-specific procedures can be placed in
node-specific roots while cluster common procedures can be placed in
the cluster common path. This allows for non-redundant code for
common events as well as node specific additions and exclusions.
78
System Startup
SYSTARTUP_VMS :
Author prefers to keep procedure modular for

easier maintenance, invoke node-specific proc.s
from SYSTARTUP_VMS:
$ FSP = F$SEARCH( SYS$MANAGER:SYSTARTUP.COM )
$ IF FSP .NES. THEN @&FSP
Avoids redundant, cut-and-paste code.
This slide illustrates a way to see if a particular startup element exists

before attempting to invoke it. This reduces the number of diagnostics
issued during the site-specific startup procedure and helps facilitate
reduction of redundant, cut-and-paste code.
79
System Startup
SYSTARTUP_VMS :
Logging SYSTARTUP_VMS:
$ SET NOON
$ DEFINE SYS$OUTPUT SYS$MANAGER:SYSTARTUP_VMS.LOG
.
.
.
$ DEASSIGN SYS$OUTPUT
This slide illustrates a trick for providing a log of events occurring during
the site-specific startup procedure.
Near the top of the procedure, insert a DEFINE SYS$OUTPUT
command. DCL will recognize this and direct subsequent output to the
file. A SET NOON helps insure that the procedure will run to completion
in spite of errors that may occur during it, and enables the procedure to
detect the success or failure of each element.
Near the bottom of the procedure, insert a DEASSIGN SYS$OUTPUT
command. DCL will detect this and close the file. SYS$OUTPUT data will
again show up on OPA0:.
80
System Startup
SYSTARTUP_VMS :
Logging SYSTARTUP_VMS:
Caveat: May not work with some application startups
Example: MiSys (Sunquest) FlexiLAB
(MUMPS application, runs in InterSystemss Cache RDB
environment)
Expects a response to a prompt, chokes on the log file as
SYS$OUTPUT.
System Startup logging by redirecting SYS$OUTPUT may not work as

expected with some application startups.
For example:
MiSyss FlexiLAB is MUMPS application and also runs under
InterSystems newest version of that environment known as Cache. At
startup time, the application startup expects a response to prompt asking
if a full startup should be done. The default answer is N or no. As a
result, when the SYS$OUTPUT stream is directed away from the console
terminal, the prompt errors out and the application does not start up.
A work-around for this has not yet been found.
81
System Startup
Saving/reporting a crash dump at System Startup
time:
$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP
COPY ddcu:<dir>:SAVEDUMP.DMP
! copy to wherever is convenient.
SET OUTPUT SYS$MANAGER:SYSDUMP.LIS ! Set this as you like

READ/EXEC
! READ SYS$SYSTEM:SYSDEF
! For VAX
READ SYS$LOADABLE_IMAGES:SYSDEF
! For Alpha
SHOW CRASH
SHOW STACK /ALL
SHOW SUMMARY
SHOW PROCESS /PCB /PHD /REGISTERS
SHOW SYMBOL /ALL
EXIT
This slide illustrates a method for performing preliminary crash dump

analysis at startup time. If the dump file contains a valid dump, the
remaining commands will execute; if not, the remaining commands will be
ignored.
82
System Startup
Saving/reporting a crash dump at System Startup time:
COPY in SDA only copies the portion of the dump file that was actually
written during the last dump.
The result is usually much smaller than the actual dump file, unless the
dump file is too small.
$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP
COPY ddcu:<dir>:SAVEDUMP.DMP
SET OUTPUT SYS$MANAGER:SYSDUMP.LIS
READ/EXEC
! READ SYS$SYSTEM:SYSDEF
READ SYS$LOADABLE_IMAGES:SYSDEF ! For Alpha
SHOW CRASH
SHOW STACK /ALL
SHOW SUMMARY
SHOW PROCESS /PCB /PHD /REGISTERS
SHOW SYMBOL /ALL
EXIT
! copy to wherever is convenient.

! Set this as you like
! For VAX
The COPY command in SDA copies only that portion of the dump file that
was actually written during the most recent dump. Thus, the COPY
destination can be significantly smaller than the dump file itself and can
more easily be FTPed to VMS Support for analysis.
83
System Startup
DEFINE-ing Group Logicals at Startup:
SET up a DCL procedure to DEFINE (or assign) the
needed logicals using /GROUP and whatever access
mode is appropriate.
Invoke that procedure as a detached process at system
startup time.
It is frequently necessary to define some group-level logical names at

system startup time. Trouble is, until a user in that group logs into the
system, the group logical name table doesnt yet exist.
This slide describes one approach to this. You can set up the groupspecific logical name definitions in a separate file and then run that
procedure as a detached process under that UIC at system startup time.
When the process exists, the group logical name table and its contents
will remain.
84
System Startup
Example:
$ RUN SYS$SYSTEM:LOGINOUT.EXE/UIC=[300,1]/INPUT=GROUP_300_LOGICALS.COM/OUTPUT=GROUP_300_LOGICALS.LOG
The UIC specified does not need to exist in the UAF.
Heres an example of the technique.

In this case, the group 300 specific logical name definitions are contained
in a DCL procedure called GROUP_300__LOGICALS.COM. That
procedure is run in a detached process under a group 300 UIC.
Note that the UIC specified need not actually exist in the UAF. Any UIC in
the target group will do.
Remember also that the group and member number elements of the UIC
are always octal numbers.
85
System Startup
Alternate Example:
$ RUN SYS$SYSTEM:LOGINOUT.EXE/UIC=[300,1]/INPUT=NLA0:/OUTPUT=NLA0:
The UIC specified does not need to exist in the UAF.

The example creates the LNM$GROUP_000300 table.
Logical names can then be created in that table by any
suitably privileged process.
Heres a variation on that technique.

In this case, the process is run with the null device as both the input and
output. The net effect of running the process is to create the desired
logical name table. Once created, the logical name table can be
populated by any suitably privileged process or procedure.
86
System Startup
Setting logins at Startup:
Global DCL symbol (STARTUP process) is set up

during SYS$STARTUP:VMS$BASEENVIRON050_VMS.COM:
$startup$interactive_logins == 64
A problem that has dogged VMS System Managers since the dawn of
VMS is to have the required number of interactive logins set at system
startup time.
Currently, a global DCL symbol (global to the STARTUP process) is set
up during SYS$STARTUP:VMS$BASEENVIRON-050_VMS.COM:
$startup$interactive_logins == 64. It is assigned an arbitrary value of 64,
which happens to also be the default value for the IJOBLIM system
parameter. IJOBLIM limits the number of interactive logins available at
any given time.
87
System Startup
Setting logins at Startup, contd:
Global DCL symbol (STARTUP process) is used in

SYS$STARTUP:VMS$LPBEGIN050_STARTUP.COM:
$set logins/interactive='startup$interactive_logins
This global DCL symbol is used in the procedure

SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM which is run
AFTER the site-specific startup procedure, SYSTARTUP_VMS.
So, the number of interactive logins to be allowed upon completion of the
system startup sequence can be manipulated by assigning the desired
value to startup$interactive_logins.
However, this has the drawback that unless a way is found to soft code
this value, the the site-specific startup procedure may need to be edited
in order to change it.
88
System Startup
Change the value of startup$interactive_logins

during SYSTARTUP_VMS:
$ startup$interactive_logins == F$GETSYI( IJOBLIM )
Illustrated here is a method of allowing the number of interactive logins

permitted after startup to be soft coded.
The value of IJOBLIM read in when the system parameters get loaded
does not change until SET LOGINS/INTERACTIVE=value occurs very
late in the startup sequence. So, the system parameters file can be used
as a source of the desired value for interactive logins allowed upon
completion of the startup.
89
System Startup
Notes:
Set the desired value for IJOBLIM in
MODPARAMS and run AUTOGEN, or change the
CURRENT value using SYSMAN or SYSGEN.
Change takes effect on next boot.
Set the desired or required value into the IJOBLIM parameter in

MODPARAMS.DAT as well as in the current system parameters (or edit
MODPARAMS.DAT, then run AUTOGEN through at least the
SETPARAMS phase).
Insert the code shown into the site-specific startup procedure, very late in
the procedure - near the end to help ensure it doesnt get changed by
anything else.
Upon your next startup, you will have the desired number of logins set
automatically and you can change it at anytime without having to edit the
site-specific startup procedure.
90
System Startup
Notes, contd:
IJOBLIM is a dynamic parameter. The SET
LOGINS/INTERACTIVE command displays or
varies its value. See the HELP.
Remember that IJOBLIM is a dynamic parameter. It is this parameter that

gets modified by the SET LOGINS/INTERACTIVE=value command. The
command with no value or without the /INTERACTIVE qualifier displays
the current number of logins and the number allowed.
91
System Startup
SET LOGINS/INTERACTIVE caveat:
Largely undocumented, little known fact: until this

command is issued for the first time after a reboot,
the job controller will not create interactive
processes.
If used in SYSTARTUP_VMS, it may enable logins
before the system is ready for users to log in.
Heres an important caveat regarding SET LOGINS/INTERACTIVE:

It is largely unknown and undocumented that the system job controller will
not create interactive process when OpenVMS is first booted until this
command is issued with a value. Once that happens, logins become
possible, even if the value specified is zero. Remember that suitably
privileged users can still login, even when logins are disabled by setting
them to zero.
If the site-specific startup procedure, or a procedure that it invokes
executes a SET LOGINS/INTERACTIVE=x command, this may result in
logins being enabled before the system is ready to have users log in.
Application errors and loss or corruption of data may be possible under
such circumstances.
TCP/IP Caveat:
Note that UCX and TCPware use the job controller to create interactive
processes as a result of a TELNET connect. Multinet, however, uses its
own MULTINET_SERVER process to do this. MULTINET_SERVER does
not observe this protocol, and so will produce interactive logins even
before they have been enabled by SET LOGINS/INTERACTIVE=n.
92
System Startup
SET LOGINS/INTERACTIVE caveat:
DO NOT USE THIS COMMAND IN

SYSTARTUP_VMS!!!
or any proc. that it invokes!!!

Use the global DCL symbol instead
(STARTUP$INTERACTIVE_LOGINS).
For the reason outlined in the notes on the previous slide, the author of
this presentation recommends that this command NEVER be used in the
site-specific startup procedure or any that it invokes. Use the global DCL
symbol instead.
93
System Startup - VMS Files
Must never be changed unless software

documentation or VMS support instructs you to do
so.
May be replaced when VMS or layered products

are upgraded.
May use deprecated lexical functions (like
F$LOGICAL()), or may contain misspelled function
names (like F$GETSYS(), DCL sees only
F$GETS).
Some other important notes about the system startup, files:

Never muck about with the DCL procedures and data files in the
SYS$STARTUP directories SYS$SYSROOT:[SYS$STARTUP] and
SYS$COMMON:[SYS$STARTUP]. They may quite likely be replaced on
the next OpenVMS or layered product upgrade or patch kit install.
Also, be careful about emulating anything you find in any of the startup
procedures provided with OpenVMS. They may use deprecated lexical
functions like F$LOGICAL() or may contain misspelled lexical function
names like F$GETSYS (should be F$GETSYI). DCL only looks at the
first four characters of the a command or function name, so these do not
cause problems now, but may result in errors later if DCL is ever
revamped in a major way.
94
System Startup - VMS Files
Site-specific startups are usually found in the

SYS$MANAGER path.
System startup files that are unique to a system or a cluster are usually
found in the SYS$MANAGER path.
The translation of the logical name SYS$MANAGER is
SYS$SYSROOT:[SYSMGR].
Since SYS$SYSROOT is a search list, care should be taken when setting
SYS$MANAGER as your default. If you are editing files, the revised
versions of those files will be written back to their original location. If
found in SYS$SPECIFIC:[SYSMGR], thats where the new version will be
written. If found in SYS$COMMON:[SYSMGR], thats where the new
version will be written. If you create a new file, and your default is set to
SYS$MANAGER, the new file will be created in the directory indicated by
the first element of SYS$MANAGER, namely the node-specific path.
Note that the translation of SYS$SPECIFIC is the same as the first
translation of the SYS$SYSROOT search list.
95
Session 1065
SYSMAN and
STARTUP
96
SYSMAN & STARTUP

SYSMAN can be used to modify the user portion
of the startup database.
Two database files used by SYSMAN:
STARTUP$STARTUP_VMS
Used for the VMS startup
DO NOT MODIFY !!!
STARTUP$STARTUP_LAYERED
When you add an item using SYSMAN it goes here.
The SYSMAN utility includes options to add items to the startup

sequence by entering records in the startup databse.
SYSMAN will modify the STARTUP$STARTUP_VMS file in the startup
database. However, this file should only be modified by OpenVMS
support or engineering, or by software or patch kits developed by them.
The OpenVMS system manager must never modify
STARTUP$STARTUP_VMS unless intsructed to do so by OpenVMS
support.
The STARTUP$STARTUP_LAYERED file in the startup database is the
correct place to make site-specific modifications to the startup database.
97
SYSMAN & STARTUP

SYSMAN can be used to modify the user portion
of the startup database.
Not as flexible the traditional method using
SYSTARTUP_VMS.
Not as widely used. Incoming SysAdmins may be unware
of previous modifications to the startup database using
SYSMAN.
Allows for specifying that some startup procedures run in
BATCH, in-line (DIRECT) or in sub-processes (SPAWN).
While SYSMAN does provide this ability, there are some caveats and
notes:
This method of entering site-specific startups into the startup sequence is
not as flexible as doing so from the site specific startup procedure.
Making startups conditional upon the success or failure of previous
startups becomes more cumbersome as does inserting startups that are
local to a node rather than common to the cluster.
This method of modifying the startup sequence is not as widely used or
as widely known. Those who come after you may have difficulty
understanding or supporting modifications to the startup database made
using SYSMAN.
The good news, however, is that SYSMAN provides for specifying that
procedures added this way should run detached, in batch, in a
subprocess or in-line (DIRECT).
98
SYSMAN & STARTUP

Allows for entering startup items that run after
SYSTARTUP_VMS.
SYSTARTUP_VMS is invoked during the LPBEGIN phase.
Valid phases for SYSMAN STARTUP entries are LPBEGIN,
LPMAIN, LPBETA and END.
Premature logins are possible if SYSTARTUP_VMS enables
logins before startups in later phases (LPMAIN, LPBETA or END)
have run.
SYSMAN allows for entering items into the startup sequence that run
after SYSTARTUP_VMS. So, these notes should be borne in mind when
planning and implementing startup modifications through SYSMAN:
SYSTARTUP_VMS is invoked during the LPBEGIN phase. This phase is
not executed in a minimal startup. Neither are any of the other LP
(Layered Product) phases.
Valid phases for startup sequence modifications entered using SYSMAN
are LPBEGIN, LPMAIN, LPBETA and END, in order of execution.
When adding a startup that occurs after SYSTARTUP_VMS is completed
be aware that SYSTARTUP_VMS, or a procedure that it invokes may
have enabled logins and users may already be accessing the system,
before the startup sequence is complete.
99
Session 1065
Conversational Boot,
Minimum Startup
100
Conversational Boot
HP Integrity Servers EFI Shell
Shell> set vms_flags x,1
or
Shell> fs0:\efi\vms\vms_loader.efi fl x,1
Using a shell alias:
Shell> alias b fs0:\efi\vms\vms_loader.efi
Shell> b fl x,1
Conversational boot is invoke by setting bit 0 of Register 5 before loading

the bootstraps.
On HP integrity servers, this is done by setting the EFI environment
variable vms_flags to an appropriate value in the familiar format,
root_number,flag_value.
On Alphas and VAX 7000s, this is done using the -fl[ags] x,1 qualifier,
were x is the nodes system root (0-FF).
101
Conversational Boot
Most Current Alphas, most old Alphas (including
Multia), VAX 7000:
>>> boot fl x,1
VAX 6000
>>> BOOT boot_profile/R5=1
>>> BOOT boot_profile/R5=x0000001
Older small VAXes

>>> B/R5:1 or B/R5:x0000001
VAX 8000s
See the manual
Conversational boot is invoke by setting bit 0 of Register 5 before loading

the bootstraps.
On VAX 6000s, add the /R5:value qualifier to the boot command after the
name of the boot profile, or just after the BOOT command if using the
default boot profile. VAX 6000s can only boot from roots 0 thru F.
Most older small VAXes (VAX 4000, MicroVAX, etc.) have console
variables for the boot device and the default boot flags. Just add the
appropriate variant of /R5:value.
For VAX 8000, 9000 and 10000, see the console documentation on how
to do this.
102
Minimum Boot
>>> b fl 10,1
SYSBOOT> SET STARTUP_P1 MIN
SYSBOOT> CONTINUE
Use SET WRITESYSPARAMS 0 before CONTINUE for a
one-time minimum boot.
Setting bit zero in Register 5 before loading the bootstraps causes

SYSBOOT to pause and prompt for input at the console. Hence, the
name: Conversational boot.
At the SYSBOOT prompt, you can modify system parameters, then
continue the boot up sequence.
For a minimum boot, SET the STARTUP_P1 parameter to MIN.
If the minimum boot is a one-time event, you can the SET the
WRITESYSPARAMS parameter to zero(0) to prevent the system from
saving the system parameters at boot time. The default value for this
parameter is one(1), write the system parameters at boot time, meaning
any changes you make in SYSBOOT will be saved in the current
parameter set.
To continue the boot up sequence, tell SYSBOOT to CONTINUE.
103
Session 1065
System Shutdown
Procedure
104
System Shutdown
$ @SYS$SYSTEM:SHUTDOWN
Prompts interactively for parameters
Parameters can also be specified on the command line
that invokes the procedure.
See the SHUTDOWN and REBOOT symbols in
SYS$MANAGER:LOGIN.TEMPLATE
Lets look now at the process of shutting down OpenVMS.

The provided DCL procedure is found as
SYS$SYSTEM:SHUTDOWN.COM. It should actually be found in the
cluster common path. This is provided by/with OpenVMS, and so should
not be modified except as instructed by OpenVMS support (which should
never happen).
SHUTDOWN prompts interactively for the shutdown parameters if none
are specified on the command line used to invoke SHUTDOWN.
Parameters to SHUTDOWN can also be specified on the command line
used to invoke SHUTDOWN. Two examples are found in the
SYS$MANAGER:LOGIN.TEMPLATE script template. Look for
SHUTDOWN and REBOOT in that file.
If you use these foreign commands, bear in mind that as supplied, they
do NOT execute the site-specific shutdown procedure.
105
System Shutdown
SYS$SYSTEM:SHUTDOWN.COM
Parameters:
P1 = Minutes to final shutdown
P2 = Reason for Shutdown
P3 = Spin down disk volumes? (Y/N)
P4 = Invoke SYSHUTDWN.COM? (Y/N)
P5 = When will system be rebooted?
P6 = Should auto. reboot be performed? (Y/N)
P7 = Options (SAVE_FEEDBACK, etc.)
P5 and P6 are reverse order to the prompts.
To modify the SHUTDOWN or REBOOT symbols, refer to the information

in the slide regarding the parameters that SHUTDOWN accepts from the
command line.
Notice that P5, when the system will be rebooted and P6, should an
automatic reboot be performed are in reverse order to the order of the
prompts issued by SHUTDOWN.
106
Site-Specific Shutdown Proc.

SYSHUTDWN.COM
Found in the SYS$MANAGER path.
Just as there is a site-specific startup procedure, there is also a sitespecific shutdown procedure. SYS$MANAGER:SYSHUTDWN.COM is
run as part of the SHUTDOWN sequence if this option is selected in
SHUTDOWN.
Use SYSHUTDWN to stop applications, databases, daemons, etc. that
may be holding files open. This provides that such software can be
shutdown gracefully instead of letting SHUTDOWN STOP them abruptly
later on in the SHUTDOWN sequence.
Like SYSTARTUP_VMS, the author recommends keeping SYSHUTDWN
modular so that individual shutdowns can be invoked at will for testing,
problem solving, etc.
107
System Shutdown
SYS$SYSTEM:SHUTDOWN.COM
Logical Names
SHUTDOWN$MINIMUM_MINUTES
Default value for minutes to final shutdown.
AGEN$SHUTDOWN_TIME
Used by AUTOGEN as minutes to final SHUTDOWN or
REBOOT.
SHUTDOWN$INFORM_NODES
Cluster nodes to receive REPLY messages from SHUTDOWN
SHUTDOWN$VERIFY
Allows SET VERIFY to be in effect during SHUTDOWN
In the minutes until shutdown prompt, a default value of zero is given.

This can be over-ridden with the SHUTDOWN$MINIMUM_MINUTES
logical name.
Also, if P1 to SHUTDOWN is specified as MINIMUM, the value of this
logical name is used as the time until final shutdown, or zero if the logical
is not DEFINEd.
The AUTOGEN procedure has its own logical name for the minutes until
final shutdown value that will be provided to SHUTDOWN by
AUTOGEN. The AGEN$SHUTDOWN_MINUTES logical name can be
used to provide a value for this; otherwise, AUTOGEN uses either
SHUTDOWN$MINIMUM_MINUTES or a default of zero(0).
108
Shutdown Options
REBOOT_CHECK
SAVE_FEEDBACK
DISABLE_AUTOSTART
POWER_OFF
The SHUTDOWN procedure allows for some shutdown options. The

options listed here are common to both clusters and non-clustered
systems.
These options are specified as a comma-separated list either interactively
or as P7 on the command line used to invoke SHUTDOWN. The option
names can be abbreviated. The author of this presentation recommends
using the option name up to the first underscore as a minimum
abbreviation.
In the next slides, well look at these options one by one.
109
Shutdown Options
REBOOT_CHECK
Performs a basic check for the existence of files

needed to reboot the system.
Not comprehensive - cannot detect a damaged

boot block, corrupted bootstrap image, etc.
The reboot check option performs some very basic checks for the
existence of some key files. Some examples include the APB or VMB
bootstraps, SYSBOOT and others.
Note, however, that this check is not comprehensive. It does not attempt
to detect corrupted or unreadable files, for instance, nor does it check the
integrity of the boot block. It can catch certain situations that would
prevent a successful reboot; the author has found this useful. The errors
were fixed and a successful shutdown and reboot was done.
110
Shutdown Options
SAVE_FEEDBACK
Saves some vital statistics about the system that

can be used by AUTOGEN after the system comes
back up.
Same as the SAVPARAMS phase of AUTOGEN.
The SAVE_FEEDBACK option does the same thing as the SAVPARAMS

phase of AUTOGEN. It allows that feedback information can be saved at
shutdown time allowing for AUTOGEN to be run using the saved
feedback at some later time.
111
Shutdown Options
DISABLE_AUTOSTART
Use this if needed to prevent AUTOSTART queues

on this node from failing over to this node from
another node.
DISABLE_AUTOSTART stops autostart queues on the node, and

prevents any queues from failing over to the node from another node in
the cluster.
112
Shutdown Options
POWER_OFF
If the system console supports it, request that the

machine power itself down once VMS has been
SHUTDOWN.
Some of the newer Alpha console subsystems allow for the hardware
system to be powered down under software control. The POWER_OFF
shutdown option was added to support this feature.
The POWER_OFF option is new as of OpenVMS V7.
113
Shutdown Options - Clusters
REMOVE_NODE for all but the last node.

Node exits the cluster gracefully.
CLUSTER_SHUTDOWN for the last cluster node

to be shutdown.
If used on all nodes, each node waits for other nodes to
reach the point of exiting the cluster, then proceeds to
shutdown (dissolves the cluster).
These two options are only displayed on a node which is a member of a

cluster.
Specify REMOVE_NODE to have a node exit the cluster gracefully. The
surviving nodes will recalculate quorum and then continue running after
the resulting cluster state transition, if the total of votes remaining is
greater than or equal to quorum.
When shutting down the last surviving node of a cluster, or to shutdown
all nodes of a cluster at the same time, specify the
CLUSTER_SHUTDOWN option. If you use this to shutdown all the nodes
of a cluster at the same time, each node will wait for the others to reach a
common point in the shutdown, then they will all shutdown together
gracefully dissolving the cluster.
114
Every Shutdown
Author recommends you always specify option

REBOOT_CHECK for all nodes.
Has been helpful in preventing some nasty

surprises.
A reminder that the REBOOT_CHECK option can be very helpful in

preventing problems, especially when a cluster or a system has run for
many months without being shutdown. While not 100% comprehensive, it
can detect some kinds of situations that may evolve in a long-uptime
system or cluster, such as key files getting deleted.
The Author of this presentation recommends always using the
REBOOT_CHECK option of SHUTDOWN based on personal experience.
115
Session 1065
AUTOGEN
116
AUTOGEN
SYS$UPDATE:AUTOGEN.COM
DCL procedure supplied by OpenVMS as an aid in

tuning the OpenVMS system.
Not a replacement for diligent system
management.
This presentation has mentioned the AUTOGEN procedure, so lets take

a look at it in a bit of detail.
AUTOGEN is a DCL procedure supplied by/with OpenVMS as an aid to
tuning the system and maintaining modifications to the system
parameters.
While AUTOGEN can point up some problems with proposed changes to
the system parameters, and can suggest other changes that may be
useful to maintain or improve performance, it is not a substitute for
diligent system management. You must still monitor your systems
performance and tune the system to maintain expected levels of
performance or service.
117
AUTOGEN
Applies changes to the default system parameters

as specified in the file
SYS$SYSTEM:MODPARAMS.DAT
Is invoked during installs and upgrades, sometimes

more than once.
Can be used to help size the swap and page files.
AUTOGEN applies changes to the system parameters as specified in the

SYS$SYSTEM:MODPARAMS.DAT file. The OpenVMS system manager
maintains MODPARAMS based on the need of the site, system or
cluster.
AUTOGEN is invoked during OpenVMS installation and upgrades,
sometimes more than once.
AUTOGEN calculates changes to the system parameters based on
entries in MODPARAMS, but can also suggest changes to the system
swap, page and dumpfiles based on the physical configuration and on
observed utilization of the system (feedback).
118
AUTOGEN - MODPARAMS
SYS$SYSTEM:MODPARAMS.DAT
This is where changes to the default values are

made so they persist from one AUTOGEN to the
next.
Entries look like this:

parameter_name = needed_value
MIN_parameter_name = needed_value
MAX_parameter_name = needed_value
ADD_ parameter_name = needed_value
MODPARAMS is the supported method for setting modifications to the

values of the system parameters. Values specified in MODPARAMS are
applied to the DEFAULT system parameters. So, changes are not
cumulative. Also, any changes made outside of MODPARAMS will be
wiped out by AUTOGEN.
AUTOGEN accepts your specified modifications and also calculates
changes to related parameters where appropriate.
There are four type of entries that can be made in MODPARAMS to
specify changes to the default values of the system parameters: hardcoded values, minimum values, maximum values and additional values.
119
AUTOGEN - MODPARAMS
parameter_name = needed_value
Provides a hard-coded value for the parameter.

SCSNODE = ALPHAONE
GBLPAGES = 121589
AUTOGEN calculations do not over-ride hardcoded values.
Hard-coded values are appropriate for some system parameters such as

the SCSNODE name, the SCSSYSTEMID, quorum disk name and
others.
In some cases, other parameters can be hard-coded, also. Generally, its
best to specify minimum values for many system parameters and let
AUTOGEN use higher values if it calculates that higher values would be
helpful.
In any case, the values that AUTOGEN calculates for system parameters
do not over-ride hard-coded value specified in MODPARAMS.
120
AUTOGEN - MODPARAMS
MIN_parameter_name = minimum_value
Provides a minimum value for the parameter.

MIN_GBLPAGES = 121589
AUTOGEN may calculate and use a higher value,

but will always use the MIN_ if it calculates a lower
value.
Sometimes, it is appropriate to specify a minimum value for some

parameters and let AUTOGEN use higher values for them, if AUTOGEN
determines that higher values would be helpful for performance reasons
or other reasons.
In these cases, use a MIN_ value in MODPARAMS. AUTOGEN will
reflect that the values of such parameters are not allowed to be lower
than the value specified for them in MODPARAMS.
121
AUTOGEN - MODPARAMS
MAX_parameter_name = maximum_value
Provides a maximum value for the parameter.

MAX_GBLPAGES = 12158900
AUTOGEN may calculate and use a lower value,

but will always use the MAX_ if it calculates a
higher value.
Some times, it is appropriate to specify a maximum value for some

parameters and let AUTOGEN use a lower value if it calculates that a
lower value is appropriate.
In these cases, use a MAX_ value in MODPARAMS. AUTOGEN will
reflect that the values of such parameters are not allowed to exceed the
value specified for them in MODPARAMS.
122
AUTOGEN - MODPARAMS
ADD_parameter_name = addtl_value
Provides an addition to the default value for the

parameter.
ADD_GBLPAGES = 81920
AUTOGEN can use feedback to calculate a new

value, then adds the specified value to the
calculated value.
In other cases, it may only be necessary to specify that AUTOGEN

should add a certain value to the calculated value of some parameters,
but otherwise allow AUTOGEN calculations to prevail.
In these cases, AUTOGEN will perform all of its usual calculations, then
add the specified value to the calculated value of such parameters.
For parameters not calculated by AUTOGEN, the value specified is
added to the default to arrive at the new value.
123
AUTOGEN - Phases
SAVPARAMS
GETDATA
GENPARAMS
TESTFILES
GENFILES
SETPARAMS
SHUTDOWN
REBOOT
- Collects Feedback
- Collects all other data
- Generates new parameters
- Calculates new sys file sizes
- Generates new system files
- Creates new boot param.s
- Shutdown the system
- Reboot the system
HELP
- Displays AUTOGEN info
AUTOGEN runs in phases that perform specific sub-tasks of the overall

AUTOGEN task.
The AUTOGEN phases are listed above. In the following slides, well
discuss these phases in some detail.
124
AUTOGEN - Phases
SAVPARAMS
Saves dynamic feedback from the running system.

Same as SAVE_FEEBACK option of SHUTDOWN.
The SAVPARAMS phase extracts the feedback information from the

running system. If the system uptime is less than twenty-four(24) hours,
AUTOGEN may complain about this.
Feedback includes some dynamic data from the running system that can
be used in later calculations to determine optimal values for certain
performance related system parameters.
SAVPARAMS does the same thing as the SAVE_FEEBACK option of
SHUTDOWN.
125
AUTOGEN - Phases
GETDATA
Collects all data to be used in AUTOGEN

calculations.
Includes existing feedback data if it is not over 30
days old.
Includes MODPARAMS info.
During the GETDATA phase, AUTOGEN collects all of the information

needed to perform its calculations. This includes validating the feedback
information, unless NOFEEDBACK is specified or the feedback
information is older than 30 days.
126
AUTOGEN - Phases
GENPARAMS
Performs calculations and generates the new system
parameters (but does not yet set them into the Current
parameters).
Creates the new list of installed images based on the state
of the currently running system.
During the GENPARAMS phase, AUTOGEN performs its calculations

and writes a list of changes that will be applied to the default system
parameters. This can be found in the SYS$SYSTEM path in the
SETPARAMS.DAT file.
AUTOGEN also creates a new list of images to be installed at systemstartup time during the GENPARAMS phase.
127
AUTOGEN - Phases
TESTFILES
Calculates new page and swap file sizes, but does not
apply any changes.
During the TESTFILES phase, AUTOGEN performs its calculations for

changes it will suggest to the sizes of the swap, page and dump files.
Only the calculations are performed no changes are actually applied in
the TESTFILES phase.
128
AUTOGEN - Phases
GENFILES
Generates new swap and page files based on AUTOGEN
calculations.
Use entries in MODPARAMS to override:
DUMPFILE=0
SWAPFILE=0
PAGEFILE=0
During the GENFILES phase, AUTOGEN will apply the changes it

calculates for the swap, page and dump files.
This can be over-ridden in MODPARAMS by supplying entries for the
swap, page and dumpfiles with zero(0) values.
These keywords can also be used to specify hard-coded values for the
sizes of these files. The hard-coded values will over-ride AUTOGENs
calculations.
129
AUTOGEN - Phases
SETPARAMS
Creates the new boot-time (current) parameters.
Changes take effect on the next boot.
During the SETPARAMS phase, the calculated changes to the default

system parameters are applied and saved as the current parameters to
be loaded next time the system boots. The ACTIVE parameter set is not
changed.
130
AUTOGEN - Phases
SHUTDOWN
Shutdown the system and leave it ready for a manual boot
or other console-level operations.
Caveat: Does *NOT* invoke SYSHUTDWN!
The SHUTDOWN phase allows AUTOGEN to shut the system down to

await a manual reboot, for performing operations at the console, for
power-down allowing hardware maintenance, etc.
A caveat about SHUTDOWN is that the site-specific shutdown procedure,
SYSHUTDWN is not executed during the SHUTDOWN phase of
AUTOGEN.
The SHUTDOWN and REBOOT phases of AUTOGEN invoke
SYS$SYSTEM:SHUTDOWN.COM.
131
AUTOGEN - Phases
REBOOT
Reboot the system using the newly generated parameters
and/or system files.
Caveat: Does *NOT* invoke SYSHUTDWN!
The REBOOT phase allows AUTOGEN to shut the system down and
specify that automatic reboot should be performed. This is what typically
happens at the end of an OpenVMS upgrade or install.
A caveat about REBOOT is that the site-specific shutdown procedure,
SYSHUTDWN is not executed during the REBOOT or SHUTDOWN
phase of AUTOGEN.
The SHUTDOWN and REBOOT phases of AUTOGEN invoke
SYS$SYSTEM:SHUTDOWN.COM.
132
AUTOGEN - Phases
HELP
Display HELP information for how to use AUTOGEN.
Useful to output this to a file:
$ @SYS$UPDATE:AUTOGEN/OUTPUT=AGEN_HELP.LIS HELP
There is no DCL HELP topic for AUTOGEN. However, there is a HELP

option for AUTOGEN which outputs some useful information on how to
use AUTOGEN.
It is useful to output this information to a file for future reference. Simply
specify /OUTPUT=filespec after @SYS$UPDATE:AUTOGEN and
specify HELP as the first parameter.
133
AUTOGEN - Phases
Typical uses:
See if current MODPARAMS settings are suitable:
$ @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES
Generate new system parameters for next boot:
$ @SYS$UPDATE:AUTOGEN SAVPARAMS SETPARAMS
AUTOGEN using previously saved feedback:
$ @SYS$UPDATE:AUTOGEN GENPARAMS SETPARAMS
Here are some typical examples of how to use AUTOGEN.

The first example shows how to use AUTOGEN to test the suitability of
your proposed parameter changes. No actual changes will be made to
the current parameter set; however, a new list of installed images is
generated and will be used on the next boot.
The second example shows how to use AUTOGEN to generate a new
current parameter set for use on the next boot. The running system is not
effected.
The third example show how to use AUTOGEN using feedback saved
earlier, either by the SAVE_FEEDBACK option of SHUTDOWN or by
running AUTOGEN with SAVPARAMS as both the starting and ending
phase.
134
AUTOGEN - Phases
Typical uses:
AUTOGEN ignoring feedback:
$ @SYS$UPDATE:AUTOGEN _$ GENPARAMS SETPARAMS NOFEEDBACK
AUTOGEN using previously saved feedback, if it is valid:
$ @SYS$UPDATE:AUTOGEN _$ GENPARAMS SETPARAMS CHECK_FEEDBACK
Two more examples of using AUTOGEN:

The first example here shows how to use AUTOGEN when the system
has not been up long enough to have any valid feedback. AUTOGEN is
run from the GENPARAMS phase through the SETPARAMS phase and
is told to use no feedback. The system can then be shutdown or rebooted
at a later time.
The second example here shows how to use AUTOGEN when youre not
certain of the validity of the feedback information. If the feedback
information is older than 30 days, AUTOGEN will not use it but will still
continue through the specified end phase. If P3 is not specified at all,
AUTOGEN will check the validity of the feedback and if it is suspect (too
old), AUTOGEN will adjust the ending phase to TESTFILES and allow
the system manager to take appropriate action.
135
AUTOGEN - Report
SYS$SYSTEM:AGEN$PARAMS.REPORT
Generated on each run of AUTOGEN during the
GENPARAMS phase.
Indicates any MODPARAMS errors detected by AUTOGEN.
Indicates the results of AUTOGEN calculations and
resulting changes to system parameters.
In peforming its calculations, AUTOGEN produces a report regarding

changes it makes to the default parameters to generate the new current
parameter set.
The AGEN$PARAMS.REPORT is generated in the SYS$SYSTEM path
on every run of AUTOGEN which includes the GENPARAMS phase.
Any errors or inconsistencies detected in MODPARAMS will be reported
in AGEN$PARAMS.REPORT.
136
AUTOGEN - Logging
AUTOGEN issues useful information on SYS$OUTPUT,
also.
Some SysAdmins find this useful:
$ @SYS$UPDATE:AUTOGEN/OUT=AGEN.LOG start_phase end_phase
AUTOGEN also produces some useful messages on its SYS$OUTPUT

stream.
A useful technique is to specify a log file as /OUTPUT when invoking
AUTOGEN, as shown in the slide.
137
Session 1065
Useful Tips
and Tricks
During our discussion of the system startup sequence, we looked at

some tips for logging the site-specific startup procedure, saving a crash
dump and doing a preliminary analysis, creating group-level logical
names and soft-coding the initial number of logins set during system
startup.
During our discussion of logical names, we looked at ways to modify the
logical name table search list for processes and groups of users and
ways to combine the OpenVMS-supplied logical names with our own to
help keep our system management and operational procedures separate
from the ones supplied by/with OpenVMS.
Here well look at a couple more tricks that may be useful.
138

An uptime command:
$ SHOW SYSTEM/NOPROCESS
$ UPT*TIME :== SHOW SYSTEM/NOPROCESS
Works in V6.2 and later.
A HELP enhancement, ala man | less:

$ HELP/PAGE=SAVE=64
$ MAN :== HELP/PAGE=SAVE=64
Before we begin talking about system management tools, here are a

couple of useful tips and tricks that can be helpful in the course of
everyday operations.
This slide presents a way to establish an uptime command like UN*X
has. SHOW SYSTEM/NOPROCESS shows only the banner line with no
process detail.
/NOPROCESS is new for SHOW SYSTEM since V6.2.
Also shown is a way to make HELP behave like the man command on
some flavors of UN*X which pipe the output through less or more.
HELP/PAGE=SAVE provides that you can scroll back through a long
HELP text without needing to be using a terminal program on a PC or
laptop. Using /PAGE=SAVE=64 provides a very good sized scroll-back
buffer (circa. 64 screens worth of text).
139

A simple command to show usage:
$ SHL :== PIPE SHOW USERS/FULL | (READ SYS$PIPE P9 ; WRITE SYS$OUTPUT P9 ; READ SYS$PIPE P9 ; WRITE SYS$OUTPUT P9 ; SET LOGINS)
This slide presents a way to establish a simple command to show how

many unique user names are logged in and how many processes those
users represent. The current interactive logion statistics are displayed as
well.
Because this uses the PIPE command, it only works on V7.x and later of
OpenVMS.
Here is an example of the output from this command:
$ shl
OpenVMS User Processes at 30-SEP-2002 11:33:56.56
Total number of users = 7, number of processes = 86
%SET-I-INTSET, login interactive limit = 350, current interactive value = 82
140

A simple command to show usage:
$ SHL
OpenVMS User Processes at 13-JUL-2006 20:22:50.09
This slide presents a way to establish a simple command to show how

many unique user names are logged in and how many processes those
users represent. The current interactive logion statistics are displayed as
well.
Because this uses the PIPE command, it only works on V7.x and later of
OpenVMS.
Here is an example of the output from this command:
$ shl
OpenVMS User Processes at 30-SEP-2002 11:33:56.56
141

A MORE command:
$ ipt := sys$input
$ if f$trnlnm( "sys$pipe" ) .nes. "" then $ ipt := sys$pipe
$ if p1 .eqs. "" then p1 = ipt
$ if f$type( more_pages ) .eqs. "" then $ more_pages = 64
$ type/page=save='more_pages' &p1
$ exit
This slide presents a way to establish a more command using

TYPE/PAGE=SAVE in a PIPE-line.
Note that the SYS$PIPE logical name exists only in the second or later
segment of a PIPE-line. This can be used detect whether the procedure
is being used as the target for PIPEd output and the input source for
TYPE can be selected accordingly.
The MORE_PAGES symbol can be defined in the users LGICMD, if
desired. In the slide, the code shown assumes a value of 64 for this
symbol if it is not present in the processs environment.
142

VMS Disk Partitions Logical Disks
Actual devices which use a container file or a specified
range of blocks on a disk to provide logical disk devices.
Need to install the LD V8 or later kit
See HELP LD after installing.
Available for V7.3-2 and later (Alpha and I64 only).
The LD Logical Disk software has been around as freeware from

Digital for many years. It provides the ability to use container files and
now ranges of disk blocks to provide logical disk devices that behave
more or less identically to a physical disk device.
The software is present but not supported or installed beginning with
V7.3-2. To achieve the full functionality, obtain the newer PCSI kit for LD
V8 from the OpenVMS freeware CD site. HELP is provided for the LD
command once the kit is installed.
Beginning with OpenVMS V8.2, LD becomes a supported part of the
operating system environment.
143

VMS Disk Partitions Logical Disks
Can be useful with disk storage arrays which are not easily
reconfigured. For example: EMC Symmetrix, DMX, etc.
Example
(Small Alpha with direct-attached RZ29B, 4.3GB SCSI disk):
$ ld connect dka100:/lbn=(start=0,count=3145728) lda1/allo=1
$ ld connect dka100:/lbn=(start=3145728,count=3145728) lda3
$ moun/noassi/syst dsa1/shad=($1$lda1,$1$lda2) shadow1 shadow1
$ moun/noassi/syst dsa2/shad=($1$lda3,$1$lda4) shadow2 shadow2
The LD Logical Disk software can be useful in environments where

very large but not easily reconfigured storage arrays are in use.
In such cases, large devices up to OpenVMSs current limitations can be
provided to the console and the operating system, and then carved up
using LD into smaller disk units.
In this scenario, care must be taken so that when used in a production environment the
I/O queue of the underlying physical disk unit is not being overtaxed resulting in I/O
contention. Provide a good number of large units so the I/O load can be spread out over
the physical devices provided by the array.
Take plentiful performance measurements in your development / test environment. This
may not be suitable for performance-critical environments. Field experience with this is
limited or non-existent. Use this with care.
144
Session 1065
OpenVMS
Security Elements
145
OpenVMS Security Elements

An OpenVMS system is only as secure as the
SysAdmin makes it.
Understanding and using the elements of
OpenVMS Security is the best way to help ensure
the security and integrity of an OpenVMS system.
System Security is an important job of the OpenVMS SysAdmin. The

system will only be as secure as the SysAdmin makes it. An
understanding of OpenVMS Security Elements will help the SysAdmin be
effective at keeping the system secure.
Effectively understanding and using the elements of OpenVMS Security
is the best way to help ensure the security of an OpenVMS system and
the security and integrity of the data it contains and processes.
This part of the presentation will look briefly at some of the key elements
of OpenVMS security. An in-depth security presentation may be available
as a technical breakout session in the symposium, or it may be presented
as full-day seminar at a future symposium.
146

Points to remember:
TELNET and FTP sessions are not encrypted,
passwords are sent as clear text. Use Secure Shell
and Secure FTP for best security.
LAT and DECnet are not encrypted, passwords are
sent as clear text.
Many forms of network access result in passwords being sent as clear

text. Among them are TELNET and FTP, to name only two. For the best
security, use Secure Shell and Secure FTP to help keep password
secure.
LAT and CTERM (DECnet SET HOST) do not provide for encryption.
User names and passwords are sent as clear text.
147

User Identification Codes
[group,user]
Similar to UN*X UIDs, except digits are always
octal.
Users belong to only one UIC group. Use Rights
Identifiers to grant additional access.
The first key element of OpenVMS security is the User Identification

Code or UIC. The protection masks assigned to object such as files,
devices, in-memory objects, etc. are all driven by the UIC.
Numeric UICs have only digits in the group and user (member) fields.
Where UIC identifiers exist, UICs are sometimes displayed as
Alphanumeric expressions such as [SYSTEM,SYSADMIN].
UICs are similar, but not identical, to UN*X UIDs.
Users belong to only one UIC group. If additional associations are
required, rights identifiers can be created and GRANTed to users as
needed.
148

Protection Masks
Based on the UIC.
Four classes of permission:
System
Owner
Group
World
UN*X only has Owner, Group, World
UIC-based protection masks provide four classes of permission or

access:
System
Owner
Group
World
System class users have a UIC group less than or equal to the value of
the system parameter MAXSYSGROUP.
The Owner class includes any user who has the UIC found in the owner
field of an object descriptor.
The Group class includes those users whose UIC group number matches
that of the owner.
The World class includes all users who do not match the other criteria.
UN*X has only the Owner, Group and World fields - the root (super)
user (almost) always has full access to everything.
149

Levels of Permission in each class:
Files
Read - Open read only
Write - Open write only
Execute - Run (if its a program/proc.)
Delete - Delete the file
(Requires write access to parent directory.)
For each class of user, there are four levels of permission.

For files:
Read access grants permission to open the file read-only.
Write access grants permission to open the file write-only.
Execute access grants permission to run a program (activate an image)
or execute a DCL procedure.
Delete access grants permission to delete a file (requires Write access to
the files parent directory).
Note that for OpenVMS-I64, executable images need both Read and
Execute access (RE).
150

Directories
Read - List files
Write - Create/delete files
Execute - Traverse the directory
(Look up files)
Delete - Delete the directory
(Requires Write access to parent).

For Directories:
Read access grants permission to list the contents of the directory.
Write Access grants permission to create or delete files in the directory.
Execute access grants permission to look up files in the directory.
Delete access grants permission to delete the directory (requires Write
access to the parent directory).
151

Devices
READ
WRITE
LOGICAL I/O
PHYSICAL I/O

For devices:
Read access grants permission to open a device read-only. No other
permission is granted.
For devices, Write access grants permission to open a device write-only.
No other permission is granted.
For devices, Logical I/O access grants permission to perform Logical I/O
to a device. No other permission is granted.
For devices, Physical I/O access grants permission to perform Physical
I/O to a device. No other permission is granted.
152

Queues
READ - Display queue, jobs
MODIFY - Modify queue, jobs
SUBMIT - SUBMIT/PRINT jobs
DELETE - Delete jobs or the queue

For Queues:
Read access grants permission to display characteristics of the queue or
a jobs in the queue.
Modify access grants permission to modify characteristics of the queue or
a jobs in the queue.
Submit access grants permission to submit jobs to the queue (SUBMIT or
PRINT).
Delete access grants permission to delete jobs in the queue or the queue
itself.
153

Access Control Lists
Specify access control beyond the UIC based
protections.
Consist of access control entries.
Access Control Lists (ACLs) are used to specify access permissions

beyond what the UIC based protect mask allows for.
ACLs consist of Access Control Entries (ACEs).
The OpenVMS Guide To System Security describes access control in
detail. The documentation is available on-line at this URL:
http://www.hp.com/go/openvms/doc
154

Access Control Entries
Associate access control with UICs or Rights
Identifiers
Levels of access:
READ
WRITE
DELETE
CONTROL
EXECUTE
Object owner always has CONTROL
Access Control Entries (ACEs) associate access permissions with UICs

or Rights Identifiers
ACEs can specify levels of access permission or permission to modify the
objects security profile (Control access). The owner of an object always
has Control access.
155

Rights Identifiers
Created using AUTHORIZE.
Can be associated with a resource (disk files - to
control disk quotas).
GRANTed to or REVOKEd from users using
AUTHORIZE.
Can be dynamic non-privileged users can
acquire and release using SET RIGHTS_LIST in
DCL.
Rights Identifiers for use in setting up Access Control Entries (ACEs) are
created and managed using the AUTHORIZE utility.
Identifiers can be simple identifiers or they can be associated with
common resources, such as to cause disk usage for a file to be charged
against a specific UICs disk quota. There are other types of identifiers
also, such as those associated with protected subsystems and those
associated with UICs.
Identifiers can be GRANTed to users or REVOKEd from users by using
AUTHORIZE program.
Note that identifiers can be dynamic - non-privileged users can acquire
and release them using the SET RIGHTS_LIST command in DCL.
156

Propagating ACEs, Default Protections
Set an ACE on a directory with the DEFAULT
attribute.
Default Protection ACE is set on a directory.
Will be applied to new files, or use SET
SECURITY/DEFAULT to propagate to existing
files.
Access Control Entries (ACEs) and default protection masks can be

propagated onto existing files in a directory tree. On the root directory of
a tree:
Set an ACE with the DEFAULT attribute.
Set a Default Protection ACE.
These will be applied to new file created in the root directory.
To propagate these ACEs onto all the files in the tree, use the SET
SECURITY/DEFAULT command with a wildcarded path.
Example:
$ SET SECURITY/DEFAULT ddcu:[root_level_directory]*.*;*
157

Set ACEs in the proper sequence
First matching ACE determines access.
Enter ACEs from least restrictive to most
restrictive. EDIT/ACL can be helpful.
ACL takes priority over UIC based protection mask.
The key to successful use of ACLs is to set ACEs in the proper

sequence.
When the system is determining access permission, only the first
matching ACE is used.
ACEs should be entered into the ACL starting with the least restrictive to
the most restrictive. The ACL Editor (EDIT/ACL) can be helpful for
objects that have large ACLs.
Note that the ACL takes priority over the UIC-based protection mask. If
the UIC-based protection grants access but the ACL doesnt, access to
the object will be denied.
158
Session 1065
Closing Comments,
Q&A
159
Freeware Sources
The OpenVMS Freeware CDs are online at the
OpenVMS website.
The DFWCUG DECUS CD-ROM Archive:
ftp://ftp.montagar.com/decus/
Here is a brief list of some sites where OpenVMS freeware (or links to it)
can be found.
The contents of the OpenVMS Freeware CDs V4 and V5 can be found on
line at the OpenVMS website.
The Dallas / Fort Worth LUG maintains an extensive archive of free
software and DECUS CDs.
Note that the ftp://ftp.montagar.com/ URLs were tested successfully with
an older Netscape (V4.77). The site was also accessed successfully
using the Multinet FTP client on OpenVMS. Attempts to access the site
using Internet Explorer V6 on Windows were less than successful.
160
Freeware Sources
OpenVMS FAQ
http://www.hp.com/go/openvms/faq
DJE Systems OpenVMS Freeware archive:
http://www.djesys.com/freeware/vms/
Links to other freeware sites can be found in the OpenVMS Frequently

Asked Questions (FAQ) which can be found at the URL shown.
DJE Systems also has some selected items available for download. Not
all of them are listed on our freeware page; however, they can be
downloaded by going to the URL shown above. Look for the following
files associated with this session at the URL shown above:
Session_1065.ppt
This PowerPoint Presentation
This session is based on a pre-symposium seminar given at HP/ETS2002 in St. Louis, Missouri (USA). The presentation and associated
freeware are available at the DJE Systems VMS Freeware archive:
4038_freeware.zip
Additional DCL tools from DJE Systems
seminar_1024_2002.zip
Arthur Cochranes original files and

PowerPoint slides
This presentation can be found on-line shortly after the symposium at this
URL: http://www.djesys.com/vms/support/
161
Session 1065
Thanks for coming!
Disclaimer: All information is correct to the best of
the authors knowledge.
Please fill out the evaluation forms, if available.
162

Open Vmss

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Open Vmss

Uploaded by

Copyright:

Available Formats

HP Technology Forum 2006

2006 DJE Systems, All rights reserved

This presentation is intended to be displayed or

When published with the Symposium Session

Logical name types

Lexical Function Caveat

In the newer versions of OpenVMS, Cluster-wide logical name tables

TCP/IP Services (fka UCX)

Continuing our discussion of the essential elements of the system and

Relevant to the discussion of networking is network access to OpenVMS.

SYSMAN and STARTUP

Having reviewed some of the essential elements of OpenVMS Systems

Useful Tips and Tricks

Closing Comments, Q & A

Finally, if time permits, well take a look at the essentials of OpenVMS

A form of symbol with limited or system-wide scope.

A feature that is more or less unique to OpenVMS is the concept of

Logical Name Tables

Logical names are organized in logical name tables.

Logical Name Tables

VMS provides that logical name tables can be searched by providing a

Logical Name Tables

Defines a new search list in supervisor mode.

It is possible to modify the search order specified in the LNM$FILE_DEV

Concealed Logical Names

Rooted Logical Names

Here we see examples of the various forms of logical names.

There are two DCL commands for creating logical names.

Logical names are DEFINEd is one of four access modes. More

Here we see a few examples of common single-translation logical names

Here we see an example of a commonly encountered system-wide logical

Here we see two examples of commonly encountered rooted logical

Logical Names & Lexicals

Something to watch out for here:

Cluster-Wide Logical Names

Defined in table LNM$SYSCLUSTER

LNM$SYSTEM is now a search list:

$ show log/tab=* lnm$system

A new feature in OpenVMS V7.2 is the concept of cluster-wide logical

Cluster-Wide Logical Names

There is no /CLUSTER qualifier for DEFINE,

Note, however, that there is no additional qualifier provided for the

Cluster-Wide Logical Names

The LNM$SYSCLUSTER table is synchronized

The LNM$SYSCLUSTER table depends on inter-node communication for

Using DEFINE (/PROCESS is the default) in your own privileged account

It is possible to organize your site-specific system management and/or

User (Site-Specific) Logical Names

Management procedures, software

As mentioned in the previous slide, any of these example site-specific

While SHOW LOGICAL does support the use of wildcarded logical

Whatever system management scheme you come up with, consider the

SET HOST/MOP (Phase V - NET$CCR)

Lets switch gears here and start to look at networking on OpenVMS.

TCP/IP Services for OpenVMS V5.4 introduced the performance kernel

The TCPware product from Process Software was developed natively to

Multinet performance is somewhat better than that of UCX in many

CMU/IP is a freeware TCP/IP stack for OpenVMS-VAX. It has never

DECnet phase-IV has a fairly simple and straight-forward management

DECnet-IVs management interface is simple and consistent. Information

Provides MOP downline load, upline dump

Provides for remote management of other nodes.

In DECnet-IV, you can connect to the remote console of devices