5 Configuring Oracle Net Services

This chapter provides conceptual and configuration information about Oracle Net Services in the HP OpenVMS environment.

See Also:

Oracle Database Net Services Administrator's Guide for detailed information about Oracle Net Services architecture

It contains the following topics:

5.1 Oracle Net Services Configuration Overview

Oracle Net Services is a communications software product that enables you to create a data management environment to share information stored in Oracle Database installations. Oracle Net Services uses the communications protocols supported by various operating systems to provide a distributed processing and distributed database environment for Oracle. Oracle Net Services also refers to a set of products or adapters that support industry-standard protocols such as TCP/IP.

An Oracle Database management system can be configured in one of the following ways:

5.1.1 Centralized Configuration

In a centralized configuration, Oracle Database and Oracle Database Client are located on the same system. This system is not necessarily on a network, and you can access the application through terminals. If you use a centralized configuration, then you can use a simple Oracle Net Services adapter called the Bequeath adapter, which requires no Oracle Net Services configuration. However, if you want to use Oracle Shared Servers, then you must configure Oracle Net Services even in centralized configurations.

5.1.2 Client/Server Configuration

In a client/server configuration, Oracle Database resides on a multitasking server system, and the client side of the applications resides on another computer, such as a workstation or personal computer. The client and server are connected by a physical network and communicate through a network protocol such as TCP/IP. In a client/server environment, the Oracle application built with an application development tool makes database requests to the server over the network.

5.1.3 Distributed Database Configuration

In a distributed database configuration, users query separate databases as a single database. The major advantage of a distributed database is that users and applications are not required to know where the data resides. You can query database tables by name, regardless of how the network protocols work together to access the required remote database containing the table. Therefore, Oracle Net Services users can communicate and share database information stored in different locations, on different computers, with different operating systems. Distributed databases enable local administration of data and can reduce network traffic if the data that is accessed most often at a location can be stored locally.

Oracle Net Services allows the client and the server to communicate over a variety of media and protocols. A client/server configuration allows DBAs to distribute CPU-intensive user interfaces to low-cost workstations. It also allows application users to be greeted with the graphical user interface (GUI) with which they are most familiar.

5.2 Oracle Net Services Installation

When you install Oracle Net Services on HP OpenVMS, the following protocol adapters are automatically installed:

  • TCP/IP

  • Bequeath

  • IPC

  • TCPS

See Also:

5.3 Oracle Net Services and TNS

Oracle Net Services connects dissimilar networks together and enables client/server transactions to be conducted transparently. A user does not have to know that a network exists, because Oracle Net Services hides the complexity of system-level interactions by presenting a layer of interconnectivity to the user through its client/server architecture. This layer is called Transparent Network Substrate (TNS).

The transaction proceeds as follows:

  1. The client sends a request for data.

  2. Oracle Net Services packages the request and sends it to the TNS.

  3. TNS routes the packaged request to the server.

  4. Oracle Net Services on the server side unpackages the request and sends it to Oracle Database 10g.

  5. Oracle Database 10g processes the request and sends the requested data to Oracle Net Services.

  6. Oracle Net Services packages the data and sends it to TNS.

  7. TNS routes the data to the client.

  8. Oracle Net Services on the client side unpackages the data and sends it to the application.

5.4 Protocol Adapters


This section supplements the information given in Oracle Database Net Services Administrator's Guide.

This section gives information about the following protocol adapters on HP OpenVMS:

5.4.1 IPC-Mailbox Protocol

The Mailbox protocol adapter, or IPC adapter, is automatically configured for use when you install Oracle Net Services. It can be used for client/server connections when both client and server are on the same HP OpenVMS node. If the client and server are on different systems, then the connection must take place using TCP/IP.

When configuring the TNS listener to listen for mailbox connections, you must specify a KEY value in the LISTENER.ORA file for the IPC protocol. The listener then creates a mailbox. This mailbox listens for connections and creates a systemwide logical name (the same as the KEY value) that translates to this mailbox device. It is through this logical name that clients find the mailbox of the listener.

