HP OpenVMS Version 8.3 New Features and Documentation Overview


Previous Contents Index

5.10 HP SSL for OpenVMS

Secure Sockets Layer (SSL) is the open standard security protocol for the secure transfer of sensitive information over the Internet. HP SSL Version 1.3 is based on OpenSSL 0.9.7e. (The previous version of HP SSL was based on OpenSSL 0.9.7d.)

Support for HP SSL is provided on OpenVMS I64, OpenVMS Alpha, and OpenVMS VAX.

HP SSL Version 1.3 is now included in the OpenVMS operating system as a SIP (system integrated product) instead of as a layered product. Version 1.3 also includes the bug fixes included in OpenSSL 0.9.7e. These features are described in the following list:

HP SSL addresses these three fundamental security concerns about communication over the Internet and other TCP/IP networks:

For more detailed information, refer to HP Open Source Security for OpenVMS, Volume 2: HP SSL for OpenVMS.

For information about downloading the latest version of HP SSL for OpenVMS, see the following Web site:

http://h71000.www7.hp.com/openvms/products/ssl/

For additional information about OpenSSL, see the OpenSSL Web site at the following location:

http://www.openssl.org/

5.11 System Services New Information and New Item Codes

New item codes have been added for several system services. More information about some item codes has been added as well. These topics are discussed in the following sections.

5.11.1 $GETDVI: New Item Codes and Item Code Information

OpenVMS Version 8.3 contains the new item codes and item code information described in the following sections.

5.11.1.1 New $GETDVI Item Codes

New $GETDVI item codes are the following:


DVI$_DEVICE_MAX_IO_SIZE 
DVI$_FC_HBA_FIRMWARE_REV 
DVI$_LAN_ALL_MULTICAST_MODE 
DVI$_LAN_AUTONEG_ENABLED 
DVI$_LAN_DEFAULT_MAC_ADDRESS 
DVI$_LAN_FULL_DUPLEX 
DVI$_LAN_JUMBO_FRAMES_ENABLED 
DVI$_LAN_LINK_STATE_VALID 
DVI$_LAN_LINK_UP 
DVI$_LAN_MAC_ADDRESS 
DVI$_LAN_PROMISCUOUS_MODE 
DVI$_LAN_PROTOCOL_NAME 
DVI$_LAN_PROTOCOL_TYPE 
DVI$_LAN_SPEED 
DVI$_MAILBOX_BUFFER_QUOTA 
DVI$_MAILBOX_INITIAL_QUOTA 
DVI$_PREFERRED_CPU_BITMAP 
DVI$_VOLUME_PENDING_WRITE_ERR 
DVI$_VOLUME_RETAIN_MAX 
DVI$_VOLUME_RETAIN_MIN 
DVI$_VOLUME_SPOOLED_DEV_CNT 
DVI$_VOLUME_WINDOW 

5.11.1.2 $GETDVI Item Code Information

For item codes that return a string data type, failure to pass in a buffer that is large enough to hold the returned data results in silent data truncation. When $GETDVI completes, HP recommends that you check the returned length field of an item list descriptor for each item code that can return a string.

If the returned length is equal to the size of the buffer allocated to hold the returned data, the data might have been truncated. In that case, call $GETDVI iteratively with a larger buffer until the length of the returned data is less than the size of the buffer allocated.

Unless the description of an item code specifies otherwise, HP recommends that you use a buffer of 32 bytes to hold the returned string. $GETDVI pads the unused portion of the buffer with null characters.

5.11.2 $GETJPI New Item Code

The $GETJPI system service contains the new JPI$_DEADLOCK_WAIT item code.

5.11.3 $GETSYI New Item Codes

The $GETSYI system service contains the following new item codes:


SYS$_ACTIVE_CPU_BITMAP 
SYI$_AVAIL_CPU_MASk 
SYI$_BOOT_DEVICE 
SYI$_IO_PRCPU_BITMAP 
SYI$_POWERED_CPU_BITMAP 

5.11.4 $GETDVI, $GETJPI, $GETLKI, $GETQUI, and $GETSYI Service Information

