With profiling enabled, you can compare performance data of when PPE is enabled and disabled. Assuming that you have a test that sufficiently saturates the TCP/IP CPU, complete the following steps to produce data sets that can be easily compared:

1. Enable profiling
   Profiling must be enabled while gathering statistics only. To enable profiling, execute the following:

   $ SYSCONFIG -r INET PROFILING=1

2. Ensure that PPE is disabled by executing the following:

   $ SYSCONFIG -r INET PPE_ENABLE=0

3. Run the stress test and monitor the performance as follows:
   • Using the MONITOR utility
     If the MONITOR utility shows that the TCP/IP CPU is not approaching saturation, enabling PPE will not yield any advantage.

     $ MONITOR MODES/CPU=xx ! xx = TCP/IP CPU

   • Using the TCPMON utility
     Capture the fine-granularity statistics and write them to a comma-separated value (CSV) file as well as display them on to the terminal. The CSV file can later be graphically analyzed using external programs, such as TLViz (from TDC) or a spreadsheet program.

     $ TCPMON /CSV=PPE_COMPARISON.CSV /DISPLAY [/SHOW=INET]

   • Run the Performance Data Collector (TDC)
     TDC provides the complete data set, which provides a whole-system view of performance.
     For more information about TDC, see the Web site at:

     http://h71000.www7.hp.com/openvms/products/tdc/index.html

4. Dynamically enabling PPE
   After collecting sufficient data with PPE disabled, dynamically enable PPE. There is no need to interrupt the data collection methods described in step 3.

   $ SYSCONFIG -r INET PPE_ENABLE=1

5. Comparing the data
   After gathering sufficient data with PPE disabled and enabled, compare the performance characteristics for the given test load. Stop the data collection and examine the data set.
6. Disable profiling
   There is a small overhead associated with profiling. So, it is recommended to disable profiling when statistics is not gathered.

   $ SYSCONFIG -r INET PROFILING=0

FTP Anonymous Light can be used for restricting user access to a particular set of directories. A system administrator who wants to restrict an OpenVMS user's FTP access to a particular set of directories must set the TCPIP$FTP_ANONYMOUS_LIGHT parameter for that user.

Setting this parameter restricts the FTP operations for the user to a set of directories indicted by TCPIP$FTP_ANONYMOUS_DIRECTORIES. The TCPIP$FTP_ANONYMOUS_LIGHT can be defined in LOGIN.COM.

To restrict the FTP access for all users, the parameter must be defined using a system-wide logical. FTP Anonymous Light users must specify the correct password to log in. By default, when an anonymous user is prompted for the identity, any password is accepted. Optionally, the system administrator can also set TCPIP$FTP_ANONYMOUS_WELCOME to display a message upon successful login.

The following example illustrates how FTP Anonymous Light works:

"TCPIP$FTP_ANONYMOUS_DIRECTORY" = "TCPIP$ENETINFO1:[UCX]" = "TCPIP$ENETINFO1:[UCX_AXP]" = "TCPIP$ECO:" = "TCPIP$PATCH:" = "COMMON_SYSDISK:[FAL$SERVER]" = "TCPIP$INTERNAL:" "TCPIP$FTP_ANONYMOUS_LIGHT" = "1" "TCPIP$FTP_ANONYMOUS_LOG" = "SYS$LOGIN:TCPIP$FTP_ANONYMOUS.LOG" "TCPIP$FTP_ANONYMOUS_WELCOME" = "FTP Anonymous Light demo" ftp plane.tcpip.zko.hp.com 220 plane.tcpip.zko.hp.com FTP Server (Version 5.6) Ready. Connected to plane.zko.hp.com. Name (plane.zko.hp.com:test): 331 Username test requires a Password Password: 230-FTP Anonymous Light demo 230 Guest login OK, access restrictions apply. FTP> cd sys$system 550 insufficient privilege or file protection violation (1) FTP> cd tcpip$eco 250-CWD command successful. 250 New default directory is TCPIP$ENETINFO1:[TCPIP$ENGINEERING_CHANGE_ORDERS](2) FTP> cd sys$login 250-CWD command successful. 250 New default directory is WORK4$:[TEST] FTP> bye 221 Goodbye.

Field	Description
(1)	This directory is not included in TCPIP$FTP_ANONYMOUS_DIRECTORY, so access is restricted
(2)	This directory is included in TCPIP$FTP_ANONYMOUS_DIRECTORY, so access is allowed

An output similar to the following is saved in the log file:

