Editing the DMCONFIG File

This topic includes the following sections:

• What Is a DMCONFIG File?

• Editing the DM_LOCAL_DOMAINS Section

• Editing the DM_REMOTE_DOMAINS Section

• Adding the DM_TOPEND Section

• Editing the DM_LOCAL_SERVICES Section

• Editing the DM_REMOTE_SERVICES Section

• Optional DMCONFIG Sections

See Also

• Defining Security in the DMCONFIG File

• Configuring Multiple GWTOPEND Processes

• Sample Configuration File for a TOP END Domain Gateway

 

---

What Is a DMCONFIG File?

A Domains configuration for the TEDG consists of at least one local BEA Tuxedo domain and at least one BEA TOP END system that can communicate and share services with the help of the BEA Tuxedo Domains feature. In a Domains configuration using the TEDG, a BEA TOP END system should be considered a "remote domain." How a BEA Tuxedo domain and a BEA TOP END system (remote domain) are connected and which services they make accessible to each other are defined in a Domains configuration file for the TEDG domain and the BEA TOP END system definition on the BEA TOP END system. 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 remote domains with which the local domain can communicate

• The local resources (such as services and queues) accessible to remote domains

• The remote resources accessible to the local domain

• Which local and remote resources are accessible through which gateways

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.

A DMCONFIG file for a TEDG must contain five required sections and may contain one or two optional sections. The required sections are:

• DM_LOCAL_DOMAINS

• DM_REMOTE_DOMAINS

• DM_TOPEND

• DM_LOCAL_SERVICES

• DM_REMOTE_SERVICES

The optional sections are:

• DM_ROUTING

• DM_ACCESS_CONTROL

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" on page -143 in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

See Also

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

• dmloadcf(1) in the BEA Tuxedo Command Reference

• Sample Configuration File for a TOP END Domain Gateway

 

---

Editing the DM_LOCAL_DOMAINS Section

This section describes the environment required for a particular domain gateway group. Here a logical application name, LDOM, is assigned to the subset of local services that can be accessed by remote domains. Multiple entries in this section are used to define multiple gateway groups within a single BEA Tuxedo application. Each entry specifies the parameters required for the Domains gateway running in that group.

Entries in this section have the form:

LDOM required_parameters [optional_parameters]

where LDOM is an identifier value used to name the local domain. For the TEDG, each LDOM defines a gateway process that is part of a single BEA TOP END system. The LDOM 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 of DMCONFIG.)

For a description of the syntax required for parameters specified in this section, see DMCONFIG for GWTOPEND(5) in theFile Formats, Data Descriptions, MIBs, and System Processes Reference.

Defining the Required Parameters

The parameters required in this section are listed in the following table.

Table 6-1 Required Parameters in DM_LOCAL_DOMAINS  

Required Parameter	Definition
GWGRP	Specifies the name of the gateway server group (as defined in the UBBCONFIG file) representing this local domain. There is a one-to-one relationship between a DOMAINID and the name of the gateway server group.
TYPE	Used for grouping local domains into classes. Valid entries are TDOMAIN, SNAX, OSITP, and TOPEND. For the TEDG, set this value to TOPEND.
DOMAINID	Used to identify the local domain. The TEDG uses the local domain DOMAINID as the BEA TOP END user ID for requests made to the BEA TOP END system. Define the associated password using the dmadmin subcommand topendpasswd. Refer to Using the dmadmin Command Interpreter for information on using the dmadmin command. The DOMAINID must be unique across both local and remote domains.

 

Defining the Optional Parameters

Optional parameters describe the resources and limits used in the operation of domain gateways. These parameters, which are defined in detail in the DMCONFIG for GWTOPEND(5) reference page, are listed in the following table.

Table 6-2 Optional Parameters in DM_LOCAL_DOMAINS  

