Advanced OpenVMS System Management Techniques … · Advanced OpenVMS System Management Techniques, Tools, ... Caveats SYS$COMMON Notes Caveats ... • Defines a new search list in

1

© 2006 DJE Systems, All rights reservedThe information contained herein is subject to change without notice

GET CONNECTEDPeople. Training. Technology.

HP Technology Forum 2006

Advanced OpenVMSSystem ManagementTechniques, Tools,and Tricks

DJE Systems - http://www.djesys.com/

David J. Dachtera - [email protected]

2

This presentation is intended to be displayed orprinted in the “Notes View” so it reads like a textbook.

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 Sessionnotes, this presentation might be converted to.PDF in the slide view only. Go to the URLshown to get the final PowerPoint presentation,then view it the way that works best for you.

3

AgendaLogical names

Logical name tables

Logical name table search orderModifying the search order

Logical name typesSingle Translation

Search list

“Rooted” (Concealed) logical names

Lexical Function CaveatF$TRNLNM() differs from F$LOGICAL()

Since much of the way the VMS environment works is driven by the useof logical names, we’ll spend a good bit of time talking about them.Questions “in real time” are encouraged during this discussion, and wecan always refer back to it as we proceed into those areas where logicalnames are used. This will provide an opportunity for reinforcementthrough practical examples.

We’ll also discuss a few “gotcha”’s regarding DCL lexical functions asthey relate to OpenVMS and system management.

4

AgendaLogical names, cont’d

Cluster-wide logical namesCaveats

SYS$COMMON NotesCaveats (VMS$COMMON)

Site-Specific PathsOrganizing local system management code

In the newer versions of OpenVMS, Cluster-wide logical name tableswere introduced. While these did not introduce any new complexity,working with them is not as straight-forward as it might appear at firstglance.

We’ll take a look at some practical examples of why the VMS$COMMONdirectory is rarely - if ever - used in the many logical names that thefamiliar OpenVMS environment depends on.

5

AgendaNetwork Topics

TCP/IPTCP/IP Services (fka UCX)

Multinet

TCPware

CMU/IP (VAX only)

DECnetAccess control

FAL logging

TCP/IP Services (fka UCX)Access control

Continuing our discussion of the essential elements of the system andsystem management, we’ll take a look at a brief overview of OpenVMSand networking.

We’ll look at the various TCP/IP stacks available for OpenVMS: threecommercial products for VAX and Alpha and a freeware piece forOpenVMS VAX only.

We’ll look at DECnet as well, and take a look at Access Control andlogging as well as some undocumented logical names can that be usedto modify the behavior of FAL logging.

6

AgendaNetwork Topics, cont’d

LAT

MOP

Remote Access

Remote proceduresTypes

Security concerns

Network AlertsOPCOM alerts for DECnet network access

OPCOM alerts for FTP network access

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

We’ll look at some of the types and methods of remote access offered bythe TCP/IP stacks, discuss some of he security concerns surroundingthem.

Then, we’ll look at ways to to provide expanded logging for DECnetaccess and access via FTP.

7

AgendaSystem Startup

STARTUP phases

STARTUP parameters

Site-Specific startupsLogging 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 Systemsand system management, we’ll start to look a bit deeper into the processof starting the OpenVMS operating environment.

We’ll look at how the OpenVMS-supplied procedures work so we canunderstand how to function within that framework. We’ll examine thevarious phases of the STARTUP procedure and the parameters it usesand observes.

In our discussion of site-specific startups, we’ll look at some tips andtricks for retaining a log of the site-specific startup, suggest some ways tomanage startups specific to a single node or group of nodes in a cluster,we’ll look at how to save crash dump information at system startup timeand we’ll at a method of soft-coding the number of logins allowed atsystem startup time.

In recent versions of VMS, the SYSMAN utility has acquired an interfaceto the OpenVMS-supplied system startup procedure which allows forsome customization. We’ll look into that in some detail, as well.

8

AgendaSystem Shutdown

SHUTDOWN parameters

SHUTDOWN$xxxx logical names

AUTOGEN ShutdownsAGEN$SHUTDOWN_TIME logical name

Cluster ShutdownREMOVE_NODE, CLUSTER_SHUTDOWN

Being able to startup the system is only half of the story. So, we’ll lookinto the system shutdown procedures as well.

We’ll look at the various parameters and options of the OpenVMS-supplied SHUTDOWN procedure, and some logical names that can beused to provide default values to certain SHUTDOWN parameters,including one that is used specifically by the AUTOGEN procedure.

OpenVMS clusters introduce some additional shutdown-timeconsiderations. So, we’ll look into those as well. The SYSMAN utilityprovides some functionality for system and cluster shutdown. We’ll lookat that as well.

9

AgendaAUTOGEN

MODPARAMS.DAT

Reports and outputs

Useful Tips and TricksAn 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, avenerable and trusted facility. As such, it contains some artifacts of itsheritage that are worthy of attention. We’ll take a look at those, since theycould lead to some confusion if used as a current-version example of howto program DCL procedures.

AUTOGEN is a useful tool for helping to keep OpenVMS systems in tuneand performing well. We’ll look at using AUTOGEN, setting values forsystem parameters in he MODPARAMS.DAT file, and we’ll look at thereports and outputs of AUTOGEN and how to use them.

10

AgendaOpenVMS 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, we’ll take a look at the essentials of OpenVMSSystem security and the various elements that make it work.

Additionally, we’ll look at third-party software and freeware that can beused to help secure your systems and access to them.

We’ll conclude with lists of sources for free- and open-source software forOpenVMS where one might find useful extensions for secure access toOpenVMS systems, as well as utilities and other helpful items.

11

Session 1065

OpenVMS

Logical Names

12

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 oflogical names. Similar features may be present in some mainframeoperating systems, also.

Simply stated, logical names provide a way to represent a device name, adevice name and a path name or even a device name and part of a pathname in a simple way so that software, files, etc. can be easily used onand moved from one system to another, to pass data to programs andprocedures or just for convenience.

13

Logical Name TablesLNM$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 tabledirectories at the highest or “root” levels.

As supplied, VMS has two primary logical name table hierarchies. Mostlogical name tables are found under the LNM$SYSTEM_DIRECTORY,as shown in he example in the slide. The LNM$PROCESS_DIRECTORYis private to each process on the system and cannot be viewed fromanother process except by accessing data structures via routines whichrequire privilege. This affords a degree of security for sensitiveinformation since it cannot be easily viewed by other users.

14

Logical Name TablesSearch 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 asearch list which is itself a logical name. The LNM$FILE_DEV logicalname indicates which logical names should be searched when theSHOW LOGICAL command is issued without the /TABLE qualifier orwhen a file is being opened or sought.

15

Logical Name TablesModifying 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_DEVlogical name. This can be done for individual processes, for entire UICgroups (requires GRPNAM privilege) or across the entire system (mayrequire SYSPRV, SYSNAM and CMEXEC privilege).

Note, however, that some software will only use logical names thatappear in certain logical name table directories or logical name tables orare DEFINEd in a privileged access mode. It is assumed that privilegedprograms and procedures are “trusted”, and thus that logical names theymay establish are similarly trust worthy.

16

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 non-privileged programs and procedures should not display the equivalencestring 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 referredto as “[000000]”, just as is the Master File Directory (MFD) of a diskvolume. The actual device name and root path are not displayed by non-privileged programs and procedures.

Some folks refer to rooted logicals as “pseudo disks” for that reason. Seealso discussion of Logical Disks later on in this presentation.

17

Logical NamesCreating

$ 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 andthe equivalence string(s) as the second parameter.

The ASSIGN command reverses the order of the parameters: theequivalence string(s) as the first parameter, and the logical name as thesecond parameter.

There is one DCL command for deleting logical names. The DEASSIGNcommand is used to delete logical names.

18

Logical NamesAccess 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” sinceprivilege is required to create them.

Logical names are DEFINEd is one of four “access modes”. Moreprivileged access modes are sometimes referred to as “inner” modes.

User mode logical names are the lowest and least privileged level. Usermode logical names are deleted when an image (a program) is run down(exits).

Supervisor mode is the default access mode for both DEFINE andASSIGN. Supervisor mode is also a low privilege level; however,supervisor mode logical names persist and are not deleted when animage (a program) is run down (exits).

Executive mode is similar to Supervisor mode, but requires CMEXECprivilege.

Kernel mode is the most privileged access mode. Kernel mode logicalnames can only be established by invoking the $CRELNM system servicewhich is only accessible within a program. There is no /KERNEL qualifierfor either the DEFINE or ASSIGN commands.

19

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 namesthat may be encountered on a running OpenVMS system.

20

Logical NamesSearch 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 ! Presenter’s 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 searchlists.

Under the translation of SYS$SYSROOT, we also see the translation ofone of its elements: SYS$COMMON. SYS$COMMON is a rooted logicalas is the first translation of SYS$SYSROOT.

The second example, USER_EXE is a search list that is set up in theenvironment of a specific user’s process. Under USER_EXE we see thetranslations of two of its elements, USER_IMG and USER_COM.

21

Logical NamesConcealed 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 logicalname.

SYS$SYSDEVICE is a concealed logical name created in executivemode.

SYS$SYSDEVICE also has the “Terminal” attribute which means thatafter translating SYS$SYSDEVICE no further translation be attemptedbeyond the equivalence string of SYS$SYSDEVICE (in this example,“DJAS01$DKA300:”).

22

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

The equivalence string of SYS$SPECIFIC includes the physical name ofthe system disk device and the node’s boot root (“[SYS0.]”).

The equivalence string of SYS$COMMON includes the physical name ofthe system disk device, the node’s boot root (“[SYS0.”) and the root-specific alias for the VMS$COMMON directory (“SYSCOMMON]”).

23

Logical NamesUsing 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 logicalnames.

SYS$SYROOT we saw in an earlier slide.

USER_ROOT we’ve seen before, also. Here we see how it is DEFINEd.

The USER_COM and USER_IMG logical names both use the rootedlogical name USER_ROOT.

24

Logical Names & LexicalsBeware:

F$LOGICAL() (deprecated) differs fromF$TRNLNM().

F$LOGICAL() uses hard-coded search listinternally: 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 byOpenVMS use the F$LOGICAL() lexical function. F$LOGICAL() has beendeprecated (made obsolete) and is no longer documented.