The Oracle Shared Server must be configured to use only TCP/IP protocol. The IPC protocol cannot be used here.


The following fields must be defined:

(KEY=IPC logical name)


PROTOCOL is the keyword that identifies the specific protocol adapter used. For this protocol, the value is IPC. The value can be entered in either uppercase or lowercase, and

KEY is the logical name used to connect to the listener through the Mailbox adapter.


This example shows the two fields for the HP OpenVMS Mailbox adapter.


5.4.2 TCP/IP Protocol

The TCP/IP protocol adapter provides support for client/server connections using TCP/IP as a protocol. You can turn Oracle Net Services support for TCP/IP on or off by using the options available on the NetConfig configuration screen.

Oracle Net Services on HP OpenVMS is developed and certified by using the Hewlett-Packard TCP/IP Services for HP OpenVMS, which is also known as UCX. If you want to use the TCP/IP protocol adapter for Oracle Net Services, then you should have version 5.5 - ECO 1, or later, TCP/IP Services for HP OpenVMS installed. TCP/IP protocol stacks from other vendors may work with Oracle, but customers use these products at their own risk. Any TCP/IP problems that cannot be reproduced by using TCP/IP Services for HP OpenVMS should be referred to the TCP/IP vendor.


The following fields must be defined:


The following field is optional:


In the preceding syntax:

  • PROTOCOL is the keyword that identifies the specific protocol adapter used.

    For this protocol, the value is TCP. The value can be entered in either uppercase or lowercase.

  • HOST is the host name or IP address.

  • PORT# is the TCP/IP port number.

  • Queuesize is the parameter that increases the queue size. This parameter is optional. If it is not specified, then the default value is 20. If simultaneous connections are made to the listener, then some connection requests may not be received if the listener socket queue size is too small

Example In this example, the TCP/IP connect descriptor specifies a listener on the ALPHA1 host.


5.4.3 BEQ-Bequeath Protocol

Each database that you want to connect with the Bequeath protocol adapter must have a command file named ORASRV_BEQ_sid.COM in ORA_ROOT:[NETWORK.ADMIN]. If you used Oracle Database Configuration Assistant to create the database, or if you upgraded the database, then this file is automatically created. However, if you manually created the database, or if you must re-create this file for any reason, then you must create this command procedure manually by executing ORA_NETWORK:CREATE_ORASRV_BEQ.COM.

5.4.4 Bequeath Listener

On HP OpenVMS, the Bequeath listener is used as a default to provide dedicated server connections for a local client. The Bequeath listener, running as a detached process, creates detached server processes to service clients on the same system by using the Bequeath adapter. This allows Oracle Database to run in a suitably privileged process.

For each request from the client, the Bequeath listener creates a detached server process and two mailboxes. It then sends the mailbox names to the client, and the client establishes a connection to the server using these mailboxes.

By default, these mailboxes are created with a buffer quota of 8192 bytes and a maximum message size of 2048 bytes. You can change these parameters by defining logical names in the ORASRV_BEQ_SID.com file with other values. For example:

$ define ORA_BEQ_MBXSIZ n 
$ define ORA_BEQ_MBXBFQ n 

The maximum value for the mailbox buffer quotas is 60000 bytes. You should adjust these values carefully, and you should adjust them for performance reasons only.

The Bequeath listener uses a known mailbox name to listen for client requests. This mailbox name is in the format:



xxxxxxxxxx is the Oracle install ID unique to the system (padded with zeroes).

n is a single-digit number (0-9) that is the Bequeath listener number.

This section contains the following topics: Starting Up the Bequeath Listener

The Bequeath listener starts automatically when the INSORACLE command procedure is run, usually at installation time or during system startup. Unless you decide to run the REMORACLE command, the Bequeath listener should be up and running all the time.

If the Bequeath listener is down and you want to start it, then run the following command:


If you do not provide the optional numeric parameter, then Bequeath listener 0 is started. To start additional Bequeath listeners, provide the listener number when you run the command. Determining the Status of the Bequeath Listener

You can run a status command to determine if the Bequeath listener is up and running. Run the following command:


