Scaling, Distributing, and Tuning CORBA Applications

Distributing CORBA Applications

This topic includes the following sections:

This topic describes how to distribute applications in the BEA Tuxedo CORBA environment, using a CORBA application as an example.

Notes: The BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB were deprecated in Tuxedo 8.1 and are no longer supported. All BEA Tuxedo CORBA Java client and BEA Tuxedo CORBA Java client ORB text references, associated code samples, should only be used to help implement/run third party Java ORB libraries, and for programmer reference only.

Technical support for third party CORBA Java ORBs should be provided by their respective vendors. BEA Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.

Why Distribute an Application?

This topic includes the following sections:

About Distributing an Application

Distributing an application enables you to select which parts of an application should be grouped together logically and where these groups should run. You distribute an application by creating more than one entry in the GROUPS section of the UBBCONFIG file, and by dividing application resources or tasks among the groups. Creating groups of servers enables you to partition a very large application into its component business applications, and to assure that each of these into logical components is of a manageable size and in an optimal location.

Benefits of a Distributed Application

The benefits of a distributed application include:

Scalability—to increase the load that an application can sustain:

Place extra server processes in a group.
Add machines to the application and redistribute the groups across the machines.
Replicate a group onto other machines within the application and use load balancing.
Segment a database and use data-dependent routing to reach the groups dealing with these separate database segments (the BEA Tuxedo ATMI system).

With the BEA Tuxedo CORBA system, you can use factory-based routing to distribute the processing of a particular CORBA interface across multiple server groups and, if desired, across multiple machines. This feature allows you to distribute the processing load, which can prevent the processing bottlenecks that occur when concurrent, resource-intensive applications compete for the available CPU, memory, disk I/O, and network resources. For an example of using factory-based routing, see Scaling with Factory-based Routing.
For more information about BEA Tuxedo CORBA scalability features, see Scaling BEA Tuxedo CORBA Applications.

Ease of Development and Maintenance—the separation of the business application logic into services or components that communicate through well-defined messages or interfaces allows both development and maintenance to be similarly separated and thereby simplified.
Reliability—when multiple machines are in use and one fails, the remainder can continue operation. Similarly, when multiple server processes are within a group and one fails, the others are available to perform work. Finally, if a machine should fail, but there are multiple machines within the application, these other machines can be used to handle the load.
Coordination of Autonomous Actions—if you have separate applications, you can coordinate autonomous actions, as a single logical unit of work, among applications. Autonomous actions are actions that involve multiple server groups and multiple resource manager interfaces.

Characteristics of Distributing an Application

A distributed application:

Enlarges the client and/or server model.
Establishes multiple server groups.
Enables transparent access to BEA Tuxedo services or BEA Tuxedo CORBA interfaces.
In BEA Tuxedo, allows data-dependent partitioning of data.
In BEA Tuxedo CORBA, allows partitioning of CORBA objects in multiple groups across multiple machines, or distributing application factory interfaces and application interfaces.
Enables management of multiple resources.
Supports a networked model.

Using Data-dependent Routing (BEA Tuxedo ATMI Servers Only)

This topic includes the following sections:

Note: This topic applies to BEA Tuxedo servers only.

About Data-dependent Routing

Data-dependent routing is a mechanism whereby a service request is routed by a client (or a server acting as a client) to a server within a specific group based on a data value contained within the buffer that is sent. Within the internal code of a service call, BEA Tuxedo chooses a destination server by comparing a data field with the routing criteria it finds in the bulletin board shared memory.

For any given service, a routing criteria identifier can be specified in the SERVICES section of the UBBCONFIG file. The routing criteria identifier (in particular, the mapping of data ranges to server groups) is specified in the ROUTING section.

Characteristics of Data-dependent Routing

Data-dependent routing has the following characteristics:

The service request assigned to a server in the group is based on a data value.
Routing uses the bulletin board criteria and occurs in a server call.
The routing criteria identifier for a service is specified in the SERVICES section of the UBBCONFIG file.
The routing criteria identifier is defined in the ROUTING section of the UBBCONFIG file.