However, OpenVMS always attempts to maintain compatibility acrossversions as much as possible. So, while F$LOGICAL() is no longerdocumented, it remains present in the system.

Any new procedures that are developed should use the newer,documented F$TRNLNM() lexical function.

25

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 logicalnames. These are logical names that once DEFINEd on a node of thecluster are propagated to the LNM$SYSCLUSTER_TABLE of all of thenodes participating in the cluster.

To facilitate this without “breaking” any existing code, the LNM$SYSTEMlogical name was made a search list pointing first to the local system-wide logical name table (LNM$SYSTEM_TABLE) and then to the cluster-wide logical name table. Note that LNM$SYSCLUSTER is a logical namepointing to the table of cluster-wide logical names.

26

Cluster-Wide Logical NamesCaveat (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 theDEFINE, ASSIGN and DEASSIGN commands.

To create, maintain or delete cluster-wide logical names, specify/TABLE=LNM$SYSCLUSTER in the command.

27

Cluster-Wide Logical NamesCaveat (all versions):

• The LNM$SYSCLUSTER table is synchronizedacross cluster nodes by a process which may ormay not have been started by the time theLNM$SYSCLUSTER table is needed.− See the notes in SYLOGICALS.COM

The LNM$SYSCLUSTER table depends on inter-node communication forsynchronization.

The process which manages this synchronization may or may not bestarted and functioning when you need to use the LNM$SYSCLUSTERtable in your system startup procedures.

See the notes in SYS$SYARTUP:SYLOGICALS.TEMPLATE for how todetermine whether the needed synchronization has completed beforeattempting to use the LNM$SYSCLUSTER table at system startup time.

28

Logical NamesNotes:

VMS$COMMON usually not found in system logicalnames.

It IS possible to have a system with a missing orcorrupted 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 system-wide logical names setup and used by OpenVMS.

In fact it is possible to have a missing or corrupted VMS$COMMONdirectory. The author of this presentation observed it in a running non-clustered 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 systemdisk and copy over the system-specific files as needed. This is a tediousand time-consuming task, but it can be used as a last resort ifANALYZE/DISK/NOREPAIR doesn’t turn up the missing directory as alost file.

Running a system in this condition is probably not supported byOpenVMS Support.

29

Logical NamesLeave OpenVMS-provided logical names alone.

ReDEFINE-ing things like SYS$SYSROOT canjeopardize support position or system certification(Healthcare, etc.)

If any of these are reDEFINEd, do it at the /PROCESSlevel, not system-wide. Make sure to leave the systemaccount “pristine”.

In the abstract for this seminar, mention was made of adding a translationto the SYS$SYSROOT search list. This is not a good idea, and theauthor of this presentation does not advocate making any changes tological names provided by OpenVMS. It could cause problems withOpenVMS support if a question comes up involving any such logicalnames or any software that uses them. Also, from the perspective of thehealthcare world, this would constitute a significant change to theoperating environment and could raise questions regarding theenvironment’s continued certification.

If reDEFINE-ing any of theses logical names could be helpful, be sure toonly do this at the /PROCESS level, not system-wide. Make sure to keepthe system account’s user environment as “pristine” as possible so as notto raise any questions of supportability or certified environmentspecifications.

30

Logical NamesLeave OpenVMS-provided logical names alone.

Probably okay to do this in a privileged account otherthan SYSTEM.

If these are needed at SYSTARTUP_VMS time, invoke aproc. to do the DEFINEs, invoke the proc.’s that need thelocal logical names, then clean up usingDEASSIGN/PROCESS.

Using DEFINE (/PROCESS is the default) in your own privileged accountto provide process-private logicals with the same name as those at thesystem level would probably not raise any questions or problems.However, should any support issues arise, you will likely be asked to tryto do without the private logical names by OpenVMS support.

You could use your private logical names at system startup time by firstinvoking a procedure to create the process-private logical names, performwhatever procedures require those logical names, then clean them upusing DEASSIGN (/PROCESS is the default).

OpenVMS provides certain logical names for its own use. It is best, in theauthor’s opinion, to operate within that framework and not try to “bend therules”. Such actions invariably come back to haunt you.

31

Logical NamesIt is possible to organize your site-specificprocedures and keep them separated from theOpenVMS files without reDEFINE-ing any logicalnames provided by OpenVMS.

It is possible to organize your site-specific system management and/oroperational procedures and still keep them separated from those filessupplied by/with OpenVMS, without reDEFINE-ing any logical names thatOpenVMS provides.

Keeping your your site-specific system management and/or operationalprocedures organized separately from the OpenVMS files is a very goodidea. This virtually guarantees that they will not be disturbed during asystem upgrade.

32

Logical NamesOpenVMS Logical Names:

Usually contain a “$” (dollar sign).

User (Site-Specific) Logical NamesAvoid “$” – 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 onlyunderscores as “punctutaion”.

Shown are some examples of user-supplied logical names that mightprove useful.

For example:SYS_MANAGER Management procedures, software

startups, etc.SYS_BACKUP Backup procedures and files they useSYS_OPERATOR Menus, VMSmail, etc.SYS_HELP Site-specific help libraries, documentation…

Any of these logical names can be made search lists, and probablyshould. For example, SYS_MANAGER could point first to the directorywhere the local site-specific files reside, then to SYS$MANAGER.Likewise, SYS_HELP could point first to the local site-specific help, thento SYS$HELP.

33

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-specificlogical names can be made search lists.

In the example, SYS_MANAGER points first to the directory where thelocal 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 duplicatethe name of a file found in the system directories. When the system issearching for a file, as when you invoke or edit a procedure, the systemfiles will be found if no site-specific file matches the requested filespecification.

Notice that SHOW LOGICAL allows the use of wildcards. Since anylogical name table can have a lot of entries, this makes things a bit easierto find.

34

Logical NamesSite-specific logical names for systemmanagement can be organized in their own logicalname tables.

User Logical name table can be added toLNM$FILE_DEV, but don’t do that system-wide –DEFINE things /PROCESS.

See the earlier example of how to modify the LNM$FILE_DEVsearch list for a process.

/PROCESS is the default for DEFINE and ASSIGN if notspecified.

While SHOW LOGICAL does support the use of wildcarded logicalnames as we saw in the previous slide, you may still want to isolate site-specific logical names for system management in their own logical nametable. One reason to do this might be that you can then set the protectionand/or ACL of the site-specific logical name table to deny access tounprivileged users. This helps keep your environment secure.

In those privileged accounts that need access to these logical names, youcan reDEFINE the LNM$FILE_DEV search list as mentioned in an earlierslide.

Again, as recommended in an earlier slide, do this at the process level, orno higher than the group level if all of your privileged users have he samegroup number in their UIC, and that group includes only privileged usersdoing system management.

35

Logical NamesNone of us is immortal.

Remember to document your customizationsTHOROUGHLY!

If you get hit by a bus today, will someone else be able to come inand understand what you’ve done?

Whatever system management scheme you come up with, consider theplight of someone who may come after you. If you “inherited” anoperating environment from a previous SysAdmin, remember how you feltwhen you had to figure out what had been done in the past.

Remember that none of us will be around forever, either biologically orprofessionally. Not only are we mortal, but in these layoff-crazy days, anyof us can be turned out into the job market at the whim of managementon zero notice.

Remember to document your system management proceduresthoroughly. This may even be required by the local IS Auditors. Whenyou are away on holiday, out sick or otherwise not around, someone elseshould be able to pick your notes and figure it out without having to spenda lot of time exploring the system.

36

Session 1065

OpenVMS

Networking

37

NetworkingNetwork stacks for OpenVMS:

• TCP/IP

• DECnet− Phase IV

− Phase V (DECnet/OSI)

Utilities:

• LANCP (works without DECnet)

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

Let’s switch gears here and start to look at networking on OpenVMS.

Originally, OpenVMS (it was called VAX/VMS at the time) provided onlyDECnet, LAT and MOP. As the need to support TCP/IP evolved, Digitalprovided the “Ultrix Connection” software we now know as “UCX” andwhich has come to be known as TCP/IP Services for OpenVMS.

By that time, DECnet had evolved into its fourth major phase which iswhy 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, nowknown as DECnet-Plus.

DECnet-Plus was built around the OSI “seven layer model” and did notinclude specifications for support of the proprietary LAT and MOPprotocols, nor did it provide extensive low-level (Layer 1) support. SoLANCP was developed to fill the MOP and low-level support niche.

38

Networking - TCP/IPTCP/IP Services for OpenVMS

Formerly known as UCX (Ultrix Connection)

Developed, sold and supported by HP, shared code basewith Tru64 TCP/IP

Management interface somewhat weak.Some features (like adding secondary name server and setting upNTP) require editing config. files manually. Access to non-volatileDatabase is inconsistent: sometimes SET CONFIG, sometimesSET/PERMANENT.

TCP/IP Services for OpenVMS is the new official name for the softwarethat had come to be known as “UCX”. TCP/IP Services was renamed andredeveloped so as to share a common code base with the TCP/IP stackfor Tru64.

While TCP/IP Services is developed and supported by the samecompany produces OpenVMS, it does have some weaknesses.

TCP/IP Services’ management interface is somewhat inconsistent whenit comes to setting characteristics in the “permanent database”.Sometimes the command form uses SET CONFIG (as contrasted withjust SET that effects only the “volatile” database) and sometimes thecommand form requires a /PERMANENT qualifier to indicate thatsomething is being set in the non-volatile database.

Also, adding a secondary name server requires manually editing theconfiguration files, since the management interface does not provide forthis.

39

Networking - TCP/IPTCP/IP Services for OpenVMS

V5.4 “High Performance Kernel” was optional – optimizedfor 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 (optimizedfor SMP). These were optional and were made available through a TIMAkit.

V5.5 offers only the SMP optimized kernel images.

40

Networking TCP/IPTCPware

Native to and developed on OpenVMS (originally onVAX/VMS, ported to Alpha).

Developed, sold and supported by Process Software,Inc.

Proprietary Management Interface, now similar toMultinet in some ways.

Slightly more functionality than (UCX), performs betterthan Multinet and UCX).

The TCPware product from Process Software was developed natively toVAX/VMS and then ported to Alpha.

