OpenVMS System Management Techniques, Tools, and Tricks

OpenVMS System Management Techniques, Tools, and Tricks
Seminar 1024 OpenVMS System Management Techniques, Tools, and Tricks David J. Dachtera DJE Systems

Agenda Basic DCL Concepts Commands Command Procedures Verbs Symbols
Flow Control (IF, GOTO, GOSUB, CALL) Useful Lexical Functions In this presentation, we’ll look at some helpful and useful System Management techniques as well as some helpful tips and tricks and some useful system management tools provided by OpenVMS. We’ll start off with some basics, including features of DCL and how to use them. Since the SysAdmin must develop and modify site-specific system startup procedures as well as site-specific procedures for use in the course of everyday operations, a strong basis in the fundamentals of DCL can be very helpful. We’ll look at the basic structure of DCL statements and commands, DCL symbols, how to effect control of the logic flow within procedures and how to use lexical functions to manipulate data and obtain information about the running system.

Agenda Logical names Logical name tables
Logical name table search order Modifying the search order Logical name types Single Translation Search list “Rooted” (Concealed) logical names Lexical Function Caveat F$TRNLNM() differs from F$LOGICAL() Since much of the way the VMS environment works is driven by the use of logical names, we’ll spend a good bit of time talking about them. Questions “in real time” are encouraged during this discussion, and we can always refer back to it as we proceed into those areas where logical names are used. This will provide an opportunity for reinforcement through practical examples. We’ll also discuss a few “gotcha”’s regarding DCL lexical functions as they relate to OpenVMS and system management.

Agenda Logical names, cont’d Cluster-wide logical names
Caveats SYS$COMMON Notes Caveats (VMS$COMMON) Site-Specific Paths Organizing local system management code In the newer versions of OpenVMS, Cluster-wide logical name tables were introduced. While these did not introduce any new complexity, working with them is not as straight-forward as it might appear at first glance. We’ll take a look at some practical examples of why the VMS$COMMON directory is rarely - if ever - used in the many logical names that the familiar OpenVMS environment depends on.

Agenda Network Topics TCP/IP DECnet TCP/IP Services (fka UCX) Multinet
TCPware CMU/IP (VAX only) DECnet Access control FAL logging Continuing our discussion of the essential elements of the system and system management, we’ll take a look at a brief overview of OpenVMS and networking. We’ll look at the various TCP/IP stacks available for OpenVMS: three commercial products for VAX and Alpha and a freeware piece for OpenVMS VAX only. We’ll look at DECnet as well, and take a look at Access Control and logging as well as some undocumented logical names can that be used to modify the behavior of FAL logging.

Agenda Network Topics, cont’d Remote procedures Network Alerts Types
Security concerns Network Alerts OPCOM alerts for DECnet network access OPCOM alerts for FTP network access Relevant to the discussion of networking is network access to OpenVMS. We’ll look at some of the types and methods of remote access offered by the TCP/IP stacks, discuss some of he security concerns surrounding them. Then, we’ll look at ways to to provide expanded logging for DECnet access and access via FTP.

Agenda System Startup STARTUP phases STARTUP parameters
Site-Specific startups Logging SYSTARTUP_VMS.COM Node-specific startups Saving a crash dump at start-up time Soft-coding # of logins allowed at startup SYSMAN and STARTUP Having reviewed some of the essential elements of OpenVMS Systems and system management, we’ll start to look a bit deeper into the process of starting the OpenVMS operating environment. We’ll look at how the OpenVMS-supplied procedures work so we can understand how to function within that framework. We’ll examine the various phases of the STARTUP procedure and the parameters it uses and observes. In our discussion of site-specific startups, we’ll look at some tips and tricks for retaining a log of the site-specific startup, suggest some ways to manage startups specific to a single node or group of nodes in a cluster, we’ll look at how to save crash dump information at system startup time and we’ll at a method of soft-coding the number of logins allowed at system startup time. In recent versions of VMS, the SYSMAN utility has acquired an interface to the OpenVMS-supplied system startup procedure which allows for some customization. We’ll look into that in some detail, as well.

Agenda System Shutdown Cluster Shutdown SHUTDOWN parameters
SHUTDOWN$xxxx logical names AUTOGEN Shutdowns AGEN$SHUTDOWN_TIME logical name Cluster Shutdown REMOVE_NODE Using SYSMAN Being able to startup the system is only half of the story. So, we’ll look into 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 be used to provide default values to certain SHUTDOWN parameters, including one that is used specifically by the AUTOGEN procedure. OpenVMS clusters introduce some additional shutdown-time considerations. So, we’ll look into those as well. The SYSMAN utility provides some functionality for system and cluster shutdown. We’ll look at that as well.

Agenda System/Startup File Caveats AUTOGEN
Deprecated Lexical Functions Lexical Function names misspelled AUTOGEN MODPARAMS.DAT Reports and outputs The system STARTUP procedure harks back to the early days of VMS, a venerable and trusted facility. As such, it contains some artifacts of its heritage that are worthy of attention. We’ll take a look at those, since they could lead to some confusion if used as a current-version example of how to program DCL procedures. AUTOGEN is a useful tool for helping to keep OpenVMS systems in tune and performing well. We’ll look at using AUTOGEN, setting values for system parameters in he MODPARAMS.DAT file, and we’ll look at the reports and outputs of AUTOGEN and how to use them.

Agenda OpenVMS Management Tools StorageWorks Command Console (SWCC)
OpenVMS Management Station AMDS Accessibility Manager for Distributed Systems Availability Manager Like AMDS, runs on MS-Windows Now we start to get to the meat that brought most of us here today: the system management tools supplied by OpenVMS in the software distribution and via the OpenVMS web pages. We’ll look first at the StorageWorks Command Console software, what it can do and what it won’t do. Next, we’ll look at the OpenVMS Management Station software, what it can do, and what it won’t do. Then, we’ll look at the Accessibility Manager for Distributed Systems - AMDS, and discuss briefly its younger sibling, the Availability Manager software. AMDS and Availability Manager are both useful tools providing facilities for performance monitoring as well as system and cluster management.

Agenda OpenVMS Security Essentials UICs and File/Directory Protection
Access Control Lists (ACLs) Access Control Entries (ACEs) Rights Identifiers and ACEs Propagating ACEs and Default Protections Finally, if time permits, we’ll take a look at the essentials of OpenVMS System security and the various elements that make it work. Additionally, we’ll look at third-party software and freeware that can be used to help secure your systems and access to them. We’ll conclude with lists of sources for free- and open-source software for OpenVMS where one might find useful extensions for secure access to OpenVMS systems, as well as utilities and other helpful items.

Seminar 1024 Basic DCL Concepts

Basic DCL Concepts Command Elements $ verb parameter_1 parameter_2
DCL commands consist of a verb and one or more parameters. First let’s review a few basic DCL concepts. DCL Commands consist of a verb and one or more parameters or operands. Some commands can be as simple as: $ SET VERIFY or $ LOGOUT

DCL Command Proc.’s $ @procedure_name
Top level (or terminal) is DEPTH 0. Each new command procedure invoked is a new procedure DEPTH. Maximum depth is still 32. DCL commands can be entered into a files known as a DCL command procedures. The UN*X equivalent would be a “shell script”. In DOS-land, they were usually called “batch files”. In the IBM mainframe world, they would call this a “CLIST” (Command List). Procedures can invoke other procedures. Each new invocation creates a new procedure “depth” within its own local symbol table. Procedures can be “nested” to a depth of 32.

DCL Command Proc.’s Parameters $ @procedure_name p1 p2 p3 … p8 Notes:
Only eight(8) parameters are passed from the command line, P1 through P8 Parameters with embedded spaces must be quoted strings. Parameters are separated by a space. DCL procedures receive their parameters from the command line. Up to eight parameters separated by white space can be passed to a DCL command procedure. Since “white space” delimits parameters, strings with embedded spaces must be enclosed in quotes..

DCL Command Proc.’s Parameters, cont’d $ @procedure_name p1 p2 p3 … p8
Notes, Cont’d: Reference parameters via the variable names P1 through P8. No built-in “shift” function. If you need it, write it as a GOSUB. To access the parameters passed in from the command line, reference the symbols P1 through P8. Note that DCL provides no “shift” function to shift the parameter values “over one” leaving the last one empty. However, this can easily be accomplished in a simple subroutine.

DCL Verbs Internal commands External commands
ASSIGN, CALL, DEFINE, GOSUB, GOTO, IF, RETURN, SET, STOP, others… External commands APPEND, BACKUP, COPY, DELETE, PRINT, RENAME, SET, SUBMIT, others... Commands in DCL are either internal to DCL or are executed by programs which are external to DCL. Here we see some examples of both internal and external commands. Notice that SET, STOP and other commands can be either internal or external depending upon the keyword after the verb.

DCL Verbs, Cont’d “Foreign” Commands Examples: $ symbol = value
$ DIR :== DIRECTORY/SIZE=ALL/DATE $ ZIP :== $ZIP/VMS Commands can be added or customized using symbols or “foreign commands”. In the slide, the DIR symbol redefines the behavior of the DIRECTORY command, while the ZIP symbol provides a means to invoke the ZIP program in such a manner that it can accept parameters and qualifiers from the command line.

Command Qualifiers $ command/qualifier $ command/qualifier=value
$ command/qualifier=(value,value) $ command/qualifier=keyword=value $ command/qualifier=- (keyword=value,keyword=(value,value)) Command qualifiers specify additional information or alternate behaviors of commands. Some qualifiers accept a value or a list of values. When specifying a single value, the parentheses can be left out. Some qualifiers accept a keyword or a list of keywords. Each keyword may accept a value or a list of values.

Non-positional Qualifiers
Apply to the entire command, no matter where they appear. $ command param1/qual param2 Example: $ COPY A.DAT A.NEW/LOG $ DELETE/LOG C.TMP; Some qualifiers have the same effect no matter where they appear on the command line. These are called non-positional qualifiers. The slide shows some examples. The /LOG qualifier is usually non-positional.

Positional Qualifiers
Apply only to the object they qualify. $ command param1/qual=value1 - param2/qual=value2 Examples: $ PRINT/COPIES=2 RPT1.LIS, RPT2.LIS $ PRINT RPT1.LIS/COPIES=1,- RPT2.LIS/COPIES=3 Some qualifiers can appear more than once in a command. These are called positional qualifiers. They qualify (or modify) the command element to which they are immediately adjacent. An example of this is the /COPIES qualifier of the PRINT command. When applied to the PRINT command, it is global to all the files in the print job. When applied to single file specifications in a PRINT job, it modifies only those files which match that file specification.

Common Qualifiers Many commands support a set of common qualifiers:
/BACKUP /BEFORE /CREATED /EXCLUDE /EXPIRED /INCLUDE /MODIFIED /OUTPUT /PAGE /SINCE See the on-line HELP for specifics. The VMS run time library UTIL$SHR provides support for a set of common qualifiers that have been made available in many of the more common commands. You can find these in the HELP for the DIRECTORY command, SEARCH, PRINT and others.

DCL Statement Elements
$ vbl = value DCL statements are typically assignments where a variable receives a value. Elements of a DCL statement (as opposed to a command) look very much like other programming languages. Here we have an example of an assignment statement. A variable receives a value. The value can be a literal expression, the name of another symbol, the result of a function, the result of an arithmetic or string operation, etc.

Assignment Statements
$ vbl = F$lexical_function( params ) Examples: $ FSP = F$SEARCH(“*.TXT”) $ DFLT = F$ENVIRONMENT (“DEFAULT”) $ NODE = F$GETSYI(“NODENAME”) Here we see a variable which receives the value returned by a built-in (“lexical”) function. The built-in function is part of the DCL lexicon. The slide also shows some examples.

$ vbl = string_expression Examples: $ A = “String 1 “ + “String 2” $ B = A - “String “ - “String “ $ C = ‘A’ Maximum string length 255 bytes (<=V7.3) 4096 bytes (>=V7.3-1) Here are some examples of string operations. The first operation is a string concatenation. The second operation is string reduction. The third operation is a symbol substitution. What’s happening in statement three?

$ vbl = numeric_expression Examples: $ A = 1 $ B = A +1 $ C = B + A + %X7F25 $ D = %O3776 Here, we see some examples of numeric assignments. We have an assignment using a literal and other assignments using numeric additions. Note the use of hexadecimal notation in the third example and octal notation in the fourth.

$ vbl[start_bit,bit_count]=numeric_exp Examples: $ ESC[0,8]=%X1B $ CR[0,8]=13 $ LF[0,8]=10 $ FF[0,8]=12 $ CRLF[0,8]=13 $ CRLF[8,8]=10 These are examples of assigning values to bits within a string. The result is always a string. This is useful for constructing escape sequences and binary values. In the fifth and sixth examples, the result is a two byte string containing a carriage-return and a line-feed (in that order).

$ ESC[0,8]=%X1B $ SHOW SYMBOL ESC ESC = "." $ CR[0,8]=13 $ SHOW SYMBOL CR CR = "." $ LF[0,8]=10 $ SHOW SYMBOL LF LF = "." When assigning values to specific bits, the result is always treated as a string expression. These examples show the control characters from the previous slide that can be assigned to a symbol in this manner. Note from the SHOW SYMBOL commands that the result is always a string.

$ FF[0,8]=12 $ SHOW SYMBOL FF FF = "." $ CRLF[0,8]=13 $ SHOW SYMBOL CRLF CRLF = "." $ CRLF[8,8]=10 CRLF = ".." These are the remaining examples of assigning bits within a symbol value. Note especially that the last example is a two-byte string.

DCL provides for substring replacement. $ A := abcde $ SHOW SYMBOL A “ABCDE” $ A[3,2]:=XX “ABCXX” DCL provides for replacement of substrings within strings. The notation is very similar to setting bits in symbol, except that the value specified is a string expression using the “:=“ (colon equal[ equal]) operator. In the example, a short string is setup. Then, two characters in the string are replaced. Note that the offset is zero-relative, just as with setting bits.

$ vbl = boolean_expression Examples: $ MANIA = (“TRUE” .EQS. “FALSE”) $ TRUE = (1 .EQ. 1) $ FALSE = (1 .EQ. 0) $ YES = 1 $ NO = 0 Here we have examples of assignment of a “truth value” or a boolean value. The last two examples are ordinary numeric literal assignments. They illustrate the defaults for “true” (“yes”) and “false” (“no”).

Local Assignment: $ vbl = value Global Assignment: $ vbl == value Symbols can be either local to the current procedure level (“depth”) and all levels deeper, or global to all procedure levels (“depths”). Local symbols are available to the current procedure and any that it invokes. Global symbols are available to the current procedure and any that it invokes, as well as the procedure(s) which invoked the current procedure.

Quoted String: $ vbl = “quoted string” Case is preserved. Examples: $ PROMPT = “Press RETURN to continue “ $ INVRSP = “% Invalid response!” When a quoted string is assigned to a symbol, the case and contents of the string are preserved intact.

Unquoted string: $ vbl := unquoted string Case is NOT preserved, becomes uppercase. Leading/trailing spaces are trimmed off. Examples: $ SAY := Write Sys$Output $ SYSMAN :== $SYSMAN ! Comment In the case of an unquoted string (uses the “colon-equal[-equal]” sequence), all text becomes upper case, and leading and trailing spaces and TABs are trimmed off. If the unquoted string contains an embedded quoted string, the case and content of the quoted portion of the string will be preserved. Comment delimiters are observed as usual. The comment is not considered part of the unquoted string.