This Parameter. . .	Specifies . . .
AUDITLOG	The name of the audit log for this local domain.
BLOCKTIME	The maximum wait time allowed for blocking a call.
CONNECTION_POLICY	The conditions under which a local domain gateway tries to establish a connection to a remote domain. Details on this parameter are provided in Establishing Connections Between BEA Tuxedo and BEA TOP END Systems.
DMTLOGDEV	The BEA Tuxedo file system that contains the Domains transaction log (DMTLOG) for this machine.
DMTLOGNAME	The name of the Domains transaction log for this domain.
DMTLOGSIZE	The numeric size, in pages, of the Domains transaction log for this machine.
MAXRDTRAN	The maximum number of domains that can be involved in a transaction.
MAXRETRY	The maximum number of times that a domain gateway tries to establish a connection to a remote domain before quitting.
MAXTRAN	The maximum number of simultaneous global transactions allowed on this local domain.
RETRY_INTERVAL	The number of seconds between automatic attempts (all network addresses tried) to establish a connection to a remote domain.
SECURITY	The type of security to be used by the TEDG. Details on this parameter are provided in Defining Security in the DMCONFIG File.

 

See Also

• Sample Configuration File for a TOP END Domain Gateway

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

 

---

Editing the DM_REMOTE_DOMAINS Section

This section identifies the remote domains that can be accessed by clients and servers of this Domains configuration. Entries in this section have the following form.

RDOM required_parameters

where RDOM is an identifier value used to name a remote domain to which a TEDG LDOM (as defined in the DM_LOCAL_DOMAINS section) 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 of DMCONFIG.

Note: 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.

For a description of the syntax required for parameters specified in this section, see DMCONFIG for GWTOPEND(5) in theFile Formats, Data Descriptions, MIBs, and System Processes Reference.

Defining the Required Parameters

The parameters required in the DM_REMOTE_DOMAINS section are listed in the following table.

Table 6-3 Required Parameters in DM_REMOTE_DOMAINS

Required Parameter	Definition
TYPE	Used for grouping remote domains into classes. TYPE can be set to one of the following values: TOPEND, TDOMAIN, SNAX, or OSITP. For the TEDG, set this value to TOPEND.
DOMAINID	Used to identify a remote domain. The TEDG uses the remote domain DOMAINID as the BEA Tuxedo user ID for requests made to the BEA Tuxedo system by the BEA TOP END system on this remote domain. DOMAINID must be unique across remote domains.

 

See Also

• Sample Configuration File for a TOP END Domain Gateway

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

 

---

Adding the DM_TOPEND Section

The DM_TOPEND section defines:

• The network addressing information required by domains of TYPE=TOPEND

• The BEA TOP END system name for each BEA TOP END local domain (LDOM) and remote domain (RDOM) defined in the DM_LOCAL_DOMAINS and DM_REMOTE_DOMAINS sections

Defining the Required Parameters

The parameters required in this section are listed in the following table.

Table 6-4 Required Parameters in DM_TOPEND

Required Parameter	Definition
NWADDR	Specifies the network address associated with a local domain or remote domain. If you associate the network address with an LDOM, the NWADDR parameter is used to accept connections from BEA TOP END systems. If you associate the network address with an RDOM, the NWADDR parameter is used to initiate a connection. If you associate multiple network addresses with an RDOM, the TP_SYSTEM value must be the same on each entry for the RDOM. Multiple entries for an RDOM define primary and alternate network connections to the same physical node. The number of network addresses for an RDOM is not limited. When the TEDG attempts to make a connection, each network address is tried serially. Configuring too many network addresses or addresses that may not be operational can reduce TEDG performance. Multiple network addresses are not allowed for an LDOM. 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.
TP_SYSTEM	Specifies the BEA TOP END system associated with the LDOM or RDOM defined in the DM_LOCAL_DOMAINS and DM_REMOTE_DOMAINS sections. The parameter accepts a string that corresponds to the BEA TOP END system name. The value of the string must match the value of the TP_SYSTEM environment variable specified in the node manager startup script. This script is described in the nm_script(4T) reference page.

 

Note: Do not configure LDOMs, RDOMs, and their network addresses such that more than one TEDG connection between a BEA TEDG node and a BEA TOP END node is activated for a particular TP_SYSTEM name. BEA TOP END network interface protocol does not support multiple connections of this type. As a result, if more than one TEDG connection is active, the TEDG or the BEA TOP END node rejects the duplicate connections. Due to variations in how network addresses can be specified, this type of configuration cannot be fully validated in this configuration file.

See Also

• Sample Configuration File for a TOP END Domain Gateway

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