20-JUN-2008 05:21:45.64 Anonymous Light User:test from Host:16.116.92.100 20-JUN-2008 05:22:39.61 Anonymous Light User:test status:00010001 CWD dir:TCPIP$ENETINFO1:[TCPIP$ENGINEERING_CHANGE_ORDERS] 20-JUN-2008 05:23:13.49 Anonymous Light User:test status:00010001 CWD dir:WORK4$:[TEST] 20-JUN-2008 05:23:19.15 Anonymous Light User:test status:00000000 RETR file:WORK4$:[TEST]A.TXT;30 20-JUN-2008 05:23:26.07 Anonymous Light User:test logged out

Although the system administrator does not specify the directory, SYS$LOGIN is always added to TCPIP$FTP_ANONYMOUS_DIRECTORY. As a result, the Anonymous Light users will always have access to their SYS$LOGIN.

At some instances, the system administrator may not want the user to access their SYS$LOGIN. To prevent the user from accessing the SYS$LOGIN, the system administrator must define TCPIP$FTP_ANONYMOUS_NOSYSLOGIN for that particular user. This parameter is useful when a user has changed the directory in LOGIN.COM and when the system administrator does not want to grant access to SYS$LOGIN.

1.1.2.1 Access restrictions for FTP operations

The FTP Anonymous Light feature restricts user access to a particular set of directories. To increase the system administrator's flexibility, a new set of parameters can be defined to restrict user operations.

The FTP server checks for the existence of the following four parameters:

• TCPIP$FTPD_NOLIST - LIST and NLST commands
• TCPIP$FTPD_NOREAD - RETR commands
• TCPIP$FTPD_NOWRITE - STOR, STOU, APPE, RNFR, RNTO, DELE, MKD, and RMD commands
• TCPIP$FTPD_NODELETE - DELE and RMD commands

If the parameter is defined, the FTP server will reject all.

These new access restrictions are applicable in addition to any restrictions implied by the protections of the underlying files, directories, volumes, and devices.

If TCPIP$FTPD_NOLIST is defined, the usage of wildcards is not allowed in FTP operations. This is necessary to prevent FTP users from obtaining a list of the files in the directory by attempting to retrieve or delete all the files. Table 1-2 lists the FTP restriction logicals that are used to control their operation:

Table 1-2 FTP restriction logicals

Client command	FTP Logical
Directory	TCPIP$FTPD_NOLIST
View	TCPIP$FTPD_NOREAD
Put	TCPIP$FTPD_NOWRITE
Get	TCPIP$FTPD_NOREAD
Append	TCPIP$FTPD_NOWRITE
Rename	TCPIP$FTPD_NOWRITE
Create	TCPIP$FTPD_NOWRITE
Delete	TCPIP$FTPD_NOWRITE

For example, if the System Administrator does not want a user to delete files through FTP, set TCPIP$FTPD_NODELETE for that user.

The following example illustrates how to set the TCPIP$FTPD_NODELETE and TCPIP$FTPD_NOLIST:

"TCPIP$FTPD_NODELETE" = "1" "TCPIP$FTPD_NOLIST" = "1" $ ftp plane.tcpip.zko.hp.com 220 plane.tcpip.zko.hp.com FTP Server (Version 5.6) Ready. Connected to plane.zko.hp.com. Name (plane.zko.hp.com:test): test 331 Username test requires a Password Password: 230-FTP Anonymous Light demo 230 Guest login OK, access restrictions apply. FTP> directory * 200 PORT command successful. 550 Cannot execute LIST command, Access denied. (1) %TCPIP-E-FTP_NOSUCHFILE, no such file * FTP> delete a.txt 550 Cannot execute DEL command, Access denied.(2) FTP> bye 221 Goodbye.

Field	Description
(1)	The DIRECTORY command is not allowed because a wildcard present in the command and TCPIP$FTPD_NOLIST is defined.
(2)	The DELETE command is not allowed because the TCPIP$FTPD_NODELETE logical is set.

FTP restriction logicals can be used in conjunction with FTP Anonymous Light to restrict user access through FTP, helping to mitigate a risk to the system that has been problematic for system administrators.

1.2 Enhancements

Table 1-3 TCP/IP Services for OpenVMS, Enhancements

Enhancement	Section	Description
TCPIP$CONFIG	1.2.1	Interface Configuration Menu is enhanced.
LPD configurable port	1.2.2	LPR/LPD port can be configured.
FTP over SSL	1.2.3	FTP software is enhanced to use the security features provided by SSL.
SMTP cluster ability	1.2.4	SMTP is made cluster aware.
SMTP ASCII file configuration	1.2.5	Supports the SMTP configurable fields.
SMTP Persistent receiver	1.2.6	The SMTP receiver process is made persistent.
POP ASCII file configuration	1.2.7	Supports the POP configurable fields.
POP server support for external authentication	1.2.8	Supports the POP server for external authentication.