Foreign Commands $ vbl := $filespec[ param[ param[ …]]]
“filespec” defaults to SYS$SYSTEM:.EXE Maximum string length: 510 bytes (<=V7.3) 4096 bytes (>=V7.3-1) A “foreign command” is special case where a symbol can be interpreted by DCL as verb. The value of the symbol can include qualifiers and/or parameters in addition to the file specification of the executable file. If necessary, foreign commands can be defined using quoted strings if, for example, the case of an argument or embedded spaces within an argument needs to be preserved. Using symbol substitution, strings of up to 1024 bytes can be constructed through and including OpenVMS V7.3. V7.3-1 introduces support for strings up to 4096 (4K) bytes.

Symbol Scope SET SYMBOL/SCOPE= NOLOCAL LOCAL NOGLOBAL GLOBAL
All “outer” level local symbols are “invisible” LOCAL Undoes NOLOCAL NOGLOBAL All “outer” level global symbols are “invisible” GLOBAL Undoes NOGLOBAL The concept of symbol scope relates to DCL symbols created by other procedures in the same stream. A procedure can set up local symbols or global symbols. Global symbols are available to all procedures and from command level. Local symbols are available to the current procedure and any that it invokes. Symbol scope can be limited so that a procedure only has access to its own local symbols, all global symbols or no symbols other than those it creates. This feature can be useful in large or complex processes where symbol names may be duplicated or where foreign commands have been used for convenience.

Symbol Scope SET SYMBOL/GENERAL/SCOPE=xxxx
Specifies that the values of the /SCOPE qualifier pertain to the translation of all symbols except the first token on a command line. /GENERAL is incompatible with /ALL or /VERB. DCL supports “foreign commands”; that is the first symbol or token on a command line can be interpreted as a symbol whose value may be a DCL command plus some qualifiers, the name of a program, etc. /GENERAL preserves the behavior of evaluating the first symbol or token in a command line as potentially the name of symbol or foreign command. Note that /GENERAL cannot be used at the same time as /ALL or /VERB.

Symbol Scope SET SYMBOL/VERB/SCOPE=xxxx
Specifies that the values of the /SCOPE qualifier pertain to the translation of the first token on a command line as a symbol before processing only. It does not affect general symbol substitution. /VERB is incompatible with /ALL or /GENERAL. The /VERB qualifier modifies this behavior so that the first token or symbol in a command is not treated differently. This has certain ramifications, as noted below. Note that /VERB cannot be used at the same time as /GENERAL or /ALL. Excerpt from the on-line help: NOTE: Caution must be used if the SET SYMBOL/VERB/SCOPE command is used more than once in a command procedure. Because DCL uses the translation behavior when looking for a label or subroutine, execution may be different running in one mode than in another. Digital recommends that the SET SYMBOL /VERB/SCOPE command be used once as part of the command procedure setup and left in that mode for the duration of the procedure.

Symbol Scope SET SYMBOL/ALL/SCOPE=xxxx
Specifies that the values of the /SCOPE qualifier pertain both to the translation of the first token on a command line and to general symbol substitution. /ALL is incompatible with /GENERAL or /VERB. The /ALL qualifier indicates that all of the symbols in a command line should be treated the same way, both “verbs” and symbols alike. Note that /ALL cannot be used at the same time as /GENERAL or /VERB.

Conditional Expressions
$ IF condition THEN statement Variations: $ IF condition THEN $ statement $ IF condition THEN - $ statement Conditional expressions provide logical control based on conditions you specify. In this form, the IF-THEN structure can be stated on a single line or it can be continued across two or more lines. In either case, the “$” after THEN is optional.

$ IF condition $ THEN $ statement(s) $ ENDIF Another variation is the IF-THEN[-ELSE]-ENDIF structure. This variant allows multiple statements (or no statements) to be included in the THEN or ELSE clause. Although it is not required in current versions of VMS, it is recommended that the THEN or ELSE statement appear on a line by itself.

$ IF condition $ THEN $ IF condition $ THEN $ statement(s) $ ENDIF $ ENDIF The IF-THEN[-ELSE]-ENDIF structure allows IF-THEN[-ELSE]-ENDIF structures to be nested.

$ IF condition $ THEN $ IF condition $ THEN $ statement(s) $ ENDIF $ statement(s) $ ENDIF Other statements can be included either before or after a nested IF-THEN[-ELSE]-ENDIF structure.

$ IF condition $ THEN statement(s) $ IF condition $ THEN $ statement(s) $ ENDIF $ ENDIF This may not work in pre-V6 VMS! Here’s an example of some code that might not work in some older versions of OpenVMS. Notice that the THEN clause includes a DCL statement, instead of being on a line by itself.

$ IF condition $ THEN $ statement(s) $ ELSE $ statement(s) $ ENDIF Here is an example of an IF-THEN-ELSE-ENDIF block. As we discussed earlier, the THEN and ELSE statements are recommended to be on lines by themselves. Either the THEN or ELSE portions may contain nested IFs of any kind.

Labels, GOTO $ GOTO label_1 . $label_1:
The GOTO statement provides for logical control within your procedures. Combined with IF, GOTO provides for powerful logical control within your procedures. Labels are defined by including the label name on a line followed immediately by a colon. Any statement can follow a label on a line; however, this is recommended only for the SUBROUTINE statement. Otherwise, place the label on a line by itself for readability.

GOSUB, RETURN $ GOSUB label_1 . $label_1: $ statement(s) $ RETURN
The GOSUB and RETURN statements let you create internal subroutines. All symbols local to the current procedure level are available, as are all global symbols. Combined with IF, GOSUB and RETURN provide for powerful logical control of conditional execution within your procedures. Labels are defined by including the label name on a line followed immediately by a colon.

GOSUB, RETURN Emulate UN*X/DOS shell SHIFT: $SHIFT: $ P1 = P2
In an earlier slide, we mentioned that a subroutine to “shift” the parameter values could be written simply. This subroutine illustrates how to emulate the “shift” function in the UN*X and DOS shells. DCL does not provide this natively. Typically, the main routine (DCL procedure or SUBROUTINE) expects a single value or list of values in P1, the first parameter. To allow for more flexibility and to accommodate string length limitations, your procedure can allow for additional (lists of) value(s) by processing P1 through P8 sequentially. The technique is to process P1, GOSUB SHIFT, then test to see if P1 is empty. When P1 comes back empty after the SHIFT, the end of the list of parameters has been reached.

SUBROUTINE - ENDSUB... $ CALL label_1[ param[ param[ …]]
$label_1: SUBROUTINE $ statement(s) $ END SUBROUTINE Another form of subroutine is enclosed within the SUBROUTINE and ENDSUBROUTINE statements. This form of subroutine is similar to invoking an external procedure. Use the CALL statement to invoke this form of internal subroutine. Optionally, parameters to be passed to the subroutine can be included on the CALL statement. SUBROUTINEs act like another procedure depth. Local symbols are local to the subroutine and global symbols are visible to the SUBROUTINE. The SET SYMBOL/SCOPE command can be used within this type of subroutine for better control of the symbols available to the subroutine.

Lexical Functions Functions built into the DCL Lexicon
F$CONTEXT F$CSID F$CVSI F$CVTIME F$CVUI F$DEVICE F$DIRECTORY F$EDIT F$ELEMENT F$ENVIRONMENT F$EXTRACT F$FAO F$FILE_ATTRIBUTES F$GETDVI F$GETJPI F$GETQUI F$GETSYI F$IDENTIFIER F$INTEGER F$LENGTH F$LOCATE F$MESSAGE F$MODE F$PARSE F$PID F$PRIVILEGE F$PROCESS F$SEARCH F$SETPRV F$STRING F$TIME F$TRNLNM F$TYPE F$USER F$VERIFY Here’s a list of the lexical functions that are “built-into” DCL. This list is taken from OpenVMS V7.1-2. V7.3 of OpenVMS introduces the previously undocumented F$GETENV function. F$GETENV is used for retrieving the values of certain Alpha console environment variables.

Common Lexical Functions
$ vbl = F$CVTIME(string[, keyword[, keyword]]) “string” = Absolute time expression “keyword” = (1st instance) is one of “ABSOLUTE”, “COMPARISION”, “DELTA” “keyword” = (2nd instance) is one of “DATE”, “DATETIME”, “DAY”, “MONTH”, “YEAR”, “HOUR”, “MINUTE”, “SECOND”, “HUNDREDTH”, “WEEKDAY” The DCL lexicon includes a number of built-in functions. Let’s look at a few of the more useful ones… F$CVTIME() can be used to develop routines to get and compare elements of the system date/time. This can be useful for procedures that need to change their behavior based on the day, date and/or time of day.

F$CVTIME(), Continued… Defaults: $ vbl = F$CVTIME(string, - ”COMPARISON”, - ”DATETIME” ) Pre-defined date strings: TODAY, YESTERDAY, TOMORROW, BOOT This slide shows the default behavior of F$CVTIME() if no arguments are provided. The default value for “string” is the current date and time. Some pre-defined strings are available to represent common time expressions.

F$CVTIME(), Continued… Date Formats: Comparison YYYY-MM-DD HH:MM:SS.CC Absolute DD-MMM-YYYY HH:MM:SS.CC Delta +/-DDDDD HH:MM:SS.CC This slide illustrates the date/time formats used and returned by F$CVTIME(). The COMPARISON date format is useful for comparing dates. The ABSOLUTE format is similar to that returned by F$TIME().

$ vbl = F$GETDVI( dev_name, keyword ) “dev_name” is a valid device name “keyword” is a quoted string Examples: $ FBLK = F$GETDVI( “DUA0”,”FREEBLOCKS”) $ MNTD = F$GETDVI( “DKA500”,”MNT”) $ DVNM := DUA0: $ VLNM := VOLNAM $ VNAM = F$GETDVI( DVNM, VLNM ) The F$GETDVI() function is useful for retrieving information about system devices and disk/tape volumes. The examples show some of the information that can be returned by F$GETDVI(). Notice that either literal strings or symbols can be used as arguments to DCL lexical functions.

$ vbl = F$QETQUI( - function,- item,- value,- keyword(s)) See the on-line help for descriptions. F$GETQUI() is a useful, if rather complex lexical function. Some operations of F$GETQUI(), such as retrieving information about the jobs on a queue, require that you first retrieve some piece of information about the queue (“DISPLAY_QUEUE”) such as the queue name to establish a “queue context”. Then, you can loop through the jobs on the queue (“DISPLAY_JOB”) using the “ALL_JOBS” and “FREEZE_CONTEXT” flags as needed to get individual items of information about a job on a queue. More in-depth information on F$GETQUI() may be forthcoming in a future technical session on Advanced DCL Programming at a future technical symposium. In the meantime, see the on-line HELP and the DCL Dictionary for further information about F$GETQUI(). The on-line HELP includes some useful examples that may help develop a deeper understanding of how to use F$GETQUI()

$ VBL = F$GETJPI( pid, keyword ) Examples: $ USN = F$GETJPI( 0, “USERNAME” ) $ MOD = F$GETJPI( 0, “MODE” ) F$GETJPI() can be used to get information about your own process or about any other process to which you have access. Normal rules of OpenVMS privilege apply. For information about the current process, specify the PID argument as a zero(0) as shown in the examples, or as a null string. Some F$GETJPI() items return information that is the same or similar to information returned by other lexical functions. For example, F$GETJPI( 0, “MODE”) is the same as F$MODE(). F$GETJPI( 0, “UIC” ) is similar to F$USER()

$ vbl = F$GETSYI( item[, node[, csid]] ) Examples: $ NODE = F$GETSYI( “NODENAME” ) $ FGP = F$GETSYI( “FREE_GBLPAGES” ) $ FGS = F$GETSYI( “FREE_GBLSECTS” ) F$GETSYI() can be used to retrieve information about the running system. Any valid system parameter name is a valid keyword for F$GETSYI(). Additionally, as shown in the slide, additional keywords are provided to retrieve some useful items of information about the running system. See the on-line HELP or the DCL Dictionary for a complete list of keywords and complete usage information. In some cases, it can also be used to get information about other members of an OpenVMS cluster. When used in a loop with the F$CSID() function, it is possible to retrieve and display information about every node in the cluster. The on-line HELP for F$CSID() shows an example of how to do this.

$ vbl = F$ELEMENT( idx, delim, string ) Find the nth (delim) delimited element of a string. Examples: $ A = F$ELEM( 2, “,”, “A,B,C,D,E,F” ) $ B = F$ELEM( 1, “ ”, “Turn it off” ) F$ELEMENT() provides an easy way to find elements of a delimited string. This can be useful for finding items in a comma-delimited list, “words” in a string of text, etc.

Seminar 1024 OpenVMS Logical Names

Logical Names A form of symbol with limited or system-wide scope.
$ show logical sys$sysroot "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) A feature that is more or less unique to OpenVMS is the concept of logical names. Similar features may be present in some mainframe operating systems, also. Simply stated, logical names provide a way to represent a device name, a device name and a path name or even a device name and part of a path name in a simple way so that software, files, etc. can be easily used on and moved from one system to another, to pass data to programs and procedures or just for convenience.

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

Logical Name Tables Search Order: $ sh log/tab=* lnm$file_dev
"LNM$FILE_DEV" = "LNM$PROCESS" (LNM$SYSTEM_DIRECTORY) = "LNM$JOB" = "LNM$GROUP" = "LNM$SYSTEM" = "DECW$LOGICAL_NAMES" VMS provides that logical name tables can be searched by providing a search list which is itself a logical name. The LNM$FILE_DEV logical name indicates which logical names should be searched when the SHOW LOGICAL command is issued without the /TABLE qualifier or when a file is being opened or sought.

Logical Name Tables Modifying the search order:
$ DEFINE/TABLE=LNM$PROCESS_DIRECTORY - LNM$FILE_DEV LNM$PROCESS,LNM_PRIVATE,- LNM$GROUP,LNM$SYSTEM,- DECW$LOGICAL_NAMES Defines a new search list in supervisor mode. Some software will only use “trusted” logical names in certain directories or those DEFINEd in an “inner’ (more privileged) mode. It is possible to modify the search order specified in the LNM$FILE_DEV logical name. This can be done for individual processes, for entire UIC groups (requires GRPNAM privilege) or across the entire system (may require SYSPRV, SYSNAM and CMEXEC privilege). Note, however, that some software will only use logical names that appear in certain logical name table directories or logical name tables or are DEFINEd in a privileged access mode. It is assumed that privileged programs and procedures are “trusted”, and thus that logical names they may establish are similarly trust worthy.

Logical Names Single translation Search List Concealed Logical Names
$ 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 equivalence string associated with concealed logical names. Rooted logical names are used in a manner very similar to device names. The “top level” directory in a path indicated by a rooted logical is referred to as “[000000]”, just as is the Master File Directory (MFD) of a disk volume. The actual device name and root path are not displayed by non-privileged programs and procedures. Some folks refer to rooted logicals as “pseudo disks” for that reason.

Logical Names Creating Deleting $ DEFINE lnm value $ ASSIGN value lnm
$ DEASSIGN lnm There are two DCL commands for creating logical names. The DEFINE command has the logical name as its first parameter and the equivalence string(s) as the second parameter. The ASSIGN command reverses the order of the parameters: the equivalence string(s) as the first parameter, and the logical name as the second parameter. There is one DCL command for deleting logical names. The DEASSIGN command is used to delete logical names.

Logical Names Access Modes User DEFINE/USER
Supervisor DEFINE (/SUPER is default) Executive DEFINE/EXECUTIVE, requires CMEXEC privilege. Kernel Can only be created by using the $CRELNM system service, requires CMKRNL privilege. Executive and Kernel mode logical names are “trusted” since privilege is required to create them. Logical names are DEFINEd is one of four “access modes”. More privileged access modes are sometimes referred to as “inner” modes. User mode logical names are the lowest and least privileged level. User mode logical names are deleted when an image (a program) is run down (exits). Supervisor mode is the default access mode for both DEFINE and ASSIGN. Supervisor mode is also a low privilege level; however, supervisor mode logical names persist and are not deleted when an image (a program) is run down (exits). Executive mode is similar to Supervisor mode, but requires CMEXEC privilege. Kernel mode is the most privileged access mode. Kernel mode logical names can only be established by invoking the $CRELNM system service which is only accessible within a program. There is no /KERNEL qualifier for either the DEFINE or ASSIGN commands.

Logical Names Single Translation Examples: $ DEFINE lnm value
"LNM$PROCESS" = "LNM$PROCESS_TABLE" (LNM$PROCESS_DIRECTORY) "LNM$JOB" = "LNM$JOB_80D27B00" (LNM$PROCESS_DIRECTORY) "LNM$GROUP" = "LNM$GROUP_000030" (LNM$PROCESS_DIRECTORY) "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY) “SYS$LOGIN" = "DKA0:[DDACHTERA]" (LNM$JOB_80D27B00) Here we see a few examples of common single-translation logical names that may be encountered on a running OpenVMS system.

Logical Names Search Lists $ DEFINE lnm value,value[,…] Examples:
$ sh log sys$sysroot "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "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 search lists. Under the translation of SYS$SYSROOT, we also see the translation of one of its elements: SYS$COMMON. SYS$COMMON is a rooted logical as is the first translation of SYS$SYSROOT. The second example, USER_EXE is a search list that is set up in the environment of a specific user’s process. Under USER_EXE we see the translations of two of its elements, USER_IMG and USER_COM.

Logical Names Concealed Logical Names Example:
$ DEFINE lnm value/TRANS=CONCEAL Example: $ sh log sys$sysdevice "SYS$SYSDEVICE" = "DJAS01$DKA300:" (LNM$SYSTEM_TABLE) $ sh log sys$sysdevice/full "SYS$SYSDEVICE" [exec] = "DJAS01$DKA300:" [concealed,terminal] (LNM$SYSTEM_TABLE) Here we see an example of a commonly encountered system-wide logical name. SYS$SYSDEVICE is a concealed logical name created in executive mode. SYS$SYSDEVICE also has the “Terminal” attribute which means that after translating SYS$SYSDEVICE no further translation be attempted beyond the equivalence string of SYS$SYSDEVICE (in this example, “DJAS01$DKA300:”).

Logical Names “Rooted” Logical Names Examples:
$ DEFINE lnm ddcu:[dir.]/TRANS=CONCEAL Examples: $ show logical sys$specific,sys$common,user_root "SYS$SPECIFIC" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) "USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00) Here we see two examples of commonly encountered rooted logical names. The equivalence string of SYS$SPECIFIC includes the physical name of the system disk device and the node’s boot root (“[SYS0.]”). The equivalence string of SYS$COMMON includes the physical name of the system disk device, the node’s boot root (“[SYS0.”) and the root-specific alias for the VMS$COMMON directory (“SYSCOMMON]”).

