Table of Contents Previous Next PDF


Configuring and Starting the System

Configuring and Starting the System
To use Oracle Tuxedo Mainframe Adapter for SNA, proper configuration based on your system’s architecture is required. This section covers the following topics:
Note:
Preparing for Configuration
Before you can properly configure your Oracle Tuxedo Mainframe Adapter for SNA Gateway and the CRM to communicate with CICS and IMS applications, you must complete the following prerequisites:
Determine Your System Architecture
To determine your system’s architecture, you must determine the location of the Oracle Tuxedo Mainframe Adapter for SNA components within that architecture.
Oracle Tuxedo Mainframe Adapter for SNA Components
The following basic components of the Oracle Tuxedo Mainframe Adapter for SNA system are factors in configuring your system:
The Oracle Tuxedo Mainframe Adapter Gateway is the transactional SNA gateway. It is implemented as an ATMI domain gateway and uses the ATMI environments. The gateway communicates over a Transmission Control Protocol/Internet Protocol (TCP/IP) connection with the CRM.
The Communications Resource Manager (CRM) communicates with the SNA network using an SNA stack. It communicates with Oracle Tuxedo Mainframe Adapter clients through the Gateway.
The stack is vendor-supplied software that provides connectivity to an SNA network.
System Configuration
Your system architecture will reflect one of the following basic Oracle Tuxedo Mainframe Adapter for SNA configurations:
Local Configuration
Local configuration combines the Tuxedo ATMI platform, the Oracle Tuxedo Mainframe Adapter Gateway, CRM, and SNA stack (PU2.1 server) on the same UNIX platform with CRM configured as a Tuxedo server, as shown in Figure 2‑1. For this version of Oracle Tuxedo Mainframe Adapter for SNA, the platform would be HP-UX 11.23 on PA-RISC because that is the only non-mainframe UNIX platform on which the CRM runs. Local configuration features the widely used TCP/IP connectivity between the Oracle Tuxedo Mainframe Adapter for SNA Gateway and CRM, giving a high-performance communications interface. On the mainframe side, the CRM uses a stack to communicate over a System Network Architecture (SNA) interface with the host system. This configuration allows you to:
Note:
Figure 2‑1 Local Oracle Tuxedo Mainframe Adapter for SNA Configuration on HP-UX 11.23 Platform
Distributed Configuration—CRM on z/OS Host
This distributed configuration deploys the CRM to the z/OS host system as shown in Figure 2‑2. It employs TCP/IP connectivity with the host, eliminating the need for a local SNA stack. This configuration provides a faster network interface and is less complex than the local configuration.
Figure 2‑2 Distributed CRM on z/OS Platform
Distributed Configuration—CRM on HP-UX 11.23 Platform with Gateway on Another UNIX or Windows Platform
This distributed configuration deploys the CRM and stack to a UNIX or Windows platform, as shown in Figure 2‑3. It employs the TCP/IP connectivity between the Oracle Tuxedo Mainframe Adapter Gateway and CRM, as well as the SNA connectivity to the host. This configuration allows you to use multiple stacks from different stack vendors. Also, on the ATMI platform side, you have a greater variety of UNIX-based or Windows platform manufacturers to choose from.
Figure 2‑3 Distributed CRM on UNIX/NT Platform
Configure the Local Host
Ensure that the local host is prepared to conduct operations with the remote host by configuring the Local LU for the appropriate stack.
Refer to the Oracle Tuxedo Mainframe Adapter for SNA CRM Administration Guide for more information about this task.
Configure the Remote Host
Ensure that the remote host is prepared to conduct operations with the ATMI local domain by completing the following tasks:
1.
2.
3.
Refer to the Oracle Tuxedo Mainframe Adapter for SNA CRM Administration Guide for more information about these tasks.
Configuring the Oracle Tuxedo Mainframe Adapter for SNA Gateway
The following list summarizes the tasks that must be completed to configure the Oracle Tuxedo Mainframe Adapter for SNA Gateway (GWSNAX):
1.
Edit the DMTYPE file.
2.
Edit the UBBCONFIG file and load to create the binary.
3.
Edit the DMCONFIG file and load to create the binary.
4.
5.
In addition, if you want TSAM Plus to retrieve customized call ID from every inbound request, do the followings.
Step 1: Edit the DMTYPE File
The DMTYPE file is an ASCII file. Use any text editor to edit this file.
1.
Insert the following line in the DMTYPE file located in the $TUXDIR/udataobj directory:
For UNIX:
SNAX::::
For Windows:
SNAX;;;;
2.
Ensure that the $TUXDIR/udataobj/DMTYPE file exists prior to editing the DMCONFIG file. See dmloadcf in Appendix A, “Administrative Command Reference Pages”for more information.
Step 2: Edit the UBBCONFIG File
The UBBCONFIG file is an ASCII file that can be edited with any text editor. To edit the UBBCONFIG file, complete the following tasks:
1.
Create a UBBCONFIG file for each application. Refer to the Configuration section in the appropriate ATMI platform product documentation for more specific information about the UBBCONFIG file.
2.
3.
If the CRM is to run as an ATMI server in a local configuration, add a CRM entry to the *SERVERS section of the UBBCONFIG file. For a description, refer to the Oracle Tuxedo Mainframe Adapter for SNA CRM Administration Guide.
Note:
4.
Establish the Oracle Tuxedo Mainframe Adapter for SNA Gateway by adding an entry to the *SERVERS section of the UBBCONFIG file. For a description, refer to the GWSNAX command in Appendix A, “Administrative Command Reference Pages.” The following gateway features may be enabled in the UBBCONFIG file:
5.
Listing 2‑1 Sample UBBCONFIG File Entries Specifying CRM as an ATMI Server
*GROUPS
SNAGRP LMID=mysys
GRPNO=4