1.2.1 TCPIP$CONFIG

With support for IP as the cluster interconnect (IPCI), Interface Configuration Menu now supports the following:

• Management of interfaces and addresses on another cluster member that shares the same TCPIP$CONFIGURATION database.
• Addresses that can be configured for use with IPCI.

Assuming that the cluster members share the same TCPIP$CONFIGURATION database, each cluster member can be configured from the same console. This only affects the TCPIP$CONFIGURATON database; it is not possible to manage the active addresses on a remote cluster member.

An output similar to the following is displayed for the TCPIP$CONFIG Interface * Address Configuration menu from one of the node in a cluster:

HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu Hostname Details: Configured=kirra-g0, Active=kirra-g0 Configuration options: 0 - Set The Target Node (Current Node: KIRRA) 1 - IE0 Menu (EIA0: TwistedPair 1000mbps) 2 - 19.176.56.100/23 kirra-g0 Configured,Active 3 - 19.176.56.101/23 kirra-g1 Configured,Active-Standby 4 - 19.176.57.100/23 hogwarts-nfs Configured,Active-Standby 5 - 19.176.56.25/23 ns1 Configured,Active-Standby 6 - IE1 Menu (EIB0: TwistedPair 1000mbps) 7 - 19.176.56.101/23 kirra-g1 Configured,Active 8 - 19.176.56.100/23 kirra-g0 Configured,Active-Standby 9 - 19.176.57.100/23 hogwarts-nfs Configured,Active-Standby 10 - 19.176.56.25/23 ns1 Configured,Active-Standby I - Information about your configuration [E] - Exit menu Enter configuration option: 0 (1) Enter name of node to manage [KIRRA]: GRYFFI (2) Enter system device for GRYFFI [$1$DGA62:]: (3) Enter system root for GRYFFI [SYS0]: (4) HP TCP/IP Services for OpenVMS Interface & Address Configuration Menu Hostname Details: Configured=gryffindor-e0 Configuration options: 0 - Set The Target Node (Current Node: GRYFFI - $1$DGA62:[SYS0.]) 1 - IE0 Menu (EIA0: TwistedPair 100mbps) 2 - 19.176.56.65/23 gryffindor-e0 Configured 3 - 19.176.56.81/23 gryffindor-e1 Configured 4 - 19.176.57.100/23 hogwarts-nfs Configured 5 - 19.176.56.25/23 ns1 Configured 6 - IE1 Menu (EIB0: TwistedPair 100mbps) 7 - 19.176.56.81/23 gryffindor-e1 Configured 8 - 19.176.56.65/23 gryffindor-e0 Configured 9 - 19.176.57.100/23 hogwarts-nfs Configured 10 - 19.176.56.25/23 ns1 Configured I - Information about your configuration [E] - Exit menu Enter configuration option:

Field	Description
(1)	If node GRYFFI is another cluster member that shares the same TCPIP$CONFIGURATION database, to manage the interfaces and addresses on node GRYFFI, select option "0".
(2)	Enter the SCSNODE name of the other node in the cluster to manage. In this case, it is GRYFFI.
(3)	To support the management of IPCI, it is necessary to confirm the system root on the remote node. The remote cluster member's system device is determined using SYSMAN.
(4)	The remote clusters member's system root is determined using SYSMAN. The new TCPIP$CONFIG window now displays the configuration on node GRYFFI. Changes to this screen will affect node GRYFFI's permanent TCP/IP configuration only.

1.2.2 LPD configurable port

LPR/LPD provided by TCP/IP services for OpenVMS 5.6 and prior versions connects directly to port 515 on a remote server and sends the data as specified in the RFC 1179. With TCP/IP services for OpenVMS 5.7, this remote port is made configurable. A system manager can choose any ephemeral port.

1.2.2.1 Configuring the remote port

In the printcap file, TCPIP$PRINTCAP.DAT, for each printer entry, a new field, rt is added, which can be used to configure remote port.

For example:

LOOP_BOGUS_P_1|loop_bogus_p_1:\ :lf=/TCPIP$LPD_ROOT/000000/LOOP_BOGUS_P_1.LOG:\ :lp=LOOP_BOGUS_P_1:\ :rm=qtvtcp.digitalindiasw.net:\ :rp=bogus_p_1:\ :rt#2333:\ :sd=/TCPIP$LPD_ROOT/LOOP_BOGUS_P_1:

