Managing the Application Server

The Application Server is the core of the middle tier in a TrueSight Server Automation installation. Not only does the Application Server control communication between clients and servers, it also regulates activity between the client server and the database server, file server, and mail server. The Application Server provides many adjustable parameters that enable you to scale a TrueSight Server Automation system to virtually any size. The following topics describe some of those parameters:

Tip

For the latest sizing and scalability recommendations refer to the Sizing Guide in the BMC Communities.

 You can also review guidance on appropriate settings for the configuration parameters for an Application Server in Sizing-Application-Servers.

To scale the Application Server

The Application Server provides several options that you can adjust to accommodate increased activity.
An Application Server should be configured so that even when all of its work item threads are busy, the Application Server still has additional resource capacity.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To specify the maximum number of worker threads, enter the following command:
    set appserver maxworkerthreads #
    where # is the maximum number of threads that can process requests from clients. For example, you might set this value to 10, which means that only 10 client connections can be serviced at a time even though many more users might actually be connected to the Application Server. Worker threads should not be confused with work item threads, which process Console jobs (see step 5).
  3. To specify the maximum number of client connections that the Application Server can manage, enter the following command:
    set appserver MaxClientContexts #
    where # is the maximum number of connections to clients.
  4. To specify the maximum number of jobs, enter the following command:
    set appserver MaxJobs #
    where # is the maximum number of jobs. By controlling the number of jobs that are processed simultaneously, you can avoid overtaxing Application Server resources.
    For more information and recommendations for this setting, see Recommendations for Application Servers of type Job.
  5. To specify a maximum size for the pool of threads that can be used to process Console jobs, enter the following command:
    set appserver MaxWorkItemThreads #
    where # is a number of work item threads.
    All TrueSight Server Automation jobs let you specify how many targets to process in parallel. You can set a value from 1 to 10 or allow an unlimited number of targets to be processed in parallel. The MaxWorkItemThreads and MaxLightweightWorkItemThreads (see step 6) also can control how many targets can be processed in parallel. If your system uses one Application Server, the maximum number of targets that can be processed is based on the Application Server available work item threads. If your system uses multiple Application Servers, the maximum number of targets that can be processed in parallel is based on the sum of all available work item threads on all Application Servers. When processing Deploy Jobs, work item threads often sit idle while target servers process deployment tasks. To avoid this kind of inefficiency, the Application Server can use a pool of lightweight work item threads to process phases of a Deploy Job that access target servers.
    For more information about the role of work item threads, see Work item and job execution threads.
  6. To specify a maximum size for the pool of lightweight work item threads that can be used for Deploy Jobs, enter the following command:
    set appserver MaxLightweightWorkItemThreads #
    where # is a number of lightweight work item threads. By default this value is set to 0.
    An Application Server can optionally provide a secondary pool of lightweight work item threads. These threads are only used during the Simulate and Commit phases of a Deploy Job. Lightweight work item threads primarily perform tasks on target servers and consequently consume almost no memory on an Application Server. Using lightweight work item threads helps you run more Deploy Jobs in parallel more efficiently. Other than being limited to particular types of tasks, lightweight work item threads behave exactly like work item threads.
  7. Restart the Application Server.

To set up job distribution between multiple Application Servers

When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads. They accomplish this balance by distributing the processing of entire jobs or work items for large individual jobs to other Application Servers.
For Application Servers to cooperate, they must know which Application Servers are in service. Each Application Server periodically updates its time stamp, which functions as its heartbeat. Application Servers that are cooperating monitor each other's heartbeat to determine which Application Servers are in service.

Note