LOCGRP LMID=mysys
BRPNO=5

*SERVERS
DEFAULT: CLOPT = “-A”

DMADM SRVGRP=LOCGRP
SRVID=14

GWADM SRVGRP=SNAGRP
SRVID=14
REPLYQ=Y
RESTART=N
GRACE=0

SNACRM SRVGRP=SNAGRP
SRVID=15
CLOPT=“-A--//dalhps2:4452 SNAGRP”
RESTART=Y
RCMD=rstsnagrp
GRACE=120
MAXGEN=2

GWSNAX SRVRGRP=SNAGRP
SRVID=16
RQADDR=”SNADOM”
REPLYQ=N
RESTART=Y
RCMD=rstsnagrp
GRACE=120
MAXGEN=2
 
Step 3: Edit the DMCONFIG File
The configuration specified in the DMCONFIG file controls much of the operation of the Oracle Tuxedo Mainframe Adapter for SNA Gateway (GWSNAX). A sample of this file is provided in the installation directory of your Oracle Tuxedo Mainframe Adapter for SNA product software.
Note:
1.
2.
3.
Set each of the parameters of the DMCONFIG file as described in the following sections and load the DMCONFIG file. Refer to the appropriate ATMI documentation for instruction for using dmloadcf to load the DMCONFIG file.
a.
Update the *DM_LOCAL_DOMAINS Section.
This section identifies local domains and their associated gateway groups. The section must have an entry for each gateway group (Local Domain). Entries have the form:
LDOM required parameters {optional parameters}
In this entry, LDOM is an identifier value used to name each local domain. For a full description of the optional and required parameters, see DMCONFIG in Appendix A, “Administrative Command Reference Pages.”
For each LDOM entry, the value of the TYPE parameter distinguishes this gateway from other gateway types. Currently, SNAX replaces the value SNADOM used in previous releases. The parameter entry takes the form:
TYPE={SNAX | OSITP | TDOMAIN}
Select the value TYPE=SNAX for the LDOM entry.
b.
Update the *DM_REMOTE_DOMAINS Section.
This section identifies the known set of remote domains and their characteristics. Entries have the form:
RDOM required parameters
In this entry, RDOM is an identifier value used to identify each remote domain known to this configuration. For a full description of the required parameters, see DMCONFIG in Appendix A, “Administrative Command Reference Pages.”
For each RDOM entry, the value of the TYPE parameter indicates that the remote domain communicates using the SNA protocol. The parameter entry takes the form:
TYPE={SNAX | OSITP | TDOMAIN}
Select the value TYPE=SNAX for the RDOM entry.
c.
Add the *DM_SNACRM Section.
Note:
*DM_SNACRM, *DM_SNASTACKS, and the *DM_SNALINKS sections have replaced the *DM_SNADOM section used in previous releases of eLink Adapter for Mainframe.