Sample Distributed Application

Table 3-1 illustrates how client requests are routed to servers. In this example, a banking application called bankapp uses data-dependent routing. For bankapp, there are three groups (BANKB1, BANKB2, and BANKB3), and two routing criteria (Account_ID and Branch_ID). The services WITHDRAW, DEPOSIT, and INQUIRY are routed using the Account_ID field. The services OPEN and CLOSE are routed using the Branch_ID field.

Table 3-1 Data-dependent Routing Criteria for Sample Distributed Application

Server Group	Routing Criteria	Services
`BANKB1`	`Account_ID: 10000 - 49999`	`WITHDRAW`, `DEPOSIT`, and `INQUIRY`
`BANKB1`	`Branch_ID: 1 - 4`	`OPEN` and `CLOSE`
`BANKB2`	`Account_ID: 50000 - 79999`	`WITHDRAW`, `DEPOSIT`, and `INQUIRY`
`BANKB2`	`Branch_ID: 5 - 7`	`OPEN` and `CLOSE`
`BANKB3`	`Account_ID: 80000 - 109999`	`WITHDRAW`, `DEPOSIT`, and `INQUIRY`
`BANKB3`	`Branch_ID: 8 - 10`	`OPEN` and `CLOSE`

Example of UBBCONFIG Sections in a Distributed Application

Listing 3-1 shows a sample UBBCONFIG file that contains the GROUPS, SERVICES, and ROUTING sections of a configuration file to accomplish data-dependent routing in the BEA Tuxedo system.

Listing 3-1 Sample UBBCONFIG File

*GROUPS
BANKB1            GRPNO=1
BANKB2            GRPNO=2
BANKB3            GRPNO=3
#
*SERVICES
WITHDRAW          ROUTING=ACCOUNT_ID
DEPOSIT           ROUTING=ACCOUNT_ID
INQUIRY           ROUTING=ACCOUNT_ID
OPEN_ACCT         ROUTING=BRANCH_ID
CLOSE_ACCT        ROUTING=BRANCH_ID
#
*ROUTING
ACCOUNT_ID        FIELD=ACCOUNT_ID BUFTYPE="FML"
                   RANGES="MIN - 9999:*,
                      10000-49999:BANKB1,
                      50000-79999:BANKB2,
                      80000-109999:BANKB3,
                      *:*"
BRANCH_ID         FIELD=BRANCH_ID BUFTYPE="FML"
                   RANGES="MIN - 0:*,
                      1-4:BANKB1,
                      5-7:BANKB2,
                      8-10:BANKB3,
                        *:*"

Configuring the UBBCONFIG File

This topic includes the following sections:

For more information about the UBBCONFIG file, see "Creating a Configuration File" in Setting Up a BEA Tuxedo Application.

About the UBBCONFIG File in Distributed Applications

The UBBCONFIG file contains a description of either data-dependent routing (BEA Tuxedo) or factory-based routing (BEA Tuxedo CORBA), as follows:

The GROUPS section is populated with as many server groups as are required for distributing the system. This allows the system to route a request to a server in a specific group. These groups can all reside on the same site (SHM mode) or, if there is networking, the groups can reside on different sites (MP mode).
For data-dependent routing in BEA Tuxedo, the SERVICES section must list the routing criteria for each service that uses the ROUTING parameter.

Note: If a service has multiple entries, each with a different SRVGRP parameter, all such entries must set ROUTING the same way to ensure consistency for that service. A service can route only on one field, which must be the same for all the same services.

For factory-based routing in BEA Tuxedo CORBA, the INTERFACES section must list the name of the routing criteria for each CORBA interface that uses the FACTORYROUTING parameter. This parameter is set to the name of a routing criteria defined in the ROUTING section.
Add a ROUTING section to the configuration file to show mappings between data ranges and groups so that the system can send the request to a server in a specific group. Each ROUTING section item contains an identifier that is used in the INTERFACES section (for BEA Tuxedo ATMI) or in the SERVICES section (for BEA Tuxedo).

