|
|
 |
| e-docs > Tuxedo > File Formats, Data Descriptions, MIBs, and System Processes Reference > Section 5 - File Formats, Data Descriptions, MIBs, and System Processes Reference |
|
File Formats, Data Descriptions, MIBs, and System Processes Reference
|
EVENT_MIB(5) Additional Information
Files
${TUXDIR}/udataobj/evt_mib ${TUXDIR}/include/evt_mib.hSee Also
factory_finder.ini(5)
Name
factory_finder.ini—FactoryFinder Domains configuration file
Description
factory_finder.ini is the FactoryFinder configuration file for Domains. This text (ASCII) file is parsed by the TMFFNAME service when it is started as a Master NameManager. The file contains information used by NameManagers to control the import and the export of object references for factory objects with other domains. To use the information in the factory_finder.ini file, you must specify the factory_finder.ini file in the -f option of the TMFFNAME server process.
The FactoryFinder Domains configuration file may have any name as long as the content of the file conforms to the format described on this reference page.
Definitions
A BEA Tuxedo domain is defined as the environment described in a single TUXCONFIG file. A BEA Tuxedo domain can communicate with another BEA Tuxedo domain or with another TP application—an application running on another TP system—via a domain gateway group. In BEA Tuxedo terminology, a domain is the same as an application—a business application.
A Remote Factory is a factory object that exists in a remote domain that is made available to the application through a BEA Tuxedo FactoryFinder.
A Local Factory is a factory object that exists in the local domain that is made available to remote domains through a BEA Tuxedo FactoryFinder.
File Format
The file is made up of two specification sections. Allowable section names are: DM_REMOTE_FACTORIES and DM_LOCAL_FACTORIES.
Parameters are generally specified by: KEYWORD = value, which sets KEYWORD to value. Valid keywords are described within each section. KEYWORDs are reserved; they cannot be used as values, unless they are quoted.
If a value is an identifier, standard C rules are used. An identifier must start with an alphabetic character or underscore and must contain only alphanumeric characters or underscores. An identifier cannot be the same as any KEYWORD.
A value that is not an identifier must be enclosed in double quotes.
Input fields are separated by at least one space or tab character.
The # character introduces a comment. A newline ends a comment.
Blank lines and comments are ignored.
Lines are continued by placing at least one tab after the newline. Comments can not be continued.
This section provides information about the factories exported by each local domain. This section is optional; if it is not specified, all local factory objects can be exported to remote domains. If this section is specified, it should be used to restrict the set of local factory objects that can be retrieved from a remote domain. The reserved factory_id.factory_kind identifier of NONE can be used to restrict any local factory from being retrieved from a remote domain.
Lines within this section have the form:
factory_id.factory_kind
where factory_id.factory_kind is the local name (identifier) of the factory. This name must correspond to the identifier of a factory object registered by one or more BEA Tuxedo server applications with the BEA Tuxedo FactoryFinder.
The factory_kind must be specified for TMFFNAME to locate the appropriate factory. An entry that does not contain a factory_kind value does not default to a value of FactoryInterface.
This section provides information about factory objects imported and available on remote domains. Lines within this section have the form:
factory_id.factory_kind required_parameters
where factory_id.factory_kind is the name (identifier) of the factory object used by the local BEA Tuxedo domain for a particular remote factory object. Remote factory objects are associated with a particular remote domain.
Note: If you use the TobjFactoryFinder interface, the factory_kind must be FactoryInterface.
The required parameter is:
DOMAINID = domain_id
This parameter specifies the identity of the remote domain in which the factory object is to be retrieved. The domain_id must not be greater than 32 octets in length. If the value is a string, it must be 32 characters or fewer (counting the trailing NULL). The value of domain_id can be a sequence of characters or a sequence of hexadecimal digits preceded by 0x.
The optional parameter is:
RNAME = string
This parameter specifies the name exported by remote domains. This value will be used by a remote domain to request this factory object. If this parameter is not specified, the remote factory object name is the same as the named specified in factory_id.factory_kind.
Multiple entries with the same name can be specified as long as the values associated with either the DOMAINID or RNAME parameter results in the identification of a unique factory object.
Examples
The following FactoryFinder Domains configuration file defines two entries for a factory object that will be known in the local domain by the identifier Teller.FactoryIdentity that is imported from two different remote domains:
# BEA Tuxedo FactoryFinder Domains
# Configuration File
#
*DM_REMOTE_FACTORIES
Teller.FactoryIdentity
DOMAINID="Northwest"
RNAME=Teller.FactoryType
Teller.FactoryIdentity
DOMAINID="Southwest"
In the first entry, a factory object is to be imported from the remote domain with an identity of Northwest that has been registered with a factory identity of Teller.FactoryType.
In the second entry, a factory object is to be imported from the remote domain with an identity of Southwest that has been registered with a factory identity of Teller.FactoryIdentity. Note that because no RNAME parameter was specified, the name of the factory object in the remote domain is assumed to be the same as the factory's name in the local domain.
The following FactoryFinder Domains configuration file defines that only factory objects registered with the identity of Teller.FactoryInterface in the local domain are allowed to be exported to any remote domain. Requests for any other factory should be denied.
# BEA Tuxedo FactoryFinder Domains
# Configuration File
#
*DM_LOCAL_FACTORIES
Teller.FactoryInterface
The following FactoryFinder Domains configuration file defines that none of the factory objects registered with the BEA Tuxedo FactoryFinder are to be exported to a remote domain.
# BEA Tuxedo FactoryFinder Domains
# Configuration File
#
*DM_LOCAL_FACTORIES
NONE
See Also
UBBCONFIG(5), DMCONFIG(5), TMFFNAME(5), TMIFRSVR(5)
Ferror, Ferror32(5)
Name
Ferror, Ferror32—FML error codes
Synopsis
#include "fml.h"
#include "fml32.h"
Description
The numerical value represented by the symbolic name of an error condition is assigned to Ferror for errors that occur when executing many FML library routines.
The name Ferror expands to a modifiable lvalue that has type int, the value of which is set to a positive error number by several FML library routines. Ferror need not be the identifier of an object; it might expand to a modifiable lvalue resulting from a function call. It is unspecified whether Ferror is a macro or an identifier declared with external linkage. If a tperrno() macro definition is suppressed to access an actual object, or if a program defines an identifier with the name Ferror, the behavior is undefined.
The reference pages for FML routines list possible error conditions for each routine and the meaning of the error in that context. The order in which possible errors are listed is not significant and does not imply precedence. The value of Ferror should be checked only after an error has been indicated; that is, when the return value of the component indicates an error and the component definition specifies that tperrno() be set. An application that checks the value of Ferror must include the fml.h header file.
Ferror32 provides a similar capability for users of FML32 routines. An application that checks the value of Ferror32 must include the fml32.h header file.
The following list shows error codes that may be returned by FML and FML32 routines.
#define FMINVAL 0 /* bottom of error message codes */
#define FALIGNERR 1 /* fielded buffer not aligned */
#define FNOTFLD 2 /* buffer not fielded */
#define FNOSPACE 3 /* no space in fielded buffer */
#define FNOTPRES 4 /* field not present */
#define FBADFLD 5 /* unknown field number or type */
#define FTYPERR 6 /* illegal field type */
#define FEUNIX 7 /* unix system call error */
#define FBADNAME 8 /* unknown field name */
#define FMALLOC 9 /* malloc failed */
#define FSYNTAX 10 /* bad syntax in boolean expression */
#define FFTOPEN 11 /* cannot find or open field table */
#define FFTSYNTAX 12 /* syntax error in field table */
#define FEINVAL 13 /* invalid argument to function */
#define FBADTBL 14 /* destructive concurrent access to field table */
#define FBADVIEW 15 /* cannot find or get view */
#define FVFSYNTAX 16 /* bad viewfile */
#define FVFOPEN 17 /* cannot find or open viewfile */
#define FBADACM 18 /* ACM contains negative value */
#define FNOCNAME 19 /* cname not found */
Usage
Some routines do not have an error return value. Because no routine sets Ferror to zero, an application can set Ferror to zero, call a routine and then check Ferror again to see if an error has occurred.
In DOS and OS/2 environments, this variable is known as FMLerror.
See Also
See the ERRORS section of the individual FML library routines for a more detailed description of the meaning of the error codes returned by each routine.
Introduction to the C Language Application-to-Transaction Monitor Interface
, tperrordetail(3c), tpstrerror(3c), tpstrerrordetail(3c), Introduction to FML Functions, F_error, F_error32(3fml)
field_tables(5)
Name
field_tables—FML mapping files for field names
Description
The Field Manipulation Language functions implement and manage fielded buffers. Each field in a fielded buffer is tagged with an identifying integer. Fields that can variable in length (for example, a string) have an additional length modifier. The buffer then consists of a series of numeric-identifier/data pairs and numeric-identifier/length/data triples.
The numeric-identifier of a field is called its field identifier and is typedef'd by FLDID. A field is named by relating an alphanumeric string (the name) to a FLDID in a field table.
The original FML interface supports 16-bit field identifiers, field lengths, and buffer sizes. A newer 32-bit interface, FML32, supports larger identifiers, field lengths, and buffer sizes. All types, function names, etc. are suffixed with "32" (for example, the field identifier type definition is FLDID32).
Field Identifiers
FML functions allow field values to be typed. Currently the following types are supported: char, string, short, long, float, double, carray (character array), ptr (pointer to a buffer), FML32 (embedded FML32 buffer), and VIEW32 (embedded VIEW32 buffer). The ptr, FML32, and VIEW32 types are supported only for the FML32 interface. Constants for field types are defined in fml.h (fml32.h for FML32). So that fielded buffers can be truly self-describing, the type of a field is carried along with the field by encoding the field type in the FLDID. Thus, a FLDID is composed of two elements: a field type, and a field number. In 32-bit FML, field numbers must be between 10,001 and 30,000,000. The numbers 1-10,000 and 30,000,001-33,554,431 are reserved for system use. In 16-bit FML, field numbers must be between 101 and 8,191. The numbers 1-100 are reserved for system use.
Field Mapping
For efficiency, it is desirable that the field name to field identifier mapping be available at compile time. For utility, it is also desirable that these mappings be available at run time. To accommodate both these goals, FML represents field tables in text files, and provides commands to generate corresponding C header files. Thus, compile time mapping is done by the C preprocessor, cpp, by the usual #define macro. Run-time mapping is done by the function Fldid() (or Fldid32() for FML32), which maps its argument, a field name, to a field identifier by consulting the source field table files.
Field Table Files
Files containing field tables have the following format:
name rel-numb type
where:
Entries are white-space separated (any combination of tabs and spaces).
Conversion of Field Tables to Header Files
The command mkfldhdr (or mkfldhdr32) converts a field table, as described above, into a file suitable for processing by the C compiler. Each line of the generated header file is of the form:
#define name fldid
where name is the name of the field, and fldid is its field identifier. The field identifier includes the field type and field number, as previously discussed. The field number is an absolute number, that is, base + rel-number. The resulting file is suitable for inclusion in a C program.
Environment Variables
Functions such as Fldid(), which access field tables, and commands such as mkfldhdr() and vuform(), which use them, both need the shell variables FLDTBLDIR and FIELDTBLS (FLDTBLDIR32 and FIELDTBLS32 for FML32) to specify the source directories and files, respectively, from which the in-memory version of field tables should be created. FIELDTBLS specifies a comma-separated list of field table filenames. If FIELDTBLS has no value, fld.tbl is used as the name of the field table file. The FLDTBLDIR environment variable is a colon-separated list of directories in which to look for each field table whose name is not an absolute pathname. (The search for field tables is very similar to the search for executable commands using the PATH variable.) If FLDTBLDIR is not defined, it is taken to be the current directory. Thus, if FIELDTBLS and FLDTBLDIR are not set, the default is to take fld.tbl from the current directory.
The use of multiple field tables is a convenient way to separate groups of fields, such as groups of fields that exist in a database from those which are used only by the application. However, in general field names should be unique across all field tables, since such tables are capable of being converted to C header files (by the mkfldhdr command), and identical field names would produce a compiler name conflict warning. In addition, the function Fldid, which maps a name to a FLDID, does so by searching the multiple tables, and stops upon finding the first successful match.
Example
The following is a sample field table in which the base shifts from 500 to 700:
# employee ID fields are based at 500
*base 500
#name rel-numb type comment
#---- -------- ---- -------
EMPNAM 1 string emp's name
EMPID 2 long emp's id
EMPJOB 3 char job type: D,M,F or T
SRVCDAY 4 carray service date
# address fields are based at 700
*base 700
EMPADDR 1 string street address
EMPCITY 2 string city
EMPSTATE 3 string state
EMPZIP 4 long zip code
The associated header file would be:
#define EMPADDR ((FLDID)41661) /* number: 701 type: string */
#define EMPCITY ((FLDID)41662) /* number: 702 type: string */
#define EMPID ((FLDID)8694) /* number: 502 type: long */
#define EMPJOB ((FLDID)16887) /* number: 503 type: char */
#define EMPNAM ((FLDID)41461) /* number: 501 type: string */
#define EMPSTATE ((FLDID)41663) /* number: 703 type: string */
#define EMPZIP ((FLDID)8896) /* number: 704 type: long */
#define SRVCDAY ((FLDID)49656) /* number: 504 type: carray */
See Also
mkfldhdr, mkfldhdr32(1)
Programming a BEA Tuxedo ATMI Application Using FML
GWADM(5)
Name
GWADM—Domains gateway administrative server
Synopsis
GWADM SRVGRP = "identifier" SRVID = "number" REPLYQ = "N"
CLOPT = "-A -- [-a {on | off}] [-t {on | off}]"
Description
The gateway administrative server (GWADM) is a BEA Tuxedo system-supplied server that provides administrative functions for a Domains gateway group.
GWADM should be defined in the SERVERS section of the UBBCONFIG file as a server running within a particular gateway group, that is, SRVGRP must be set to the corresponding GRPNAME tag specified in the GROUPS section. The SVRID parameter is also required and its value must consider the maximum number of gateways allowed within the gateway group.
There should be only one instance of a GWADM per Domains gateway group, and it should not be part of the MSSQ defined for the gateways associated with the group. Also, GWADM should have the REPLYQ attribute set to N.
The CLOPT option is a string of command-line options that is passed to the GWADM when it is booted. This string has the following format:
CLOPT="-A -- gateway group runtime_parameters"
The following run-time parameters are recognized for a gateway group:
The GWADM server must be booted before the corresponding gateways.
Portability
GWADM is supported as a BEA Tuxedo system-supplied server on all supported server platforms.
Interoperability
GWADM must be installed on BEA Tuxedo release 4.2.1 or later; other machines in the same domain with a release 4.2.2 gateway can be release 4.1 or later.
Examples
The following example illustrates the definition of the administrative server in the UBBCONFIG file. This example uses the GWTDOMAIN gateway process to provide connectivity with another BEA Tuxedo domain. To provide interoperability with a BEA TOP END system, use the GWTOPEND gateway process. For details on the GWTOPEND gateway process and an example using GWTOPEND, see GWTOPEND(5).
#
*GROUPS
DMADMGRP GRPNO=1
gwgrp GRPNO=2
#
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y GRACE=0
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y GRACE=0
CLOPT="-A -- -a on -t on"
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=N RESTART=Y MIN=1 MAX=1
See Also
dmadmin(1)
, tmboot(1), DMADM(5), DMCONFIG(5), DMCONFIG for GWTOPEND(5), GWTOPEND(5), servopts(5), UBBCONFIG(5)Administering a BEA Tuxedo Application at Run Time
Setting Up a BEA Tuxedo Application
Using the BEA Tuxedo Domains Component
GWTDOMAIN(5)
Name
GWTDOMAIN—TDomain gateway process
Synopsis
GWTDOMAIN SRVGRP = "identifier" SRVID = "number" RQADDR = "queue_name"
REPLYQ = value RESTART = Y [MAXGEN = value] [GRACE = value]
Description
GWTDOMAIN is the domain gateway process that provides interdomain communication. GWTDOMAIN processes communicate with other GWTDOMAIN processes in remote domains.
Domain gateways are described in the SERVERS section of the UBBCONFIG file and the BDMCONFIG file. Domain gateways must be always associated with a particular gateway group, that is, SRVGRP must be set to the corresponding GRPNAME tag specified in the GROUPS section. The SVRID parameter is also required and its value must consider the maximum number of gateways allowed within the domain group. The RESTART parameter should be set to Y. The REPLYQ parameter may be set to Y or N.
The GWTDOMAIN process must be in the same group as the GWADM(5) process, with the GWADM listed first. Multiple GWTDOMAIN processes can be configured for a domain; each must be configured in a different BEA Tuxedo group.
Examples
The following example shows the definition of a Domains gateway group in the UBBCONFIG file.
*GROUPS
DMADMGRP LMID=mach1 GRPNO=1
gwgrp LMID=mach1 GRPNO=2
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
GWTDOMAIN SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
Additional examples are available in the "EXAMPLES" sections of UBBCONFIG(5) and DMCONFIG(5).
See Also
tmadmin(1)
, tmboot(1), DMADM(5), DMCONFIG(5), GWADM(5), servopts(5), UBBCONFIG(5)Using the BEA Tuxedo Domains Component
Setting Up a BEA Tuxedo Application
Administering a BEA Tuxedo Application at Run Time
GWTOPEND(5)
Name
GWTOPEND—TOP END Domain Gateway process
Synopsis
GWTOPEND SRVGRP = "identifier" SRVID = "number" RQADDR = "queue_name"
REPLYQ = N RESTART = Y [MAXGEN = value] [GRACE = value]
Description
GWTOPEND is the domain gateway process that provides communication between a BEA Tuxedo domain and a BEA TOP END system. GWTOPEND gateway processes communicate with the Network Interface (NI) component on one or more nodes of a single BEA TOP END system. Different GWTOPEND gateways (in different BEA Tuxedo groups) may be configured to access different BEA TOP END systems or to split the load. GWTOPEND supports request/reply, pseudo-conversations, queuing, and transactions.
Domain gateways are described in the SERVERS section of the UBBCONFIG file and the BDMCONFIG file. Domain gateways must be associated with a particular group, that is, SRVGRP must be set to the corresponding GRPNAME tag specified in the GROUPS section.
The SVRID parameter is also required and its value must specify the maximum number of gateways allowed within the domain group. The RESTART parameter should be set to Y. The REPLYQ parameter should be set to N.
The GWTOPEND process must be in the same group as the GWADM(5) process, with the GWADM listed first. Multiple GWTOPEND processes can be configured for a domain; each must be configured in a different BEA Tuxedo group.
If BEA TOP END security is configured for the gateway, the BEA TOP END Security Services product must be installed on the node and the srvtab file for the TP_SYSTEM name must be copied to the node in the location shown in the "Files" section. If long node names are to be supported, the nodemap file must be copied to the node in the location shown in the "Files" section.
Files
$TUXDIR/udataobj/nodemap
$APPDIR/srvtab.system (where system is the BEA TOP END system name)
/usr/lib/libtp_krb.so (installed on UNIX platforms on which BEA TOP END security is configured)
%TOPENDDIR%\bin\krb.dll (installed on Windows platforms on which BEA TOP END security is configured)
Examples
The following example shows the definition of a domain gateway group in the UBBCONFIG file.
*GROUPS
DMADMGRP LMID=mach1 GRPNO=1
gwgrp LMID=mach1 GRPNO=2
*SERVERS
DMADM SRVGRP="DMADMGRP" SRVID=1001 REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
GWADM SRVGRP="gwgrp" SRVID=1002 REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
GWTOPEND SRVGRP="gwgrp" SRVID=1003 RQADDR="gwgrp" REPLYQ=N RESTART=Y MAXGEN=5 GRACE=3600
See the "Examples" section of UBBCONFIG(5) and DMCONFIG for GWTOPEND(5) for additional information.
See Also
tmadmin(1)
, tmboot(1), DMADM(5), DMCONFIG for GWTOPEND(5), GWADM(5), servopts(5), UBBCONFIG(5)BEA TOP END Programmer's Reference Manual: ext_srvtab(1T), nodemap(5T)
Administering a BEA Tuxedo Application at Run Time
Setting Up a BEA Tuxedo Application
Using the BEA Tuxedo Domains Component
Using the BEA Tuxedo TOP END Domain Gateway with ATMI Applications
GWTUX2TE, GWTE2TUX(5)
Name
GWTUX2TE, GWTE2TUX—BEA Tuxedo / BEA TOP END gateway servers
Synopsis
GWTUX2TE SRVGRP = "identifier" SRVID = "number"
CLOPT = "-- -f service_definition_file
[-c TOPEND_remote_configuration_file]
[-R sec] [-w wait_time] [[-u username] [-p password_file]]"
GWTE2TUX SRVGRP = "identifier" SRVID = "number"
CLOPT = "-- -f service_definition_file
[-c TOPEND_remote_configuration_file]
[-R sec] [[-u username] [-g groupname]]"
Description
GWTUX2TE and GWTE2TUX are gateway servers. GWTUX2TE provides connectivity between BEA Tuxedo clients and BEA TOP END servers. GWTE2TUX provides connectivity between BEA TOP END clients and BEA Tuxedo servers. One or both of these gateway servers may be configured for a domain.
GWTUX2TE and GWTE2TUX are defined in the SERVERS section of the UBBCONFIG file as servers running within a particular server group. Therefore, SRVGRP must be set to the value of the corresponding GRPNAME parameter (as specified in the GROUPS section). The SVRID parameter is also required. GWTUX2TE and GWTE2TUX allow for MIN and MAX values of gateway instances to be specified. Although the gateway servers are synchronous, you may use multiple instances to provide better throughput.
CLOPT is an "umbrella parameter" that passes a set of command-line options to the gateway servers when the servers are booted. To specify options with CLOPT, use the following format.
CLOPT="-- gateway_group_run_time_parameters"
The following CLOPT options are recognized:
Programming Paradigms
The GWTUX2TE and GWTE2TUX gateway servers support request/response messages only. The following BEA Tuxedo client API calls for sending and receiving are allowed:
BEA TOP END servers cannot set the APPL_CONTEXT flag. If this flag is set, the gateway server dissolves the BEA TOP END dialog and returns an error (TPESVCFAIL) to the BEA Tuxedo client.
The following BEA TOP END client API calls are allowed:
Buffer Types
The GWTUX2TE and GWTE2TUX gateway servers support BEA Tuxedo CARRAY (X_OCTET) buffers only. Attempts to send other types of buffers from a BEA Tuxedo application generate an error, which is logged by the gateway server.
Configuration
The GWTUX2TE and GWTE2TUX gateway servers use the BEA TOP END remote client and remote server services. GWTUX2TE assumes the role of a BEA TOP END client and makes use of the remote client services. GWTE2TUX assumes the role of a BEA TOP END server and makes use of the remote server services. Therefore, you must provide a BEA TOP END remote client/server configuration file on any BEA Tuxedo node running these gateway processes.
BEA TOP END Remote Client/Server Configuration File
The BEA TOP END remote client/server configuration file is described in the BEA TOP END Remote Client Services Guide; this section provides a brief description of the file.
Entries in this configuration file are formatted as follows:
[top end configuration file]
[component type] remote server
[system] sysname
[primary node] machine_name portnum
The component type entry should be set to remote server. The system entry should match the name of the BEA TOP END system. The primary node entry should be set to the machine name and port number of the BEA TOP END Network Agent (NA).
A secondary node may also be specified. This node can be used when a connection to the primary node cannot be established. If multiple secondary nodes are specified, the BEA TOP END system uses a "round robin" technique to load balance the connections. This feature enables multiple instances of a gateway server to connect to different nodes on the BEA TOP END system, as follows:
[secondary node] machine 28001
[secondary node] machine2 28001
The optional target parameter is also supported by the GWTUX2TE and GWTE2TUX gateway servers.
The following parameters are not supported by the GWTUX2TE and GWTE2TUX gateway servers; do not include them in the configuration file.
Each gateway process may connect to only one BEA TOP END system, as specified by [system] in the TOPENDRC.cfg file. A second gateway process may be configured to connect to a different BEA TOP END system. Use the CLOPT -c parameter to point to a second configuration file.
Service Definition File
The service definition file has the following syntax:
*TE_LOCAL_SERVICES # For BEA Tuxedo services accessible by TOP END clients
Servicename PRODUCT=product_name FUNCTION=function_name
QUALIFIER=function_qualifier
*TE_REMOTE_SERVICES # For TOP END services accessible by BEA Tuxedo clients
Servicename PRODUCT=product_name FUNCTION=function_name
QUALIFIER=function_qualifier TARGET=target_name
Servicename indicates the BEA Tuxedo service to be imported (TE_REMOTE_SERVICE) or exported (TE_LOCAL_SERVICE).
While the PRODUCT parameter must be specified, the FUNCTION, QUALIFIER, and TARGET parameters are optional. In addition, the TARGET parameter is valid for TE_REMOTE_SERVICES only.
You can define any service definition file parameter as a default by using the following syntax:
DEFAULT: PRODUCT=product_name
All services in the TE_LOCAL_SERVICES section must have the same PRODUCT name.
If the FUNCTION parameter is not specified, the function name is assumed to be the service name. If the QUALIFIER and TARGET parameters are not specified for a service entry, no function qualifier or target name is used for that service.
Refer to Setting Up a BEA Tuxedo Application for information on valid values for BEA Tuxedo service names. Refer to the BEA TOP END Administrator's Guide for information on valid values for the PRODUCT, FUNCTION, QUALIFIER, and TARGET parameters.
Limitations
The gateways do not support the following:
Security
The following table lists the appropriate security settings for various configurations.
The username and groupname or username and password specified with CLOPT must also be entered into the corresponding BEA Tuxedo or BEA TOP END security database. For the BEA Tuxedo security database, the username is typically created using tpusradd(). The group name is typically created using tpgrpadd(). Portability The GWTUX2TE and GWTE2TUX gateway servers are supported on Windows, Sun Solaris, HP-UX, IBM AIX, and NCR MP-RAS. Interoperability The GWTUX2TE and GWTE2TUX gateway servers must run on BEA Tuxedo release 6.5 or later. These gateway servers inter-operate with BEA TOP END 2.05 or later. Examples The following example shows how gateway servers are defined in the BEA Tuxedo UBBCONFIG file and in the BEA TOP END service definition file. In this example, a BEA Tuxedo client issues tpcall() to the RSERVICE service. The request is forwarded (via the GWTUX2TE gateway) to a BEA TOP END system (pluto) and invokes a BEA TOP END service (RPRODUCT:RFUNC). Similarly, a BEA TOP END client issues tp_client_send, specifying LPRODUCT as the PRODUCT and LFUNC as the FUNCTION. The request is forwarded (via the GWTE2TUX gateway) to the BEA Tuxedo system and invokes a BEA Tuxedo service (LSERVICE). Listing 37-1 BEA Tuxedo UBBCONFIG File Listing 37-2 BEA TOP END Service Definition File Listing 37-3 BEA TOP END Remote Configuration File Note: Remember that the value of port in the primary node entry (which is 28001 in the listing BEA TOP END Remote Configuration File) must match the port number of the BEA TOP END Network Agent. Software Requirements The following software components are required:
##############
#UBBCONFIG
*GROUPS
TOPENDGRP GRPNO=1
#
*SERVERS
GWTE2TUX SRVGRP="TOPENDGRP" SRVID=1001 RESTART=Y MAXGEN=3 GRACE=10
CLOPT="-- -f servicedefs -R 30"
GWTUX2TE SRVGRP="TOPENDGRP" SRVID=1002 RESTART=Y MAXGEN=3 GRACE=10
MIN=5 MAX=5
CLOPT="-- -f servicedefs"############
#service definition file
*TE_LOCAL_SERVICES
DEFAULT: PRODUCT=LPRODUCT
LSERVICE FUNCTION=LFUNC
*TE_REMOTE_SERVICES
RSERVICE PRODUCT=RPRODUCT FUNCTION=RFUNC# TOP END remote configuration file
[top end configuration file]
[component type] remote server
[system] pluto
[primary node] topendmach 28001
Failures
A BEA Tuxedo client receives a TPESVCFAIL under any of the following conditions:
A BEA TOP END client receives an error of TP_RESET, with the TP_EXT_SERVER_APPL extended status, under any of the following conditions:
Note that if a gateway offers a service that is not available on the corresponding system, the client receives an error (TPESVCFAIL), as indicated above, that is different from the error returned after a local service invocation. In the latter case, the client receives TPENOENT for the BEA Tuxedo system or TP_SERVICE for the BEA TOP END system.
See Also
tmboot(1)
, servopts(5), UBBCONFIG(5)Setting Up a BEA Tuxedo Application
Administering a BEA Tuxedo Application at Run Time
BEA TOP END Remote Client/Server Services Guide
ISL(5)
Name
Enables access to BEA Tuxedo objects by remote BEA Tuxedo clients using IIOP.
Synopsis
ISL SRVGRP="identifier"
SRVID="number"
CLOPT="[-A ] [ servopts options ] -- -n netaddr
[-C {detect|warn|none} ]
[-d device ]
[-E principal_name]
[-K {client|handler|both|none} ]
[-m minh ]
[-M maxh ]
[-T Client-timeout]
[-x mpx-factor ]
[-H external-netaddr]
#options for Outbound IIOP
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users]
#options for SSL
[-a]
[-R renegotiation-interval]
[-S secure port]
[-v {detect|warn|none} ]
[-z [0|40|56|128]]
[-Z [0|40|56|128]]"
Description
The IIOP Server Listener (ISL) is a BEA Tuxedo-supplied server command that enables access to BEA Tuxedo objects by remote BEA Tuxedo clients using IIOP. The application administrator enables access to the application objects by specifying the IIOP Server Listener as an application server in the SERVERS section. The associated command-line options are used to specify the parameters of the IIOP Server Listener and IIOP Server Handlers.
The location, server group, server ID, and other generic server-related parameters are associated with the ISL using the standard configuration file mechanisms for servers. ISL command-line options allow for customization.
Each ISL booted as part of an application facilitates application access for a large number of remote BEA Tuxedo clients by providing access via a single, well-known network address. The IIOP Server Handlers are started and stopped dynamically by the ISL, as necessary, to meet the incoming load.
For joint client/servers, if the remote joint client/server ORB supports bidirectional IIOP connections, the ISL can use the same inbound connection for outbound invokes to the remote joint client/server. The ISL also allows outbound invokes (outbound IIOP) to objects located in a joint client/server that is not connected to an ISH. This capability is enabled when the -O option is specified. The associated command-line options allow configuration of outbound IIOP support:
Parameters
You specify the following options in the CLOPT string after the double-dash (--) in the CLOPT parameters:
"//hostname:port_number"
"//#.#.#.#:port_number"
Note: The hostname must begin with a letter character.
Note: The Java Tobj_Bootstrap object uses a short type to store the port_number. Therefore, you must use a port_number in the range of 0 to 32767 if you plan to support connections from Java clients.
Note: The network address that is specified by programmers in the Bootstrap constructor or in TOBJADDR must exactly match the network address in the application's UBBCONFIG file. The format of the address as well as the capitalization must match. If the addresses do not match, the call to the Bootstrap constructor will fail with a seemingly unrelated error message:
ERROR: Unofficial connection from client at
<tcp/ip address>/<port-number>:
For example, if the network address is specified as //TRIXIE:3500 in the ISL command line option string, specifying either //192.12.4.6:3500 or //trixie:3500 in the Bootstrap constructor or in TOBJADDR will cause the connection attempt to fail.
On UNIX systems, use the uname -n command on the host system to determine the capitalization used. On Windows NT systems, see the host system's Network control panel to determine the capitalization used.
Note: Unlike the BEA Tuxedo system Workstation Listener (WSL), the format of the network addresses is limited to //host:port. The reason for this limitation is that the host name and port number are used by BEA Tuxedo servers; the host name does not appear as such in the hexadecimal format, and it could only be passed to the servers using the dotted IP address format.
Caution: The use of unofficial connections can cause problems for remote client applications that use transactions. The application may have the notion that invocations on both the official and unofficial connections within the same transaction have succeeded; however, in reality, only invocations on the official connection are ACID (Atomicity, Consistency, Isolation, and Durability).
Note: The KEEPALIVE interval is an operating system parameter, so changing the value affects any other applications that enable KEEPALIVE. Many platforms have a two-hour default value that may be longer than desired.
Portability
The IIOP Server Listener is supported as a BEA Tuxedo-supplied server on UNIX and Microsoft Windows NT operating systems.
Interoperability
The ISL works with any IIOP compliant ORB.
Depending on the type of remote object and the desired outbound IIOP configuration, you may have to perform additional programming tasks. Table 38 lists the requirements for each type of object and outbound IIOP configuration.
Network Addresses
Suppose the local machine on which the ISL is being run is using TCP/IP addressing and is named backus.company.com, with address 155.2.193.18. Further suppose that the port number at which the ISL should accept requests is 2334. The address specified by the -l option could be:
//155.2.193.18:2334
//backus.company.com:2334
Examples
*SERVERS
ISL SRVGRP="ISLGRP" SRVID=1002 RESTART=Y GRACE=0
CLOPT="-A -- -n //piglet:1900 -d /dev/tcp"
langinfo(5)
Name
langinfo—Language information constants
Synopsis
#include <langinfo.h>
Description
This header file contains the constants used to identify items of langinfo data. The mode of items is given in nl_types(5).
This information is retrieved by nl_langinfo(3c)
.The items are retrieved from a special message catalog named LANGINFO, which should be generated for each locale supported and installed in the appropriate directory (see mklanginfo(1)
).See Also
mklanginfo(1)
, nl_langinfo(3c), strftime(3c), nl_types(5)
LAUTHSVR
Name
LAUTHSVR—WebLogic Server embedded LDAP-based authentication server
Synopsis
LAUTHSVR SRVGRP="identifier" SRVID=number other_parms CLOPT="-A -- -f filename"
Description
LAUTHSVR is a System/T provided server that offers the authentication service while the user security information is located in WebLogic Server. This server may be used in a secure application to provide per-user authentication when clients join the application. This server accepts service requests containing TPINIT typed buffer as a user password and validates it against the configured password that is stored in WebLogic Server. If the request passes validation, then an application key is returned with a successful return as the ticket for the client to use.
Note: The application keys that correspond to tpsysadm and tpsysop must be 0x80000000 and 0xC0000000, respectively.
By default, the file $TUXDIR/udataobj/tpldap is used for obtaining LDAP configuration information. The file can be overridden by specifying the file name, using a "-f filename" option in the server command line option. For example, CLOPT="-A -- -f/usr/tuxedo/myapp/myldap". There is no automatic propagation of this configuration file from the master machine to other machines in the Tuxedo UBBCONFIG file. To use multiple LAUTHSVRs, you must provide separate configurations on the various machines.
For additional information pertaining to LAUTHSVR, see LAUTHSVR Additional Information.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||