Any changes to the *DM_SNACRM, *DM_SNASTACKS, or *DM_SNALINKS sections require a cold start for the Oracle Tuxedo Mainframe Adapter for SNA domain. If you do not cold start the Oracle Tuxedo Mainframe Adapter for SNA domain, an error will occur on domain start-up indicating cold start required for the configuration change.
The *DM_SNACRM section provides three keywords used to identify the CRM that provides ATMI transaction semantics in a given domain and its partners. Entries have the general form:
<CRMName> parameters
In this entry, <CRMName> is the locally known name of this SNACRM definition to be used when referencing this SNACRM in subsequent sections. This name is an ASCII string 1-30 characters in length. The parameters are the keyword/value pairs that make up the definition. All keywords are required for a valid SNACRM definition. Keywords can be in any order.
LDOM=<LocalDomainName> (Required)
LDOM associates this SNACRM with a defined local domain. <LocalDomainName> is the reference to an entry in the *DM_LOCAL_DOMAINS section. This name is an ASCII string 1 to 30 characters in length. This parameter is required. This parameter has no default.
SNACRMADDR=<HexSocketAddress> (Required)
SNACRMADDR provides the socket address the domain gateway uses to communicate with the SNACRM. This address represents the machine and port where the CRM runs. In a local configuration, this address is the local platform. In a distributed configuration, this address is a remote platform. This address must be used on the SNACRM command line. This parameter is required and has no default.
<HexSocketAddress> is a TCP/IP address using //hostname:port_addr or the sockaddr_in format of family, port, address:
<0xFFFFPPPPAAAAAAAA>
In this entry, arguments and options are defined in the following way:
FFFF is the hex value of the protocol family, always 0x0002 for the INET family.
PPPP is the hex value of an unused TCP/IP port.
AAAAAAAA is the hex value of the IP address for the machine running the SNACRM.
Therefore, if the CRM was running on a machine named myhost with an IP address of 206.189.43.13, and you wanted to use port 6000 for the CRM, then SNACRMADDR would be:
//myhost:6000 or 0x00021770CEBD2B0D
NWDEVICE=<Device Name> (Required)
<Device Name> is the logical name used to access the network. For example:
/dev/tcp
d.
Add the *DM_SNASTACKS Section.
The DM_SNASTACKS section provides five keywords that identify the third-party SNA stack that should be used for connections established between a given domain and its partners. Entries have the general form:
<StackReference> parameters
In this entry, <StackReference> is the locally known name of this stack definition and it is used when referencing this stack in subsequent sections. This name is an ASCII string 1-30 characters in length. The parameters are the keyword/value pairs that make up the definition. Keywords can be in any order. All keywords are required for a valid stack definition.
LOCALLU=<LocalLUAlias> (Required)
LOCALLU provides a reference to an LU alias defined in the third-party SNA stack. <LocalLUAlias> is the name used to identify the local LU definition as specified by the third-party SNA stack configuration. This name represents the end node for an LU6.2 connection. The value for this parameter is an ASCII string, 1-8 characters in length. This parameter is required. This parameter has no default. The third party SNA stack requires a corresponding definition for a local LU.
LTPNAME=<LocalTransactionProgramName> (Required)
LTPNAME identifies the inbound transaction programs that are serviced by any SNACRM using this stack definition. <LocalTransactionProgramName> is the name used to identify inbound transaction programs for which an attach will be accepted. The only useful value is an asterisk that indicates all inbound attaches will be accepted. This parameter is required. This parameter has no default. Partial TP names are not supported. The third-party SNA stack requires a corresponding definition for inbound TP names.
SNACRM=<CRMName> (Required)
SNACRM provides a name to which the associated SNACRM definition is referenced. <CRMName> is the name used to associate the *DM_SNACRM definition with this *DM_SNASTACKS entry. The value for this parameter is an ASCII string, 1-30 characters in length. This parameter is required. This parameter has no default.
STACKPARMS=<parameters required for third-party sna stack> (Required)
STACKPARMS provides a method for the domain gateway to pass any required parameters to the third party SNA stack. The <parameters required for third-party sna stack> is an ASCII string, 1-128 characters in length. Currently, the only value used is the TCP/IP hostname for the machine running the third-party SNA stack. This parameter is required. This parameter has no default.
STACKTYPE={hp62 | vt210}
This option is used to indicate which vender SNA stack is being used. It is also used to determine the names of specific Oracle Tuxedo Mainframe Adapter for SNA system libraries. Because of this, it is essential that the value of this option be coded correctly. These values are mapped to the equivalent Oracle Tuxedo Mainframe Adapter for SNA system library.
e.
Add the *DM_SNALINKS Section.
The *DM_SNALINKS section provides 11 key words that define the SNA Link information required by domains of type SNA. Entries have the general form:
<Link Name> parameters
In this entry, <Link Name> is the identifier value used to identify the connection between a local domain (LDOM) and a remote domain (RDOM). This name is an ASCII string 1-30 characters in length. The parameters are the keyword/value pairs that make up the definition. Keywords can be in any order.
STACKREF=<Stack Reference> (Required)
This required parameter defines the stack that will be used for establishment of this link. The STACKREF string is the tag that was used in the corresponding definition established in the *DM_SNASTACKS section.
RDOM=<name>
Each link defines a connection between an ATMI system application domain and a remote system connected with an SNA network. The remote system is, in ATMI terms, a remote domain. The RDOM option associates the link with a remote domain. This remote domain must have been configured with the TYPE=SNAX option. The RDOM name should match an RDOM value previously identified in the *DM_REMOTE_DOMAINS section.
LSYSID=<name>
LSYSID is the four-character identifier for this link. This should match the connection ID in the CICS/ESA resource definition used by a partner CICS/ESA to communicate to the SNACRM across this link. If you are using the macro definition, it is a four-character name on the SYSIDNT option of the DFHTCT macro.
RSYSID=<name>
RSYSID is the four-character remote sysid of the partner. Typically it is the sysid of a CICS/ESA region, but could also be the subsystem ID of an IMS control region. This parameter must match the actual sysid of the remote partner. This name is the SYSIDNT of the DFHSIT or the value in the CICS/ESA start-up overrides
RLUNAME=<name> (Required)
The RLUNAME value represents an alias known to the third-party SNA stack that resolves to a VTAM netname for the remote application. This remote application is most likely the VTAM applid for a CICS/ESA region, however it could also be an APPC/MVS LU defined for use with IMS. The value must be unique within the SNA network. The value name should be 1-8 characters. This parameter is required. This parameter has no default. The third-party stack configuration requires a matching definition.
MODENAME=<name> (Required)
MODENAME is VTAM mode entry defined to the third-party SNA stack. For a CICS/ESA link, this entry must be compatible with the session definition or profile entry for the corresponding connection. For an IMS connection, this entry must be compatible with the DLOGMOD entry on the LU definition used to access the IMS scheduler. The value name should be 1-8 ASCII characters. This parameter is required. This parameter must match the third-party SNA stack configuration and must be compatible with the corresponding entries defined to VTAM and/or CICS/ESA.
SECURITY={LOCAL | IDENTIFY | VERIFY | PERSISTENT | MIXIDPE}
SECURITY specifies the security setting in CICS/ESA connection resource definition. It identifies the level of security enforced under CICS/ESA by the external security manager. Legal values are LOCAL, IDENTIFY, VERIFY, PERSISTENT or MIXIDPE. The default setting is LOCAL. PERSISTENT and MIXIDPE identify the setting in the remote connection definition, but are identical to the VERIFY option in this release of Oracle Tuxedo Mainframe Adapter for SNA.
MAXSESS=<number>
This number represents the maximum number of sessions that can be concurrently acquired on this link. It must be greater than or equal to four, and less than or equal to the maximum number of sessions that can be configured by the SNA stack. The actual number of concurrent sessions is determined by both system configurations to be the lowest maximum number of sessions allowed by either system. The default value is MAXSESS=64.
MINWIN=<number>
This value is the minimum number of contention winners. Typically, this value is half the MAXSESS value. This number added to all CICS/ESA session definition winner numbers for the connection should be equal to the MAXSESS value. The default value is MINWIN=0.
STARTTYPE={AUTO|COLD}
This option sets the recovery mode for transactional links. When set to AUTO, the system restarts using configuration and link data recovered from the transaction log. When set to COLD, the system uses configuration data taken from the current DMCONFIG file and loses any in-flight link data. Changing DMCONFIG file parameters and performing an AUTO start results in a message warning that changed parameters are ignored until the next cold start.
MAXSYNCLVL={0 | 1 | 2}
This value represents the maximum sync‑level conversation that can be supported on this link. The default is sync-level 2. Transaction support is only available at sync-level 2.
Sync-level 0
A value of zero (0) means this link is non-transactional. No synchronization is maintained. This value can be used for sending and receiving messages from IMS via the APPC/MVS transparency interface.
Sync-level 1
Allows sync-level 0 capabilities as well as support for SYNCONRETURN Distributed Program Link (DPL) with CICS/ESA systems (outbound ATMI tpcall() requests with TPNOTRAN).
Sync-level 2
Supports all sync-level 0 and sync-level 1 features for systems able to exchange logs and compare states. In addition, full syncpoint synchronization at sync-level 2 is supported.
f.
Update the *DM_LOCAL_SERVICES Section.
The *DM_LOCAL_SERVICES section provides information on the services exported by each local domain. Entries have the general form:
<Local Service Name> parameters
In this entry, <Local Service Name> is the local name of the exported service. This name is an ASCII string 1-15 characters in length. The parameters are the keyword/value pairs that make up the definition. Keywords can be in any order. For a full description of parameters, see DMCONFIG in Appendix A, “Administrative Command Reference Pages.”
RNAME=<name> (Required)
The RNAME option is the local-service name imported from a remote CICS/ESA region. This name is used by the CRM to select a local service.
When the RNAME specifies an alternate mirror transaction identifier for explicit attachment for inbound DPL requests, it must be a combination of the alternate mirror TRANSID and a CICS/ESA program name in the following format:
RNAME=AAAA:BBBBBBBB
In this statement, the arguments and options are defined in the following way:
AAAA is a 1-4 character alternate mirror TRANSID.
BBBBBBBB is a 1-8 character CICS/ESA program name.
The colon is required to indicate the TRANSID/program name combination. The TRANSID must be composed of acceptable CICS/ESA characters:
A-Za-z0-9$@#./-_%&Q¢?!|”=,;<>
Refer to “Special Treatment of TRANS ID for DPL” in “Application to Application Programming Considerations.”
g.
Update *DM_REMOTE_SERVICES Section.
The *DM_REMOTE_SERVICES section provides information on services “imported” and available on remote domains. Entries have the general form:
<Remote Service Name> parameters
In this entry, <Remote Service Name> is the name used by the local application for a particular remote service. This name is an ASCII string 1-15 characters in length. The parameters are the keyword/value pairs that make up the definition. Keywords can be in any order. For a full description of parameters, see DMCONFIG in Appendix A, “Administrative Command Reference Pages.”
FUNCTION={APPC | DPL}
The FUNCTION option has been added to allow outbound ATMI service requests to map to APPC transaction programs or CICS/ESA DPL programs. The default value is APPC.
RNAME=<name>
The RNAME option is the name of the host TP_NAME. For non-CICS/ESA systems, this name can be up to 64 characters in length. For CICS/ESA systems, this name is the transaction ID for FUNCTION=APPC and the program name for FUNCTION=DPL requests. CICS/ESA trans-id names cannot exceed four characters and CICS/ESA program names cannot exceed eight characters. The RNAME option must observe these requirements.
When the RNAME specifies an alternate mirror transaction identifier for explicit attachment to outbound DPL requests, it must be a combination of the alternate mirror TRANSID and an advertised remote CICS/ESA program name in the following format:
RNAME=AAAA:BBBBBBBB
In this statement, the arguments and options are defined in the following way:
AAAA is a 1-4 character alternate mirror TRANSID.
BBBBBBBB is a 1-8 character CICS/ESA program name.
The colon is required to indicate the TRANSID/program name combination. The TRANSID must be composed of acceptable CICS/ESA characters:
A-Za-z0-9$@#./-_%&Q¢?!|”=,;<>
Refer to “Special Treatment of TRANS ID for DPL” in the “Application to Application Programming Considerations” section of the Oracle Tuxedo Mainframe Adapter for SNA Reference Guide.
Configurations for Customized Call ID Support
You can retrieve customized call ID from every Oracle Tuxedo Mainframe Adapter incoming call message. Many buffer types support this feature, including CHANNEL/CONTAINER, VIEW, and FML32. Call ID is composed of fields; you can choose to put one or more fields to each call ID in configuration file. Oracle Tuxedo Mainframe Adapter for SNA Gateway loads and parses the configuration file at initialization, and generates a call ID depending on it when decoding an inbound request and sets this call ID to message.
The maximum length of call ID is 64 bytes. Excessive characters will be trimmed. Trailing spaces will be trimmed no matter what the current length is.
You can specify each field's length. The maximum length of field is 64 bytes. Excessive characters will be trimmed. Spaces will be padded if the actual length is shorter than specified.
If the environment variable CALLID_FIELDS_CFG and call ID configuration file are correctly set for Oracle Tuxedo Mainframe Adapter for SNA Gateway, and Oracle Tuxedo System and Applications Monitor Plus (TSAM Plus) call path is enabled on SNA Gateway, the call ID is collected to the ECID field in the TSAM Plus call path. For more information, see "Call Path" in Oracle Tuxedo System and Applications Monitor Plus Console Users Guide.
To utilize this support, do the following steps.
1.
Set Environment Variable CALLID_FIELDS_CFG to enable this support, specifying configuration file location and field names.
2.
For a sample of configurations for customized call ID, see Sample.
Notes:
This feature only support STRING and CARRAY field types in VIEW. If the field type is CARRAY, TMA represents it in hexadecimal characters in upper case and doubles its length (two characters represent one single byte).
Set Environment Variable CALLID_FIELDS_CFG
Set CALLID_FIELDS_CFG to enable this support. If it is not set, this support will not be enabled. It also specifies the configuration file location and field names. Both absolute file path and relative file path are supported.
export CALLID_FIELDS_CFG=/APPDIR/callid.ini
Set Configuration File CALLFLDS
Syntax
[<Service_Name>]
CALLFLDS = <View_Name_1>:<Field_Name_1>:<Offset_begin_1>-<Offset_end_1> [,...,<View_Name_n>:<Field_Name_n>:<Offset_begin_n>-<Offset_end_n>]
Descriptions
 
