B Stored Procedures (Deprecated)

This appendix provides information about stored procedures.

Configuring an SRP Using Stored Procedures

This section describes the basic SRP configuration steps using stored procedures. When configuring an SRP, you must first configure the basics before configuring a specific SRP type.

SRP configuration information is located in static tables in the ASAP Control server database and the SARM database.

To add an SRP to the system, perform the following steps:

• Adding the SRP to the ASAP Start-up Procedures

• Defining the SRP as an ASAP Component

• Adding the SRP to the SARM Database

• Registering the SRP

• Set Configuration Parameters by manually editing the ASAP.cfg file. See "Configuration Parameters"

Adding the SRP to the ASAP Start-up Procedures

The static table tbl_appl_proc contains ASAP application information. You must populate this table to identify the SRP as an ASAP application and add the SRP to the ASAP start-up procedure. The ASAP startup procedure uses tbl_appl_proc to determine what applications to start, and the startup sequence.

Note: This procedure does not apply to the Java SRP and OCA SRP.

For more information on tbl_appl_proc, see the ASAP Developer Reference.

Use the following stored procedures to define, delete, and list ASAP client or server applications:

• CSP_new_appl – Defines a new ASAP client or server application.

• CSP_del_appl – Deletes an ASAP client or server application.

• CSP_list_appl – Lists ASAP application registration information for the specified application or for all applications in the Control database.

For more information on these stored procedures, see the ASAP Developer Reference.

Defining the SRP as an ASAP Component

The static table tbl_component contains a list of ASAP components for each ASAP territory and system. You must populate this table to add the SRP as an ASAP component.

For more information on tbl_component, see the ASAP Developer Reference.

Use the following stored procedures to define, delete, and list ASAP components in a territory:

• CSP_new_component – Defines an ASAP component within a territory.

• CSP_del_component – Deletes an ASAP component from a territory.

• CSP_list_component – Lists ASAP components.

For more information on these stored procedures, see the ASAP Developer Reference.

Adding the SRP to the SARM Database

The static table tbl_asap_srp defines an SRP in ASAP. You must populate this table to add the SRP to the SARM database. Any ASAP application process that communicates with the SARM as an SRP using the SRP API must be defined in this table.

For more information on tbl_asap_srp, see the ASAP Developer Reference.

Use the following stored procedures to define, delete, and list SRPs in the system:

• SSP_new_srp – Defines an SRP for the system in the SARM database.

• SSP_del_srp – Deletes an SRP from the SARM database.

• SSP_list_srp – Lists SRP definitions

For more information on these stored procedures, see the ASAP Developer Reference.

Registering the SRP

This step applies to C SRP APIs only.

For more information on configuring the OCA SRP, see "About JSRP, Web Service, and OCA SRP Components". For more information on configuring the C++ SRP, see "Using the C++ SRP API". For instructions on configuring the Java SRP, see "About JSRP, Web Service, and OCA SRP Components".

Sybase Open Client/Open Server comes bundled with ASAP and is installed automatically during ASAP installation.

The ASAP administrator or DBA must register the SRP by editing the Sybase interfaces file as follows:

• Add the ASAP component server names.

• Specify the service as “tcp” (on Oracle , specify “tcl tcp”).

• Assign port numbers for the servers.

Use the dsedit utility located in the $SYBASE/SYBASE_OCS/bin directory to perform these procedures. Before using dsedit, do the following:

• Log on as the asap user.

• Ensure that the $SYBASE variable points to the ASAP_Home/SYBASE directory, where ASAP_Home is the directory in which ASAP is installed.

• Set the $DISPLAY variable by typing:

  export DISPLAY=<your IP address>:0.0
  

• Ensure that the $LANG variable is set to English. If you are currently using a non-English language setting, you must temporarily set the $LANG variable to English by typing:

  export LANG=C
  

Configuring NEPs Using Stored Procedures

The configuration of an NEP using stored procedures requires the following steps:

• Adding the NEP to ASAP Start-up Procedures

• Adding the NEP as an ASAP Component

• Adding the NEP to the SARM Database

• Adding the NEP to the Sybase Interfaces File

• Configuring Ports for the JInterpreter

These configuration procedures apply to all NEP core and optional components. These include EDD, SNMP, and generic communication protocols (such as Telnet, FTP, Serial, and socket).

Adding the NEP to ASAP Start-up Procedures

tbl_appl_proc is a static table that contains ASAP application information. ASAP uses this table to determine which applications to start, and the startup sequence. You must populate this table to add an NEP to the startup procedure.

Use the following stored procedures to define, list, and delete ASAP client or server applications:

• CSP_new_appl – This stored procedure defines a new ASAP client or server application.

• CSP_list_appl – This stored procedure lists ASAP application registration information for the specified appl_cd or all applications from the Control database.

• CSP_del_appl – This stored procedure deletes ASAP Application registration information from the Control database.

For more information on these stored procedures and “tbl_appl_proc”, refer to the ASAP Developer Reference.

Adding the NEP as an ASAP Component

tbl_component is a static table that contains a list of ASAP components for each ASAP territory and system. You must populate this table to add an NEP as an ASAP component.