The TCPware management interface is proprietary and unlike DECnet.Since Process Software now also owns the Multinet product, TCPware’smanagement interface is becoming more like that of Multinet.

TCPware provides some functionality that is not found in TCP/IPservices. However, discussion of the differences is outside the scope ofthis presentation.

41

Networking - TCP/IPMultinet

Developed from BSD V4.3 code by TGV, Inc. onVAX/VMS, ported to Alpha. Now developed, sold andsupported by Process Software, Inc.

Proprietary Management Interface.

Functionality similar to TCPware.

The Multinet TCP/IP product is descended from 4.3BSD code and wasdeveloped by a company called TGV on VAX/VMS. It was later ported toAlpha. TGV sold Multinet to Cisco Systems, and Cisco sold it to ProcessSoftware.

Multinet’s management interface is proprietary, but consistent. In general,most functionality of the software is available through the managementinterface without manually editing configuration files.

In general, Multinet enjoys feature parity with TCPware since the twoproducts 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 betterthan that of Multinet or UCX.

42

Networking - TCP/IPMultinet

Performance is less than TCPware.

Uses Direct I/O – generates a lot of Interrupts. Bycontrast, current UCX uses Buffered I/O.

Sites with high transaction volumes may need toconsider this.

Multinet performance is somewhat better than that of UCX in manyrespects. However, since TCPware is native to OpenVMS itsperformance is somewhat better than that of Multinet or UCX.

Sites with high transaction volumes should carefully analyze theirprocessing loads. Multinet uses Direct I/O which generates a great dealof interrupts. This may pose a challenge in high-volume environments ifnot managed carefully.

UCX uses Buffered I/O which does not generate hardware interrupts. Itmay perform better in some environments. The SMP-optimized kernelimages help reduce MP-Synch loading, also. The two together may yieldsignificant benefits at the expense of functionality and manageability.

43

Networking - TCP/IPCMU/IP

Freeware, a bit old.

Originally developed by TEK, released to CarnegieMellon 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 neverbeen 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 onthe 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.

44

Networking - DECnetDeveloped 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 asDECnet-Plus or DECnet/OSI.

DECnet is the original network stack available for OpenVMS. It’s roots goback to the days of the PDP/11 operating systems.

DECnet Phase-IV is still widely used, even though it has gone into matureproduct support. DECnet-IV is very reliable and simple to manage. Justset it and forget it, for the most part.

DECnet-V, known as DECnet-OSI and DECnet-Plus is used where thefunctionality it provides is needed.

In general though, TCP/IP co-existence has been mandated due to theneed to consolidate onto a single network infrastructure and supportsystem.

45

Networking - DECnetDECnet Phase IV

Very SysAdmin friendly, but takes some getting used to.

“Set it and forget it” - easily configured, does not issue alot of OPCOM messages unless there is trouble on theline(s).

Specification was published, still publicly available on theweb. Google is your friend.

DECnet phase-IV has a fairly simple and straight-forward managementinterface. The Network Control Program (NCP) uses SET commands tomodify the volatile database (in-memory database or the runningsoftware) 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 andcircuit counters can be zeroed daily if needed to track network issues, butthe 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 andother noteworthy events.

The DECnet-IV specification was available from the old Digital web siteuntil recently. The open source community used it to develop a freewareDECnet stack for Linux and *BSD. It no longer appears at the old URL.

46


Permanent databaseDEFINE commands in NCP

Volatile databaseSET commands in NCP

DECnet-IV’s management interface is simple and consistent. Informationpertaining to the executor (the “DECnet kernel”), network nodes, line,circuits and DECnet objects is stored on disk and managed usingDEFINE and PURGE commands. The permanent data used whenstarting up the DECnet software.

The running DECnet software, or the “volatile” database is modified usingSET and CLEAR commands. Generally, anything that can be DEFINEdcan also be SET. Even the on-line HELP for NCP reflects this.

47


Provides MOP Remote ConsoleCONNECT command in NCP

Provides MOP downline load, upline dumpLOAD and TRIGGER commands in NCP

Provides for remote management of other nodes.SET EXECUTOR NODE command in NCP, requires privilege andremote password.

In DECnet-IV, you can connect to the remote console of devicessupporting MOP Remote Console using the CONNECT command inNCP.

DECnet-IV also provides support for MOP downline load requests andupline 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 thatsupport it.

DECnet-IV even provides for remote management of other DECnetexecutors, within certain limits. The SET EXECUTOR NODE commandcan be used to tell NCP that subsequent commands issued at hecommand line should be sent to a remote node for execution. This allowssome management of remote DECnet nodes that support this function.

48

Networking - DECnetDECnet Phase V (DECnet-Plus)

More complicated to manage - management paradigmfollows the OSI seven-layer model.

Circuits are built from the bottom up, following the OSIseven-layer model.

Management is performed using NCL (Network ControlLanguage).

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 theparadigm of the OSI seven-layer model for building the network byconfiguring 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 donein memory. DECnet-V’s “permanent database” consists of the NCL filesthat are used at DECnet-V startup time to configure and start thesoftware.

Unlike DECnet-IV, DECnet-V is designed to handle a much broaderspectrum of objects. Hence, the NCL on-line HELP can be a bit confusingand cryptic to those accustomed to NCP.

49

Networking - DECnetDECnet Phase V (DECnet-Plus)

OPCOM messages are more plentiful and more verbosethan 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. Almostall network events trigger an OPCOM message from starting the softwareto configuring the software to normal network events like bursts ofcollisions, and so on.

Because DECnet-V is designed around the seven layer model, themessages issued can be used to diagnose trouble down to a specificlayer. So troubleshooting efforts can be more targetted.

There are some features and functionality in DECnet-V that are notavailable in DECnet-IV. Most notably, DECnet-V is better suited toDECnet -over-TCP/IP.

The complete Decnet-V specification has never been published, to theknowledge of the author of this presentation.

50

Networking - DECnetAccess Control

− Set up proxy records inSYS$SYSTEM:NET$PROXY.DAT using theAUTHORIZE 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 objectsecurity.

Decnet proxy records are maintained using the OpenVMS AUTHORIZEprogram.

Remote access by proxy is configured in the NCP program for DECnet-IV. If incoming proxy access is disabled, inbound access is insteadcontrolled by the access control information of the target object.

51

Networking - DECnetAccess Control

− Create the proxy database if it doesn’t already exist. UseAUTHORIZE, CREATE/PROXY

− Set up proxy records in Authorize.

− Enable proxy access in NCL (Phase-V): See the SETSESSION CONTROL statements.

In DECnet-V, as in DECnet-IV, you must first create the proxy database ifit doesn’t already exist. This is done with the AUTORIZE program usingthe CREATE/PROXY command. Then use AUTHORIZE to populate theproxy database

Incoming and outgoing proxy access is controlled using SET SESSIONCONTROL statements in NCL.

See the DECnet-V Advanced Configuration documentation forinformation concerning your specific needs. DECnet-V configuration isoutside the scope of this presentation.

52

Networking - DECnetFAL Logging

• Two Logical Names:− FAL$LOG

− FAL$OUTPUT

FAL is the DECnet File Access Listener object. It gets started whenever aremote DECnet node (or the local node) requests network access to a filefor any reason.

There are two undocumented logical names that can be used to expandthe logging information that comes out of the FAL process (FAL$LOG)and to record that information someplace other than the default filedestination (FAL$OUTPUT).

53


• 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 Man’s Routing”:$ dir node1::node2::node3::

The FAL logical name FAL$LOG should be setup in the SYS$SYLOGINprocedure 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 touse.

The string after the slash tells FAL to disable “poor man’s routing”, wherea request is routed through multiple systems to achieve the same end ashaving routing nodes where node exist (hence the name, since DECnet-IV licenses greater than end-node are tarditionally more expensive thanend-node licenses).

54


• FAL$LOG, cont’dProduces copious output - use with discretion.

• FAL$OUTPUTCan be used to specify the name of the log file to createin place of SYS$OUTPUT

$ DEFINE FAL$OUTPUT FAL.LOG

Depending upon the level of logging requested, FAL$LOG can producecopious amounts of output and should be used with discretion to avoidfilling up a disk over weekend.

The other undocumented FAL logical name is FAL$OUTPUT. This onecan be used to specify that the output of FAL should go someplace otherthan to the SYS$OUTPUT stream. Here again, DEFINE this logical namein SYS$SYLOGIN or in the object file for FAL.

Note that the FAL object is typically just the FAL.EXE image. To utilizethese logical names without putting them in SYS$SYLOGIN, you canmake a FAL.COM procedure in the SYS$SYSTEM path to define thelogical names and then invoke FAL.

Another approach might be to put these logical names into the login scriptof one or more accounts used for remote FAL access where you wantextended logging information for whatever reason.

55

Networking - UCXAccess 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 havepasswords appear in programs or scripts, or traverse the network in cleartext.

This should, of course, only be used on systems which are “behind” thefirewall and not exposed directly to the internet or the “DMZ”.

56

Networking - UCXAccess Control

• Trusted RelationshipsNo .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 toTCPIP$UCP:$ TCPIPTCPIP> SET TCP/SIGNAL

When setting up trusted relationships between OpenVMS nodes runningUCX (a.k.a. “TCP/IP Services”), use the ADD PROXY command inTCPIP$UCP. UCX has no equivalent to either the .rhosts file orhosts.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 deletedproxies without rebooting and without bouncing UCX, use the SETTCP/SIGNAL command in TCPIP$UCP, as shown.

This command does not appear to be documented. The information wasobtained from UCX Support after a call was opened inquiring as to whyentered proxies did not take effect.

57

Networking - LATLAT - 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 ofTCP/IP and TELNET.

LAT is a very efficient and robust protocol. Data for multiple sessions at aspecific MAC address can be packed into a single packet to reducenetwork overhead and make better use of the packet size.

LAT is not routable, however, as the packets contain no usefulinformation that would make routing useful or efficient.

LAT is a DEC-proprietary protocol. The specification is available onlyunder license. The Open Source community has made efforts to reverse-engineer it.

58

Networking - LATLAT Control Program (LATCP)

• Management interface for LAT

• Controls services broadcast by an OpenVMS node

• Used to create, manage and delete LTA deviceson OpenVMS nodes.