HP strongly recommends the use of the EFN$C_ENF "no event flag" value as the event flag if you are not using an event flag to externally synchronize with the completion of this system service call. The $EFNDEF macro defines EFN$C_ENF. For more information, see the HP OpenVMS Programming Concepts Manual.

5.11.5 $GETUAI New Item Codes

The $GETUAI system service contains the following new item codes:


UAI$V_DISPWDSYNCH 
UAI$V_VMSAUTH 

5.11.6 Additional Changes to System Services

Entries have been added or changed in $IO_FASTPATH and $PROCESS_AFFINITY related to the new CPU namespace project. Other additions and changes have been made to $SET_PROCESS_PROPERTIESW related to system service logging.

For more detailed information, see the HP OpenVMS System Services Reference Manual.

5.12 Traceback Facility

A callable interface that symbolizes program locations now exists on both OpenVMS Alpha and OpenVMS for Integrity servers. Previously, this interface was only available on OpenVMS for Integrity servers.

On Alpha systems, the new interface is called TBK$ALPHA_SYMBOLIZE, which is similar to the TBK$I64_SYMBOLIZE routine on Integrity server systems.

The Integrity server routine interface (TBK$I64_SYMBOLIZE) has changed from the previous release to match the Alpha routine interface (TBK$ALPHA_SYMBOLIZE) available in this release. This change is backwards-compatible; that is, the former interface is no longer documented but is supported for programs that currently use it.

Both interfaces support callers in USER, SUPER and EXEC mode. Previously on OpenVMS for Integrity servers, only USER mode callers were supported.

For complete information on the Traceback symbolize routines for Integrity servers and Alpha, see the HP OpenVMS Utility Routines Manual.


Chapter 6
InfoServer Utility

This chapter provides a description of the InfoServer utility feature now supported on OpenVMS Alpha as well as OpenVMS for Integrity servers. This chapter includes a comparison between the InfoServer hardware and InfoServer application and a reference for the InfoServer utility commands.

6.1 InfoServer Utility Overview

The InfoServer application allows you to create a service for a virtual disk device on the local area network.

Virtual disk devices include the following:

Comparison of InfoServer Hardware and the InfoServer Application

The new InfoServer application on OpenVMS differs from previous InfoServer hardware in a number of important ways. Some of the most notable are the following:

6.1.1 InfoServer Usage Summary

You can use the InfoServer utility commands to do the following:

You can invoke the InfoServer in the following ways:

Note

All InfoServer commands require SYSPRV and OPER privileges.

To exit the InfoServer utility, enter the EXIT command at the InfoServer> prompt or press Ctrl/Z.

For information about the InfoServer utility, enter the HELP command at the InfoServer> prompt.

6.1.2 InfoServer Commands

The following sections describe and provide examples of InfoServer commands.

CREATE SERVICE

Creates a service for a specified device or partition.

Usage rules:


Format

CREATE SERVICE serviceName device-or-partitionName


Parameter

serviceName

The name by which the service is known to the local area network. The service name can consist of alphanumeric characters and dollar signs ($). It can be 255 characters or fewer in length.

device-or-partitionName

The device or partition name is the name of the OpenVMS disk device or partition as it is to be known to the local area network. The name of the device or partition that you enter must have been created previously.

Explanations of device and partition names follow.


Qualifiers

/CLASS=className

Specifies a subset of the complete LASTport Disk (LAD) name space.

The purpose of class names is to subdivide name spaces so that clients see only those names that are meaningful to them. The use of class names also allows two services to have the same name and not conflict with one another.

For example, you can use different class names for different on-disk structures that several client systems use. You might use SERVICEA/CLASS=ODS-2 for some client systems and SERVICEA/CLASS=ISO_9660 for other client systems. The service has the same name (SERVICEA), but the class names are different.

The class name you use depends on the client systems that will connect to the service being created. The default class name is ODS_2. For example, OpenVMS systems use the ODS_2 name space when attempting to mount an InfoServer device. Note that OpenVMS clients can solicit only those services that are in the ODS_2 service class.