Logical Names Using rooted logical names Examples:
$ show logical sys$sysroot,user_root,user_com,user_img "SYS$SYSROOT" = "DJAS01$DKA300:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DJAS01$DKA300:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE) "USER_ROOT" = "DKA0:[DDACHTERA.]" (LNM$JOB_80D27B00) "USER_COM" = "USER_ROOT:[EXE]" (LNM$JOB_80D27B00) "USER_IMG" = "USER_ROOT:[EXE.ALPHA]" (LNM$JOB_80D27B00) Here we see examples of system and user level uses of rooted logical names. SYS$SYROOT we saw in an earlier slide. USER_ROOT we’ve seen before, also. Here we see how it is DEFINEd. The USER_COM and USER_IMG logical names both use the rooted logical name USER_ROOT.

Logical Names & Lexicals
Beware: F$LOGICAL() (deprecated) differs from F$TRNLNM(). F$LOGICAL() uses hard-coded search list internally: Process, Job, Group, System. F$TRNLNM() uses LNM$FILE_DEV Something to watch out for here: Some of the older DCL procedures supplied with the system by OpenVMS use the F$LOGICAL() lexical function. F$LOGICAL() has been deprecated (made obsolete) and is no longer documented. However, OpenVMS always attempts to maintain compatibility across versions as much as possible. So, while F$LOGICAL() is no longer documented, it remains present in the system. Any new procedures that are developed should use the newer, documented F$TRNLNM() lexical function.

Cluster-Wide Logical Names
New in V7.2. Defined in table LNM$SYSCLUSTER LNM$SYSTEM is now a search list: $ show log/tab=* lnm$system "LNM$SYSTEM" = "LNM$SYSTEM_TABLE" (LNM$SYSTEM_DIRECTORY) = "LNM$SYSCLUSTER" 1 "LNM$SYSCLUSTER" = "LNM$SYSCLUSTER_TABLE" (LNM$SYSTEM_DIRECTORY) A new feature in OpenVMS V7.2 is the concept of cluster-wide logical names. These are logical names that once DEFINEd on a node of the cluster are propagated to the LNM$SYSCLUSTER_TABLE of all of the nodes participating in the cluster. To facilitate this without “breaking” any existing code, the LNM$SYSTEM logical name was made a search list pointing first to the local system-wide logical name table (LNM$SYSTEM_TABLE) and then to the cluster-wide logical name table. Note that LNM$SYSCLUSTER is a logical name pointing to the table of cluster-wide logical names.

Cluster-Wide Logical Names
Caveat: There is no /CLUSTER qualifier for DEFINE, ASSIGN or DEASSIGN. Use /TABLE= LNM$SYSCLUSTER Note, however, that there is no additional qualifier provided for the DEFINE, ASSIGN and DEASSIGN commands. To create, maintain or delete cluster-wide logical names, specify /TABLE=LNM$SYSCLUSTER in the command.

Logical Names Notes: VMS$COMMON usually not found in system logical names. It IS possible to have a system with a missing or corrupted VMS$COMMON. OpenVMS upgrades will fail. Difficult to recover. Running in this condition is not supported. Note that the VMS$COMMON directory does not appear in the system-wide logical names setup and used by OpenVMS. In fact it is possible to have a missing or corrupted VMS$COMMON directory. The author of this presentation observed it in a running 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 system disk and copy over the system-specific files as needed. This is a tedious and time-consuming task, but it can be used as a last resort if ANALYZE/DISK/NOREPAIR doesn’t turn up the missing directory as a lost file. Running a system in this condition is probably not supported by OpenVMS Support.

Logical Names Leave OpenVMS-provided logical names alone.
ReDEFINE-ing things like SYS$SYSROOT can jeopardize support position or system certification (Healthcare, etc.) If any of these are reDEFINEd, do it at the /PROCESS level, not system-wide and make sure to leave the system account “pristine”. In the abstract for this seminar, mention was made of adding a translation to the SYS$SYSROOT search list. This is not a good idea, and the author of this presentation does not advocate making any changes to logical names provided by OpenVMS. It could cause problems with OpenVMS support if a question comes up involving any such logical names or any software that uses them. Also, from the perspective of the healthcare world, this would constitute a significant change to the operating environment and could raise questions regarding the environment’s continued certification. If reDEFINE-ing any of theses logical names could be helpful, be sure to only do this at the /PROCESS level, not system-wide. Make sure to keep the system account’s user environment as “pristine” as possible so as not to raise any questions of supportability or certified environment specifications.

Logical Names Leave OpenVMS-provided logical names alone.
Probably okay to do this in a privileged account other than SYSTEM. If these are needed at SYSTARTUP_VMS time, invoke a proc. to do the DEFINEs, then invoke the proc.’s that need the local logical names, then clean up using DEASSIGN/PROCESS. Using DEFINE (/PROCESS is the default) in your own privileged account to provide process-private logicals with the same name as those at the system level would probably not raise any questions or problems. However, should any support issues arise, you will likely be asked to try to do without the private logical names by OpenVMS support. You could use your private logical names at system startup time by first invoking a procedure to create the process-private logical names, perform whatever procedures require those logical names, then clean them up using DEASSIGN (/PROCESS is the default). OpenVMS provides certain logical names for its own use. It is best, in the author’s opinion, to operate within that framework and not try to “bend the rules”. Such actions invariably come back to haunt you.

Logical Names It is possible to organize your site-specific procedures and keep them separated from the OpenVMS files without reDEFINE-ing any logical names provided by OpenVMS. It is possible to organize your site-specific system management and/or operational procedures and still keep them separated from those files supplied by/with OpenVMS, without reDEFINE-ing any logical names that OpenVMS provides. Keeping your your site-specific system management and/or operational procedures organized separately from the OpenVMS files is a very good idea. This virtually guarantees that they will not be disturbed during a system upgrade.

Logical Names OpenVMS Logical Names:
Usually contain a “$” (dollar sign). User (Site-Specific) Logical Names Avoid “$” – use underscore: SYS_MANAGER SYS_BACKUP SYS_OPERATOR SYS_HELP SYS_ROOT In logical names, symbol names, file names, etc., use of the dollar sign (“$”) is reserved to OpenVMS. User supplied names should use only underscores as “punctutaion”. Shown are some examples of user-supplied logical names that might prove useful. For example: SYS_MANAGER Management procedures, software startups, etc. SYS_BACKUP Backup procedures and files they use SYS_OPERATOR Menus, VMSmail, etc. SYS_HELP Site-specific help libraries, documentation… Any of these logical names can be made search lists, and probably should. For example, SYS_MANAGER could point first to the directory where the local site-specific files reside, then to SYS$MANAGER. Likewise, SYS_HELP could point first to the local site-specific help, then to SYS$HELP.

Logical Names $ sho log sys_* (LNM$PROCESS_TABLE) (LNM$JOB_80D128C0)
(LNM$GROUP_000030) (LNM$SYSTEM_TABLE) "SYS_BACKUP" = "SYS_ROOT:[BACKUP]" "SYS_HELP" = “SYS_ROOT:[SYSHLP]" "SYS_MANAGER" = "SYS_ROOT:[SYSMGR]" "SYS_OPERATOR" = "SYS_ROOT:[OPERATOR]” “SYS_ROOT“ = “SYS$SYSDEVICE:[XYZCORP.]” = ”SYS$SYSROOT:” As mentioned in the previous slide, any of these example site-specific logical names can be made search lists. In the example, SYS_MANAGER points first to the directory where the local site-specific files reside, then to SYS$MANAGER. Likewise, SYS_HELP points first to the local site-specific help, then to SYS$HELP. In these cases, the local files will be found first, if their names duplicate the name of a file found in the system directories. When the system is searching for a file, as when you invoke or edit a procedure, the system files will be found if no site-specific file matches the requested file specification. Notice that SHOW LOGICAL allows the use of wildcards. Since any logical name table can have a lot of entries, this makes things a bit easier to find.

Logical Names Site-specific logical names for system management can be organized in their own logical name tables. User Logical name table can be added to LNM$FILE_DEV, but don’t do that system-wide – DEFINE things /PROCESS. See the earlier example of how to modify the LNM$FILE_DEV search list for a process. /PROCESS is the default for DEFINE and ASSIGN if not specified. While SHOW LOGICAL does support the use of wildcarded logical names as we saw in the previous slide, you may still want to isolate site-specific logical names for system management in their own logical name table. One reason to do this might be that you can then set the protection and/or ACL of the site-specific logical name table to deny access to unprivileged users. This helps keep your environment secure. In those privileged accounts that need access to these logical names, you can reDEFINE the LNM$FILE_DEV search list as mentioned in an earlier slide. Again, as recommended in an earlier slide, do this at the process level, or no higher than the group level if all of your privileged users have he same group number in their UIC, and that group includes only privileged users doing system management.

Logical Names None of us is immortal.
Remember to document your customizations THOROUGHLY! If you get hit by a bus today, will someone else be able to come in and understand what you’ve done? Whatever system management scheme you come up with, consider the plight of someone who may come after you. If you “inherited” an operating environment from a previous SysAdmin, remember how you felt when you had to figure out what had been done in the past. Remember that none of us will be around forever, either biologically or professionally. Not only are we mortal, but in these layoff-crazy days, any of us can be turned out into the job market at the whim of management on zero notice. Remember to document your system management procedures thoroughly. This may even be required by the local IS Auditors. When you are away on holiday, out sick or otherwise not around, someone else should be able to pick your notes and figure it out without having to spend a lot of time exploring the system.

Seminar 1024 OpenVMS Networking

Networking Network stacks for OpenVMS: TCP/IP DECnet Utilities:
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 only DECnet, LAT and MOP. As the need to support TCP/IP evolved, Digital provided the “Ultrix Connection” software we now know as “UCX” and which has come to be known as TCP/IP Services for OpenVMS. By that time, DECnet had evolved into its fourth major phase which is why we call it DECnet Phase-IV. About the same time as Digital was developing its early TCP/IP offerings, it was also developing a new version of DECnet called DECnet/OSI for “Open Systems Interconnect”, also known as DECnet Phase-V, now known as DECnet-Plus. DECnet-Plus was built around the OSI “seven layer model” and did not include specifications for support of the proprietary LAT and MOP protocols, nor did it provide extensive low-level (Layer 1) support. So LANCP was developed to fill the MOP and low-level support niche.

Networking - TCP/IP TCP/IP Services for OpenVMS
Formerly known as UCX (Ultrix Connection) Developed, sold and supported by HP, shares code base with Tru64 TCP/IP Management interface somewhat weak. Some features (like adding secondary name server) require editing config. files manually. Access to non-volatile Database inconsistent: sometimes SET CONFIG, sometimes SET/PERMANENT. TCP/IP Services for OpenVMS is the new official name for the software that had come to be known as “UCX”. TCP/IP Services was renamed and redeveloped so as to share a common code base with the TCP/IP stack for Tru64. While TCP/IP Services is developed and supported by the same company produces OpenVMS, it does have some weaknesses. TCP/IP Services’ management interface is somewhat inconsistent when it comes to setting characteristics in the “permanent database”. Sometimes the command form uses SET CONFIG (as contrasted with just SET that effects only the “volatile” database) and sometimes the command form requires a /PERMANENT qualifier to indicate that something is being set in the non-volatile database. Also, adding a secondary name server requires manually editing the configuration files, since the management interface does not provide for this.