The program for managing LAT on OpenVMS is called LATCP. It is usedfor setting up and controlling services broadcast by the node, as well tosetup and configure LTA devices which are used for “reverse-LAT” -outbound connections to remote services or ports on servers for printers,modems, terminals, etc.

59

Networking MOPMaintenance 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 managedusing NCP is MOP, the Maintenance Operation Protocol.

Like LAT, MOP cannot be routed.

Like LAT, MOP is DEC-proprietary and the specification is subject tolicense.

MOP provides for remote console capabilities, but also provides thatremote systems can receive their operating software from as a downlineload from a load host, or dump their memory up to an upline dump host.

60


• User interfaces - Remote Console:− NCP (DECnet Phase IV)

CONNECT NODE

CONNECT VIA circuit_id PHYS ADDR mac_addr

− LANCPCONNECT 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 usingthe CONNECT NODE and CONNECT VIA commands.

Even when DECnet is not installed, the LANCP and LANACP programsare available.

DECnet-V provides for downline loading and upline dumping just likeDECnet-IV. However, remote console is provided by an extension to theSET HOST command by way of an additional qualifier, /MOP. SETHOST/MOP can use a known remote node name if the node is set up inDECnet-V or it supports connecting using the MAC (/PHYSICAL) addressover a specified DECnet-V circuit.

61


• User interfaces - Downline Load, Upline dump:− NCP (DECnet Phase IV)

DEFINE/SET NODE name –ADDRESS xx.xxxx-HARDWARE 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 theDEFINE or SET NODE command.

