This chapter contains the following topics:
Section 7.2, "Maintaining Multiple Instances of JD Edwards EnterpriseOne in a Clustered Environment"
Section 7.5, "Setting Up JD Edwards EnterpriseOne for HACMP"
High availability clusters provide redundancy of software and hardware so that a single point of failure will not interrupt service. If a failure occurs, the clustering software automatically detects the problem and shifts to an alternate machine without ending processes and interrupting the enterprise.
Clustering enables Oracle's JD Edwards EnterpriseOne processes running on a machine that fails to continue running without interruption on a second machine. The second machine has a setup that supports the given processes. Essentially, JD Edwards EnterpriseOne moves to the alternate machine without requiring you to restart a process that was active on the machine that failed.
Note:
Each node in the cluster must have the appropriate software and hardware to ensure that processing moves successfully from server to server.Make sure you understand the clustering software and the tasks necessary to implement the software on a given platform.
Hewlett-Packard provides two mutually exclusive software products to manage high availability clusters:
Hewlett-Packard Multi-Computer/ServiceGuard (MC/ServiceGuard)
Hewlett-Packard Multi-Computer/LockManager (MC/LockManager)
You must use MC/LockManager when you use Oracle Parallel Server (OPS).
You will set up only one of these products for the HP-UX cluster.
JD Edwards EnterpriseOne requires a named IP address for workstations to connect with a server. With the Hewlett-Packard clustering software, you can assign a floating IP address that can move from node to node within the cluster. You should enter this IP address into the WINS or DNS database so that workstations can access the address. If the enterprise servers are not using DNS to resolve host names, you must also add the floating IP address to the /etc/hosts file on each node in the cluster where JD Edwards EnterpriseOne might run.
Note:
If you do not assign a floating IP address, then whenever JD Edwards EnterpriseOne moves to another node in the cluster, the workstations will be unable to connect with the servers.When you run multiple instances of JD Edwards EnterpriseOne in a clustered environment, you must consider several factors. Even though each instance might begin on a separate node, a situation might arise for which multiple instances need to run on the same node. When this happens, communication to each JD Edwards EnterpriseOne instance must occur on a different port number, or service name, and each instance must use a different range of IPC keys. These parameters in the jde.ini file control these settings:
[JDENET] serviceNameListen=Service Name or Port Number serviceNameConnect=Service Name or Port Number [JDEIPC] startIPCKeyValue=Numeric Value
where
Service Name or Port Number is the actual port number or the name of a service that you enter into the /etc/services file.
Numeric Value is the IPC key value of the JD Edwards EnterpriseOne instance.
The IPC key values should differ by at least 1000 between any two JD Edwards EnterpriseOne instances.
This section discusses how to:
Configure Oracle Parallel Server (OPS).
Set up an Oracle package for MC/ServiceGuard.
Set up a JD Edwards EnterpriseOne package.
Oracle Parallel Server (OPS) enables concurrent database access from multiple nodes in a cluster. If you use OPS, you must install MC/LockManager, not MC/ServiceGuard.
This task describes how to set up OPS and MC/LockManager. For more information, refer to the Hewlett Packard documentation on setting up OPS and MC/LockManager.
To set up Oracle Parallel Server and MC/LockManager:
Install Oracle client software on each node in the cluster where it might run. The JD Edwards EnterpriseOne database should be created on shared disks, or on a machine outside the cluster, so that it can be accessed from multiple nodes.
Create a package in MC/ServiceGuard with no services.
This package should be set up with an associated IP address so that it can be reached from any node where it might run. This package should also specify the shared volume group on which the JD Edwards EnterpriseOne database will reside.
Edit the package control script to add the Oracle startup and shutdown commands. This code sample provides an example of the customer_defined_run_cmds function from a package control script:
function customer_defined_run_cmds
{
# ADD customer defined run commands.
export ORACLE_HOME=/u01/app/oracle/product/8.0.5
export ORACLE_SID=jde1
export ORAENV_ASK=NO
. $ORACLE_HOME/bin/oraenv
su oracle -c '$ORACLE_HOME/bin/lsnrctl start'
su oracle -c '$ORACLE_HOME/bin/svrmgrl' <<EOF1
connect internal
startup
exit
EOF1
test_return 52 }
You can use these same steps to enter the Oracle shutdown commands into the customer_defined_halt_commands section of the package control script.
If you use MC/ServiceGuard, you should set up a package for Oracle. An Oracle package enables the Oracle processes to move from one node to another when a node fails or during scheduled maintenance.
You do not need to perform this step if you use MC/LockManager.
To set up an Oracle package for MC/ServiceGuard:
Install Oracle on each node in the cluster.
Create the JD Edwards EnterpriseOne database on shareable disks so that multiple nodes can access the database.
Create a package in MC/ServiceGuard with no services.
You should set up this package with an IP address so that any node on the cluster can access and run the package. This package should also specify the shared volume group where the database will reside.
Edit the package control script to add the Oracle startup and shutdown commands.
This code sample provides an example of the customer_defined_run_cmds function from a package control script:
Function customer_defined_run_cmds
{
# ADD cusomter defined run commands.
Export ORRACLE_HOME=/u01/app/oracle/product/8.0.5
Export ORACLE_SID=jde1
Export ORAENV_ASK=NO
.$ORACLE_HOME/bin/oraenv
su oracle '$ORACLE_HOME/bin/svrmgr1'<<EOF1
connect internal
startup
exit
EAOF1
Test return 52
}
You can use the same steps to enter the Oracle shutdown commands into the customer_defined_halt_commands section of the package control script.
The standard JD Edwards EnterpriseOne enterprise server software requires minimal modifications to function in a cluster. These modifications include these items:
Enterprise server jde.ini
owenv script file in the $SYSTEM/bin32 directory
Package control script
To set up a JD Edwards EnterpriseOne package for a cluster:
In the server jde.ini file, locate the [CLUSTER] section, then change these setting:
[CLUSTER]
PrimaryNode=Package IP name
where Package IP name represents name given to the IP address that is associated with the JD Edwards EnterpriseOne package that you are creating.
Change the owenv script file in the $SYSTEM/bin32 directory. The owenv script file contains the settings for various UNIX environment variables required by JD Edwards EnterpriseOne.
Create a package using SAM.
Note:
You can also use the command line to create a package. See HP documentation for details.For JD Edwards EnterpriseOne, set up a package with an associated floating IP address, but with no services. This setup is necessary because the cluster manager needs to start services without environment variables under the root user. The software will not run properly unless you set environment variables. This setup also enables you to utilize the installation defaults and the start and end scripts provided by the JD Edwards company.
Depending on the needs of the enterprise, you might want to install JD Edwards EnterpriseOne on a shared volume group. This setup enables multiple nodes in a cluster to access a single version of JD Edwards EnterpriseOne, but only one node at a time. This setup also enables you to easily update JD Edwards EnterpriseOne through server package installations.
Using SAM, modify the package control script on each node to start and stop JD Edwards EnterpriseOne.
Note:
You might need to vary the control scripts for different nodes in the cluster to configure different volume group names or path names. In this case, you must edit the scripts on each node individually instead of using SAM.This code sample provides an example of the customer_defined_run_cmds function from a package control script:
function customer_defined_run_cmds
{
# ADD customer defined run commands
# wait 60 seconds for Oracle to come up
sleep 60. /home/jde/owenvsu jde
<< EOF1mv $OWHOME/log/jde*.log
$OWHOME/log/oldlogscd
$SYSTEM/bin32RunOneWorld.sh
EOF1
test_return 51
}
This code sample provides an example of the customer_defined_halt_cmds function from a package control script:
function customer_defined_halt_cmds
{
# ADD customer defined halt commands
.. /home/jde/owenv
su jde << EOF2
cd $SYSTEM/bin32
EndOneWorld.sh
sleep 15
rmics.sh
EOF2
test_return 52
}
The following list provides explanations for these functions:
sleep 60
The "run" function first waits 60 seconds for Oracle processes to start. HP states that you should set the PKG_SWITCHING_ENABLED parameter to NO for applications that access OPS. This setting prevents these applications from starting before OPS is active. If you use the sleep command in the script, you do not need to modify this setting. You can remove the sleep command from the script when you use the control script for a backup node with OPS running.
. /home/jde/owenv
This line runs the owenv script to set up UNIX environment variables. The owenv script resides in the $SYSTEM/bin32 directory. You must edit this script to ensure that the correct setup exists for all necessary environment variables for JD Edwards EnterpriseOne and Oracle. In these examples, the script has been moved to the home directory of the jde user. The script might need to move to the home directory if you use a different SID to access Oracle from different nodes.
su jde
This line switches to the user ID that owns the JD Edwards EnterpriseOne processes. If you omit this line, the root user owns the JD Edwards EnterpriseOne processes.
mv $OWHOME/log/jde*.log $OWHOME/log/oldlogs
This line moves any logs in the log directory to a backup log directory, which you create. This command is particularly important if the JD Edwards EnterpriseOne instance resides on a shared disk where a "failed over" instance of JD Edwards EnterpriseOne will use the same physical disk space as the failed instance. You might consider adding the command rm $OWHOME/log/oldlogs/* before this line to clean out any older versions of logs.
RunOneWorld.sh; EndOneWorld.sh
These are the standard start and stop scripts that we provide for the UNIX enterprise server.
The directory that contains the package control script also contains the control.sh.log file, which contains the results of starting and stopping a package. This file is the first place to check if problems arise when you start or stop a package. In particular, it will contain any output or error messages from the customer-defined commands you might enter.
This section provides an overview of HACMP for AIX clustering and discusses how to create group and user accounts.
If a failure occurs, HACMP provides a transparent recovery for critical applications. You can configure a cluster using any RS/6000 processor and a variety of network adapters and disk subsystems to satisfy the LAN, disk capacity, and performance requirements.
Be careful when you delete or write to shared files. You might want to move old log files rather than delete them. If you move a package running on a shared file system from one node to another, the new instance of JD Edwards EnterpriseOne references the logs and files from the old instance.
HACMP for AIX (Version 4.2) enables customers to automatically detect system failures and recover users, applications, and data on backup systems, minimizing downtime to minutes or seconds. In addition, using HACMP for AIX virtually eliminates planned outages, since users, applications and data can be moved to backup systems during scheduled system maintenance. HACMP Version 4.2 adds new features such as the Cluster Single Point of Control (CSPOC) and Dynamic Reconfig, which enable the system administrator to add users, files, and security functions without stopping mission-critical jobs.
HACMP provides several configuration options, including these:
Idle standby for up to seven processors being backed up by a single processor.
Rotating standby for up to seven processors backed up by a standby processor in a predefined or contention takeover sequence.
Mutual takeover for up to eight processors backing each other up by sharing the application workloads.
Concurrent access for up to eight processors working on the same jobs and sharing the same data.
The configuration flexibility of HACMP enables customers to select the cluster topology and database manager that best suits the requirements of their computing environment. IBM states that HACMP can support both concurrent and parallel data access within a common cluster. HACMP also operates with the new Parallel Database Products, such as IBM DB2 for IBM i Parallel Edition and Oracle 8 Parallel Server.
Several components make up the HACMP environment, including these:
Nodes
Nodes are the core of an HACMP cluster. A node is a processor that runs the AIX operating system, HACMP, and the mission-critical software. Software execution can be spread over several nodes for system load balancing. In the event of a failover, HACMP executes customer-defined scripts that will establish environments and start specific software packages on a standby node.
Shared external disk
Shared external disks are disks that are physically connected to multiple nodes. The shared disks store mission-critical data, which is shared among processes running on separate nodes.
Networks
Networks are the independent components of HACMP. TCP/IP is the protocol with which HACMP was designed to function. It has been tested with ethernet, token ring, and Fiber Distributed Data Interface (FDDI) topology.
Network adapters
Clients
Installing the HACMP cluster requires that you create logon accounts and use the Oracle Standard Enterprise Database Management System (DBMS).
A major consideration when setting up HACMP and JD Edwards EnterpriseOne is user accounts. When these accounts are created, they are given unique user IDs and unique role IDs. When a node fails over to another node, these unique IDs are matched to names in the /etc/passwd and /etc/role files. If no matches occur, the unique user and role values are then used as IDs, which can create problems with access and security.
To avoid a problem, before starting the JD Edwards EnterpriseOne installation or configuration, create all user accounts and roles on all nodes that will be used in the cluster environment. Use the same unique number for all users and the same unique number for all roles. The easiest way to do this is to use the add user/role function found in the HACMP extension of SMIT.
If JD Edwards EnterpriseOne is already installed, use the existing user and role ID numbers to create accounts on the nodes that are defined in the resource group.
Oracle Standard Enterprise DBMS is used in the HACMP configuration explained in this chapter. The resource control scripts are coded to start and stop the database using standard Oracle program calls. These scripts can be easily modified to allow for changes in database start and stop procedures as well as the introduction of commands for Oracle Parallel Server. To minimize installation and configuration problems, have the database administrator review the commands in the control scripts to ensure that they are correct for the installation.
By performing this operation using the add group/user option in the HACMP component of SMIT, all user accounts and group assignments are synchronized across all nodes. This ensures that when the resource disk volume groups remount on the failover system, the user and group IDs match.
To create group and user accounts:
Verify that HACMP is running on all nodes within the resource group.
Select a unique ID number that can be assigned to the new group and user that you want to create.
Verify the selection by searching all password and group files on the node where the new user and group will be created.
Enter this command on the command line:
# smit hacmp
From the menu, select Cluster System Management, then Cluster Users & Groups, then Groups, and then Add a Group to the Cluster.
Select the resource group to which you want to add the new group. The resource group identifies the nodes that will need to be updated. Next, add a group called JD Edwards EnterpriseOne and assign it the unique ID number that you chose.
Press Enter.
From the Cluster Users & Groups panel, select Users and then Add a User to the Cluster.
Select the same resource group that you chose for adding a group.
Add a user psft, assign it the pre-selected unique ID number, and select the JD Edwards EnterpriseOne group.
Repeat these steps for the Oracle sign on, creating the group dba.
The standard JD Edwards EnterpriseOne enterprise server software requires minimal modifications to function in a cluster, including editing the enterprise server jde.ini file, the owenv script, the start resource control script, and the stop resource control script.
This section discusses how to:
Edit the owenv script.
Edit the Start Resource Control script.
Edit the Stop Resource Control script.
To edit the owenv script:
In Windows Explorer, go to the /$SYSTEM/bin32 directory and open the owenv file.
Edit the emphasized lines:
#! /bin/ksh ## set OWHOME to point to the base install path for JD Edwards EnterpriseOne export OWHOME=/ow2/JDEdwards/E900 ## set ENVIRON to the path code from which you want to run business functions export ENVIRON=MSTR ## set up the path to your JD Edwards EnterpriseOne system and path code export SYSTEM=$OWHOME/system export APPDEV=$OWHOME/$ENVIRON ## set JDE_BASE to the location of your JDE.INI file export JDE_BASE=$SYSTEM/ini/aix ## set up the Oracle environment export ORACLE_HOME=/u01/app/oracle/product/8.0.5 export ORACLELIB=$ORACLE_HOME/lib ## the remaining variables point to libraries and executables export SHLIB_PATH=$SYSTEM/lib:$APPDEV/bin32:$ORACLELIB:$SYSTEM/libv32 export LD_LIBRARY_PATH=$SHLIB_PATHexport PATH=$PATH:$SYSTEM/bin32
Save and close the file.
To edit the start resource control script:
In Windows Explorer, go to the /$SYSTEM/bin32 directory and open the StartResource.sh file.
Edit the emphasized lines:
#____________________ #Global Variables #____________________ # #export PATH=$PATH #Set environment variables # ./usr/sbin/cluster/scripts/owenv # loop=0 StartUpError=false ORACLEPROCESS=oracle OWStartupDir=$SYSTEM/bin32 StartUpLog=$OWStartupDir/OWStartup.log ORACLE_UID=oracle APP_UID=psft LOGFILES=$OWStartupDir/jde*.log
The first emphasized line executes the script that sets various required JD Edwards EnterpriseOne environment variables.
Note:
This script, as well as others, will be relocated into the scripts directory as described in the Control Scripts section under Creating an Application Server in the JD Edwards EnterpriseOne Tools 8.94 Implementation Guide: Server and Workstation Administration.ORACLE_UID and APP_UID are the login ID names for Oracle and JD Edwards EnterpriseOne. These are used in the script so that the respective applications are started with the proper application ownership.
Note:
This script is delivered with these IDs undefined. If the script is executed, an error message will be generated.Save and close the file.
To edit the stop resource control script:
In Windows Explorer, go to the /$SYSTEM/bin32 directory and open the StartResource.sh file.
Edit the bold lines:
#____________________ #Global Variables #____________________ export PATH=$PATH:. # # Set environment variables # ./usr/sbin/cluster/scripts/owenv LogicalVolumn=/ow2 ShutdownDir=$SYSTEM"/bin32" StartUpLog=$OWStartupDir"/OWStartup.log" APP_UID=psft
Similar to the script modification described in the previous procedure, the APP_ID needs to have the login ID of the application owner. In this example, psft owns the application.
Save and close the file.
The application server is a method that invokes predetermined actions of applications. The server is called in the cluster startup or shutdown sequence and executes predefined scripts depending on what activity is occurring. As part of the cluster installation and configuration process, an application server must be created and the access path to the control scripts defined.
This section discusses how to:
Move the control scripts.
Define an application server.
Define cluster resources.
The control scripts that are included with JD Edwards EnterpriseOne are located in the /$SYSTEM/bin32 directory. These scripts are generic and can be modified as needed to meet the requirements. Before you can create an application server, you must move the scripts to a non-shared disk directory.
To move the control scripts:
Log in as root and enter these commands:
#export SYSTEM=< JD Edwards EnterpriseOne system directory path>
Where JD Edwards EnterpriseOne system directory path is the path to the system directory. An example of the path is /ow2/JDEdwards/900/system.
# cd /usr/sbin/cluster
# mkdir scripts
# cd scripts
Be sure to include the periods, preceded by a single space, in these commands:
# cp $SYSTEM/bin32/StartResource.sh .
# cp $SYSTEM/bin32/owenv .
# chmod 755 *
Repeat this step on all failover nodes and FTP over the modified script files.
To define an application server:
From the command line, enter this command:
# smit hacmp
From the menu, select Cluster Configuration, then Cluster Resources, then Define Application Servers, and then Add an Application Server.
In the Server Name field, enter OneWorldSrv. This adds a label to the resource server that controls the starting and stopping of JD Edwards EnterpriseOne.
In the Start Script field, enter the path of the StartResource.sh script - for example, /usr/sbin/cluster/scripts/StartResource.sh.
In the Stop Script field, enter the path of the StopResource.sh script - for example, /usr/sbin/cluster/scripts/StopResource.sh.
Press Enter.
This procedure explains how to let HACMP know that you have defined an application server. This is so that HACMP will know to use the server during a cluster-related event. Within the cluster parameters display is a field in which this resource is defined.
From the command line, enter this command:
# smit hacmp
From the menu, select Cluster Configuration, Cluster Resources, Change/Show Resource for a Resource Group.
Select the resource group - for example, JD Edwards EnterpriseOne.
On Configure Resources for a Resource Group, in the Application Server field, enter the name of the application server that you defined in the previous procedure.
This section provides an overview of Sun Solaris clustering and discusses how to:
Modify the SunStartResource.sh script.
Modify the SunStopResource.sh script.
Modify the owenv script.
Modify the SunOracleMgr.sh script.
Register JD Edwards EnterpriseOne with SUNClustering.
This software provides higher availability for the applications because it enables you to recover almost instantaneously from a power failure or hardware problem. It also enables applications to be available during scheduled downtime.
This documentation assumes that you have successfully installed Oracle and the SUNClustering software. If you are having trouble with either of these products, you should contact Oracle or Sun as needed.
You must have a disk that is accessible to all machines in the cluster, and this disk must be large enough to accommodate the JD Edwards EnterpriseOne installation. If you wish to place the database on the same cluster as well, the database file must also be placed on a shared disk accessible to all machines in the cluster (although not necessarily on the same shared disk as the one that the JD Edwards EnterpriseOne server is on).
The SUNClustering 2.2 or greater API is recommended.
Four cluster-specific scripts are delivered with JD Edwards EnterpriseOne:
SunStartResource.sh
SunStopResource.sh
owenv
SunOracleMgr.sh
These scripts can be found in the system/bin32 directory under the base JD Edwards EnterpriseOne installation directory.
The SunStartResource.sh script runs whenever a node in the cluster starts the JD Edwards EnterpriseOne service. It must be registered with the SUNClustering software and should handle everything that needs to happen when the JD Edwards EnterpriseOne service starts or is switched from one node to another.
The SunStopResource.sh script runs whenever a node in the cluster stops the JD Edwards EnterpriseOne service. It is registered with the SUNClustering software, and handles shutting down various processes and any cleanup that needs to happen when the JD Edwards EnterpriseOne service is stopped.
The owenv script sets various UNIX environment variables that are needed by JD Edwards EnterpriseOne. The script is called from within the SunStartResource.sh and SunStopResource.sh scripts.
The SunOracleMgr.sh script is necessary if you are running the database on the same cluster as the JD Edwards EnterpriseOne server. If you are not running the database on the same cluster, you can ignore this section.
To modify the SunStartResource.sh script:
Under Global Variables, there is a call to /suncldata/JDEdwards/E900_sp1/system/bin32/owenv. Change /suncldata/JDEdwards/E900_sp1/ to the same path that OWHOME was set to in the owenv script.
Set the APP_UID to the user name that JD Edwards EnterpriseOne is to be run under.
Set ORACLE_UID to the user that is to run Oracle if the database is on the same cluster as JD Edwards EnterpriseOne.
If you are using Oracle, uncomment the section under Check for ORACLE running and Check to see if ORACLE started/running.
To modify the SunStopResource.sh script:
Under Global Variables, change the call to /suncldata/JDEdwards/E900_sp1/system/bin32/owenv to the same thing that is in the SunStartResource.sh script.
Set APP_UID and ORACLE_UID to the users running JD Edwards EnterpriseOne and Oracle, respectively. These values will be the same as in SunStartResource.sh.
Under the Shutdown JD Edwards EnterpriseOne section, set LOGDIR to be the location where all the log files are located.
To modify the owenv script:
Set OWHOME to be the base directory of JD Edwards EnterpriseOne, for example, /suncldata/JDEdwards/E900_sp1/.
Set ENVIRON to the pathcode that you are using, for example, PROD or CRP.
Once OWHOME and ENVIRON are set, SYSTEM, APPDEV, AND JDE_BASE should be correct.
Set ORACLE_HOME to be the location of the ORACLE installation on the machine, for example, /suncldata/app/oracle/product/8.0.5.
Set ORACLE_SID as needed.
To modify the SunOracleMgr.sh script:
In the Setup Global Variables section of the script, set ORACLE_UID to the user ID that is used to start Oracle.
Set ORACLE_HOME to the appropriate value for the Oracle installation.
You must register JD Edwards EnterpriseOne with the SUNClustering software.
To register JD Edwards EnterpriseOne with SUNClustering:
To register JD Edwards EnterpriseOne with SUNClustering, log in as the root user and enter this command:
/opt/SUNWcluster/bin/hareg -r[service name] -m start_net=[absolute path of SunStartResource.sh] -mstop_net=[absolute path of SunStopResource.sh]
Where service name can be anything you want, but you may want to make it something easy to remember like JD Edwards since you will need to use that name when modifying JD Edwards EnterpriseOne registry with SUNClustering.
Enter this command with no options:
/opt/SUNWcluster/bin/hareg
If the line containing the service name you assigned to JD Edwards EnterpriseOne contains off, then enter this command:
/opt/SUNWcluster/bin/hareg -y [service name]
This sets the data service to "on," which enables the data service to switch physical hosts when appropriate.
To test whether the cfluster switches, enter this command:
/opt/SUNWcluster/bin/haswitch
Also, try pulling the plug on the current active host.
Note:
You should not use reboot or shutdown on the primary node as a test as doing so will result in an error and not in a switchover.These sections address specific problems with HP-UX clustering.
Complete these steps if you experience problems with OPS:
Verify that the cluster software is operational. OPS requires the cluster software to start before OPS can start.
Verify that DLM is enabled in the DLM configuration. Oracle Group Management Services (OGMS) will not start if DLM is disabled.
Complete these steps if JD Edwards EnterpriseOne fails to start:
When you start JD Edwards EnterpriseOne using the package control script, first check the control script log for errors. Look for errors in the script that occur before the RunOneWorld.sh command.
Check the log directory for log files. If none reside, verify that the JD Edwards EnterpriseOne processes exist in the proper directory and that you correctly set the $SYSTEM environment variable.
If the log file names are in all capital letters, the $JDE_BASE environment variable might be set incorrectly. If you incorrectly set this environment variable, the process will be unable to locate the jde.ini file.
Verify whether an entry exists in the /etc/hosts table for the floating IP address. If no entry exists, jdenet_n will start, but all other processes will return this message in the log: 239-gethostbyname returned Connection refused.
If no entry for the floating IP address exists that the workstation can reference, it will fail to connect and return this message in the log: 11001-gethostbyname returned 11001 (WSAHOST_NOT_FOUND): The host was not found.
You must associate an IP address with the JD Edwards EnterpriseOne package. The package must be operational for the IP address to be active. Otherwise, workstations will not connect to the server and endnet will not work properly on the server.
Oracle must be operational and the owenv must reference the proper SID for JD Edwards EnterpriseOne to work from within the package control script.
You must enable automatic switching in the package failover options. If you do not enable this setting, the package will not switch to the backup node when the node fails or you remove the node from the cluster. If you do not want the package to switch, for example, you might want to stop JD Edwards EnterpriseOne, you can disable this flag and then halt the package.
If JD Edwards EnterpriseOne does not end cleanly during a package halt, the package halt might fail. This could occur if Oracle is not operational or if JD Edwards EnterpriseOne cannot access the database. You might need to change the test condition in the package control script, or add commands to search for remaining JD Edwards processes and end them.
Generally, the owenv file should not reside on the shared disk. Different environment settings, particularly ORACLE settings, might exist depending on which node you run a package. If you placed the JD Edwards EnterpriseOne bin32 directory on a shared disk, move the owenv file to another directory.