Networking TCP/IP TCPware
Native to and developed on OpenVMS (originally on VAX/VMS, ported to Alpha). Developed, sold and supported by Process Software, Inc. Proprietary Management Interface, now similar to Multinet in some ways. Slightly more functionality than (UCX), performs better than Multinet and *UCX). The TCPware product from Process Software was developed natively to VAX/VMS and then ported to Alpha. The TCPware management interface is proprietary and unlike DECnet. Since Process Software now also owns the Multinet product, TCPware’s management interface is becoming more like that of Multinet. TCPware provides some functionality that is not found in TCP/IP services. However, discussion of the differences is outside the scope of this presentation.

Networking - TCP/IP Multinet
Developed from BSD V4.3 code by TGV, Inc. on VAX/VMS, ported to Alpha. Now developed, sold and supported by Process Software, Inc. Proprietary Management Interface. Functionality similar to TCPware. Performance is somewhat better than (UCX), less than TCPware. The Multinet TCP/IP product is descended from 4.3BSD code and was developed by a company called TGV on VAX/VMS. It was later ported to Alpha. TGV sold Multinet to Cisco Systems, and Cisco sold it to Process Software. Multinet’s management interface is proprietary, but consistent. In general, most functionality of the software is available through the management interface without manually editing configuration files. In general, Multinet enjoys feature parity with TCPware since the two products are now owned and developed by the same company. Multinet performance is somewhat better than that of UCX. However, since TCPware is native to OpenVMS its performance is somewhat better than that of Multinet or UCX.

Networking - TCP/IP Author’s opinion re: Marvel:
TCP/IP Services for OpenVMS will probably be Marvel-ready sooner than Process Software’s products; however, TCPware and Multinet provide more robust functionality - should be worth waiting for on Marvel. (SMP considerations) Opinion of the Author of this presentation (not an official statement of any kind): Since TCP/IP Services is developed and supported by same company that provides OpenVMS, it will probably provide better multiprocessor performance than third party products. However, since the other TCP/IP products provide more robust functionality, they should be worth waiting for on Marvel.

Networking - TCP/IP CMU/IP Freeware, a bit old.
Originally developed by TEK, released to Carnegie Mellon Univ. C.S. department - became freeware. VAX only - no known Alpha port. TCP/IP-V4 only. CMU/IP is a freeware TCP/IP stack for OpenVMS-VAX. It has never been ported to Alpha. CMU/IP is a bit old and does not provide much beyond the basic TCP/IP “end node” functionality. Also, it is TCP/IP V4 only. As of the date this presentation was prepared, CMU/IP was available on the web at ftp://ftp.csus.edu/pub/cmuip. There may be other sources. Search the Google archives of the comp.os.vms newsgroup for CMUIP, CMU-IP or CMU/IP for more information.

Networking - DECnet Developed by Digital for PDP-11, migrated to VAX and ported to Alpha. Phase-IV is in use widely. Phase V used where it is needed. Also known as DECnet-Plus or DECnet/OSI. DECnet is the original network stack available for OpenVMS. It’s roots go back to the days of the PDP/11 operating systems. DECnet Phase-IV is still widely used, even though it has gone into mature product support. DECnet-IV is very reliable and simple to manage. Just set it and forget it, for the most part. DECnet-V, known as DECnet-OSI and DECnet-Plus is used where the functionality it provides is needed. In general though, TCP/IP co-existence has been mandated due to the need to consolidate onto a single network infrastructure and support system.

Networking - DECnet DECnet Phase IV is very SysAdmin friendly, but takes some getting used to. “Set it and forget it” - easily configured, does not issue a lot of OPCOM messages unless there is trouble on the line(s). Specification was published, no longer publicly available on the web. DECnet phase-IV has a fairly simple and straight-forward management interface. The Network Control Program (NCP) uses SET commands to modify the volatile database (in-memory database or the running software) and DEFINE commands to modify the permanent database (on-disk information used when the software is started). Generally, DECnet-IV does not require a lot of daily attention. Line and circuit counters can be zeroed daily if needed to track network issues, but the software will run quite happily for extended periods without doing so. DECnet-IV is very conservative about issuing OPCOM messages, generally only on line and circuit transitions, adjacency transitions and other noteworthy events. The DECnet-IV specification was available from the old Digital web site until recently. The open source community used it to develop a freeware DECnet stack for Linux and *BSD. It no longer appears at the old URL.

Networking - DECnet DECnet Phase IV Permanent database
DEFINE commands in NCP Volatile database SET commands in NCP DECnet-IV’s management interface is simple and consistent. Information pertaining to the executor (the “DECnet kernel”), network nodes, line, circuits and DECnet objects is stored on disk and managed using DEFINE and PURGE commands. The permanent data used when starting up the DECnet software. The running DECnet software, or the “volatile” database is modified using SET and CLEAR commands. Generally, anything that can be DEFINEd can also be SET. Even the on-line HELP for NCP reflects this.

Networking - DECnet DECnet Phase IV Provides MOP Remote Console
CONNECT command in NCP Provides MOP downline load, upline dump LOAD and TRIGGER commands in NCP Provides for remote management of other nodes. SET EXECUTOR NODE command in NCP, requires privilege and remote password. In DECnet-IV, you can connect to the remote console of devices supporting MOP Remote Console using the CONNECT command in NCP. DECnet-IV also provides support for MOP downline load requests and upline dump requests from terminal servers, remote VMS satellite nodes, etc. Nodes supporting it can be TRiGGERed to request an downline load. There is also a LOAD command available for those remote nodes that support it. DECnet-IV even provides for remote management of other DECnet executors, within certain limits. The SET EXECUTOR NODE command can be used to tell NCP that subsequent commands issued at he command line should be sent to a remote node for execution. This allows some management of remote DECnet nodes that support this function.

Networking - DECnet DECnet Phase V (DECnet-Plus)
More complicated to manage - management paradigm follows the OSI seven-layer model. Circuits are built from the bottom up, following the OSI seven-layer model. Management is performed using NCL (Network Control Language). Non-volatile database is .NCL files - no “permanent” database. DECnet-V, also known as DECnet-Plus and DECnet-OSI takes a more “from the ground up” approach to network management. It follows the paradigm of the OSI seven-layer model for building the network by configuring the software one layer at a time. The DECnet-V management interface is the Network Control Language (NCL) program. Unlike DECnet-V, NCL has no “permanent database” - everything is done in memory. DECnet-V’s “permanent database” consists of the NCL files that are used at DECnet-V startup time to configure and start the software. Unlike DECnet-IV, DECnet-V is designed to handle a much broader spectrum of objects. Hence, the NCL on-line HELP can be a bit confusing and cryptic to those accustomed to NCP.

Networking - DECnet DECnet Phase V (DECnet-Plus)
OPCOM messages are more plentiful and more verbose than Phase IV. Allows for diagnosis of trouble in each layer. Provides some features not available in Phase IV. Complete specification is not published. DECnet-V issues a lot more OPCOM messages than DECnet-IV. Almost all network events trigger an OPCOM message from starting the software to configuring the software to normal network events like bursts of collisions, and so on. Because DECnet-V is designed around the seven layer model, the messages issued can be used to diagnose trouble down to a specific layer. So troubleshooting efforts can be more targetted. There are some features and functionality in DECnet-V that are not available in DECnet-IV. Most notably, DECnet-V is better suited to DECnet -over-TCP/IP. The complete Decnet-V specification has never been published, to the knowledge of the author of this presentation.

Networking - DECnet Access Control
Set up proxy records in SYS$SYSTEM:NET$PROXY.DAT using the AUTHORIZE program. Enable proxy access in NCP (Phase-IV): incoming, outgoing. Incoming proxy access, if disabled, defaults to the access control info of the target object instead of the source node/user. DECnet Access Control focuses mostly on network proxies and object security. Decnet proxy records are maintained using the OpenVMS AUTHORIZE program. Remote access by proxy is configured in the NCP program for DECnet-IV. If incoming proxy access is disabled, inbound access is instead controlled by the access control information of the target object.

Networking - DECnet Access Control
Create the proxy database if it doesn’t already exist. Use AUTHORIZE, CREATE/PROXY Set up proxy records in Authorize. Enable proxy access in NCL (Phase-V): See the SET SESSION CONTROL statements. In DECnet-V, as in DECnet-IV, you must first create the proxy database if it doesn’t already exist. This is done with the AUTORIZE program using the CREATE/PROXY command. Then use AUTHORIZE to populate the proxy database Incoming and outgoing proxy access is controlled using SET SESSION CONTROL statements in NCL. See the DECnet-V Advanced Configuration documentation for information concerning your specific needs. DECnet-V configuration is outside the scope of this presentation.

Networking - DECnet FAL Logging Two Logical Names: FAL$LOG FAL$OUTPUT
FAL is the DECnet File Access Listener object. It gets started whenever a remote DECnet node (or the local node) requests network access to a file for any reason. There are two undocumented logical names that can be used to expand the logging information that comes out of the FAL process (FAL$LOG) and to record that information someplace other than the default file destination (FAL$OUTPUT).

Networking - DECnet FAL Logging FAL$LOG
In SYLOGIN or the DECnet object file: $ DEFINE FAL$LOG “1/disable=8” This is an unsupported feature “1”: file name and file type access information disable=8 disables “Poor Man’s Routing”: dir node1::node2::node3:: The FAL logical name FAL$LOG should be setup in the SYS$SYLOGIN procedure or in the DECnet object file, SYS$SYSTEM:FAL.COM The value shown for this logical name has two functional parts. The digit before the slash tells FAL what level of information logging to use. The string after the slash tells FAL to disable “poor man’s routing”, where a request is routed through multiple systems to achieve the same end as having routing nodes where node exist (hence the name, since DECnet-IV licenses greater than end-node are tarditionally more expensive than end-node licenses).

Networking - DECnet FAL Logging FAL$LOG, cont’d FAL$OUTPUT
Produces copious output - use with discretion. FAL$OUTPUT Can be used to specify the name of the log file to create in place of SYS$OUTPUT $ DEFINE FAL$OUTPUT FAL.LOG Depending upon the level of logging requested, FAL$LOG can produce copious amounts of output and should be used with discretion to avoid filling up a disk over weekend. The other undocumented FAL logical name is FAL$OUTPUT. This one can be used to specify that the output of FAL should go someplace other than to the SYS$OUTPUT stream. Here again, DEFINE this logical name in SYS$SYLOGIN or in the object file for FAL. Note that the FAL object is typically just the FAL.EXE image. To utilize these logical names without putting them in SYS$SYLOGIN, you can make a FAL.COM procedure in the SYS$SYSTEM path to define the logical names and then invoke FAL. Another approach might be to put these logical names into the login script of one or more accounts used for remote FAL access where you want extended logging information for whatever reason.

Networking - LAT LAT - Local Area Transport Robust, Efficient
Can package data for multiple sessions at the same MAC address into common packets. Not routable No routable info in the network layer DEC-proprietary (licensed) Specification published under license LAT was commonly used for terminal server access prior to the rise of TCP/IP and TELNET. LAT is a very efficient and robust protocol. Data for multiple sessions at a specific MAC address can be packed into a single packet to reduce network overhead and make better use of the packet size. LAT is not routable, however, as the packets contain no useful information that would make routing useful or efficient. LAT is a DEC-proprietary protocol. The specification is available only under license. The Open Source community has made efforts to reverse-engineer it.

Networking - LAT LAT Control Program (LATCP)
Managememt interface for LAT Controls services broadcast by an OpenVMS node Used to create, manage and delete LTA devices on OpenVMS nodes. The program for managing LAT on OpenVMS is called LATCP. It is used for setting up and controlling services broadcast by the node, as well to setup and configure LTA devices which are used for “reverse-LAT” - outbound connections to remote services or ports on servers for printers, modems, terminals, etc.

Networking MOP Maintenance Operation Protocol Not routable
No routable info in the network layer DEC-proprietary (licensed) Specification published under license Remote Console facility Downline load, upline dump. A service originally provide by the DECnet-IV executor and managed using NCP is MOP, the Maintenance Operation Protocol. Like LAT, MOP cannot be routed. Like LAT, MOP is DEC-proprietary and the specification is subject to license. MOP provides for remote console capabilities, but also provides that remote systems can receive their operating software from as a downline load from a load host, or dump their memory up to an upline dump host.

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

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

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

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

Networking - Remote Access
Types of remote Access, cont’d: TCP/IP: TELNET Rshell Rlogin The Various TCP/IP stacks also provide for some common modes of remote access, including Telnet, Remote Shell (RSHELL), Remote Login (RLOGIN) and in the case of some of the newer versions of he TCP/IP stacks for OpenVMS, Secure Shell and Secure Socket Layer are provided for. See the documentation or the vendor for your TCP/IP stack to see what is currently availabe as this tends to change frequently.

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

Networking - Remote Proc.’s
Security Concerns DECnet objects like TASK Unsecured accounts by any access method. (This is not a security presentation.) Again, the DECnet TASK object is best left out or disabled for security reasons. If needed, care should be taken to keep your system as secure as possible. Regardless of how the system is accessed, unsecured accounts (no password, weak passwords) represent a significant risk. Good system management must include vigilance in this area. In-depth security discussion is beyond the scope of this presentation, although elements of OpenVMS security will be examined near the end of this presentation.

Network Alerts OPCOM Alerts for network access
SET AUDIT/ENABLE=CONNECTION DECnet (Phase IV) $IPC SYSMAN SET AUDIT/ENABLE=LOGIN= ALL, BATCH, DETACHED, DIALUP, LOCAL, NETWORK, REMOTE, SUBPROCESS Simple things that can help alert the OpenVMS System Manager to security issues include enabling Security Audits of incoming connections via Telnet, CTERM, DECnet, etc. In addition to login failures (LOGFAIL), successful logins can likewise be audited to help ensure that everyone’s tracks can be followed, so to speak. Here again, care must be taken to not audit too much so that disk space and processing resources are not overly dedicated to security issues, unless that is the purpose of the system.

Network Alerts Additional OPCOM Alerts for FTP
Add commands to the DCL proc. associated with the FTP service. Example: MULTINET:FTP_SERVER.COM Can be as general or specific needed. See the documentation and example code for your TCP/IP stack. Additional OPCOM alerts can be set up for FTP using the service procedures supplied with TCP/IP stack or by building you own “wrapper” around the vendor’s scripts. These can be as general or as specific as deemed necessary and/or appropriate for each situation. The best source of information is the vendor of your TCP/IP stack or FTP server software.

Seminar 1024 System Startup Procedure

System Startup Default /STARTUP procedure: SYS$SYSTEM:STARTUP.COM
Set using SYSBOOT, SYSGEN or SYSMAN. Here we begin our discussion of the system startup procedures. The procedure run as the STARTUP process on OpenVMS is the procedure associated with the /STARTUP qualifier in SYSGEN, SYSMAN or SYSBOOT. For example, the command in SYSGEN or SYSBOOT would look like this: SET/STARTUP filespec In SYSMAN, the command is preceded by the PARAMETERS keyword: SYSMAN> PARA SET/STARTUP filespec

System Startup STARTUP Phases: In SYS$STARTUP:VMS$VMS.DAT
RMS Indexed file Changes to this area of the startup are *NOT* supported by HP. The OpenVMS startup procedure, SYS$SYSTEM:STARTUP.COM runs in phases. These phases are setup in the VMS$VMS.DAT file. This is an ordinary RMS indexed file. Do NOT change this file as such changes may jeopardize your support agreements.