For Application Servers to cooperate, the following prerequisites must be met:

  • Each Application Server must be configured to access the same database and have the same bladelogic.keystore file. For information about synchronizing bladelogic.keystore files, see Synchronizing keystore files of multiple Application Servers.
  • System clocks on all Application Servers must be synchronized to within a few seconds of each other.
  • If you are using server-side, CA-signed certificate for securing the connection between the Application Server and the RSCD Agents, each Application Server must be configured to access the same rscd.cabundle.pem file. For more information about synchronizing rscd.cabundle.pem files, see To synchronize rscd.cabundle.pem files of multiple Application Servers.
  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To specify a time span that indicates a remote Application Server has timed out, enter the following command:
    set appserver RemoteServerTimeout #
    where # is number of seconds between heartbeats before a remote Application Server is considered out of service. For example, if RemoteServerTimeout is set to 5, and 10 seconds elapse between heartbeats, the Application Server is considered out of service.
  3. To specify an interval between heartbeats for an Application Server, enter the following command:
    set appserver ServerMonitorInterval #
    where # is the frequency at which an Application Server updates its own time stamp (that is, its heartbeat). When the Application Server updates its heartbeat, it also checks for the heartbeat of remote Application Servers and updates their status accordingly. The default interval is 20 seconds.
  4. To specify a time-out for connecting to a remote Application Server, enter the following command:
    set appserver SocketConnectTimeout #
    where # is the maximum number of seconds for obtaining an initial socket connection to a remote Application Server. After that maximum is exceeded, the connection times out.
  5. To specify a time-out for responses from a remote Application Server, enter the following command:
    set appserver SocketTimeout #
    where # is the maximum number of seconds to wait for a response from an Application Server after the initial connection has already been established. After the maximum is exceeded, the connection times out.

  6. To specify that a socket connection use SSL, enter the following command:
    {{code language="none"}}
    set appserver UseSSLSockets true
    {{/code}}

    where true indicates that connections to this Application Server must be encrypted using SSL.

    Note

    When the UseSSLSockets parameter is set to true, JMX client applications (bljconsole and jmxcli) are supported only from the servers that are running Application Servers.

  7. To accept connections from other processes that are authenticated using client-side X509 certificates, enter the following command:

    set appserver RequireClientAuthentication true 
    This parameter is applicable only if SSL is enabled (using parameter UseSSLSockets). Because SSL only provides transport layer-level security, X509 client authentication makes communication with other Application Servers or client applications (such as jmxcli or bljconsole) more secure than only having an SSL connection.

    Depending on the version of the product you are using, note the behavior of the Application based on whether RequireClientAuthentication is set to true or false.

    Value of RequireClientAuthentication

    Versions earlier than 8.9.01.001

    Versions 8.9.01.001 and later

    true

    Application Server accepts connections with or without client-side authentication.

    Application Server only accepts connections with client-side authentication.

    false (default)

    Application Server accepts connections irrespective of client-side authentication.

    Application Server accepts connections with or without client-side authentication.

  8. To specify a port used for communication between Application Servers, enter the following command:
    set appserver RegistryPort #
    where # is a port number. By default the RegistryPort is set to 9836.
  9. Restart the Application Server.

Considerations for troubleshooting jobs in a MAS environment

Each Application Server has a log file that contains information about what is being executed on that Application Server. When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads, which means that the log information is also distributed.

For example, you might have two physical Application Servers (appserver1 and appserver2), with one job server running on each, and the Distribution Manager is dynamically allocating resources and running jobs on both Application Servers as needed. In this example, the logging information for the job is actually distributed between the log files on both appserver1 and appserver2. Therefore you would need to review the log files on both Application Servers.
By default, the Application Server log file, appserver.log, is located in /opt/bmc/bladeLogic/NSH/br (on UNIX) or installationDirectory\BladeLogic\NSH\br (on Windows). Additional log files are generated for each individual Application Server deployment (deploymentProfileName.log) in the same location.

Job distribution and job priority in a multiple Application Server environment