Use the following stored procedures to define, list, and delete ASAP components in a territory are:

• CSP_new_component – This stored procedure defines an ASAP component in a territory.

• CSP_list_component – This stored procedure lists ASAP components.

• CSP_del_component – This stored procedure deletes an ASAP component.

For more information on these stored procedures and tbl_component, refer to the ASAP Developer Reference.

Adding the NEP to the SARM Database

tbl_nep is a static table that is referenced by the SARM and the NEP. This table maintains the relationship between the NEP and the secondary pool of devices that are used by the NEP to establish auxiliary connections to host NEs. Each NEP references this table upon start up to determine the secondary pool of devices available to all session managers within that NEP. It spawns a command processor thread for each device in the secondary pool of devices. You must populate this table to configure these connections.

Use the following stored procedures to define, list, and delete the auxiliary pool of devices or connections for an NEP:

• SSP_new_nep – This stored procedure defines a secondary (dialup) pool of devices or connections for a specified NEP in the SARM database.

• SSP_del_nep – This stored procedure deletes an NEP secondary pool definition from the SARM database.

• SSP_list_nep – This stored procedure lists NEP secondary pool definitions.

For more information on these stored procedures and “tbl_nep”, refer to the ASAP Developer Reference.

Adding the NEP to the Sybase Interfaces File

You must add the NEP server to the Sybase interfaces file. For more information, refer to the ASAP Installation Guide.

Configuring Ports for the JInterpreter

You can enable or disable the JInterpreter for an NEP by defining or not defining the listener entry in tbl_listeners. If no $NEP_jlistener entry is configured for the server $NEP, the NEP is not Java-enabled. This configuration must be specified before startup; it is not runtime applicable.

During installation, ASAP defines a default NEP enabled with a JInterpreter.

Every NEP must maintain a dedicated connection to its JInterpreter (configured in tbl_listeners).

You can enable or disable the ports on the JInterpreter in one of two ways:

• Using the Service Activation Configuration Tool (SACT) – refer to

• Using the following stored procedures to define, list, and delete the auxiliary pool of devices or connections for an NEP:

  • CSP_new_listener – This stored procedure defines a listener entry for an NEP.

  • CSP_del_listener – This stored procedure deletes a listener entry for an NEP.

  • CSP_get_listener – This stored procedure lists listener entries for an NEP.

For more information on “tbl_listeners”, refer to the ASAP Developer Reference.

Configuring Multiple JInterpreters

Each NEP has an entry in tbl_appl_proc. If the NEP is java-enabled, ensure that the following conditions are met:

• There should be a corresponding entry in $SYBASE/interfaces file. See "Adding the NEP to the Sybase Interfaces File".

• There should be a corresponding entry in tbl_listeners."Configuring Ports for the JInterpreter".

• There should be a unique JInterpreter script under ASAP_Home/programs.

  The JInterpreter script located in ASAP_Home/programs directory is a template. For each NEP, copy the JInterpreter script file in the format:

$NEP_ID_jinterpreter.

For example, if you have the following NEPs:

NEP_S123, NEP1S123, NEP2S123, NEP3S123

you must copy JInterpreter script for each NEP as follows:

cp JInterpreter NEP_S123_jinterpreter

cp JInterpreter NEP1S123_jinterpreter

cp JInterpreter NEP2S123_jinterpreter

cp JInterpreter NEP3S123_jinterpreter

Additional Considerations when Configuring Multiple JInterpreters

In the situation described above, where multiple JNEPs are deployed and the Jinterpreter_<NEP> files were created by making hard copies of the Jinterpreter, additional issues should be considered.

If you deploy using SAM/Studio the file updated is the Jinterpreter file. The updates are not propagated into the additional interpreter files (e.g. NEP_S123_jinterpreter, NEP1S123_jinterpreter, NEP2S123_jinterpreter, NEP3S123_jinterpreter from the example above.) Not all the NEPs would have knowledge of what has been deployed. This implies that changes to the Jinterpreter file would have to be manually propagated to these other files or they will have to be re-copied.

If you have some Class B JNEPs, they may connect to other databases, perform many lookups, perform many file management task, ftp transfers or other tasks. In this case, some but not all of your JNEPs may need different JVM startup parameters.

Consider whether it is the best choice to start all NEPs with high JVM allocation if only a small percentage of them needs it. It may make more sense for the majority to be configured as soft links to Jinterpreter and the small percentage that need the high JVM allocation to be standalone copies.

To simplify maintenance in a case where you have added JNEPs which are all the same, consider creating a soft link to the original Jinterpreter file.

Sample Scripts

Refer to ASAP_Home\ASAP\samples\JeNEP\PLSQL for a sample Oracle script that configures ASAP for JInterpreter connectivity.

Configuring Resource Pools Using Stored Procedures

Use the following stored procedures to define, delete, and list reserouce pools:

• SSP_new_resource – This stored procedure defines an NEP resource (“device”) to be used for NE access in the SARM database.

• SSP_del_resource – This stored procedure deletes an NEP resource record from the SARM database.

• SSP_list_resource – This stored procedure lists NEP resource records.

For more information on these stored procedures and tbl_resource_pool, refer to the ASAP Developer Reference.