System Startup STARTUP Phases:
$ TY SYS$STARTUP:VMS$VMS.DAT BASEENVIRON DVMS$BASEENVIRON-050_VMS.COM E*BASEENVIRON DVMS$BASEENVIRON-050_SMISERVER.COM E*BASEENVIRON DVMS$BASEENVIRON-050_LIB.COM E*BASEENVIRON DDECDTM$STARTUP.COM E*BASEENVIRON DLICENSE_CHECK.EXE E*CONFIG DVMS$CONFIG-050_VMS.COM E*CONFIG DVMS$CONFIG-050_ERRFMT.COM E*CONFIG DVMS$CONFIG-050_CACHE_SERVER.COM E*CONFIG DVMS$CONFIG-050_CSP.COM E*CONFIG DVMS$CONFIG-050_OPCOM.COM E*CONFIG DVMS$CONFIG-050_AUDIT_SERVER.COM E*CONFIG DVMS$CONFIG-050_JOBCTL.COM E*CONFIG DVMS$CONFIG-050_LMF.COM E*CONFIG DVMS$CONFIG-050_SHADOW_SERVER.COM E*CONFIG DVMS$CONFIG-050_SECURITY_SERVER.COM E*DEVICES DVMS$DEVICE_STARTUP.COM E*INITIAL DVMS$INITIAL-050_VMS.COM E*INITIAL DVMS$INITIAL-050_LIB.COM E*INITIAL CVMS$INITIAL-050_CONFIGURE.COM E*LPBEGIN DVMS$LPBEGIN-050_STARTUP.COM E*PRECONFIG DIPC$STARTUP.COM E*PRECONFIG DVMS$SPIRALOG_STARTUP.COM E* Here’s a look at the contents of VMS$VMS.DAT. You can see which procedures are executed and in what sequence - the file is read sequentially.

System Startup Phases, Files
INITIAL DEVICES SYCONFIG SYLOGICALS SYPAGSWPFILES PRECONFIG CONFIG SYSECURITY BASEENVIRON LPBEGIN SYSTARTUP_VMS LPMAIN LPBETA END Here’s a little more “plain English” presentation of how the startup procedure progresses. The file names are indented from the phase names in an effort to clarify the sequence of events.

System Startup Phases, Files
INITIAL DEVICES SYCONFIG These files are always SYLOGICALS executed, even during a SYPAGSWPFILES “MIN”-imum boot. PRECONFIG CONFIG SYSECURITY BASEENVIRON LPBEGIN SYSTARTUP_VMS LPMAIN LPBETA END Note that even during a minimum boot, some procedures are always a part of the startup sequence. It is best not to MOUNT disks in these procedures unless it will always be okay to do so, even in a minimal startup.

System Startup Site-Specific STARTUPs:
SYSTARTUP_VMS.COM in SYS$MANAGER path. SYSTARTUP_V5.COM in V5.x SYSTARTUP.COM in V4 and earlier. The site-specific startup procedure is executed during the LPBEGIN phase of STARTUP. For OpenVMS V6 and later, the site-specific system startup procedure is SYS$MANAGER:SYSTARUP_VMS.COM. For OpenVMS V5.5-2 and or VAX/VMS v5.x, the site-specific system startup procedure is SYS$MANAGER:SYSTARTUP_V5.COM. For VAX/VMS V4 and earlier, site-specific system startup procedure is SYS$MANAGER:SYSTARTUP.COM. Some folks simply use in their SYSTARTUP_VMS or SYSTARTUP_V5 procedure if the system has been upgraded or migrated from earlier versions and/or architectures.

System Startup STARTUP Parameters: STARTUP_P1
blank - Normal System Startup “MIN” - Minimal Startup No SYSTARTUP_VMS but Most of the other SY*.COM proc.’s will still be run. The STARTUP procedure accepts a couple of parameters. These are derived from the values of the system parameters STARTUP_P1 through STARTUP_P8. Currently, only P1 and P2 are used. The other are reserved to OpenVMS engineering. For a normal system startup, STARTUP_P1 is empty or blank. For mininum startup, set STARTUP_P1 to “MIN”. Other values are available, but reserved to OpenVMS enginerring for updates and such.

System Startup STARTUP Parameters: STARTUP_P2 STARTUP_P3 thru _P8
blank - Normal System Startup “1”, “YES” or “TRUE” - Verify on STARTUP_P3 thru _P8 Reserved for future use STARTUP_P2 is used to control DCL command verification during the startup process. If STARTUP_P2 is empty or blank, verify is “off” or “false”. If STARTUP_P2 is “1” or “TRUE”, verify is “on”. STARTUP_P3 through STARTUP_P8 are reserved to OpenVMS engineering for future use.

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

System Startup SYSTARTUP_VMS :
Author prefers to keep procedure modular for easier maintenance, invoke node-specific proc.’s from SYSTARTUP_VMS: $ FSP = F$SEARCH( - “SYS$MANAGER:SYSTARTUP.COM” ) $ IF FSP .NES. “” Avoids redundant, cut-and-paste code. This slide illustrates a way to see if a particular startup element exists before attempting to invoke it. This reduces the number of diagnostics issued during the site-specific startup procedure and helps facilitate reduction of redundant, cut-and-paste code.

System Startup SYSTARTUP_VMS : Logging SYSTARTUP_VMS: $ SET NOON
$ DEFINE SYS$OUTPUT - SYS$MANAGER:SYSTARTUP_VMS.LOG . $ DEASSIGN SYS$OUTPUT This slide illustrates a trick for providing a log of events occurring during the site-specific startup procedure. Near the top of the procedure, insert a DEFINE SYS$OUTPUT command. DCL will recognize this and direct subsequent output to the file. A SET NOON helps insure that the procedure will run to completion in spite of errors that may occur during it, and enables the procedure to detect the success or failure of each element. Near the bottom of the procedure, insert a DEASSIGN SYS$OUTPUT command. DCL will detect this and close the file. SYS$OUTPUT data will again show up on OPA0:.

System Startup Saving/reporting a crash dump at System Startup time:
$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP COPY ddcu:<dir>:SAVEDUMP.DMP ! copy to wherever is convenient. SET OUTPUT SYS$MANAGER:SYSDUMP.LIS ! Set this as you like READ/EXEC ! READ SYS$SYSTEM:SYSDEF ! For VAX READ SYS$LOADABLE_IMAGES:SYSDEF ! For Alpha SHOW CRASH SHOW STACK /ALL SHOW SUMMARY SHOW PROCESS /PCB /PHD /REGISTERS SHOW SYMBOL /ALL EXIT This slide illustrates a method for performing preliminary crash dump analysis at startup time. If the dump file contains a valid dump, the remaining commands will execute; if not, the remaining commands will be ignored.

System Startup DEFINE-ing Group Logicals at Startup:
SET up a DCL procedure to DEFINE (or assign) the needed logicals using /GROUP and whatever access mode is appropriate. Invoke that procedure as a detached process at system startup time. It is frequently necessary to define some group-level logical names at system startup time. Trouble is, until a user in that group logs into the system, the group logical name table 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 that procedure as a detached process under that UIC at system startup time. When the process exists, the group logical name table and its contents will remain.

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

System Startup DEFINE-ing Group Logicals at Startup:
Alternate Example: $ RUN SYS$SYSTEM:LOGINOUT.EXE- /UIC=[300,1]/INPUT=NLA0:/OUTPUT=NLA0: The UIC specified does not need to exist in the UAF. The example creates the LNM$GROUP_ table. Logical names can then be created in that table by any suitably privileged process. Here’s a variation on that technique. In this case, the process is run with the null device as both the input and output. The net effect of running the process is to create the desired logical name table. Once created, the logical name table can be populated by any suitably privileged process or procedure.

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

System Startup Setting logins at Startup, cont’d:
Global DCL symbol (STARTUP process) is used in SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM: $set logins/interactive='startup$interactive_logins This global DCL symbol is used in the procedure SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM which is run AFTER the site-specific startup procedure, SYSTARTUP_VMS. So, the number of interactive logins to be allowed upon completion of the system startup sequence can be manipulated by assigning the desired value to startup$interactive_logins. However, this has the drawback that unless a way is found to soft code this value, the the site-specific startup procedure may need to be edited in order to change it.

Change the value of startup$interactive_logins during SYSTARTUP_VMS: $ startup$interactive_logins == - F$GETSYI( “IJOBLIM” ) Illustrated here is a method of allowing the number of interactive logins permitted after startup to be soft coded. The value of IJOBLIM read in when the system parameters get loaded does not change until SET LOGINS/INTERACTIVE=value occurs very late in the startup sequence. So, the system parameters file can be used as a source of the desired value for interactive logins allowed upon completion of the startup.

$ startup$interactive_logins == - F$GETSYI( “IJOBLIM” ) Notes: Set the desired value for IJOBLIM in MODPARAMS and run AUTOGEN, or change the CURRENT value using SYSMAN or SYSGEN. Change takes effect on next boot. Set the desired or required value into the IJOBLIM parameter in MODPARAMS.DAT as well as in the current system parameters (or edit MODPARAMS.DAT, then run AUTOGEN through at least the SETPARAMS phase). Insert the code shown into the site-specific startup procedure, very late in the procedure - near the end to help ensure it doesn’t get changed by anything else. Upon your next startup, you will have the desired number of logins set automatically and you can change it at anytime without having to edit the site-specific startup procedure.

$ startup$interactive_logins == - F$GETSYI( “IJOBLIM” ) Notes, cont’d: IJOBLIM is a dynamic parameter. The SET LOGINS/INTERACTIVE command displays or varies its value. See the HELP. Remember that IJOBLIM is a dynamic parameter. It is this parameter that gets modified by the SET LOGINS/INTERACTIVE=value command. The command with no value or without the /INTERACTIVE qualifier displays the current number of logins and the number allowed.

SET LOGINS/INTERACTIVE caveat: Largely undocumented, little known fact: until this command is issued for the first time after a reboot, the job controller will not create interactive processes. If used in SYSTARTUP_VMS, it may enable logins before the system is ready for users to log in. Here’s an important caveat regarding SET LOGINS/INTERACTIVE: It is largely unknown and undocumented that the system job controller will not create interactive process when OpenVMS is first booted until this command is issued with a value. Once that happens, logins become possible, even if the value specified is zero. Remember that suitably privileged users can still login, even when logins are disabled by setting them to zero. If the site-specific startup procedure, or a procedure that it invokes executes a SET LOGINS/INTERACTIVE=x command, this may result in logins being enabled before the system is ready to have users log in. Application errors and loss or corruption of data may be possible under such circumstances.

SET LOGINS/INTERACTIVE caveat: DO NOT USE THIS COMMAND IN SYSTARTUP_VMS!!! …or any proc. that it invokes!!! Use the global DCL symbol instead (STARTUP$INTERACTIVE_LOGINS). For the reason outlined in the notes on the previous slide, the author of this presentation recommends that this command NEVER be used in the site-specific startup procedure or any that it invokes. Use the global DCL symbol instead.

System Startup - VMS Files
Must never be changed unless software documentation or VMS support instructs you to do so. May be replaced when VMS or layered products are upgraded. May use deprecated lexical functions (like F$LOGICAL()), or may contain misspelled function names (like F$GETSYS(), DCL sees only F$GETS). Some other important notes about the system startup, files: Never muck about with the DCL procedures and data files in the SYS$STARTUP directories SYS$SYSROOT:[SYS$STARTUP] and SYS$COMMON:[SYS$STARTUP]. They may quite likely be replaced on the next OpenVMS or layered product upgrade or patch kit install. Also, be careful about emulating anything you find in any of the startup procedures provided with OpenVMS. They may use deprecated lexical functions like F$LOGICAL() or may contain misspelled lexical function names like F$GETSYS (should be F$GETSYI). DCL only looks at the first four characters of the a command or function name, so these do not cause problems now, but may result in errors later if DCL is ever revamped in a major way.

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

Seminar 1024 SYSMAN and STARTUP

SYSMAN & STARTUP SYSMAN can be used to modify the “user” portion of the startup database. Two database files used by SYSMAN: STARTUP$STARTUP_VMS Used for the VMS startup DO NOT MODIFY !!! STARTUP$STARTUP_LAYERED When you add an item using SYSMAN it goes here. The SYSMAN utility includes options to add items to the startup sequence by entering records in the startup databse. SYSMAN will modify the STARTUP$STARTUP_VMS file in the startup database. However, this file should only be modified by OpenVMS support or engineering, or by software or patch kits developed by them. The OpenVMS system manager must never modify STARTUP$STARTUP_VMS unless intsructed to do so by OpenVMS support. The STARTUP$STARTUP_LAYERED file in the startup database is the correct place to make site-specific modifications to the startup database.

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

SYSMAN & STARTUP Allows for entering startup items that run after SYSTARTUP_VMS. SYSTARTUP_VMS is invoked during the LPBEGIN phase. Valid phases for SYSMAN STARTUP entries are LPBEGIN, LPMAIN, LPBETA and END. Premature logins are possible if SYSTARTUP_VMS enables logins before startups in later phases (LPMAIN, LPBETA or END) have run. SYSMAN allows for entering items into the startup sequence that run after SYSTARTUP_VMS. So, these notes should be borne in mind when planning and implementing startup modifications through SYSMAN: SYSTARTUP_VMS is invoked during the LPBEGIN phase. This phase is not executed in a minimal startup. Neither are any of the other “LP” (Layered Product) phases. Valid phases for startup sequence modifications entered using SYSMAN are LPBEGIN, LPMAIN, LPBETA and END, in order of execution. When adding a startup that occurs after SYSTARTUP_VMS is completed be aware that SYSTARTUP_VMS, or a procedure that it invokes may have enabled logins and users may already be accessing the system, before the startup sequence is complete.

Seminar 1024 Conversational Boot, Minimum Startup

Conversational Boot Most Current Alphas, VAX 7000: VAX 6000
>>> boot –fl x,1 VAX 6000 >>> BOOT boot_profile/R5=1 >>> BOOT boot_profile/R5=x Older small VAXes >>> B/R5:1 or B/R5:x VAX 8000’s See the manual Conversational boot is invoke by setting bit 0 of Register 5 before loading the bootstraps. 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). On VAX 6000s, add the /R5:value qualifier to the boot command after the name of the boot profile, or just after the BOOT command if using the default boot profile. VAX 6000s can only boot from roots 0 thru F. Most older small VAXes (VAX 4000, MicroVAX, etc.) have console variables for the boot device and the default boot flags. Just add the appropriate variant of /R5:value. For VAX 8000, 9000 and 10000, see the console documentation on how to do this.

Minimum Boot >>> b –fl 10,1 SYSBOOT> SET STARTUP_P1 “MIN”
SYSBOOT> CONTINUE Use SET WRITESYSPARAMS 0 before CONTINUE for a one-time minimum boot. Setting bit zero in Register 5 before loading the bootstraps causes SYSBOOT to pause and prompt for input at the console. Hence, the name: “Conversational boot”. At the SYSBOOT prompt, you can modify system parameters, then continue the boot up sequence. For a minimum boot, SET the STARTUP_P1 parameter to “MIN”. If the minimum boot is a one-time event, you can the SET the WRITESYSPARAMS parameter to zero(0) to prevent the system from saving the system parameters at boot time. The default value for this parameter is one(1), write the system parameters at boot time, meaning any changes you make in SYSBOOT will be saved in the current parameter set. To continue the boot up sequence, tell SYSBOOT to CONTINUE.