1.2.2.2 Using the LPD configurable port for secure printing

Using the rt field in the printer entry in TCPIP$PRINTCAP.DAT, the LPD jobs is sent over an SSH encrypted tunnel. You can configure SSH port forwarding to establish a tunnel from port (rt) on a system to an LPD receiver port (default is 515 or any other port on which LPD service is configured manually) on another system where the LPD receiver is listening. For sample LPD/LPR configurations, see Appendix A.

1.2.3 FTP over SSL

The Transport Layer Security/Secure Socket Layer (TLS/SSL) feature enables the FTP software to use the security features provided by SSL. When this feature is enabled, FTP provides a secured FTP session and a secure file transfer. FTP over SSL is compliant with RFC 4217 and RFC 2228.

1.2.3.1 Configuring an FTP server for SSL

To configure an FTP server and to allow the FTP server to handle incoming client connections which are over SSL, the certificates and keys must be copied at the following location:

Certificate file : SSL$CERTS:SERVER.CRT Key file: SSL$KEYS:SERVER.KEY

The key and certificate file of the server must be placed in this directory and must be named as SERVER.CRT and SERVER.KEY. During the FTP server startup, if it does not find either the key or the certificate file in the required location, the FTP server will not support SSL.

1.2.3.2 Using FTP client in an SSL environment

You can use FTP over SSL to connect to the server by invoking the client using the following commands:

$FTP /SSL <server>

Or

$FTP FTP> CONNECT /SSL <server>

If you connect to the server using the /SSL qualifier, both the control and data connection use SSL by default. By default, the PROT P command is sent by the client to the server indicating that the data connection will use SSL.

If you want the data connection communication to happen in clear text, you can issue the PROT C command on the FTP client CLI.

ftp> PROT C

The OpenVMS FTP client and server also supports the Clear Command Channel (CCC) mode of operation. The CCC mode can be used in NAT environments that need a clear command channel to setup NAT for FTP/SSL. An FTP Client issues the CCC command to indicate to the server that the command channel must not be encrypted. Note that the data channel will remain encrypted. As a result, the file transfer will continue to be secured by SSL.

For example, if you want the control connection to not be encrypted, execute the CCC command at the FTP client CLI:

ftp> CCC

If you want to use the copy operation in FTP, COPY/FTP , the syntax is as follows:

copy /ftp/ssl=(data,ccc) <src system> <dst system>

If you do not want the data connection to be encrypted, specify NODATA in the preceding command instead of DATA.

If you want CCC (by default), specify CCC , else specify NOCCC .

1.2.3.3 Considerations during configuration

• If the server does not find the SEREVER.CRT and SERVER.KEY, the server will not accept the AUTH TLS command. However, the server will continue to accept regular FTP connections.
  An SSL enabled client will still be able to connect to non-SSL enabled server and displays the following message:

  AUTH command will fail, session will continue in plain text.

• A non-SSL enabled client will be able to login to SSL enabled server.

SMTP provided by TCP/IP Services for OpenVMS is cluster aware. It exploits the high availability and load balancing features of a cluster. The name of the generic queue is now TCPIP$SMTP, without the node name as the suffix. This is a common SMTP generic queue for all nodes in the cluster.

1.2.4.1 Configuration

The following configurable parameters can be found in the TCPIP$SMTP.CONF file:

• Number-Of-Queues-Per-Node: Specifies the number of execution SMTP queues created on each node of a cluster. The default value is 1. The execution queue will have the name format as follows:

  TCPIP$SMTP_<emphasis>(<nodename>_<n>)

• Queue-name: Specifies the name of generic SMTP queue. The default is TCPIP$SMTP.

TCPIP$SMTP.CONF can also be used to configure the trace and debug parameters, but the precedence will be changed.

The existing configuration based on logical names and TCPIP> SET CONFIGURATION SMTP is obsolete. The SMTP rollover tool, TCPIP$SMTP_V57_ROLLOVER.EXE, can be used to upgrade the TCP/IP software to Version 5.7. Up on upgrade, the SMTP startup procedure will automatically change over to new ASCII file based configuration method. It creates the TCPIP$SMTP.CONF file in the TCPIP$SMTP_COMMON directory. Up on successful rollover, SYS$MANAGER:TCPIP$SMTP_V57_ROLLOVER.FLG is created.

Include the appropriate SMTP parameters in this file. The configuration template file, TCPIP$SMTP.CONF_TEMPLATE, contains the description of all SMTP configurable parameters and its usage.