• nm_script(4T) reference page in the BEA TOP END Programmer's Reference Manual

 

---

Editing the DM_LOCAL_SERVICES Section

The DM_LOCAL_SERVICES section defines the mapping required to make BEA Tuxedo services and /Q queue spaces available to a BEA TOP END system.

In DMCONFIG files written for domain gateways other than the TEDG, the purpose of entries in the DM_LOCAL_SERVICES 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 to map BEA Tuxedo names to BEA TOP END names for the following:

• Request/reply and conversational services

• BEA Tuxedo queue spaces and queue names

For BEA TOP END and BEA Tuxedo systems to exchange queue messages, there must be a mapping of the queue addresses on both systems. The address of a BEA Tuxedo /Q queue consists of a combination of queue space (QSPACE) and queue name (QNAME).

Defining Service and Queue Mapping Entries

Entries in this section must adhere to the following form.

service [TYPE=SERVICE] required_parameters [optional_parameters]
qspace  TYPE=QSPACE    required_parameters [optional_parameters]
qname   TYPE=QNAME     required_parameters [optional_parameters]

Here:

• service is the name of an exported BEA Tuxedo service (TYPE=SERVICE is the default).

• qspace is the name of an exported BEA Tuxedo queue space.

• qname is the name of a queue defined in a BEA Tuxedo queue space and used in tpenqueue(3c) requests.

Configuration Guidelines for DM_LOCAL_SERVICES

Observe the following guidelines when editing the DM_LOCAL_SERVICES section of the DMCONFIG file.

• For SERVICE and QSPACE entries, the BEA Tuxedo service or queue space is assumed to be available in the local BEA Tuxedo domain. A queue name specified in a QNAME entry is assumed to be defined in the queue space associated with that queue.

• If the configuration includes LDOMs for more than one BEA TOP END system, or if it includes multiple gateway types, specify the LDOM parameter in the local service entry. Do not specify a mixed configuration that does not specify an LDOM; such a configuration may prevent a gateway from initializing properly. If in doubt, explicitly set LDOM.

• Entries configured for a specific LDOM are advertised by the gateway for that LDOM. Additionally, any local SERVICE entry that is not configured for a particular local domain using the LDOM parameter, and that has the required TE_PRODUCT parameter, is advertised to the BEA TOP END system by each local domain of type TOPEND.

• 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 example, do not specify both a SERVICE entry and a QSPACE entry such that the TE_PRODUCT and TE_FUNCTION parameters of the SERVICE entry match the TE_RTQGROUP and TE_RTQNAME of the QSPACE entry, respectively.

• QSPACE and QNAME entries are independent. Any combination of QSPACE and QNAME entries may be used by an application by supplying the associated BEA TOP END identifiers in the tp_rtq_put(3T) routine call. A run-time error will occur if the specified combination does not exist in the local BEA Tuxedo domain.

Defining Service Type Parameters

A SERVICE entry defines BEA Tuxedo services that are accessible from a BEA TOP END system via the TEDG. These services are made accessible by mapping the BEA TOP END service identifiers 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. RTQ service requests are not mapped in SERVICE entries.

The following table lists the parameters available for mapping in entries of type SERVICE in the DM_LOCAL_SERVICES section. Some parameters are required; others are optional.

Table 6-5 Parameters of SERVICE Type Entries in DM_LOCAL_SERVICES  

This Parameter . . .	Defines . . .	Required?
TE_PRODUCT	The BEA TOP END product name.	Yes
TE_FUNCTION	The BEA TOP END function name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
TE_QUALIFIER	The BEA TOP END function qualifier.	No
TYPE	A type for this entry. The value SERVICE means that the purpose of this entry is to map various parameters for a local BEA Tuxedo service being exported to a BEA TOP END system.	No
ACL	The name of the access control list (ACL) to be used by the TEDG to restrict requests made to the specified SERVICE by BEA TOP END systems. You define the ACL in the DM_ACCESS_CONTROL section of DMCONFIG, as described in Defining Security in the DMCONFIG File.	No
LDOM	The name of the local domain exporting the specified service. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No
INBUFTYPE	The input buffer type allowed for this service. You can restrict the input buffer type by setting one of the following values: FML32, CARRAY, or X_OCTET.	No
OUTBUFTYPE	The output buffer type accepted from this service. You can restrict this to one of the following buffer types: FML32, CARRAY, or X_OCTET.	No

 