If you do not provide the optional numeric parameter, then Bequeath listener 0 is queried. To determine the status of any other Bequeath listeners, provide the listener number when you run the command. Shutting Down the Bequeath Listener

To stop the Bequeath listener, run the following command:


If you do not provide the optional numeric parameter, then all Bequeath listeners for the installation are stopped. To stop a particular Bequeath listener, provide its number at the command line. Problem Resolution

This section details the steps that you can take to resolve problems with a Bequeath listener.

Collecting Bequeath Client Trace Information:

  1. Look for a file in ORA_ROOT:[network.log]BEQ_sid_pid.LOG that corresponds to the time of a client connect/disconnect issue.

  2. Make file available to Oracle Support.

Writing Trace Information

The Bequeath listener writes some trace information. Because the output of the detached processes is set to the null device (NL:), usually, you will not see it.

To get the trace information from the Bequeath listener:

  1. Stop the Bequeath listener.


  3. Change NL: to a file name.

  4. Restart the Bequeath listener.

Changing the Quota for a Server Process That is Created by the Bequeath Listener

To change the process quotas, modify the BEQLSNR.COM file and remove the comment characters for the quota parameter that you want to change. You must stop and then restart the Bequeath listener after modifying this file.

For all ORA-12203 Problems

Ensure that after starting the Bequeath listener, the HP OpenVMS logical name ORA_BEQ has the correct install id as part of its value.

Example (with the Bequeath listener running):

$type ora_rootdir:install.id
$show log *beq*
"ORA_BEQ" = "519462874"
"ORA_BEQ_READ_MBX_519462874_0" = "MBA3737:"

Problem: ORA-12203: TNS: unable to connect to destination

If you experience this problem, then run the BEQLSNR STATUS command to determine if the Bequeath listener is up and running. If the Bequeath listener does not respond, then run the BEQLSNR STOP command to stop the Bequeath listener and run the BEQLSNR START command to restart it.


Contact Oracle Support if the Bequeath listener does not respond, even after restarting it.

Client Problem: ORA-12203: TNS: unable to connect to destination

Use one of the following solutions:

  • Change the ORA_BEQ_TIMEOUT logical name to something greater than 120 seconds. Before running the client program, you must define this logical name in the ORA_NETWORK:BEQLSNR.COM file.

  • Define the ORA_BEQ_NUM_OF_LISTENERS logical name to a value between 1 and 10 to increase the capacity, when a number of clients are connecting at the same time to the Bequeath listener.This is the number of Bequeath listener that you must run.

With this method, you can increase the number of connections that the Bequeath listeners can handle concurrently. Each time that a client requests a connection, it randomly picks one of the Bequeath listeners that run to serve it with the connection request. You do not need to stop and restart the Bequeath listener after defining this logical name. This logical name determines the number of Bequeath listeners. However, you must start explicitly each Bequeath listener by running the following command:


In this command, n is an integer that starts from 1 for the first listener and goes up to the value of the ORA_BEQ_NUM_OF_LISTENERS logical name. Bequeath Listener Privileges

The Bequeath listener must have the HP OpenVMS privileges listed in Table 5-1 to be able to perform the associated functions listed in the table.


Before attempting to start the Bequeath listener or the TNS listener, the process that starts the Bequeath listener must have the privileges listed in Table 5-1 or be able to have them set. Refer to Section 5.5.2, "TNS Listener Privileges" for more information about setting TNS listener privileges.

Table 5-1 describes the HP Open VMS privileges and functions of Bequeath TNS listeners.

Table 5-1 Privileges and Functions of Bequeath TNS Listeners

Privilege Function


Pass this privilege to server processes that the listener creates.


Create detached processes.


Perform certain I/O functions.


Create a permanent mailbox on which to listen. (The mailbox is permanent so that the logical name associated with it goes into the SYSTEM logical name table.)


Lock systemwide resources.


Create SYSTEM logical names and shared logical name tables.


May assign channels to nonshared devices.


Create temporary mailboxes.


Enable the listener to get information about and to control processes that it may not have created, such as dispatchers and shared server processes.

5.5 TNS Listener

The function of the TNS listener is to receive connection requests from local or remote clients and to provide the client with a server process to which the client can connect. The listener can service multiple instances. For each instance, the listener keeps a list of services that provide access to that instance. If multithreaded servers are being used, then the listener may direct a client connection to a dispatcher. Otherwise, for dedicated servers, the listener directs the client connection to an existing Oracle Shared Server or creates a new server process to service the connection.

In Oracle Database 10g, there is a major change in the way the listener is configured for Oracle Shared Servers. The Oracle Shared Server parameters are not the same as in Oracle8i. When you configure for Oracle Shared Server, a request for a dedicated server is no longer handled using the parameters from the LISTENER.ORA file. This now happens as part of the dispatcher registration. The PMON process registers dispatchers with the listener for Oracle Shared Server connections.


The SID_LIST_listener section is no longer used to establish dedicated server connections. These are now automatically handled by the listener, which directly uses the ORA_ROOT:[NETWORK.ADMIN]ORASRV_NETV2_sid.COM script to launch the dedicated server process. This script is automatically created when a new database or instance is created through Oracle Database Configuration Assistant or scripts provided by Oracle Database Configuration Assistant.

Generic information about the TNS listener and its configuration can be found in the generic Oracle Net Services documentation. This section provides information only about the TNS listener that is specific to HP OpenVMS.

This section contains information about the following topics:


The LSNRCTL utility is used to start and stop the TNS listener and to query its status or services. The LSNRCTL command runs the command procedure ORA_NETCONFIG:LSNRCTL.COM, which provides a shell to the executable program ORA_ROOT:[BIN]LSNRCTL.EXE.

The main function of the command procedure is to check that the privileges required to start the TNS listener are present. These privileges are covered in the following section. If a LSNRCTL START command is entered and the required privileges are not present, then an error message is displayed and LSNRCTL exits.


Start the TNS listener from the Oracle Account.


If you enter the LSNRCTL interactive mode by giving the LSNRCTL command without a subcommand, and you have received a warning about inadequate privileges, then do not attempt to start the listener. Depending on the privileges you have, although the listener process may start, it may not function properly.

Do not start the listener from a process that has a User Identification Code (UIC) in the system group, for example, a group less than or equal to MAXSYSGROUP. If you enter a LSNRCTL START command from such a process, then an error message is displayed and LSNRCTL exits. If you enter a LSNRCTL command with no arguments, then you are warned not to start the listener from within the LSNRCTL utility. If the listener is running in a system group, then any server processes it creates will be in the system group. The server is shut down, because it does not let itself run in privileged groups.

On HP OpenVMS, the Oracle Shared Server must be configured to use only TCP/IP protocol.

5.5.2 TNS Listener Privileges

The process in which the TNS listener runs must have the HP OpenVMS privileges listed in Table 5-1 to be able to perform the associated function.


Before attempting to start the TNS listener, the process that starts the listener must have the privileges in Table 5-1 or be able to have them set. As noted in the preceding section, the LSNRCTL command attempts to set these privileges and warns the user if it was unable to do so.

5.5.3 Process Quotas

Process quotas for the TNS listener and for the server processes created by the TNS listener can be controlled by logical names. The format of the logical name is:


In this format, quotaname can be one of the following:















Several of the logical names are defined in the LSNRCTL.COM file and control the quotas of the TNS listener process. They are defined in user mode so that they are not present after exiting LSNRCTL. If the TNS listener supports an especially large number of services, then some of these quotas may need to be increased. For the quotas you determine to be deficient, or at the direction of Oracle Support Services, you can edit the quota values in the LSNRCTL.COM file.

To control the quotas of the processes that the TNS listener creates, specify the logical names in the ORA_NETWORK:TNSLSNR.COM file. This is the command file that runs in the TNS listener process. Statements to define these logical names are in the TNSLSNR.COM file, but these statements are put in comments.

If, for example, a very large SGA requires that server processes have larger quotas, then you can activate the appropriate logical name definition in TNSLSNR.COM file by removing the "!" after the "$" and specifying the quota value.

There are no restrictions on the number of quotas that you can specify in the QUOTA list. However, if any quota is specified in the QUOTA list, then none of the quotas specified by logical name is used, and quotas that are not specified in the list will assume the system default.

5.5.4 ORASRV_NETV2_SID Command File

The ORASRV_NETV2_SID.COM file is automatically created for each SID during creation of a database instance.

If an Oracle Shared Server is not being used, then the behavior is the same as seen in earlier releases. The PROGRAM parameter should point to this script in the LISTENER.ORA file. For example:

    (SID_NAME = PROD) 

When the TNS listener starts a dedicated server process, it extracts the value of the PROGRAM parameter from the LISTENER.ORA file.

In an Oracle Shared Server configuration, the TNS listener need not contain the SID_LIST_listener section mentioned earlier. The Oracle Shared Server dispatchers register with the TNS listener directly. These dispatchers also specify the command procedure to run for a dedicated procedure.

This command procedure is currently set to the ORA_ ROOT:[NETWORK.ADMIN]ORASRV_NETV2_SID.COM, which is created automatically. The location and format of the name of this file cannot be changed. A SID_LIST section in the LISTENER.ORA file that points to the same or different script is completely ignored.

5.5.5 General Connections

Ensure that the Oracle Net Services task file defines any logical names used by the INIT.ORA parameters USER_DUMP_DEST and BACKGROUND_DUMP_DEST (if defined).

5.5.6 Trace Information for TCPIP connection

If the TCPIP connection error is unsuccessful, then check for the following file:


This file matches the time of the error. Provide this file to Oracle Support.

5.6 Advanced Security Option

This section provides information that is specific to the current release of Advanced Security Option (ASO) for Security and Single Sign-On.


A separate license is required to use ASO.

This section covers the following topics:

5.6.1 Manual Steps for Authentication Adapters

Set the following parameters in the local INIT.ORA file of the database server:

remote_os_authent = false
os_authent_prefix = ""

For Kerberos5 Adapter

The KRB.CONF file is required on the client side. This configuration file specifies the default realm of the client and maps all known realms to Key Distribution Centers (KDCs).

The following files are required on the server side:

  • KRB.REALMS: This file maps host names and domains into realms.

  • V5SRVTAB: This file contains a key that the KDC uses to encrypt a service ticket for the client.

The location of these files must be specified by using corresponding parameters in the SQLNET.ORA file.

In addition, the Oracle Net Services client also creates a credential cache file, whose location must be specified in the SQLNET.ORA file on the client side.

The following is an example of the parameters in the SQLNET.ORA file for an installation that can act as both client and server:


5.6.2 Usage Notes for Authentication Adapters

This section covers the usage notes for authentication adapters.

General Information

Include the following line in the SQLNET.ORA file:


The listener should not participate in the authentication service.

It is recommended that you always include BEQ as one of the authentication services in the SQLNET.ORA file. For example:


In this way, connections within the server system through the default Bequeath adapter do not have to go through authentication. This is especially important during database startups and shutdowns.

Kerberos 5

  1. Ensure that the clock skew between the client system and the system running the KDC is less than one minute.

  2. Oracle Database client and server processes use the Coordinated Universal Time (UTC) format (time elapsed since 00:00:00 Jan. 1, 1970 in records). Ensure that the system is set to the correct time zone in terms of deviation from Greenwich Mean Time (GMT). Otherwise, the following error message is written to the Oracle Net Services trace file:

    Clock skew too great

  3. Ensure that the value of the SQLNET.AUTHENTICATION_KERBEROS5_SERVICE parameter that you specify in the SQLNET.ORA file matches exactly with the value specified in the KDC. This value is case-sensitive.

5.7 Oracle Net Services Configuration Files

This section describes the files that you can use to configure Oracle Net Services products.

The default directory for Oracle Net Services configuration files is ORA_ROOT:[NETWORK.ADMIN] or TNS_ADMIN.

Oracle Net Services searches for configuration files in the following order:

  1. For the SQLNET.ORA file, the current working directory from where an application is run

  2. The directory specified by the TNS_ADMIN logical name, if it is set

For each system-level configuration file, users may have a corresponding local private configuration file (stored in the user's home directory). The settings in the local file override the settings in the system-level file.

Table 5-2 lists the system-level configuration files and the corresponding local configuration files.

Table 5-2 Oracle Net Configuration Files

System-Level Configuration Files Local Configuration Files





5.8 Configuring Oracle Net Services Protocol Support

Oracle Net Services release 10g on HP OpenVMS supports the following protocols:

  • Bequeath (BEQ)

  • IPC

  • TCP/IP

Before installing the TCP/IP protocol support, you must install and configure the required operating system software. BEQ and IPC protocol support does not have any specific operating system requirements.

See Also:

Oracle Database Installation Guide for HP OpenVMS for more information about Oracle Net Services protocol support

5.8.1 ADDRESS Specification

IPC and TCP/IP protocol support have a protocol-specific ADDRESS specification that is used for Oracle Net Services configuration files and for the DISPATCHERS initialization parameter in the initsid.ora file.

Table 5-3 shows the ADDRESS specifications for each supported protocol.

Table 5-3 ADDRESS Specification Summary

Supported Protocol ADDRESS Specification












5.9 BEQ Protocol Support

The Bequeath (BEQ) protocol support is both a communications mechanism and a process-spawning mechanism. To use the BEQ protocol support, the client and the server must be on the same system. A network service name can be specified directly by the user at the command line or on the Login screen. It can also be specified indirectly by using a logical name, such as ORA_DFLT_HOSTSTR.

If a network service name is not specified, then the BEQ protocol support is used. In this case, the BEQ protocol support always uses a dedicated server and the shared server model is never used. This dedicated server is started automatically by the BEQ protocol, which waits for the server process to start and attach to an existing System Global Area (SGA). If the startup of the server process is successful, then the BEQ protocol support provides interprocess communication through HP OpenVMS mailboxes.

An important feature of the BEQ protocol support is that it does not require a listener for its operation. The protocol support is linked to the client tools and directly starts its own server process without outside interaction. However, you can use the BEQ protocol support only when the client program and Oracle Database 10g are installed on the same system. The BEQ protocol support is always installed and always linked to all client tools and to the Oracle Database 10g server.

5.10 IPC Protocol Support

The IPC protocol support is similar to the BEQ protocol support in that it can be used only when the client program and the Oracle Database 10g server are installed on the same system. The IPC protocol support requires a listener for its operation. The IPC protocol support is always installed and always linked to all client tools and to Oracle Database 10g.

Specifying an IPC ADDRESS

The IPC protocol support connection parameters are part of the ADDRESS keyword-value pair. The ADDRESS is commonly part of a larger construct, such as a connect descriptor or configuration file. You can enter the following parameters in any order:


Table 5-4 describes the syntax for IPC protocol connection parameters.

Table 5-4 Syntax for IPC Protocol Connection Parameters

Parameter Description


IPC protocol support to be used

The value is IPC. It is not case-sensitive.


Service name of database or system identifier (SID)

Example 5-1 shows a sample IPC ADDRESS.

Example 5-1 IPC ADDRESS Specifying a Client



5.11 TCP/IP Protocol Support

On HP OpenVMS, the default tnslnr port is 1521.

5.11.1 Specifying a TCP/IP ADDRESS

The TCP/IP protocol connection parameters are part of the ADDRESS keyword-value pair. The ADDRESS is commonly part of a larger construct such as a connect descriptor or configuration file. You can enter the parameters in any order:


Table 5-5 describes the syntax for the TCP/IP protocol connection parameters.

Table 5-5 Syntax for TCP/IP Protocol Connection Parameters

Parameter Description


The protocol support to be used

The value is TCP. It is not case-sensitive.


The host name or the host IP address


The TCP/IP port

Example 5-2 shows a sample TCP/IP ADDRESS.

Example 5-2 TCP/IP ADDRESS Specifying a Client


You can specify the last field by name as follows: