To set the time on an AlphaServer ES47, AlphaServer ES80 or AlphaServer GS1280 series system, you must access the platform management utility. In particular, this is how OpenVMS obtains its system time on these systems.

MBM - (PMU, Platform Management Utility) From SRM P00> enter {Esc} {Esc} MBM CTRL/[ CTRL/[ MBM (MBM must be uppercase) MBM> connect (to exit to SRM)

The serial PMU is a command line interface for a serial communication (MBM) port or to the telnet session. Commands entered on this line are forwarded to the PMU server, and the serial PMU is responsible for the following tasks:

• Show the system configuration and provide the basic debugging capability
• Initiate the firmware update or load the test firmware version
• Power on or off, halt, or reset the system or partition
• The system partitioning and cabling functions
• Displays of the health of hardware environment, including such constructs as fans, power supplies and environmental and temperature values.
• Remote server management tasks
• The connection to the virtual SRM console

Use an escape key sequence to enter the PMU. You can access the PMU through a modem or from a terminal emulator connected to the server management LAN.

4.6 UTC vs GMT vs vs UT1/UT1/UT2 TDF? What are these acronyms?

The results of an international compromise---though some would say an international attempt to increase confusion---UTC is refered to as "Coordinated Universal Time" (though not as CUT) in English and as "Temps Universel Coordinné" (though not as TUC) in French. (No particular information exists to explain why UTC was chosen over the equally nonsensical TCU, according to Ulysses T. Clockmeister, one of the diplomats that helped establish the international compromise.)

Universal Time UT0 is solar time, UT1 is solar time corrected for a wobble in the Earth's orbit, and UT2 is UT1 corrected for seasonal rotational variations in rotation due to the Earth's solar orbit.

GMT---Greenwich Mean Time---is UT1. GMT is the time at the classic site of the since-disbanded Royal Greenwich Observatory; at the most widely-known tourist attraction of Greenwich, England.

UTC is based on an average across multiple atomic clocks, and is kept within 0.9 seconds of GMT, through the insertion (or removal) of seconds. In other words, UTC matches GMT plus or minus up to 0.9 seconds, but UTC is not GMT.

TDF is the Timezone Differential Factor, the interval of time between the local time and UTC. Areas that celebrate daylight savings time (DST) will see periodic changes to the TDF value, when the switch-over between daylight savings time and standard time occurs. The switch-over itself is entirely left to local governmental folks, and can and has varied by political entity and politics, and the switch-over has varied over the years even at the same location.

If your local OpenVMS system time is off by one hour (or whatever the local DST change) for some or all applications, you probably need to reset your local TDF. (For related details, please see sections Section 4.3 and Section 10.22.1.)

Further discussions of history and politics, the Royal Observers' outbuildings, and the compromise that left the English with the Time Standard (the Prime Meridian) and the French with the standards for Distance and Weight (the Metric System) are left to other sources. Some of these other sources include the following URLs:

• ftp://elsie.nci.nih.gov/pub/
• http://physics.nist.gov/GenInt/Time/time.html
• http://nist.time.gov/

The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here.

The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function.

The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.)

It's important to note that there is no such thing as "installing a shareable image with privileges". The INSTALL utility will let you do it, but the privileges you specify will be ignored. To have a callable routine run with enhanced privileges that are not available to its caller, you must construct your routines as "user-written system services" and install the shareable image with the /PROTECT qualifier. See the OpenVMS Programming Concepts Manual for more information on user-written system services. Note also that in many cases the need to grant privileges to an image can be replaced with the use of the "Protected Subsystems" feature that grants a rights identifier to an image. See the OpenVMS Guide to System Security for information on Protected Subsystems.

5.2 Are there any known viruses for OpenVMS?

Viruses and worms are common on personal computers because the operating systems involved, such as the Microsoft MS-DOS, Windows 95, Windows 98 and Windows ME variants, do not particularly protect the operating system or the file system against hostile action by programs. Microsoft Windows NT, Windows 2000 and Windows XP do implement protections for specific configurations and do implement memory protection models, but many users of these systems choose to operate with full adminstrator access and thus the available protections are entirely defeated and entirely not relevent, and any program that can activate itself or can cause the user to activate the code can subvert the operating system and take over the hardware, at which point the malicious code can do most anything it wishes, including hiding copies of itself in other programs or in the file system, redistributing itself via mail, IM, or network connections, or can be used as a zombie in staging attacks on other systems.

This is less likely with multi-user systems such as OpenVMS, Unix, Linux, MVS and other platforms for various reasons. First, the operating system runs in a privileged mode in memory that is protected against modification by normal user programs. Any program cannot simply take over the hardware as it can on operating systems without security and particularly without memory page protections. Secondly, multi-user systems can be set up so that non-privileged programs cannot modify system programs and files on disk, and this is normal for most installations. Both of these protection schemes mean that traditional viral infections don't work on these OSes. Third, typical applications and configurations tend to prevent the uncontrolled execution of untrusted code as part of received mail messages or web access; one of the central vulnerabilities of the Microsoft Windows platform involves its intentionally easy ability to dynamically (and transparently) activate code and macros that are embedded within mail messages and within data files.

It is possible for OpenVMS and other multi-user systems to become infected by viruses or worms, but to do so, the program containing the virus must be run from a user account that has amplified privileges. So long as the system administrator is careful that only trusted applications are run from such accounts (and this is generally the case) and so long as there are no OpenVMS system security breaches (due to malicious operator activity, OpenVMS errors, or errors within trusted and privileged product packages) there is no of modifications to the operating system or other protected files from the virus or the worm.

The FAQ maintainer is aware of a few (and very old) DECnet worms that have affected OpenVMS systems on DECnet networks, but is aware of no OpenVMS viruses that are loose in the field.

To protect against viruses and other attempts at system interference or misuse, please follow the security recommendations in the OpenVMS Guide to System Security. Additionally, you will want to keep your OpenVMS ECOs current and you will want to apply all mandatory ECO kits and any security MUPs for OpenVMS and OpenVMS products, and you will want to keep to OpenVMS releases with Prior Version Support (PVS) or with Current Version Support. (This is obviously a general system maintenance recommendation, in addition to being a good system security recommendation---new security features and capabilities are implemented in more recent OpenVMS releases, for instance.) You may also want to consider optional software products which can monitor your system for intrusion or infection attempts. Computer Associates (CA) offers various products in this area, as to other vendors.

Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com). MD5 tools are also available.

