|
•
|
The $TUXDIR/udataobj/DMTYPE file defining the valid domain types must exist so the dmloadcf utility can load the binary configuration file and must contain a domain type of OSITPX. During the installation process if the DMTYPE file does not contain an OSI TP entry, the DMTYPE file is automatically updated with the required OSITP domain type.
|
You must set OSIRUNDIR, before you can boot the gateway or run the
osiadmin utility. If you do not set the
OSIRUNDIR environment variable before you boot the gateway, you will receive a message telling you to set
OSIRUNDIR. This environment variable specifies the path that the TMA gateway uses for runtime files. You can set the
OSIRUNDIR environment variable through a script, a command line entry, or through the Windows System Properties in the Control Panel. The variable value should include the path and directory as appropriate for your operating system. If the directory does not exist, the system will create it for you.
|
2.
|
Run the osiadmin processor if you are upgrading from eLink OSI TP 1.3. Refer to Using the OSI TP Administration Utility for more information.
|
|
1.
|
In the GROUPS section of the UBBCONFIG file, add a server group using the following format:
|
|
Note:
|
OSIGRP is used as an example. You may give the group any name you wish.
|
|
2.
|
In the SERVERS section of the UBBCONFIG file, add the three server names: DMADM,GWADM,and GWOSITP.
|
|
Note:
|
The DMADM and GWADM entries should be placed in this order BEFORE GWOSITP in the UBBCONFIG file so the admin servers are loaded before the GWOSITP gateway server.
|
Refer to the Oracle Tuxedo Reference Manual for additional information about the
UBBCONFIG file.
Following is a sample UBBCONFIG file and corresponding
DMCONFIG file for multiple gateways that reside on the same physical system. Note that use of
LDBAL=Y in the
UBBCONFIG file is not required for multiple gateways. Loads are automatically balanced for multiple gateways.
Listing 4‑7 shows a sample
UBBCONFIG file and
Listing 4‑8 shows the corresponding
DMCONFIG file for a pass-through configuration.
Note that the service that resides on the backend /TDOMAIN system must be defined as a local service on the TMA OSI TP system, so TMA OSI TP can process the incoming request. It must also be defined as a remote service so that the
/TDOMAIN gateway can pass the service request to the backend
/TDOMAIN system. The gateway system must have available the viewfiles and corresponding environment variables that are required by the service, even though the service exists on the backend system.
The Oracle Tuxedo UBBCONFIG and TMA OSI TP
DMCONFIG files include five sections in which you specify security parameters for whichever type of security you want to implement:
Three sections in the DMCONFIG file contain parameters affecting how TMA OSI TP controls access to the local Tuxedo domain:
|
•
|
DM_LOCAL_DOMAINS section contains a SECURITY parameter that specifies the type of security enforced for the Tuxedo local domain.
|
The SECURITY parameter settings in this section work in conjunction with the
SECURITY parameter in the
RESOURCES section of the Tuxedo domain’s
UBBCONFIG file to establish how TMA OSI TP controls access to the Tuxedo local domain. If this parameter is set to
NONE or
APP_PW, the TMA OSI TP domain takes no action with regard to security. If this parameter is set to
DM_PW, the TMA OSI TP domain enforces security according to the security settings in the
DM_PASSWORDS section of the
BDMCONFIG file.
|
Caution:
|
Do not delete the Tuxedo BDMCONFIG file. The DM_PW information will be lost if the file is deleted. When new passwords are entered, the GWOSITP service must be shut down and restarted for the passwords to take effect.
|
|
•
|
DM_REMOTE_DOMAINS section contains an OPTIONS=SECURITY_SUPPORTED parameter that specifies the type of security enforced for the Tuxedo remote domain.
|
|
•
|
DM_OSITPX section contains an OPTION of SECURITY_SUPPORTED, which indicates that the remote domain supports the OSI TP security extension. The OSI TP security extension allows OSI TP systems to perform link-layer security. The link layer security feature is activated when the DM_LOCAL_DOMAINS section has SECURITY=DM_PW set and OPTIONS= SECURITY_SUPPORTED is set for the remote domain.
|
Listing 4‑9
Sample DMCONFIG File for Establishing Link Layer Security
When SECURITY is set to either "
APP_PW" or "
USER_AUTH", user authentication is performed. If the
ACL_POLICY for the remote domain from which the call was issued is defined as
LOCAL, then the user ID used for authentication will be the
LOCAL_PRINCIPAL_NAME of the remote domain if it has been defined. If the
LOCAL_PRINCIPAL_NAME has not been defined, then the user ID will be the
DOMAINID of the remote domain. If the
ACL_POLICY for the remote domain from which the call was issued is defined as
GLOBAL, then the userid passed with the call is used for user authentication. The user ID is authenticated against the user IDs defined in the
tpusr file.
When SECURITY is set to "
ACL", then user authentication is performed as previously defined for "
APP_PW" and "
USER_AUTH". User authorization of the service, requested in the call, is also performed. ACL authorization requires that the services have been defined in the ACL Service list and that the user be a member of a group that is allowed access to this service. Services are added to the ACL Service list through the
tpacladd command. If the requested service has not been added to the ACL Service list, then all users are allowed access to this service.
When SECURITY is set to "
MANDATORY_ACL" authentication and authorization are performed identical to that for
SECURITY equal "
ACL", however, the request service must be defined in the ACL Service list and the users group must be allowed access to this service.
Listing 4‑10
Sample UBBCONFIG File Showing Security Set to
MANDATORY_ACL.
Listing 4‑11
Sample DMCONFIG File Showing
LLS set and
ACL_POLICY of
LOCALCurrently, the type of XATMI encoding must be configured for each RDOM using the
XATMI_ENCODING parameter in the
DM_OSITPX section of the
DMCONFIG file. An
XATMI_ENCODING keyword value of
NATIVE_A_SERIES is used to indicate that the Tuxedo system will handle the encode/decode of data into the Native MCP format, not the Unisys MCP machine.
There is an optional CODEPAGE parameter on the
RDOM statement in the
DM_REMOTE_DOMAINS section of the
DMCONFIG file. The
CODEPAGE parameter is configured to specify the pair of code sets involved when translating character strings between the Tuxedo system and the MCP (A-Series) system. If
XATMI_ENCODING is not set to
NATIVE_A_SERIES, then the
CODEPAGE parameter is ignored.
*DM_REMOTE_DOMAINS
...
rdom TYPE=OSITPX DOMAINID="
domainid" CODEPAGE="
cpname"
Where cpname is a case-insensitive keyword from the following table.
If XATMI_ENCODING is not set to
NATIVE_A_SERIES, then no conversion of character strings occurs. If
XATMI_ENCODING is set to
NATIVE_A_SERIES, then conversions occur according to the rules described in the following subsections.
All view fields of type string must be null-terminated on both the Tuxedo and NATIVE_A_SERIES encoding feature,
string fields may contain any non-zero bytes, followed by a zero byte as a null-terminator.
All view fields of type string are always translated from the ISO character set to the MCP character set (as specified by the
CODEPAGE parameter) when passing from the Tuxedo system to the MCP system. The input string must be null-terminated; any bytes after the null-terminator are ignored. The resulting string on the Unisys MCP system is null-terminated; any remaining space in the field is also padded with zero bytes.
Conversly, all view fields of type string are translated from the MCP character set to the ISO character set (as specified by the
CODEPAGE parameter) when passing from the Unisys MCP system to the Tuxedo system. The input string must be null-terminated; any bytes after the null-terminator are ignored. The resulting string on the Tuxedo system is null-terminated; any remaining space in the field is also padded with zero bytes.
View fields of type carray need not be null-terminated.
Carray fields may contain any non-zero bytes; if a zero byte is detected, it is treated as a null-terminator and scanning stops.
All view fields of type carray are always translated from the ISO character set to the MCP character set (as specified by the
CODEPAGE parameter) when passing from the Tuxedo system to the Unisys MCP system. The input string may or may not be null-terminated; any bytes after a null-terminator are ignored. The resulting string on the MCP system is not null-terminated; any remaining space in the field is padded with EBCDIC space characters (0x40 bytes).
Conversly, all view fields of type carray are translated from the MCP character set to the ISO character set (as specified in the
CODEPAGE parameter) when passing from the Tuxedo system to the Unisys MCP system. The input string may or may not be null-terminated; any bytes after a null-terminator are ignored. If the input string is not null-terminated, then any trailing EBCDIC space characters (0x40 bytes) are discarded before translation starts. The resulting string on the Tuxedo system is null-terminated if there is room; any remaining space in the field is also padded with zero bytes.
View fields of type char may contain any arbitrary binary data. View fields of type
char are never translated.
To edit the DMCONFIG file manually, perform the following steps:
|
1.
|
Find the DMCONFIG file in your installation directory and open it in any text editor.
|
|
2.
|
Edit the DMCONFIG file as necessary. Refer to the parameter descriptions in this section for details about defining your TMA OSI TP configuration.
|
|
4.
|
Process the DMCONFIG file with the dmloadcf utility. This parses the input and creates a binary file: the BDMCONFIG file, which is used by GWOSITP.Refer to Understanding the DMCONFIG File for more detailed information about the parameters in the DMCONFIG file.
|
|
5.
|
Specify any of the optional DM_LOCAL_DOMAINS parameters that you require: AUDITLOG, BLOCKTIME, DMTLOGDEV, DMTLOGNAME, MAXRDTRAN, MAXTRAN, and SECURITY.
|
|
2.
|
Specify the OSITPX domain type with the TYPE parameter.
|
|
3.
|
Specify any of the optional DM_OSITPX parameters that you require: DNS_RESOLUTION, P_SEL, S_SEL, T_SEL, OPTIONS, TAILOR_PATH, and XATMI_ENCODING.
|
In the DM_ACCESS_CONTROL section of the
DMCONFIG file, specify a list of all the remote OSI TP domain IDs that can access the local domain with the
ACLIST parameter. This parameter is optional.
In the DM_LOCAL_SERVICES section of the
DMCONFIG file, specify the Tuxedo services that will be made available to OSI TP applications and define their options with the
ACL,
COUPLING,
INBUFTYPE,
INRECTYPE,
LDOM,
OUTBUFTYPE,
OUTRECTYPE, and
RNAME parameters. If the local service supports transactions, make sure the group it belongs to contains a
TMS name.
In the DM_REMOTE_SERVICES section of the
DMCONFIG file, specify the remote services that can be requested by Tuxedo applications and define their options with the
AUTOPREPARE,
CODEPAGE,
CONV,
INBUFTYPE,
INRECTYPE,
LDOM,
OUTBUFTYPE, OUTRECTYPE,
RDOM,
RNAME,
ROUTING, and
TRANTIME parameters. These parameters are all optional.
The dmloadcf utility compiles the
DMCONFIG file and creates a binary configuration file,
BDMCONFIG, which is used by the
DMADM server to control the run-time environment.
Figure 4‑3 shows how the
dmloadcf utility processes the configuration file. A description of the process follows the figure.
The dmloadcf utility is invoked from a command line with the following syntax:
dmloadcf [-c] [-n] [-y] [-b blocks] [-k]
DMCONFIG_file
Indicates the number of blocks the device should use to create the Tuxedo file system. If the value of the -b option is large enough to hold the new
BDMCONFIG tables,
dmloadcf uses the specified value to create the new file system; otherwise,
dmloadcf prints an error message and exits. If the
-b option is not specified,
dmloadcf creates a new file system large enough to hold the
BDMCONFIG tables. The
-b option is ignored if the file system already exists. The
-b option is highly recommended if
BDMCONFIG is a raw device (that has not been initialized) and should be set to the number of blocks on the raw device.
The dmloadcf utility prints an error message if any required section of the
DMCONFIG file is missing. If a syntax error is found while parsing the input file,
dmloadcf exits without performing any updates to the
BDMCONFIG file.
A Tuxedo DMTYPE file is required to define the valid domain types. If this file does not exist,
dmloadcf exits without performing any updates to the
BDMCONFIG file.
After syntax checking, dmloadcf verifies that the file pointed to by
BDMCONFIG exists, is a valid Tuxedo System file system, and contains
BDMCONFIG tables. If these conditions are not true and the
-y option was not entered on the command line, the user is prompted to create and initialize the file with
where path is the complete file name of the
BDMCONFIG file and “
Y” indicates that the configuration file should be created.
If the BDMCONFIG file is determined to already have been initialized,
dmloadcf ensures that the local domain described by that
BDMCONFIG file is not running. If a local domain is running,
dmloadcf prints an error message and exits. Otherwise,
dmloadcf confirms that the file should be overwritten by prompting the user with:
If the SECURITY parameter is specified in the
RESOURCES section of the
TUXCONFIG file, then
dmloadcf flushes the standard input, turns off terminal echo, and prompts the user for an application password.
If dmloadcf is run on an active node, the following error message is displayed:
If dmloadcf is run by a person whose effective user ID doesn’t match the
UID specified in the
TUXCONFIG file, the following error message is displayed:
The OSI TP TAILOR file is external to the
DMCONFIG and is used for tuning OSI TP- specific tables. All parameters in the
TAILOR file are optional with preset defaults.