Modifying the GROUPS Section

The parameters in the GROUPS section implement two important aspects of distributed transaction processing:

They associate a group of servers with a particular LMID and a particular instance of a resource manager.
By allowing a second LMID to be associated with the server group, they name an alternate machine to which a group of servers can be migrated if the MIGRATE option is specified.

Table 3-2 describes the parameters in the GROUPS section.

Table 3-2 Parameters Specified in the GROUPS Section

Parameter	Meaning
`LMID`	`LMID` must be assigned in the `MACHINES` section to indicate that this server group runs on this particular machine. A second `LMID` value can be specified (separated from the first by a comma) to name an alternate machine to which this server group can be migrated if the `MIGRATE` option has been specified. Servers in the group must specify `RESTART=Y` to migrate.
`GRPNO`	`A`ssociates a numeric group number with this server group. The number must be greater than zero (0) and less than 30000. It must be unique among entries in the `GROUPS` section in this configuration file. (Required)
`TMSNAME`	Specifies which transaction management server (`TMS`) should be associated with this server group.
`TMSCOUNT`	Specifies how many copies of `TMSNAME` should be started for this server group. The minimum value is `2`. If not specified, the default is `3`. All `TMSNAME` servers started for a server group are automatically set up in an `MSSQ` set. (Optional)
`OPENINFO`	Specifies information needed to open a particular instance of a particular resource manager, or it indicates that such information is not required for this server group. When a resource manager is named in the `OPENINFO` parameter, information such as the name of the database and the access mode is included. The entire value string must be enclosed in double quotes and must not be more than 256 characters. The format of the `OPENINFO` string is dependent on the requirements of the vendor providing the underlying resource manager. The string required by the vendor must be prefixed with `rm_name`:, which is the published name of the vendor's transaction (XA) interface followed immediately by a colon (`:`). The `OPENINFO` parameter is ignored if `TMSNAME` is not set or is set to `TMS`. If `TMSNAME` is set but the `OPENINFO` string is set to the null string (`""`) or if this parameter does not appear on the entry, it means that a resource manager exists for the group but does not require any information for executing an open operation.
`CLOSEINFO`	Specifies information the resource manager needs when closing a database. The parameter can be omitted or the null string can be specified. The default is the null string.

Modifying the SERVICES Section

The SERVICES section contains parameters that control the way application services are handled. An entry line in this section is associated with a service by its identifier name. Because the same service can be link edited with more than one server, the SRVGRP parameter is provided to tie the parameters for an instance of a service to a particular group of servers.

Parameters to Modify

Two parameters in the SERVICES section are particularly related to distributed transaction processing (DTP) for BEA Tuxedo CORBA applications that use BEA Tuxedo ATMI services: AUTOTRAN, and TRANTIME.

Table 3-4 describes the parameters in the SERVICES section.

Table 3-3 Parameters Specified in the SERVICES Section

Parameter	Meaning
`AUTOTRAN`	Determines whether a transaction should be started automatically if a message received by this service is not already in transaction mode.The default is `N`. Use of the parameter should be coordinated with the programmers that code the services for your application.
`TRANTIME`	Specifies a timeout value, in seconds, for transactions automatically started in this service. The default is 30 seconds. Required only if `AUTOTRAN=Y` and another timeout value is needed.

Sample SERVICES Section

Listing 3-2 shows a sample SERVICES section.

Listing 3-2 Production Sample SERVICES Section

*SERVICES

    # Publish Tuxedo Teller application services
    #
    DEBIT
        AUTOTRAN=Y
    CREDIT
        AUTOTRAN=Y
    CURRBALANCE
        AUTOTRAN=Y

Modifying the INTERFACES Section

The INTERFACES section contains parameters that control the way application interfaces are handled. An entry line in this section is associated with an interface by its identifier name. Because the same interface can be link edited with more than one server, the SRVGRP parameter is provided to tie the parameters for an instance of a interface to a particular group of servers.

