![]() ![]() ![]() ![]() ![]() ![]() ![]() |
The following sections provide information that you need to know before installing the Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) product software:
The Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) product software installer is based on the Oracle Universal Installer (OUI). To install the Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) product software on your host, you must know how to use OUI to install Oracle products. For more information, see Introduction to Oracle Universal Installer.
OUI is a Java-based installer that enables you to install Oracle components.
When you install Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3), an Oracle home is created. Oracle home is managed by OUI.
An Oracle home is the system context where Oracle products run. It consists of the following:
To install Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) and create the Oracle home, do the following steps:
To remove an existing Oracle home, run OUI and click Deinstall Products. In the inventory dialog, select the home(s) you want to delete and click Remove. You can also use the REMOVE_HOMES
variable in the command line or in a response file.
[On UNIX] ./runInstaller -deinstall -silent ORACLE_HOME=<LOCATION_OF_ORACLE_HOME> "REMOVE_HOMES={<LOCATION_OF_ORACLE_HOME_TO_BE_REMOVED>}"
By default, when you start OUI, it searches your system to determine the default Oracle home where Oracle software should be installed.
In each case, the ORACLE_HOME
name is taken first from the command line if it is specified, or from the response file if specified. If not specified, the following convention is used for the name:
Ora<Oracle Home Name>
The ORACLE_HOME
path is taken first from the command line if specified, or from the response file if specified. If not specified, the ORACLE_HOME
environment variable is used.
If ORACLE_BASE
is specified in the environment, the default ORACLE_HOME
starts with $ORACLE_BASE
.
OUI supports the installation of several active Oracle homes on the same host as long as the products support this at run-time. Multiple versions of the same product or different products can run from different Oracle homes concurrently. Products installed in one home do not conflict or interact with products installed on another home. You can update software on any home at any time, assuming all Oracle applications, services, and processes installed on the target home are shut down. Processes from other homes may still be running.
The Oracle home currently accessed by OUI for installation or deinstallation is the target home. To upgrade or remove products from the target home(s), these products must be shut down or stopped.
The OUI inventory stores information about all Oracle software products installed in all Oracle homes on a host (provided the product installed using Oracle Universal Installer).
Inventory information is stored in Extensible Markup Language (XML) format. The XML format allows for easier problems diagnosis and faster data loading. Secure information is not stored directly in the inventory. As a result, during removal of some products, you may be prompted to enter the required credentials for validation.
The OUI inventory has the following hierarchical structure:
Every Oracle software installation has an associated Central Inventory where details of all Oracle products installed on a host are registered. The Central Inventory is located in the directory that the inventory pointer file specifies. Each Oracle software installation has its own Central Inventory pointer file that is unknown to another Oracle software installation.
For Oracle homes sharing the same Central Inventory, OUI performs all read and write operations on the inventory. The operations on the Central Inventory are performed through a locking mechanism. This implies that when an installation, upgrade, or patching operation occurs on an Oracle home, these operations become blocked on other Oracle homes that share the same Central Inventory.
Below table shows the location of the default inventory pointer file for various platforms:
In UNIX, if you do not want to use the Central Inventory located in the directory specified by the inventory pointer file, you can use the -invPtrLoc
flag to specify another inventory pointer file. The syntax is as follows:
./runInstaller -silent -invPtrLoc <Location_of_oraInst.loc> ORACLE_HOME="<Location_of_Oracle_Home>" ORACLE_HOME_NAME="<Name_of_Oracle_Home>"
Note: | If the content of the oraInst.loc file is empty, OUI prompts you to create a new inventory. |
The Central Inventory contains information relating to all Oracle products installed on a host. It contains the following files and folders:
This file lists all Oracle homes installed on the node. For each Oracle home, it also lists the Oracle home name, home index, and nodes where home is installed. It also mentions if the home is an Oracle Clusterware home or a removed Oracle home. It can only detect removed Oracle homes created using OUI version 11.1 and later.
<central inventory location>/ContentsXML/inventory.xml
Note: | It is recommended that you do not remove or manually edit this file as it could affect installation and patching. |
The Central Inventory contains installation logs at the following location:
<central inventory location>/logs
The logs directory contains the logs corresponding to all installations performed on a particular node. You can also find a copy of the installation log in the $ORACLE_HOME/cfgtoollogs
directory.
The installation logs for an installation are identified by the timestamp associated with the log files. These files are generally saved in the following format:
<Name_of_Action><YYYY-MM-DD_HH-MM-SS{AM/PM}>.log
For example, consider an attachHome
operation performed on 17th, May, 2007 at 6.45AM. The associated log file would be created as follows:
AttachHome2007-05-17_06-45-00AM.log
Note: | The installation logs do not contain any errors or failures. |
The Oracle home inventory (or local inventory), is present inside each Oracle home. It contains information relevant to a particular Oracle home. This file is located at:
$ORACLE_HOME/inventory
It contains the following files and folders:
This file contains details about third-party applications (like Java Runtime Environment (JRE)), required by different Java-based Oracle tools and components. In addition, it also contains details of all the components as well as patchsets or interim patches installed in the Oracle home. This file is located at:
ORACLE_HOME/inventory/ContentsXML/comps.xml
This file contains node list details, the local node name, and the CRS
flag for the Oracle home. In a shared Oracle home, the local node information is not presented. This file also contains the following information:
GUID
— Unique global ID for the Oracle homeARU ID
— Unique platform ID. The patching and patchset application depends on this ID.ARU ID DESCRIPTION
— Platform description
The information in oraclehomeproperties.xml
overrides the information in inventory.xml
. This file is located at:
$ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml
The following table lists the other folders you can find in the Oracle home inventory:
OUI enables you to set up the Central Inventory on a clean host or register an existing Oracle home with the Central Inventory when it is lost or corrupted. If the Central Inventory does not exist, OUI creates the Central Inventory in the location specified by the oraInst.loc
file.
You can set up the Central Inventory by using the -attachHome
flag of Oracle Universal Installer. The syntax is as follows:
./runInstaller -silent -attachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
"CLUSTER_NODES={<node1,node2>}" LOCAL_NODE="<node_name>"
You can use the following session variables:
After attaching the Oracle home, you can verify the success of the operation by verifying the contents of the log file located in the <central_inventory>/logs
directory. You can also view the contents of the inventory.xml
file under the <central-inventory>/ContentsXML
directory to verify if the Oracle home is registered.
You can detach an Oracle home from the Central Inventory. When you pass the flag, it updates the inventory.xml
file presented in the Central Inventory. The syntax is as follows:
./runInstaller -silent -detachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
If you are using a shared Oracle home, use the -cfs
flag. This ensures that the local node information is not populated inside a shared Oracle home.
./runInstaller -silent -cfs -detachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
./runInstaller -silent -detachHome -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
You can completely clean the Oracle home and remove the home directory using the -removeallfiles
flag. The syntax is as follows:
./runInstaller -silent -deinstall -removeallfiles -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
If you want to disable the warning message that appears when you use the -removeallfiles
flag, use the -nowarningonremovefiles
flag. The syntax is as follows:
./runInstaller -silent -deinstall -nowarningonremovefiles -invPtrLoc ./oraInst.loc
ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Oracle_Home_Name>"
Even after all Oracle homes on a host are removed, you will find traces of the inventory with certain log files. If you do not want to maintain these files and want to remove the Central Inventory, do the following:
You can remove the Central Inventory on UNIX. Do the following steps:
You can back up the Oracle home using your preferred method. You can use any method (such as zip, tar, and cpio), to compress the Oracle home.
It is highly recommended to back up the Oracle home before any upgrade or patch operation. You should also back up the Central Inventory when Oracle home is installed or deinstalled.
The inventory (Central and the Oracle home inventory) is critically important in Oracle software life-cycle management. The following sections explain what you need to do in case of inventory corruption.
This section introduces you OUI response file availability for silent and suppressed installations. This section also describes how to modify or create a response file so you can customize and standardize Oracle products installation in your organization.
A silent installation runs in the console and does not use the GUI. The interactive dialogs you normally see are not displayed during silent installation. Instead of prompting you to select a series of installation options, OUI installs the software using a predefined set of options stored in the response file or entered in the command line. You can view silent installation progress in the console.
A response file is a specification file containing information you normally enter through the OUI user interface during an interactive installation session. Each answer is stored as a value for a variable identified in the response file. For example, values for Oracle home or installation type can be set automatically within the response file.
Silent installation can be useful if you have to install an Oracle product multiple times on multiple computers. If the options you select while installing on each computer are always the same, you save the time of reviewing each installation screen and selecting the various installation options.
Silent installations can also ensure that multiple users in your organization use the same installation options when they install your Oracle products. This makes supporting those users easier because you already know what components and options have been installed on each computer.
Before you perform silent installation, you should review the settings in the response file template provided with your Oracle product.
Notes: |
oraInstRoot.sh
script with root privileges upon successful installation. _*Central Inventory - oraInventory *_
directory. This script sets up the Central Inventory on a clean host. You can override the default location by setting it in INVENTORY_LOCATION
. /var/opt/oracle/oraInst.loc
(or /etc/oraInst.loc
for Linux, AIX, and Sequent).Note: | For more information, see Oracle Universal Installer Inventory. |
You can create a new response file, based on the installation options you select, using OUI record mode.
When you use record mode, OUI records the installation session into a response file. You specify the name of the response file in the command line. The recorded response file is generated immediately after the Summary page, so you do not need to actually install your Oracle product to create the response file. That is, you can start the installation in Record mode and proceed through the installation options until you get to the Summary page. On the Summary Page, click Exit to stop the installation from proceeding with the installation. However, all the options you selected will be saved in the resulting response file.
You can use the newly created response file to run identical installation sessions on other computers in your organization.
Record mode can be also used during a silent installation. In those cases, the variable values specified in the original source response file will be recorded into the new response file.
The following sections describe how to use record mode on UNIX systems.
To record a new response file:
with the complete path for the new response file. For example:
./runInstaller -record -destinationFile /private/temp/install_oracle11g.rsp
When OUI displays the Summary page, you can either continue with the installation or exit.
OUI saves your new response file using the path and file name you specified on the command line.
The following sections describe the organization and content of an OUI response file.
Note: | It is recommended that you use an absolute path for the file name. However, if the file name is a relative path, it should be relative to the directory where the oraparam.ini file is presented. |
All variable values within a response file are in the name-value format. If two components have a variable with the same name, the expression should be written as follows to preserve the uniqueness of each variable:
<component>:<variable>=<value>
If two components have the same internal name, but are different versions, resolve the ambiguity by specifying the expression as follows:
<component>:<version>:<variable>=<value>
OUI looks for command line variables in the following order:
<component>:<version>:<variable>=<value>
<component>:<variable>=<value>
<variable>=<value>
Similarly, if command line variables are not found, OUI looks for variables in the response file in the same order as shown above.
Note: | OUI treats incorrect context, format, or type values within a response file as if no value were specified. |
There are no restrictions on where you place entries in the response file. You can insert entries in any order desired. You can also subsequently move existing entries to any other position within the file. Be aware, however, that although the order of the entries is unimportant, naming conventions require that the variable names must be unique regardless of where they appear in the file.
Values for variables are specified as:
<variable> = <recommendation> : <value>
The values that are given as <value_required>
must be specified for silent installation to be successful.
For values given as <value_unspecified>
, you can optionally specify a value, where <value>
can be one of the following types listed in below table.
The <recommendation>
parameter can be specified as Forced
or Default
.
Forced
, no dialog appears during installation. The value is automatically used. You cannot change the value.Default
, the dialog appears during installation with the value as the default. You can choose another value if desired.<recommendation>
, Forced
is used as the default
.
Comments begin with a "#
" (hash or pound) symbol. They contain information about the type of the variable, state whether the variable appears in dialog, and describe the function of the variable. A variable and a value are associated with a comment.
#TopLevelComponent;StringList;Used in Dialog
TopLevelComponent={"Demo", "1.0"}
The header is a comment that describes the different formats and comment conventions used in a response file.
#Parameter : UNIX_GROUP_NAME
#Type : String
#Description : UNIX group to be set for the inventory directory.
#Valid only on UNIX platforms.
#Example : UNIX_GROUP_NAME = "install"
UNIX_GROUP_NAME=<Value Unspecified>
The following list describes OUI parameters. All products installed using OUI have these parameters in addition to product-specific variables.
Note: | The parameters provided below are OUI-specific and not necessarily the parameters applicable for your platform and version. Always check your specific installation guide for the list of valid response file parameters. |
Note: | For Oracle Tuxedo Mainframe Adapter for SNA specific response file parameters, see Required Variables in Oracle Tuxedo Mainframe Adapter for SNA Response File. |
Specifies the list of response files to be included in a particular response file. If you want to include other response files in your main response file, you must use this parameter. Note that the values in the main response file have priority over the included response files.
INCLUDE={"file1.rsp","file2.rsp",............."filen.rsp"}
You should specify the absolute path in the INCLUDE
statement for each response file to be included. If you wish to specify a relative path, note that the location is relative to the current working directory (the location of the oraparam.ini
file).
Specifies the version number of the response file.
RESPONSEFILE_VERSION = <version_number>
The location of the source of the products to be installed. The default generated value for this parameter is a path relative to the location of the runInstaller
file oraparam.ini
. Relative paths are necessary for shared response files used by multiple users over a network. Since people may be mapping to different drives, absolute paths will not work for shared response files.
Notes: |
FROM_LOCATION
for a complete silent installation. You may want to use the command line to set this parameter. If the location is a relative path, remember that the path should be relative to the location of the oraparam.ini
file./var/opt/oracle/oraInst.loc
(or /etc/oraInst.loc
for Linux, AIX, and Sequent) exists. The response file for UNIX has a public variable, setunixinstallgroup
, which only becomes effective when it is the first OUI installation and the oraInst.loc
file is not already present at the location mentioned above.
Used in multiple-CD installations. It includes the label of the compact disk where the file products.jar
exists. You can find the label in the disk.label
file in the same directory as products.jar
.
This parameter is for the complete path to other disks.
LOCATION_FOR_DISK2="F:\teststage\cd\Disk2"
If there are more than two disks, more variables will be added as LOCATION_FOR_DISK3
, and so on.
The CD location for a silent installation is located using two mechanisms:
Therefore, you can either specify the location to look for it in the response file or you can copy them into the disk. For example:
<Product_Shiphome_Location>/stage
Set this boolean variable to TRUE
if you want to restart the system without user confirmation. This is the force value for restarting the system.
Set this boolean variable to TRUE
if the installer needs to go to the File Locations page for another installation or to another response file if you are performing a silent installation.
NEXT_SESSION = TRUE
Set this boolean variable to TRUE
to allow users to invoke another installation session even if the current installation session fails. This variable is used only if NEXT_SESSION
variable is set to TRUE.
NEXT_SESSION_ON_FAIL = TRUE
Use this string variable to enter the complete path of the response file for the next session if you want to automatically begin another silent installation when the current installation is complete. If you specify only a file name, the Installer looks for the response file in the <TEMP>/orainstall
directory. This variable is only used if NEXT_SESSION
is set to TRUE
; otherwise, OUI ignores the value of this variable.
NEXT_SESSION_RESPONSE="/private/usr2/nextinstall.rsp"
The location where products are to be installed. You must enter a value for ORACLE_HOME
for a complete silent installation.
The name of the current Oracle home. You must enter a value for ORACLE_HOME_NAME
for a complete silent installation.
The location page, which appears in a custom installation type, can be suppressed by setting this value to FALSE
. If you set the value to FALSE
, you are prevented from specifying alternate directories. If there are products with installed directories which can be changed, you may want to set the value to TRUE
.
Set SHOW_CUSTOM_TREE_PAGE
to TRUE
if the custom tree page in the installer must be shown. In the Custom Tree page, dependencies can be selected or deselected. This page appears only during custom installation type.
The installation success/failure page, which appears at the end of an installation, can be suppressed by setting this value to FALSE
.
Set to TRUE
if you need to show the confirmation when exiting the installer.
The installation progress page, which appears during the installation phase, can be suppressed by setting the value to FALSE
.
Set to TRUE
if you must show the Optional Configuration Tools page in the installer. The Optional Configuration Tools page shows a list of optional configuration tools that are part of this installation and the status of each tool, including detailed information on why the tool has failed.
Set to TRUE
if you need to show the Confirmation dialog asking to run the root.sh
script in the installer. This variable is valid only on UNIX platforms.
SHOW_ROOTSH_CONFIRMATION = TRUE
Set to TRUE if the initial splash screen in the installer needs to be shown.
SHOW_SPLASH_SCREEN = TRUE
The Summary page can be suppressed by setting this value to FALSE
.
Set to TRUE
if you need to show the Welcome page on the installer.
SHOW_WELCOME_PAGE = FALSE
Set this parameter to TRUE
if you want the release notes for this installation to be shown at the end of the installation. A dialog box lists the available release notes. Note that the SHOW_END_SESSION
parameter must be set to TRUE
before you can use this parameter.
The name of the component (products), and the version as a string list. You must enter a value for TOPLEVEL_COMPONENT
.
Usually, the components are represented with a pair of strings: the first one representing the internal name, the second representing the version.
For example, RDBMS 11.1. may be represented as {"oracle.rdbms","11.1.0.0.0"}.
The UNIX group name to be set for the inventory on UNIX platforms.
Note: | The UNIX group name is used for first-time installations only. |
Use to identify the Oracle home(s) you want to remove from the inventory during a deinstallation session. For each home, specify the home name using the full path information.
REMOVE_HOMES={"/home/oracle/ora9i","/home/oracle/ora8i"}
Use to enter a list of components to be removed during a silent deinstall session. For each component, specify the internal component name and version.
DEINSTALL_LIST={"sample1","1.0.0.0.0"}
Set to FALSE
if you want to hide the deinstall confirmation dialog box during silent deinstallation.
Set this parameter to FALSE
if you want to hide the deinstallation progress dialog box during silent deinstallation.
List of dependents on which the component depends. These dependent components represent the list of components that appear as "selected" during installation. Following is a list of a few parameter characteristics:
DEPENDENCY_LIST
variable is only generated when dependencies are present and if the dependency is not a required one.A typical example is listed here:
DEPENDENCY_LIST={"oracle.netclt","9.2.0.4.0","oracle.netmgr","9.2.0.4.0"}
Lists the nodes on the cluster where Oracle home is installed or would be installed. For new installations, this would be the node list where the installation needs to be done (including the local node). For patching or upgrades, this is the node list where Oracle home is already installed.
"CLUSTER_NODES={alpha-1, alpha-2}"
Lists the remote nodes (apart from the local node), on the install cluster during a silent installation. OUI installs on all named nodes.
"REMOTE_NODES={alpha-1, alpha-2}"
This parameter specifies the current node where the installation occurs.
LOCAL_NODE={}
While all the required configuration tools are launched by the installer, you can control the optional configuration tools you would want to launch by specifying the tool internal names in the OPTIONAL_CONFIG_TOOLS
section.
Note: | The OPTIONAL_CONFIG_TOOLS variable is only generated when at least one optional configuration tool is available. |
You can also call the Net Configuration Assistant or the Database Configuration Assistant at the end of a database installation in silent mode. For example, to launch the Net Configuration Assistant in silent mode, you can pass the parameter s_responseFileName="netca.rsp"
.
You can specify both the Auto-launch optional tools and User-launch optional tools in a string list.
OPTIONAL_CONFIG_TOOLS = {"configtool2 ", "configtool3"}
OPTIONAL_CONFIG_TOOLS=<Value Unspecified>
If no value is specified for this variable, all the tools are run by default. If there is a value specified, only those optional tools are run while the rest of the tools are ignored.
Suppress the configuration tool by mentioning only the tools that you want to run as part of the OPTIONAL_CONFIG_TOOLS
variable added for each component. You should use the configuration tool internal names.
The response file generator generates these internal names also as part of the options provided for the variable.
For example, if oracle.server
has Tool1
and Tool2
and you want to run only Tool1
in the response file, you can specify it as follows:
oracle.server:11.1.0.0.0:OPTIONAL_CONFIG_TOOLS={"Tool1"}
You can set the installation type variable to determine the installation type of the currently selected top-level component.
The installation type variable is only generated for top-level components and only when there is more than one installation type available.
Note: | You must enter a value for INSTALL_TYPE . |
You can set the languages for component installation. You must use the internal name while specifying the value:
en, : English
ja, : Japanese
For example, to specify Japanese:
SELECTED_LANGUAGES = {"ja"}
Note: | The SELECTED_LANGUAGES variable is only generated when more than one language is available. |
Many Oracle software products provide tools and procedures for running OUI from the command line without displaying OUI screens or responding to questions during the installation.
These are called silent installations. Instead of prompting you to select a series of installation options, OUI installs the software using a predefined set of options. These options are stored in a response file (.rsp
).
Note: | If you attempt to perform a silent installation on a UNIX computer where no Oracle products have been installed, you will receive an error message. Before you can perform a silent installation on such a computer, you must first run the oraInstRoot.sh script, which is saved in the /oraInventory directory. You must run this script with root privileges. This enables OUI to set up the Central Inventory on a clean host. |
Note: | For more information, see Oracle Universal Installer Inventory. |
To start OUI and specify the response file, enter the following on the command line in the directory where the executable file is installed:
On UNIX: ./runInstaller -responseFile <filename> <optional_parameters>
Note: | You must specify the complete responseFile path. If you do not, OUI assumes the location to be relative to the oraparam.ini file associated with the launched OUI. |
For help on command line usage, enter the following on the command line in the directory where the executable file is stored:
./runInstaller -help
Optional parameters you can use with the -responseFile
flag are:
-nowelcome
— Used flag with the -responseFile
flag to suppress the Welcome dialog that appears during installation.-silent
— Used with the -responseFile
flag to run OUI in complete silent mode. Note that the Welcome dialog is suppressed automatically.silentInstall<timestamp>.log
for hosts without an Oracle inventory. This file is generated in the /tmp
directory on UNIX.Note: | Using the -nowelcome option with the -silent option is unnecessary since the Welcome screen does not appear when you use the -silent option. |
With OUI 2.1 and higher, you can specify the value of certain variables when you start OUI from the command line. Specifically, you can specify session and component variables.
For more information, see Response File Format.
Note: | When you specify the value of a variable on the command line, that value overrides the value of the variable if it is defined in the response file. |
To specify the value of a session variable, use the following command syntax:
./runInstaller session:<variable_name>=<value>
For example, to prevent the Universal Welcome page from displaying:
./runInstaller session:SHOW_WELCOME_PAGE=false
Note: | The "session: " tag is optional and is used mainly to remove any possible ambiguity. |
To specify the value of a component variable, use the following command syntax:
./runInstaller <component_name>:<component_version>:<variable_name>=<value>
You can use OUI to install Oracle products in any of the three following modes:
Use OUI interactive mode to use the graphical user interface to walk through the installation, providing information in the installation dialogs when prompted. This method is most useful when installing a small number of products in different setups on a small number of hosts.
Use OUI suppressed mode to supply the necessary information by using a combination of a response file or command line entries with certain interactive dialogs. You can choose which dialogs to suppress by supplying the information on the command line when you invoke OUI. This method is most useful when an installation has a common set of parameters that can be captured in a response file, in addition to custom information that must be input by hand.
Use OUI silent installation mode to bypass the graphical user interface and supply the necessary information in a response file. This method is most useful when installing the same product multiple times on multiple hosts. By using a response file, you can automate the installation of a product for which you know the installation parameters.
Note: | When you invoke runInstaller (UNIX), you should invoke it from the directory where this command is present, or you must specify the complete path to runInstaller (UNIX). |
The following sections describe special instructions that apply when you are installing certain products on a UNIX system.
If you receive an Xlib
error or a "Failed to connect to Server
" error when you are running OUI on the Solaris operating system, do the following:
%setenv DISPLAY <machine name>:0.0
<machine name>
with the name of the computer that will display OUI.%xhost +
runInstaller
script after you have set the DISPLAY
environment variable.Note: | You can run OUI without specifying the DISPLAY variable by running in silent mode using a response file. |
You must have root privileges to perform various UNIX installation operations. For example, you must have root privileges to be able to create the OUI inventory.
If you are installing OUI for the first time, you are prompted to run a shell script from another terminal window before proceeding with the installation. OUI prompts you to run root.sh
after installation completes only if the script is required to run as root before configuration assistants are run. Otherwise, you are prompted to run root.sh
as root later.
Note: | When running OUI in silent mode, if root.sh is required prior to configuration assistants, OUI skips configuration assistants during the installation. You must run root.sh as root and then run the skipped configuration assistants after the silent installation is complete. |
To successfully run the required shell script:
su -root
./root.sh
.Note: | Do not exit the installation to run the shell script. Exiting the installation removes this script. |
Note: | You are prompted to run the script only the first time you install. |
If you are installing a product on a UNIX system, the Installer also prompts you to provide the name of the group that owns the base directory.
You must choose a UNIX group name that has permissions to update, install, and remove Oracle software. Members of this group must have write permissions for the chosen base directory.
Only users who belong to this group are able to install or remove software on this host.
You can deinstall Oracle products before selecting products to install, or after a successful installation.
To remove an Oracle product or Oracle home using interactive mode, do the following steps:
OUI warns you of any product dependencies that might cause problems if particular products are removed, and prompts you to confirm the deinstallation.
Pay special attention to the full list of products being removed before proceeding. OUI computes this list based on the dependencies of each component.
Note: | You can also remove products by using the OUI Installed Products button as long as you perform this action before selecting products to install. |
A top-level component is the most important component of an installation. It is the installable product you see on the first installation screen. You can only install one top-level component for each installation session.
When you select a specific component for removal, OUI analyzes the dependency information to determine if other components should be removed along with it. Generally, if a component is selected for removal, the following components are removed with it:
All components that have a required dependency on the selected component.
Dependents of the selected component that have no other dependents. A dependent is a component on which the top-level component (dependent), has a dependency.
Not only can you perform command line installations, you can also perform command line deinstallations. A command line deinstallation enables you to remove Oracle products or Oracle homes from your system without using the OUI graphical user interface.
You can choose to display no dialog boxes or prompts, or you can selectively avoid displaying certain dialog boxes that are normally used during a deinstallation.
Use the following commands to immediately display the Inventory dialog box, which allows you to select items for removal without navigating the OUI startup screen:
./runInstaller -deinstall -silent
(on UNIX)
If you want to hide the inventory dialog box during a deinstallation, you can specify the products to be removed in the response file DEINSTALL_LIST
parameter; specify Oracle homes to be removed with the REMOVE_HOMES
variable.
As with other response file parameters, you can also specify the DEINSTALL_LIST
parameter on the OUI command line. For example, on a UNIX machine, enter:
./runInstaller -deinstall -silent DEINSTALL_LIST={"component1","1.0.1.2.0"}
To remove Oracle homes from the inventory, use the REMOVE_HOMES
variable.
Use the following commands to hide the deinstallation confirmation and progress dialog boxes during a command line deinstallation:
./runInstaller -deinstall -silent session:SHOW_DEINSTALL_PROGRESS=false session:SHOW_DESINSTALL_CONFIRMATION=false
When you install or deinstall products using OUI, important information about each installation is saved not only in the inventory, but also in a series of log files, located in the following directory:
$ORACLE_HOME/cfgtoollogs
You can use these log files to troubleshoot installation problems. These files are also crucial for removing and configuring the various software components you install on your UNIX computer. OUI displays the name and location of the current session log file on the Install page. Each installation or configuration utility provides a separate folder containing the logs inside the $ORACLE_HOME/cfgtoollogs
folder.
Note: | The logs used to remove products are different from the installActions<timestamp>.log generated during the install process. The installActions<timestamp>.log is easier to read and can be used to view the operations performed at installation time. |
OUI runs in the operating system language. OUI uses the language that Java detects, the system locale value, and sets that to the default language. OUI dialogs are displayed in this language if available. If specific OUI dialogs are not translated in the language of the operating system, these dialogs are shown in English.
OUI displays the translated GUI only if the variable NLS_ENABLED
has been set to TRUE
in the oraparam.ini
file. If the NLS_ENABLED
variable is set to FALSE
, all text is shown in English.
Note: | The dialogs displayed for internationalization can only be customized parts; some of them are embedded in OUI. |
You must consider configuration as you prepare to install the TMA SNA software. The normal TMA SNA environment includes two properly configured components: the Tuxedo Mainframe Adapter for SNA Gateway and the Communications Resource Manager (CRM). The type of network connectivity you are working with determines which type of CRM installation and configuration is required.
When the Tuxedo Mainframe Adapter for SNA Gateway and CRM are installed on the same machine with the CRM configured as a Tuxedo server, the installation is referred to as a local (combined) configuration. When these components are installed on different UNIX, or mainframe platforms, the installation is referred to as a distributed (or remote) configuration. The diagrams in the following sections show examples of the TMA SNA components in three types of configurations.
Local configuration consists of the application, which is the Tuxedo Mainframe Adapter for SNA Gateway and the CRM with the necessary libraries needed to communicate with the stack on the same UNIX platform. This configuration uses the IBM proprietary SNA protocol for transactions with the mainframe via the stack. This configuration requires a one-to-one relationship between the local Tuxedo Mainframe Adapter for SNA Gateway and the CRM.
In a distributed configuration, the CRM is installed on a different platform than the Tuxedo Mainframe Adapter for SNA Gateway and applications.
One type of distributed configuration separates applications and the Tuxedo Mainframe Adapter for SNA Gateway from the CRM by installing the CRM to the z/OS mainframe. This configuration eliminates the need for a third-party stack on the UNIX machine. This configuration requires a one-to-one relationship between the local Tuxedo Mainframe Adapter for SNA Gateway and the remote CRM.
Another type of distributed configuration separates applications and the Tuxedo Mainframe Adapter for SNA Gateway from the CRM on different UNIX-based platforms. This configuration uses Transmission Control Protocol/Internet Protocol (TCP/IP) connectivity between the TMA SNA Gateway and the CRM, as well as the SNA connectivity to the mainframe environment(s). This configuration provides the flexibility to deploy the ATMI platform separately from the CRM in installations that require the ATMI platform on an operating system other than the one on which the SNA stack is running. This configuration also requires a one-to-one relationship between the local Tuxedo Mainframe Adapter for SNA Gateway and the remote CRM.
Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) contains the following components:
The Oracle Tuxedo Mainframe Adapter for SNA must be installed into an Oracle Home which has already installed Oracle Tuxedo 12c Release 2 (12.1.3) server component (Rolling Patch 003 or above is required on certain platforms).
Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) must be installed on a supported OS version for the given platform. Refer to Supported Oracle Tuxedo Mainframe Adapter for SNA Gateway Platforms for the supported platforms.
The Oracle Installation program uses a temporary directory in which it extracts the files from the archive that are needed to install Oracle Tuxedo Mainframe Adapter for SNA on the target system. During the installation process, your temporary directory must contain sufficient space to accommodate the compressed Java Runtime Environment (JRE) bundled with the installer and an uncompressed copy of the JRE that is expanded into the temporary directory. The installation program moves the JRE from the temporary directory to the Oracle Home directory at the end of the installation process. For information about the Oracle Home directory, see Oracle Home Directory.
By default, the installation program uses the temporary directories shown in Table 1-1.
To ensure there is adequate temporary space, you may want to allocate an alternate directory for use as a temporary directory for the installation. To do so, perform the appropriate step in Table 1-2 and clean up files as more as possible in the temporary directory before starting the Oracle Installation program.
Whether your TMA SNA software is installed on UNIX, or a mainframe, make sure your system meets the appropriate requirements and that supporting software is operating correctly. The following sections describe mainframe and non-mainframe requirements, and verification of supporting software installations.
Note: | Because TMA SNA interacts with mainframe applications, involve your mainframe system support personnel early in the process of planning and installing your TMA SNA software. Different individuals may be responsible for Multiple Virtual System (MVS), Virtual Telecommunications Access Method (VTAM), Information Management System (IMS), and Customer Information Control System/Enterprise Systems Architecture (CICS TS). Make sure everyone is involved. |
Whether the CRM component of TMA SNA is located on the mainframe environment or not, mainframe configurations affect how TMA SNA software functions. Prepare the mainframe to conduct operations within the Tuxedo Mainframe Adapter for SNA/ATMI platform environment by:
Refer to the Oracle Tuxedo Mainframe Adapter for SNA CRM Administration Guide for detailed information about these tasks.
A non-mainframe environment is a UNIX machine running the TMA SNA software. The software is fully bidirectional, supporting the local system as either a client or server. This environment consists of the following components:
The Tuxedo ATMI platform is not required if you are installing only the CRM on Unix.
The following software should be installed and configured prior to installing the TMA SNA software for UNIX:
Refer to the Tuxedo Mainframe Adapter for SNA Release Notes for a list of supported SNA stacks.
Note: | Refer to the SNA stack vendor’s documentation on configuring your environment. A properly configured SNA protocol stack is required for the CRM to communicate with the mainframe application. |
simpapp
or bankapp
.Refer to the corresponding product installation documentation for installation and configuration information. Some specific configuration tasks must be completed before you install TMA SNA.
The Oracle Tuxedo Mainframe Adapter for SNA software is distributed as an installer file, which also contains a copy of the Oracle Installation program. The Oracle Installation program is the Oracle standard tool for installing the Oracle Tuxedo Mainframe Adapter for SNA software on UNIX systems.
The Oracle Installation program supports two installation methods. You can use any of these methods to install the Oracle Tuxedo Mainframe Adapter for SNA product software:
Clicking the “Cancel” or the “close’ window button in GUI mode creates an incomplete Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) installation. You will have to re-install Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3).
If you installed Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) in a previous Tuxedo product directory, and you want to return to your original configuration, you must re-install your previous Oracle Tuxedo Mainframe Adapter for SNA version.
An install type is a bundle of product software components related by function. Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) offers the following install types:
Notes: |
In addition to selecting an install set during an Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3) installation, a user can further customize the installation by selecting (adding) or deselecting (deleting) one or more software components from the install set. Customizing is only possible for GUI-mode installation methods described in Installing Oracle Tuxedo Mainframe Adapter for SNA Using GUI-Mode Installation.
When you install Oracle Tuxedo Mainframe Adapter for SNA, you are prompted to specify an Oracle Home directory. The Oracle Home directory is a repository for common files that are used by multiple Oracle products installed on the same machine.
An Oracle home is the system context where Oracle products run. This context consists of the following:
During the installation of Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3), you are prompted to choose an existing Oracle Home directory, where Oracle Tuxedo Mainframe Adapter for SNA is installed. Particularly, CRM can also be installed in a different directory from Oracle home.
OUI supports the installation of several active Oracle homes on the same host as long as the products support this at run-time. Multiple versions of the same product or different products can run from different Oracle homes concurrently. Products installed on one home do not conflict or interact with products installed on another home. You can update software on any home at any time, assuming all Oracle applications, services, and processes installed on the target home are shut down. Processes from other homes may still be running.
You are now ready to begin your installation. To install Oracle Tuxedo Mainframe Adapter for SNA 12c Release 2 (12.1.3), see one of the following sections:
If you want to uninstall your Oracle Tuxedo Mainframe Adapter for SNA software, see Post Installation Tasks for Oracle Tuxedo Mainframe Adapter for SNA.
![]() ![]() ![]() |