As shown in the slide, the system needs to know the device’s physical orMAC address, the circuit over which service will be provided, and thefile(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 potentialload host which has the requested software and has service enabled canservice the load request. MOP does not provide for loading from only aspecific host.

62


• 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 forLocal 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 answerload requests for nodes that are in the node database. By contrast, theDECnet-IV executor will answer any load request if the requested load fileis available.

LANCP is documented in the System Management Utilities A-L manual.

63

Networking - Remote AccessTypes 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-upaccess to a physical terminal port on the machine itself, DECnet providesfor remote terminal access via the CTERM protocol (SET HOST, noqualifiers) and provides for remote access to files via the File AccessListener (FAL). In NCP, you can access the DECnet-IV executor onanother node using the SET EXECUTOR NODE command. The portionof DECnet used is called the Network Management Layer (NML).

LAT provides for remote connections from terminal servers, PCs thathave an LAT stack and other nodes running LAT. From an OpenVMSsystem, you can connect to other systems and nodes that support LATusing the SET HOST/LAT command. (Note that unlike SET HOST 0, youcannot SET HOST/LAT to the local node.)

64

Networking - Remote AccessTypes of remote Access, cont’d:

• TCP/IP:− TELNET

− Rshell / Rexec

− Rlogin

− RCP

− SSH, SFTP, etc.

The Various TCP/IP stacks also provide for some common modes ofremote access, including Telnet, Remote Shell (RSHELL), Remote Login(RLOGIN) and in the case of some of the newer versions of he TCP/IPstacks for OpenVMS, Secure Shell, Secure FTP (SFTP) and SecureSocket Layer are provided for along with Kerberos.

See the documentation or the vendor for your TCP/IP stack to see whatis currently available as this tends to change frequently as productsdevelop and evolve.

65

Networking - Remote Proc.’sTypes 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 areremotely accessible. The most notorious of these is the TASK object,which is generally considered best left disabled unless absolutelynecessary. It represents an opportunity for some serious security risks.Disabling the default DECNET account goes along way toward securing aDECnet system.

Also on DECnet systems, the SUBMIT/REMOTE and PRINT/REMOTEcommand provided for some remote access as well. These are veryrestricted in their functionality in order to preserve security as much aspossible.

TCP/IP provides for Remote Procedure Call (RPC) and Secure SocketLayer connections for various purposes. Refer to the documentation foror the vendor of your TCP/IP stack(s) to determine the current states ofsupport and availability. Such information is beyond the scope of thispresentation.

66

Networking - Remote Proc.’sSecurity 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 securityreasons. If needed, care should be taken to keep your system as secureas possible.

Regardless of how the system is accessed, unsecured accounts (nopassword, weak passwords) represent a significant risk. Good systemmanagement 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 ofthis presentation.

67

Network AlertsOPCOM 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 tosecurity issues include enabling Security Audits of incoming connectionsvia Telnet, CTERM, DECnet, etc.

In addition to login failures (LOGFAIL), successful logins can likewise beaudited to help ensure that everyone’s tracks can be followed, so tospeak. Here again, care must be taken to not audit too much so that diskspace and processing resources are not overly dedicated to securityissues, unless that is the purpose of the system.

68

Network AlertsAdditional OPCOM Alerts for FTP

• Add commands to the DCL proc. associated withthe FTP service.− Example: MULTINET:FTP_SERVER.COM

• Can be as general or specific needed.

• See the documentation and example code for yourTCP/IP stack.

Additional OPCOM alerts can be set up for FTP using the serviceprocedures supplied with TCP/IP stack or by building your own “wrapper”around the vendor’s scripts.

These can be as general or as specific as deemed necessary and/orappropriate for each situation.

The best source of information is the vendor of your TCP/IP stack or FTPserver software.

69

Session 1065

System Startup

Procedure

70

System StartupDefault /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 theprocedure associated with the /STARTUP qualifier in SYSGEN, SYSMANor SYSBOOT.

For example, the command in SYSGEN or SYSBOOT would look likethis: SET/STARTUP filespec

In SYSMAN, the command is preceded by the PARAMETERS keyword:

SYSMAN> PARA SET/STARTUP filespec

71

System StartupSTARTUP Phases:

• In SYS$STARTUP:VMS$VMS.DAT− RMS Indexed file

− Changes to this area of the startup are *NOT* supportedby HP.

The OpenVMS startup procedure, SYS$SYSTEM:STARTUP.COM runsin 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 supportagreements.

72

System StartupSTARTUP 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*

Here’s a look at the contents of VMS$VMS.DAT.

You can see which procedures are executed and in what sequence - thefile is read sequentially.

73

System Startup Phases, FilesINITIAL

DEVICESSYCONFIG

SYLOGICALS

SYPAGSWPFILES

PRECONFIG

CONFIGSYSECURITY

BASEENVIRON

LPBEGINSYSTARTUP_VMS

LPMAIN

LPBETA

END

Here’s a little more “plain English” presentation of how the startupprocedure progresses. The file names are indented from the phasenames in an effort to clarify the sequence of events.

74

System Startup Phases, FilesINITIAL

DEVICESSYCONFIG These files are always

SYLOGICALS executed, even during a

SYPAGSWPFILES “MIN”-imum boot.

PRECONFIG

CONFIGSYSECURITY

BASEENVIRON

LPBEGINSYSTARTUP_VMS

LPMAIN

LPBETA

END

Note that even during a minimum boot, some procedures are always apart of the startup sequence. It is best not to MOUNT disks in theseprocedures unless it will always be okay to do so, even in a minimalstartup.

75

System StartupSite-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 LPBEGINphase of STARTUP.

For OpenVMS V6 and later, the site-specific system startup procedure isSYS$MANAGER:SYSTARUP_VMS.COM.

For OpenVMS V5.5-2 and or VAX/VMS v5.x, the site-specific systemstartup procedure is SYS$MANAGER:SYSTARTUP_V5.COM.

For VAX/VMS V4 and earlier, site-specific system startup procedure isSYS$MANAGER:SYSTARTUP.COM.

Some folks simply use “@SYS$MANAGER:SYSTARTUP” in theirSYSTARTUP_VMS or SYSTARTUP_V5 procedure if the system hasbeen upgraded or migrated from earlier versions and/or architectures.

76

System StartupSTARTUP 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 arederived from the values of the system parameters STARTUP_P1 throughSTARTUP_P8. Currently, only P1 and P2 are used. The other arereserved to OpenVMS engineering.

For a normal system startup, STARTUP_P1 is empty or blank. Formininum startup, set STARTUP_P1 to “MIN”. Other values are available,but reserved to OpenVMS enginerring for updates and such.

77

System StartupSTARTUP 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 thestartup 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 OpenVMSengineering for future use.

78

System StartupSYSTARTUP_VMS :

• Author prefers to keep procedure modular foreasier maintenance, invoke modules fromSYSTARTUP_VMS:$ SET NOON

.

.

.

$ @MOUNT_DISKS

$ @DEFINE_GROUP_LOGICALS

The author of this presentation prefers to keep redundant, “cut-and-paste” code down to a bare minimum, and so advocates keeping thesystem startup procedures modular.

This has multiple advantages.

Individual startup procedures can be run manually at anytime withouthaving to run the entire site-specific startup procedure.

Maintenance of individual procedures is eased by having less code towade through. Changes typically need to be done in only one place ratherthan many.

Startups that differ between nodes can be separated by exploiting theSYS$SYSROOT search list. Node-specific procedures can be placed innode-specific roots while cluster common procedures can be placed inthe cluster common path. This allows for non-redundant code forcommon events as well as node specific additions and exclusions.

79


• Author prefers to keep procedure modular foreasier maintenance, invoke node-specific proc.’sfrom 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 existsbefore attempting to invoke it. This reduces the number of diagnosticsissued during the site-specific startup procedure and helps facilitatereduction of redundant, cut-and-paste code.

80


• 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 duringthe site-specific startup procedure.

Near the top of the procedure, insert a DEFINE SYS$OUTPUTcommand. DCL will recognize this and direct subsequent output to thefile. A SET NOON helps insure that the procedure will run to completionin spite of errors that may occur during it, and enables the procedure todetect the success or failure of each element.

Near the bottom of the procedure, insert a DEASSIGN SYS$OUTPUTcommand. DCL will detect this and close the file. SYS$OUTPUT data willagain show up on OPA0:.

81


• Logging SYSTARTUP_VMS:Caveat: May not work with some application startups

Example: MiSys (Sunquest) FlexiLAB

» (MUMPS application, runs in InterSystems’s Cache’ RDBenvironment)

» Expects a response to a prompt, chokes on the log file asSYS$OUTPUT.

System Startup logging by redirecting SYS$OUTPUT may not work asexpected with some application startups.

For example:

MiSys’s FlexiLAB is MUMPS application and also runs underInterSystem’s newest version of that environment known as Cache’. Atstartup time, the application startup expects a response to prompt askingif a full startup should be done. The default answer is “N” or “no”. As aresult, when the SYS$OUTPUT stream is directed away from the consoleterminal, the prompt errors out and the application does not start up.

A work-around for this has not yet been found.

82

System StartupSaving/reporting a crash dump at System Startuptime:

$ 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 dumpanalysis at startup time. If the dump file contains a valid dump, theremaining commands will execute; if not, the remaining commands will beignored.

83

System StartupSaving/reporting a crash dump at System Startup time:

COPY in SDA only copies the portion of the dump file that was actuallywritten during the last dump.

The result is usually much smaller than the actual dump file, unless thedump file is too small.

$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMPCOPY ddcu:<dir>:SAVEDUMP.DMP ! copy to wherever is convenient.SET OUTPUT SYS$MANAGER:SYSDUMP.LIS ! Set this as you likeREAD/EXEC! READ SYS$SYSTEM:SYSDEF ! For VAXREAD SYS$LOADABLE_IMAGES:SYSDEF ! For AlphaSHOW CRASHSHOW STACK /ALLSHOW SUMMARYSHOW PROCESS /PCB /PHD /REGISTERSSHOW SYMBOL /ALLEXIT

The COPY command in SDA copies only that portion of the dump file thatwas actually written during the most recent dump. Thus, the COPYdestination can be significantly smaller than the dump file itself and canmore easily be FTPed to VMS Support for analysis.

84

System StartupDEFINE-ing Group Logicals at Startup:

− SET up a DCL procedure to DEFINE (or assign) theneeded logicals using /GROUP and whatever accessmode is appropriate.

− Invoke that procedure as a detached process at systemstartup time.

It is frequently necessary to define some group-level logical names atsystem startup time. Trouble is, until a user in that group logs into thesystem, the group logical name table doesn’t yet exist.

This slide describes one approach to this. You can set up the group-specific logical name definitions in a separate file and then run thatprocedure as a detached process under that UIC at system startup time.When the process exists, the group logical name table and its contentswill remain.

85


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.

Here’s an example of the technique.

In this case, the group 300 specific logical name definitions are containedin a DCL procedure called GROUP_300__LOGICALS.COM. Thatprocedure 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 inthe target group will do.

Remember also that the group and member number elements of the UICare always octal numbers.

86


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 anysuitably privileged process.

Here’s a variation on that technique.

In this case, the process is run with the null device as both the input andoutput. The net effect of running the process is to create the desiredlogical name table. Once created, the logical name table can bepopulated by any suitably privileged process or procedure.

87

System StartupSetting logins at Startup:

• Global DCL symbol (STARTUP process) is set upduring SYS$STARTUP:VMS$BASEENVIRON-050_VMS.COM:$startup$interactive_logins == 64

A problem that has dogged VMS System Managers since the dawn ofVMS is to have the required number of interactive logins set at systemstartup time.

Currently, a global DCL symbol (global to the STARTUP process) is setup 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 systemparameter. IJOBLIM limits the number of interactive logins available atany given time.

88

System StartupSetting logins at Startup, cont’d:

• Global DCL symbol (STARTUP process) is used inSYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM:$set logins/interactive='startup$interactive_logins

This global DCL symbol is used in the procedureSYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM which is runAFTER the site-specific startup procedure, SYSTARTUP_VMS.

So, the number of interactive logins to be allowed upon completion of thesystem startup sequence can be manipulated by assigning the desiredvalue to startup$interactive_logins.

However, this has the drawback that unless a way is found to soft codethis value, the the site-specific startup procedure may need to be editedin order to change it.

89


• Change the value of startup$interactive_loginsduring SYSTARTUP_VMS:

$ startup$interactive_logins == -

F$GETSYI( “IJOBLIM” )

Illustrated here is a method of allowing the number of interactive loginspermitted after startup to be soft coded.

The value of IJOBLIM read in when the system parameters get loadeddoes not change until SET LOGINS/INTERACTIVE=value occurs verylate in the startup sequence. So, the system parameters file can be usedas a source of the desired value for interactive logins allowed uponcompletion of the startup.

90




Notes:

• Set the desired value for IJOBLIM inMODPARAMS and run AUTOGEN, or change theCURRENT value using SYSMAN or SYSGEN.Change takes effect on next boot.

Set the desired or required value into the IJOBLIM parameter inMODPARAMS.DAT as well as in the current system parameters (or editMODPARAMS.DAT, then run AUTOGEN through at least theSETPARAMS phase).

Insert the code shown into the site-specific startup procedure, very late inthe procedure - near the end to help ensure it doesn’t get changed byanything else.

Upon your next startup, you will have the desired number of logins setautomatically and you can change it at anytime without having to edit thesite-specific startup procedure.

91




Notes, cont’d:

• IJOBLIM is a dynamic parameter. The SETLOGINS/INTERACTIVE command displays orvaries its value. See the HELP.

Remember that IJOBLIM is a dynamic parameter. It is this parameter thatgets modified by the SET LOGINS/INTERACTIVE=value command. Thecommand with no value or without the /INTERACTIVE qualifier displaysthe current number of logins and the number allowed.

92


SET LOGINS/INTERACTIVE caveat:

• Largely undocumented, little known fact: until thiscommand is issued for the first time after a reboot,the job controller will not create interactiveprocesses.

• If used in SYSTARTUP_VMS, it may enable loginsbefore the system is ready for users to log in.

Here’s an important caveat regarding SET LOGINS/INTERACTIVE:

It is largely unknown and undocumented that the system job controller willnot create interactive process when OpenVMS is first booted until thiscommand is issued with a value. Once that happens, logins becomepossible, even if the value specified is zero. Remember that suitablyprivileged users can still login, even when logins are disabled by settingthem to zero.

If the site-specific startup procedure, or a procedure that it invokesexecutes a SET LOGINS/INTERACTIVE=x command, this may result inlogins being enabled before the system is ready to have users log in.Application errors and loss or corruption of data may be possible undersuch circumstances.

TCP/IP Caveat:

Note that UCX and TCPware use the job controller to create interactiveprocesses as a result of a TELNET connect. Multinet, however, uses itsown MULTINET_SERVER process to do this. MULTINET_SERVER doesnot observe this protocol, and so will produce interactive logins evenbefore they have been enabled by SET LOGINS/INTERACTIVE=n.

93


SET LOGINS/INTERACTIVE caveat:

• DO NOT USE THIS COMMAND INSYSTARTUP_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 ofthis presentation recommends that this command NEVER be used in thesite-specific startup procedure or any that it invokes. Use the global DCLsymbol instead.

94

System Startup - VMS Files• Must never be changed unless software

documentation or VMS support instructs you to doso.

• May be replaced when VMS or layered productsare upgraded.

• May use deprecated lexical functions (likeF$LOGICAL()), or may contain misspelled functionnames (like F$GETSYS(), DCL sees onlyF$GETS).

Some other important notes about the system startup, files:

Never muck about with the DCL procedures and data files in theSYS$STARTUP directories SYS$SYSROOT:[SYS$STARTUP] andSYS$COMMON:[SYS$STARTUP]. They may quite likely be replaced onthe next OpenVMS or layered product upgrade or patch kit install.

Also, be careful about emulating anything you find in any of the startupprocedures provided with OpenVMS. They may use deprecated lexicalfunctions like F$LOGICAL() or may contain misspelled lexical functionnames like F$GETSYS (should be F$GETSYI). DCL only looks at thefirst four characters of the a command or function name, so these do notcause problems now, but may result in errors later if DCL is everrevamped in a major way.

95

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 usuallyfound in the SYS$MANAGER path.

The translation of the logical name SYS$MANAGER isSYS$SYSROOT:[SYSMGR].

Since SYS$SYSROOT is a search list, care should be taken when settingSYS$MANAGER as your default. If you are editing files, the revisedversions of those files will be written back to their original location. Iffound in SYS$SPECIFIC:[SYSMGR], that’s where the new version will bewritten. If found in SYS$COMMON:[SYSMGR], that’s where the newversion will be written. If you create a new file, and your default is set toSYS$MANAGER, the new file will be created in the directory indicated bythe first element of SYS$MANAGER, namely the node-specific path.

Note that the translation of SYS$SPECIFIC is the same as the firsttranslation of the SYS$SYSROOT search list.

96

Session 1065

SYSMAN and

STARTUP

97

SYSMAN & STARTUPSYSMAN can be used to modify the “user” portionof 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 startupsequence by entering records in the startup databse.

SYSMAN will modify the STARTUP$STARTUP_VMS file in the startupdatabase. However, this file should only be modified by OpenVMSsupport or engineering, or by software or patch kits developed by them.The OpenVMS system manager must never modifySTARTUP$STARTUP_VMS unless intsructed to do so by OpenVMSsupport.

The STARTUP$STARTUP_LAYERED file in the startup database is thecorrect place to make site-specific modifications to the startup database.

98

SYSMAN & STARTUPSYSMAN can be used to modify the “user” portionof the startup database.− Not as flexible the traditional method using

SYSTARTUP_VMS.

− Not as widely used. Incoming SysAdmins may be unwareof previous modifications to the startup database usingSYSMAN.

− Allows for specifying that some startup procedures run inBATCH, in-line (DIRECT) or in sub-processes (SPAWN).

While SYSMAN does provide this ability, there are some caveats andnotes:

This method of entering site-specific startups into the startup sequence isnot as flexible as doing so from the site specific startup procedure.Making startups conditional upon the success or failure of previousstartups becomes more cumbersome as does inserting startups that arelocal to a node rather than common to the cluster.

This method of modifying the startup sequence is not as widely used oras widely known. Those who come after you may have difficultyunderstanding or supporting modifications to the startup database madeusing SYSMAN.

The good news, however, is that SYSMAN provides for specifying thatprocedures added this way should run detached, in batch, in asubprocess or in-line (DIRECT).

99

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 enableslogins before startups in later phases (LPMAIN, LPBETA or END)have run.

SYSMAN allows for entering items into the startup sequence that runafter SYSTARTUP_VMS. So, these notes should be borne in mind whenplanning and implementing startup modifications through SYSMAN:

SYSTARTUP_VMS is invoked during the LPBEGIN phase. This phase isnot executed in a minimal startup. Neither are any of the other “LP”(Layered Product) phases.

Valid phases for startup sequence modifications entered using SYSMANare LPBEGIN, LPMAIN, LPBETA and END, in order of execution.

When adding a startup that occurs after SYSTARTUP_VMS is completedbe aware that SYSTARTUP_VMS, or a procedure that it invokes mayhave enabled logins and users may already be accessing the system,before the startup sequence is complete.

100

Session 1065

Conversational Boot,

Minimum Startup

101

Conversational BootHP Integrity Servers – EFI ShellShell> 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 loadingthe bootstraps.

On HP integrity servers, this is done by setting the EFI environmentvariable “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 node’s system root (0-FF).

102

Conversational BootMost Current Alphas, most “old” Alphas (includingMultia), 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 8000’sSee the manual

Conversational boot is invoke by setting bit 0 of Register 5 before loadingthe bootstraps.

On VAX 6000s, add the /R5:value qualifier to the boot command after thename of the boot profile, or just after the BOOT command if using thedefault boot profile. VAX 6000s can only boot from roots 0 thru F.

Most older small VAXes (VAX 4000, MicroVAX, etc.) have consolevariables for the boot device and the default boot flags. Just add theappropriate variant of /R5:value.

For VAX 8000, 9000 and 10000, see the console documentation on howto do this.

103

Minimum Boot>>> b –fl 10,1

SYSBOOT> SET STARTUP_P1 “MIN”

SYSBOOT> CONTINUE

Use SET WRITESYSPARAMS 0 before CONTINUE for aone-time minimum boot.

Setting bit zero in Register 5 before loading the bootstraps causesSYSBOOT to pause and prompt for input at the console. Hence, thename: “Conversational boot”.

At the SYSBOOT prompt, you can modify system parameters, thencontinue 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 theWRITESYSPARAMS parameter to zero(0) to prevent the system fromsaving the system parameters at boot time. The default value for thisparameter is one(1), write the system parameters at boot time, meaningany changes you make in SYSBOOT will be saved in the currentparameter set.

To continue the boot up sequence, tell SYSBOOT to CONTINUE.

104

Session 1065

System Shutdown

Procedure

105

System Shutdown$ @SYS$SYSTEM:SHUTDOWN

− Prompts interactively for parameters

− Parameters can also be specified on the command linethat invokes the procedure.• See the SHUTDOWN and REBOOT symbols in

SYS$MANAGER:LOGIN.TEMPLATE

Let’s look now at the process of shutting down OpenVMS.

The provided DCL procedure is found asSYS$SYSTEM:SHUTDOWN.COM. It should actually be found in thecluster common path. This is provided by/with OpenVMS, and so shouldnot be modified except as instructed by OpenVMS support (which shouldnever happen).

SHUTDOWN prompts interactively for the shutdown parameters if noneare specified on the command line used to invoke SHUTDOWN.

Parameters to SHUTDOWN can also be specified on the command lineused to invoke SHUTDOWN. Two examples are found in theSYS$MANAGER:LOGIN.TEMPLATE script template. Look forSHUTDOWN and REBOOT in that file.

If you use these “foreign commands”, bear in mind that as supplied, theydo NOT execute the site-specific shutdown procedure.

106

System ShutdownSYS$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 informationin the slide regarding the parameters that SHUTDOWN accepts from thecommand line.

Notice that P5, when the system will be rebooted and P6, should anautomatic reboot be performed are in reverse order to the order of theprompts issued by SHUTDOWN.

107

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 site-specific shutdown procedure. SYS$MANAGER:SYSHUTDWN.COM isrun as part of the SHUTDOWN sequence if this option is selected inSHUTDOWN.

Use SYSHUTDWN to stop applications, databases, daemons, etc. thatmay be holding files open. This provides that such software can beshutdown gracefully instead of letting SHUTDOWN STOP them abruptlylater on in the SHUTDOWN sequence.

Like SYSTARTUP_VMS, the author recommends keeping SYSHUTDWNmodular so that individual shutdowns can be invoked at will for testing,problem solving, etc.

108

System ShutdownSYS$SYSTEM:SHUTDOWN.COM

Logical NamesSHUTDOWN$MINIMUM_MINUTES

Default value for minutes to final shutdown.

AGEN$SHUTDOWN_TIMEUsed by AUTOGEN as minutes to final SHUTDOWN orREBOOT.

SHUTDOWN$INFORM_NODESCluster nodes to receive REPLY messages from SHUTDOWN

SHUTDOWN$VERIFYAllows 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_MINUTESlogical name.

Also, if P1 to SHUTDOWN is specified as “MINIMUM”, the value of thislogical name is used as the time until final shutdown, or zero if the logicalis not DEFINEd.

The AUTOGEN procedure has its own logical name for the “minutes untilfinal shutdown” value that will be provided to SHUTDOWN byAUTOGEN. The AGEN$SHUTDOWN_MINUTES logical name can beused to provide a value for this; otherwise, AUTOGEN uses eitherSHUTDOWN$MINIMUM_MINUTES or a default of zero(0).

109

Shutdown OptionsREBOOT_CHECK

SAVE_FEEDBACK

DISABLE_AUTOSTART

POWER_OFF

The SHUTDOWN procedure allows for some shutdown options. Theoptions listed here are common to both clusters and non-clusteredsystems.

These options are specified as a comma-separated list either interactivelyor as P7 on the command line used to invoke SHUTDOWN. The optionnames can be abbreviated. The author of this presentation recommendsusing the option name up to the first underscore as a minimumabbreviation.

In the next slides, we’ll look at these options one by one.

110

Shutdown OptionsREBOOT_CHECK

• Performs a basic check for the existence of filesneeded to reboot the system.

• Not comprehensive - cannot detect a damagedboot block, corrupted bootstrap image, etc.

The reboot check option performs some very basic checks for theexistence of some key files. Some examples include the APB or VMBbootstraps, SYSBOOT and others.

Note, however, that this check is not comprehensive. It does not attemptto detect corrupted or unreadable files, for instance, nor does it check theintegrity of the boot block. It can catch certain situations that wouldprevent a successful reboot; the author has found this useful. The errorswere fixed and a successful shutdown and reboot was done.

111

Shutdown OptionsSAVE_FEEDBACK

• Saves some vital statistics about the system thatcan be used by AUTOGEN after the system comesback up.

• Same as the SAVPARAMS phase of AUTOGEN.

The SAVE_FEEDBACK option does the same thing as the SAVPARAMSphase of AUTOGEN. It allows that feedback information can be saved atshutdown time allowing for AUTOGEN to be run using the savedfeedback at some later time.

112

Shutdown OptionsDISABLE_AUTOSTART

• Use this if needed to prevent AUTOSTART queueson this node from failing over to this node fromanother node.

DISABLE_AUTOSTART stops autostart queues on the node, andprevents any queues from failing over to the node from another node inthe cluster.

113

Shutdown OptionsPOWER_OFF

• If the system console supports it, request that themachine power itself down once VMS has beenSHUTDOWN.

Some of the newer Alpha console subsystems allow for the hardwaresystem to be powered down under software control. The POWER_OFFshutdown option was added to support this feature.

The POWER_OFF option is new as of OpenVMS V7.

114

Shutdown Options - Clusters• REMOVE_NODE for all but the last node.

− Node exits the cluster gracefully.

• CLUSTER_SHUTDOWN for the last cluster nodeto be shutdown.− If used on all nodes, each node waits for other nodes to

reach the point of exiting the cluster, then proceeds toshutdown (“dissolves” the cluster).

These two options are only displayed on a node which is a member of acluster.

Specify REMOVE_NODE to have a node exit the cluster gracefully. Thesurviving nodes will recalculate quorum and then continue running afterthe resulting cluster state transition, if the total of votes remaining isgreater than or equal to quorum.

When shutting down the last surviving node of a cluster, or to shutdownall nodes of a cluster at the same time, specify theCLUSTER_SHUTDOWN option. If you use this to shutdown all the nodesof a cluster at the same time, each node will wait for the others to reach acommon point in the shutdown, then they will all shutdown togethergracefully dissolving the cluster.

115

Every Shutdown• Author recommends you always specify option

REBOOT_CHECK for all nodes.

• Has been helpful in preventing some nastysurprises.

A reminder that the REBOOT_CHECK option can be very helpful inpreventing problems, especially when a cluster or a system has run formany months without being shutdown. While not 100% comprehensive, itcan detect some kinds of situations that may evolve in a long-uptimesystem or cluster, such as key files getting deleted.

The Author of this presentation recommends always using theREBOOT_CHECK option of SHUTDOWN based on personal experience.

116

Session 1065

AUTOGEN

117

AUTOGENSYS$UPDATE:AUTOGEN.COM

• DCL procedure supplied by OpenVMS as an aid intuning the OpenVMS system.

• Not a replacement for diligent systemmanagement.

This presentation has mentioned the AUTOGEN procedure, so let’s takea look at it in a bit of detail.

AUTOGEN is a DCL procedure supplied by/with OpenVMS as an aid totuning the system and maintaining modifications to the systemparameters.

While AUTOGEN can point up some problems with proposed changes tothe system parameters, and can suggest other changes that may beuseful to maintain or improve performance, it is not a substitute fordiligent system management. You must still monitor your system’sperformance and tune the system to maintain expected levels ofperformance or service.

118

AUTOGEN• Applies changes to the default system parameters

as specified in the fileSYS$SYSTEM:MODPARAMS.DAT

• Is invoked during installs and upgrades, sometimesmore than once.

• Can be used to help size the swap and page files.

AUTOGEN applies changes to the system parameters as specified in theSYS$SYSTEM:MODPARAMS.DAT file. The OpenVMS system managermaintains MODPARAMS based on the need of the site, system orcluster.

AUTOGEN is invoked during OpenVMS installation and upgrades,sometimes more than once.

AUTOGEN calculates changes to the system parameters based onentries in MODPARAMS, but can also suggest changes to the systemswap, page and dumpfiles based on the physical configuration and onobserved utilization of the system (feedback).

119

AUTOGEN - MODPARAMSSYS$SYSTEM:MODPARAMS.DAT

• This is where changes to the default values aremade so they persist from one AUTOGEN to thenext.

• 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 thevalues of the system parameters. Values specified in MODPARAMS areapplied to the DEFAULT system parameters. So, changes are notcumulative. Also, any changes made outside of MODPARAMS will bewiped out by AUTOGEN.

AUTOGEN accepts your specified modifications and also calculateschanges to related parameters where appropriate.

There are four type of entries that can be made in MODPARAMS tospecify changes to the default values of the system parameters: hard-coded values, minimum values, maximum values and additional values.

120

AUTOGEN - MODPARAMSparameter_name = needed_value

• Provides a hard-coded value for the parameter.SCSNODE = “ALPHAONE”

GBLPAGES = 121589

• AUTOGEN calculations do not over-ride hard-coded values.

Hard-coded values are appropriate for some system parameters such asthe SCSNODE name, the SCSSYSTEMID, quorum disk name andothers.

In some cases, other parameters can be hard-coded, also. Generally, it’sbest to specify minimum values for many system parameters and letAUTOGEN use higher values if it calculates that higher values would behelpful.

In any case, the values that AUTOGEN calculates for system parametersdo not over-ride hard-coded value specified in MODPARAMS.

121

AUTOGEN - MODPARAMSMIN_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 lowervalue.

Sometimes, it is appropriate to specify a minimum value for someparameters and let AUTOGEN use higher values for them, if AUTOGENdetermines that higher values would be helpful for performance reasonsor other reasons.

In these cases, use a MIN_ value in MODPARAMS. AUTOGEN willreflect that the values of such parameters are not allowed to be lowerthan the value specified for them in MODPARAMS.

122

AUTOGEN - MODPARAMSMAX_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 ahigher value.

Some times, it is appropriate to specify a maximum value for someparameters and let AUTOGEN use a lower value if it calculates that alower value is appropriate.

In these cases, use a MAX_ value in MODPARAMS. AUTOGEN willreflect that the values of such parameters are not allowed to exceed thevalue specified for them in MODPARAMS.

123

AUTOGEN - MODPARAMSADD_parameter_name = addtl_value

• Provides an addition to the default value for theparameter.ADD_GBLPAGES = 81920

• AUTOGEN can use feedback to calculate a newvalue, then adds the specified value to thecalculated value.

In other cases, it may only be necessary to specify that AUTOGENshould 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, thenadd the specified value to the calculated value of such parameters.

For parameters not calculated by AUTOGEN, the value specified isadded to the default to arrive at the new value.

124

AUTOGEN - PhasesSAVPARAMS - Collects Feedback

GETDATA - Collects all other data

GENPARAMS - Generates new parameters

TESTFILES - Calculates new sys file sizes

GENFILES - Generates new system files

SETPARAMS - Creates new boot param.’s

SHUTDOWN - Shutdown the system

REBOOT - Reboot the system

HELP - Displays AUTOGEN info

AUTOGEN runs in phases that perform specific sub-tasks of the overallAUTOGEN task.

The AUTOGEN phases are listed above. In the following slides, we’lldiscuss these phases in some detail.

125

AUTOGEN - PhasesSAVPARAMS

Saves dynamic feedback from the running system.

Same as SAVE_FEEBACK option of SHUTDOWN.

The SAVPARAMS phase extracts the feedback information from therunning 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 canbe used in later calculations to determine optimal values for certainperformance related system parameters.

SAVPARAMS does the same thing as the SAVE_FEEBACK option ofSHUTDOWN.

126

AUTOGEN - PhasesGETDATA

Collects all data to be used in AUTOGENcalculations.

Includes existing feedback data if it is not over 30days old.

Includes MODPARAMS info.

During the GETDATA phase, AUTOGEN collects all of the informationneeded to perform its calculations. This includes validating the feedbackinformation, unless NOFEEDBACK is specified or the feedbackinformation is older than 30 days.

127

AUTOGEN - PhasesGENPARAMS

Performs calculations and generates the new systemparameters (but does not yet set them into the “Current”parameters).

Creates the new list of installed images based on the stateof the currently running system.

During the GENPARAMS phase, AUTOGEN performs its calculationsand writes a list of changes that will be applied to the default systemparameters. This can be found in the SYS$SYSTEM path in theSETPARAMS.DAT file.

AUTOGEN also creates a new list of images to be installed at system-startup time during the GENPARAMS phase.

128

AUTOGEN - PhasesTESTFILES

Calculates new page and swap file sizes, but does notapply any changes.

During the TESTFILES phase, AUTOGEN performs its calculations forchanges it will suggest to the sizes of the swap, page and dump files.Only the calculations are performed – no changes are actually applied inthe TESTFILES phase.

129

AUTOGEN - PhasesGENFILES

Generates new swap and page files based on AUTOGENcalculations.

Use entries in MODPARAMS to override:

DUMPFILE=0

SWAPFILE=0

PAGEFILE=0

During the GENFILES phase, AUTOGEN will apply the changes itcalculates for the swap, page and dump files.

This can be over-ridden in MODPARAMS by supplying entries for theswap, page and dumpfiles with zero(0) values.

These keywords can also be used to specify hard-coded values for thesizes of these files. The hard-coded values will over-ride AUTOGEN’scalculations.

130

AUTOGEN - PhasesSETPARAMS

Creates the new boot-time (“current”) parameters.

Changes take effect on the next boot.

During the SETPARAMS phase, the calculated changes to the defaultsystem parameters are applied and saved as the current parameters tobe loaded next time the system boots. The ACTIVE parameter set is notchanged.

131

AUTOGEN - PhasesSHUTDOWN

Shutdown the system and leave it ready for a manual bootor other console-level operations.

Caveat: Does *NOT* invoke SYSHUTDWN!

The SHUTDOWN phase allows AUTOGEN to shut the system down toawait a manual reboot, for performing operations at the console, forpower-down allowing hardware maintenance, etc.

A caveat about SHUTDOWN is that the site-specific shutdown procedure,SYSHUTDWN is not executed during the SHUTDOWN phase ofAUTOGEN.

The SHUTDOWN and REBOOT phases of AUTOGEN invokeSYS$SYSTEM:SHUTDOWN.COM.

132

AUTOGEN - PhasesREBOOT

Reboot the system using the newly generated parametersand/or system files.

Caveat: Does *NOT* invoke SYSHUTDWN!

The REBOOT phase allows AUTOGEN to shut the system down andspecify that automatic reboot should be performed. This is what typicallyhappens 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 SHUTDOWNphase of AUTOGEN.

The SHUTDOWN and REBOOT phases of AUTOGEN invokeSYS$SYSTEM:SHUTDOWN.COM.

133

AUTOGEN - PhasesHELP

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 HELPoption for AUTOGEN which outputs some useful information on how touse AUTOGEN.

It is useful to output this information to a file for future reference. Simplyspecify /OUTPUT=filespec after “@SYS$UPDATE:AUTOGEN” andspecify HELP as the first parameter.

134

AUTOGEN - PhasesTypical uses:

See if current MODPARAMS settings are suitable:

$ @SYS$UPDATE:AUTOGEN -

SAVPARAMS TESTFILES

Generate new system parameters for next boot:


SAVPARAMS SETPARAMS

AUTOGEN using previously saved feedback:


GENPARAMS SETPARAMS

Here are some typical examples of how to use AUTOGEN.

The first example shows how to use AUTOGEN to test the suitability ofyour proposed parameter changes. No actual changes will be made tothe current parameter set; however, a new list of installed images isgenerated and will be used on the next boot.

The second example shows how to use AUTOGEN to generate a newcurrent parameter set for use on the next boot. The running system is noteffected.

The third example show how to use AUTOGEN using feedback savedearlier, either by the SAVE_FEEDBACK option of SHUTDOWN or byrunning AUTOGEN with SAVPARAMS as both the starting and endingphase.

135

AUTOGEN - PhasesTypical uses:

AUTOGEN ignoring feedback:


_$ GENPARAMS SETPARAMS NOFEEDBACK

AUTOGEN using previously saved feedback, if it is valid:


_$ GENPARAMS SETPARAMS CHECK_FEEDBACK

Two more examples of using AUTOGEN:

The first example here shows how to use AUTOGEN when the systemhas not been up long enough to have any valid feedback. AUTOGEN isrun from the GENPARAMS phase through the SETPARAMS phase andis told to use no feedback. The system can then be shutdown or rebootedat a later time.

The second example here shows how to use AUTOGEN when you’re notcertain of the validity of the feedback information. If the feedbackinformation is older than 30 days, AUTOGEN will not use it but will stillcontinue 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 (tooold), AUTOGEN will adjust the ending phase to TESTFILES and allowthe system manager to take appropriate action.

136

AUTOGEN - ReportSYS$SYSTEM:AGEN$PARAMS.REPORT

• Generated on each run of AUTOGEN during theGENPARAMS phase.

• Indicates any MODPARAMS errors detected by AUTOGEN.

• Indicates the results of AUTOGEN calculations andresulting changes to system parameters.

In peforming its calculations, AUTOGEN produces a report regardingchanges it makes to the default parameters to generate the new currentparameter set.

The AGEN$PARAMS.REPORT is generated in the SYS$SYSTEM pathon every run of AUTOGEN which includes the GENPARAMS phase.

Any errors or inconsistencies detected in MODPARAMS will be reportedin AGEN$PARAMS.REPORT.

137

AUTOGEN - LoggingAUTOGEN 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$OUTPUTstream.

A useful technique is to specify a log file as /OUTPUT when invokingAUTOGEN, as shown in the slide.

138

Session 1065

Useful Tips

and Tricks

During our discussion of the system startup sequence, we looked atsome tips for logging the site-specific startup procedure, saving a crashdump and doing a preliminary analysis, creating group-level logicalnames and soft-coding the initial number of logins set during systemstartup.

During our discussion of logical names, we looked at ways to modify thelogical name table search list for processes and groups of users andways to combine the OpenVMS-supplied logical names with our own tohelp keep our system management and operational procedures separatefrom the ones supplied by/with OpenVMS.

Here we’ll look at a couple more tricks that may be useful.

139

Useful Tips and TricksAn “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 acouple of useful tips and tricks that can be helpful in the course ofeveryday operations.

This slide presents a way to establish an “uptime” command like UN*Xhas. SHOW SYSTEM/NOPROCESS shows only the banner line with noprocess detail.

/NOPROCESS is new for SHOW SYSTEM since V6.2.

Also shown is a way to make HELP behave like the “man” command onsome flavors of UN*X which pipe the output through “less” or “more”.HELP/PAGE=SAVE provides that you can scroll back through a longHELP text without needing to be using a terminal program on a PC orlaptop. Using /PAGE=SAVE=64 provides a very good sized scroll-backbuffer (circa. 64 screens worth of text).

140

Useful Tips and TricksA 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 howmany unique user names are logged in and how many processes thoseusers represent. The current interactive logion statistics are displayed aswell.

Because this uses the PIPE command, it only works on V7.x and later ofOpenVMS.

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

141

Useful Tips and TricksA simple command to show usage:

$ SHLOpenVMS User Processes at 13-JUL-2006 20:22:50.09



This slide presents a way to establish a simple command to show howmany unique user names are logged in and how many processes thoseusers represent. The current interactive logion statistics are displayed aswell.

Because this uses the PIPE command, it only works on V7.x and later ofOpenVMS.

Here is an example of the output from this command:$ shl

OpenVMS User Processes at 30-SEP-2002 11:33:56.56



142

Useful Tips and TricksA 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 usingTYPE/PAGE=SAVE in a PIPE-line.

Note that the SYS$PIPE logical name exists only in the second or latersegment of a PIPE-line. This can be used detect whether the procedureis being used as the target for PIPEd output and the input source forTYPE can be selected accordingly.

The MORE_PAGES symbol can be defined in the user’s LGICMD, ifdesired. In the slide, the code shown assumes a value of 64 for thissymbol if it is not present in the process’s environment.

143

Useful Tips and TricksVMS Disk “Partitions” – Logical Disks

» Actual devices which use a container file or a specifiedrange 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 fromDigital for many years. It provides the ability to use container files andnow ranges of disk blocks to provide logical disk devices that behavemore or less identically to a physical disk device.

The software is present but not supported or installed beginning withV7.3-2. To achieve the full functionality, obtain the newer PCSI kit for LDV8 from the OpenVMS freeware CD site. HELP is provided for the LDcommand once the kit is installed.

Beginning with OpenVMS V8.2, LD becomes a supported part of theoperating system environment.

144

Useful Tips and TricksVMS Disk “Partitions” – Logical Disks

Can be useful with disk storage arrays which are not easilyreconfigured. 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$ ld connect dka200:/lbn=(start=0,count=3145728) lda2$ ld connect dka200:/lbn=(start=3145728,count=3145728) lda4$ 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 wherevery large but not easily reconfigured storage arrays are in use.

In such cases, large devices up to OpenVMS’s current limitations can beprovided 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 theI/O queue of the underlying physical disk unit is not being overtaxed resulting in I/Ocontention. Provide a good number of large units so the I/O load can be spread out overthe physical devices provided by the array.

Take plentiful performance measurements in your development / test environment. Thismay not be suitable for performance-critical environments. Field experience with this islimited or non-existent. Use this with care.

145

Session 1065

OpenVMS

Security Elements

146

OpenVMS Security ElementsAn OpenVMS system is only as secure as theSysAdmin makes it.

Understanding and using the elements ofOpenVMS Security is the best way to help ensurethe security and integrity of an OpenVMS system.

System Security is an important job of the OpenVMS SysAdmin. Thesystem will only be as secure as the SysAdmin makes it. Anunderstanding of OpenVMS Security Elements will help the SysAdmin beeffective at keeping the system secure.

Effectively understanding and using the elements of OpenVMS Securityis the best way to help ensure the security of an OpenVMS system andthe security and integrity of the data it contains and processes.

This part of the presentation will look briefly at some of the key elementsof OpenVMS security. An in-depth security presentation may be availableas a technical breakout session in the symposium, or it may be presentedas full-day seminar at a future symposium.

147

OpenVMS Security ElementsPoints to remember:

TELNET and FTP sessions are not encrypted,passwords are sent as clear text. Use Secure Shelland Secure FTP for best security.

LAT and DECnet are not encrypted, passwords aresent as clear text.

Many forms of network access result in passwords being sent as cleartext. Among them are TELNET and FTP, to name only two. For the bestsecurity, use Secure Shell and Secure FTP to help keep passwordsecure.

LAT and CTERM (DECnet SET HOST) do not provide for encryption.User names and passwords are sent as clear text.

148

OpenVMS Security ElementsUser Identification Codes

[group,user]

Similar to UN*X UIDs, except digits are alwaysoctal.

Users belong to only one UIC group. Use RightsIdentifiers to grant additional access.

The first key element of OpenVMS security is the User IdentificationCode 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 asAlphanumeric 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 arerequired, rights identifiers can be created and GRANTed to users asneeded.

149

OpenVMS Security ElementsProtection Masks

Based on the UIC.

Four classes of permission:System

Owner

Group

WorldUN*X only has Owner, Group, World

UIC-based protection masks provide four classes of permission oraccess:

SystemOwnerGroupWorld

System class users have a UIC group less than or equal to the value ofthe system parameter MAXSYSGROUP.

The Owner class includes any user who has the UIC found in the ownerfield of an object descriptor.

The Group class includes those users whose UIC group number matchesthat 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.

150

OpenVMS Security ElementsLevels of Permission in each class:

Files

Read - Open read only

Write - Open write only

Execute - Run (if it’s 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 tothe file’s parent directory).

Note that for OpenVMS-I64, executable images need both Read andExecute access (RE).

151


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 Writeaccess to the parent directory).