Tools to scan OpenVMS file systems for Microsoft Windows infections are also available, including a commercial package from Sophos. These scanning tools are particularly useful for systems running Samba or Advanced Server (PATHWORKS), as these servers tend to have a higher population of files intended for Microsoft Windows systems users, and as common virus and worm attacks can find and infect files on the file shares that these products can provide. These infections do not target OpenVMS itself, though the OpenVMS server (and any other platform and any other server capable of storing files for Windows systems) can silently host files containing common Microsoft Windows infections.

5.3 Sources of OpenVMS security information?

Where can I get information on OpenVMS system security?

• http://www.hp.com/go/openvms/doc
• http://www.blacksheepnetworks.com/security/resources/openvms/
• http://www.vmsone.com/~opcom/defcon9.htm

ISO-9660 support was added in the following releases:

• OpenVMS VAX V6.0
• OpenVMS AXP V1.5

An add-on ISO-9660 kit was also available for OpenVMS VAX V5.5, V5.5-1, V5.5-2, and V5.5-2H4. This requires the installation of the F11CD kit from the InfoServer CD, from the Consolidated Distribution CD under the InfoServer area, Customer Support Center kit CSCPAT #1071012, or the F11CD ECO kit. (Upgrades to V6 and later are strongly recommended.)

By default, OpenVMS senses the specific type of media. If you are working with dual-format media---media that uses both the ODS-2 and ISO-9660 formats on the same CD-ROM---then MOUNT will first detect and then default to the ODS-2 format. If you wish to override this and explicitly mount the media using ISO-9660, use the command:

$ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label]

In most circumstances, you will not need nor will you want to include an explicit /MEDIA_FORMAT specification. For further information, please refer to the OpenVMS MOUNT Utility Manual. Particularly note the information on the MOUNT /MEDIA_FORMAT and /UNDEFINED_FAT qualifiers.

The MOUNT /UNDEFINED_FAT qualifier is of interest because ISO-9660 media can be mastered on a wide variety of operating system platforms, and these platforms do not necessarily support the semantics needed for files containing predefined record formats. The /UNDEFINED_FAT allows you to specify the default attributes for files accessed from volumes using the ISO-9660 format.

An example which works for most CD-ROMs is:

$ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE

This particular MOUNT command forces access to the CD-ROM media using the ISO-9660 volume structure, and the use of the MOUNT /UNDEFINED_FAT qualifier causes any file whose file attributes are "undefined" to be returned with "stream" attributes with a maximum record length 2048.

On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS.

For details on ODS-1 and ODS-2 file specifications, see Kirby McCoy's VMS File System Internals Manual (published by Digital Press, but potentially out of print), and see:

• http://pdp-11.trailing-edge.com/www/ods1.txt
• Look for the Freeware V5.0 directory ODS2 at http://www.hp.com/go/openvms/freeware/

A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits.

If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command:

$ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCE

A PCSI kit file has a file specification of the following form:

DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI

In this example, "FORTRAN" is the "prodname". PCSI will expand the kit files into the directory you specify and subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the eventual destination of files found there. Most of the actual product files (images, etc.) will be in the subdirectories. In the top-level directory will be a file with the file type PCSI$DESCRIPTION that specifies where various files should go. For more details, see the POLYCENTER Software Installation Developer's Guide for OpenVMS, which can be found in the OpenVMS documentation on the Consolidated Online Documentation CD-ROM.

