|
|
|
|
|
|
DMCONFIG for GWTOPEND(5)
Name
DMCONFIG for GWTOPEND - text version of a Domains configuration file for a TOP END Domain Gateway
Description
A Domains configuration is a set of two or more domains (or applications) that can communicate and share services with the help of the BEA Tuxedo Domains feature. How multiple domains are connected and which services they make accessible to each other are defined in a Domains configuration file on each domain. The text version of a Domains configuration file is known as the DMCONFIG file (after the environment variable used to hold the name of the actual file used).
A DMCONFIG file defines the following:
The DMCONFIG file is parsed and loaded into a binary version, called BDMCONFIG, by the dmloadcf(1) utility. The dmadmin(1) command uses BDMCONFIG (or a copy of it) for monitoring the run-time application.
One BDMCONFIG file is required on each domain in a multi-domain configuration in which the Domains feature is being used.
The DMCONFIG and BDMCONFIG files are analogous to the UBBCONFIG and TUXCONFIG files used to define a BEA Tuxedo application.
Definitions
A BEA Tuxedo system domain Application is defined as the environment described in a single TUXCONFIG file. A BEA Tuxedo system application can communicate with another BEA Tuxedo system application or with another TP application via a domain gateway group. In "BEA Tuxedo system domain" terms, an application is the same as a TP Domain.
A Gateway Group is a collection of domain gateway processes that provide communication services with a specific type of TP Domain.
A Domain Gateway is a BEA Tuxedo system domain process that relays requests to another TP Domain and receives replies.
A Local Domain is a part of the application (set or subset of services) that is made available to other domains. A Local Domain is always represented by a Domain Gateway Group, and both terms are used as synonyms.
A Remote Domain is a remote application that is accessed through a Gateway Group. The remote application may be another BEA Tuxedo system domain application or an application running under another TP system.
A Remote Service is a service provided by a remote domain that is made available to the application through a Gateway Group.
A Local Service is a service of a local domain that is made available to remote domains through a Gateway Group.
Configuration File Format
The format of a domain configuration file is as follows.
The file is made up of several possible specification sections. Allowable section names are: DM_LOCAL_DOMAINS, DM_REMOTE_DOMAINS, DM_LOCAL_SERVICES, DM_REMOTE_SERVICES, DM_TOPEND, DM_RESOURCES, DM_ROUTING, and DM_ACCESS_CONTROL. Additional section names applicable only to other gateway types are: DM_TDOMAINS, DM_OSITP, DM_SNACRM, DM_SNASTACKS, and DM_SNALINKS. The DM_LOCAL_DOMAINS section must precede the DM_REMOTE_DOMAINS section.
Note: This reference page describes how to configure a domain gateway of only one type: TOPEND. For information about how to configure a domain of type TDOMAIN, see DMCONFIG(5). See BEA eLink documentation for information about how to configure an OSITP or an SNAX domain.
Parameters are generally specified by: KEYWORD = value; white space (space or tab character) is allowed on either side of the equal sign (=). This format sets KEYWORD to value. Valid keywords are described below within each section.
Lines beginning with the reserved word, DEFAULT:, contain parameter specifications that apply to all lines that follow them in the section in which they appear. Default specifications can be used in all sections. They can appear more than once in the same section. The format for these lines is:
DEFAULT: [KEYWORD1 = value1 [KEYWORD2 = value2 [...]]]
The values set on this line remain in effect until reset by another DEFAULT: line, or until the end of the section is reached. These values can also be overridden on non-DEFAULT: lines by placing the optional parameter setting on the line. If on a non-DEFAULT: line, the parameter setting is valid for that line only; lines that follow revert to the default setting. If DEFAULT: appears on a line by itself, all previously set defaults are cleared and their values revert to the system defaults.
If a value is numeric, standard C notation is used to denote the base (that is, 0x prefix for base 16 (hexadecimal), 0 prefix for base 8 (octal), and no prefix for base 10 (decimal)). The range of values acceptable for a numeric parameter is given under the description of that parameter.
If a value is an identifier (a string value already known to the BEA Tuxedo Domains feature such as TOPEND for the TYPE parameter), standard C rules are typically used. A standard C identifier starts with an alphabetic character or underscore and contains only alphanumeric characters or underscores. The maximum allowable length of an identifier is 30 (not including the terminating null).
There is no need to enclose an identifier in double quotes. A value that is neither an integer number nor an identifier must be enclosed in double quotes.
Input fields are separated by at least one space (or tab) character.
"#" introduces a comment. A newline ends a comment.
Blank lines and comments are ignored.
Comments can be freely attached to the end of any line.
Lines are continued by placing at least one tab after the newline. Comments cannot be continued.
Domains Terminology Improvements
In this release, some of the domains terminology is changing. The Domains MIB uses improved class and attribute terminology to describe the interaction between local and remote domains. While this improved terminology is more accurate than previous domains terminology, the scope of changes to domains-related documentation and error messages is limited in this release. The improved terminology has been applied to the DM_MIB classes, reference page, and error messages, the DMCONFIG file syntax, and various DMCONFIG error messages.
For backwards compatibility, aliases are provided between the DMCONFIG terminology used prior to this release and the improved Domains MIB terminology. In this release, DMCONFIG accepts both versions of the terminology. For details, see Domains Terminology Improvements in the DM_MIB(5) reference page.
DM_LOCAL_DOMAINS Section
This section identifies local domains and their associated gateway groups. The section must have an entry for each gateway group (Local Domain). Each entry specifies the parameters required for the domain gateway processes running in that group. The entry defines a GWTOPEND instance (with its associated GWADM) that is associated with a single BEA TOP END system. The local domain communicates with remote domains of type TOPEND that are part of the same BEA TOP END system. The BEA TOP END system name is defined in the DM_TOPEND section.
Entries have the form:
LDOM required_parameters [optional_parameters]
where LDOM is an identifier value used to name the local domain. LDOM must be unique within a particular configuration. As described in the DM_LOCAL_SERVICES section, LDOM is the identifier that associates the local and remote services with a particular gateway group.
The following are required parameters:
Optional parameters describe resources and limits used in the operation of domain gateways:
DM_REMOTE_DOMAINS Section
This section identifies the known set of remote domains and their characteristics.
For TOP END Domain Gateway (TEDG) definitions, this section defines connections to Network Interface components on nodes of remote BEA TOP END systems.
Entries have the form:
RDOM required_parameters
where RDOM is an identifier value used to identify each remote domain known to this configuration. RDOM must be unique within the configuration.
Each RDOM defines a node in the BEA TOP END system to which a BEA TOP END LDOM may have a connection. The LDOM communicates with remote domains of type TOPEND that are part of the same BEA TOP END system as the LDOM. (The BEA TOP END system name is defined in the DM_TOPEND section.) Because of the BEA TOP END adjacent node routing topology, the services for the BEA TOP END system may reside on several different nodes. Therefore, a TEDG LDOM may need several RDOM entries to define connections to the BEA TOP END nodes where the desired BEA TOP END services reside.
The TYPE and DOMAINID parameters are required; MTYPE is not used for remote domains of type TOPEND:
DM_TOPEND Section
This section defines the addressing information required by domains of type TOPEND. This section should have an entry per local domain if requests from remote domains to local services are accepted on that local domain (gateway group), and an entry per remote domain accessible by the defined local domains.
Entries have the form:
DOM required_parameters [optional_parameters]
where DOM is an identifier value used to identify either a local domain (LDOM) or a remote domain (RDOM) in the DM_LOCAL_DOMAINS section or in the DM_REMOTE_DOMAINS section. The DOM identifier must match a previously defined LDOM in the DM_LOCAL_DOMAINS section or RDOM in the DM_REMOTE_DOMAINS section.
Local and remote domains and their network addresses must be configured such that no more than one BEA TOP END gateway connection to a BEA TOP END node is activated for a particular TP_SYSTEM name at runtime. The BEA TOP END network interface protocol does not support multiple gateway connections. If an attempt is made to activate more than one connection, runtime errors occur in the TEDG or on the BEA TOP END node, and all connections except one are rejected. Due to variations in how network addresses can be specified, this type of configuration cannot be fully validated in this configuration file.
The following parameters are required:
Note: Some port numbers may be reserved for the underlying transport protocols (such as TCP/IP) used by your system. Check the documentation for your transport protocols to find out which numbers, if any, are reserved on your system.
Note: Care should be taken when specifying the host address portion of the NWADDR parameter. When a BEA TOP END NI accepts a connection request that was issued from a TEDG, it resolves the network address of the TEDG to a name. The resolved name must match the defined hostname of the TEDG. If the defined hostname of the TEDG and the resolved name differ, including case, the NI connection fails. Such a failure may not be evident from either the GWTOPEND log file or the remote BEA TOP END NI log file. As a general rule, ensure that the hostname definitions match in the DMCONFIG file, the TOP END NI configuration file, the TOP END nodemap file, the TOP END tp_alias file, and the locally configured name resolution facilities. For further information on NI name resolution, refer to the tp_alias(4T) reference page in the BEA TOP END Programmer's Reference Manual.
If the entry is for a BEA TOP END local domain (that is, if DOM matches a previously specified LDOM), then NWADDR is the network address to be used to listen for incoming connections. Only one entry may be configured for a local domain.
Multiple entries may be configured for a remote domain to specify network addresses to be tried serially on a connection attempt. The first one specified is considered the primary address, which means it is the first one tried when a connection is being attempted to a remote domain. If a network connection cannot be established using the NWADDR of the primary entry, the NWADDR associated with the secondary entry is used. Each subsequent entry is used if all previous entries have failed. A connection attempt fails when all configured network addresses have been tried. Entries associated with a remote domain can be specified an unlimited number of times. Configuring too many network addresses or addresses that may not be operational can degrade performance.
If the entry is for a secondary remote domain (that is, if DOM matches a previously specified RDOM), then the entry is used only when a network connection cannot be established using the NWADDR of the primary entry (and any prior secondary entries). For every secondary entry:
Secondary remote gateway definitions are not recommended for use with TOP END Domain Gateways.
DM_ACCESS_CONTROL Section
This section specifies the access control lists used by the local domain.
Lines in this section are of the form:
ACL_NAME required_parameters
where ACL_NAME is an identifier used to specify an access control list; it may contain no more than 15 characters.
The only required parameter is:
ACLIST = identifier[,identifier]
where an ACLIST is composed of one or more remote domain names (RDOM) separated by commas. The wildcard character (*) can be used to specify that all the remote domains defined in the DM_REMOTE_DOMAINS section can access a local domain.
DM_LOCAL_SERVICES Section
This section defines the mapping information required to make BEA Tuxedo services and /Q queue spaces available to BEA TOP END systems. In DMCONFIG files written for domain gateways other than the TEDG, the purpose of entries in this section is to map local services to remote names for those services. In DMCONFIG files written for the TEDG, however, the type entry is used to define request/reply and conversational service mapping. Additionally, similar entries are accepted in this section for defining BEA Tuxedo queue space mapping and queue name mapping. Entries may be for a SERVICE, QSPACE or QNAME and are identified by the TYPE parameter. This section is required for TOP END domain gateways.
Lines within this section have one of these forms:
service [TYPE=SERVICE]required_parameters [optional_parameters]
qspace TYPE=QSPACE required_parameters [optional_parameters]
qname TYPE=QNAME required_parameters [optional_parameters]
where service is the name of an exported BEA Tuxedo service, qspace is the name of an exported BEA Tuxedo queue space, and qname is the name of a queue name defined within a BEA Tuxedo queue space. Each of these names may contain no more than 15 characters.
SERVICE entries define BEA Tuxedo services that are advertised (product, function, target) to the BEA TOP END system by the TEDG. Entries for BEA Tuxedo services that are advertised to a BEA TOP END system must include a mapping from BEA TOP END service identifiers (product, function, target, qualifier) to BEA Tuxedo service names. These service identifiers are used with the BEA TOP END tp_client_send(3T) and tp_client_signon(3T) routine calls.
QSPACE entries in this section define BEA Tuxedo queue spaces that are made available to BEA TOP END as RTQ queues (limitations apply). RTQ queues are made available in BEA TOP END by advertising the RTQ Group name, RTQ Queue name, and target name as a BEA TOP END service name. The BEA TOP END gateway handles tp_rtq_put(3T) requests sent to its RTQ queue names in a manner similar to that used by the RTQ server. Each request is then mapped to the BEA Tuxedo queue space identified in this QSPACE entry. Both QSPACE entries and QNAME entries are required for message queuing.
QNAME entries define the mapping of a BEA TOP END service request to a BEA Tuxedo queue name for requests enqueued to the BEA Tuxedo system via RTQ. QNAME entries are not advertised as services to the BEA TOP END system. QSPACE and QNAME entries are independent. Any combination of QSPACE and QNAME identifiers may be used by an application by supplying the associated BEA TOP END identifiers with a tp_rtq_put(3T) routine call. A run-time error results if the combination does not exist in the local BEA Tuxedo domain.
QNAME entries should be unique with respect to their product, function, target, and qualifier combination for a particular LDOM. If multiple entries of the same combination are configured, the TEDG uses only the first one.
Any SERVICE or QNAME entry that includes the TE_PRODUCT parameter, or any QSPACE entry that includes the TE_RTQGROUP parameter, is applicable to all local domains of type TOPEND if the entry is not configured for a particular local domain using the LDOM parameter. Entries configured for a specific LDOM are applicable only to the gateway for that domain.
Because SERVICE and QSPACE entries configure BEA TOP END service identifiers that are advertised as BEA TOP END services, these identifiers must not overlap for a particular LDOM. For a SERVICE entry, the TE_PRODUCT, TE_FUNCTION, and TE_TARGET are advertised. For a QSPACE entry, the TE_RTQGROUP, TE_RTQNAME, and TE_TARGET are advertised as product, function, and target identifiers. Therefore if a SERVICE entry product, function, and target match a QSPACE entry RTQ Group, RTQ Queue name and target, the TEDG cannot route the request. Note that, as in the BEA TOP END system, the default value for the target is the truncated node name.
If the configuration includes LDOMs for more than one BEA TOP END system, or if it includes multiple gateway types, the LDOM parameter should be specified in the local service entry. Mixed configurations that do not specify LDOM should not be created; they may prevent a gateway from initializing properly. If in doubt, explicitly set LDOM.
The following are the required and optional parameters for each entry type:
|
Entry TYPE |
Required Parameters |
Optional Parameters |
|
SERVICE |
TE_PRODUCT, TE_FUNCTION |
TYPE, ACL, LDOM, INBUFTYPE, OUTBUFTYPE, TE_TARGET, TE_QUALIFIER |
|
QSPACE |
TYPE, TE_RTQGROUP, TE_RTQNAME |
ACL, LDOM, TE_TARGET |
|
QNAME |
TYPE, TE_PRODUCT, TE_FUNCTION |
LDOM, INBUFTYPE, TE_TARGET, TE_QUALIFIER |
The following are descriptions of both required and optional parameters.
DM_REMOTE_SERVICES Section
This section defines the mapping information required to make BEA TOP END services, RTQ queues, and services accessed via RTQ available to BEA Tuxedo applications. In DMCONFIG files written for domain gateways other than the TEDG, the purpose of entries in this section is to map local services to remote names for those services.
In a DMCONFIG file written for the TEDG, however, the purpose of entries in this section is different.
Entries may be included for a SERVICE, QSPACE, or QNAME, and are identified by the TYPE parameter. This section is required for TOP END domain gateways.
Lines within this section have one of these forms:
service [TYPE=SERVICE]required_parameters [optional_parameters]
qspace TYPE=QSPACE required_parameters [optional_parameters]
qname TYPE=QNAME required_parameters [optional_parameters]
where service is the BEA Tuxedo service name assigned to the BEA TOP END service, qspace is the BEA Tuxedo queue space name assigned to the RTQ Queue, and qname is the BEA Tuxedo queue name assigned to a BEA TOP END service accessed through RTQ. Each of these names may contain 15 characters or fewer.
SERVICE entries define BEA TOP END services that are advertised to the BEA Tuxedo domain by the TEDG. Entries for BEA TOP END services that are advertised to a BEA Tuxedo application must map BEA Tuxedo service names to BEA TOP END service identifiers. These service names are used with the XATMI tpcall(3c) and tpacall(3c) functions.
QSPACE entries in this section define BEA TOP END RTQ queues that are made available in the BEA Tuxedo domain by the TEDG as if they were BEA Tuxedo queue spaces (limitations apply). A queue space is made available in the BEA Tuxedo system by advertising the queue space name as a BEA Tuxedo service name. The gateway handles a tpenqueue request sent to its queue space name in a manner similar to that used by the TMQUEUE server. The request is then mapped to the RTQ queue identified in this qspace entry. Both QSPACE and QNAME entries are required for message queuing.
QNAME entries define the mapping of a BEA Tuxedo queue name to a BEA TOP END service name for requests enqueued to the BEA TOP END system. QNAME entries are not advertised as services to BEA Tuxedo systems. Note that QSPACE and QNAME entries are independent; any combination of QSPACE and QNAME identifiers may be used by an application with the tpenqueue(3c) function.
QNAME entries should be unique with respect to the queue name identifier for a particular LDOM. If multiple entries for the same identifier value are configured, the TEDG uses only the first one.
Any SERVICE or QNAME entry that includes the TE_PRODUCT parameter, or any QSPACE entry that includes the TE_RTQGROUP parameter, is applicable to each local domain of type TOPEND if the entry is not configured for a particular local domain using the LDOM parameter. Entries configured for a specific LDOM are also applicable to the gateway for that domain.
Because SERVICE and QSPACE entries configure service identifiers and queue space identifiers that are advertised as BEA Tuxedo services, these identifiers must not overlap for a particular LDOM. However, multiple entries of the same type and identifier are permitted for load balancing. All entries for the same service identifier must have the same value for the CONV parameter.
If the configuration includes LDOMs for more than one BEA TOP END system, or if it includes multiple gateway types, the LDOM parameter should be specified in the DM_REMOTE_SERVICES section of the DMCONFIG file. If an RDOM is specified in a remote services entry, or in a referenced routing entry, its value should match the value of the LDOM type (TOPEND) and TP_SYSTEM. Mixed configurations that do not specify LDOM, or that reference RDOMs of mixed types or mixed TP_SYSTEMs should not be created; they may prevent gateways from initializing properly. If in doubt, explicitly set LDOM and specify a remote domain (via the RDOM parameter or ROUTING). A "wildcard" specification for a remote domain should be used only when a single gateway type is defined.
The following are the required and optional parameters for each entry type.
The following are descriptions of both required and optional parameters.
DM_RESOURCES
This optional section is used for defining global Domains configuration information, specifically a user-supplied configuration version string.
The only parameter in this section is
VERSION = string
where string is a field in which users can enter a version number for the current Domains configuration file. This field is not checked by the software.
DM_ROUTING Section
This section provides information for data-dependent routing of service requests using FML32. This description only applies to gateways of type TOPEND. For routing information for gateways of type TDOMAIN, refer to the DMCONFIG(5) reference page.
Lines within the DM_ROUTING section have the following form.
CRITERION_NAME required_parameters
where CRITERION_NAME is the identifier name of the routing entry that was specified in the services entry. The value of CRITERION_NAME may contain up to 15 characters.
The following parameters are required.
Files
The BDMCONFIG environment variable is used to find the BDMCONFIG configuration file.
Example
The following configuration file example is based on Example 1 in the core BEA Tuxedo DMCONFIG(5) reference page. The example has been extended to include a TOP END domain gateway with a single connection to a BEA TOP END system. In this scenario the BEA TOP END system is also running a banking application that offers services needed by users of a BEA Tuxedo application. Conversely, certain BEA Tuxedo services need to be available to the BEA TOP END system for use by modified client programs. A simple queuing example is also included.
The DMCONFIG file for this configuration is shown below. Changes from the original example in the core DMCONFIG(5) file are shown in bold.
# 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>]
# [<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.CENTRAL02"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C02"
c03 GWGRP = bankg3
TYPE = TOPEND
DOMAINID = "CENTRALBKGW"
DMTLOGDEV = "/usr/apps/bank/DMTLOG"
DMTLOGNAME = "DMTLG_C03"
SECURITY = CLEAR
#
*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"
b05 TYPE = TOPEND
DOMAINID = "BANK05"
*DM_TDOMAIN
#
# <local or remote domain name> <network address> [<nwdevice>]
#
# Local network addresses
c01 NWADDR = "//newyork.acme.com:65432" NWDEVICE ="/dev/tcp"
# Remote network addresses
b01 NWADDR = "//192.11.109.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.CENTRAL02"
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_TOPEND
#Local network addresses
c03 NWADDR = "//newyork.acme.com:65434"
TP_SYSTEM = "BANKSYS"
#Remote network addresses
b05 NWADDR = "//sandiego.acme.com:65434"
TP_SYSTEM = "BANKSYS"
*DM_LOCAL_SERVICES
#<service_name> [<Local Domain name>] [<access control>] [<exported svcname>]
# [<inbuftype>] [<outbuftype>]
#
#Not available to TOP END, no mapping
open_act ACL = branch LDOM=c01
close_act ACL = branch LDOM=c01
credit LDOM=c01
debit LDOM=c01
loan LDOM = c02 ACL = loans
#Services exported to TOP END and other domains
balance TYPE=SERVICE TE_PRODUCT="TUX" TE_FUNCTION="BALANCE" LDOM=c03
#Queues available to TOP END
qspace TYPE=QSPACE TE_RTQGROUP="TUXQUEUE" TE_RTQNAME="TUXQ" LDOM=c03
qname TYPE=QNAME TE_PRODUCT="TUX" TE_FUNCTION="QSERV" LDOM=c03
*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 = ACCOUNTNetwork Addresses
Suppose the local machine on which a TEDG is being run is using TCP/IP addressing and is named backus.company.com. The address of the machine is 155.2.193.18. Further suppose that the port number at which the TEDG should accept requests is 2334. Assume that the port number 2334 has been added to the network services database under the name bankapp-gwaddr. The complete address of this port can be represented in the following ways.
//155.2.193.18:bankapp-gwaddr//155.2.193.18:2334//backus.company.com:bankapp-gwaddr//backus.company.com:23340x0002091E9B02C112The last of these representations is written in hexadecimal format. The string 0002 is the first part of a TCP/IP address. 091E is the port number 2334 translated into a hexadecimal number. The rest of the address (9B02C112) consists of hexadecimal translations of each element of the IP address (155.2.193.12): 9B is translated from 155, 02 is translated from 2, and so on.
See Also
dmadmin(1), dmloadcf(1), dmunloadcf(1), tmboot(1), tmshutdown(1), DMADM(5), GWADM(5), GWTOPEND(5)
BEA TOP END Programmer's Reference Manual: tp_intro(3T), ni_config(4T), nm_config(4T), nm_script(4T)
Administering a BEA Tuxedo Application at Run Time
Setting Up a BEA Tuxedo Application
Programming a BEA Tuxedo Application Using C
Using the BEA Tuxedo Domains Component
Using the BEA Tuxedo TOP END Domain Gateway
Copyright © 2000 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.