152


Devices

READ

WRITE

LOGICAL I/O

PHYSICAL I/O


For devices:

Read access grants permission to open a device read-only. No otherpermission 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/Oto a device. No other permission is granted.

For devices, Physical I/O access grants permission to perform PhysicalI/O to a device. No other permission is granted.

153


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 ora jobs in the queue.

Modify access grants permission to modify characteristics of the queue ora jobs in the queue.

Submit access grants permission to submit jobs to the queue (SUBMIT orPRINT).

Delete access grants permission to delete jobs in the queue or the queueitself.

154

OpenVMS Security ElementsAccess Control Lists

Specify access control beyond the UIC basedprotections.

Consist of access control entries.

Access Control Lists (ACLs) are used to specify access permissionsbeyond what the UIC based protect mask allows for.

ACLs consist of Access Control Entries (ACEs).

The OpenVMS Guide To System Security describes access control indetail. The documentation is available on-line at this URL:

http://www.hp.com/go/openvms/doc

155

OpenVMS Security ElementsAccess Control Entries

Associate access control with UICs or RightsIdentifiers

Levels of access:

READ DELETE

WRITE CONTROL

EXECUTE

Object owner always has CONTROL

Access Control Entries (ACEs) associate access permissions with UICsor Rights Identifiers

ACEs can specify levels of access permission or permission to modify theobject’s security profile (Control access). The owner of an object alwayshas Control access.