Seminar 1024 System Shutdown Procedure

System Shutdown $ @SYS$SYSTEM:SHUTDOWN
Prompts interactively for parameters Parameters can also be specified on the command line that invokes the procedure. See the SHUTDOWN and REBOOT symbols in SYS$MANAGER:LOGIN.TEMPLATE Let’s look now at the process of shutting down OpenVMS. The provided DCL procedure is found as SYS$SYSTEM:SHUTDOWN.COM. It should actually be found in the cluster common path. This is provided by/with OpenVMS, and so should not be modified except as instructed by OpenVMS support (which should never happen). SHUTDOWN prompts interactively for the shutdown parameters if none are specified on the command line used to invoke SHUTDOWN. Parameters to SHUTDOWN can also be specified on the command line used to invoke SHUTDOWN. Two examples are found in the SYS$MANAGER:LOGIN.TEMPLATE script template. Look for SHUTDOWN and REBOOT in that file. If you use these “foreign commands”, bear in mind that as supplied, they do NOT execute the site-specific shutdown procedure.

System Shutdown SYS$SYSTEM:SHUTDOWN.COM Parameters:
P1 = Minutes to final shutdown P2 = Reason for Shutdown P3 = Spin down disk volumes? (Y/N) P4 = Invoke SYSHUTDWN.COM? (Y/N) P5 = When will system be rebooted? P6 = Should auto. reboot be performed? (Y/N) P7 = Options (SAVE_FEEDBACK, etc.) P5 and P6 are reverse order to the prompts. To modify the SHUTDOWN or REBOOT symbols, refer to the information in the slide regarding the parameters that SHUTDOWN accepts from the command line. Notice that P5, when the system will be rebooted and P6, should an automatic reboot be performed are in reverse order to the order of the prompts issued by SHUTDOWN.

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 is run as part of the SHUTDOWN sequence if this option is selected in SHUTDOWN. Use SYSHUTDWN to stop applications, databases, daemons, etc. that may be holding files open. This provides that such software can be shutdown gracefully instead of letting SHUTDOWN STOP them abruptly later on in the SHUTDOWN sequence. Like SYSTARTUP_VMS, the author recommends keeping SYSHUTDWN modular so that individual shutdowns can be invoked at will for testing, problem solving, etc.

System Shutdown SYS$SYSTEM:SHUTDOWN.COM Logical Names
SHUTDOWN$MINIMUM_MINUTES Default value for minutes to final shutdown. AGEN$SHUTDOWN_TIME Used by AUTOGEN as minutes to final SHUTDOWN or REBOOT. In the “minutes until shutdown” prompt, a default value of zero is given. This can be over-ridden with the SHUTDOWN$MINIMUM_MINUTES logical name. Also, if P1 to SHUTDOWN is specified as “MINIMUM”, the value of this logical name is used as the time until final shutdown, or zero if the logical is not DEFINEd. The AUTOGEN procedure has its own logical name for the “minutes until final shutdown” value that will be provided to SHUTDOWN by AUTOGEN. The AGEN$SHUTDOWN_MINUTES logical name can be used to provide a value for this; otherwise, AUTOGEN uses either SHUTDOWN$MINIMUM_MINUTES or a default of zero(0).

Shutdown Options REBOOT_CHECK SAVE_FEEDBACK DISABLE_AUTOSTART
POWER_OFF The SHUTDOWN procedure allows for some shutdown options. The options listed here are common to both clusters and non-clustered systems. These options are specified as a comma-separated list either interactively or as P7 on the command line used to invoke SHUTDOWN. The option names can be abbreviated. The author of this presentation recommends using the option name up to the first underscore as a minimum abbreviation. In the next slides, we’ll look at these options one by one.

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

Shutdown Options SAVE_FEEDBACK
Saves some vital statistics about the system that can be used by AUTOGEN after the system comes back up. Same as the SAVPARAMS phase of AUTOGEN. The SAVE_FEEDBACK option does the same thing as the SAVPARAMS phase of AUTOGEN. It allows that feedback information can be saved at shutdown time allowing for AUTOGEN to be run using the saved feedback at some later time.

Shutdown Options DISABLE_AUTOSTART
Use this if needed to prevent AUTOSTART queues on this node from being restarted once SHUTDOWN has STOPped them. DISABLE_AUTOSTART stops autostart queues on the node, and prevents any queues from failing over to the node.

Shutdown Options POWER_OFF
If the system console supports it, request that the machine power itself down once VMS has been SHUTDOWN. Some of the newer Alpha console subsystems allow for the hardware system to be powered down under software control. The POWER_OFF shutdown option was added to support this feature. The POWER_OFF option is new as of OpenVMS V7.

Shutdown Options - Clusters
REMOVE_NODE for all but the last node. Node exits the cluster gracefully. CLUSTER_SHUTDOWN for the last cluster node to be shutdown. If used on all nodes, each node waits for other nodes to reach the point of exiting the cluster, then proceeds to shutdown (“dissolves” the cluster). These two options are only displayed on a node which is a member of a cluster. Specify REMOVE_NODE to have a node exit the cluster gracefully. The surviving nodes will recalculate quorum and then continue running after the resulting cluster state transition, if the total of votes remaining is greater than or equal to quorum. When shutting down the last surviving node of a cluster, or to shutdown all nodes of a cluster at the same time, specify the CLUSTER_SHUTDOWN option. If you use this to shutdown all the nodes of a cluster at the same time, each node will wait for the others to reach a common point in the shutdown, then they will all shutdown together gracefully dissolving the cluster.

Every Shutdown Author recommends you always specify option REBOOT_CHECK for all nodes. Has been helpful in preventing some nasty surprises. A reminder that the REBOOT_CHECK option can be very helpful in preventing problems, especially when a cluster or a system has run for many months without being shutdown. While not 100% comprehensive, it can detect some kinds of situations that may evolve in a long-uptime system or cluster, such as key files getting deleted. The Author of this presentation recommends always using the REBOOT_CHECK option of SHUTDOWN based on personal experience.

Seminar 1024 AUTOGEN

AUTOGEN SYS$UPDATE:AUTOGEN.COM
DCL procedure supplied by OpenVMS as an aid in tuning the OpenVMS system. Not a replacement for diligent system management. This presentation has mentioned the AUTOGEN procedure, so let’s take a look at it in a bit of detail. AUTOGEN is a DCL procedure supplied by/with OpenVMS as an aid to tuning the system and maintaining modifications to the system parameters. While AUTOGEN can point up some problems with proposed changes to the system parameters, and can suggest other changes that may be useful to maintain or improve performance, it is not a substitute for diligent system management. You must still monitor your system’s performance and tune the system to maintain expected levels of performance or service.

AUTOGEN Applies changes to the default system parameters as specified in the file SYS$SYSTEM:MODPARAMS.DAT Is invoked during installs and upgrades, sometimes more than once. Can be used to help size the swap and page files. AUTOGEN applies changes to the system parameters as specified in the SYS$SYSTEM:MODPARAMS.DAT file. The OpenVMS system manager maintains MODPARAMS based on the need of the site, system or cluster. AUTOGEN is invoked during OpenVMS installation and upgrades, sometimes more than once. AUTOGEN calculates changes to the system parameters based on entries in MODPARAMS, but can also suggest changes to the system swap, page and dumpfiles based on the physical configuration and on observed utilization of the system (feedback).

AUTOGEN - MODPARAMS SYS$SYSTEM:MODPARAMS.DAT
This is where changes to the default values are made so they persist from one AUTOGEN to the next. Entries look like this: parameter_name = needed_value MIN_parameter_name = needed_value MAX_parameter_name = needed_value ADD_ parameter_name = needed_value MODPARAMS is the supported method for setting modifications to the values of the system parameters. Values specified in MODPARAMS are applied to the DEFAULT system parameters. So, changes are not cumulative. Also, any changes made outside of MODPARAMS will be wiped out by AUTOGEN. AUTOGEN accepts your specified modifications and also calculates changes to related parameters where appropriate. There are four type of entries that can be made in MODPARAMS to specify changes to the default values of the system parameters: hard-coded values, minimum values, maximum values and additional values.

AUTOGEN - MODPARAMS parameter_name = needed_value
Provides a hard-coded value for the parameter. SCSNODE = “ALPHAONE” GBLPAGES = AUTOGEN calculations do not over-ride hard-coded values. Hard-coded values are appropriate for some system parameters such as the SCSNODE name, the SCSSYSTEMID, quorum disk name and others. In some cases, other parameters can be hard-coded, also. Generally, it’s best to specify minimum values for many system parameters and let AUTOGEN use higher values if it calculates that higher values would be helpful. In any case, the values that AUTOGEN calculates for system parameters do not over-ride hard-coded value specified in MODPARAMS.

AUTOGEN - MODPARAMS MIN_parameter_name = minimum_value
Provides a minimum value for the parameter. MIN_GBLPAGES = AUTOGEN may calculate and use a higher value, but will always use the MIN_ if it calculates a lower value. Sometimes, it is appropriate to specify a minimum value for some parameters and let AUTOGEN use higher values for them, if AUTOGEN determines that higher values would be helpful for performance reasons or other reasons. In these cases, use a MIN_ value in MODPARAMS. AUTOGEN will reflect that the values of such parameters are not allowed to be lower than the value specified for them in MODPARAMS.

AUTOGEN - MODPARAMS Provides a maximum value for the parameter.
MAX_parameter_name = maximum_value Provides a maximum value for the parameter. MAX_GBLPAGES = AUTOGEN may calculate and use a lower value, but will always use the MAX_ if it calculates a higher value. Some times, it is appropriate to specify a maximum value for some parameters and let AUTOGEN use a lower value if it calculates that a lower value is appropriate. In these cases, use a MAX_ value in MODPARAMS. AUTOGEN will reflect that the values of such parameters are not allowed to exceed the value specified for them in MODPARAMS.

AUTOGEN - MODPARAMS ADD_parameter_name = addtl_value
Provides an addition to the default value for the parameter. ADD_GBLPAGES = 81920 AUTOGEN can use feedback to calculate a new value, then adds the specified value to the calculated value. In other cases, it may only be necessary to specify that AUTOGEN should add a certain value to the calculated value of some parameters, but otherwise allow AUTOGEN calculations to prevail. In these cases, AUTOGEN will perform all of its usual calculations, then add the specified value to the calculated value of such parameters. For parameters not calculated by AUTOGEN, the value specified is added to the default to arrive at the new value.

AUTOGEN - Phases SAVPARAMS - 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 overall AUTOGEN task. The AUTOGEN phases are listed above. In the following slides, we’ll discuss these phases in some detail.

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

AUTOGEN - Phases Collects all data to be used in AUTOGEN calculations.
GETDATA Collects all data to be used in AUTOGEN calculations. Includes existing feedback data if it is not over 30 days old. Includes MODPARAMS info. During the GETDATA phase, AUTOGEN collects all of the information needed to perform its calculations. This includes validating the feedback information, unless NOFEEDBACK is specified or the feedback information is older than 30 days.

AUTOGEN - Phases GENPARAMS
Performs calculations and generates the new system parameters (but does not yet set them into the “Current” parameters). Creates the new list of installed images based on the state of the currently running system. During the GENPARAMS phase, AUTOGEN performs its calculations and writes a list of changes that will be applied to the default system parameters. This can be found in the SYS$SYSTEM path in the SETPARAMS.DAT file. AUTOGEN also creates a new list of images to be installed at system-startup time during the GENPARAMS phase.

AUTOGEN - Phases TESTFILES
Calculates new page and swap file sizes, but does not apply any changes. During the TESTFILES phase, AUTOGEN performs its calculations for changes it will suggest to the sizes of the swap, page and dump files. Only the calculations are performed – no changes are actually applied in the TESTFILES phase.

AUTOGEN - Phases GENFILES
Generates new swap and page files based on AUTOGEN calculations. Use entries in MODPARAMS to override: DUMPFILE=0 SWAPFILE=0 PAGEFILE=0 During the GENFILES phase, AUTOGEN will apply the changes it calculates for the swap, page and dump files. This can be over-ridden in MODPARAMS by supplying entries for the swap, page and dumpfiles with zero(0) values. These keywords can also be used to specify hard-coded values for the sizes of these files. The hard-coded values will over-ride AUTOGEN’s calculations.

AUTOGEN - Phases SETPARAMS
Creates the new boot-time (“current”) parameters. Changes take effect on the next boot. During the SETPARAMS phase, the calculated changes to the default system parameters are applied and saved as the current parameters to be loaded next time the system boots. The ACTIVE parameter set is not changed.

AUTOGEN - Phases SHUTDOWN
Shutdown the system and leave it ready for a manual boot or other console-level operations. The SHUTDOWN phase allows AUTOGEN to shut the system down to await a manual reboot, for performing operations at the console, for power-down allowing hardware maintenance, etc. A caveat about SHUTDOWN is that the site-specific shutdown procedure, SYSHUTDWN is not executed during the SHUTDOWN phase of AUTOGEN. The SHUTDOWN and REBOOT phases of AUTOGEN invoke SYS$SYSTEM:SHUTDOWN.COM.

AUTOGEN - Phases REBOOT
Reboot the system using the newly generated parameters and/or system files. The REBOOT phase allows AUTOGEN to shut the system down and specify that automatic reboot should be performed. This is what typically happens at the end of an OpenVMS upgrade or install. A caveat about REBOOT is that the site-specific shutdown procedure, SYSHUTDWN is not executed during the SHUTDOWN phase of AUTOGEN. The SHUTDOWN and REBOOT phases of AUTOGEN invoke SYS$SYSTEM:SHUTDOWN.COM.

AUTOGEN - Phases HELP Display HELP information for how to use AUTOGEN.
Useful to output this to a file: /OUTPUT=AGEN_HELP.LIS HELP There is no DCL HELP topic for AUTOGEN. However, there is a HELP option for AUTOGEN which outputs some useful information on how to use AUTOGEN. It is useful to output this information to a file for future reference. Simply specify /OUTPUT=filespec after and specify HELP as the first parameter.

AUTOGEN - Phases Typical uses:
See if current MODPARAMS settings are suitable: - 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 of your proposed parameter changes. No actual changes will be made to the current parameter set; however, a new list of installed images is generated and will be used on the next boot. The second example shows how to use AUTOGEN to generate a new current parameter set for use on the next boot. The running system is not effected. The third example show how to use AUTOGEN using feedback saved earlier, either by the SAVE_FEEDBACK option of SHUTDOWN or by running AUTOGEN with SAVPARAMS as both the starting and ending phase.

AUTOGEN - Phases Typical 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 system has not been up long enough to have any valid feedback. AUTOGEN is run from the GENPARAMS phase through the SETPARAMS phase and is told to use no feedback. The system can then be shutdown or rebooted at a later time. The second example here shows how to use AUTOGEN when you’re not certain of the validity of the feedback information. If the feedback information is older than 30 days, AUTOGEN will not use it but will still continue through the specified end phase. If P3 is not specified at all, AUTOGEN will check the validity of the feedback and if it is suspect (too old), AUTOGEN will adjust the ending phase to TESTFILES and allow the system manager to take appropriate action.