You can use the PRIORITY* property to mark a job, or a class of jobs, with a relatively higher priority to ensure they are executed first in case of resource contention. You can assign one of any of the following priorities: Critical, High, Normal, Low, and Lowest. By default, all job types have a priority of Normal. Note that these priority levels are meaningful only in relation to each other.
For a list of the permissions and authorizations required to modify a job priority, see Setting-up-authorizations-for-changing-job-priority and Setting-job-priority.
If you have implemented a multiple Application Server environment, note the following considerations about job priority:

  • While queuing work items across all jobs, the Distribution Manager queues work items in respect to priority. For example, if two concurrent jobs are competing for resources, the individual work items of the higher priority job are queued to be processed before the work items of the lower priority job.
  • There is no guarantee about the order of completion of each job (which is dependent on various extraneous factors including the actions performed in each job, its target vector, the responsiveness of the target space, and so on).
  • The parallelism configuration of a job can significantly impact the appearance of the effectiveness of the job's priority level, as it controls the maximum number of simultaneous work items that can be allocated for a given job. For example, consider the case of a job with a priority of Critical, but with a low maximum parallelism level. Such a job would appear to relinquish resources to a lower priority job with a high parallelism level, after the initial work item assignment quota for that Critical priority job is reached.

To synchronize keystore files of multiple Application Servers

Multiple Application Servers on different hosts can be set up to cooperate on processing jobs. (For information, see Setting up job distribution between multiple Application Servers.) For this cooperation to take place, all Application Servers must have the same bladelogic.keystore file.
To synchronize keystore files of cooperating Application Servers, perform the following steps on each cooperating Application Server:

  1. Stop the cooperating Application Server.
  2. Copy the bladelogic.keystore file from the <installationDirectory>/br/deployments directory of the central Application Server to each deployment directory of the cooperating Application Server.
  3. Using the blasadmin utility, ensure that the passwords match for bladelogic.keystore files of all deployments of the cooperating Application Server. Updating the password for one deployment will update it for all deployments. If the new bladelogic.keystore file that you copied into a deployment has a different password from that of the old bladelogic.keystore file, change the keystore password for that deployment. (If keystore passwords match, you can skip this step.)
  4. Restart the cooperating Application Servers.

To change the password needed for the bladelogic.keystore file for all Application Server deployments:

  1. On the cooperating Application Server, start the Application Server Administration console to configure all Application Servers on the host:
    blasadmin -a
    This command starts the blasadmin utility and you can enter set and show commands. All commands that you enter during the session affect all additional Application Servers configured on the same host.
  2. At the blasadmin prompt, enter:
    set appserver CertPasswd <password>
  3. Restart the cooperating Application Server services.

For a video that demonstrates how to perform this task, see Implementing-private-certificates-in-TrueSight-Server-Automation.

To synchronize rscd.cabundle.pem files of multiple Application Servers

To synchronize rscd.cabundle.pem files of cooperating Application Servers, perform the following steps on each cooperating Application Server:

  1. Stop the cooperating Application Server.
  2. Copy the rscd.cabundle.pem file from the <installationDirectory>/br/deployments directory of the central Application Server to each deployment directory of the cooperating Application Server.
  3. Restart the cooperating Application Servers.

To specify a maximum time for canceling a job part

You can specify a maximum period of time that can elapse for a job part to be canceled. If cancellation of a job part exceeds this maximum, the job part is aborted and the entire job is cancelled. In addition, the thread is marked as stuck and it cannot be used by the Application Server until the next restart. This prevents situations where cancellation of a job is not performing as expected and the act of canceling the job can potentially hang the job. The default time period is 10 minutes.

You might want to increase this time period, to allow more time for cancellation of a job part (for example, 60 or 70 minutes). If, during that time, you decide to cancel the job, you can manually abort the job in progress.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set a maximum period for job cancellation, enter the following command:
    set appserver MaxTimeForCancelToFinish #
    where # is the maximum amount of time in minutes that should elapse for job cancellation.
  3. Restart the Application Server.

To set limits for client connections