156

OpenVMS Security ElementsRights Identifiers

Created using AUTHORIZE.

Can be associated with a resource (disk files - tocontrol disk quotas).

GRANTed to or REVOKEd from users usingAUTHORIZE.

Can be dynamic – non-privileged users canacquire and release using SET RIGHTS_LIST inDCL.

Rights Identifiers for use in setting up Access Control Entries (ACEs) arecreated and managed using the AUTHORIZE utility.

Identifiers can be simple identifiers or they can be associated withcommon resources, such as to cause disk usage for a file to be chargedagainst a specific UIC’s disk quota. There are other types of identifiersalso, such as those associated with protected subsystems and thoseassociated with UICs.

Identifiers can be GRANTed to users or REVOKEd from users by usingAUTHORIZE program.

Note that identifiers can be dynamic - non-privileged users can acquireand release them using the SET RIGHTS_LIST command in DCL.

157

OpenVMS Security ElementsPropagating ACEs, Default Protections

Set an ACE on a directory with the DEFAULTattribute.

Default Protection ACE is set on a directory.

Will be applied to new files, or use SETSECURITY/DEFAULT to propagate to existingfiles.

Access Control Entries (ACEs) and default protection masks can bepropagated onto existing files in a directory tree. On the root directory ofa 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 SETSECURITY/DEFAULT command with a wildcarded path.