This name must match the local service name defined in DM_LOCAL_SERVICES section of DMCONFIG. For nested VIEW, this name is the closest VIEW name which includes this field. For channel/container, because container name is mapped to VIEW name, those two names are the same.
It must be the same as the name defined in OUTBUFTYPE of DM_LOCAL_SERVICES section in DMCONFIG; otherwise, though no errors are reported, the configuration is invalid.
Notes:
Every separator is required. If the total number of separator ":" is not equal to 2 in any one of the field definitions, errors are reported.
Sample
In this scenario, Tuxedo local services defined in DMCONFIG are configured as follows. OUTBUFTYPE here defines the message format of the incoming call.
Listing 2‑2 Scenario: Tuxedo Local Services Defined in DMCONFIG
[RECVIEW]
CONV=N
RNAME="RECVIEW"
INBUFTYPE="VIEW32:flat1"
OUTBUFTYPE="VIEW32:nest"
 
And nested VIEW is defined in bufview.v as follows.
Listing 2‑3 Scenario: Nested VIEW Defined in bufview.v
#type cname fbname count flag size null
VIEW ECvw
carray Eca ECA 1 - 20 -
END
 
VIEW EDvw
string EDCstr EDCSTR 1 - - -
END
 
VIEW Evw
string ECstr ECSTR 1 - - -
short EBsh EBSH 1 - - -
struct ECvw ECVW 1 - - -
struct EDvw EDVW 1 - - -
END
 
VIEW nest
char Ach ACH 1 - - -
short Bsh BSH 1 - - -
string Cstr CSTR 1 - 41 -
long Dlo DLO 1 - - -
struct Evw EVW 1 - - -
 
END
 
Then you should set environment variable as follows.
export CALLID_FIELDS_CFG=/APPDIR/callid.ini
And define configuration file as follows.
[RECVIEW]
CALLFLDS= nest: Cstr:0-2, Evw: ECstr :3-7, EDvw: EDCstr:8-15, ECvw: Eca:16-63
Starting the System
To start your Oracle Tuxedo Mainframe Adapter for SNA system, you must first start the CRM and then start the ATMI Servers as described in the following sections.
Step 1: Start the CRM
If the CRM is run in distributed mode or from the command line, it must be started independently of the ATMI processes. Start the CRM in one of the following ways:
For all other distributed configurations, use the CRM command in the following format:
CRM [parameters] <HexSocketAddress> <group name>
Refer to CRM in Appendix A, “Administrative Command Reference Pages” for more information about this command.
Step 2: Start the ATMI Servers
Perform a tmboot as described in the appropriate ATMI platform documentation to start the ATMI servers. If it is already running, perform a tmshutdown and tmboot.
 

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.