The Application Server lets you specify certain limits for connections to the Application Server, such as a prune time for idle connections or the maximum amount of time a client can perform read operations from the Application Server. If the client exceeds these maximums, the connection is closed.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To specify an idle prune time, enter the following command:
    set appserver IdleConnectionPruneTime #
    where # is a value in minutes. When there is no traffic over the connection between a client and the Application Server for this period of time, the connection is considered expired. When a new incoming connection is made, idle connections with non-zero IdleConnectionPruneTime values are checked, and the connections that have expired are pruned.
    By default this value is set to 120, and the minimum permissible value you can set is 2.
  3. To specify a time-out for client socket read operations from the Application Server, enter the following command:
    set appserver SocketTimeout #
    where # is the maximum number of seconds for client socket reads before the socket times out.
  4. Restart the Application Server.

To set time-out behavior for work item threads

The Application Server lets you specify time-out behavior for work item threads associated with job parts. Job parts are relevant only in jobs that are based on component templates — Component Discovery Job, Compliance Job, Audit Job, and Snapshot Job. By default, when one job part times out based on the value of the JOB_PART_TIMEOUT property, all other job parts that act on the same server are also canceled. This prevents situations where multiple parts in a job must time out serially on the same unresponsive server. If the job includes multiple component templates, the exact behavior depends on the job type:

  • In a Component Discovery Job, all job parts in all templates included in the job are cancelled.
  • In other job types (Compliance, Audit, and Snapshot), all job parts in the same template are cancelled, but job execution proceeds with any other templates that were included in the job.

If necessary, you can use this procedure to override the default behavior so that only one job part times out automatically in any specific job on a specific target, and the job continues executing on all other job parts.

Example

A component template contains three parts — a registry key, a configuration file, and a service. During execution of a Compliance Job, the registry key times out.  If the PropagateWorkItemTimeout is set to false (to override the default behavior described above), the registry key is skipped, but the Compliance Job will continue analyzing compliance of the configuration file and service.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set time-out behavior, enter the following command:
    set appserver PropagateWorkItemTimeout true|false
    Setting this value to true (the default) means all work item threads acting on the same server are canceled when one work item thread times out. Setting it to false means only the one work item thread is canceled.
  3. Restart the Application Server.

To enable automatic restart of provisioning jobs after Application Server restart

A restart of an Application Server cancels provisioning jobs that have been submitted but are waiting idle (for example, a job waiting for the PXE client to boot). To ensure that these jobs are automatically restarted when the Application Server restarts, use this procedure.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enable automatic restart of Provision Jobs by entering the following command:
    set appserver restartIdleProvisionJobs true
  3. Restart the Application Server.

To set the outcome of Update Server Properties Jobs when target agents are unreachable, not licensed, or not accessible by user

By default, an Update Server Properties Job always ends successfully, even if the RSCD agents on the remote target servers are unreachable, not licensed, or not accessible by the user because the AGENT_STATUS property for the target servers is updated in any case. You can, however, set the Update Server Properties Job to end in failed status whenever agents do not respond or when the user does not have access to agent.

If a server has the IS_ONLINE property set to false, the Update Server Properties Job result for that server shows the status to be Offline.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Set the outcome of Update Server Properties Jobs by entering the following command:
    set JobFactory UspJobSucceedsWhenAgentDown true|false
    The default value is true. Setting the value to false means that the Update Server Properties Job is reported (in the log and in the display of job results) as having ended in failed status if the agent on the remote target is unreachable, not licensed, or not accessible by the user.

For more information, see Creating-or-modifying-Update-Server-Properties-Jobs.

To limit the number of targets that can be assigned to a job

You can limit the number of targets that can be assigned to a job during job creation, job modification, or job execution against specific targets. To limit the number of targets allowed in jobs, you use a pair of blasadmin parameters. This maximum number of targets is applied to jobs of the following types: Audit Job, Compliance Job, Component Discovery Job, SCAP Compliance Job, Snapshot Job, Deploy Job, NSH Script Job, ACL Push Job, Update Server Properties Job, and Patch Job.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Activate the limit of targets in jobs by entering the following command:
    set JobFactory LIMITMAXTARGETSINJOB true
    The default value of this parameter is false.
  3. Set the maximum number of targets allowed in a job by entering the following command:
    set JobFactory MAXTARGETSINJOB #
    where # is a the maximum number of targets that can be assigned to a job.