AUTOGEN - Report SYS$SYSTEM:AGEN$PARAMS.REPORT
Generated on each run of AUTOGEN during the GENPARAMS phase. Indicates any MODPARAMS errors detected by AUTOGEN. Indicates the results of AUTOGEN calculations and resulting changes to system parameters. In peforming its calculations, AUTOGEN produces a report regarding changes it makes to the default parameters to generate the new current parameter set. The AGEN$PARAMS.REPORT is generated in the SYS$SYSTEM path on every run of AUTOGEN which includes the GENPARAMS phase. Any errors or inconsistencies detected in MODPARAMS will be reported in AGEN$PARAMS.REPORT.

AUTOGEN - Logging AUTOGEN issues useful information on SYS$OUTPUT, also. Some SysAdmins find this useful: - start_phase end_phase AUTOGEN also produces some useful messages on its SYS$OUTPUT stream. A useful technique is to specify a log file as /OUTPUT when invoking AUTOGEN, as shown in the slide.

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

Useful Tips and Tricks An “uptime” command: $ SHOW SYSTEM/NOPROCESS
$ UPT*TIME :== SHOW SYSTEM/NOPROCESS Before we begin talking about system management tools, here are a couple of useful tips and tricks that can be helpful in the course of everyday operations. This slide presents a way to establish an “uptime” command like UN*X has. SHOW SYSTEM/NOPROCESS shows only the banner line with no process detail. /NOPROCESS is new for SHOW SYSTEM since V6.2.

Useful Tips and Tricks An simple command to show usage: $ SHL :== -
PIPE SHOW USERS/FULL | - (READ SYS$PIPE P9 ; - WRITE SYS$OUTPUT P9 ; - READ SYS$PIPE P9 ; - SET LOGINS) This slide presents a way to establish a simple command to show how many unique user names are logged in and how many processes those users represent. The current interactive logion statistics are displayed as well. Because this uses the PIPE command, it only works on V7.x and later of OpenVMS. Here is an example of the output from this command: $ shl OpenVMS User Processes at 30-SEP :33:56.56 Total number of users = 7, number of processes = 86 %SET-I-INTSET, login interactive limit = 350, current interactive value = 82

Seminar 1024 OpenVMS System Management Tools

System Management Tools
Supplied as no-charge additional software, licensed with OpenVMS. StorageWorks Command Console (SWCC) OpenVMS Management Station (“TNT” or “Argus”) Accessibility Manager for Distributed Systems (AMDS), Availability Manager Now, we get to the meat of this session. Here, we’ll discuss the system management tools supplied by or with OpenVMS. Our discussion today will focus on these items: StorageWorks Command Console OpenVMS Management Station AMDS and Availability Manager

Seminar 1024 StorageWorks Command Console

StorageWorks Cmd Console
Provides MS/Win GUI for management of StorageWorks storage array controllers. HSJ (CI) HSZ (SCSI) HSG (FC-SF) Uses TCP/IP to communicate with server agent on OpenVMS. Behaves like other “Explorer” software. StorageWorks Command Console (SWCC) provides a Microsoft Windows GUI management environment for StorageWorks array controllers, including the HSJ, HSZ and HSG controllers. SWCC uses TCP/IP as a data transport between the Windows client and the server agent process on the OpenVMS system. SWCC behaves like other software that uses an interface like Windows Explorer. Object trees can be expanded and traversed just like the directory structures of a hard disk. Double-clicking on an object opens it, “right –clicking” on an object opens a menu of options.

Limitations: PC’s IP address must back-translate DHCP is o.k. so long as DNS is updated when address lease is obtained / renewed. Does not work over WAN unless PC’s DNS name is “visible” outside of firewall and firewall allows the TCP ports. OpenVMS server agent will only run on one node of a cluster. SWCC has some caveats, as one might expect: Your PCs TCP/IP address must back-translate; that is, the address must equate back to a name which translates to the original address. This is mostly a security measure, though it does sometimes raise issues when dealing with network administrators. Obtaining an address via DHCP works fine as long as the DNS is subsequently updated with address just leased or renewed. Because of this, getting SWCC to work over a WAN can be a challenge. Where ever your SWCC PC goes on your corporate network, it must always be issued an address which is associated with a DNS entry that translates to the address issued. As an OpenVMS issue, the server agent will only run on one node of a cluster.

Limitations, cont’d: Unit names and storage-set names are assigned randomly and arbitrarily. Some names can be changed manually using the CLI. Can hold onto the virtual console so that other access means are denied: SET HOST/DUP, SET HOST/SCSI StorageWorks Command Console (SWCC) assigns random, arbitrary names to most containers created above the device level and below the disk unit level. This can make diagnosis from the CLI a bit trying since it then becomes necessary to explore the units to find which storage-sets comprise them, then explore the storage-sets to find the disk units that comprise them. To ease this effort, most containers can be renamed from the CLI after they have been created via SWCC. Another potential issue is that SWCC can hold onto the virtual console preventing access via SET HOST/DUP or SET HOST/SCSI.

Limitations, cont’d: Disks falling into the Failed Set are detected and reported as warnings; however, CLI messages are not passed through to the GUI - you must still connect to the CLI to get them. “Other controller restarted” Cache battery alerts Disks falling into the Failed Set are detected and reported. The controller icon will appear in the object tree with an exclamation mark icon over it. Right-clicking on the object and selecting “Properties” indicates that the controller or controller pair is in a warning status. Opening the object shows which physical device is the subject of the warning – it will appear with a warning icon over its own icon. Other CLI messages are effectively ignored by SWCC. Some conditions that are ignored include cache battery alerts and “Other controller restarted” messages, to name only two.

Limitations, cont’d: No provisions for running HSx utilities and diagnostics. No performance data available via the GUI - use the CLI to run VTDPY. In the StorageWorks Command Console (SWCC) there is no provision other than the CLI window for running HSx utilities and diagnostics. Also, no performance data is available via the GUI. Use the physical console, SET HOST/DUP or SET HOST/SCSI to run VTDPY for real-time statistics.

Management Considerations PCs must be authorized to access OpenVMS server agent. Use the SWCC configuration utility supplied with the OpenVMS-side software. Controllers and/or controller pairs must be set up using the SWCC configuration utility supplied with the OpenVMS-side software. Some of the management considerations for StorageWorks Command Console (SWCC) include: Individual client PCs must be authorized to access the OpenVMS server agent. Use the SWCC_CONFIG procedure supplied with the server agent to manage its configuration and authorize client PCs to access the server. Likewise, individual controllers and controller pairs to be managed must be set up in the server before they can be accessed via the client.

Management Considerations HSZ and HSG controller pairs present only a single virtual device for remote access - cannot connect to an individual controller by name using the CLI window. You will still need to access the physical console terminal port from time to time, as when a controller fails out of the pair. Some more of the management considerations for StorageWorks Command Console (SWCC) include: Note that newer HSZ and HSG controller pairs present only a single virtual device for managing the pair. You cannot connect to an individual controller in a pair. To access an individual controller in a pair, such as when a controller fails out of the pair, you must still connect a terminal, PC or laptop directly to the controller’s physical console port.

This is an example of the SWCC main window. It shows the object tree, the SWCC server system and the managed object under it. Note that a problem is indicated communicating with some of the controller pairs.

In the main window, you can expand a controller item to show the StorageWindow and CLI Window objects.

This is the storage window for the selected controller. The disk devices present are shown as icons. In this case, all of the icons are green indicating that they are all in a healthy status.

When we select a unit icon in the upper portion of the storage window (the units pane), the disks associated with that unit are highlighted.

The storage unit properties window is shown. Open this window by right-clicking on a storage unit and selecting Properties. The storage unit window has three tabs. Shown here is the information available on the General tab.

The storage unit properties window is shown. Open this window by right-clicking on a storage unit and selecting Properties. The storage unit window has three tabs. Shown here is the information available on the Settings tab.

The storage unit properties window is shown. Open this window by right-clicking on a storage unit and selecting Properties. The storage unit window has three tabs. Shown here is the information available on the Membership tab.

The physical device properties window is shown. Open this window by right-clicking on a device and selecting Properties. The device window has three tabs. Shown here is the information available on the General tab.

The physical device properties window is shown. Open this window by right-clicking on a device and selecting Properties. The device window has three tabs. Shown here is the information available on the Membership tab.

The physical device properties window is shown. Open this window by right-clicking on a device and selecting Properties. The device window has three tabs. Shown here is the information available on the Support Information tab.

Open the controller properties window by right-clicking on a controller/pair and selecting Properties.

Open the controller properties window by right-clicking on a controller/pair and selecting Properties. The controller properties window has three tabs. Shown here is the information available on the General tab.

Open the controller properties window by right-clicking on a controller/pair and selecting Properties. The controller properties window has three tabs. Shown here is the information available on the Event notification tab. For each controller, you can set event notification properties to allow for paging someone when an event is detected, sending , etc.

Open the controller properties window by right-clicking on a controller/pair and selecting Properties. The controller properties window has three tabs. Shown here is the information available on the Notes tab. The notes you enter here are local to your workstation and are not shared.

Open the System properties window by right-clicking on a system and selecting Properties.

Open the System properties window by right-clicking on a system and selecting Properties. The system properties window has four tabs. Shown is the information available on the General tab.

Open the System properties window by right-clicking on a system and selecting Properties. The system properties window has four tabs. Shown is the information available on the Event Notification tab. For each system, you can set event notification properties to allow for paging someone when an event is detected, sending , etc.

Open the System properties window by right-clicking on a system and selecting Properties. The system properties window has four tabs. Shown is the information available on the Notes tab. The notes you enter here are local to your workstation and are not shared.

Open the System properties window by right-clicking on a system and selecting Properties. The system properties window has four tabs. Shown is the information available on the errors tab.

Seminar 1024 OpenVMS Management Station

OpenVMS Mgt Station Provides an MS/Win GUI for management of some areas of OpenVMS: User records and identifiers OpenVMS storage Printer (but not batch) queues. Uses TCP/IP to communicate between Windows client and OpenVMS Server. The OpenVMS Management Station (OMS) provides a Microsoft GUI interface for managing user records, rights identifiers, symbiont (printer and server) queues and OpenVMS storage. The OMS server agent on OpenVMS can even be allowed to MOUNT your disk volumes at system startup time. OMS uses TCP/IP as a data transport between the server and the client.

OpenVMS Mgt Station Considerations:
No interfaces for application-specific user setups. Provides only for “traditional” OpenVMS printer queues - no provisions for TCP/IP considerations. V3.0 is still available for Alpha/NT. Later versions are Intel only. OpenVMS Management Station (OMS) porvides for GUI management of many aspects of the OpenVMS system, but not quite all. Here are some noteworthy exceptions: OMS does not provide a plug-in interface for handling application-specific user setups. These must still be done using the application’s facilities and utilities. OMS provides support for “traditional” OpenVMS printer queues. Server queues can be managed if they are set up outside of OMS. There is no provision for third-party TCP/IP printer queues and no provision for managing batch queues. OMS V3.0 is still available for Alpha/NT. Later versions are for Intel PCs only. The current version at this writing is V3.2.

OpenVMS Mgt Station Considerations:
Runs on W/NT and W2K, W/98, and W/95, but needs Internet Explorer V3.02 or later to provide some support. V3.2 Server needs OpenVMS V6.2 or later. The OpenVMS Management Stations (OMS) client can be installed on Windows/95, Windows/98, Windows/NT (V4.0 and later) and Windows No support of W/NT V3.51 or W/XP is indicated in the documentation. OMS is built on Microsoft Management Console and requires that Internet Explorer V3.02 or later be installed on the PC to provide some needed files. The OpenVMS server agent for OMS V3.2 needs OpenVMS V6.2 or later, including the hardware releases versions of V6.2 for Alpha such as V6.2-1H3.

OpenVMS Mgt Station Here is an example of the OpenVMS Management Station (OMS) display. OMS uses management domains, such as a cluster or a stand-alone system.

OpenVMS Mgt Station Once installed, an OpenVMS Management Station (OMS) program group appears under Programs on the Windows Start menu. Select the OpenVMS Management Station to launch the program.

OpenVMS Mgt Station Set up Wizard
When starting OpenVMS Management Station for the first time after installing it, the set up wizard will appear and guide you through setting up the first system or cluster to be managed.

The wizard prompts for information about the management domain. You can select to manage individual systems or an entire cluster. Then, enter a name that will be displayed for this domain. Some examples of names you might use: the node name of a non-clustered system or a cluster alias for a cluster.

The Wizard prompts for the transport to be used between the client and the primary server of this domain. From the Overview and Release notes Document: Currently the OpenVMS Management Station client supports only TCP/IP connections for primary servers. That is, the OpenVMS Management Station client will use only TCP/IP to communicate with any primary server; at least one OpenVMS system must be running TCP/IP. However, this does not prevent the OpenVMS systems from communicating with each other using DECnet.

The wizard prompts for the OpenVMS account to be used when the client (the Management Station) logs into VMS. If the Management Station’s logged in username is also a valid OpenVMS username on the node which hosts the primary server for this domain, selecting the first radio button will cause the Management Station to use that name. If the Management Station’s logged in username is NOT a valid OpenVMS username on the node which hosts the primary server for this domain, select the second radio button and enter a valid OpenVMS username for the node which hosts the primary server for this domain.

Select finish to complete your entries. The Management Station will create the object you’ve just setup and insert the object tree under it.

OpenVMS Mgt Station Here is the newly created system/domain, Brahma.
The Accounts, Printers and Storage object trees have been provided. You may now populate items under these objects by adding, modifying or deleting users, printers and storage volumes. The OpenVMS Management Station server on node Brahma will provide the client with the existing items under each object.

OpenVMS Mgt Station Logon to a managed system
During the Set Up Wizard, we told OMS to use the SYSTEM account on the managed system. In order to connect to the managed system, the Management Station must log into the system. When attempting to connect to node Brahma, the Management Station must prompt you for the password for the management account specified in the set up wizard. Pictured is a sample of the login dialogue box where the password prompt appears at the bottom of the box.

OpenVMS Mgt Station Accounts Window
Pictured here is the list of users on node Brahma. Double click on any user item to bring up the user detail dialogue.

OpenVMS Mgt Station Account Detail
The user detail dialogue box provides fields for all of the items you would enter for user via the various qualifiers of the ADD command in AUTHORIZE. The various tabs in this window provide for related sets of fields. Also provided is a Network Proxies tab where ADD/PROXY information can be entered for each user.

OpenVMS Mgt Station Printers and other Symbiont Queues
The Printers object is selected here. Detail of a Printer appears in the following slide…

OpenVMS Mgt Station Detail of Printers / Symbiont Queues
Detail of a Printer queue. The tabs across the top allow for setting those items that are available via qualifiers of the INITIALIZE/QUEUE command. The last tab, “Logical Names” allows for setting up “logical queues”; that is, logical names whose translation point to this queue, or you might choose to associate a logical name with the target device of this queue.

OpenVMS Mgt Station OpenVMS Storage
This shows the items under the storage object. Note that any volume that is not MOUNTed or is otherwise inaccessible may be shown with a slashed circle to indicate that it may need attention.

OpenVMS Mgt Station OpenVMS Storage Detail
Here is the detail display for a storage volume. The tabs allow for inputting such information as the members of a shadow-set, the volume protections, whether the Management Station server should MOUNT the volume, and more.