Parameters to Modify

Three parameters in the INTERFACES section are particularly related to distributed transaction processing (DTP): FACTORYROUTING, AUTOTRAN, and TRANTIME.

Table 3-4 describes the parameters in the INTERFACES section.

Table 3-4 Parameters Specified in the INTERFACES Section

Parameter	Meaning
`FACTORYROUTING = criterion-name`	Specifies the name of the routing criteria to be used for factory-based routing for this BEA Tuxedo CORBA interface. You must specify a `FACTORYROUTING` parameter for interfaces requesting factory-based routing.
`AUTOTRAN`	Determines whether a transaction should be started automatically if a message received by this interface is not already in transaction mode.The default is `N`. Use of this parameter should be coordinated with the programmers that code the interface for your application so that it matches the setting of the `transaction policy` option in the application's ICF file.
`TRANTIME`	Specifies a timeout value, in seconds, for transactions automatically started in this interface. The default is 30 seconds. Required only if `AUTOTRAN=Y` and a timeout value other than the default is needed.
LOAD = number	Specifies an arbitrary number between 1 and 100 that represents the relative load that the CORBA interface is expected to impose on the system. The numbering scheme is relative to the LOAD numbers assigned to other CORBA interfaces used by this application. The default is 50. This number is used by the BEA Tuxedo system to select the best server to which to route the request

Sample INTERFACES Section

Listing 3-2 shows a sample INTERFACES section.

Listing 3-3 Sample INTERFACES Section

*INTERFACES

   "IDL:beasys.com/UniversityP/Registrar:1.0"
        FACTORYROUTING = STU_ID
        AUTOTRAN=Y
        TRANTIME=50

   "IDL:beasys.com/BillingP/Teller:1.0"
        FACTORYROUTING = ACT_NUM
        AUTOTRAN=Y

Creating the ROUTING Section

For information about ROUTING parameters that support BEA Tuxedo data-dependent routing or BEA Tuxedo CORBA factory-based routing, see "Creating a Configuration File" in Setting Up a BEA Tuxedo Application.

Listing 3-4 shows the ROUTING section of the UBBCONFIG file used in the Production sample application for factory-based routing.

Listing 3-4 Production Sample ROUTING Section

*ROUTING

   STU_ID
      FIELD     = "student_id"
      TYPE      = FACTORY
      FIELDTYPE = LONG
      RANGES    = "100001-100005:ORA_GRP1,100006-100010:ORA_GRP2"

   ACT_NUM
      FIELD     = "account_number"
      TYPE      = FACTORY
      FIELDTYPE = LONG
      RANGES    = "200010-200014:APP_GRP1,200015-200019:APP_GRP2"

Configuring the factory_finder.ini (CORBA Applications Only)

For CORBA applications, to configure factory-based routing across multiple domains, you must configure the factory_finder.ini file to identify factory objects that are used in the current (local) domain but that are resident in a different (remote) domain. For more information, see "Configuring Multiple Domains Multiple Domains for CORBA Applications in Using the BEA Tuxedo Domains Component.

Modifying the Domain Gateway Configuration File to Support Routing

This topic includes the following sections:

This section is specific to BEA Tuxedo and explains how and why you need to modify the domain gateway configuration to support routing. For more information about the domain gateway configuration file, see "Configuring Multiple Domains Multiple Domains for CORBA Applications in Using the BEA Tuxedo Domains Component.

About the Domain Gateway Configuration File

The Domain gateway configuration information is stored in a binary file called BDMCONFIG. The DMCONFIG file (ASCII) is created and edited with any text editor. The compiled BDMCONFIG file can be updated while the system is running by using the dmadmin(1) command.