Defining QSPACE Type Parameters

A QSPACE entry defines a BEA Tuxedo queue space that is made available to the BEA TOP END system by the TEDG as if it were an RTQ queue (limitations apply). RTQ queues are made available in a BEA TOP END system by advertising the RTQ Group and Queue name as a BEA TOP END service name. In a manner similar to that used by the RTQ server, the TEDG handles tp_rtq_put(3T) requests sent to its RTQ queues. Each request is mapped to the BEA Tuxedo queue space identified in this QSPACE entry. Both QSPACE entries and QNAME entries are required for message queuing.

The following table lists the parameters available for mapping entries of type QSPACE in the DM_LOCAL_SERVICES section. Some parameters are required; others are optional.

Table 6-6 Parameters of QSPACE Type Entries in DM_LOCAL_SERVICES

This Parameter . . .	Defines . . .	Required?
TYPE	A type for this entry. The value QSPACE means that the purpose of this entry is to map various parameters to a local BEA Tuxedo queue space being made available to a BEA TOP END system as an RTQ queue.	Yes
TE_RTQGROUP	The BEA TOP END RTQ group name.	Yes
TE_RTQNAME	The BEA TOP END RTQ queue name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
ACL	The name of the access control list (ACL) to be used by the TEDG to restrict requests made to the specified QSPACE by BEA TOP END systems. You define the ACL in the DM_ACCESS_CONTROL section of DMCONFIG as described in Defining Security in the DMCONFIG File.	No
LDOM	The name of the local domain exporting the specified queue space. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No

 

Defining QNAME Type Parameters

A QNAME entry maps BEA TOP END service names to BEA Tuxedo queue names for requests enqueued to a BEA Tuxedo application via RTQ. The services defined in QNAME entries are not advertised as services to a BEA TOP END system.

The following table lists the parameters available for mapping entries of type QNAME in the DM_LOCAL_SERVICES section. Some parameters are required; others are optional.

Table 6-7 Parameters of QNAME Type Entries in DM_LOCAL_SERVICES

This Parameter . . .	Defines . . .	Required?
TYPE	A type for this entry. The value QNAME means that the purpose of this entry is to define the parameters used in mapping a BEA TOP END service name to a BEA Tuxedo queue name for requests enqueued to a BEA Tuxedo application via RTQ.	Yes
TE_PRODUCT	The BEA TOP END product name.	Yes
TE_FUNCTION	The BEA TOP END function name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
TE_QUALIFIER	The BEA TOP END function qualifier.	No
LDOM	The name of the local domain to which this QNAME entry applies. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No

 

See Also

• Sample Configuration File for a TOP END Domain Gateway

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

• tpenqueue(3c) in the BEA Tuxedo ATMI C Function Reference

 

---

Editing the DM_REMOTE_SERVICES Section

The DM_REMOTE_SERVICES section defines the mapping information required to make BEA TOP END services, RTQ queues, and services accessed via RTQ available to a BEA Tuxedo application. This section is required for TOP END Domain Gateways.

In DMCONFIG files written for domain gateways other than the TEDG, the purpose of entries in the DM_REMOTE_SERVICES 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 to map:

• Request/reply and conversational services

• BEA Tuxedo queue spaces and queue names

For BEA Tuxedo and BEA TOP END systems to exchange queue messages, there must be a mapping of the queue addresses on both systems. The address of a BEA Tuxedo /Q queue consists of a combination of queue space (QSPACE) and queue name (QNAME).

Defining Service and Queue Mapping Entries

The entries in this section must adhere to the following form.

service [TYPE=SERVICE] required_parameters [optional_parameters]
qspace  TYPE=QSPACE    required_parameters [optional_parameters]
qname   TYPE=QNAME     required_parameters [optional_parameters]

Here:

• service is the BEA Tuxedo service assigned to the BEA TOP END service (default).

• qspace is the name of the BEA Tuxedo queue space assigned to the RTQ queue.

• qname is the name of the BEA Tuxedo queue assigned to a BEA TOP END service accessed through RTQ.