5.6 Emergency (Conversational) System Startup?

If you need to perform system management operations on an OpenVMS system and cannot access the system through normal means---the password on the SYSTEM username was forgetten and no other privileged usernames are available, or one or more core system product authorization key (PAK) software licenses are unavailable or expired---then you must perform a conversational (emergency) bootstrap.

Here are the steps:

1. Halt the system. Exactly how this is done depends on the specific system model: Depending on the model, this can involve pressing the [HALT] button, entering [CTRL/P] on the console, or pressing the [BREAK] key on the console.
2. At the console prompt, use a console command to boot into the SYSBOOT utility. (SYSBOOT allows conversational changes to system parameters.) (The console syntax for the conversational bootstrap varies by system model and by system architecture---this typically involves specifying a flag with the lowest bit set. See Section 14.3.5 for related details.) For example:
   On VAX, use one of the following three commands depending on the particular model of VAX system involved:

   B/R5:1 B/1 @GENBOO

   
   On Alpha:

   b -flags 0,1

   
   If your system has a non-zero system root (such as root SYSE, shown here), you will have to use a console command such as the following:
   On VAX:

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

   
   On Alpha:

   b -flags e,1

   
   On IA-64, you can establish a boot alias for a conversational bootstrap, as discussed in Section 14.3.5.1.
   If your system has a hardware password (various systems support a password that prevents unauthorized access to the console), you will need to know theis password and will need to enter it using the LOGIN command at the console. If you get an "Inv Cmd" error trying to perform a conversational bootstrap, and you do not have the hardware console password for the console LOGIN command, you are stuck---you will need to call for hardware service in order to reset the hardware console password. The syntax used for the console password mechanism varies.

3. Once at the SYSBOOT prompt, request that OpenVMS read the system startup commands directly from the system console, that the window system (if any) not be started, and that OpenVMS not record these particular parameter changes for subsequent system reboots:

   SET/STARTUP OPA0: SET WINDOW_SYSTEM 0 SET WRITESYSPARAMS 0 CONTINUE

4. At the $ prompt, the system will now be accepting startup commands directly from the console. Type the following two DCL commands:

   $ SPAWN $ @SYS$SYSTEM:STARTUP

5. You should now see the dollar ($) prompt of DCL.
   The result of these two commands will be the normal system startup, but you will be left logged in on the console, running under a fully privileged username. Without the use of the SPAWN command, you would be logged out when the startup completes.
   Perform the task(s) required, such as resetting the password on the SYSTEM username as described in Section 5.6.1 or registering one or more license product authorization keys (PAKs) as described in Section 5.6.2.
6. Once you log out of this session, the system will complete the startup and can be used normally. You can choose to reboot the system, but that is not necessary.

Some system managers will suggest a method using the UAFALTERNATE system parameter rather than the SET/STARTUP OPA0: command shown. This approach is not always available and is accordingly less commonly recommended, as there can easily be an alternate user authorization database (SYS$SYSTEM:SYSUAFALT.DAT) configured on the system. With a system manager that has configured an alternate SYSUAFALT.DAT file, the UAFALTERNATE method will fail---well, assuming you do not know the password of a privileged username stored within SYSUAFALT.DAT, of course.

The UAFALTERNATE system parameter is used to trigger what is sometimes known as the console backdoor. The OPA0: system console is critical to system operations and system security, and will allow access when the SYSUAF system authorization database is unavailable or corrupted, when core product license PAKs are not registered, expired or disabled (NOLICENSE errors), or in various other cases of system failures. All this is in addition to the role of the console in the display of certain system-critical event messages. Access to the OPA0: console has a security exposure that is equivalent to direct access to the system hardware.

When LOGINOUT detects an error (such as a SYSUAF corruption, by a missing SYSUAF, missing product licenses, or other trigger), it will prevent access to the OpenVMS system from all terminals except the system console. The OPA0: system console will be allowed access, and the resulting process will be fully privileged. Resetting the UAFALTERNATE system parameter---in the absence of an alternate SYSUAF system authorization database---will cause the console backdoor to be opened simply because LOGINOUT cannot locate SYS$SYSTEM:SYSUAFALT.DAT. When the authorization database cannot be located, access will be granted from the console only.

For further information on emergency startup and shutdown, as well as for the official OpenVMS documentation on how to change the SYSTEM password from the console in an emergency, please see the OpenVMS System Manager's Manual in the OpenVMS documentation set.

For information and recommendations on setting up OpenVMS system security, please see the NCSC Class C2 appendix of the Guide to OpenVMS System Security manual, also in the OpenVMS documentation set.

You can also use the conversational bootstrap technique shown earlier (the steps until SET/STARTUP) to alter various system parameters, as well. At the SYSBOOT prompt, you can enter new parameters values:

SHOW MAXPROCESSCNT SET . 64 CONTINUE

The "." is a shorthand notation used for the last parameter examined within SYSGEN and SYSBOOT.