Valid class names are the following:


           V2.0           Names understood by PCSA MS-DOS Clients 
           Unformatted    Virtual disk has no format 
           MSDOS          MSDOS virtual disks 
           ODS_2          VMS virtual disks 
           UNIX           UNIX virtual disks 
           ISO_9660       ISO 9660 CD format 
           HIGH_SIERRA    MS-DOS CD format 
           APPLE          Macintosh HFS format 
           SUN            Sun format 

/ENCODED_PASSWORD=hexstring

The SAVE command creates this qualifier. Because passwords are not stored in plain text, the hashed password value is written out as part of the SAVE operation so that the service can be recreated without revealing the password.

Note that if you edit the command procedure that the SAVE command creates and change the service name, the encoded password value is no longer valid. You need to set another password on the service using the /PASSWORD qualifier.

/PASSWORD=passwordString

/NOPASSWORD (default)

Specifies an optional service access control password. The client system must specify the password to access the service.

The password string can be up to 39 alphanumeric ASCII characters in length. If no password is specified, the client system is not required to provide a password to access the service.

The text password is hashed and stored in encrypted form in memory with the other service information.

/RATING=DYNAMIC

/RATING=STATIC=value

Clients use the service rating to select a service in the case of multiple matching services. The service with the highest service rating is selected.

The system adjusts the dynamic service rating based on load. You can also set a static rating between 0 and 65535. The system does not adjust static ratings.

One use of static ratings is to migrate clients from one copy of a service to another. If you set a static rating of 0 on services you want to migrate clients away from, no new clients will connect to a 0-rated service; instead, they will connect to higher-rated services. When all current clients have disconnected from a service, you can safely delete it.

/READAHEAD (default)

/NOREADAHEAD

When a disk read is required to fill a cache block, the /READAHEAD qualifier specifies that the read is to be from the first block requested to the end of the bucket boundary. Readahead can speed up sequential operations by preloading disk blocks that are needed into the cache.

If you specify both the /READAHEAD and the /READBEHIND qualifiers, any block requested within a cache bucket causes the entire bucket range of blocks to be read into the cache.

/READBEHIND

/NOREADBEHIND (default)

When a disk read is required to fill a cache block, the /READBEHIND qualifier specifies that the read is to include all blocks from the beginning of the cache bucket boundary up to and including the requested blocks.

If you specify both the /READAHEAD and the /READBEHIND qualifiers, any block requested within a cache bucket causes the entire bucket range of blocks to be read into the cache.

/READERS=number (default is READERS=1000)

/NOREADERS

Specifies the maximum number of simultaneous client connections allowed for read access. The default is 1000 readers. A value of 0 indicates write-only access.

If a client requests read-only or read/write access to a service, the system counts this as one reader.

/WRITERS

/NOWRITERS (default)

Specifies that the service is to allow access to a single writer.

Examples

#1

$ SHOW DEVICE MOVMAN$DQA0:/full
 
Disk MOVMAN$DQA0:, device type Compaq  CRD-8322B, is online, file-oriented 
    device, shareable, served to cluster via MSCP Server, error logging is 
    enabled. 
 
 Error count                 0    Operations completed 
 Owner process              ""    Owner UIC                  [SYSTEM] 
 Owner process ID     00000000    Dev Prot        S:RWPL,O:RWPL,G:R,W 
 Reference count             0    Default buffer size             512 
 Total blocks         16515072    Sectors per track                63 
 Total cylinders         16384    Tracks per cylinder              16
 

$ MOUNT/SYSTEM dqa0 OVMSIPS11 Volume is write locked OVMSIPS11 mounted on _MOVMAN$DQA0: $ InfoServer InfoServer> CREATE SERVICE VMS_SIPS_V11 _MOVMAN$DQA0: %INFOSRVR-I-CRESERV, service VMS_SIPS_V11 [ODS-2] created for _MOVMAN$DQA0:.

This example shows how to create a service for a CD device:

#2