To set a maximum number of Compliance Results displayed

The Application Server lets you specify the maximum number of compliance results that are displayed for any failed condition in a compliance rule. A Compliance Job examines a component and compares its parts to conditions defined in compliance rules for a component template. Parts that do not comply are shown in Compliance Job results. If you are running a Compliance Job that examines many server objects that fail a compliance condition, you might tax your system resources, particularly disk space. If results for a Compliance Job exceed the limits you set in this procedure, the job run is marked with a warning and the job log includes a message saying that job results have been truncated.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set a maximum for compliance results displayed, enter the following command:
    set appserver ComplianceResultMaxNumberOfAssets #
    where # is a the maximum number of server objects displayed per failed condition in a compliance rule.
  3. Restart the Application Server.

To set behavior for past due jobs

The Application Server lets you specify a period of time that a newly created job can remain in a queue while the Application Server is down or too busy to process the job. The period of time is measured from the scheduled occurrence of the job to the time the Application Server starts. Setting a value for this option specifies that if you restart the Application Server and the specified period has:

  • Not elapsed, the scheduled occurrence of a one-time-only job is not executed but the scheduled occurrence of a recurring job is executed.
  • Elapsed, the scheduled occurrence of a job is not executed.
  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set past due job execution behavior, enter the following command:
    set scheduler MaxJobTimeInSchedulerQ #
    where # is a value in minutes. By default this value is set to 60. Setting this value to 0 means that all past due jobs are executed when the Application Server starts.
  3. Restart the Application Server.

To set the number of database connections

Use this procedure to set maximums and minimums for database connections. You can set the maximum and minimum number of database connections that jobs use. You can also set the maximum and minimum number of database connections used for general, non-job-related purposes, such as client connections to the database. By providing separate settings for job-related and non-job-related activity, you can help to prevent situations where client connections seem to hang because large jobs are using all available database connections.

Note

The sum of the maximum numbers that you define for MaxJobExecutionConnections, MaxClientConnections, and MaxGeneralConnections cannot exceed the connection limit specified by the database server.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.

  2. To set a maximum and minimum number of job-related database connections, use either of the following commands:
    set database MaxJobExecutionConnections #
    set database MinJobExecutionConnections #
    where #is a number of database connections. Note that the job-related database connection is set to 1 even if you set MaxJobExecutionConnections=0.

    Note

    Values that you set for job-related database connections are actually divided across two job connection pools, with 75% of the value that you set applied to a primary pool and 25% to a secondary pool that is reserved for nested jobs. This means that you might run out of job-related connections sooner than expected, as discussed in Troubleshooting-the-Application-Server.

  3. To set a maximum and minimum number of non-job-related database connections, use either of the following commands:
    set database MaxGeneralConnections #
    set database MinGeneralConnections #
    where # is a number of database connections.
  4. Restart the Application Server.

To set up HTTP proxy server support

This procedure describes how to set up a user name and password for authentication on an HTTP proxy server. Many organizations provide Internet access through a proxy server. If the HTTP proxy server authenticates users, it requires a user name and password, which the Application Server can provide if you perform the following procedure.

Note

The patch management component of TrueSight Server Automation incorporates the ability to download files from the Internet. Both the Catalog Update and Patch Download Jobs require proxy server settings that are operating-system specific. To eliminate the possibility of overwriting proxy server settings defined for the Application Server, or having to change these settings, these jobs do not use the same proxy server settings as the Application Server. For more information about setting the proxy server settings for patch management, see Configuring global configuration parameters.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To identify a proxy server, enter the following command:
    set appserver HTTPProxyName <serverName>
    where <serverName> is the name of the HTTP proxy server.
  3. To specify a listening port for the HTTP proxy server, enter the following command:
    set appserver HTTPProxyPort #
    where # is the port used to contact the proxy server.
  4. To specify a user name provided to the HTTP proxy server, enter the following command:
    set appserver HTTPProxyUser <userName>
    where <userName> is the name of a valid user on the proxy server.
  5. To specify a password, enter the following command:
    set appserver HTTPProxyPassword <password>
    where <password> is the password assigned to the proxy user you identified in the previous step.
  6. Restart the Application Server.

To bind the Application Server to an IP address

Use this procedure to specify an IP address to which an Application Server should listen. You can also instruct the Application Server to listen for connections on all of its IP addresses. This procedure is primarily useful when an Application Server has more than one network interface and you want the Application Server to listen for connections on only one.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To specify an IP address to which the Application Server should listen, enter the following command:
    set appserver SocketsBindAddress <IP_address>|all
    In the command shown above <IP_address> is the IP address (IPv4 or IPv6) or host name to which the Application Server should listen. If you do not specify an IP address or host name, the Application Server listens on all of its IP addresses. Similarly, if you enter all in the command shown above, the Application Server listens on all IP addresses. If you have previously instructed an Application Server to listen for a specific IP address, you must use all in this command to change those instructions so the Application Server listens on all IP addresses.
  3. Restart the Application Server.

To enable and disable Network Shell proxy inspection

To ensure data integrity, TrueSight Server Automation inspects data packets traveling between Network Shell clients and proxy servers. When this inspection reveals a problem, the packet is not delivered. You can use this procedure to turn off packet inspection.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enable or disable packet inspection by entering the following command:
    set appserver EnableProxyInspection true | false
    where false turns off proxy inspection and true turns it on. By default proxy inspection is turned on.
  3. Restart the Application Server.

To control Network Shell proxy sessions

To ensure proper performance of connections between clients and Application Servers of type NSH_Proxy, you can set a connection session timeout for the NSH proxy. Such session timeouts minimize the number of handshakes that take place during the connection between the client and NSH proxy.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enter the following command:
    set appserver NshProxyApplicationSessionTimeOut # 
    where # is the number of seconds to allow the NSH proxy session to remain active based on the last authentication credentials that were provided, before timing out. 
  3. Restart the Application Server.

As of patch 1 for version 8.7 (that is, version 8.7.00.001), you can, instead, control this timeout using a configuration file. Create a configuration file, openssl_sessions.cnf in <install-dir>/rscd. In this configuration file, include the following two parameters:

  • session_reuse: The number of times an NSH session can be reused. To disable the reuse of sessions, assign a value of 0; to enable it, assign a value of 1 or more.
  • session_timeout: Amount of time in seconds after which the NSH session will time out. Note that the default timeout is 86400 seconds (24 hours).
Example
session_reuse=1
session_timeout=600

Note

This mechanism generates temporary files that contain encrypted session information. These temporary files accumulate in the RSCD/sessions folder on the agent. You can use a script provided by BMC to clean up these temporary files; obtain this script from BMC Communities. This cleanup script is necessary only in product version 8.7.00. As of version 8.7.00.001 (Patch 1 for 8.7.00), the temporary files from NSH proxy sessions are automatically deleted when the NSH session times out or is closed and a new session is activated.

To control NSH proxy tunneling

TrueSight Server Automation offers a tunneling mechanism that provides high efficiency and quick throughput in the communication between clients and Application Servers of type NSH_Proxy. A blasadmin parameter is available for controlling the use of this communication mechanism.

Note

Do not use the NSH proxy tunneling mechanism in the following cases:

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enable or disable NSH proxy tunneling by entering the following command:
  3. set appserver EnableProxyTunneling true | false
    where false turns off NSH proxy tunneling and true turns it on. The default state is NSH proxy tunneling turned off.
  4. Restart the Application Server.

To control enhanced handling of OS-level exceptions by the Application Server

Various OS-level exceptions from the Windows Structured Exception Handling (SEH) mechanism or from Linux signals can be recognized and properly handled by the TrueSight Server Automation Application Server. New error messages are written to the Application Server log (appserver.log), and Application Server crashes are avoided. A blasadmin parameter enables you to control this mechanism.

Click here for more information about the exceptions and signals handled by this mechanism:
  • For Windows exceptions, see the list and descriptions of exceptions returned by the GetExceptionCode macro, in the Windows Dev Center.
  • The following Linux signals are handled by this mechanism:
    • SIGFPE
    • SIGILL
    • SIGSEGV
    • SIGBUS
    • SIGTRAP
    • SIGABRT
  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enable or disable enhanced handling of OS-level exceptions by entering the following command:
    set appserver EnableSignalHandling true | false
    where true turns on enhanced signal handling and false turns it off.
    The default state is enhanced signal handling turned off. You turn it on only if you know that specific exceptions can be ignored.
  3. Restart the Application Server.

To ensure version compatibility between Application Server and client

To ensure that a connection does not take place when an Application Server and client are at different versions, you can set up a version compatibility check. This check compares the version numbers of the client and the Application Server, at a level of detail you specify. If the version numbers are not the same, the Application Server refuses the connection.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. Enter the following command:
    set appserver VersionCompatibilityCheck major|minor|micro|build
    (In the version number 8.1.0.125, 8 is the major part, 1 is the minor part, and so on.)
    major — Sets the check to compare only the major part of the version numbers.
    minor — Sets the check to compare the major and minor parts of the version numbers. This setting is the default.
    micro — Sets the check to compare the major, minor, and micro parts of the version numbers.
    build — Sets the check to compare all four parts of the version numbers.
    For example, suppose the Application Server version is 8.1.0.125 and the client version is 8.1.0.123. If you specify:
    set appserver VersionCompatibilityCheck micro
    The check would find that the version numbers are the same and allow the connection.
    If you specify:
    set appserver VersionCompatibilityCheck build
    The check would find that the version numbers differ and would refuse the connection.
  3. Restart the Application Server.

To set a maximum cache size for file system objects

The Application Server lets you specify the maximum number of file system objects that are stored in the cache. You can use this setting to improve database performance. For example, if you take a snapshot of a directory structure that contains multiple instances of the same object, the Job does not have to write the same file to the database multiple times, as the file system object is stored in the cache and can be reused.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set a maximum cache size for file system objects, enter the following command:
    set appserver FileSystemObjectCacheMaxSize #
    where # is a the maximum number of file system objects that are stored in the cache. The default value is 50000.
  3. Restart the Application Server.

To set the maximum number of items per page

The Application Server lets you specify a maximum number of records retrieved from a managed server, per page. These records are used when you are working with groups, smart groups, folders, search groups, database assets, custom objects, and server objects in the Configuration Object Dictionary, for example.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To set a maximum page size, enter the following command:
    set Paging MaxPageSize #
    where # is a the maximum number of items retrieved per page. The default value is 1000.

  3. Restart the Application Server.

    Tip

    In the Console, large numbers of objects are presented in groups of 50, by default. You can adjust this display number by selecting Window > Preferences. Expand BMC and Paging Options to change the default. You can then page through these groups to make working with large numbers of objects more manageable. You must select File > Refresh after changing the default to have the change take effect.

To control activation of the BLCLI Server service used by NSH Script Jobs

The BLCLI Server service enhances the performance of NSH Script Jobs for scripts that contain the blcli_execute command. When this service is used, execution of NSH scripts of Type 1 that run BLCLI commands on large numbers of target servers involves less resources. As a result, NSH Script Jobs take less time and do not risk crashing the Application Server. A blasadmin parameter enables you to control the use of this service. By default, the service is enabled, but you might need to disable it for troubleshooting purposes.

  1. Start the Application Server Administration console, as described in Starting-the-Application-Server-Administration-console.
  2. To turn on or turn off the BLCLI Server service, enter the following command:
    set appserver EnableBlCliServer true|false
    Setting this value to true means that the Application Server uses the BLCLI Server service when executing BLCLI commands in NSH scripts (the default).
    Setting it to false disables this service.
  3. Restart the Application Server.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*