Configuration Guidelines for the DM_REMOTE_SERVICES

Observe the following guidelines when editing the DM_REMOTE_SERVICES section of the DMCONFIG file.

• Because SERVICE and QSPACE entries define service identifiers and qspace identifiers that are advertised as BEA Tuxedo services, these identifiers must be unique for a particular LDOM. However, multiple entries of the same type and identifier are permitted for load balancing. All entries for a single service identifier must have the same value for the CONV parameter.

• If they do not define a particular local domain (with the LDOM parameter), the following types of entries apply to each local domain of type TOPEND:

  • Any SERVICE and QNAME entry that includes the TE_PRODUCT parameter

  • Any QSPACE entry that includes the TE_RTQGROUP parameter

• For SERVICE and QSPACE entries, the BEA TOP END service or RTQ queue is assumed to be available on the remote BEA TOP END node specified with the RDOM parameter or obtained through specified routing criteria. Services specified in a QNAME entry are assumed to be available via the BEA TOP END node to which they are enqueued.

• Entries in which multiple remote domains are specified with the RDOM parameter use the Domains Failover feature that enables this service request to be routed to the alternate RDOM if the primary RDOM is not connected, or to the second alternate if the primary and first alternate are not connected. This feature may also be used in conjunction with the load balancing feature in which multiple remote service entries are configured for the same service or queue space identifier.

• If a configuration includes LDOMs for more than one BEA TOP END system, or includes multiple gateway types (such as TDOMAIN and TOPEND), the LDOM parameter should be specified in the remote service entry. If an RDOM is specified on the entry or in a referenced routing entry, it should match the LDOM type (TOPEND) and TP_SYSTEM. Mixed configurations that do not specify LDOM, or reference RDOMs of mixed types or mixed TP_SYSTEMs should not be created and may prevent a gateway from initializing properly. If in doubt, explicitly set LDOM and a remote domain (via the RDOM parameter or ROUTING). "Wildcard" specifications for remote domains should be used only when a single gateway type is defined.

Defining the Service Type Parameters

A SERVICE entry defines BEA TOP END services that are accessible from a BEA Tuxedo domain via the TEDG. These BEA TOP END services are made accessible by mapping BEA Tuxedo service names to BEA TOP END service identifiers. These service names are used with two BEA Tuxedo functions:tpcall(3c) and tpacall(3c).

The following table lists the parameters available for mapping entries of type SERVICE in the DM_REMOTE_SERVICES section. Some parameters are required; others are optional.

Table 6-8 Parameters of SERVICE Type Entries in DM_REMOTE_SERVICES  

This Parameter . . .	Defines . . .	Required?
TE_PRODUCT	The BEA TOP END product name.	Yes
TE_FUNCTION	The BEA TOP END function name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
TE_QUALIFIER	The BEA TOP END function qualifier.	No
TYPE	A type for this entry. The value SERVICE means that the purpose of this entry is to define the parameters available when mapping a BEA TOP END service to a local BEA Tuxedo service.	No
LDOM	The name of the local domain importing this service. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No
RDOM	The name of the remote domain providing this service. The remote domain must be of type TOPEND and it must belong to the TP_SYSTEM to which the local domain (that is, the domain to which this entry applies) belongs. If you do not specify the RDOM parameter and routing criteria, the local domain assumes that any remote domain of type TOPEND with the same TP_SYSTEM value as the local domain provides the service. To configure alternate remote domains using this parameter, you must specify ON_STARTUP as the value of the CONNECTION_POLICY parameter in the DM_LOCAL_DOMAINS section.	No
INBUFTYPE	The input buffer type allowed for this service. You can restrict the input buffer type by setting one of the following values: FML32, CARRAY, or X_OCTET.	No
OUTBUFTYPE	The output buffer type accepted from this service. You can restrict this to one of the following buffer types: FML32, CARRAY, or X_OCTET.	No
CONV	Request/Response or conversational service mapping. If this value is set to Y, the BEA TOP END server application must manage a pseudo-conversation that may or may not maintain application context. The default is N.	No
TRANTIME	The default timeout value, in seconds, for a transaction automatically started for the associated service.	No
ROUTING	The name of the criteria used by a local domain for data-dependent routing when more than one remote domain offers the same service. If you do not specify this parameter, data-dependent routing is not done for this service.	No

 

Defining QSPACE Type Parameters

A QSPACE entry defines a BEA TOP END RTQ queue that is made available in the BEA Tuxedo domain by the TEDG as if it were a BEA Tuxedo queue space. Queue spaces are made available in a BEA Tuxedo application by advertising the queue space name as a BEA Tuxedo service name. In a manner similar to that used by the TMQUEUE server, the TEDG handles tpenqueue requests sent to its queue space names. Each request is mapped to the RTQ queue identified in this QSPACE entry. Both QSPACE entries and QNAME entries are required for message queuing.

The following table lists the parameters available for mapping entries of type QSPACE in the DM_REMOTE_SERVICES section. Some parameters are required; others are optional.

Table 6-9 Parameters of QSPACE Type Entries in DM_REMOTE_SERVICES

This Parameter . . .	Defines . . .	Required?
TYPE	A type for this entry. The value QSPACE means that the purpose of this entry is to define the parameters available when mapping a BEA TOP END RTQ queue to a local BEA Tuxedo queue space.	Yes
TE_RTQGROUP	The BEA TOP END RTQ group name.	Yes
TE_RTQNAME	The BEA TOP END RTQ queue name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
LDOM	The name of the local domain importing this RTQ queue. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No
RDOM	The name of the remote domain providing this RTQ queue. The remote domain must be of type TOPEND and it must belong to the same TP_SYSTEM to which the local domain (that is, the domain to which this entry applies) belongs. If you do not specify the RDOM parameter and routing criteria, the local domain assumes that any remote domain of type TOPEND with the same TP_SYSTEM value as the local domain provides the service. To configure alternate remote domains using this parameter, you must specify ON_STARTUP as the value of the CONNECTION_POLICY parameter in the DM_LOCAL_DOMAINS section.	No
TRANTIME	The default timeout value, in seconds, for a transaction automatically started for the associated service.	No
ROUTING	The name of the criteria used by a local domain for data-dependent routing when more than one remote domain offers the same service. If you do not specify this parameter, data-dependent routing is not done for this service.	No

 

Defining QNAME Type Parameters

A QNAME entry maps a BEA Tuxedo queue name to a BEA TOP END service (product and function) for requests enqueued to a BEA TOP END system. QNAME entries are not advertised as services to a BEA Tuxedo application.

The following table lists the parameters available for mapping entries of type QNAME in the DM_REMOTE_SERVICES section. Some parameters are required; others are optional.

Table 6-10 Parameters of QNAME Type Entries in DM_REMOTE_SERVICES

This Parameter . . .	Defines . . .	Required?
TYPE	A type for this entry. The value QNAME means that the purpose of this entry is to define the parameters available when mapping a BEA Tuxedo queue name to a BEA TOP END service name for requests enqueued to a BEA TOP END system via /Q.	Yes
TE_PRODUCT	The BEA TOP END product name.	Yes
TE_FUNCTION	The BEA TOP END function name.	Yes
TE_TARGET	The BEA TOP END MSR target.	No
TE_QUALIFIER	The BEA TOP END function qualifier.	No
LDOM	The name of the local domain to which the queue name entry applies. If you do not specify this parameter, then the entry applies to all the local domains of type TOPEND that are defined in the DM_LOCAL_DOMAINS section.	No

 

See Also

• Sample Configuration File for a TOP END Domain Gateway

• tpacall(3c)in the BEA Tuxedo ATMI C Function Reference

• tpcall(3c) in the BEA Tuxedo ATMI C Function Reference

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

 

---

Optional DMCONFIG Sections

A DMCONFIG file for a TEDG may include either or both of the following optional sections:

• DM_ROUTING

  This section provides information for data-dependent routing of service requests. Only FML32 descriptions are applicable to gateways of type TOPEND. Refer to DMCONFIG for GWTOPEND(5) for details.

• DM_ACCESS_CONTROL

  This section specifies the access control lists used by the local domain. For additional information, refer to Defining Security in the DMCONFIG File and the DMCONFIG for GWTOPEND(5) reference page in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

See Also

• Sample Configuration File for a TOP END Domain Gateway

• DMCONFIG for GWTOPEND(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference