This chapter provides information about ASAP configuration parameters.
Every Oracle Communications ASAP application, whether client or server, references configuration files to determine configuration information. ASAP has a global file, ASAP.cfg, that maintains global configuration information, as well as component-specific information that may overwrite the globally-defined data. If a configuration parameter has not been defined in this configuration file, the application provides a suitable default value.
The ASAP.cfg file is located in the ASAP_home/config directory (where ASAP_home is the location of your ASAP server installation directory).
Every ASAP application client and server uses an ASAP API. The API provides considerable functionality to the application process, including configuration parameter management, system event generation, performance and process parameters, diagnostics, and database administrative functions.
Each parameter grouping provides a definition of the default character string value and a brief description of the configuration parameter settings.
Global parameters can usually be specified once in the global configuration section (beginning with the comment #### Common API Configuration Parameters).
Local parameters should be specified in the local configuration section (beginning with the first application server listed in square brackets [] followed by a comment, for example, [CTRL] #### Control Server Configuration Parameters).
Note:
To start ASAP, you must define the server application name within the brackets [ ] in the header for each Server Configuration Parameters section in the ASAP.cfg file. You must define the server application name for each section, for example, the CTRL, OCA, SRP, SARM, NEP, and ADM. Ensure there are no empty brackets [ ] in any of the sections in the Server Configuration Parameters; otherwise, system errors occur.Note:
The maximum length for a configuration parameter value is 128 characters.Configuration parameters are grouped as follows:
Global Configuration Parameters – Parameters appearing at the beginning of the ASAP.cfg file before the application-specific sections and providing ASAP-wide parameter values.
Application-specific Configuration Parameters – Parameters residing within the ASAP.cfg file in sections delimited by [ApplName], where ApplName represents the application name.
To determine the configuration parameter values, use the ASC_get_config_param() API call or in the case of object oriented libraries the Config::get_config_param() API call. You can specify the parameter values in the application-specific section or the global section of the ASAP.cfg file. If they are not specified, the default value is used.
Configuration parameters are read from the configuration file upon application startup and are referenced from a cache within the application's memory from that point onwards. Therefore, the application only has to reference the configuration parameter by means of this API call once.
Application-specific section of ASAP.cfg – If the parameter value is specified in this section, its value overrides the parameter values specified in the global section. The application-specific section is determined to be the first section in the file which matches a substring of the application name. For example, an [SRP] section would match SRP_TST1, SRP_TST2 and SRP_PRD1 whereas an [SRP_P] section would only match SRP_PRD1. This is used to specify separate production configurations to those in test environments. In addition, if the SRP_PRD1 application is determining a configuration parameter in a configuration file in which there are both [SRP] and [SRP_P] sections, then the first of these two sections in the file is assumed to be the application-specific section. For this reason, you must specify the application-specific sections before the general ones. For example, you would place the [SRP_P] section prior to the [SRP] section.
Global section of ASAP.cfg – If the parameter value is specified in this section but not in the application-specific section, the value of the global parameter is assumed.
If a parameter is not specified in either the application-specific or global sections, the default value passed to the API call is assumed.
The configuration parameters are grouped in sections that correspond to their scope within the system. For each parameter, the default character string value is detailed together with a brief description of the configuration parameter settings. In addition, the configuration section in which this parameter is usually placed is identified. However, you can choose to place the configuration parameters in different sections.
Local – The parameter should be specified in the local configuration section (for example, APPL_USERID has to be explicitly set for each application process).
Global – The parameter can usually be specified once in the global configuration section (for example, APPL_SQL_SERVER) because these settings may be system wide.
To support the insertion of environment variables within the configuration files, special processing is performed whenever the configuration parameter begins with the "$" character. An example appears below:
APPL_USERID = $USERID
The logic is as follows:
If the configuration parameter value you specify begins with "$", the API determines whether the UNIX environment variable USERID is defined in the environment. If it is defined, the value of this environment variable is used for the configuration parameter, APPL_USERID.
If the environment is not defined, the configuration parameter USERID is set as usual in the application; that is, to $USERID.
This facility allows the inclusion of environment variables within the configuration files. This eases the configuration effort required to maintain a number of ASAP environments especially during testing phases.
The API common to both application servers and clients is represented by the Common API library (libasc), as well as configuration parameters common to both the Client (libclient) and Server (libcontrol) APIs. The configuration parameters in the following sections are used by the common components of servers and clients.
You can specify the configuration parameters to allow an application process (client or server) to determine a network application name from the application's logical name, which usually resides within the database. The network application name is used to define the application to the network. This capability is only used when the logical application name is different from the network name.
You can globally define these configuration parameters for the system. The definition of these configuration parameters are required as an application process reading a logical name from the database references them to determine the network application name. If this is not specified, the network application name will default to the logical application name.
For example, the Service Activation Request Manager (SARM) application server accesses the configuration file to determine the network server names of all Service Request Processors (SRPs) and Network Element Processors (NEPs) to which it may establish network connections. Another example is the Control server, which requires the network name of each application server that it establishes network connections to.
To perform logical to network application name mapping, see Table 9-1.
Table 9-1 Logical to Network Application Name Mapping
Default Value | Config Section | Description |
---|---|---|
Generic Process Name |
Global |
The GENERIC configuration parameter represents the logical name of an ASAP application process. It is set equal to the network process name in this environment. For example, in the production environment, the configuration file may include entries as follows:
Each application process that is to be spawned by the Control server must be defined as above if network names different from logical names are employed, because the Control server reads the logical names from the database and then uses these configuration file settings to determine the network names. |
Table 9-2 lists and describes the logical-to-network application name mapping parameters and values.
Every Host machine in ASAP is assigned a Control server to monitor and control the ASAP process for that machine. The Admin server also provides some system monitoring capabilities using administrative Remote Procedure Calls (RPCs).
Table 9-3 lists and describes the ASAP monitoring parameters and values used to monitor the server performance.
Table 9-3 ASAP Monitoring Parameters, and Values
Parameter | Description | Value |
---|---|---|
SYSMON_ALWAYS_ON |
Boolean flag. If set to 1, activates system monitoring upon startup. Default = 0. |
Default = $MASTER_CONTROL |
SYSMON_LOG_ENABLED |
Records work order logging information. This feature significantly increases the memory and CPU overhead. |
Default = 0 |
SYSMON_DUMP_TRANSACTIONS |
Dumps transaction details to a file. This feature significantly increases the memory and CPU overhead. |
Default = 0 |
SYSMON_SHOW_DESCRIPTIONS |
Shows descriptions of various sections of the generated report. |
Default = 0 |
SYSMON_DELIMITED_OUTPUT |
Generates ASCII formatted file (0) or comma-delimited spreadsheet file (1). |
Default = 0 |
Use the parameters in this section to set up the Connection Pool Manager (CPM) to automatically tune connection pools and log internal application server pools statistics.
Table 9-4 lists and describes the CPM and debugging tools parameters and values.
Table 9-4 Connection Pool Manager and Debugging Tools Parameters, and Values
Parameter | Description | Value |
---|---|---|
ASAP_DEVELOPMENT_MODE |
Boolean flag. If set to 1, it is used during the development process to aid in debugging and tuning the system. It should be set to 0 in production environments. |
Default = 0 |
CONNECT_TO_CTRL |
Boolean flag. If set to 1, it instructs the client application to open a connection to the Control server to log system events. |
Default = 1 |
CPM_OPTIMIZE_POOLS |
Boolean flag. If set to 1, it enables auto-tuning of connection pools by the CPM. The algorithm that CPM_OPTIMIZE_POOLS uses does not guarantee that the oldest unused connection in the pool is closed first. This flag must not be used in a large scale production environment. |
Default = 0 |
DEBUGGER_ON |
Enables the Interpreter State Table debugger. If set, it initializes the Interpreter debugging facilities. |
Default = 1 |
DIAG_LINE_FLUSH |
Boolean flag. If set to 1, it determines whether the diagnostic file output is flushed to disk at the end of each diagnostic line. If set to 0, the diagnostics are only flushed to the diagnostic file if a PROGRAM or SANITY level diagnostic message is written, or if the I/O buffer is flushed by the operating system. You can change this diagnostic parameter by adjusting this configuration parameter or changing the diagnostic line flush flag of the application server by using the diag_line_flush() API RPC/Registered Procedure to the particular server. |
Default = 1 This option should be set to 0 in a production environment because it causes considerable performance overhead in disk activity. |
LANGUAGE_DUMP_ON |
Boolean flag. If set to 1, it determines whether the language buffer being transmitted or received should be logged as a low-level diagnostic in the server's diagnostic log file. The primary use is for debugging such language buffers and is, therefore, generally used in non-production environments. |
Default = 1 |
RPC_SHOW_OUTGOING_PARAMS |
N/A |
Default = 1 |
SYSMON_ALWAYS_ON |
Activates system monitoring upon startup. |
Default = 1 |
This section describes application logical to network application name mapping.
Table 9-5 lists and describes application logical to network application name mapping of parameters and values.
The following parameters are associated with establishing connections to a SQL Server using various user ID/password combinations to determine the default database within the SQL Server. The SQL Server names rarely need to be specified, but the user ID and password combination are likely be explicitly set in either the local or global configuration file.
Table 9-6 lists and describes the SQL Server security-related parameters and values.
Table 9-6 SQL Server Security-Related Parameters, and Values
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $APPL_USER |
APPL_SQL_SERVER |
The SQL Server in which the primary application database resides. If you specify this, the database can reside on a separate SQL Server from other ASAP databases if required. Maximum length eight alphanumeric characters. |
Default = $DSQUERY |
CONTROL_USERID |
The SQL Server user ID the application process uses to connect to the Control database in the CONTROL_SQL_SERVER SQL Server. Maximum length is 20 alphanumeric characters. |
Default = $CTRL_USER |
CONTROL_SQL_SERVER |
The SQL Server where the Control database resides. If specified, the Control database can reside on a separate SQL Server from the application databases, if required. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
The following parameters configure the number of retries and the time interval between each RPC retry. The default parameter values are usually sufficient.
Table 9-7 lists and describes the RPC-related parameters and values.
Table 9-7 RPC-related Parameters, and Values
Parameter | Description | Value |
---|---|---|
RPC_ERROR_SLEEP |
The time interval, in seconds, of the RPC retries when an error condition other than database deadlock is encountered (for example, transaction logs full). This time interval should be large enough to allow the system administrator time to determine the problem and resolve the problem between retries. |
Default = 300 |
RPC_RETRY_COUNT |
The number of times the RPC is retried by the RPC API functions. If after the number of retries the RPC is still unsuccessful, the calling function returns a failure condition, and the API issues a system event. |
Default = 5 |
RPC_RETRY_SLEEP |
The sleep interval, in seconds, for the RPC retries for the database deadlock condition. |
Default = 1 |
RPC_SHOW_OUTGOING_PARAMS |
N/A |
Default = 1 |
The following parameters are referenced whenever an application process opens a network connection to either an application server or SQL Server. The default settings are usually sufficient and rarely require modifications.
Table 9-8 lists and describes the network connection-related parameters and values.
Table 9-8 Network Connection-Related Parameters, and Values
Parameter | Description | Value |
---|---|---|
MAX_CONN_PER_CONTEXT |
The number of Client and Server (CS) library connections that may be opened per context. It may be specified if using a global context; that is, USE_GLOBAL_CONTEXT = 1. |
Default = 25 |
MAX_CONNECT_RETRY |
The maximum number of retry attempts an application will perform when attempting to asynchronously connect to a TCP/IP server using the UNIX connect() API call. These retries may be necessary as the application can be interrupted during the connection attempt. This parameter is generally not set to a value other than its default. |
Default = 10 |
SOCK_REUSEADDR |
Boolean flag. If set to 1, will set the re-use address TCP/IP option on a socket when acting as a TCP/IP socket listener. |
Default = 1 |
USE_GLOBAL_CONTEXT |
This specifies whether each Client (CT)-Library connection should use the global context or allocate a context for each connection. See also MAX_CONN_PER_CONTEXT. |
Default = 0 |
There are two sets of files maintained by ASAP applications for monitoring and troubleshooting purposes: log files and diagnostic files. These files are created by ASAP daily or whenever an application starts up.
Table 9-9 lists and describes the application diagnostics-related parameters and values.
Table 9-9 Application Diagnostics-Related Parameters, and Values
Parameter | Description | Value |
---|---|---|
CONNECT_ERROR_LOGGING |
Boolean flag. If set to 1, causes applications to log messages to their diagnostic files upon unsuccessful connection attempts to servers. |
Default = 0 |
DIAG_FILE_COUNT |
When the current diagnostic file associated with an ASAP server reaches its maximum size (see MAX_DIAG_FILE), it creates a new current diagnostic file, and rolls over the old diagnostic file with a time stamped files. The DIAG_FILE_COUNT parameter specifies the number of time stamped diagnostic files to maintain in addition to the current file. In addition, if the ASAP server or process associated with the diagnostic files stops and restarts, ASAP creates new time stamped files, keeping the old time stamped files without updating them. |
Default = 1 |
DIAG_LINE_FLUSH |
Boolean flag. Determines whether the diagnostic file output is flushed to disk at the end of each diagnostic line. If set to 0, the diagnostics are only flushed to the diagnostic file if a PROGRAM or SANITY level diagnostic message is written, or if the I/O buffer is flushed by the operating system. You can change this diagnostic parameter by either adjusting this configuration parameter or changing the diagnostic line flush flag of the application server by using the diag_line_flush() API RPC/Registered Procedure to the particular server. |
Default = 0 This option should be set to 0 in a production environment because the option causes considerable performance overhead in disk activity. |
MAX_DIAG_FILE |
Application process diagnostic file size in megabytes. It is located in the $LOGDIR/yymmdd directory, where $LOGDIR is $ASAP_BASE/DATA/logs. After this file size is reached, this file can be copied to a time stamped file and a new diagnostic file opened. You can modify the diagnostic file growth by either adjusting this configuration parameter or modifying the diagnostic level of the application server (statically in the Control database or, if a server process, dynamically by means of the diag_level() API RPC/Registered Procedure). For more information on diagnostic levels, see ASAP System Administrator's Guide. |
Default = 3 |
OS_ERROR_LOGGING |
Boolean flag. If set to 1, logs operating system client messages to the diagnostic file. This should be set to 0 in most implementations. |
Default = 0 |
The following parameter is referenced whenever an application process initializes.
Table 9-10 lists and describes self-balancing binary tree-related parameters and values.
Table 9-10 Self-Balancing Binary Tree-Related Parameters, and Values
Parameter | Description | Value |
---|---|---|
SBT_ELEMENTS_PER_NODE |
The number of self-balancing elements per node within the ASAP self-balancing binary trees. This should generally not be set to a value other than the default. This parameter is referenced whenever an application process initializes. |
Default = 3 |
This section describes the server API configuration parameters.
The Sybase Open server configuration parameters can be configured by the server API as the Open server application is starting. The default settings are sufficient for most requirements. However, some specialized application servers may require the tuning of specific parameters.
Table 9-11 lists and describes Sybase open server parameters and values.
Table 9-11 Sybase Open Server Parameters, and Values
Parameter | Description | Value |
---|---|---|
API_CHECK |
Boolean flag. If set to 1, it performs validation of Open server library arguments and state checking. |
Default = 0 |
ATTN_ON_DISCONNECT |
Boolean flag. If set to 1, it calls the Open server's SRV_ATTENTION handler when a client disconnects. |
Default = 0 |
DEFERRED_QUEUE_SIZE |
Open server deferred event queue size. |
Default = 1024 |
LOG_SIZE |
The maximum size, in bytes, of the Open server log file. Open server moves the current contents of the log file to currentfilename_old and truncates the current log to 0 bytes. |
Default = 4194304 The numbers and sizes of the ASAP diagnostic files are controlled by the MAX_DIAG_FILE and DIAG_FILE_SIZE configuration parameters respectively. |
MAX_CONNECTIONS |
This parameter is used for tuning. The maximum number of physical network client connections the Open server accepts. It should be set high enough to accommodate all connections from other ASAP servers in addition to ad hoc connections from client programs such as sqlplus. The actual number of connections possible depends on the platform dependencies and resources. This parameter sets the maximum number of client connections that are accepted by a component server. The actual number is based on platform dependencies and resources. The configured value of MAX_CONNECTIONS must be high enough to accommodate all connections from other ASAP servers, as well as spontaneous connections from client-built programs, such as sqlplus. If the configured number of connections is exceeded, the Open server returns error message 16133. > > 173815059:1:PROG:Server Info:1039: main.cSERVER: Information: Error 16133 Severity 10 State 'Configuration of 10 connections has been exceeded, connection rejected' You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Error 16133" echo "searching for $TARGET (MAX_CONNECTIONS)" grep "$TARGET" *.diag* Changes in the value of MAX_CONNECTIONS affect the MAX_MSGQUEUES and the MAX_SERVER_PROCS parameters. |
Default = 30 Recommended initial values are based on system size:
|
MAX_MSGQUEUES |
The number of thread message queues available to allocate when the Open server starts up. This number does not include message queues created for internal use by the Open server run-time system. Message queues are created for each thread spawned by a component and for each client connection. The configured value of MAX_MSGQUEUES must be greater than or equal to the sum of the values of MAX_THREADS and MAX_CONNECTIONS. Changes in the value of this parameter affect the MAX_MSGPOOL parameter. Larger values are required only for the SARM section of the configuration file. The small value can be used for all other ASAP servers regardless of the size of the ASAP system. |
Default = 278 Recommended initial values are based on system size:
|
MAX_MSGPOOL |
This parameter is used for tuning. The number of message structures available to the Open server. This parameter sets the number of message structures to be allocated at the time of start up. This number must always be greater than or equal to the sum of MAX_MSGQUEUES times 256. |
Default = 71168. Recommended initial values are based on system size:
|
MAX_MUTEXES |
The number of mutually exclusive semaphores available to the application. Determine this number as follows: 110 + the number of NEPs + the number of SRPs + MAX_WO_MGRS (refer to ASAP.cfg). At a minimum, the number of mutexes would be 117 (110 + 1 NEP + 1 SRP + 5 work order managers). In this case, Oracle recommends that you accept the default. If you are operating multiple NEPs, SRPs, and work order managers, you may want to increase the default value. See ASAP Developer's Guide for information on mutexes. |
Default = 128 |
MAX_REMBUF |
The window size used in server-to-server communications and indicates the maximum number of packets that can be outstanding on a logical subchannel before an acknowledgment is required. |
Default = 15 |
MAX_SERVER_PROCS |
This parameter is used for tuning. This parameter sets the maximum number of thread IDs for the application server. The server API maintains an array of administrative thread information for each element, which is indexed using thread IDs. If the thread IDs in the server exceed the value of MAX_SERVER_PROCS, the server terminates. Set MAX_SERVER_PROCS equal to MAX_THREADS plus MAX_CONNECTIONS plus MAX_REMSITES plus 68 (the number of reserved Sybase internal threads). Larger values are required only for the SARM section of the configuration file. The smaller value can usually be used for all other ASAP servers regardless of the size of the ASAP system. In addition, you can set the Shrink Frequency value to non-zero (to allow shrinking) for the RPCConnectionPool in WebLogic Server. See "Socket Connections" to see how to access the Configuration tab. The Shrink Frequency parameter can be found on the Connection Pool sub-tab, under Advanced. In the WebLogic Server configuration, set RPC connection to SARM from dynamic control to static connection to disable shrinking. |
Default = 512 |
MAX_THREADS |
This parameter is used for tuning. The maximum number of threads that may be spawned in the application (including the server API). It does not include threads spawned internally within the Sybase Open server library. The value of MAX_THREADS should be less than or equal to the value of MAX_SERVER_PROCS. This parameter sets the maximum number of threads in the ASAP component. Larger values are only required for the SARM section of the configuration file. Small values can usually be used for all other ASAP component servers regardless of the size of the ASAP system. The value of MAX_THREADS must be greater than MAX_CONNECTIONS because each incoming client connection will spawn a thread. If the number of threads that the ASAP server attempts to spawn exceeds the configured value of this parameter, then the Open server returns the following error message 16115: >> 173532841:7:PROG:Server Info :1039: main.c SERVER: Information: Error 16115 Severity 10 State 0 'Could not start thread' >> 173532843:7:SHUT:System Event :158: asc_spawn.c ASAP System Event: SYS_TERM Error: Unable to Spawn Service Thread WO Prov 1 - Insufficient Resources You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Error 16115" echo "searching for $TARGET (MAX_THREADS)" Grep "$TARGET" *.diag* Changes in the value of MAX_THREADS affect the MAX_MSGQUEUES and the MAX_SERVER_PROCS parameters. |
Default = 150 Recommended initial values are based on system size:
|
MAX_USEREVENTS |
The maximum number of user events that an Open server may define. These are not generally used in ASAP applications. |
Default = 0 |
MAX_REMSITES |
The maximum number of Open server site handlers that can run at a time. Each site handler can support multiple connections to a single remote SQL Server. When a remote server attempts to log into the Open server and there are no available site handlers, the connection request fails. |
Default = 10 |
NET_BUF_SIZE |
The maximum size of the network I/O buffer to be used by client applications. The actual size of the network buffer used is determined at login time. If a smaller size is requested, Open server will not resize the memory buffer. |
Default = 2048 |
NET_TRACE_FILE |
File to which Sybase Net library will write trace information if so configured. |
Default = NULL |
PRE_EMPTIVE |
Boolean flag. If set to 1, it causes Open server to use pre-emptive thread scheduling. Support for pre-emptive scheduling is platform-specific. |
Default = 0 |
SRV_ATTENTION |
N/A |
Default = 0 |
STACK_SIZE |
The size (in MB) of the stack allocated for each thread. This size can be increased should a thread in an Open server run out of stack space. Increasing the thread stack size will impact the amount of memory required by the server. |
Default = 256000 |
TIME_SLICE |
The number of clock ticks an active thread consumes before the time slice callback routine is called. The callback routine for this state transition is called when a thread has run for a time slice determined by the TIME_SLICE, VIRTUAL_CLK_RATE, and VIRTUAL_TIMER Open server properties. |
Default = 10 |
TRUNCATE_LOG |
Boolean flag. If set to 1, it causes the Open server to truncate its server log file upon start up. Note: It does not affect the ASAP diagnostic file. |
Default = 0 |
USE_SRV_LANG |
Boolean flag. If set to 1, it causes the Open server's national language to be used for Open server error messages. If set to 0, the client's national language is used for error messages. |
Default = 0 |
VIRTUAL_CLK_RATE |
The Open server virtual clock rate, in microseconds per tick. |
Default = 1000000 |
VIRTUAL_TIMER |
Boolean flag. If set to 1, it enables the Open server virtual timer. |
Default = 0 |
The following configuration parameters are included to facilitate dynamic enabling of the Open server diagnostics within the Open server library. They are referenced only when you require detailed debugging output. Therefore, the default values for these flags are sufficient in most environments.
Table 9-12 lists and describes the Sybase Open Server debugging trace flag parameters and values.
Table 9-12 Sybase Open Server Debugging Trace Flag Parameters, and Values
Parameter | Description | Value |
---|---|---|
SRV_TR_ATTN |
Boolean Trace flag. If set to 1, the Open server writes information about attention signals from the client to standard error and to the server logfile. |
Default = 0 |
SRV_TR_DEFQUEUE |
Boolean Trace flag. If set to 1, the Open server writes information about deferred queues to standard error and the server log file. |
Default = 0 |
SRV_TR_EVENT |
Boolean Trace flag. If set to 1, the Open server writes information about event information to standard error and the server log file. |
Default = 0 |
SRV_TR_MSGQ |
Boolean Trace flag. If set to 1, the Open server writes information about message queues to standard error and the server logfile. |
Default = 0 |
SRV_TR_NETDRIVER |
Boolean Trace flag. If set to 1, the Open server writes information about network drivers to standard error and the server log file. |
Default = 0 |
SRV_TR_NETREQ |
Boolean Trace flag. If set to 1, the Open server writes information about network requirements to standard error and the server log file. |
Default = 0 |
SRV_TR_NETWAKE |
Boolean Trace flag. If set to 1, the Open server writes information about network wake-ups to standard error and the server log file. |
Default = 0 |
SRV_TR_TDSDATA |
Boolean Trace flag. If set to 1, the Open server writes Tabular Data Stream (TDS) packet contents in hexadecimal (HEX) and ASCII to standard error and the server logfile. This displays the actual data between the client and the server. |
Default = 0 |
SRV_TR_TDSHDR |
Boolean Trace flag. If set to 1, the Open server writes protocol packet header information (such as packet type and length) to standard error and the server logfile. |
Default = 0 |
The following parameters facilitate the configuration of the application server memory management. To use this memory management capability, you must use the memory management API routines (in particular, the creation and use of memory pools) provided as part of the server API.
Table 9-13 lists and describes the application server memory management parameters and values.
Table 9-13 Application Server Memory Management Parameters, and Values
Parameter | Description | Value |
---|---|---|
MEMORY_LOGGING |
Status flag. Determines whether to create diagnostic memory management RPCs (mem_usage() and mem_stats()) in the server as well as the degree of memory management diagnostic logging to be performed while the server is running. |
Default = 0 The values are:
|
ASC_BLOCK##_POOL |
Number of byte memory blocks to allocate within the memory pool for use by the application server. ## is a variable that represents: 16, 32, 64, and so forth, up to 1048576. |
The ASAP.cfg file defines the following default values:
|
The APPL_POOL_SIZE and CONTROL_POOL_SIZE parameters relate to various Client library attributes that can be specified within the application server.
Note:
ASAP no longer supports DB library as a client API.The number of client library connections that the application server opens to its primary application database in the APPL_SQL_SERVER SQL Server with user APPL_USERID is calculated based on the number of threads running in the application.
Table 9-14 lists and describes the client library parameters and values.
Table 9-14 Client Library Parameters, and Values
Parameter | Description | Value |
---|---|---|
CONTROL_POOL_SIZE |
This parameter is used for tuning. This parameter sets the number of CT-Library connections to the Control database. If the configured number is not sufficient, the following error message is logged: >> 181540.988:41:PROG:ASC cppalloc :153: ctlib.c Waiting for Connection from 'Control Pool', (2 In Use). Auto-tuning will increase connection pool if problems persist. You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Waiting for connection from 'Control Pool'" echo "searching for $TARGET (APPL_POOL_SIZE)" grep "$TARGET" *.diag* |
Default = 2 Recommended initial values are based on system size:
|
APPL_POOL_SIZE |
This parameter is used for tuning. This parameter sets the number of CT-Library connections to the component database that you are tuning. Larger system sizes are required only for the SARM section of the configuration file. The smaller value can usually be used for all other ASAP servers regardless of the size of the ASAP system. If the configured number is not sufficient, the following error message is logged: >> 181540.988:41:PROG:ASC cppalloc :153: ctlib.c Waiting for Connection from 'Application Pool', (2 In Use). Auto-tuning will increase connection pool if problems persist. You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Waiting for connection from 'Application Pool'" echo "searching for $TARGET (APPL_POOL_SIZE)" grep "$TARGET" *.diag* |
Default = 2 Recommended initial values are based on system size:
|
ASAP_IS_ALIVE_INTERVAL |
The Control server can also be configured to issue "Keep Alive" notifications to an external operations center signifying that ASAP is functioning correctly. The absence of this periodic notification may indicate an ASAP outage. ASAP_IS_ALIVE_INTERVAL is the check-time interval, in seconds, during which application servers validate existing connections to the SQL Server. This parameter also determines the time period between connection retries between application servers in the event a server is unavailable for some reason. |
Default = 60 |
This section describes the DB library parameters.
Table 9-15 lists and describes the DB library parameters and values.
Table 9-15 DB Library Parameters, and Values
Parameter | Description | Value |
---|---|---|
DBERROR_TIME_INTERVAL |
Threshold time frame. See also NUM_DBERROR_ALLOWED. |
Default = 60 |
MAX_DBPROCS |
The maximum number of database processes per application. |
Default = 25 |
NUM_DBERROR_ALLOWED |
DB library error threshold. If more than this number of DB library errors occur in a specified time interval, the application server will stop. This is to avoid recursive error situations. See also DBERROR_TIME_INTERVAL. |
Default = 40 |
The following parameters are used by the poll manager thread in the server API, which provides thread-safe polling functionality. The poll manager thread monitors the network connections on behalf of all the threads in the ASAP application server. The server API call, ASC_poll(), sends poll requests to the poll manager and returns the same return values as the native, srv_poll() Sybase call.
Table 9-16 lists and describes the poll management parameters and values.
Table 9-16 Poll Management Parameters, and Values
Parameter | Description | Value |
---|---|---|
MAX_CONNECTIONS_TO_POLL |
The initial number of network connections for which the poll manager polls. This configuration parameter is used to determine the initial poll list size. This list is automatically resized as additional connections are added to the poll list. |
Default = 1 |
MAX_POLL_REQUESTS |
This specifies the maximum initial number of poll requests to the server API poll manager thread at one time. If more than this number of requests are received, the poll manager automatically resizes the poll request list. |
Default = 1 |
MAX_POLL_RETRY |
This is the number of retries that the server API poll manager will attempt should the Sybase srv_poll() call be interrupted in the ASC_poll() server API call. |
Default = 10 |
You can use the following parameters to configure various aspects of the database administration thread in each application server. This calls a stored procedure in the database and passes it a configurable parameter before recompiling all the stored procedures in that application server's default database (the database defaulted to using the APPL_SQL_SERVER and APPL_USERID login information). It also updates the SQL Server statistics for all indexes on user-defined tables in the database.
Table 9-17 lists and describes the DB_ADMIN_ON parameter and values.
Table 9-17 DB_ADMIN_ON Parameter and Values
Parameter | Description | Value |
---|---|---|
DB_ADMIN_ON |
Boolean flag. If set to 1, it enables the database administration thread operation in the application server. This can be disabled in particular servers in situations where multiple servers share the same application database (for example, multiple NEPs) and then only one server is required to perform this database administration. |
Default = 0 |
This section describes the IPC diagnostic parameters.
Table 9-18 lists and describes the IPC Diagnostic parameters and values.
Table 9-18 IPC Diagnostic Parameters and Values
Parameter | Description | Value |
---|---|---|
LANGUAGE_DUMP_ON |
Boolean flag. If set to 1, it determines whether the language buffer being transmitted or received should be logged as a low-level diagnostic in the server's diagnostic log file. The primary use is for debugging such language buffers, and is therefore, generally used in non-production environments. Enables the logging of diagnostic details of language requests being transmitted to and from application servers. |
Default = 1 |
REGISTERED_PROCS |
Defines the behavior of a particular API call to create a registered/remote procedure call in an application server. The parameters enable diagnostic output of the RPCs and language requests being transmitted to and from application servers. Boolean flag. If set to 1, it determines whether procedures added with the add_appl_rpc() API call are to be added as Sybase registered procedures or as Sybase remote procedures. The advantage to adding them as registered procedures is that there is less overhead in determining the procedure handler because the Sybase Open server library searches the registered procedure handlers before the remote procedure handlers. The disadvantage of using registered procedures is that they do not allow optional parameters. Therefore, any such procedures should be added using the API function, add_rpc(), which adds them as remote procedures regardless of this configuration setting. In general, to register a procedure with fixed number of parameters as a registered procedure, call ASC_define_rpc(). To register a procedure with variable number of parameters as an RPC, call add_rpc(). |
Default = 0 |
The following parameters describe security-related parameters.
Table 9-19 lists and describes the Security-Related parameters and values.
Table 9-19 Security-Related Parameters and Values
Parameter | Description | Value |
---|---|---|
CLIENT_SECURITY_ON |
Determines whether client processes connecting to server processes have their user IDs and passwords verified against the SQL Server (APPL_SQL_SERVER SQL). If this connection fails, the client is denied access to the server. |
Default = 0 |
NE_DIALOG_OFF |
Controls the NE dialog message in the diagnostic file. |
Default = 0 Possible values are:
|
The following parameters identify the system and territory used in ASAP.
Table 9-20 lists and describes the high-availability parameters and values.
Every application server logs process performance parameters which are maintained in memory within the application. The parameters are also written to the database at an interval configured using the PERF_POLL_PERIOD parameter.
Table 9-21 lists and describes the application server performance parameter and value.
Table 9-21 Application Server Performance Parameter and Value
Parameter | Description | Value |
---|---|---|
PERF_POLL_PERIOD |
Time period, in seconds, that the application servers wait to update the Control database with periodic performance information related to the operation of the application server. |
Default = 600 |
This section describes client API configuration parameters.
This section describes client application signal handling.
Table 9-22 lists and describes the client application signal handling parameter and value.
Table 9-22 Client Application Signal Handling Parameter and Value
Parameter | Description | Value |
---|---|---|
SIG_IGNORED |
Boolean flag. If set to 1, it instructs the client application to ignore any received signals that are not explicitly handled by the application. If set to 0, reception of such a signal results in the termination of the client application. |
Default = 1 |
This section describes SRP API parameters.
This section describes SARM connectivity parameters.
Table 9-23 lists and describes the SARM connectivity parameters and values.
Table 9-23 SARM Connectivity Parameters and Values
Parameter | Description | Value |
---|---|---|
DUMP_WO_PATH |
The location of the dump file for work orders processed by the SRP Emulator. This parameter works in conjunction with DUMP_WO_FLAG, which specifies whether the work orders processed by the SRP Emulator should be dumped to a dump file. |
Default = /tmp |
MAX_SARM_DRIVER |
The number of SARM driver threads to spawn within the SRP library. These threads send orders to the SARM. |
Default = 5 |
MAX_WO_MGRS |
The number of work order manager threads to be started by the SARM. |
Default = 5 |
SARM |
The logical name of the SARM server to which the SRP will establish network connections. |
Default = $SARM |
SRP_SEND_GPARMS |
Boolean flag. If set to 1, it transmits global parameters on the order to the SARM as global parameters. This parameter is provided for backward compatibility with some existing SRPs. |
Default = 1 |
The following parameter provides loopback delay functionality in the SRP upon reception of work order event notifications.
Table 9-24 lists and describes the loopback testing parameter and value.
Table 9-24 Loopback Testing Parameter and Value
Parameter | Description | Value |
---|---|---|
WO_MGR_DELAY |
Artificial loopback time delay which, if not zero, results in a pause for the configured number of seconds after SRP processes a work order event notification from the SARM. This is used primarily in testing and should not be configured in a non-test environment. |
Default = 0 |
The following parameters relate directly to the operation of the Interpreter State Tables.
Table 9-25 lists and describes the interpreter operation parameters and values.
Table 9-25 Interpreter Operation Parameters and Values
Parameter | Description | Value |
---|---|---|
INSTRUCTIONS_PER_SLICE |
The number of State Table instructions that are consecutively run by the Interpreter before the Interpreter explicitly suspends the thread to let other threads run in a non pre-emptive environment. This is generally only a concern when the Interpreter is running in loopback mode because there is no I/O that would otherwise suspend the thread. |
Default = 10 |
MAX_STACK_DEPTH |
The maximum depth of the stack in the Interpreter State Tables. For complicated or recursive state tables, this stack depth size may need to be increased to accommodate the largest anticipated stack size. Each Interpreter instance in an application server has its own State Table stack, and therefore, the memory requirements for each Interpreter is multiplied by the number of configured Interpreters within the application server to determine process memory requirements. Each unit increase in the stack depth parameter results in roughly eight extra bytes per Interpreter. If an NEP has 10 Interpreters or command processors and defines its stack depth at 100, the memory requirements would be 8 KB (10 x 100 x 8). |
Default = 20 |
STRING_LENGTH_CHECK |
Boolean flag. If set to 1, it performs extensive checking of the length of State Table variables. This is useful in situations in which long variables are being extensively manipulated in State Tables and allows the library to perform the validation rather than the State Tables themselves. |
Default = 0 |
SWITCH_OPTIMIZATION |
Boolean flag. If set to 1, it enables State Table optimizations to be made to the State Tables to improve performance. Switch/case/default statements are load-time compiled into a map that is used when the SWITCH action is called. In this mode of operation, the CASE values are treated as static strings and the CASE, DEFAULT, and ENDSWITCH actions are never called because the SWITCH statements provide all the functionality with the map. Optimization can be enabled in two ways:
Note: User-defined actions that use the SWITCH_VALUE do not work when optimization is enabled and will cause compilation errors. |
Default = 0 |
Use the following parameters to configure the Interpreter's access to the core ASAP database, which contains the State Tables, the Interpreter's local database (for example, the NEP database if the Interpreter is running in the NEP), and the number of network connections to open to each database.
Table 9-26 lists and describes the SQL Server connectivity parameters and values.
Table 9-26 SQL Server Connectivity Parameters and Values
Parameter | Description | Value |
---|---|---|
CORE_SQL_SERVER |
The SQL Server where the core ASAP database resides. This allows distribution of the core ASAP database to a separate SQL Server, if required. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
CORE_USERID |
The user ID for CORE_SQL_SERVER. |
Default = $SARM_USER |
MAX_CMD_DBPROCS |
This parameter sets the number of connections to the Interpreter database, where the State Tables use additional tables and stored procedures. If the configured number is not sufficient, the following error message is logged: 181540.988:71:PROG:Alloc DBPROC:888: cmd_utils.c Waiting for Command DBPROCESS to become Available You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Waiting for Command DBPROCESS" echo "searching for $TARGET (MAX_CMD_DBPROCS)" grep "$TARGET" *.diag* |
Default = 1 Recommended initial values are based on system size:
|
MAX_CORE_CPPROCS |
The number of Client library network connections the Interpreter establishes to the SARM database. These connections can then be accessed by action functions within the Interpreter in order to interact with the SARM database. The NEP library uses these connections to write information directly to the SARM database. The SRP library uses these connections to access data directly in the SARM database. |
Default = 2 |
MAX_CORE_DBPROCS |
This parameter sets the number of connections to the SARM database. If the configured number is not sufficient, the following error message is logged: 111921.013:42:PROG:Alloc DBPROC :904: cmd_utils.c Waiting for Core DBPROCESS to become Available You can run the following sample code from the diagnostic directory to locate error messages in the log file: export TARGET= "Waiting for Core DBPROCESS" echo "searching for $TARGET (MAX_CORE_DBPROCS)" grep "$TARGET" *.diag* |
Default = 2 Recommended initial values are based on system size:
|
NEP_SQL_SERVER |
The SQL Server to which the Interpreter provides database access. For an interpreter in an NEP, this is the SQL Server where the NEP database resides. For an interpreter within an SRP, this is the SQL Server where the SRP database resides. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
NEP_USERID |
The user ID the Interpreter uses to open network connections to the SQL Server in order to access the Interpreter database. For an interpreter in an NEP, this is the NEP user ID. For an interpreter in an SRP, this is the SRP user ID. The default database for this user is the location of any tables, stored procedures, etc., required by the Interpreter in its processing. Maximum length is 20 alphanumeric characters. |
Default = $NEP_USER |
This section describes the State Table debugger support.
Table 9-27 lists and describes the State Table Debugger support parameter and values.
Table 9-27 State Table Debugger Support Parameter and Value
Parameter | Description | Value |
---|---|---|
DEBUGGER_ON |
Boolean flag. You can use the DEBUGGER_ON parameter to enable the Interpreter State Table debugger. If set to 1, it initializes the Interpreter debugging facilities. Refer to the relevant ASAP specification for details about the Interpreter debugger. |
Default = 0 |
The following parameters describe how you can configure the Interpreter to run in loopback mode. They are used primarily in system testing.
Table 9-28 lists and describes the loopback support parameters and values.
Table 9-28 Loopback Support Parameters and Values
Parameter | Description | Value |
---|---|---|
LOOPBACK_DELAY |
If the Interpreter is running in loopback mode, this value represents the number of seconds the interpreter waits before returning a successful Atomic Service Description Layer (ASDL) status to mimic real run-time conditions. Note: This is a global parameter over all ASDLs. Specific ASDL settings may be configured through the ASDL response table in the core database. |
Default = 5 |
LOOPBACK_ON |
Boolean flag. If set to 1, it denotes the Interpreter loopback operational status. In addition, the library accesses the ASDL response table in the core database to determine the post-processing emulation action to take. If this parameter appears in the global section of the ASAP.cfg file, it sets the global loopback status. Alternatively, it can be put within NEP server sections to manage loopback settings for each NEP server independently. If there is no LOOPBACK_ON parameter configured in ASAP.cfg, each NEP server assumes that LOOPBACK_ON is not set (that is, LOOPBACK_ON=0) unless it is specified to be on for that NEP server. Using asap_utils option 37, you can dynamically set the value of LOOPBACK_ON for individual NEs. Changes made using asap_utils take effect without the need to restart the ASAP server. You can also query the current settings of LOOPBACK_ON. See options 36 and 37 in "NEP Utilities". A LOOPBACK_ON field is located in the SARM database table tbl_ne_config to control the LOOPBACK mode for each NE individually; There are three possible values for the field:
|
Default = 1 |
Table 9-29 lists all possible NE loopback values according to the values in ASAP.cfg and tbl_ne_config.
This section describes the NEP API parameters.
The following parameters are used to configure specific aspects of the NEP ASDL processing.
Table 9-30 lists and describes the ASDL processing parameter and values.
Table 9-30 ASDL Processing Parameters and Values
Parameter | Description | Value |
---|---|---|
ASAP_STATS_ON |
Boolean flag. If set to 1, the NEP saves ASAP statistics logged by the State Tables in the core database statistics table. |
Default = 0 |
DEFAULT_ASDL_ESTIM |
The default estimate (in seconds) for an ASDL to be processed. This value is used by the NEP to initially estimate the processing times of ASDLs in the NEP. |
Default = 10 |
NE_CMD_LOG_ON |
Boolean flag. If set to 1, it indicates whether the NEP should save each Man-Machine Language (MML) command issued by the SEND State Table action in the core database for user viewing. |
Default = 1 |
The following parameters relate directly to the NEP connectivity logic.
Table 9-31 lists and describes the ASDL processing parameter and values.
Table 9-31 ASDL Processing Parameters and Values
Parameter | Description | Value |
---|---|---|
CONNECT_FAIL_DELAY |
Time interval, in seconds, the NEP waits between login retries after establishing a successful connection to an external system. |
Default = 120 |
NEP_MAINTENANCE_INTERVAL |
Time interval, in seconds, before the NEP retries the NE connection after the NEP or State Tables have determined that the NE is in maintenance mode. |
Default = 600 |
NEP_PORT_BIND_INTERVAL |
Time interval, in seconds, the NEP waits between attempts to bind to an NEP port in order to establish a connection to an external system. This generally occurs when there are fewer ports available than connection requests and the bind attempt fails. In such circumstances, the binding operation is retried on the assumption that a port will become available. |
Default = 60 |
NEP_PORT_CONNECT_INTERVAL |
Time interval, in seconds, between primary connection attempts to an external system. If the NEP is requested to establish a primary connection and that connect attempt fails, this is the time interval the NEP will wait between attempts to establish the primary connection. |
Default = 60 |
PORT_ENABLE_TIMER |
The time interval, in seconds, after the disabling of an NEP port that the NEP will automatically re-enable the port. A port can be disabled by the NEP if the connect attempt to the external system fails. This avoids manual intervention to re-enable the port in such circumstances. |
Default = 600 |
SARM |
The logical name of the SARM server to which the NEP opens network connections. |
Default = $SARM |
The following parameters relate directly to the NEP support for Switch Direct processing.
Table 9-32 lists and describes the switch direct parameters and values.
Table 9-32 Switch Direct Parameters and Values
Parameter | Description | Value |
---|---|---|
NEP_HOST_IPADDR |
This is the NEP IP address upon which the NEP is running. It must be set to support Switch Direct functionality. See also SWD_SESSIONS_SUPPORTED. |
Default = $NEP_HOST_IPADDR |
NEP_HOST_NAME |
Host name of the machine on which the NEP is running. See also SWD_SESSIONS_SUPPORTED. |
Default = $NEP_HOST_NAME |
SWD_SESSIONS_SUPPORTED |
Boolean flag. If set to 1, it enables switch direct functionality in the NEP. |
Default = 0 |
This section describes the NE communication API parameters.
The following parameters are used to specify the various device drivers that are licensed to the client.
Table 9-33 lists and describes the device driver support parameters and values.
Table 9-33 Switch Direct Parameters and Values
Parameter | Description | Value |
---|---|---|
DCE_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the DCE option. |
Default = 1 |
FTP_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the FTP device driver in the communications interface. |
Default = 1 |
LDAP_IF_SUPPORTED |
Indicates whether LDAP is supported or not. |
Default = 1 |
SERIAL_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the serial device driver in the communications interface. |
Default = 1 |
SNMP_IF_SUPPORTED |
Boolean flag. Specifies whether the NEP SNMP Option should be enabled. If set to 1, it enables the NEP SNMP option. |
Default = 0 |
SOCKET_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the TCP/IP socket device driver in the communications interface. |
Default = 1 |
TELNET_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the TCP/IP telnet device driver in the communications interface. If telnet is supported, the ALLOW_TELNET_EXTENDED_CHAR_SET Boolean flag specifies whether to print extended ASCII characters. |
Default = 1 Possible values are:
|
X25_IF_SUPPORTED |
Boolean flag. If set to 1, it enables the generic device driver in the communications interface. |
Default = 1 |
The MAX_GR_CONNECTIONS and MPM_READ_BUF_SIZE parameters are required if the communication to the NE is terminal-based.
Table 9-34 lists and describes the terminal communication support parameters and values.
Table 9-34 Terminal Communication Support Parameters and Values
Parameter | Description | Value |
---|---|---|
MAX_GR_CONNECTIONS |
Identifies the maximum number of connections that the Generic Router (GR) thread will be polling (including the connection used by the command processors to communicate with the GR). This parameter is used by the GR to set up the initial data structures for polling. If more command processor connection requests are received, the queue is automatically resized. |
Default = 20 |
MPM_READ_BUF_SIZE |
Specifies the size of the buffer, in bytes, used by the GR thread to read data from terminal based ports. This value can be tuned depending upon the length of the communication. |
Default = 512 |
This section describes the serial device driver support.
Table 9-35 lists and describes the serial device driver support parameters and values.
Table 9-35 Serial Device Driver Support Parameters and Values
Parameter | Description | Value |
---|---|---|
IGNORE_MODEM_ST |
Boolean flag. If set to 1, it instructs the serial device driver to treat the serial connection as a local direct connection with no modem control. If set to 0, modem control (dial-up) is assumed. |
Default = 0 |
An external device driver (EDD) is a client application that resides outside the NEP and provides the communication mechanism with external systems. An EDD links in the generic EDD API, libgedd, as well as the client API, libclient, and the common API, libasc.
Note:
These parameters are only available to Solaris based ASAP installations when you install the optional SNMP component. For more information about installing this component, see the ASAP Installation Guide.Table 9-36 lists and describes the generic EDD API parameters and values.
Table 9-36 Serial Device Driver Support Parameters and Values
Parameter | Description | Value |
---|---|---|
HOST_NAME |
The host name of the machine that the NEP (that the EDD is communicating with) is on. |
Default = $HOST_NAME |
IO_TIMEOUT |
The I/O timeout, in seconds, the EDD waits before timing out from an I/O write operation to the NEP. |
Default = 180 |
SERVER_IPADDR |
The IP address of the host machine upon which the EDD is listening for incoming connections. |
Default = $SERVER_IPADDR |
SERVER_PORT |
The IP port number upon which the EDD is listening for incoming connections from the NEP. |
Default = $SERVER_PORT |
SNMP_VERSION |
Specifies the SNMP version, which will be used for the current EDD. Available versions are V1, V2C, V3. |
Default = V1 |
The following parameters are used by the CSOL library Work Order Query component:
Table 9-37 lists and describes the CSOL API parameters and values.
Table 9-37 CSOL API Parameters and Values
Parameter | Description | Value |
---|---|---|
MAX_QUERY_RESULTS |
A limiting parameter on query result sets. Query results for work orders, CSDL history responses, ASDL history responses and such are limited to this configurable maximum so as not to overload the caller with a potentially large result set. Large result sets can require a lot of memory and CPU resources to maintain and manage. |
Default = 250 The default value of 250 is also the maximum value. |
QUERY_POOL_SIZE |
Number of database connections to the query database to maintain in the connection pool. The number of simultaneous work order queries supported by the database. The queries exceeding the number will wait until a database connection is available. |
Default = 7 |
QUERY_SQL_SERVER |
Name of the database server, either Sybase SQL Server or an Oracle database instance, where the QUERY_USERID is located. |
Default = $DSQUERY |
QUERY_USERID |
Database user ID for the C++ library Work Order query component. Normally this is the login name for the SARM database. |
Default = $SARM_USER |
This section describes the auditing level parameter.
Table 9-38 lists and describes the auditing level parameter and values.
Table 9-38 Auditing Level Parameter and Value
Parameter | Description | Value |
---|---|---|
WO_AUDIT_LEVEL |
ASAP provides the ability to audit all transactions involved in provisioning a work order. All work order auditing messages are stored in an audit table in the SARM database (tbl_wo_audit). The user can query work order audit trail records through Order Control Application (OCA). Set the audit level for transactions performed by the work order. See ASAP Developer's Guide for more information on ASAP auditing features. If you want to log error messages (SRQ_ERROR_EVENTS) for service requests events (srq_evt) in tbl_srq_log, you must set WO_AUDIT_LEVEL to 2. |
Default = 1 Possible values are:
|
This section describes the WebLogic server parameters.
Table 9-39 lists and describes the WebLogic server parameters and values.
Table 9-39 WebLogic Server Parameters and Values
Parameter | Description | Value |
---|---|---|
BEA_CONN_TYPE |
Sets the type of connection that the WebLogic server is expecting (mandatory). |
Default = http Possible values are:
|
BEA_WLS_HOST |
Sets the host name or IP address of the system that the WebLogic server is running on. (mandatory). |
Default = localhost |
BEA_WLS_PORT |
Sets the port number for the WebLogic server. (mandatory). |
Default = 7001 |
BEA_WLS_USER |
Sets the name of the WebLogic admin user login. (mandatory). |
Default = system |
SECURITY_SERVICE |
Sets the name of the Security Web service deployed in the WebLogic server. (mandatory). |
Default = security |
This section describes the Control server configuration parameters.
Table 9-40 lists and describes the Control server parameter and values.
Table 9-40 Control Server Parameter and Value
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $CTRL_USER |
The Control server controls the generation of system alarms by means of the closely coupled fork agent client process. The ALARM_RETRIES and ALARM_TIME_INTERVAL configuration parameters control specific aspects of the alarm program generation.
Table 9-41 lists and describes the Control server alarm parameters and values.
Table 9-41 Control Server Alarm Parameters and Values
Parameter | Description | Value |
---|---|---|
ALARM_RETRIES |
The number of times the Control server will attempt to generate an alarm program. |
Default = 3 |
ALARM_TIME_INTERVAL |
The time interval, in seconds, between unsuccessful alarm program generations. |
Default = 10 |
Table 9-42 lists and describes the Control server database and file system monitoring parameters and values.
Table 9-42 Control Server Database and File System Monitoring Parameters and Values
Parameter | Description | Value |
---|---|---|
DB_MONITOR_TIME |
The time interval, in minutes, when the Control server monitors the database and logs segment sizes and then issues a system event if they exceed a predetermined threshold value. This functionality can be enabled within the Control server by populating the database threshold monitoring table in the Control database. |
Default = 10 |
FS_MONITOR_TIME |
The time interval, in minutes, when the Control server monitors the UNIX file system sizes and issues a system event if they exceed a predetermined threshold value. This functionality can be enabled within the Control server by populating the file system threshold monitoring table in the Control database. |
Default = 5 |
RESTART_ATTEMPTS |
The number of times the Control server attempts to restart an ASAP application. |
Default = 5 |
RESTART_DELAY |
The time delay, in seconds, that the Control server waits between attempts to restart an ASAP application. |
Default = 60 |
RESTART_RESET_DELAY |
The time delay, in seconds, the Control server waits to reset its counters after the last attempt to restart an ASAP application. |
Default = 600 |
You can configure the fork agent to retry process generation a number of times before returning a failure. The frequency and number of such attempts is determined by the FORK_ATTEMPTS_INTERVAL and FORK_ATTEMPTS_MAX parameters.
Table 9-43 lists and describes the fork agent process generation configuration parameters and values.
Table 9-43 Fork Agent Process Generation Configuration Parameters and Values
Parameter | Description | Value |
---|---|---|
FORK_ATTEMPTS_INTERVAL |
The time interval, in seconds, between process generation attempts. |
Default = 0 |
FORK_ATTEMPTS_MAX |
The maximum number of times the fork agent attempts to generate a new application, either an ASAP application or an alarm program. |
Default = 1 |
MSGSND_RETRIES |
Controls the number of retries if the submission fails. The Control server passes messages to the fork agent using message queues. If the system temporarily cannot submit messages to the queue, the Control server can be configured to retry the submission. Changing the MSGSND_RETRIES and MSGSND_RETRY_DELAY parameters should be done only after diagnostics show that the Control server stops. |
Default = 0 |
MSGSND_RETRY_DELAY |
Specifies, in milliseconds, the delay between two retries. |
Default = 5 |
You can use these parameters to configure various aspects of the database administration thread in each application server. This calls a stored procedure in the database and passes it a configurable parameter before recompiling all the stored procedures in that application server's default database (the database defaulted to using the APPL_SQL_SERVER, and APPL_USERID login information). It also updates the SQL Server statistics for all indexes on user-defined tables in the database.
Table 9-44 lists and describes the Control Server database administration parameters and values.
Table 9-44 Control Server Database Administration Parameters and Values
Parameter | Description | Value |
---|---|---|
DB_ADMIN_ON |
Boolean flag. If set to 1, it enables the database administration thread operation in the application server. This can be disabled in particular servers in situations where multiple servers share the same application database and then only one server is required to perform this database administration. |
Default = 0 |
DB_ADMIN_PROC_PARAM |
The integer parameter passed to the database administration procedure. For example, this can specify a purge interval for a particular database. |
Default = 100 |
DB_ADMIN_PROC |
The procedure the database administration thread calls at a specified time in the day. This procedure could perform many tasks, including archiving and purging of dynamic data. All stored procedures in the database are recompiled and the statistics updated after this administration procedure has been called. |
Default = CSP_db_admin |
DB_ADMIN_TIME |
The number of minutes after midnight when the database administration tasks are to be performed. This is usually performed at a time of low system activity. |
Default = 300 |
DB_PCT_ANALYZE |
This parameter applies to Oracle Database only. It is used to update statistics on all user-defined tables. The updates are done when the database administrations tasks are performed. (See also DB_ADMIN_TIME.) This parameter is used to optimize the database query performance. The Oracle SQL statement is "analyze table table_name estimate statistics sample DB_PCT_ANALYZE percent". See the discussion on the Analyze command in Oracle SQL Reference Manual. |
Default = 20 |
The SRP Emulator is a generic SRP used for performance bench marking, system testing, and the prototyping of new SRPs.
This application server links in libsrp, libinterpret, libcontrol, and libasc. Therefore, it requires the libsrp, libinterpret, libcontrol, and libasc configuration parameter definitions in addition to the ones outlined below.
Note:
DUMP_WO_FLAG is specific to the SRP Emulator server and not the SRP.The SRP Emulator Server can have multiple instances of the following:
SARM Driver Threads – Configurable with the MAX_SARM_DRIVER parameter
WO Manager Threads – Configurable with the MAX_WO_MGRS parameter
SARM RPC Handler Threads – The connections threads spawned when the SARM open connections to the SRP
WO Translation Threads – Increasing the number of WO translation threads leads to a faster load of work orders in the SRP. To increase the number of WO translation threads you must connect more clients to the SRP because the event-driven threads dedicated to these clients are the WO translation threads themselves.
Table 9-45 lists and describes the SRP Emulator server configuration parameters and values.
Table 9-45 SRP Emulator Server Configuration Parameters and Values
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $SRP_USER |
DUMP_WO_FLAG |
Boolean flag that specifies whether the work orders processed by the SRP Emulator should be dumped to a dump file located in the /tmp directory. |
Default = 0 |
NEP_USERID |
The user ID the Interpreter uses to open network connections to the SQL Server in order to access the Interpreter database. For an interpreter in an NEP, this is the NEP user ID. For an interpreter in an SRP, this is the SRP user ID. The default database for this user is the location of any tables, stored procedures, etc., required by the Interpreter in its processing. Maximum length is 20 alphanumeric characters. |
Default = $SRP_USER |
SAVE_SARM_DATA |
Boolean flag that controls the saving of order information by the SRP Emulator when a work order completion or failure is received by the emulator. If set to 1, the emulator will query the SARM for all information about the completed or failed order. |
Default = 0 |
SRP_EMUL_ORDER_ID |
The single character prefix for all work orders created by the SRP Emulator. |
Default = A |
USE_RAW_WO_IDS |
Boolean flag. If set to 1, dictates that the SRP Emulator use the work order IDs present in the database. If set to 0, the SRP will generate a numerical prefix to the order number and transmit this derived order number to the SARM. This allows the same order definition to be transmitted many times to the SARM by the emulator. |
Default = 0 |
ZERO_PAD_WO_IDS |
Boolean flag. If set to 1, pads the generated work order IDs with zeros. |
Default = 0 |
This section describes SARM server configuration parameter.
Table 9-46 lists and describes the SARM server configuration parameter and values.
Table 9-46 SARM Server Configuration Parameter and Value
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $SARM_USER |
This section describes mask for WO ID generation.
Table 9-47 lists and describes the mask for WO ID parameter and values.
Table 9-47 Mask for WO ID Parameter and Value
Parameter | Description | Value |
---|---|---|
OCA_WOID_MASK |
Format string that uses a single integer placeholder (%d) to set a mask for generation of work order IDs. The integer field is populated by a unique integer from the SARM. |
The default value results in work order IDs beginning with OCA-00000001.Default=OCA-{0,number,********}. |
The following parameters are used to configure Virtual Network Operator (VNO) status.
Table 9-48 lists and describes the configuration for VNO external validation parameters and values.
Table 9-48 Configuration for VNO External Validation Parameters and Values
Parameter | Description | Value |
---|---|---|
VNO_ENABLED |
This VNO configuration parameter is designed to activate the OCA client to perform VNO security checking on OCA users and to un-authorize users who are not members of any VNO group in WebLogic Server security. The value of this configuration parameter is obtained by the OCA SRP server and is provided to the OCA client. |
Default = 0 |
VNO_ID_DEFAULT |
This parameter controls the specification of a default VNO ID at the OCA SRP. If VNO_ID_DEFAULT is not set, no default VNO ID will be added to work orders, even if they do not include a VNO ID. If VNO_ID_DEFAULT is set to the VNO ID, the VNO ID specified will be added to work orders that do not already have a VNO ID specified. When a default VNO ID is added to an order and the order is submitted successfully, a record is inserted to tbl_usr_wo_prop in the SARM database for that order, with VNO ID in the name field and the default value in the value field. |
Default = no value |
VNO_ID_STRIP |
This parameter controls whether the VNO ID is stripped. If VNO_ID_STRIP is set to 0, the VNO ID will not be stripped before returning the information upstream. If VNO_ID_STRIP is set to 1, the information being returned upstream is filtered by removing the VNO ID. The OCA SRP maintains the VNO ID in its memory and databases for this order. For example, tbl_usr_wo_prop still contains the VNO ID for the order. |
Default = 0 |
EXTERNAL_VALIDATION_JNDI |
This parameter configures the WO extended validation server. It works only when VNO_ENABLED is set to 1. To enable WO extended validation, set the full JNDI path of external Validation EJB. To disable WO extended validation with VNO filter enabled, do not define this parameter. An external validation sample can be found in $ASAP_BASE/oca_sys_if/sample/validationServer/. With the sample validation logic, if a work order contains the CSDL C-ADD_POTS_LINE and its parameter DN is not equal to 6742727, the InvalidOrderException message is thrown. |
Default = abc/Comp/SampleExternalOrderValidation |
These following parameters are relevant to the processing of work orders within the SARM.
Table 9-49 lists and describes the SARM work order processing parameters and values.
Table 9-49 SARM Work Order Processing Parameters and Values
Parameter | Description | Value |
---|---|---|
ASDL_TIMEOUTS |
Each ASDL has a timeout value that governs how long it can remain in the pending queue without being successfully provisioned. All ASDLs within the same work order must have the same timeout value. When the work order has timed out and failed, the final status is WO_TIME_OUT. Boolean flag. For SARM to support ASDL timeout, set the following:
Each ASDL can time out based on the configuration parameters. The timer must be set for each ASDL, and it starts once the ASDL is in pending queue. If the value of the ASDL_TIMEOUTS is 0 (zero), the ASDL timeout feature is not used, regardless of the asdl_timeout value. Timeout and retry attributes are configurable at the ASDL level, at the NE level, at the work-order level, and at the system level. If no ASDL timeout parameters are defined, other settings may apply. See ASAP Cartridge Development Guide. The way the ASDL timeout is applied to the first ASDL differs from the way it applies to all subsequent ASDLs. If an ASDL timeout occurs during the provisioning of the first ASDL, a grace period is given. For the second, and subsequent ASDLs, no grace period is given. The value of the grace period is the same as the asdl_timeout value. When the first ASDL times out during provisioning, the ASDL does not fail and the work order remains in an In Progress status. The SARM sends an event notification to the SRP, gives the timed out ASDL a grace period, and continues provisioning. If the same ASDL times out again, the SARM fails the ASDL. Then the work order fails. When both the work order and the ASDL timeouts are set for a particular work order, only the first occurrence of timeout is processed and the other is ignored. The following notification events are triggered to inform the SRP of the state of the work order for both the work order and ASDL timeouts:
|
Default = 0 |
BATCH_SLEEP_INTERVAL |
The time period, in seconds, between SARM database queries for future dated orders that:
|
Default = 20 |
CORE_SQL_SERVER |
The SQL Server in which the SARM database resides. This is the same as APPL_SQL_SERVER for the SARM. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
EXP_ONLY_COMP_DEFINED_PARM |
This parameter controls the evaluation logic of ASDL spawning expressions within the SARM. If set to 1, the (sub)expression returns false if a label is not provided, except for DEF/NOTDEF cases. If set to 0, the legacy logic is used. When a label is not provided, the label name is used as the value of the label in the expression. |
Default=0 |
FAIL_WO_ON_EMPTY_CSDL |
Boolean flag. If set to 1, the CSDL triggers a work order failure if it fails to spawn any ASDLs. |
Default=0 |
INPROC_CHK_INT |
The time interval, in seconds, the SARM waits between checks of the internal queues to determine whether there are any orders in progress beyond the specified in progress threshold. See also MAX_IN_QUEUE_TM. |
Default = 900 |
MAX_IN_QUEUE_TM |
This is the time interval, in seconds, for which the SARM allows a work order to be in progress before calling the WOINPROC system event, which notifies the user that at least one work order is still in progress beyond the defined threshold. The order is not automatically failed by this mechanism. For example, a work order that requires provisioning at two different NEs, one of which is presently unavailable, could result in the SARM issuing a system event. See also INPROC_CHK_INT. |
Default = 3600 |
MAX_ORDERS_IN_GM_Q |
Limits the number of work orders the SARM keeps in memory. During each BATCH_SLEEP_INTERVAL, the Batch Handler attempts to load work orders from the SARM database that are due for provisioning. The Batch Handler does not fetch work orders from the SARM database when the number of new or reloaded messages in the Group Manager common queue exceeds MAX_ORDER_IN_GM_Q. You must correlate MAX_ORDER_IN_GM_Q with BATCH_SLEEP_INTERVAL. To do this, use the following formula: BATCH_SLEEP_INTERVAL (in seconds) x <max.# of WO per sec.>= MAX_ORDER_IN_GM_Q where: <max.# of WO per sec.> is the maximum number of work orders that the ASAP instance can provision. Examples of typical values:
Each time you add 100 to any of the above values, MAX_ORDER_IN_GM_Q can increase the amount of memory the SARM uses by up to 1 MB. A smaller value can affect performance during peak hours. If you set a smaller value, the SARM and NEPs request fewer work orders from the SARM database. |
Default = 500 |
MAX_ORDERS_IN_PROGRESS |
The maximum number of orders that the SARM allows to be in progress at any given time. This is to limit the memory requirements of the SARM should there be large numbers of orders in progress for long periods of time. If zero, this check is disabled. In production environments, ensure that the MAX_ORDERS_IN_PROGRESS parameter is not set to 0. A setting of 0 specifies no upper limit on memory consumption and can have a significant impact on performance. |
Default = 10000 |
NUM_TIMES_RETRY |
The number of times the SARM sends an ASDL to the NEP to be processed after the NEP returned it with a Fail but Retry status. A work order is failed when the number of retries equals the value specified for NUM_TIMES_RETRY. |
Default = 5 |
ORDER_TIMEOUT |
The number of seconds a particular work order can remain in progress before the SARM fails the order. The work order timer starts after the work order has been submitted and started. This threshold can be exceeded if, for example, the connection to an NE is interrupted after the connection has been established. You can set the system-wide parameter ORDER_TIMEOUT in the ASAP.cfg file. If you are using the SRP Emulator, you can also set the wo_timeout value in the tbl_wo_def table in the SRP database. The order timeout behavior is governed by two parameters: the wo_timeout parameter on the work order and the ORDER_TIMEOUT configuration parameter in ASAP.cfg. |
Default = 0 Possible values are:
|
RETRY_TIME_INTERVAL |
Time, in seconds, the SARM waits between retries of an ASDL command returned to the SARM with 'Fail but Retry' status. |
Default = 120 |
SECURITY_CHECK |
Boolean flag. Indicates whether security checking is enabled in the SARM. If set to 1, whenever the SARM receives the WO from the SRP, it checks to see if the user ID and password passed on the work order are present in the SARM database user/password table. If so, the work order is accepted, otherwise it is rejected. If security checking is 0, the work order is accepted by default. |
Default = 0 |
WO_HANDLER_TIMEOUT |
The time interval, in seconds, the SARM waits for the transmission of a work order from the SRP to the SARM before aborting the transaction. If the SRP were to terminate when it is transmitting work orders to the SARM, this condition might occur. |
Default = 60 |
WO_TIME_ESTIMATE_ON |
Boolean flag. If set to 1, it instructs the SARM to calculate the rough time estimate for completing the work order. If WO estimate notifications back to the SRP are enabled, this parameter should be set. If no WO estimate notifications are required, this parameter should not be set. |
Default = 0 |
WO_TIMEOUT_EVENT_TWICE |
Boolean flag. If set to 1, then two timeout events are generated, whenever a work order gets times out. If set to 0, then only one timeout event is raised, whenever a work order gets times out. This parameter must be added manually to set it to 0. Otherwise ASAP uses the default setting of 1. |
Default = 1 |
The following parameters are relevant to the configuration and number of threads within the SARM.
Table 9-50 lists and describes the thread configuration management parameters and values.
Table 9-50 Thread Configuration Management Parameters and Values
Parameter | Description | Value |
---|---|---|
MAX_GROUP_MGRS |
The number of group manager threads to be started by the SARM upon startup. |
Default = 5 |
MAX_PROVISION_HANDLERS |
The number of provisioning handler threads to be started by the SARM. |
Default = 5 |
SRP_READY_WAIT_TIME |
This is the time required by the SRP drivers to complete initializing before SARM starts processing work orders. If this parameter is not present, SARM may not wait for the SRP drivers to complete initializing and may begin processing work orders earlier. |
Default = 0 |
MAX_SRP_DRIVERS |
The number of SRP driver threads to be started by the SARM to communicate with each SRP server. |
Default = 2 |
MAX_WO_HANDLERS |
The number of work order handler threads to be started by the SARM. |
Default = 5 |
MAX_WO_MGRS |
The number of work order manager threads to be started by the SARM. |
Default = 5 |
This section describes the parameter used for SARM message pool size.
Table 9-51 lists and describes the SARM message pool size parameters and values.
Table 9-51 SARM Message Pool Size Parameters and Values
Parameter | Description | Value |
---|---|---|
MAX_MSGPOOL |
This parameter is used for tuning. The number of message structures available to the Open server. This parameter sets the number of message structures to be allocated at the time of start up. This number must always be greater than or equal to the value of MAX_MSGQUEUES times 256. The SARM requires a larger message pool size approximately 50% larger than the message pool size configured for Sybase Open servers, see "SARM Message Pool Size". |
Default = 106752 Recommended initial values are based on system size:
|
SARM batch error thresholds are configured using the BATCH_DELETE_DELAY and BATCH_THRESHOLD SARM parameters.
Table 9-52 lists and describes the SARM batch error thresholds parameters and values.
Table 9-52 SARM Batch Error Thresholds Parameters and Values
Parameter | Description | Value |
---|---|---|
BATCH_DELETE_DELAY |
After all the orders in the batch group are processed, the SARM does not delete the batch group until the time interval that is specified by the configuration parameter expires. Orders are released from the batch group upon completion or batch failure. Any order in the same batch group that is sent after the time interval expires is not treated as part of the batch. You can specify an error threshold for the number of failures that can occur in the batch before the SARM stops activation of that batch. The batch failure threshold value is based on the SARM configuration parameter and is not configurable by the SRP using the Batch Order Delay fail threshold. The time interval, in seconds, after the processing of the last order in the batch, that the SARM waits to remove the batch details from memory. |
Default = 60 |
BATCH_THRESHOLD |
Defines the maximum number of errors that can occur within a batch of loosely coupled requests. Batch orders are defined by means of the SRP batch order property that identified the batch to which the order belongs. Should the batch error threshold be exceeded for a particular batch, the batch as a whole will be suspended. This parameter is set for all batch work orders. You cannot set this parameter on a per work order basis. |
Default = 0 |
The LANGUAGE_OF_MSG and MESSAGE_NUMBERS parameters provide support for SARM internationalized messages.
Table 9-53 lists and describes the SARM international messages parameters and values.
Table 9-53 SARM International Messages Parameters and Values
Parameter | Description | Value |
---|---|---|
DB_MONITOR_TIME |
After all the orders in the batch group are processed, the SARM does not delete the batch group until the time interval that is specified by the configuration parameter expires. The time interval, in minutes, when the Control server monitors the database and logs segment sizes and then issues a system event if they exceed a predetermined threshold value. This functionality can be enabled within the Control server by populating the database threshold monitoring table in the Control database. Default = 20. |
Default = 60 |
LANGUAGE_OF_MSG |
The language code to determine the language in which the Service Request (SRQ) Log messages are written to the database. These messages are detailed in message conversion tables in the SARM database and allow substitution of data fields in their expansion. To use a language other than the default, insert all the relevant messages into this table with the new language code, while ensuring the same placeholder positions within the data string. Any new messages added to the SARM are added under the default language. |
Default = USA |
MAX_MAINT_INTERVAL |
Default = 0 |
|
MESSAGE_NUMBERS |
Boolean flag. If set to 1, it causes the SARM to write only the message IDs from the message conversion table to the SARM database. This is used primarily in system testing and should be set to 0 in all other environments. |
Default = 0 |
SOURCE_ROUTING |
Default = 1 |
This section describes the OCA work order entry.
Table 9-54 lists and describes the OCA work order entry parameters and values.
This section describes the UNID manager.
Table 9-55 lists and describes the UNID manager parameters and values.
Table 9-55 UNID Manager Parameters and Values
Parameter | Description | Value |
---|---|---|
ASDL_LOG_UNID_JUMP_INTERVAL |
Number of ASDL LOG UNIDs to cache per work order. Reduces number of SLAVE to MASTER UNID fetch RPCs called. |
Default = 5 |
UNID_JUMP_INTERVAL |
Number of unique integers to cache in the master SARM. The larger the value, the fewer stored procedures are called to the SARM databases. This can cause UNIDs to be unused in the event that the SARM is shut down. |
Default = 1000 |
These parameters provides direct switch access capability, which must be configured in both the SARM and the NEP.
Table 9-56 lists and describes the SARM switch direct parameters and values.
Table 9-56 SARM Switch Direct Parameters and Values
Parameter | Description | Value |
---|---|---|
SWD_HOST_IPADDR |
Used for Switch Direct support. This is the Host IP Address for the machine where the SARM is running. |
Default = $SWD_HOST_IPADDR |
SWD_HOST_NAME |
Used for Switch Direct support. This is the Host Name for the machine where SARM is running. |
Default = $SWD_HOST_NAME |
SWD_IDLE_TIMEOUT |
Used for Switch Direct support. This is the idle timeout period, in seconds, for automatically disconnecting the Switch Direct Interface (SWD) session if no activity is detected. |
Default = 120 |
SWD_LISTEN_PORT |
Used for Switch Direct support. The TCP/IP port number for the SARM server for Switch Direct support. The SWD client connects to this port. |
Default = $SWD_LISTEN_PORT |
SWD_SESSIONS_SUPPORTED |
Boolean flag. If set to 1, it determines whether Switch Direct sessions are supported by the SARM. This parameter is also used by NEP applications. |
Default = 0 |
This section describes the admin server parameters.
Table 9-57 lists and describes the Admin server parameters and values.
Table 9-57 Admin Server Parameters and Values
Parameter | Description | Value |
---|---|---|
CORE_SQL_SERVER |
The SQL Server in which the SARM database resides. This is the same as APPL_SQL_SERVER for the SARM. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
CORE_USERID |
The user ID for the CORE_SQL_SERVER. |
Default = $SARM_USER |
SARM |
The logical name of the SARM server to which the SRP will establish network connections. |
Default = $SARM |
This section describes persistent ADM data in SARM.
Table 9-58 lists and describes the Persistent ADM data in SARM parameters and values.
Table 9-58 Persistent ADM Data in SARM Parameters and Values
Parameter | Description | Value |
---|---|---|
ADM_SQL_SVR |
The database where ADM tables reside. |
Default = $DSQUERY |
ADM_USER |
The database user ID for ADM_SQL_SVR. |
Default = $ADM_USER |
LOAD_PERSISTENT_DATA |
Boolean flag. If set to 1, it loads the last known data from the ADMIN database into the SARM's memory. This prevents jumps or gaps in the statistical data. |
Default = 1 |
This section describes the socket connections.
Table 9-59 lists and describes the socket connections parameters and values.
Table 9-59 Socket Connections Parameters and Values
Parameter | Description | Value |
---|---|---|
MAX_CLIENT_CONN |
This parameter defines the maximum number of socket connections that the SARM can create to receive RPC requests from the SRP. This value can be tuned to meet the actual need of the connections. One connection corresponds to one thread in SARM, so this value should be less than MAX_SERVER_PROCS (default = 512) Also, the maximum capacity of the connection pool is defined in the jconnector in the JSRP and should not exceed the value of MAX_CLIENT_CONN. To configure the Maximum Capacity parameter through the WebLogic Server Administration Console:
You can determine whether the maximum connections threshold is reached through the SARM diagnostic file. |
Default = 100 |
Use the following parameters to configure various aspects of the database administration thread in each application server. This calls a stored procedure in the database and passes it a configurable parameter before recompiling all the stored procedures in that application server's default database (the database defaulted to using the APPL_SQL_SERVER, and APPL_USERID login information). It also updates the SQL Server statistics for all indexes on user-defined tables in the database.
Table 9-60 lists and describes the SARM database administration parameters and values.
Table 9-60 SARM Database Administration Parameters and Values
Parameter | Description | Value |
---|---|---|
DB_ADMIN_ON |
Boolean flag. If set to 1, it enables the database administration thread operation in the application server. This can be disabled in particular servers in situations where multiple servers share the same application database and then only one server is required to perform this database administration. |
Default = 0 |
DB_ADMIN_PROC_PARAM |
The integer parameter passed to the database administration procedure. For example, this can specify a purge interval for a particular database. |
Default = 100 |
DB_ADMIN_PROC |
The procedure the database administration thread calls at a specified time in the day. This procedure could perform many tasks, including archiving and purging of dynamic data. All stored procedures in the database are recompiled and the statistics updated after this administration procedure has been called. |
Default = SSP_db_admin |
DB_ADMIN_TIME |
The number of minutes after midnight when the database administration tasks are to be performed. This is usually performed at a time of low system activity. |
Default = 300 |
DB_PCT_ANALYZE |
This parameter applies to Oracle Database only. It is used to update statistics on all user-defined tables. The updates are done when the database administrations tasks are performed. (See also DB_ADMIN_TIME.) This parameter is used to optimize the database query performance. The Oracle SQL statement is "analyze table table_name estimate statistics sample DB_PCT_ANALYZE percent". See the discussion on the Analyze command in Oracle SQL Reference Manual. |
Default = 20 |
This section describes NEP server configuration parameters.
Table 9-61 lists and describes the NEP server configuration parameters and values.
Table 9-61 NEP Server Configuration Parameters and Values
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $NEP_USER |
AUTOMATIC_BLACKOUT_CHECK |
If set to greater than 0, the NEP will check for NE blackout prior to connection and State Table execution. |
Default = 0 |
CACHE_BLACKOUT_TABLE |
If set to greater than 0, the NEP will cache the blackout table and check blackouts using this cached table. If set to 0, the table will not be cached and the database will be queried when blackout is checked. This parameter influences only automatic blackout checking. |
Default = 1 |
LOAD_JCLASS_FROM_DB |
Indicates that the provisioning and connection classes should be loaded from:
|
Default = 0 |
NEP_USERID |
The user ID the Interpreter uses to open network connections to the SQL Server to access the Interpreter database. For an interpreter in an NEP, this is the NEP user ID. For an interpreter in an SRP, this is the SRP user ID. The default database for this user is the location of any tables, stored procedures, etc., required by the Interpreter in its processing. Maximum length is 20 alphanumeric characters. |
Default = $NEP_USER |
RESPONSE_LOG_FILE_APPEND |
If set to 0, the Java-enabled NEP (JNEP) does not append a new response log to the existing log file with the same name when the startResponseLog() method is called. This parameter is used in only JNEP and does not take affect the response log in the State Table. |
Default = 1, could be absent in the ASAP.cfg file. |
PRE_EMPTIVE |
Boolean flag. If set to 1, you can enable this flag in the NEP to allow the NEP to use pre-emptive threading, which improves NEP efficiency. Note that pre-emptive threading is CPU-intensive. |
Default = 0 |
This section describes the ADM server configuration parameters.
Table 9-62 lists and describes the ADM server configuration parameters and values.
Table 9-62 ADM Server Configuration Parameters and Values
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length is 20 alphanumeric characters. |
Default = $ADM_USER |
COPY_DOWN_DATA |
Boolean flag. If set to 1, writes information to the performance-related tables with the value of D in the Record Type field. |
Default = 0 |
POLL_TIMER_ASDL |
Polling time, in minutes, for querying ASDL-related statistics from the SARM. |
Default = 30 |
POLL_TIMER_CSDL |
Polling time, in minutes, for querying CSDL-related statistics from the SARM. |
Default = 30 |
POLL_TIMER_NE |
Polling time, in minutes, for querying network-element-related statistics from the SARM. |
Default = 30 |
POLL_TIMER_NE_ASDL |
Polling time, in minutes, for querying network-element/ASDL-related statistics from the SARM. |
Default = 30 |
POLL_TIMER_ORDER |
Polling time, in minutes, for querying order-related statistics from the SARM. |
Default = 30 |
Use the following parameters to configure various aspects of the database administration thread in each application server. This calls a stored procedure in the database and passes it a configurable parameter before recompiling all the stored procedures in that application server's default database (the database defaulted to using APPL_SQL_SERVER, and APPL_USERID login information). It also updates the SQL Server statistics for all indexes on user-defined tables in the database.
Table 9-63 lists and describes the Admin database administration parameters and values.
Table 9-63 Admin Database Administration Parameters and Values
Parameter | Description | Value |
---|---|---|
DB_ADMIN_ON |
Boolean flag. If set to 1, it enables the database administration thread operation in the application server. This can be disabled in particular servers in situations where multiple servers share the same application database and then only one server is required to perform this database administration. |
Default = 0 |
DB_ADMIN_PROC_PARAM |
The integer parameter passed to the database administration procedure. For example, this can specify a purge interval for a particular database. |
Default = 100 |
DB_ADMIN_PROC |
The procedure the database administration thread calls at a specified time in the day. This procedure could perform many tasks, including archiving and purging of dynamic data. All stored procedures in the database are recompiled and the statistics updated after this administration procedure has been called. |
Default = PSP_db_admin |
DB_ADMIN_TIME |
The number of minutes after midnight when the database administration tasks are to be performed. This is usually performed at a time of low system activity. |
Default = 300 |
DB_PCT_ANALYZE |
This parameter applies to Oracle only. It is used to update statistics on all user-defined tables. The updates are done when the database administrations tasks are performed. (See also DB_ADMIN_TIME.) This parameter is used to optimize the database query performance. The Oracle SQL statement is "analyze table table_name estimate statistics sample DB_PCT_ANALYZE percent". See the discussion on the Analyze command in Oracle SQL Reference Manual. |
Default = 20 |
This section describes generic EDD API parameters.
Table 9-64 lists and describes the generic EDD API parameters and values.
Table 9-64 Generic EDD API Parameters and Values
Parameter | Description | Value |
---|---|---|
APPL_USERID |
The primary SQL Server user ID the application process uses to connect to the APPL_SQL_SERVER SQL Server. The user ID defaults to the primary application database, and therefore, the application does not need database names because the definition of the user in the SQL Server specifies that user's default database. Maximum length 20 alphanumeric characters. |
Default = $CTRL_USER |
External device driver applications link in libgedd, libclient, and libasc. Therefore, they require the libgedd, libclient, and libasc configuration parameter definitions in addition to the ones outlined below.
Table 9-65 lists and describes the BX25_EDD configuration parameter and values.
This section describes the PADEDD configuration parameters.
Table 9-66 lists and describes the PADEDD configuration parameter and values.
This section describes the UTILITY configuration parameters.
Table 9-67 lists and describes the UTILITY configuration parameters and values.
Table 9-67 UTILITY Configuration Parameters and Values
Parameter | Description | Value |
---|---|---|
CONTROL_SQL_SERVER |
The SQL Server where the Control database resides. If specified, the Control database can reside on a separate SQL Server from the application databases, if required. Maximum length is eight alphanumeric characters. |
Default = $DSQUERY |
CONTROL_USERID |
The SQL Server user ID the application process uses to connect to the Control database in the CONTROL_SQL_SERVER SQL Server. Maximum length is 20 alphanumeric characters. |
Default = $CTRL_USER |
This section describes the login information for SARM database.
Table 9-68 lists and describes the login information for the SARM database parameters and values.
Table 9-68 Login Information for the SARM Database Parameters and Values
Parameter | Description | Value |
---|---|---|
SARM_USER |
SARM user ID. |
Default = $SARM_USER |
SARM_SQL_SVR |
SARM server where the database resides. |
Default = $DSQUERY |
SARM_POOL_SIZE |
Number of database connections to the SARM database to maintain in the connection pool. |
Default = 7 |
This section describes login information for ADM DB.
Table 9-69 lists and describes the login information for ADM database parameters and values.