Chapter 3
Configuring the TCP/IP Core Environment
This chapter describes the steps you need to take before using CNFNET to configure TCPware’s core environment, TCP-OpenVMS. This chapter is for the OpenVMS system manager or operator responsible for the TCP/IP core environment configuration.
This chapter covers the TCP/IP core configuration only. You later configure the individual TCP/IP components in Chapter 4, Configuring the TCP/IP Services.
Before you run CNFNET, there are certain things you need to do first:
1 Define the file location logicals.
2 Obtain Internet addresses for your network devices.
Each of these steps are described in detail in later sections of this chapter.
You run the CNFNET.COM procedure file to configure the TCPware core environment and the TCP/IP components. You can access CNFNET using either of two options. Each option provides different configuration choices.
TCPware file definitions include a number of logicals. You can define these logicals using the SYS$SYSROOT:[TCPWARE]TCPWARE_LOGICALS.COM command file. The VMSINSTAL procedure (from the previous chapter) generates this command file.
Note! Execute TCPWARE_LOGICALS.COM before performing any other TCPware procedure.
Table 3-1 shows the TCPware logicals and how they relate to OpenVMS system logicals. The system logical equivalents apply only if the TCPware installation is on the default locations on the sy
Table 3-1 TCPware Logicals (Continued)
stem disk.
You can also set customized filenames and locations for TCPware component files by using a customized logicals command file. This can help prevent duplicate databases in mixed architecture systems. TCPware provides a CUSTOM_LOGICALS.TEMPLATE file containing logicals (such as TCPWARE_NFS_PROXY_DB) you can redefine from their given defaults. Rename this file to CUSTOM_LOGICALS.COM to put the new file locations into effect on a system-wide basis.
See Appendix C, Installed Files, for the default component filenames and locations.
Depending on how you want to configure the TCP/IP core environment (TCP-OpenVMS) and the TCP/IP components, you can choose either a command-driven method or a menu-driven method. Using either method, you can perform a basic, full, or component configuration.
However, if you are configuring TCPware for the first time, you need to configure TCP-OpenVMS first.
• The basic configuration allows you to configure TCP-OpenVMS and some of the basic TCP/IP component settings.
• The full configuration allows you to configure TCP-OpenVMS and the full TCP/IP components.
• The component configuration allows you to specify a component to configure. Use this if you are not configuring TCPware for the first time and you need to configure certain services components only.
The CNFNET.COM procedure creates the configuration data file, TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM.
To use the command-driven method, enter the CNFNET command followed by the option choice you want:
@TCPWARE:CNFNET option
Your option choices and description are listed in Table 3-2.
Table 3-2 Command-driven Option Choices (Continued)
The menu-driven method provides configuration options as convenient menu selections. Your selection choices are shown in Example 3-1. The menus that appear as you make your choices move from one function to the next, and you can back up and make corrections as you go. You can use the menus to configure TCP-OpenVMS specifically.
To describe the configuration process for the core environment, this chapter uses the menu-driven method.
These are the steps to the TCP/IP core environment configuration:
1 Start CNFNET.
2 Enter your Maintenance Agreement Number.
3 Enter line identification codes for the network devices.
4 Enter host addresses for the network devices.
5 Enter the default gateway host address.
6 Enter the local time zone.
7 Enter the local hostname or update the HOSTS. file.
To start CNFNET using the menu-driven method:
1 At the DCL prompt, enter:
$ @TCPWARE:CNFNET MENU
2 Press Return at the
Type <return> to continue... prompt.
The menu in Example 3-1 appears.
Example 3-1 TCPware Configuration Menu
TCPware(R) for OpenVMS Configuration Menu
Configuration Options:
1 - Configure TCPware Services
2 - Startup/Restart all TCPware Services
3 - Shutdown all TCPware Services
L - Display the software licensing information (PASSWORD)
E - Exit the configuration procedure (changes will be saved)
Enter configuration option: 1 Return
3 Enter 1(Configure TCPware Services) at the Enter configuration option: prompt. CNFNET displays the TCPware Services Configuration Menu shown in Example 3-2.
4 Enter 1(Core environment for TCP/IP services) at the Enter configuration option: prompt. CNFNET displays the message and prompt:
Configuring the core TCP/IP environment...
Enter your Maintenance Agreement (MAS) number []:
Example 3-2 TCP/IP Services Configuration Menu
TCPware Services Configuration Menu
Configuration Options:
1 - Core environment for TCP/IP services
2 - Configure all TCP/IP components
3 - Configure a specific TCP/IP component
4 - Startup/Restart TCP/IP services
5 - Shutdown TCP/IP services
6 - Startup/Restart a specific TCP/IP component
7 - Shutdown a specific TCP/IP component
E - Exit to previous menu
Enter configuration option: 1 Return
If you have a maintenance agreement with Process Software, you can find your "Master Agreement No." (MAS) on your Software Maintenance and Support Acknowledgment form. The MAS number helps in future communications with Process Software.
Note! If you decided to start the configuration using either the @TCPWARE:CNFNET TCPWARE or @TCPWARE:CNFNET TCP command, a different screen appears. It contains a message that CNFNET creates the TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM file to reflect your configuration. Press Return to continue and the MAS number request prompt appears. (See Example 3-3.) CNFNET purges up to the last five versions of the TCPWARE_CONFIGURE.COM file. You are strongly advised not to edit this file directly.
Example 3-3 Entering Your Maintenance Agreement Number
This procedure creates the configuration data file, TCPWARE_SPECIFIC:[TCPWARE]TCPWARE_CONFIGURE.COM, to reflect your system's configuration.
Please enter your Process Software Maintenance Agreement (MAS) number if you have one and have it available. This number can be found on the top of your Software Maintenance and Support Acknowledgment form.
If you do not have this number, press <RETURN> at the prompt. If you would like to enter this information later, you can set it using the command:
$ @TCPWARE:CNFNET MAS
Enter your Maintenance Agreement (MAS) number []: M123456 Return
Enter the MAS number now, or later using the @TCPWARE:CNFNET MAS command. Once entered, this number appears when you use the NETCU SHOW VERSION /ALL command.
CNFNET prompts you for the necessary information during the rest of the procedure. Default answers, if available, are provided in square brackets as part of some prompts, based on information extracted from your environment. If you want to accept the default, press Return. If not, enter the value or information you need and then press Return.
You now need to define the network devices and information for each device. Entering line identification codes is the first step.
CNFNET displays the text and prompt in Example 3-4.
Example 3-4 Entering Line Identification Codes
You need to enter the line identifications for the available network devices. The following is a partial list of the network devices that are supported:
Line IdNetwork Device [1]
---------------------
QNA-n for Digital's DELQA, DESQA, or DEQNA (XQDRIVER)
UNA-n for Digital's DELUA or DEUNA (XEDRIVER)
BNA-n for Digital's DEBNI, DEBNA, or DEBNT (ETDRIVER)
SVA-n for Digital's DESVA (ESDRIVER)
MNA-n for Digital's DEMNA (EXDRIVER)
ISA-n for Digital's VAX 4000 (EZDRIVER)
MFA-n for Digital's DEMFA FDDIcontroller 400 (FXDRIVER)
FZA-n for Digital's DEFZA FDDIcontroller 700 (FCDRIVER)
PRO-n for Proteon's proNET (PNDRIVER)
HYP-n for NSC's HYPERchannel (NxDRIVER)
SLIP-n for (static) Serial Line IP (any terminal device)
DECNET-n for IP over DECnet (requires DECnet)
DSB-n for Digital's DSB32 (SLDRIVER)
DST-n for Digital's DST32 (ZSDRIVER)
DSV-n for Digital's DSV11 (SJDRIVER)
X25-n for VAX P.S.I. (IP over X.25)
LPB-0 for local loopback (no device driver)
EIA-0 for HP’s i82558 10/100 Ethernet interface
EWA-0 for HP’s DEGXA gigabit interface
Unless your system has more than one controller, n is 0.
Enter the line identifications [LPB-0,SVA-0]: Return [2]
For a full list of supported network devices, see Table 3-3.
The network device line identification (line ID) consists of a line name and controller number combination, such as QNA-0 or UNA-1 (see Example 3-4).
1 Find each network device over which you plan to run TCPware on your system in Table 3-4 and note its line ID.
2 Enter the line ID or IDs at the following prompt:
Enter the line identifications [default-lines]:
The system displays any default line IDs that exist on your system in the square brackets. Press Return to accept them or add additional devices. You can enter up to sixteen devices, separated by commas.
Always enter the local loopback device (LPB-0) first. This is a pseudo-device not associated with any physical device. TCPware uses the loopback device only if no other hosts are connected to the network. TCPware always configures the LPB-0 device unless you specify not to do so.
For example, to support the DELQA controller (QNA) and a HYPERchannel (HYP) device, enter:
LPB-0,QNA-0,HYP-0
Note! If your system runs Oracle software with TCPware as the transport, make sure that you configure the LPB-n device. Otherwise, Oracle sends a message stating that it cannot connect. Note that you must have TCPware fully installed and operating before you can install Oracle's SQL*Net.
If you are configuring HYPERchannel devices, respond to the prompt:
What is the local HYPERchannel address for line...:
The format of the 32-bit HYPERchannel address combination is:
aa-bb-cc-dd
For each HYPERchannel device selected, also enter the Address Resolution Protocol (ARP) server's HYPERchannel address for line HYP-n at the prompt:
What is the ARP server's HYPERchannel address?
You can enter NONE or press Return at the prompt if there is no ARP server address.
See the Management Guide, Chapter 1, Common Interfaces, the HYPERchannel section for further information. Also see the NETCU Command Reference, Chapter 2, NETCU Commands, the ADD ARP command for populating ARP tables.
If you are configuring IP-over-DECnet devices, use the following format at the prompt:
What is the DECnet link information:
node-name::"TASK=object-name"
If you enter N at the prompt:
Is this the LISTENER end of the DECnet link?
TCPware assumes that you are issuing commands for the master node. See the Management Guide, Chapter 1, Common Interfaces, the IP-over-DECnet section for further information.
Table 3-3 Network Devices and Line IDs (Continued)
|
This controller... |
Has line ID... |
For device driver |
|
Classical IP over ATM |
CLIP-n |
CLDRIVER |
|
PMAD Communications Link |
MXE-n |
ECDRIVER |
|
LAN Emulation Driver** |
ELA-n |
ELDRIVER |
|
EISA Bus Adapter (DE422/425)** |
ERA-n |
ERDRIVER |
|
DESVA VAXstation 2000/3100/4000 |
SVA-n |
ESDRIVER |
|
DEBNA/DEBNI/DEBNT VAXBI Ethernet* |
BNA-n |
ETDRIVER |
|
PCI Bus Adapter (TULIP)** |
EWA-n |
EWDRIVER |
|
DEMNA XMI Ethernet |
MNA-n |
EXDRIVER |
|
VAX 4000 Ethernet (SGEC*, TGEC**) |
ISA-n |
EZDRDIVER |
|
DE600-AA, DE602-AA (NC3123, NC3131)** |
EIA-n |
EIDRIVER |
|
DEFAA FDDIcontroller |
FAA-n |
FADRIVER |
|
DEFTA/DEFZA FDDIcontroller |
FZA-n |
FCDRIVER |
|
DEFQA FDDIcontroller* |
FQA-n |
FQDRIVER |
|
DEFEA FDDIcontroller** |
FEA-n |
FRDRIVER |
|
DEFPA FDDIcontroller |
FPA-n |
FWDRIVER |
|
DEMFA FDDIcontroller |
MFA-n |
FXDRIVER |
|
DETRA TRNcontroller 700** |
TRA-n |
ICDRIVER |
|
DEGXAgigabit controller*** |
EWA-n |
EW5700 |
|
i82558 10/100 Ethernet controller*** |
EIA-n |
EIDRIVER |
|
Proteon PROnet-4/16 EISA NIC (DW300)** |
TRE-n |
IRDRIVER |
|
HYPERchannel H269 |
HYP-n |
NxDRIVER**** |
|
Proteon proNET-10/80 |
PRO-n |
PNDRIVER**** |
|
HP WAN DSV11 |
DSV-n |
SJDRIVER**** |
|
HP WAN DSB32 |
DSB-n |
SLDRIVER**** |
|
DELUA/DEUNA UNIBUS Ethernet* |
UNA-n |
XEDRIVER |
|
DELQA/DEQNA/DEQTA/DESQA Q-BUS Ethernet* |
QNA-n |
XQDRIVER |
|
HP WAN DST32 |
DST-n |
ZSDRIVER**** |
|
IP-over-DECnet |
DECNET-n |
DECnet |
|
Serial lines |
SLIP-n |
various |
|
IP-over-X.25 |
X25-0 |
VAX P.S.I. |
|
Local loopback |
LPB-0 |
*VAX-specific
**Alpha-specific
***I64-specific
****PNDRIVER, NxDRIVER, SJDRIVER, SLDRIVER, and ZSDRIVER are not provided as part of OpenVMS, MicroVMS, or TCPware for OpenVMS. Purchase the proNET driver directly from Proteon, Inc. (part number p5330). The HYPERchannel drivers include NADRIVER for Q-BUS and UNIBUS, NBDRIVER for MASSBUS, and NCDRIVER for VAXBI; you must purchase the H269 drivers directly from Network Systems Corporation. Purchase the HP WAN drivers directly from HP (see Software Product Description 29.64.xx).
If you plan to use IP-over-X.25 support:
1 Install, configure, and have running the full VAX P.S.I. V4.3 (or later) software and any required hardware.
See Chapter 2, Installing TCPware, the Installing Other Products section.
2 During CNFNET, enter the IP-over X.25 line ID as X25-n. Do not enter it as DSV-n. If you are using only X.25, enter the IP address for the X.25 interface at the What is the local host's INTERNET ADDRESS prompt. If your interface is unnumbered, press Return at the Is this interface unnumbered: prompt. If you have a unique IP address for X.25, enter N at the prompt.
See the Management Guide, Chapter 8, X.25 Interface. Also see the documentation with your VAX P.S.I. products.
If your system will be running Oracle software with TCPware as the transport, make sure that you configure the LPB-n device. Otherwise, Oracle sends a message stating that it cannot connect. Note that you must have TCPware fully installed and operating before you can install Oracle's SQL*Net.
If you are configuring Serial Line IP (SLIP) devices, you can use any valid OpenVMS terminal device as a SLIP line. Unlike other line ID controller numbers, the one for SLIP lines is not related to the actual device name. To configure SLIP devices, respond to the prompt with:
What is the device name for line...:
You can also create the TCPWARE:SLIP_SETUP.COM file. The network startup command procedure executes this command procedure, if it exists, before starting the SLIP lines. SLIP_SETUP.COM should contain the commands necessary to configure the terminal devices for proper operation. Typically, it would include SET TERMINAL commands to set the baud rate and other terminal characteristics.
See the Management Guide, Chapter 1, Common Interfaces, the Serial Line IP (SLIP) Interface section for further information. See Chapter 6 in the Installation and Configuration Guide, the System Parameters section.
If you are configuring HP WAN device drivers, the configuration options include the protocol, type of duplex mode, clocking method, type of CRC, line speed, number of receive buffers, and retransmission time to use. To configure HP WAN devices, respond to the prompt:
What are the configuration options for line...:
See the Management Guide, Chapter 1, Common Interfaces, the HP Wide Area Network (WAN) Device Drivers section for further information, especially Table 1-1.
The next step in defining your network devices is to enter the local host internet address, hostname, and host subnet mask for each device (see Example 3-5):
1 Enter each network device's local host internet address. (See Table 3-5 below for tips.)
2 Enter each network device's local hostname. (You may have to enter the fully qualified domain name, as in Example 3-5; see Table 3-5 for an explanation.)
3 Enter each network device's local host subnet mask (if it exists). For help, see Table 3-6.
4 Respond to the prompt asking if you want trailer packet (default=NO) and Reverse ARP (RARP) support (default=YES) for the configured network line. This does not apply to VMS Communications Interface (VCI) support.
For details on RARP and trailer packets, see the Management Guide, Chapter 1, Common Interfaces, the appropriate subsections under the Ethernet, FDDI, Token Ring, and ATM Interfaces section.
5 Indicate whether the configuration is correct. If the answer is N, start the network device configuration process over again
Table 3-4 Tips for Entering Network Device Information (Continued)
|
Internet Address |
Hostname |
Subnet Mask |
|
The local loopback device (LPB-0) automatically gets an internet address of 127.0.0.1. Each network device connects the host to a different network. The host must have a unique internet address on each connected network. For most lines, the internet address is not related to the physical address. For some interfaces, the Address Resolution Protocol (ARP) resolves the mapping between internet and physical addresses. |
If you are using Domain Name Services to resolve hostnames, enter the fully qualified domain name (including the machine name) of the local host. If not using the Domain Name Services, enter just the machine name as it appears in the local TCPware:Hosts.file. Enter the host name only once. Its case is preserved. You do not need to enter a name for each network. Indicate only the "primary" network. |
If a device is on a subnet, you should assign a subnet mask. This mask "extends" the network portion of the address to cover part of the host portion to divide the latter into subnets. For example, host 192.168.4.56 is on a subnet of network 192.168.0.0 encompassing addresses 192.168.4.1 through 192.168.7.254 (comprising 1022 hosts). The mask to use would be 255.255.252.0. The subnet mask must include at least the network mask. Do not use a subnet mask with an unnumbered interface. See the next section for details. |
Table 3-5 Internet Address Classes (Continued)
|
Address Class |
First Byte Range |
Network Mask |
|
Class A |
1. 127. |
255.0.0.0 |
|
Class B |
128. 191. |
255.255.0.0 |
|
Class C |
192. 223. |
255.255.255.0 |
|
Class D |
224. 239. |
None |
Example 3-5 Entering Host Address Information
You need to supply the following information for each network:
- The internet address for this host
- The host name for the local internet address
- The subnet mask for the network
- The line specific information (depends on line)
If a network is not subnetted, press return at the subnet mask prompt. Otherwise, enter the subnet mask for the network as an internet address. These are the default subnet masks for each network class:
Network Class Default Subnet Mask
------------- -------------------
A 255.0.0.0
B 255.255.0.0
C 255.255.255.0
Using LOOPBACK (127.0.0.1) as host name for line LPB-0. [1]
What is the local host's INTERNET ADDRESS for line SVA-0:198.168.1.56 Return
What is the HOST NAME for line SVA-0: NUNKI.NENE.COM Return [2]
What is the SUBNET MASK for line SVA-0 [255.255.255.0]: Return [3]
Do you want to enable TRAILER packet support for line SVA-0 [NO]: Return
Do you want to enable RARP (Reverse ARP) support for line SVA-0 [YES]:Return
[4]
The network devices are configured as follows:
Line Address Name Options
---- ------- ---- -------
LPB-0 127.0.0.1 LOOPBACK
SVA-0 198.168.1.56 NUNKI.NENE.COM /FLAGS=(NOTRAILERS)
Is this configuration correct [YES]: Return [5]
The next step is to define the internet address of your default gateway (see Example 3-6):
Enter the internet address of the default gateway, if the network or networks connected to your host connect to other networks, for example.
The address must be on a network to which your host is directly connected. If the network has more than one gateway, enter the gateway that is "closest" to the networks with which you will communicate most frequently.
If you want to remove a previously assigned default gateway, or if your network does not have a gateway, enter 0.0.0.0 as the default gateway internet address.
Example 3-6
Sample Defining a Default Gateway
If your network is connected to other networks, you need to enter the internet address of a default gateway. If your network has more than one gateway, enter the gateway "closest" to the networks that you will be connecting to most frequently. The (sub)network portion of the internet address for the gateway MUST match that of a locally connected (sub)network.
Enter 0.0.0.0 if you need to remove a previously defined default gateway or your network does not have any gateways.
Your routing requirements might be more complex if your network has several gateways. Handle this by adding the appropriate NETCU commands (such as ADD ROUTE) to the TCPWARE_COMMON:[TCPWARE]ROUTING.COM command procedure.
For more information on routing, refer to the TCPware(R) for OpenVMS documentation.
Enter the internet address of the default gateway [0.0.0.0]: Return
Support for automatic Daylight Savings Time (DST) changes has now been added to the existing method of specifying time zone information. You can configure time zone and DST information, which can be used by the Network Time Protocol (NTP) to change the system clock and the time offset information automatically.
To understand time zone configuration, time zone offset, and the hardware clock in relation to choosing the time zone settings you need, please read the following sections.
By convention, the hardware clock is usually set to the local time, but network protocols represent time in Greenwich Mean Time (GMT), also known as Universal Coordinated Time (UTC).
To convert between local time and GMT, TCPware uses built-in rules or rules provided by the system manager. Each country or geographical area has its own names for time zones and its own rules for Daylight Savings Time (DST). The names for these time zones and rules are not necessarily unique; for example, "EST" could refer to the United States Eastern Standard Time, the Canadian Eastern Standard Time (which uses different DST rules), or the Australian Eastern Standard Time (which is a different offset from GMT as well).
TCPware uses the name of the local time zone specified by a system manager to calculate the offset between the local time and GMT, so it is important that an appropriate set of time zone rules be selected for your area.
TCPware assumes that the hardware clock is always set exactly to local time. For a smooth transition to and from Daylight Savings Time (DST), the hardware clock must be reset at the appropriate time. If NTP is used to synchronize the clock to a time server, NTP adjusts the clock automatically when the Daylight Savings Time transition occurs. Note that using a military time zone or an explicit GMT offset disables automatic Daylight Savings Time transitions.
It is not possible to consider every country or area in which TCPware might be used, and because the Daylight Savings Time rules are subject to change by local governmental action, you can write your own site-specific time zone rules.
Time zone rules are either compiled-in or defined in the time zone rule definition file and converted by the time zone rule logical at startup, or by entering a specific NETCU command (DEFINE TIMEZONE).
• Compiled-in rules are geographically centered around the United States but also include foreign time zones having names that do not conflict with the U.S. time zones.
• User-defined rules are specified by using the NETCU command DEFINE TIMEZONE. Use the NETCU command to override the compiled-in rules.
TCPware includes a database of the most common loadable rules; you can select these rules as is, or modify them to conform to the correct local time zone rules.
When TCPware searches the time zone rules looking for a zone, it first searches the loaded rules in the order they are selected, then searches the compiled-in rules.
In addition to the standard one-letter U.S. military time zones and time zones of the form GMT+hh:mm or GMT-hh:mm, there are compiled-in time zone rules supported by TCPware, which are shown in Table 3-7.
When a time zone is compiled-in, the logical "TCPWARE_ TIMEZONE_NAME" specifies which rule is to be compiled in; for example, EST. The compiled-in time zone rules are listed in the following table.
Table 3-6 Compiled-In Time Zone Rule (Continued)
|
Time Zone Name |
GMT Offset (hours) |
DST Rules |
Area or Country |
|
EST or EDT |
-5 |
U.S. Federal |
Eastern United States |
|
CST or CDT |
-6 |
U.S. Federal |
Central United States |
|
MST or MDT |
-7 |
U.S. Federal |
Mountain United States |
|
PST or PDT |
-8 |
U.S. Federal |
Pacific United States |
|
YST or YDT |
-9 |
U.S. Federal |
Yukon |
|
HST |
-10 |
none |
Hawaii |
|
NST or NDT |
-3:30 |
Canadian |
Canadian Newfoundland |
|
AST or ADT |
-4 |
Canadian |
Canadian Atlantic |
|
JST |
+9 |
none |
Japan |
|
SST |
+8 |
none |
Singapore |
|
GMT |
+0 |
none |
Greenwich Mean Time |
|
GMT or BST |
+0 |
British |
Britain |
|
WET or WET-DST |
0 |
European |
Western Europe |
|
MET or MET-DST |
+1 |
European |
Middle Europe |
|
CET or CET-DST |
+1 |
European |
Central Europe (Middle Europe) |
|
EET or EET-DST |
+2 |
European |
Eastern Europe |
|
NZST or NZDT |
+12 |
New Zealand |
New Zealand |
Loadable time zone rules provided with TCPware are in the text file TCPWARE:TIMEZONES.DAT. You can add user-written time zone rules to the file TCPWARE:TIMEZONES.LOCAL to override the zones in TIMEZONES.DAT. The user-defined time zone rule format has three parts:
• COUNTRY is a collection of time zones (ZONES); for example, the country US selects all U.S. time zones. This provides a convenient way to select groups of time zones.
• ZONE is a specification of a particular time zone, including the name of the zone, the GMT offset, the DST rules in effect, and the name to use while DST is in effect.
• RULE is a rule for determining when DST is in effect.
COUNTRY countryname zonename [zonename . . .]
The COUNTRY specification gives the name of the geographical area and the names of the time zones associated with it. This provides a way to group time zones so they can be selected more conveniently.
The following example shows the definition of the country "US" listing the zones corresponding to the United States. The example for Arizona is slightly different, showing the zone "US/Arizona" instead of "US/Mountain." (US/Arizona is the definition of a Mountain time zone that does not observe Daylight Savings Time.)
Country US US/Eastern US/Central US/Mountain US/Pacific US/Yukon US/
Country -
US/Arizona US/Eastern US/Central US/Arizona US/Pacific US/Yukon US/H
ZONE zonename gmtoffset rulename standard-name dst-name [COMPILED_IN]
In the ZONE specification format:
• zonename is the name by which this zone can be selected, or the name by which it is referred to in a COUNTRY specification.
• gmtoffset is this zone's standard time offset from GMT.
• rulename is the name of the RULE specification that determines when DST is in effect for this zone. The rulename may be an underscore (_) to indicate that this zone does not use DST.
• standard-name and dst-name are the names by which this zone is referred to during standard time, and during Daylight Savings Time, respectively. These are the names by which DEFINE TIMEZONE selects the local time zone.
If there are no DST rules, the dst-name should be specified as an underscore (_). The optional COMPILED_IN keyword indicates that this rule is compiled-in and need not be loaded, as long as no other rules conflict with it. If you edit a COMPILED_IN ZONE specification, you must remove the COMPILED-IN keyword to force the ZONE specification to be loaded.
The first of the following examples shows the definition of the normal United States Mountain time zone. The second example, for Arizona, shows the definition of a Mountain time zone that does not observe Daylight Savings Time.
Zone US/Mountain -7:00 US MST MDT COMPILED_IN
Zone US/Arizona -7:00 _ MST
RULE rulename startyear ruletype save start-date end-date
The RULE specification describes a set of rules for determining the times DST is in effect:
• rulename is the name of the RULE specification in ZONE specifications.
• startyear is the year during which this DST rule takes effect. The rule remains in effect until a later startyear is specified in a rule with the name rulename.
• ruletype specifies the type of DST rules. There are three permitted values:
– DST indicates normal Northern Hemisphere Daylight Savings Time rules, which change at the time and date indicated.
– REV_DST indicates normal Southern Hemisphere Daylight Savings Time rules.
– NULL indicates that no Daylight Savings Time is in effect during the specified years.
– save indicates the difference between Standard Time and DST.
• START DATE
• END DATE
The following example illustrates the United States Federal Daylight Savings Time rules:
Rule US 2007 DST 1:00 Sunday >= 8 March 2:00 First Sunday November 2:00
Rule US 1987 DST 1:00 First Sunday April 2:00 Last Sunday October 2:00
Rule US 1976 DST 1:00 Last Sunday April 2:00 Last Sunday October 2:00
Rule US 1975 DST 1:00 23 February 2:00 Last Sunday October 2:00
Rule US 1974 DST 1:00 6 January 2:00 Last Sunday October 2:00
Rule US 1970 DST 1:00 Last Sunday April 2:00 Last Sunday October 2:00
The next table shows the loadable rules provided in the TCPWARE:TIMEZONES.DAT file; you may modify or augment as appropriate for your location.
|
Country Name |
Rule Name |
Time Zone Name |
GMT Offset (hours) |
|
GMT |
GMT |
0 |
|
|
UT |
UT* |
0 |
|
|
US-Military |
US-Military/Z* |
Z |
0 |
|
US-Military |
US-Military/A* |
A |
-1 |
|
US-Military |
US-Military/B* |
B |
-2 |
|
US-Military |
US-Military/C* |
C |
-3 |
|
US-Military |
US-Military/D* |
D |
-4 |
|
US-Military |
US-Military/E* |
E |
-5 |
|
US-Military |
US-Military/F* |
F |
-6 |
|
US-Military |
US-Military/G* |
G |
-7 |
|
US-Military |
US-Military/H* |
H |
-8 |
|
US-Military |
US-Military/I* |
I |
-9 |
|
US-Military |
US-Military/K* |
K |
-10 |
|
US-Military |
US-Military/L* |
L |
-11 |
|
US-Military |
US-Military/M* |
M |
-12 |
|
US-Military |
US-Military/N* |
N |
10 |
|
US-Military |
US-Military/O* |
O |
2 |
|
US-Military |
US-Military/P* |
P |
3 |
|
US-Military |
US-Military/Q* |
Q |
4 |
|
US-Military |
US-Military/R* |
R |
5 |
|
US-Military |
US-Military/S* |
S |
6 |
|
US-Military |
US-Military/T* |
T |
7 |
|
US-Military |
US-Military/U* |
U |
8 |
|
US-Military |
US-Military/V* |
V |
9 |
|
US-Military |
US-Military/W* |
W |
10 |
|
US-Military |
US-Military/X* |
X |
11 |
|
US-Military |
US-Military/Y* |
Y |
12 |
|
US |
US/Eastern* |
EST/EDT |
-5 |
|
US |
US/Central* |
CST/CDT |
-6 |
|
US |
US/Mountain* |
MST/MDT |
-7 |
|
US |
US/Pacific* |
PST/PDT |
-8 |
|
US |
US/Yukon* |
YST/YDT |
-9 |
|
US |
US/Hawaii* |
HST |
-10 |
|
US/East-Indiana |
US/East-Indiana* |
EST |
-5 |
|
US/Arizona |
US/Arizona* |
MST |
-7 |
|
Canada |
Canada/Newfoundland* |
NST/NDT |
-3:30 |
|
Canada |
Canada/Atlantic* |
AST/ADT |
-4 |
|
Canada |
Canada/Eastern |
EST/EDT |
-5 |
|
Canada |
Canada/Central |
CST/CDT |
-6 |
|
Canada |
Canada/Mountain |
MST/MDT |
-7 |
|
Canada |
Canada/Pacific |
PST/PDT |
-8 |
|
Canada |
Canada/Yukon |
YST/YDT |
-9 |
|
Canada |
Canada/Saskatchewan |
CST |
-6 |
|
Israel |
Israel |
IST/IDT |
+2 |
|
Australia |
Australia/Tasmania |
EST/EST |
10 |
|
Australia |
Australia/Queensland |
EST |
10 |
|
Australia |
Australia/North |
CST |
9:30 |
|
Australia |
Australia/West |
WST |
8:00 |
|
Australia |
Australia/South |
CST |
9:30 |
|
Australia |
Australia/Victoria |
EST/EST |
10 |
|
Australia |
Australia/NSW |
EST/EST |
10 |
|
Australia |
Australia/Yancowinna |
CST/CST |
9:30 |
|
Europe |
Britain |
GMT/BST |
0 |
|
Europe |
Europe/Western* |
WET/WET-DST |
0 |
|
Europe |
Europe/Middle* |
MET/MET-DST |
1 |
|
Europe |
Europe/Central* |
CET/CET-DST |
1 |
|
Europe |
Europe/Eastern* |
EET/EET-DST |
2 |
|
Poland |
MET/MET-DST |
2 |
|
|
Turkey |
EET/EET-DST |
3 |
|
|
Japan |
Japan* |
JST |
+9 |
|
Singapore |
Singapore* |
SST |
+8 |
|
New Zealand |
NewZealand* |
NZST/NZDT |
+12 |
* This time zone is compiled in.
The next step is to define your local time zone information (see Example 3-7):
Using CNFNET, you need to specify your local time zone information as it relates to the offset from Universal time. You can choose to either:
• Specify a time zone offset or name as a fixed value that you must set manually for each Daylight Savings Time change. This is the existing method.
• Choose to have the Network Time Protocol (NTP) server change the system clock and time offset automatically according to information you provide. This is a new feature and has been added to the configuration prompts.
If you enter an unknown time zone name, the system prompts you for the Universal time offset for the time zone.
For the offset from Universal time, enter +hhmm or -hhmm, the number of hours (hh) and minutes (mm) offset from Universal time; + is for east and - is for west of the central meridian. Example 3-7 uses an offset for Eastern Standard Time (-0500). Make sure the specification is five characters long, so include any leading and trailing zeros.
The following describes the CNFNET process for configuring the time zone information (see Table 3-7).
Example 3-7 Sample Defining Your Local Time Zone
You need to specify local time zone information. Time zones may be specified as a fixed value, which must be set manually for the Daylight Savings Time change, or you can use the NTP (Network Time Protocol) server to change the system clock and time offset
Do you want to have NTP set the time zone and time offset automatically [N]?
• If you accept the default [N], then the screen displays:
Offset from Universal time in hours and minutes:
+HHMM (east) or -HHMM (west)
Universal time zone: UT, UTC, GMT
North American time zone: EST, EDT, CST, CDT, MST, MDT, PST, PDT
Military time zone: Any single letter A through Z except J
You may enter a non-standard time zone name, although this is discouraged for Internet use. If you use a non-standard name, you are prompted to enter the offset from Universal time as well.
Enter the offset from UT or the local time zone name [UT]: -0500 Return
If you enter an unknown time zone name, you are prompted for the Universal time offset for the time zone.
For the offset from Universal time, enter +HHMM or -HHMM, for the number of hours (HH) and minutes (MM) the time is offset. The + is for east of the Central Meridian and the - is for west of the Central Meridian. Your entry must be five characters long, so include any leading or trailing zeros.
• If you enter Y at the prompt in the first display, the following appears on the screen:
Enter the time zone name and time zone rules (if different from default rules). TCPWARE:TIMEZONE.DAT contains a list of available time zone rules, or local definitions may be defined in TCPWARE.TIMEZONES.LOCAL.
Enter the time zone name: EST
Enter the time zone rule:
When you use CNFNET to configure time zones, you are prompted for information that defines symbols in the TCPWARE_CONFIGURATION.COM file.
• Zone Name
• Time Zone Rule
You can skip the Time Zone Rule prompt when a compiled-in time zone is specified.
Define your local time zone information according to its offset from Universal time. You can either manually change the offset as needed or configure the offset to be done automatically. If you have it done automatically, you need to run NTP.
Enter your local time zone’s offset from Universal time or its symbolic time zone abbreviation. See Table 3-7.
Table 3-7 Symbolic Time Zones (Continued)
|
This time zone... |
Is abbreviated as... |
|
Universal Time |
UT, TUC, or GMT |
|
North American Time |
EST, EDT, CST, CDT, MST, MDT, PST, PDT**Standard "S" times are one hour later than Daylight "D" times; for example, EST is -0500 while EDT is -0400 |
|
Military Time |
Any single uppercase letter A through Z except J (this format not recommended). |
The next step is to define your local host's name (see Example 3-8):
Enter the official host-domain name for your local host. Press Return if the default shown is correct. Make sure you enter the full host-domain name, especially if you plan to use the Domain Name Services.
Define the official host-domain name as other hosts on the network know it. Your hostname defines the TCPWARE_DOMAINNAME logical that the Domain Name Services use to determine the current domain. The Domain Name Services determines the domain by dropping the hostname and dot from the beginning of the entry you make.
The official name of the local host is usually the same as what you specified at the prompt:
What is the HOST NAME for line...
in the Enter Address Information for the Network Devices section. If your network uses domain-name style hostnames, enter the full domain name for your host. Otherwise, enter the full hostname.
Although the hostname is not case-sensitive, TCPware preserves the case as you enter it.
Example 3-8 Sample Defining Your Local Host's Name
You need to enter the official name of this host as it is known locally and by other hosts on the network.
If your system will use Domain Name Services, you must enter the full domain name of the host.
Enter the official host-domain name for this host [NUNKI.NENE.COM]:Return
If you are using the Domain Name Services, continue to the next section, Update the Hosts. File. If you are not using the Domain Name Services, this completes the TCP/IP core configuration. If you need to configure the TCP/IP components, continue to the next chapter.
Ignore this section if you are using the Domain Name Services (DNS).
If you are not using DNS, you need to define a host definition (HOSTS.) file. Some Socket Library routines use this file when looking up hostnames and internet addresses. If you configure TCPware for the first time, TCPware creates the HOSTS. file automatically.
Follow these steps to update the host definition (HOSTS.) file (see Example 3-9):
Note! If this is not a first-time installation, CNFNET may identify that a HOSTS. file already exists and asks if you want to use it or create a new one. The default is NO (do not use the existing file). If you accept this default, a new HOSTS. file is created. Make sure that you properly define these hosts in the file. If you answer Y, the core configuration ends here.
1 The local loopback and the hostname you entered previously become the first entries in the HOSTS. file. Enter the next hostname at the prompt:
Next host name (<return> to end):
2 Enter the Internet address of the hostname.
3 Continue entering hostnames until you define all the hosts and their Internet addresses. Then press Return at the prompt:
Next host name (<return> to end):
Although hostnames are not case-sensitive, TCPware preserves their case as you enter them.
Example 3-9 Creating the HOSTS. File
You can enter the host name and the corresponding internet address for the hosts on the network.
The host definition file, TCPWARE_COMMON:[TCPWARE]HOSTS., contains the host names and internet addresses for the hosts on the network. You may also edit this file manually.
localhost LOOPBACK (127.0.0.1) added to host definition file. NUNKI.NENE.COM (192.168.1.56) added to host definition file.
Next host name (<return> to end): DAISY Return [1]
Internet address for DAISY.NENE.COM: 192.168.1.57 Return [2]
DAISY.NENE.COM (192.168.1.57) added to host definition file.
Next host name (<return> to end): Return [3]
If you need to define additional hostnames later, or correct names already entered, edit the TCPWARE:HOSTS. file directly. The syntax of entries in the file is:
address hostname [alias [alias...]]
If you need to configure TCP/IP components, continue to the next chapter now.