You must have one BDMCONFIG file for each BEA Tuxedo application that requires the Domains functionality. System access to the BDMCONFIG file is provided through the Domains administrative server, DMADM(5). When a gateway group is booted, the gateway administrative server, GWADM(5), requests from the DMADM server a copy of the configuration required by that group. The GWADM server and the DMADM server also ensure that run-time changes to the configuration are reflected in the corresponding Domain gateway groups.

Note: For more information about modifying the DMCONFIG file, see "Configuring Multiple Domains Multiple Domains for CORBA Applications" in Using the BEA Tuxedo Domains Component.

Parameters in the DM_ROUTING Section of the DMCONFIG File (BEA Tuxedo ATMI Only)

The DM_ROUTING section provides information for data-dependent routing of service requests using FML, VIEW, X_C_TYPE, and X_COMMON typed buffers. Lines within the DM_ROUTING section have the form CRITERION_NAME, where CRITERION_NAME is the (identifier) name of the routing entry specified in the SERVICES section. The CRITERION_NAME entry may contain no more than 15 characters.

Parameters to Specify

Table 3-5 describes the parameters in the DM_ROUTING section.

Table 3-5 Parameters Specified in the DM_ROUTING Section

Parameter	Description
`FIELD = identifier`	Specifies the name of the routing field. It must contain 30 characters or fewer. This field is assumed to be a field name identified in an `FML` field table (for `FML` buffers) or an `FML` `VIEW` table (for `VIEW`, `X_C_TYPE`, or `X_COMMON` buffers). The `FLDTBLDIR` and `FIELDTBLS` environment variables are used to locate `FML` field tables; the `VIEWDIR` and `VIEWFILES` environment variables are used to locate `FML` `VIEW` tables. If a field in an `FML32` buffer is used for routing, it must have a field number less than or equal to `8191`.
`BUFTYPE = "type1[:subtype1[,subtype2 . . . ]][;type2[:subtype3[, . . . ]]] . . ."`	Specifies list of types and subtypes of data buffers for which this routing entry is valid. The types are restricted to `FML`, `VIEW`, `X_C_TYPE`, and `X_COMMON`. No subtype can be specified for type `FML`, and subtypes are required for the other types (`*` is not allowed). Duplicate type/subtype pairs cannot be specified for the same routing criteria name; more than one routing entry can have the same criteria name as long as the type/subtype pairs are unique. This parameter is required. If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same. (If the field value is not set (for `FML` buffers), or does not match any specific range, and a wildcard range has not been specified, then an error is returned to the application process that requested the execution of the remote service.) No routing is allowed on CORBA and EJB (TGIOP is not a valid buffer type).
`RANGES ="range1:rdom1[,range2:rdom2 ...]"`	Specifies the ranges and associated remote domain names (`RDOM`) for the routing field. The string must be enclosed in double quotes, with the format of a comma-separated ordered list of `range/RDOM` pairs. A range is either a single value (signed numeric value or character string in single quotes), or a range of the form lower - upper (where lower and upper are both signed numeric values or character strings in single quotes). The value of lower must be less than or equal to upper. A single quote embedded in a character string value (such as `"O'Brien"`), must be preceded by two backslashes (`"O\\'Brien"`). Use `MIN` to indicate the minimum value for the data type of the associated `FIELD`. For strings and carrays, it is the null string; for character fields, it is `0`; for numeric values, it is the minimum numeric value that can be stored in the field. Use `MAX` to indicate the maximum value for the data type of the associated `FIELD`. For strings and carrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field. Thus, `MIN - -5` is all numbers less than or equal to `-5`, and `6 - MAX` is all numbers greater than or equal to `6`. The metacharacter `*` (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry. Only one wildcard range is allowed per entry and it should be last (ranges following it are ignored).

Parameter

Description

FIELD = identifier

Specifies the name of the routing field. It must contain 30 characters or fewer. This field is assumed to be a field name identified in an FML field table (for FML buffers) or an FML VIEW table (for VIEW, X_C_TYPE, or X_COMMON buffers). The FLDTBLDIR and FIELDTBLS environment variables are used to locate FML field tables; the VIEWDIR and VIEWFILES environment variables are used to locate FML VIEW tables. If a field in an FML32 buffer is used for routing, it must have a field number less than or equal to 8191.

BUFTYPE = "type1[:subtype1[,subtype2 . . . ]][;type2[:subtype3[, . . . ]]] . . ."

Specifies list of types and subtypes of data buffers for which this routing entry is valid. The types are restricted to FML, VIEW, X_C_TYPE, and X_COMMON.

No subtype can be specified for type FML, and subtypes are required for the other types (* is not allowed).

Duplicate type/subtype pairs cannot be specified for the same routing criteria name; more than one routing entry can have the same criteria name as long as the type/subtype pairs are unique. This parameter is required.

If multiple buffer types are specified for a single routing entry, the data types of the routing field for each buffer type must be the same. (If the field value is not set (for FML buffers), or does not match any specific range, and a wildcard range has not been specified, then an error is returned to the application process that requested the execution of the remote service.) No routing is allowed on CORBA and EJB (TGIOP is not a valid buffer type).

RANGES ="range1:rdom1[,range2:rdom2 ...]"

Specifies the ranges and associated remote domain names (RDOM) for the routing field. The string must be enclosed in double quotes, with the format of a comma-separated ordered list of range/RDOM pairs.

A range is either a single value (signed numeric value or character string in single quotes), or a range of the form lower - upper (where lower and upper are both signed numeric values or character strings in single quotes). The value of lower must be less than or equal to upper. A single quote embedded in a character string value (such as "O'Brien"), must be preceded by two backslashes ("O\\'Brien").

Use MIN to indicate the minimum value for the data type of the associated FIELD. For strings and carrays, it is the null string; for character fields, it is 0; for numeric values, it is the minimum numeric value that can be stored in the field.

Use MAX to indicate the maximum value for the data type of the associated FIELD. For strings and carrays, it is effectively an unlimited string of octal-255 characters; for a character field, it is a single octal-255 character; for numeric values, it is the maximum numeric value that can be stored in the field.

Thus, MIN - -5 is all numbers less than or equal to -5, and 6 - MAX is all numbers greater than or equal to 6.

The metacharacter * (wildcard) in the position of a range indicates any values not covered by the other ranges previously seen in the entry. Only one wildcard range is allowed per entry and it should be last (ranges following it are ignored).

Routing Field Description

The routing field can be of any data type supported in FML or VIEW. A numeric routing field must have numeric range values, and a string routing field must have string range values.

String range values for string, carray, and character field types must be placed inside a pair of single quotation marks and cannot be preceded by a sign. Short and long integer values are a string of digits, optionally preceded by a plus (+) or minus (-) sign. Floating point numbers are of the form accepted by the C compiler or atof(): an optional sign, followed by a string of digits optionally containing a decimal point, and an optional e or E followed by an optional sign or space, and an integer.

When a field value matches a range, the associated RDOM value specifies the remote domain to which the request should be routed. An RDOM value of * indicates that the request can go to any remote domain known by the gateway group. Within a range/RDOM pair, the range is separated from the RDOM by a colon (:).

Example of a Five-Site Domain Configuration Using Routing

Listing 3-5 shows a configuration file that defines a five-site domain configuration. It has four bank branch domains communicating with a Central Bank Branch. Three of the bank branches run within other BEA Tuxedo system domains. The fourth branch runs under the control of another TP domain, and OSI-TP is used in the communication with that domain. The example shows the BEA Tuxedo Domain gateway configuration file from the Central Bank point of view. In the DM_TDOMAIN section, this example shows a mirrored gateway for b01.

Listing 3-5 DMCONFIG File for a Five-Site Domains Configuration

# BEA TUXEDO DOMAIN CONFIGURATION FILE FOR THE CENTRAL BANK
#
#
*DM_LOCAL_DOMAINS
# <local domain name> <Gateway Group name> <domain type> <domain id> <log device>
#                     [<audit log>] [<blocktime>]
#                     [<log name>] [<log offset>] [<log size>]
#                     [<maxrdom>] [<maxrdtran>] [<maxtran>]
#                     [<maxdatalen>] [<security>]
#                     [<tuxconfig>] [<tuxoffset>]

#
#
DEFAULT: SECURITY = NONE
c01     GWGRP = bankg1
        TYPE = TDOMAIN
        DOMAINID = "BA.CENTRAL01"
        DMTLOGDEV = "/usr/apps/bank/DMTLOG"
        DMTLOGNAME = "DMTLG_C01"
c02     GWGRP = bankg2
        TYPE = OSITP
        DOMAINID = "BA.CENTRAL01"
        DMTLOGDEV = "/usr/apps/bank/DMTLOG"
        DMTLOGNAME = "DMTLG_C02"
        NWDEVICE = "OSITP"
        URCH = "ABCD"
#
*DM_REMOTE_DOMAINS
#<remote domain name>  <domain type> <domain id>
#
b01     TYPE = TDOMAIN
        DOMAINID = "BA.BANK01"
b02     TYPE = TDOMAIN
        DOMAINID = "BA.BANK02"
b03     TYPE = TDOMAIN
        DOMAINID = "BA.BANK03"
b04     TYPE = OSITP
        DOMAINID = "BA.BANK04"
        URCH = "ABCD"
#
*DM_TDOMAIN
#
#     <local or remote domainname> <network address> [nwdevice]
#
# Local network addresses
c01     NWADDR = "//newyork.acme.com:65432"     NWDEVICE ="/dev/tcp"
c02     NWADDR = "//192.76.7.47:65433"     NWDEVICE ="/dev/tcp"
# Remote network addresses: second b01 specifies a mirrored gateway
b01     NWADDR = "//192.11.109.5:1025" NWDEVICE = "/dev/tcp"
b01     NWADDR = "//194.12.110.5:1025" NWDEVICE = "/dev/tcp"
b02     NWADDR = "//dallas.acme.com:65432"  NWDEVICE = "/dev/tcp"
b03     NWADDR = "//192.11.109.156:4244" NWDEVICE = "/dev/tcp"
#
*DM_OSITP
#
#<local or remote domain name> <apt> <aeq>
#                              [<aet>] [<acn>] [<apid>] [<aeid>]
#                              [<profile>]
#
c02     APT = "BA.CENTRAL01"
        AEQ = "TUXEDO.R.4.2.1"
        AET = "{1.3.15.0.3},{1}"
        ACN = "XATMI"
b04     APT = "BA.BANK04"
        AEQ = "TUXEDO.R.4.2.1"
        AET = "{1.3.15.0.4},{1}"
        ACN = "XATMI"
*DM_LOCAL_SERVICES
#<service_name>  [<Local Domain name>] [<access control>] [<exported svcname>]
#                [<inbuftype>] [<outbuftype>]
#
open_act        ACL = branch
close_act       ACL = branch
credit
debit
balance
loan            LDOM = c02      ACL = loans
*DM_REMOTE_SERVICES
#<service_name>   [<Remote domain name>] [<local domain name>]
#                 [<remote svcname>] [<routing>] [<conv>]
#                 [<trantime>] [<inbuftype>] [<outbuftype>]
#
tlr_add   LDOM = c01  ROUTING = ACCOUNT
tlr_bal   LDOM = c01  ROUTING = ACCOUNT
tlr_add   RDOM = b04  LDOM = c02 RNAME ="TPSU002"
tlr_bal   RDOM = b04  LDOM = c02 RNAME ="TPSU003"
*DM_ROUTING
# <routing criteria>    <field> <typed buffer> <ranges>
#
ACCOUNT FIELD = branchid  BUFTYPE ="VIEW:account"
        RANGES ="MIN - 1000:b01, 1001-3000:b02, *:b03"
*DM_ACCESS_CONTROL
#<acl name>   <Remote domain list>
#
branch  ACLIST = b01, b02, b03
loans   ACLIST = b04