Example:

$ SET SECURITY/DEFAULT ddcu:[root_level_directory…]*.*;*

158

OpenVMS Security ElementsSet ACEs in the proper sequence

First matching ACE determines access.

Enter ACEs from least restrictive to mostrestrictive. 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 propersequence.

When the system is determining access permission, only the firstmatching ACE is used.

ACEs should be entered into the ACL starting with the least restrictive tothe most restrictive. The ACL Editor (EDIT/ACL) can be helpful forobjects that have large ACLs.

Note that the ACL takes priority over the UIC-based protection mask. Ifthe UIC-based protection grants access but the ACL doesn’t, access tothe object will be denied.

159

Session 1065

Closing Comments,

Q & A

160

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 online at the OpenVMS website.

The Dallas / Fort Worth LUG maintains an extensive archive of freesoftware and DECUS CDs.

Note that the ftp://ftp.montagar.com/ URLs were tested successfully withan older Netscape (V4.77). The site was also accessed successfullyusing the Multinet FTP client on OpenVMS. Attempts to access the siteusing Internet Explorer V6 on Windows were less than successful.

161

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 FrequentlyAsked Questions (FAQ) which can be found at the URL shown.

DJE Systems also has some selected items available for download. Notall of them are listed on our freeware page; however, they can bedownloaded by going to the URL shown above. Look for the followingfiles 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/ETS-2002 in St. Louis, Missouri (USA). The presentation and associatedfreeware are available at the DJE Systems VMS Freeware archive:

4038_freeware.zip Additional DCL tools from DJE Systems

seminar_1024_2002.zip Arthur Cochrane’s original files andPowerPoint slides

This presentation can be found on-line shortly after the symposium at thisURL: http://www.djesys.com/vms/support/

162

Session 1065Thanks for coming!

Disclaimer: All information is correct to the best ofthe author’s knowledge.

Please fill out the evaluation forms, if available.

Documents

Advanced OpenVMS System Management Techniques … · Advanced OpenVMS System Management Techniques, Tools, ... Caveats SYS$COMMON Notes Caveats ... • Defines a new search list in