$ LD CREATE KIT1/SIZE-100000
$ DIRECTORY KIT1
Directory DKB0:[DISKS] 
 
KIT1.DSK;1       100000/100008   29-APR-2005 14:14:43.49 
 
Total of 1 file, 100000/100008 blocks.
$ LD CONNECT KIT1
%LD-I-UNIT, Allocated device is MOVMAN$LDA1:
 $ CREATE SERVICE TEST_KIT_1 MOVMAN$LDA1:
%INFOSRVR-I-CRESERV, service TEST_KIT_1 [ODS-2] created for 
 _MOVMAN$LDA1:
 
 
      

This example shows how to create a service for a logical disk (LD) device:

DELETE SERVICE

Deletes one or more services.

Format

DELETE SERVICE serviceName [device-or-partitionName]


Parameters

serviceName

The name by which the service is known to the local area network. The service name can consists of alphanumeric characters and dollar signs ($). It can be up to and include 255 characters. Wildcards are permitted.

In the InfoServer utility, wildcards, where supported, are those used in OpenVMS. The percent (%) character matches exactly one character. The asterisk (*) character matches zero or more characters.

device-or-partitionName

The device or partition name is the name of the OpenVMS disk device or partition as it is to be known to the local area network. The name of the device or partition that you enter must have been created previously.

Explanations of device and partition names follow.


Qualifiers

/CLASS=className

Specifies a subset of the complete LASTport Disk (LAD) name space.

The purpose of class names is to subdivide name spaces so that clients see only those names that are meaningful to them. The use of class names also allows two services to have the same name and not conflict with one another.

For example, you can use different class names for different on-disk structures that several client systems use. You might use SERVICEA/CLASS=ODS-2 for some client systems and SERVICEA/CLASS=ISO_9660 for other client systems. The service has the same name, SERVICEA, but the class names are different.

The class name you use depends upon the client systems that will connect to the service being created. The default class name is ODS_2. For example, OpenVMS systems use the ODS_2 name space when attempting to mount an InfoServer device. Note that OpenVMS clients can solicit only those services that are in the ODS_2 service class.

Valid class names are the following:


           V2.0           Names understood by PCSA MS-DOS Clients 
           Unformatted    Virtual disk has no format 
           MSDOS          MSDOS virtual disks 
           ODS_2          VMS virtual disks 
           UNIX           UNIX virtual disks 
           ISO_9660       ISO 9660 CD format 
           HIGH_SIERRA    MS-DOS CD format 
           APPLE          Macintosh HFS format 
           SUN            Sun format 

/CONFIRM (default)

/NOCONFIRM

Confirm the deletion of a service. If there are any connections, even though /NOCONFIRM has been entered, the system forces a confirmation.

Controls whether a request is issued before each delete operation to confirm that the operation should be performed on that service. The following responses are valid:


 
       YES      NO       QUIT 
       TRUE     FALSE    Ctrl/Z 
       1        0        ALL 
           Return (key) 

Usage notes:

/DISCONNECT

/NODISCONNECT (default)

Overrides the default prompting for confirmation if you attempt to delete a service that has sessions connected to it. If a service has connected sessions and the /DISCONNECT qualifier is not supplied, you are prompted to confirm service deletion.

To delete services without being prompted at all, specify both the /NOCONFIRM and /DISCONNECT qualifiers.


Example


$ SHOW SERVICES
Service Name         [Service Class] Device or File 
-------------------- --------------- -------------------------- 
HUDSON               [ODS-2]         _MOVERS$LDA1: [ 1 Connection] 
BAFFIN               [ODS-2]         _MOVERS$LDA1: 
FUNDY                [ODS-2]         _MOVERS$LDA1: 
3 services found.
 
$ DELETE SERVICE HUDSON
Service HUDSON has 1 session connected! 
Delete service HUDSON [ODS-2] for _MOVERS$LDA1:? [N]:
 
 
      

The first command displays three services, including one session connection. The second command deletes the HUDSON service. It displays messages indicating that HUDSON had one session connected and that this service has been deleted.


Previous Next Contents Index