Documentation __________________________________________________________ 3.11 Where can I find the latest C run-time library manuals? The C run-time library (RTL) reference documentation has been moved from the C language documentation set to the OpenVMS documentation set. For the most recent version of the C RTL documentation and the OpenVMS standard C library, please see the OpenVMS manuals. In addition to the user-mode C RTL, there is a second kernel-mode RTL accessable to drivers on OpenVMS Alpha and OpenVMS I64. For details on this second library and on the duplicate symbol errors that can be triggered when this library is referenced during an incorrectly- specified LINK command, please see Section 10.22.1. For general information on this kernel RTL, see the Digital Press book Writing OpenVMS Device Drivers in C. For details, please see the associated OpenVMS source listings distribution. o http://www.hp.com/go/openvms/doc/ 3-13 _______________________________________________________ 4 Time and Timekeeping This chapter discusses time, timekeeping, system time synchronization, clock skew and clock drift, implications of using SUBMIT/AFTER=TOMORROW, and other time-related topics. __________________________________________________________ 4.1 A brief history of OpenVMS Timekeeping, please? Why does OpenVMS regards November 17, 1858 as the beginning of time... The modified Julian date adopted by the Smithsonian Astrophysical Observatory (SAO) for satellite tracking is Julian Day 2400000.5, which turns out to be midnight on November 17, 1858. SAO started tracking satellites with an 8K (nonvirtual) 36-bit IBM 704 in 1957 when Sputnik went into orbit. The Julian day was 2435839 on January 1, 1957. This is 11225377 octal, which was too big to fit into an 18-bit field. With only 8K of memory, the 14 bits left over by keeping the Julian date in its own 36-bit word would have been wasted. SAO also needed the fraction of the current day (for which 18 bits gave enough accuracy), so it was decided to keep the number of days in the left 18 bits and the fraction of a day in the right 18 bits of one word. Eighteen bits allows the truncated Julian Day (the SAO day) to grow as large as 262143, which from November 17, 1858, allowed for 7 centuries. Possibly, the date could only grow as large as 131071 (using 17 bits), but this still covers 3 centuries and leaves the possibility of representing negative time. The 1858 date preceded the oldest star catalogue in use at SAO, which also avoided having to use negative time in any of the satellite tracking calculations. 4-1 Time and Timekeeping The original Julian Day (JD) is used by astronomers and expressed in days since noon January 1, 4713 B.C. This measure of time was introduced by Joseph Scaliger in the 16th century. It is named in honor of his father, Julius Caesar Scaliger (note that this Julian Day is different from the Julian calendar that is named for the Roman Emperor Julius Caesar!). Why 4713 BC? Scaliger traced three time cycles and found that they were all in the first year of their cyle in 4713 B.C. The three cycles are 15, 19, and 28 years long. By multiplying these three numbers (15 * 19 * 28 = 7980), he was able to represent any date from 4713 B.C. through 3267 A.D. The starting year was before any historical event known to him. In fact, the Jewish calendar marks the start of the world as 3761 B.C. Today his numbering scheme is still used by astronomers to avoid the difficulties of converting the months of different calendars in use during different eras. The following web sites: o http://www.openvms.compaq.com/openvms/products/year- 2000/leap.html o http://www.eecis.udel.edu/~ntp/ o http://www.nist.gov/ o http://www.boulder.nist.gov/timefreq/ o http://www.tondering.dk/claus/calendar.html o http://es.rice.edu/ES/humsoc/Galileo/Things/gregorian_ calendar.html are all good time-related resources, some general and some specific to OpenVMS. _____________________________ 4.1.1 Details of the OpenVMS system time-keeping? 4-2 Time and Timekeeping _____________________________ 4.1.1.1__VAX_hardware_time-keeping details... 4.1.1.1.1 TOY clock This is battery backed up hardware timing circuitry used to keep the correct time of year during rebooting, power failures, and system shutdown. This clock only keeps track of months, days, and time. The time is kept relative to January 1st, at 00:00:00.00 of the year the _________clock_was_initiailized. 4.1.1.1.2 EXE$GQ_SYSTIME This is the OpenVMS VAX system time cell. This cell contains the number of 100ns intervals since a known reference. This cell is incremented by 100000 every _________10ms_by_an_hardware_interval timer. 4.1.1.1.3 EXE$GQ_TODCBASE This cell contains the time and date the system time was last adjusted by EXE$SETTIME. It uses the same format as EXE$GQ_SYSTIME. On adjustment of the system time a copy of EXE$GQ_SYSTIME is stored in this cell in both memory and on disk. This cell is used to get the _________year_for_the_system_time. 4.1.1.1.4 EXE$GL_TODR This cell contains the time and date the system time was last adjusted by EXE$SETTIME. It uses the same format as the time of year clock. On adjustment of the system time this cell gets saved back to both memory and disk. The contents of this cell are used to test the validity of the TOY clock. The system parameters SETTIME and TIMEPROMPTWAIT determine how the system time will be set. o IF SETTIME = 0 and the TOY clock is valid THEN the contents of the TOY clock are compared to those of EXE$GL_TODR. IF the TOY clock is more than a day behind EXE$GL_TODR THEN the TOY clock is presumed invalid. o IF the TOY clock is within a day of EXE$GL_TODR THEN the system time is calculated as follows: 4-3 Time and Timekeeping o EXE$GQ_SYSTIME = EXE$GQ_TODCBASE + ((TOY_CLOCK - EXE$GL_TODR) * 100000) o IF SETTIME = 1 or the TOY clock is invalid THEN the value of TIMEPROMPTWAIT determines how to reset the time of year. IF TIMEPROMPTWAIT > 0 THEN the user is prompted for the time and date, for a length of time equal to TIMEPROMPTWAIT microfortnights. o IF TIMEPROMPTWAIT = 0 THEN the time of year is the value of EXE$GL_TODR + 10ms. o IF TIMEPROMPTWAIT < 0 to proceed until they do so. o THEN the user is prompted for the time and date and unable When booting a CD-ROM containing an OpenVMS VAX system, the system will typically be deliberately configured prompt the user to input the time - this is necessary in order to boot with the correct time. If either TIMEPROMPTWAIT or SETTIME are set to zero, OpenVMS VAX will use the TOY clock to get the time of year, and the year will be fetched from the distribution medium. The value of the year on the distribution medium (saved within the SYS.EXE image) will most likely be that of when the kit was mastered, and cannot be changed. Unless the current year happens to be the same year as that on the distribution, most likely the year will be incorrect. (Further, with the calculation of Leap Year also being dependent on the current year, there is a possibility that the date could be incorrect, as well.) _____________________________ 4.1.1.2 Alpha hardware time-keeping details... 4-4 Time and Timekeeping _____________________________ 4.1.1.2.1 Battery-Backed Watch (BB_WATCH) Chip This is battery backed up hardware timing circuitry used to keep the correct time of year during rebooting, power failures, and system shutdown. This clock keeps track of date and time in 24 hour binary format. The BB_WATCH time is used to initialize the running system time during bootstrap, and the BB_WATCH time is read when the SET TIME command is issued with no parameters; when the running system time is reset to the value stored in the BB_WATCH. The running system time is written into the BB_WATCH when the SET TIME command is issued with a parameter. _____________________________ 4.1.1.2.2 EXE$GQ_SYSTIME This is the OpenVMS Alpha system time cell. This cell contains the number of 100ns intervals since November 17, 1858 00:00:00.00. This cell is incremented by _________100000_every_10ms_by an hardware interval timer. 4.1.1.2.3 EXE$GQ_SAVED_HWCLOCK This cell is used by OpenVMS Alpha to keep track of the last time and date that EXE$GQ_SYSTIME was adjusted. It keeps the same time format as EXE$GQ_SYSTIME. The value in this cell gets updated in memory and on disk, every time EXE$GQ_SYSTIME gets adjusted. o The system parameters SETTIME and TIMEPROMPTWAIT determine how the system time will be set. o If SETTIME = 0 then EXE$INIT_HWCLOCK reads the hardware clock to set the system time. o IF TIMEPROMPTWAIT > 0 THEN the value of TIMEPROMPTWAIT determines how long the user is prompted to enter the time and date. If time expires and no time has been entered the system acts as if TIMEPROMPTWAIT = 0. o IF TIMEPROMPTWAIT = 0 THEN the system time is calculated from the contents of EXE$GQ_SAVED_HWCLOCK + 1. 4-5 Time and Timekeeping o IF TIMEPROMPTWAIT < 0 THEN the user is prompted for the time and date and unable to continue until the information is entered. Unlike the VAX, the Alpha hardware clock tracks the full date and time, not just the time of year. This means it is possible to boot from the CD-ROM media without entering the time at the CD-ROM bootstrap. (This provided that the time and date have been initialized, of course.) IA-64 (Itanium) hardware time-keeping details to be added... _____________________________ 4.1.1.3 Why does VAX need a SET TIME at least once a year? Because the VAX Time Of Year (TOY) has a resolution of 497 days, the VAX system time is stored using both the TOY and the OpenVMS VAX system image SYS.EXE. Because of the use of the combination of the TOY and SYS.EXE, you need to issue a SET TIME command (with the time parameter specified) at least once between January 1st and about April 11th of each year, and whenever you change system images (due to booting another OpenVMS VAX system, booting the standalone BACKUP image, an ECO that replaces SYS.EXE, etc). The SET TIME command (with the current time as a parameter) is automatically issued during various standard OpenVMS procedures such as SHUTDOWN, and it can also obviously be issued directly by a suitably privileged user. Issuing the SET TIME command (with a parameter) resets the value stored in the TOY, and (if necessary) also updates the portion of the time (the current year) saved in the SYS.EXE system image. This VAX TOY limit is the reason why OpenVMS VAX installation kits and standalone BACKUP explicitly prompt for the time during bootstrap, and why the time value can "get weird" if the system crashes outside the 497 day window (if no SET TIME was issued to update the saved values), and why the time value can "get weird" 4-6 Time and Timekeeping if a different SYS$SYSTEM:SYS.EXE is used (alternate system disk, standalone BACKUP, etc). _____________________________ 4.1.2 How does OpenVMS VAX maintain system time? VAX systems maintain an interval clock, and a hardware clock. The VAX hardware clock is called the TOY ("Time Of Year") clock. The register associated with the clock is called the TODR ("Time Of Day Register"). The TOY clock-as used-stores time relative to January first of the current year, starting at at 00:00:00.00. It is a 100 Hz, 32-bit counter, incremented every 10ms, and thus has a capacity of circa 497 days. OpenVMS (on the VAX platform) stores system date information-and in particular, the current year-in the system image, SYS$SYSTEM:SYS.EXE. The TOY is used, in conjunction with the base date that is stored and retrieved from the system image, to initialize the interval clock value that is stored in EXE$GQ_SYSTIME. Once the interval clock is loaded into the running system as part of the system bootstrap, the system does not typically reference the TOY again, unless a SET TIME (with no parameters) is issued. The interval clock value is updated by a periodic IPL22 or IPL24 (depending on the specific implementation) interrupt. (When these interrupts are blocked as a result of the activity of higher-IPL code-such as extensive driver interrupt activity or a hardware error or a correctable (soft) memory error-the clock will "loose" time, and the time value reported to the user with appear to have slowed down.) When SET TIME is issued with no parameters, the TOY clock is loaded into the system clock; the running system clock is set to the time stored in the TOY clock. This assumes the TOY clock is more accurate than the system clock, as is normally the case. 4-7 Time and Timekeeping On most (all?) VAX systems, the battery that is associated with the TOY clock can be disconnected and replaced if (when) it fails-TOY clock failures are quite commonly caused by a failed nickel-cadmium (NiCd) or lithium battery, or by a failed Dallas chip. __________________________________________________________ 4.2 Keeping the OpenVMS system time synchronized? To help keep more accurate system time or to keep your system clocks synchronized, TCP/IP Services NTP, DECnet-Plus DTSS (sometimes known as DECdtss), DCE DTS, and other techniques are commonly used. If you do not or cannot have IP access to one of the available time-base servers on the Internet, then you could use dial-up access to NIST or other authoritative site, or you can use a direct connection to a local authorative clock. There exists code around that processes the digital (ie: binary) format time that is available via a modem call into the NIST clock (the Automated Computer Telephone Service (ACTS) service), and code that grabs the time off a GPS receiver digital link, or a receiver (effectively a radio and a codec) that processes the time signals from radio stations WWV, WWVH, WWVB, or similar. Processing the serial or hardware time protocols often involves little more than reading from an EIA232 (RS232) serial line from the receiver, something that is possible from most any language. Information on correctly drifting the OpenVMS system clock to match the time-base time is available within the logic of at least one OpenVMS Freeware package. One example of acquring a time-base through local integrated hardware involves the IRIG time format (IRIG-A, -B, -G), a binary signal containing the current time in hours, minutes, seconds and days since the start of the current year. IRIG can also contain the time of day as the number of seconds since midnight. HP Custom Systems and third-party vendors have variously offered IRIG-based reader/generator modules for OpenVMS systems. 4-8 Time and Timekeeping One of the easiest approaches is a network-based GPS or other similar receiver. Basically, this is a network server box that provides an NTP server with the necessary hardware for external synchronization. In addition to the antenna and the receiver and processing components, these devices provide a network interface (NIC) and support for an NTP time server, and applications including the NTP support within TCP/IP Services and within various third-party IP stacks can then be used to synchronize with the the NTP information provided by time-base receivers. No other host software is required, and no host configuration steps and no host software beyond NTP are required. Differing time servers (DECnet-Plus DTSS, DCE DTS, NTP, etc) do not coexist particularly well, particularly if you try to use all these together on the same node. Please pick and use just one. (If needed, you can sometimes configure one package to acquire its timebase from another protocol, but one and only one time server package should have direct control over the management of and drifting of the local OpenVMS system time. In the specific case of DECnet-Plus DTSS, older product versions and versions V7.3 and later provide a provider module, a module which permits DTSS to acquire its time from NTP. For details on this, please see the comments in the module DTSS$NTP_PROVIDER.C.) Unlike DECnet-Plus, TCP/IP Services NTP is not capable of connecting to a time-base other than the network time base or the local system clock. Third-party and open source NTP implementations are available for OpenVMS, as well. Useful URLs: o http://www.boulder.nist.gov/timefreq/service/nts.htm o http://www.boulder.nist.gov/timefreq/service/acts.htm o http://www.boulder.nist.gov/timefreq/ o http://www.time.gov/ 4-9 Time and Timekeeping _____________________________ 4.2.1 Why do my cluster batch jobs start early? Your system time is skewed across your cluster members, and the cluster member performing the queue management tasks has a system time set later than the system time of the member running the batch job. This behaviour is most noticable when using SUBMIT/AFTER=TOMORROW and similar constructs, and use of /AFTER="TOMMOROW+00:01:00" or such is often recommended as a way to avoid this. The combination time value specified should be larger than the maximum expected time skew. In the example shown, the maximum cluster clock skew is assumed less than 1:00. You can also maintain your system times in better synchronization, with available tools described in Section 4.2 and elsewhere. _____________________________ 4.2.2 Why does my OpenVMS system time drift? Memory errors, hardware problems, or most anything operating at or above IPL 22 or IPL 24 (clock IPL is system family dependent; code executing at or above the clock IPL will block the processing of clock interrupts), can cause the loss of system time. Clock drift can also be caused by normal (thermal) clock variations and even by the expected level of clock drift. When clock interrupts are blocked as a result of the activity of high-IPL code-such as extensive driver interrupt activity or a hardware error or a correctable (soft) memory error-the clock will "loose" time, and the time value reported to the user with appear to have slowed down. Correctable memory errors can be a common cause of system time loss, in other words. Heavy PCI bus traffic can also cause lost time. One bug in this area involved the behaviour of certain graphics controllers including the ELSA GLoria Synergy PBXGK-BB; the PowerStorm 3D10T effectively stalling the PCI bus. See Section 5.16 for details on the ELSA GLoria Synergy controller, and make certain you have the current GRAPHICS ECO kit installed. 4-10 Time and Timekeeping Clock drift can also be (deliberately) caused by the activity of the DTSS or NTP packages. Also see Section 14.8, Section 14.15, and Section 4.2.4. _____________________________ 4.2.3 Resetting the system time into the past? You can resynchronize system time using DCL commands such as SET TIME and SET TIME/CLUSTER, but these commands can and obviously will cause the current system time to be set backwards when the specified time predates the current system time. This time-resetting operation can cause application problems, and can adversely effect applications using absolute timers, applications that assume time values will always be unique and ascending values, and applications. Setting the time backwards by values of even an hour has caused various run-time problems for applications and layered products. For this reason, this technique was not considered supported during the Year 2000 (Y2K) testing; a system or cluster reboot was strongly recommended as the correct means to avoid these problems. Application programmers are encouraged to use the time- related and TDF-related events that are available with the $set_system_event system service, and/or to use UTC or similar time, as these techniques can permit the application to better survive retrograde clock events. (There is an ECO to repair problems seen in the DECnet-Plus support for generating TDF events from DTSS, and this applies to V7.3 (expected to be in ECO4 and later) V7.3-1 (expected to be in ECO3 and later) and V7.3-2 (expected to be in ECO1 and later). Apply the most current DECnet-Plus ECO kits for these OpenVMS releases, for best TDF event support from DECnet-Plus.) See Section 4.2.4 and Section 4.2.1. 4-11 Time and Timekeeping _____________________________ 4.2.4 How can I drift the OpenVMS system time? With DECdts and TCP/IP Services NTP, the system time value is "drifted" (rather than changed), to avoid the obvious problems that would arise with "negative time changes". The same basic clock drifting technique is used by most (all?) time servers operating on OpenVMS, typically using the support for this provided directly within OpenVMS. An example of the technique used (on OpenVMS VAX) to drift the system time is the SETCLOCK tool on the OpenVMS Freeware. For information on the use of the EXE$GL_TIMEADJUST and EXE$GL_TICKLENGTH cells on OpenVMS Alpha, see OpenVMS AXP Internal and Data Structures, located on page 348. For those areas which switch between daylight savings time (DST) and standard time, the time value is not drifted. The time is adjusted by the entire interval. This procedure is inherent in the definition of the switch between DST and standard time. See Section 4.2.4 and Section 4.2.3. _____________________________ 4.2.5 How can I configure TCP/IP Services NTP as a time provider? An NTP time provider provides its idea of the current time to NTP clients via the NTP protocol. Most systems are NTP clients, but... NTP has a heirarchy of layers, called strata. The further away from the actual NTP time source (Internet time servers are at stratum 1), the lower the strata (and the larger the number assigned the statum). NTP explicity configured at stratum one provides time to NTP operating at lower strata, and the provided time is acquired based on the local system time or via some locally-accessible external time source. 4-12 Time and Timekeeping NTP at other (lower) strata both receive time from higher strata and can provide time to lower strata, and automatically adjust the local stratum. The highest stratum is one, and the lowest available stratum is fifteen. The TCP/IP Services NTP package can operate at any stratum, and can be configured as a peer, as a client, or as a broadcast server. NTP can also provide time to a DECnet-Plus DTSS network, see Section 4.2. With TCP/IP Services V5.0 and later, the only supported reference clock is the LCL (local system clock). If your system has an excellent clock or if the system time is being controlled by some other time service or peripheral (such as DTSS services, GPS services, a cesium clock, a GPIB controller or other similar time-related peripheral), you can configure NTP to use the system clock as its reference source. This will mimic the master-clock functionality, and will configre NTP as a stratum 1 time server. To do this, enter the following commands in TCPIP$NTP.CONF: server 127.127.1.0 prefer fudge 127.127.1.0 stratum 0 For local-master functionality, the commands are very similiar. Use: server 127.127.1.0 fudge 127.127.1.0 stratum 8 The difference between these two is the stratum, and the omission of the prefer keyword. Specifying a higher stratum allows the node to act as a backup NTP server, or potentially as the sole time server on an isolated network. The server will become active only when all other normal synchronization sources are unavailable. The use of "prefer" causes NTP to always use the specified clock as the time synchronization source. With the TCP/IP Services versions prior to V5.0, the NTP management is rather more primitive. To configure the local OpenVMS system from an NTP client to an NTP server (on TCP/IP Services versions 4-13 Time and Timekeeping prior to V5.0), add the following line to the sys$specific:[ucx$ntp]ucx$ntp.conf file: master-clock 1 Also, for TCP/IP Services prior to V5.0, see the NTP template file: SYS$SPECIFIC:[UCX$NTP]UCX$NTP.TEMPLATE Note that NTP does not provide for a Daylight Savings Time (DST) switch-over, that switch must arise from the timezone rules on the local system and/or from the SYS$EXAMPLES:DAYLIGHT_SAVINGS procedure. (Further, there is a known bug in SYS$EXAMPLES:DAYLIGHT_ SAVINGS.COM in V7.3, please obtain the available ECO kit.) For current TCP/IP Services and related OpenVMS documentation, please see: o http://www.hp.com/go/openvms/doc/ __________________________________________________________ 4.3 Managing Timezones, Timekeeping, UTC, and Daylight Savings? You will want to use the command procedure: o SYS$MANAGER:UTC$TIME_SETUP.COM to configure the OpenVMS Timezone Differential Factor (TDF) on OpenVMS V6.0 and later. Select the BOTH option. This configures the OpenVMS TDF settings, though it may or may not configure the TDF and the timezone rules needed or used by other software packages. Please do NOT directly invoke the following command procedures: o SYS$MANAGER:UTC$CONFIGURE_TDF.COM ! do not directly use o SYS$MANAGER:UTC$TIMEZONE_SETUP.COM ! do not directly use 4-14 Time and Timekeeping TCP/IP Services V5.0 and later use the OpenVMS TDF, UTC, and timezone support. Earlier versions use a TDF mechanism and timezone database that is internal to the TCP/IP Services package. Also on the earlier versions, the TDF must be manually configured within TCP/IP Services, in addition to the OpenVMS configuration of the TDF. DECnet-Plus in V7.3 and later uses the OpenVMS TDF, UTC, and timezone support, and displays its timezone prompts using UTC$TIME_SETUP.COM. Earlier versions use a TDF TDF mechanism, timezone database, and automatic switch-over that is internal to the DECnet-Plus package. Also on earlier versions, the TDF must be configured within the DECnet-Plus DECdtss package, in addition to the OpenVMS configuration of the TDF. Application code using HP C (formerly Compaq C, formerly DEC C) will use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS V7.0 and later (and when the macro _VMS_V6_SOURCE is NOT defined). HP C does NOT use the OpenVMS UTC and TDF mechanisms when the C code is compiled on OpenVMS releases prior to V7.0, or when the preprocessor declaration _VMS_V6_SOURCE is declared. DCE DTS TDF details TDB. In OpenVMS Alpha V6 releases (V6.1, V6.2, V6.2-1Hx, etc), the TDF value is written to SYS$BASE_IMAGE.EXE. With OpenVMS Alpha V7.0 and later and with OpenVMS VAX V6.0 and later, SYS$SYSTEM:SYS$TIMEZONE.DAT contains the TDF. This means that OpenVMS Alpha systems will need to have the TDF value reset manually-usually within SYSTARTUP_VMS.COM-on reboots prior to V7.0. During OpenVMS Bootstrap, the SYSINIT module reads SYS$TIMEZONE.DAT to acquire the TDF for use in the system global cell EXE$GQ_TDF. This is done to ensure that the system boots with a valid TDF (a value which may be zero). The UTC system services get the TDF from this cell. These services, as well as the HP C RTL, must have a valid TDF. (Prior to OpenVMS V7.3, if either DECnet-Plus or DECnet/VAX Extensions is configured and run, the image DTSS$SET_TIMEZONE.EXE 4-15 Time and Timekeeping is invoked and can override the TDF and timezone rule settings from SYSINIT or from UTC$TIME_SETUP.COM- this image runs even if DTSS is disabled. If the settings do not match (due to inconsistencies in timezone specification in UTC$TIME_SETUP.COM and NET$CONFIGURE.COM), DTSS will reset the values to match its definitions.) Prior to OpenVMS V7.3, daylight savings time switchover is handled automatically only when DCE DTS or DECnet- Plus DTSS is in use. In V7.3, OpenVMS can be configured to automatically switch over to daylight savings time, and also generates an event that interested applications can use to detect the switch-over between standard time and daylight time. The manual switchover between daylight savings time and standard time is correctly accomplished via the SYS$EXAMPLES:DAYLIGHT_SAVINGS.COM command procedure procedure. Note NTP (alone) does NOT provide automatic switch- over. Note The DST switch-over does NOT drift the time value; the switch-over applies the entire difference as a unit, as is standard and expected practice. If you switch the TDF or daylight savings time setting, you will also want to restart or reconfigure any time- sensitive applications (those not using the time differential factor (TDF) change event available in V7.3 and later). Examples of these applications include the need to restart the NFS client and (yes) NTP. (NTP will want to try to "drift" the time (see Section 4.2), and will find the daylight savings time switch-over to be far too large to "drift". Hence the NTP restart.) You can also use the (undocumented) TCP/IP Services (prior to V5.0) commands: SET TIME/DIFF=[positive or negative TDF integer] GENERATE TIME 4-16 Time and Timekeeping to reset the value of the logical name UCX$TDF. Prior to V7.3, the command: $ SETTZ :== $SYS$SYSTEM:DTSS$SET_TIMEZONE $ SETTZ MODIFY can be used to modify the settings of the SYS$TIMEZONE_ DAYLIGHT_SAVING, SYS$TIMEZONE_DIFFERENTIAL, and SYS$TIMEZONE_NAME system logical names based on the SYS$TIMEZONE_RULE. The following are other TDF-related logical names used/available on OpenVMS systems, with typical Daylight Savings and Standard Settings for the US Eastern Time (ET) timezone. $daylight_time: $ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EDT $ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0400 EDT" $ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P true ! Not 'EDT' $ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant $ $standard_time: $ DEFINE/SYSTEM/EXECUTIVE MAIL$TIMEZONE EST $ DEFINE/SYSTEM/EXECUTIVE NOTES$TIMEZONE "-0500 EST" $ DEFINE/SYSTEM/EXECUTIVE LISP$DAYLIGHT_SAVING_TIME_P false ! Not 'EST' $ DEFINE/SYSTEM/EXECUTIVE LISP$TIME_ZONE 05 ! Constant $ $ DEFINE/SYSTEM/EXECUTIVE UCX$NFS_TIME_DIFFERENTIAL - 'f$integer(f$element(0," ",f$logical("notes$timezone"))/-100)' One issue with the UTC implementation on OpenVMS is the behaviour of C functions and other programs that use SYS$TIMEZONE_RULE; the OpenVMS mechanism assumes all control over the timezone and the daylight time switchover. This allows calculation of the time by the C library and various applications. This can be incompatible with a system or application that requires manual modifications to the DST or TDF settings. For such a site to ensure the timekeeping is correct, the site must provide procedure that sets the local time and the TDF when the SYS$TIMEZONE_RULE says to do it. 4-17 Time and Timekeeping If a site requires a non-standard time switch-over, as in coordinating with a shift change, the site will need to use the ZIC utility to create a custom timezone rule. Additionally, applications may need to have special actions taken or actions queued just before the time change takes effect. If the application source code is available, one of the best ways to handle this is via the TDF and time-change notification events available via the OpenVMS sys$set_system_event system service. For information on ZIC and related tools used to manage the OpenVMS Timezone database, please see the DEC C Run-time Library Utilities Reference Manual-though the title would imply otherwise, this particular manual is part of the OpenVMS documentation set, and not part of the HP C (formerly Compaq C, formerly DEC C) documentation set. _____________________________ 4.3.1 How to troubleshoot TDF problems on OpenVMS? This is an OpenVMS Alpha system prior to V7.0 and the startup is not invoking the procedure: SYS$MANAGER:UTC$TIME_SETUP.COM This is an OpenVMS system prior to V6.0, where there is no OpenVMS TDF nor UTC available. The version of the application does not use the OpenVMS TDF. This includes TCP/IP Services prior to V5.0, applications using HP C built on or targeting OpenVMS prior to V7.0, and systems using the DECnet-Plus DTSS mechanisms prior to the release associated with OpenVMS V7.3. (DCE TDF TBD.) If you should find either of the following two timezone-related database files located in SYS$SPECIFIC:[SYSEXE]: o SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE.DAT o SYS$SPECIFIC:[SYSEXE]SYS$TIMEZONE_SRC.DAT 4-18 Time and Timekeeping These two files are in an erroneous location and must be recreated in the correct directory: SYS$COMMON:[SYSEXE] If the DCL command: $ DIRECTORY SYS$SYSTEM:SYS$TIMEZONE*.DAT shows these files in SYS$SPECIFIC:[SYSEXE], then delete them and use SYS$MANAGER:UTC$TIME_SETUP.COM to recreate them. On OpenVMS versions prior to V7.3, if the file: $ SYS$STARTUP:DTSS$UTC_STARTUP.COM is present on your system, then you may need to invoke: $ @SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM to recreate the timezone files correctly. Invoke this command immediately after [re]executing SYS$MANAGER:UTC$TIME_SETUP.COM.) If SYS$UPDATE:DTSS$INSTALL_TIMEZONE_RULE.COM is not present on your system, then you may need to execute the following commands: $ DELETE SYS$STARTUP:DTSS$UTC_STARTUP.COM $ DEASSIGN/SYSTEM/EXEC SYS$TIMEZONE_RULE. If your system time is being reported as being off by one hour (or whatever the local DST change), please see sections Section 4.6, Section 4.3 and Section 10.22.1. _____________________________ 4.3.2 Customizing your TDF (Timezone) Setting? Individual, local, and regional differences on the use (or the lack of use) of Daylight Savings Time (DST) are quite common. If you need to add (or remove) daylight savings time for your area or otherwise alter the rules for your local area, you will probably end up creating a variation to an existing timezone rule. 4-19 Time and Timekeeping The necessary zone line to add for WhereEverLand will probably look something like this: # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone WhereEver 2:00 - WhereEver The OpenVMS source file for the timezone rules here: SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES] You'll then want to ZIC this to create your own timezone definiton. ZIC is documented in the OpenVMS Documentation Set, in the HP C Run-Time Library Reference Manual. (Despite the name of the manual, it is part of the OpenVMS documentation set and not the C manuals.) Once you have created the new rule, use SYS$MANAGER:UTC$TIME_SETUP.COM to select the new timezone-with V7.3 and later, this tool will notice the new timezone and will offer it, on earlier releases, you may/will have to hack the tool somewhat. (Don't even think of trying to define the TZ logical name (found on older configurations), or the SYS$TIMEZONE_ NAME logical name, or any other time- or timezone- related logical names directly yourself.) For various timezone rules, see the tar.gz files (these are gzipped tar archives) available at: o ftp://elsie.nci.nih.gov/pub/ __________________________________________________________ 4.4 Why does the SET TIME command fail? Help managing DTSS? If you try to set the system time with the SET TIME command, and see one of the following messages: %SET-E-NOTSET, error modifying time -SYSTEM-F-IVSSRQ, invalid system service request %SET-E-NOTSET, error modifying time -SYSTEM-E-TIMENOTSET, time service enabled; enter a time service command to update the time 4-20 Time and Timekeeping This occurs if the time on the local system is controlled by a time service software, for example the distributed time service software (DTSS) provided as part of the DECnet-Plus installation. The DTSS software communicates with one or more time servers to obtain the current time. It entirely controls the local system time (for DECnet-Plus, there is a process named DTSS$CLERK for this); therefore, the usage of the SET TIME command (and the underlying $SETTIM system service) is disabled. The first message is displayed on systems running DECnet-Plus V6.1 and earlier. On systems with newer DECnet-Plus software, the second (and more informative) message is given. You shouldn't have to change the time manually - you should be doing this through the time server - but if you insist... you'll have to shutdown DTSS: $ RUN SYS$SYSTEM:NCL DISABLE DTSS DELETE DTSS This will shutdown DTSS$CLERK. You may then change the system time as usual. To restart the DTSS software, type $ @SYS$STARTUP:DTSS$STARTUP You will need a number of privileges to ussue this command, and you must also be granted the NET$MANAGE identifer to shutdown and to restart DTSS. If you wish to "permanently" disable DTSS on a system running DECnet-Plus, the above NCL sequence must be performed each time the system is bootstrapped. (On DECnet-Plus V7.3 and later, you can define the logical name NET$DISABLE_DTSS to disable the DTSS startup. This logical name must be defined in the command procedure SYLOGICALS.COM, as this logical name must be present and defined sufficiently early in the OpenVMS system bootstrap sequence for it to function.) 4-21 Time and Timekeeping If DTSS is running and no time servers are configured, you can (and will) see the following messages at regular intervals: %%%%%%%%%%% OPCOM 2-SEP-1999 19:41:20.29 %%%%%%%%%%% Message from user SYSTEM on UNHEDI Event: Too Few Servers Detected from: Node LOCAL:.mynode DTSS, at: 1999-09-02-19:41:20.296-04:00Iinf Number Detected=0, Number Required=1 eventUid 5FA70F4F-616E-11D3-A80E-08002BBEDB0F entityUid DE9E97DE-6135-11D3-8004-AA000400BD1B streamUid D6513A46-6135-11D3-8003-AA000400BD1B You can either configure the appropriate number of time servers, or you can disable DTSS, or you can ignore it and (if OPCOM is set to write to the log via via the logical names in SYLOGICALS.COM/SYLOGICALS.TEMPLATE) clean out OPERATOR.LOG regularly. You can also simply disable the display of these messages: $ run sys$system:ncl block event dispatcher outbound stream local_stream global filter - ((Node, DTSS), Too Few Servers Detected) If you wish to disable the automatic TDF adjustment for daylight savings time (on OpenVMS versions prior to V7.3), you can use the command: $ run sys$system:ncl set dtss automatic TDF change = false or alternatively, you can set the local timezone to one that does not include the automatic daylight savings time change-over. OpenVMS V7.3 and later simplify time and timezone management. 4-22 Time and Timekeeping __________________________________________________________ 4.5 Setting time on AlphaServer ES47, ES80, GS1280 console? 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: o Show the system configuration and provide the basic debugging capability o Initiate the firmware update or load the test firmware version o Power on or off, halt, or reset the system or partition o The system partitioning and cabling functions o Displays of the health of hardware environment, including such constructs as fans, power supplies and environmental and temperature values. o Remote server management tasks o 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-23 Time and Timekeeping __________________________________________________________ 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.) 4-24 Time and Timekeeping 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: o ftp://elsie.nci.nih.gov/pub/ o http://physics.nist.gov/GenInt/Time/time.html o http://nist.time.gov/ 4-25 _______________________________________________________ 5 System Management Information __________________________________________________________ 5.1 What is an installed image? The term "install" has two distinct meanings in OpenVMS. The first relates to "installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM command procedure or the POLYCENTER Software Installation (PCSI) utility (PRODUCT command). The second meaning relates to the use of the INSTALL utility, which is what concerns us here. The INSTALL utility is used to identify to OpenVMS a specific copy of an image, either executable or shareable, which is to be given some set of enhanced properties. For example, when you issue the SET PASSWORD command, the image SYS$SYSTEM:SETP0.EXE is run. That image needs to have elevated privileges to perform its function. The other important attribute is /SHARED. This means that shareable parts of the image (typically read-only code and data) are loaded into memory only once and are shared among all users on a system. Executable images can be installed /SHARED as well as shareable library images. (The term "shareable" has dual meanings here, too. See the OpenVMS Programming Concepts Manual for further details.) It's important to note that there is no such thing as "installing a shareable image with privileges". The INSTALL utility will let you do it, but the privileges you specify will be ignored. To have a callable routine run with enhanced privileges that are not available to its caller, you must construct your routines as "user- written system services" and install the shareable image with the /PROTECT qualifier. See the OpenVMS Programming Concepts Manual for more information on user-written system services. Note also that in many cases the need to grant privileges to an 5-1 System Management Information image can be replaced with the use of the "Protected Subsystems" feature that grants a rights identifier to an image. See the OpenVMS Guide to System Security for information on Protected Subsystems. __________________________________________________________ 5.2 Are there any known viruses for OpenVMS? Viruses 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 5-2 System Management Information 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. 5-3 System Management Information 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? o http://www.hp.com/go/openvms/doc o http://www.blacksheepnetworks.com/security/resources/openvms/ o http://www.vmsone.com/~opcom/defcon9.htm __________________________________________________________ 5.4 How do I mount an ISO-9660 CD on OpenVMS? ISO-9660 support was added in the following releases: o OpenVMS VAX V6.0 o OpenVMS AXP V1.5 An add-on ISO-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 5-4 System Management Information 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: o http://pdp-11.trailing-edge.com/www/ods1.txt o Look for the Freeware V5.0 directory ODS2 at http://www.hp.com/go/openvms/freeware/ 5-5 System Management Information __________________________________________________________ 5.5 How do I extract the contents of a PCSI kit? A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits. If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command: $ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCE 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. 5-6 System Management Information 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 button, entering on the console, or pressing the 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 @ 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. 5-7 System Management Information 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. 5-8 System Management Information 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. 5-9 System Management Information 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. _____________________________ 5.6.1 I've forgotten the SYSTEM password - what can I do? If you have forgotten or do not have the password for the SYSTEM username, you must perform the conversational bootstrap as described in Section 5.6, and must enter the following commands once you have reached the dollar ($) prompt: $ SET DEFAULT SYS$SYSTEM: ! or wherever your SYSUAF.DAT resides $ RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT You have now reset the password on the SYSTEM username. 5-10 System Management Information _____________________________ 5.6.2 My product licenses have expired - what can I do? If you have a system with no licenses for OpenVMS or for OpenVMS users and thus cannot log into the OpenVMS system normally, you should be able to log into the console serial terminal-this is the terminal device known as OPA0:-and perform the commands necessary. For systems that are not configured with an accessable console serial terminal-as can be the case with how some DECwindows workstations are configured-you must log in over the network or from a local serial connection. If you cannot log in over a network connection (SET HOST, telnet, etc) or from another local serial terminal connection, you will have to halt the system and perform a conversational bootstrap as described in Section 5.6. You must then enter licensing-related commands once the conversational bootstrap has reached the dollar ($) prompt. Use the following DCL command to invoke a menu that allows you to manage and to register new or replacement license PAKs: $ @SYS$UPDATE:VMSLICENSE You have now registered the license PAKs. Direct use of the DCL commands LICENSE and SHOW LICENSE and such is also obviously available. If you wish to connect a serial console on your DECwindows workstation, please see Section 14.3.3.3, Section 14.3.6, Section 11.10, and Section 14.19. For information on troubleshooting DECwindows, please see Section 11.5. __________________________________________________________ 5.7 How do I change the node name of an OpenVMS System? The first step is to get a BACKUP of the system disk before making any changes-use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk. 5-11 System Management Information Changing the node name involves a number of steps-the node name tends to be imbedded in a number of different data files around the system. o Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.) o Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.) o Modify the host node name on the various queues in the queue database. (each queue has a host name, and it defaults to the SCS node name of the queue's host system. See the command INIT/QUEUE/ON=node for information.) Site-specific startup command procedures can explicitly specify the node on the /ON parameter in an INIT/QUEUE/START/ON= command. o Modify the node name saved in any application databases, or any local node-conditional operations present in the site-specific system startup, etc. (SEARCH for the node name, specifying all types of files.) o Use the AUTHORIZE utility command RENAME/IDENTIFIER to rename the SYS$NODE_oldnodename rightslist identifier to match the new node name. (Do not change the binary value of this identifier, and do not delete the identifier.) If you have erroneously deleted or duplicate the identifier, you can locate existing references to the binary identifier value using the Freeware DFU package, and specifically the commands SEARCH/ACE and /OWNER. You must (re)create the correctly-named identifier using the binary value that is often stored in various Access Control List Entry (ACE) structures and object owner fields associated with files and objects present in the OpenVMS system. o Reset any license PAKs that are restricted to the old node name to the new node name. o If the node name is part of a disk volume label, see Section 5.13. 5-12 System Management Information o Reboot the node or-if in a VMScluster-reboot the whole VMScluster. (This tends to catch any errors immediately.) o Modify the IP node name. (The TCP/IP Services tool is UCX$CONFIG prior to V5.0, and is TCPIP$CONFIG in V5.0 and later releases.) Note that TCP/IP Services ties the IP host name to the current SCSNODE value within its database. Thus if SCSNODE is changed, the IP host name reconfiguration must occur only after a system reboot. Accordingly, it is best to perform the TCP/IP Services host name reconfiguration step after the reboot. There are likely a few other areas where the nodename will be stored. Local procedures and data files are one such example, and various sites will have the system name loaded in the operator control panel via the OCP_ TEXT console environment variable available at the SRM prompt on some Alpha systems is another. If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID-but not both values-then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.) To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478) This may well have missed one or two configuration tools (or more!) that are needed at your site-the node name tends to get stored all over the place, in layered products, and in local software... Also see Section 15.6.3 and Section 15.6.4. 5-13 System Management Information __________________________________________________________ 5.8 Why doesn't OpenVMS see the new memory I just added? When adding memory to an OpenVMS system, one should check for an existing definition of the PHYSICALPAGES (OpenVMS VAX) or PHYSICAL_MEMORY (OpenVMS Alpha) parameter in the SYS$SYSTEM:MODPARAMS.DAT parameter database, use a text editor to reset the value in the file to the new correct value as required, and then perform the following command: $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK This AUTOGEN command will reset various system parameters based on recent system usage (FEEDBACK), and it will reset the value for the PHYSICALPAGES parameter to the new value. It will also reboot the OpenVMS system. PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately lower the amount of memory available for use by OpenVMS. This ability can be useful in a few specific circumstances, such as testing the behaviour of an application in a system environment with a particular (lower) amount of system memory available. PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1 (on OpenVMS Alpha) or (better and simpler) the entry can be removed from the MODPARAMS.DAT file, to indicate that all available memory should be used. __________________________________________________________ 5.9 How do I change the text in a user's UIC identifier? The text translations of the numeric User Identification Code (UIC) are based on identifiers present in the OpenVMS rightslist. Documentation on this area is included in the _Guide to OpenVMS System Security_ manual. To control the identifiers shown for a user's UIC, you use AUTHORIZE. Each user has an associated group identifier, and an identifier specific to the user. And each user should have a unique UIC. To alter the text of a user or group identifier, use commands such as: 5-14