OpenVMS Mgt Station OpenVMS Server reads OMS configuration when it starts. Storage configured in OMS and not yet MOUNTed gets MOUNTed (if enabled). Symbiont queues configured in OMS and not yet STARTed get STARTed. The Management Station Server gets started during the System Startup sequence. The startup can be placed at a point before the applications and layered product startups so that it can be allowed to manage the disk mounts. This can be useful on systems where a large number of shadow-sets are present. For symbiont queues, there is no detail item for allowing the Management Station server to START the queues. Queues in the Management Server’s configuration will be started if this has not already been done by another process or procedure.

OpenVMS Mgt Station OpenVMS Server builds a DCL procedure that can be used to MOUNT your storage, even if the server cannot be started for whatever reason: TNT$EMERGENCY_MOUNT.COM If the OpenVMS Management Station server won’t start for some reason, you can still get your disk volumes MOUNted using a procedure that the server generates when it is running. TNT$EMERGENCY_MOUNT.COM can be invoked to MOUNT the disk volumes to their last known state as recorded by the server process. Printer and Symbiont queues must be processed by other means as the OpenVMS Management Station server does not provide a similar facility for them.

OpenVMS Mgt Station Can be useful to ease certain system management tasks that would otherwise require the use of command-line utilities, but is not a replacement for those utilities. OpenVMS Management Station provides a GUI interface to the functions and services that would otherwise be manipulated using the command line interface. OpenVMS Management Station provides a convenience, but is not 100% comprehensive - it does not replace the command line utilities. It only provides a GUI interface to the most common functions and uses of these facilities. Exceptions to what OpenVMS Management Station can handle must still be provided for by other means. An example of this would be the way that TCP/IP Services (UCX) manages print queues via the LPD$PRINTCAP facility. The facilities and procedures of TCP/IP Services must still be used to set up and maintain the print queues. Another example would be the way that Multinet manages print queue via the MULTINET:REMOTE_PRINTER_QUEUES.COM procedure. Such queues must still be managed within that framework. Likewise for TCPware.

OpenVMS Mgt Station Download URL:
The current OpenVMS Management Station software can be found via links at this web page. This URL should be considered subject to change without notice. The best approach is to start from the main OpenVMS web site and navigate to the items you need to explore. However, as of the date this presentation was prepared, the survey page for OpenVMS Management Station was not working, or was not working reliably with certain non-Microsoft browsers. The only way to access the OpenVMS Management Station software download reliably was to go directly to the download page by entering the target URL manually from the keyboard.

Accessibility Manager for
Seminar 1024 Accessibility Manager for Distributed Systems (AMDS) and Availability Manager

AMDS Provides DECwindows interface for
system or cluster management, some performance monitoring. Warnings can be issued when performance metrics go out of spec. - you determine the thresholds for your environment. Can (maybe) be used to “un-hang” a cluster (force quorum adjustment). Here we’ll take a look at the AMDS and Availability Manager offerings. AMDS is the predecessor to Availability Manager. AMDS is still found useful by many sites that prefer it over Availability Manager. This discussion will focus on AMDS as most of the operations provided by AMDS are also found on Availability Manager with some minor variations. In general, the functionality of AMDS and Availability Manager is very similar. AMDS is useful as a more comprehensive method of monitoring system activity including CPU utilization, CPU modes, I/O activity, paging, swapping, and so on. It runs on DECwindows and provides visual cues using color to indicate when metrics have gone out of pre-specified bounds. An especially useful feature of AMDS is that when run on a separate OpenVMS workstation, it can communicate with server processes on cluster nodes that may otherwise appear hung due to cluster quorum issues. AMDS can be used to tell the cluster nodes to recalculate and adjust quorum, a feature not available by other means.

AMDS Considerations: Uses a proprietary, non-routable network protocol. For optimum availability management, needs to run on a separate OpenVMS workstation (not a cluster member). AMDS workstation must be on same LAN segment as cluster nodes or protocol must be bridged bt segments. AMDS and Availability Manager both use a proprietary, non-routable protocol to communicate between the workstation and the systems being managed. The protocol is similar, but not identical, to that used for OpenVMS intra-cluster communications (SCS). Because the OpenVMS system manager may need to use AMDS to try to unhang a hung cluster, it is most advantageous to use a separate OpenVMS workstation for AMDS. The AMDS workstation should NOT participate in the cluster, but simply be able to listen in on communications going on within the cluster and communicate with nodes in the cluster(s) being monitored. If the cluster becomes hung due to having lost quorum, AMDS can still be used to signal the cluster nodes that they should adjust quorum based on the votes currently remaining. In order to facilitate this, the AMDS workstation needs to be connected to the same LAN segment as the cluster nodes being monitored, or on a segment which is bridged to that segment.

AMDS Considerations: AMDS workstation can be accessed remotely (X on Linux, Solaris or *BSD; Reflection/X or Exceed, etc. on MS Win; DECwindows on OpenVMS). Because AMDS is DECwindows application, it can be run remotely using a workstation other than the AMDS workstation, so long as the AMDS workstation “sees” the remote workstation as reachable via the TCP/IP network. X on Linux, FreeBSD, NetBSD, OpenBSD, Solaris, Tru64, etc. can be used as remote workstations for AMDS. Likewise, Reflection/X, Exceed, eXcursion and others can be used on MS Windows to provide a remote workstation for running AMDS on the AMDS workstation.

AMDS Licensing: AMDS license is now included in the OpenVMS base license (as of AMDS V7.1). Software Kit: On the OpenVMS binary CD. On the OpenVMS website. AMDS is licensed with the base operating system as of V7.1. Prior to that, it required the VMScluster license. The distribution kit for AMDS is found on the OpenVMS binary CDROM. Normally, it is also available on the OpenVMS website. The kit is not available on the web as of this writing (early October, 2002).

AMDS Startup Procedure: $ @SYS$STARTUP:AMDS$STARTUP
Specify START as the first parameter. The AMDS logical names need to be DEFINEd and server process needs to be started. Both of these can be done at system startup time using the procedure shown in the slide. AMDS$STARTUP is found in the SYS$STARTUP path. Specify START as the first parameter.

AMDS Logical Names: Defined in AMDS$SYSTEM:AMDS$LOGICALS.COM
AMDS$GROUP_NAME is the node information display group, default is DECAMDS Define a group name for each cluster AMDS$DEVICE defines the network device to use if multiple LAN connections are present. The AMDS$SYSTEM:AMDS$LOGICALS.COM procedure can be edited to add two logical names that will modify the behavior of AMDS. The AMDS$GROUP_NAME logical name specifies the name of the AMDS display group. The default is DECAMDS. A unique name should be used for all nodes in a cluster. AMDS$DEVICE specifies which network device AMDS should use if multiple LAN adapters are present.

Availability Mgr Availability Manager An MS Windows tool (W/NT, W2K)
Does not require an X-server on the PC. Uses the same non-routable protocol as AMDS - similar restrictions. Could be accessed remotely using PCAnywhere, or maybe Citrix. Availability Manager is an MS Windows application and runs on Windows/NT and Windows/2000. Being a Windows application, it does not require an X-server and it runs directly on the PC. Availability Manager uses the same non-routable protocol as AMDS. Thus, the PC where Availability Manager is run must meet the same conditions as an AMDS workstation: it must be on the same LAN segment as the nodes being managed or it must on a LAN segment that is bridged to that segment. The Availability Manager PC could be accessed remotely using PCAnywhere, or perhaps even Citrix.

AMDS AMDS Screen shots follow.
Many display objects can be selected to “drill down” for more information. Following are screen shots for AMDS. Many of the display objects can be selected to “drill down” for more detail. Screen shots for Availability Manager were not available when this presentation was prepared.

AMDS The system overview display shows a general performance summary similar to MONITOR CLUSTER. More than one cluster can be displayed. The items that are colored red or green indicate that specific metric is outside of the pre-specified limits. You can set the thresholds that determine the specified limits to suit the need of your site.

AMDS Here is a sample of the Event Log display An entry is made here whenever a metric exceeds a pre-specified limit.

AMDS The Node Summary display is very similar to the MONITOR SYSTEM display, but provides more detail. Again, metrics are displayed in color to indicate whether they are in spec. or out of spec. You specify the limits for your site.

AMDS The process I/O summary is similar to MONITOR process, but includes process quota information along side the actual I/O activity. This can be helpful in determining which process quota is being exhausted if a process experiences a “Quota exceeded” message.

AMDS The process detail display provides an in-depth look at what a process is doing. Working set utilization is displayed along with I/O execution rates and the associated process quotas, processor states and the various resource quotas for the process, and at the bottom of the window is shown the filespec of the currently executing image, just like the SHOW PROCESS/CONTINUOUS display on a VT.

AMDS Another useful feature of AMDS is the ability to force a process to exit the image it is running or to delete a process. Forcing the image to exit will allow its rundown processing to execute, unlike simply deleting the process (asking the process to delete itself, really) which can leave buffers unflushed resulting in data loss or corruption.

AMDS In the previous slides, a Fix option is visible on the menu bar.
Here is where we can access the much sought after Quorum Adjustment option. For the currently selected cluster, a request to adjust quorum based on the existing votes can eb made via AMDS. In some cases, this can “free” a “hung” cluster if the hang is due to having lost quorum (too many nodes crashed or were shutdown at once). Also shown is an option to crash a node. Obviously, you won’t want to leave this display running on an unattended workstation.

Seminar 1024 OpenVMS Security Elements

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

Points to remember: TELNET and FTP sessions are not encrypted, passwords are sent as clear text. Use Secure Shell and Secure FTP for best security. LAT and DECnet are not encrypted, passwords are sent as clear text. Many forms of network access result in passwords being sent as clear text. Among them are TELNET and FTP, to name only two. For the best security, use Secure Shell and Secure FTP to help keep password secure. LAT and CTERM (DECnet SET HOST) do not provide for encryption. User names and passwords are sent as clear text.

User Identification Codes [group,user] Similar to UN*X UIDs, except digits are always octal. Users belong to only one UIC group. Use Rights Identifiers to grant additional access. The first key element of OpenVMS security is the User Identification Code or UIC. The protection masks assigned to object such as files, devices, in-memory objects, etc. are all driven by the UIC. Numeric UICs have only digits in the group and user (member) fields. Where UIC identifiers exist, UICs are sometimes displayed as Alphanumeric expressions such as [SYSTEM,SYSADMIN]. UICs are similar, but not identical, to UN*X UIDs. Users belong to only one UIC group. If additional associations are required, rights identifiers can be created and GRANTed to users as needed.

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

Levels 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 to the file’s parent directory).

Levels of Permission in each class: 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 each class of user, there are four levels of permission. For Directories: Read access grants permission to list the contents of the directory. Write Access grants permission to create or delete files in the directory. Execute access grants permission to look up files in the directory. Delete access grants permission to delete the directory (requires Write access to the parent directory).

Levels of Permission in each class: Devices READ WRITE LOGICAL I/O PHYSICAL I/O For each class of user, there are four levels of permission. For devices: Read access grants permission to open a device read-only. No other permission is granted. For devices, Write access grants permission to open a device write-only. No other permission is granted. For devices, Logical I/O access grants permission to perform Logical I/O to a device. No other permission is granted. For devices, Physical I/O access grants permission to perform Physical I/O to a device. No other permission is granted.

Levels of Permission in each class: Queues READ - Display queue, jobs MODIFY - Modify queue, jobs SUBMIT - SUBMIT/PRINT jobs DELETE - Delete jobs or the queue For each class of user, there are four levels of permission. For Queues: Read access grants permission to display characteristics of the queue or a jobs in the queue. Modify access grants permission to modify characteristics of the queue or a jobs in the queue. Submit access grants permission to submit jobs to the queue (SUBMIT or PRINT). Delete access grants permission to delete jobs in the queue or the queue itself.

Access Control Lists Specify access control beyond the UIC based protections. Consist of access control entries. Access Control Lists (ACLs) are used to specify access permissions beyond what the UIC based protect mask allows for. ACLs consist of Access Control Entries (ACEs). The OpenVMS Guide To System Security describes access control in detail. The documentation is available on-line at this URL:

Access Control Entries Associate access control with UICs or Rights Identifiers Levels of access: READ DELETE WRITE CONTROL EXECUTE Object owner always has CONTROL Access Control Entries (ACEs) associate access permissions with UICs or Rights Identifiers ACEs can specify levels of access permission or permission to modify the object’s security profile (Control access). The owner of an object always has Control access.

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

Propagating ACEs, Default Protections Set an ACE on a directory with the DEFAULT attribute. Default Protection ACE is set on a directory. Will be applied to new files, or use SET SECURITY/DEFAULT to propagate to existing files. Access Control Entries (ACEs) and default protection masks can be propagated onto existing files in a directory tree. On the root directory of a tree: Set an ACE with the DEFAULT attribute. Set a Default Protection ACE. These will be applied to new file created in the root directory. To propagate these ACEs onto all the files in the tree, use the SET SECURITY/DEFAULT command with a wildcarded path. Example: $ SET SECURITY/DEFAULT ddcu:[root_level_directory…]*.*;*

Set ACEs in the proper sequence First matching ACE determines access. Enter ACEs from least restrictive to most restrictive. EDIT/ACL can be helpful. ACL takes priority over UIC based protection mask. The key to successful use of ACLs is to set ACEs in the proper sequence. When the system is determining access permission, only the first matching ACE is used. ACEs should be entered into the ACL starting with the least restrictive to the most restrictive. The ACL Editor (EDIT/ACL) can be helpful for objects that have large ACLs. Note that the ACL takes priority over the UIC-based protection mask. If the UIC-based protection grants access but the ACL doesn’t, access to the object will be denied.

Seminar 1024 Closing Comments, Q & A

Freeware Sources The OpenVMS Freeware CDs are online at the OpenVMS website. The DFWCUG DECUS CD-ROM Archive: ftp://ftp.montagar.com/decus/ DFWCUG OVMS Freeware V3 Archive: ftp://ftp.montagar.com/freeware-v3/ DJE Systems OpenVMS Freeware archive: OpenVMS FAQ Here is a brief list of sites where OpenVMS freeware (or links to it) can be found. The contents of the OpenVMS Freeware CDs V4 and V5 can be found on line at the OpenVMS website. The Dallas / Fort Worth LUG maintains an extensive archive of free software and DECUS CDs. Links to other freeware sites can be found in the OpenVMS Frequently Asked Questions (FAQ) which can be found at the URL shown. DJE Systems also has some selected items available for download. Not all of them are listed on our freeware page; however, they can be downloaded by going to the URL shown above. Look for the following files associated with this seminar at the URL shown above: seminar_1024.zip Additional DCL tools from DJE Systems seminar_1024_2002.zip Arthur Cochrane’s original files and PowerPoint slides This presentation can be found on-line shortly after the symposium at this URL:

Seminar 1024 Thanks for coming!
Disclaimer: All information is correct to the best of the author’s knowledge. Please fill out the evaluation forms, if available.

OpenVMS System Management Techniques, Tools, and Tricks

Similar presentations

Presentation on theme: "OpenVMS System Management Techniques, Tools, and Tricks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

OpenVMS System Management Techniques, Tools, and Tricks

Similar presentations

Presentation on theme: "OpenVMS System Management Techniques, Tools, and Tricks"— Presentation transcript:

Similar presentations

About project

Feedback