Skip Headers
JD Edwards EnterpriseOne Tools Server and Workstation Administration Guide
Release 8.98 Update 4

Part Number E14718-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Administering the UNIX and Linux Servers

This chapter contains the following topics:

3.1 Understanding Server Administration for UNIX and Linux

The JD Edwards company supports Oracle's JD Edwards EnterpriseOne enterprise servers for UNIX operating systems on the Hewlett-Packard HP 9000 (HP-UX), the IBM RS/6000 (AIX), and the Sun Microsystems SPARC (Solaris) platforms. In addition, beginning with JD Edwards EnterpriseOne 8.93, RedHat Enterprise Linux AS on the Intel Architecture is also supported. To operate the UNIX or Linux enterprise server, you need to perform administrative procedures on the server to ensure that JD Edwards EnterpriseOne will run properly.

Note:

Some information in this and other guides refers to UNIX generically and includes the supported Linux platforms unless otherwise noted.

This section discusses:

3.1.1 JD Edwards EnterpriseOne Directory Structure for UNIX and Linux

This is a list of directories that are shipped on the UNIX and Linux JD Edwards EnterpriseOne Server Installation CD. They should be installed under the JD Edwards EnterpriseOne base directory; for example, install them in /u01/JDEdwards/E900. Indented names indicate subdirectories of the directories, which are not indented.

Directory Description
pathcode The main directory for the business function shared libraries, C header files, object files, source files, and specification (spec or TAM) files. Upon installation, this directory is copied to the correct path codes, such as PD900 and DV900. These subdirectories are included:
  • bin32 - Business function shared libraries.

  • Spec files - Binary data files in a JD Edwards proprietary format.

system The main directory for the system-level executables, shared libraries, C header files, libraries, and localization files. These subdirectories are included:
  • bin32 - System-level executables and scripts.

  • include - System-level C header files.

  • includev - System-level C header files provided by third-party vendors, such as Vertex.

  • lib - System-level shared libraries and export files.

  • libv32 - System-level shared libraries provided by third-party vendors.

ini The location of the JDE.INI file.
PrintQueue The location to which all .PDF file outputs for reports are written.
log The location to which the jde_xxx.log and jdedbug_xxx.log files are written.
packages The server package installation base directory. Directories exist here only when a package has been installed. Under the package directory are subdirectories named for each package that has been installed. Located under each package are these directories:
  • bin32 - Business function shared libraries.

  • include - Business function header files.

  • obj - Business function object files. (These are divided among lower-level subdirectories that correspond to each shared library in the bin32 directory.)

  • source - Business function source files. (These are divided among lower-level subdirectories that correspond to each shared library in the bin32 directory.)

  • spec - Specification files. (These binary data files are in a JD Edwards proprietary format.)


3.1.2 JD Edwards EnterpriseOne Architecture and Process Flow for UNIX and Linux

The host server processes in this flowchart perform the indicated actions.

Figure 3-1 UNIX host server process

Description of Figure 3-1 follows
Description of "Figure 3-1 UNIX host server process"

This information explains the process flow:

  1. The jdenet_n Master process spawns jdenet_n Slave and jdenet_k processes (also called kernels) at startup or as they are needed. JD Edwards EnterpriseOne uses a number of different types of kernels to handle different types of processing, even though all of these have the same process name in the operating system (jdenet_k). The definitions for the number of processes to start and what types to start are stored in the JDE.INI file.

  2. The queue kernel process spawns the runbatch process whenever a relevant batch process request is placed in the Job Control Status Master table (F986110). The runbatch process completes the job, updates the F986110 table, and then quits. In JD Edwards EnterpriseOne, you use the Job Queue Maintenance program (P986130) to set up and manage the job queues.

    Nearly all jdenet_k processes access various other database tables as needed. The runbatch process, for instance, accesses and modifies any database table that is relevant to the particular business logic it is running.

  3. Message queues are a type of interprocess communication (IPC) resource. They are allocated by the jdenet_n processes by calls to the operating system. While the software is running, operating system information about the message queues can be obtained by using the command ipcs.

    When message packets are routed to the jdenet_n process from a client or another server, the jdenet_n process places them in the appropriate message queue according to the type of message. For example, when a client submits a batch process, a message is routed to the batch process kernel; when business logic needs to be run on the server, a request is routed to the CallObject kernel; when a user signs on to the system, a request is routed to the security kernel, and so on.

    Each message queue has an identifier (IPC key) so that multiple processes can access them. JD Edwards EnterpriseOne uses a configurable IPC key range, which is controlled by the startIPCKeyValue in the JDE.INI file, in case a conflict occurs with other software that is using IPC resources.

3.1.2.1 jdenet_n Operation

The jdenet_n process usually starts when you run the supplied JD Edwards EnterpriseOne startup script: RunOneWorld.sh, which then starts all other processes as needed.

The jdenet_n process listens to the socket (port) as specified in the JDE.INI file by the keywords ServiceNameListen and ServiceNameConnect. These two keywords should be set to the same number; this number must be the same for every client who wishes to connect to the JD Edwards EnterpriseOne server.

The definitions for the particular jdenet_k processes to start are also given in the JDE.INI file. They are listed in the sections headed by [JDENET_KERNEL_DEFx]. Each of these entries lists the type of jdenet_k processes to start and the maximum number of jdenet_k processes of this type to start.

The number of jdenet_n slave processes to start is listed in the JDE.INI file under the keyword maxNetProcesses. The purposes of these slave processes are to provide parallel processing for the job of listening to the socket and to put the associated messages on the message queues for the jdenet_k processes to finish.

3.1.2.2 jdenet_k Operation

jdenet_k processes are referred to as kernel processes. They do the actual work on the enterprise server. When a jdenet_k process starts, it can be any type of kernel process. The jdenet_n process instructs each kernel process to be of a certain type.

The jdenet_k process that becomes a CallObject kernel has the job of calling business function logic on the server. Business function logic is written in C code and compiled into UNIX-shared libraries. The shared libraries are loaded onto the jdenet_k processes and then called directly through a C function call.

The jdenet_k process that becomes a batch process kernel waits for requests to run batch processes from the client. These batch processes are then placed in the Job Control Status Master table (F986110). The processes are then picked up by the queue kernel processes that launch runbatch processes, as required.

Many other types of jdenet_k processes exist. Review the JDE.INI file for a complete list.

3.1.3 JD Edwards EnterpriseOne Initialization for UNIX and Linux

This initialization occurs when you start JD Edwards EnterpriseOne programs, such as the queue kernel, runbatch, and so on:

  • The environment name is passed as a command line argument to the program (such as porttest, runbatch, and so on).

  • This environment can be translated to a different environment, based on the settings in the [SERVER ENVIRONMENT MAP] section of the JDE.INI file.

  • The environment that is used must be a valid entry in the Library List Master File table (F0094). Likewise, it must have a valid corresponding path code in the Environment Detail table (F00941).

  • These JDE.INI settings in the [DB SYSTEM SETTINGS] section are used to determine where the JD Edwards EnterpriseOne server startup tables, such as the Data Source Master (F98611) and the Object Configuration Master (F986101), are located:

    • Base Datasource

    • Object Owner

    • Server

    • Database

    • Load Library

    • Type

  • Using this information, the F986101 table in the specified database on the server is opened.

  • When an override for a given table or the current user exists, that data source (the OMDATP field in the F986101 table) is used for the given object or user and environment. Otherwise, the data source in which OMOBNM=DEFAULT for the given environment is used. Ignore any inactive records (that is, OMSTSO=NA).

    We strongly recommend that you do not have any default records for reports (OMOBNM=DEFAULT and OMFUNO=UBE) on the server. These records might prevent report interconnections (that is, one report calling another report) from starting correctly.

  • Each unique data source in the F986101 table should correspond to one entry in the F98611 table.

  • The corresponding information in the F98611 table must be correct. In particular, the OMDLLNAME field must display the correct library for the database to which the data source points.

  • For an Oracle database, the OMDATB field from the F98611 table maps to an entry in the tnsnames.ora file. This tnsnames.ora file must be set up correctly. (Ask an Oracle database administrator to verify the setup).

3.2 Starting the Enterprise Server for UNIX or Linux

This section provides an overview of the enterprise server startup for UNIX or Linux and discusses how to:

3.2.1 Understanding Enterprise Server Startup for UNIX or Linux

You can start the enterprise servers either manually at the command line or automatically when the server boots. The manual process is the same for all supported platforms, but the automatic process varies slightly by platform.

Note:

If you are running JD Edwards EnterpriseOne on the same server as the Oracle database, you must make sure that Oracle is running before you start JD Edwards EnterpriseOne. In particular, if you are starting JD Edwards EnterpriseOne at system boot time, you must make sure the Oracle startup processes are completed first.

RunOneWorld.sh is the script that starts the JD Edwards EnterpriseOne system on the enterprise server. This script:

  • Checks for existing JD Edwards EnterpriseOne processes.

    The script returns an error if it detects that JD Edwards EnterpriseOne is already running.

  • Runs the rmics.sh script to clear IPC resources.

    This script ensures no IPC resources conflict with other software.

  • Starts jdenet_n, which is the JD Edwards EnterpriseOne network listener that receives requests from JD Edwards EnterpriseOne workstations.

  • Runs a program called cleanup that checks for unfinished batch processes from a previous shutdown.

The default database parameters for UNIX might not fully support multiple users. You might reach the maxprocess limit for the database. The initial settings are for a small database, so you should change these parameters to a medium setting to avoid database problems. These settings reside in the init.ora file. These path is an example of where you might typically find this file:

/u01/app/oracle/product/8.0.5/dbs/init.ora

3.2.2 Starting the Enterprise Server for UNIX or Linux Manually

To start the enterprise server for UNIX or Linux manually:

Note:

This procedure is the same for all supported UNIX or Linux operating systems.
  1. Sign on to the machine using the appropriate user ID, as set up during the installation process.

    If you used the JD Edwards-recommended user ID, the user ID is jde.

  2. Enter these commands:

    • cd log_directory

      This command moves the user's current directory to the log directory. The administrator determines the name of this directory.

    • rm -f jde*log*

      This command deletes the log files in the directory.

      Note:

      Use extreme care when you enter this command. A syntax error in this command can cause severe problems on the system.
    • RunOneWorld.sh

      This script starts the JD Edwards EnterpriseOne system.

  3. Sign off the system.

3.2.3 Starting the Enterprise Server for HP-UX Automatically

To start the enterprise server for HP-UX automatically:

  1. Create a script named psft in /sbin/init.d with all necessary permissions for execution.

    The script should contain only these:

    #! /sbin/sh
    
    /bi n/su - psft_user -c `$SYSTEM/bin32/RunOneWorld.sh'
    

    The value psft_user is the name of the user who owns the shell script $SYSTEM/bin32/RunOneWorld.sh. Make sure that no interactive commands appear in the psft_user profile, and that RunOneWorld.sh has all necessary permissions for execution.

  2. Using this command, create a soft link named S995psft to the psft script in the directory named /sbin/rc2.d.

    ln -s /sbin/init.d/psft /sbin/rc2.d/S995psft
    
  3. Verify that these line is present in the profile of the user who owns RunOneWorld.sh:

    /usr/local/bin/oraenv
    

    Before you execute oraenv, ensure that the Oracle environment variables of ORACLE_BASE, ORACLE_HOME, ORACLE_SID, ORACLE_TERM, and ORAENV_ASK are properly assigned and exported. Also, you must add $ORACLE_HOME/bin to the PATH environment variable.

  4. Set ORACLE_TERM to hp.

  5. Set ORAENV_ASK to NO.

  6. If this command is in the profile, delete it:

    unset ORAENV_ASK
    

3.2.4 Starting the Enterprise Server for AIX and Solaris Automatically

To start the enterprise server for AIX and Solaris automatically:

  1. Create a script named rc.psft in /etc with all necessary permissions for execution.

    The script should contain only these:

    #! /bin/sh
    
    /bin/su - psft_user -c `$SYSTEM/bin32/RunOneWorld.sh'
    

    The value psft_user is the name of the user who owns the shell script $SYSTEM/bin32/RunOneWorld.sh. Make sure there are no interactive commands in the psft_user .profile, and that RunOneWorld.sh has all the necessary permissions for execution.

  2. Add this line at the end of the text file named inittab in /etc:

    psft:2:wait:/etc/rc.psft
    
  3. Verify that this line is present in the .profile of the user who owns RunOneWorld.sh.

    . /usr/bin/oraenv
    

    Before you execute oraenv, ensure that the Oracle environment variables of ORACLE_BASE, ORACLE_HOME, ORACLE_SID, ORACLE_TERM, and ORAENV_ASK are properly assigned and exported. Also, you must add $ORACLE_HOME/bin to the PATH environment variable.

  4. Set ORACLE_TERM to hp.

  5. Set ORAENV_ASK to NO.

    To see a list of values for ORACLE_SID, look at the oratab text file in /etc.

  6. If this command is in the .profile, you must delete it:

    unset ORAENV_ASK
    

3.2.5 Starting the Enterprise Server for Linux Automatically

To start the enterprise server for Linux automatically:

Add this line to the rc.local file in the /etc directory:

/bin/su - psft_user -c `$SYSTEM/bin32/RunOneWorld.sh'

The value psft_user is the name of the user who owns the shell script $SYSTEM/bin32/RunOneWorld.sh. Make sure there are no interactive commands in the psft_user .profile (or .bash_profile), and that RunOneWorld.sh has all the necessary permissions for execution.

3.2.6 Verifying the JD Edwards EnterpriseOne Installation

To verify the JD Edwards EnterpriseOne installation:

After you start JD Edwards EnterpriseOne, execute these commands:

cd $SYSTEM/bin32
porttest userID password environment

The porttest program initializes an environment, initializes a user, opens the Account Balances table (F0902), and displays up to 99 rows of data.

Note:

The parameters for userID, password, and environment should be any valid JD Edwards EnterpriseOne user ID, password, or environment.

3.2.6.1 Understanding Java Runtime Engine Installation Issue on Unix

With tools release 8.98 the Java Runtime Engine is bundled into the tools code. It will be in the directory .../system/jre. However, the problem is that prior to Apps Release 8.12 the installer will not set all the correct paths for this. So if a customer is using 9.0 with tools 8.98 they will most likely get an error like this from the JDE log:

12320/1 MAIN_THREAD                             Tue Nov  8 17:35:05.884717     
ipcmisc.c299
        process 12320 </u04/oneworld/e1t_owa_stageing_development/system/bin32
/jdenet_n> registered
in entry 0

12320/1 MAIN_THREAD                             Tue Nov  8 17:35:37.374029     
 netstart.c247
        Failed to autostart kernel in range 29


and get a core file when the jdenet_k #29 tries to start.  To fix this they will
 need to add the path .../system/jre/1.4 to the LD_LIBRARY_PATH, LIBPATH, SHLIB_
PATH. 

3.3 Shutting Down the Enterprise Server for UNIX or Linux

The shutdown process is identical for all supported UNIX or Linux operating systems.

EndOneWorld.sh is the script that stops the JD Edwards EnterpriseOne system on the enterprise server. This script completes these functions:

3.3.1 Shutting Down the Enterprise Server for UNIX or Linux

To shut down the enterprise server for UNIX or Linux:

  1. Sign on using the appropriate user ID that you set up during the installation process.

  2. Execute these commands:

    cd $SYSTEM/bin32
    
    EndOneWorld.sh
    

3.4 Setting Up a Printer for UNIX or Linux

Each supported UNIX system use different processes for setting up printers. HP-UX uses a tool called SAM to help in setting up a printer; AIX uses a tool called SMIT; Solaris uses a tool called Admintool; and RedHat Enterprise Linux AS uses a tool called printgui-conf. Each of these processes requires a privileged account to access the specific setup tasks. Normally, you will need to use the root account of the system. For more information about printer setup, see the appropriate HP-UX, AIX, or Solaris documentation.

3.5 Administering Batch Processes for UNIX or Linux

This section provides an overview of batch process administration for UNIX or Linux and discusses how to:

3.5.1 Understanding Batch Process Administration for UNIX or Linux

Administering batch processes involves knowing what processes run when JD Edwards EnterpriseOne starts, where files are placed before and after printing, and how to watch those processes.

Processes running for JD Edwards EnterpriseOne are owned by the user who started the JD Edwards EnterpriseOne software. The user ID for this user is set up during the installation of the software, and is site dependent. When JD Edwards EnterpriseOne starts, these processes start and run under the environment and security of the user who started them:

Process Description
jdenet_n The network listener that listens for connection requests.
jdenet_k The jdenet_n process starts the jdenet_k processes, which control JD Edwards EnterpriseOne components, such as the security server, the transaction monitor, and data replication.

Use the jdejobs command to monitor current batch processes. This example is a sample output:

pfst900 (EnterpriseOne Admin,,,):
Semaphores: 1  Shmem Segs: 5  Msg.Queues: 13
Jobs on ent-1:
6137 ttyp6   0:43 jdenet_n
6163 ttyp6   0:44 jdenet_k
6188 ttyp6   0:44 jdenet_k
7213 ttyp6   2:12 jdenet_n
7241 ttyp6   0:47 jdenet_k
9008 ttyp6   1:36 jdenet_n
9009 ttyp6   0:45 jdenet_k
11042 ttyp6   0:09 runbatch

In the output, jdenet_n jobs are listening for requests, and four jdenet_k jobs are handling various JD Edwards EnterpriseOne kernel functions. A runbatch job is processing a report.

The first column of the output displays the UNIX process ID that is associated with each process. For more information about a particular process, look for the files in the log directory that have the same process ID as part of the file name.

All output from each report, regardless of whether it is a preview, is placed in the PrintQueue directory under the installation directory of JD Edwards EnterpriseOne before printing. Depending on the JDE.INI settings for the workstation, the job might not be deleted after printing.

Jobs are printed to the location specified in the JDE.INI file unless a JD Edwards EnterpriseOne program overwrites them. Use the Printers program to specify default printers.

Two settings in the JDE.INI file for the workstation tell the server whether to print the report immediately upon completion, and whether to save the output from the report or delete it. These settings are as follows:

[NETWORK QUEUE SETTINGS]
SaveOutput=TRUE
PrintImmediate=TRUE

Setting SaveOutput to TRUE causes the JDE.INI to hold the jobs within the PrintQueue directory until the user explicitly deletes them. Setting PrintImmediate to TRUE tells the JDE.INI file to print the job immediately after completion of the report.

You can list output files. The returned data looks similar to this:

R014021_XJDE0001_4554_PDF
R014021_XJDE0001_4554_PDF.jde.log
R014021_XJDE0001_4554_PDF.jdedebug.log
R31515_XJDE0001_4566_PDF
R31515_XJDE0001_4566_PDF.jde.log
R31515_XJDE0001_4566_PDF.jdedebug.log
R94NM08_XJDE0008_4568_PDF
R94NM08_XJDE0008_4568_PDF.jde.log
R94NM08_XJDE0008_4568_PDF.jdedebug.log
R94NM10_XJDE0016_4526_PDF
R94NM10_XJDE0016_4526_PDF.jde.log
R94NM10_XJDE0016_4526_PDF.jdedebug.log
R94NM10_XJDE0016_4526_PDF.ps
R94NM10_XJDE0016_4527_PDF
R94NM10_XJDE0016_4527_PDF.jde.log
R94NM10_XJDE0016_4527_PDF.jdedebug.log
R94NM10_XJDE0016_4527_PDF.pcl

The file names in this example are the actual reports that were generated when the job was executed. The file naming conventions are as follows:

Segment Description
R31515 The report name
XJDE00001 The report version executed
1914 The request number assigned by JD Edwards EnterpriseOne
PDF A PDF file, meant for viewing on the workstation
.jde.log The file extension that indicates the log file for the report
.jdedebug.log The file extension that indicates the debug log for the report
.ps The file extension that indicates a file formatted for postscript printing
.pcl The file extension that indicates a file formatted for pcl printing

You should encourage workstation users to use the SaveOutput=FALSE entry in their jde.ini file. If users at workstations decide to save their output, they should periodically delete the entries through JD Edwards EnterpriseOne. When you delete .PDF files from the operating system, the corresponding JD Edwards EnterpriseOne print job entries in the Job Control Status Master table (F986110) are not deleted. You must manually delete these entries from JD Edwards EnterpriseOne using the Work with Servers program (P986116).

3.5.2 Monitoring Batch Processes

To monitor batch processes:

From the operating system prompt, enter this command, replacing userid with the user ID of the user who started JD Edwards EnterpriseOne:

jdejobs <userid>

If you omit the user ID, the current user is assumed.

jdejobs is a script in the JD Edwards EnterpriseOne $SYSTEM/bin32 directory that uses the UNIX ps command to display job information.

3.5.3 Listing Batch Output Files

To list batch output files:

  1. From the operating system prompt, enter this command:

    cd $EVRHOME/PrintQueue
    

    This command changes the directory to the PrintQueue directory. The environment variable EVRHOME should be set to the JD Edwards EnterpriseOne installation directory.

  2. Enter this command to list the files:

    ls
    

3.5.4 Running Reports from the Command Line for UNIX or Linux

You can initiate batch process reports from the server command line by issuing this command (you must have the proper authority and the path equal to the description in the installation instructions) :

runube  <[-p|-P] [-f|-F|-d|-D passfile] [user password]>
   <Environment>
   <Role>
   <ReportName>
   <VersionName>
   <JobQueue>
   <"Interactive"|"Batch">
   <"Print"|"Hold">
   <"Save"|"Delete">
    [Printer]

The format for the passfile parameter is:

[enterpriseoneusername
 password]

Note:

The [user password] parameter has been deprecated.

For the command parameters, only the first character of the parameter name is required. The vertical bar symbol (|) indicates that you must specify one of the parameters on either side of the vertical bar. The brackets indicate an optional parameter. These options apply to the runube command:

Parameter Description
–p Prompts for user/password information.
–P Prompts for user/password information.
–f Reads user/password information from the plain text file that is specified in passfile (FilePath).
–F Reads user/password information from the plain text file that is specified in passfile (FilePath).
–d Reads user/password information from the plain text file and indicates the automatic removal of the file after the job has read the credentials from it.
–D Reads user/password information from the plain text file and indicates the automatic removal of the file after the job has read the credentials from it.
Interactive The system holds the current terminal session until the entire report is processed.
Batch The runube command submits the job to a UBE kernel, which in turn will send the job submission to Queue kernel, then returns control of the terminal to the user.
Print After the batch process completes generating its output, the output is printed to the specified printer queue. If you do not specify a printer on the runube command line, the system uses the EnterpriseOne user's default printer specified in the Printers program (P98616).
Hold The batch output is not printed immediately after the job completes, but may be printed later from 'Work with Submitted jobs'
Save The system retains the report's output and all records of its execution.
Delete The system removes any output from the PrintQueue directory, from Report definition output, and also removes the records of the jobs execution from F986110 after the report prints.

3.5.4.1 Example: Running Reports from the Command Line for UNIX or Linux

This example displays a command for executing a batch process report:

runube KL5952 mypass PROD *ALL R0006P XJDE0001 QBATCH I P D printer_1

3.5.5 Scheduling Reports from the Command Line for UNIX or Linux

You can schedule a report from the command line for processing on a future date, daily, or even a recurring day of the week. This task can be accomplished by using the operating system utilities called at, batch, and cron. The batch and at utilities are used to schedule single occurrence jobs; cron can be used to schedule recurring jobs. Use the at command or the batch command to schedule a job at a later time. The command line structure of these commands is identical, but you use them differently.

The batch command is intended to run a job immediately in the background, providing that the system load is low enough to handle the request. If the system load is not low enough, the job is held until system activity is low enough to handle the new request load.

The at command also runs jobs in the background, but enables you to schedule the job to run at a future time. You can use this utility to run the batch job during off-peak hours.

The command format for the batch command is as follows:

batch command

The command format for the at command is as follows:

at -t CCYYMMDDHHMMSS command

The -t switch is used to schedule the time. This table describes the CCYYMMDDHHMMSS variable:

Segment Description
CC Century (first two digits of the year).
YY Year (last two digits of the year).
MM Two-digit value of the month (such as 02 for February).
DD The day of the month (01 - 31).
HH The hour to start the job (00 - 23).
MM The minute to start the job (00 - 59).
SS The second to start the job (00 - 59).
command The command to run at the specified time. To schedule a report, use the runube command.

You can use the cron UNIX utility to run jobs at a scheduled time. You can specify variable times, such as once a year or once every hour. The operation of this utility is controlled by a table of events based upon each user.

Enter this command to modify the cron schedule and edit the cron table for the current user:

crontab -e

The format of the cron table is as follows:

mm HH DD MM W command

This table describes the variables for this command:

Segment Description
mm The minute to run the job (00 - 59, or * for any minute).
HH The hour to run the job (00 - 23, or * for any hour).
DD The day of the month to run the job (0 - 31, or * for any day).
MM The month to run the job (1 - 12, or * for any month).
W The day of the week to run the job (0 - 6, with 0 being Sunday).
command The command to run at the specified time.

After exiting the editor, the operating system should respond with a message stating that the crontab has been modified.

3.5.5.1 Example: Scheduling Single-Occurrence Reports from the UNIX or Linux Command Line

This example displays a command line used to schedule a report to run at 06:00 on February 26, 2005:

at -t20050226060000 runube KL595218 mypass PROD *ALL R0006P XJDE0001
QBATCH Interactive Print Delete printer_1

3.5.5.2 Example: Scheduling Recurring Reports from the UNIX or Linux Command Line

This example displays a command line used to schedule a report to run at 06:00, any Sunday in the month of February (by the use of * for the day of the month and 0 for the day of the week).

00 06 * 02 0 runube KL5952 mypass PROD *ALL R0006P XJDE0001 QBATCH 
Interactive Print Delete printer_1

3.6 Maintaining File Security for UNIX and Linux

This section provides an overview of file Security and discusses how to:

3.6.1 Understanding File Security Maintenance for UNIX and Linux

Overall, only two accounts ever need operating system access to the JD Edwards EnterpriseOne environment files and version executables: the account that starts and stops JD Edwards EnterpriseOne, and the account that builds the environment SPEC and BSFN files. Normally, these accounts are the same.

Specification (SPEC) files are the first part of the environment files. You access these files by the JD Edwards EnterpriseOne kernel processes. These files should never be accessed directly by an operating system user. Because of this, security on these files should be read/write for the user and role. They are not executables, so no reason exists for setting the executable option for any user, or role.

Business function security should be similar to SPEC file security. This enables the business function code to be viewed, but not modified directly on the server. In general, both business function changes and SPEC file changes are controlled by the deployment server.

You should prevent access to the JD Edwards EnterpriseOne executable files to prevent other users from attempting to start JD Edwards EnterpriseOne. Running the same version of JD Edwards EnterpriseOne on the same system and using the same JDE.INI settings can cause unpredictable results. In most cases, the second startup will fail, but giving users access to the shutdown procedures can enable them to shut down JD Edwards EnterpriseOne.

You must keep the jde.ini file as secure as possible. This file contains a database user name and password that enables JD Edwards EnterpriseOne security to function. This database account is given read authority to the JD Edwards EnterpriseOne Security table (F98OWSEC), which controls JD Edwards EnterpriseOne access.

Access to the F98OWSEC table, which contains privileged database user names and passwords, could give a user the ability to manipulate any data in the database, regardless of its sensitivity or security. Because of this, you should restrict access to the jde.ini file as much as possible.

3.6.2 Setting Specification File Security

To set specification file security:

Add this line to the .profile:

umask 022

This command sets the default file security for files that get created on the server. When a package build completes, SPEC files and business functions should be created with read permission for everyone, and with write permission for only the file owner. In general, both business function changes and SPEC file changes are controlled by the deployment server.

The security for the SPEC files should look similar to these example:

-rw-r--r-- psft psft jdeblc.xdb
-rw-r--r-- psft psft jdeblc.ddb

3.6.3 Setting Business Function File Security

To set business function file security:

  1. Enter this command in the BSFN Source directory:

    chmod 644 *.c
    
  2. Enter this command in the BSFN Include directory:

    chmod 644 *.h
    

    The security for the BSFN files should look similar to these example:

    -rw-r--r-- psft psft b4200100.c
    
    -rw-r--r-- psft psft b4200100.h
    

3.6.4 Setting Executables Security

To set executables security:

UNRECOGNIZED STYLE ->class=singlestep>Enter this command:

cd $SYSTEM/bin32
chmod 540 *..sh

The access granted by this command gives all users in the JD Edwards EnterpriseOne role read-only permission to the files, but does not grant them execute privilege. You can omit read access if desired.

The security for the JD Edwards EnterpriseOne executables should look similar to these example:

-r-xr----- psft psft RunOneWorld.sh
-r-xr----- psft psft EndOneWorld.sh

3.6.5 Setting jde.ini File Security

Warning: Implementing JDE.INI file security will prevent Server Manager from modifying configuration settings.

To set JDE.INI file security:

  1. Enter this command:

    cd $JDE_BASE
    
    chmod 600 JDE.INI
    

    This command sets maximum security for the JDE.INI file. The JDE_BASE environment variable is set to the directory that contains the JDE.INI file.

    Note:

    The file name is case-sensitive.

    The security for the JDE.INI file should look similar to this:

    -rw------- psft psft JDE.INI
    

    Denying write access to the user psft is not strictly necessary, but can prevent accidental modification of JDE.INI settings, which could adversely affect the operation of JD Edwards EnterpriseOne.

  2. If you want to deny the user write access, enter this command:

    chmod 400 JDE.INI
    

    Because it is important to keep access to the JDE.INI file as secure as possible, you should also limit the amount of access to the user psft (or the user account that starts and stops JD Edwards EnterpriseOne) to a minimum. Users with access to this account might obtain the user names and passwords in the F98OWSEC table, and, thus, gain privileged access to the database.

Note:

Denying write access may prevent Server Manager from being able to change the configuration items within the JDE.INI file.

3.7 Working with HP-UX and Solaris Kernel Parameter Settings

Beginning in Solaris 10, Sun made a major change in the way IPC parameters are handled. These parameters are no longer changed through the /etc/system file - some have been eliminated, and some must now be changed through the Solaris resource controls facility. A discussion of Solaris resource controls is beyond the scope of this document; however, we will provide one example here that may be required before starting JD Edwards EnterpriseOne for the first time. When starting the JD Edwards EnterpriseOne software on the server, the initial jdenet_n process tries to create a semaphore array containing the number of elements indicated by the "maxNumberOfSemaphores" parameter in the enterprise JDE.INI file. By default, Solaris 10 will allow a semaphore array with a maximum of 512 elements. If the setting in the JDE.INI file is greater than 512, the system default will have to be changed. In Solaris 10, the following command is the simplest way to change the default:

projmod -K 'process.max-sem-nsems=(privileged,2048,deny)' default

This command changes the default project to allow semaphore arrays with up to 2048 elements. This is most likely the only resource control that you will have to change in Solaris 10 to be able to start JD Edwards EnterpriseOne. To see the resource control limits for a given user, sign on to that user and run the following command:

prctl $$

See the Solaris documentation "System Administration Guide: Solaris Containers-Resource Management and Solaris Zones" at http://docs.sun.com..

The kernels for HP-UX and Solaris (prior to Solaris 10) include a long list of configurable parameters. These parameters control the quantity of various resources available within the HP-UX and Solaris kernels. Also, the JD Edwards EnterpriseOne server software, specifically the IPC facilities, is sensitive to numerous kernel parameters for operation. These parameters differ among the various vendor implementations of UNIX. To change the values of kernel parameters for HP-UX, you must use the System Administration Management (SAM) tool to modify the parameters, which might require rebooting the system. For Solaris, you must reboot the system after you modify kernel parameters in the /etc/system file. The proper values of these parameters depend on various criteria, such as number of users on the system, active applications, and the resource requirements for the active applications.

For HP-UX, you set kernel parameters with the SAM tool. To modify these parameters for Solaris, open the /etc/system file with the a text editor. You can set any given parameter to either a simple numerical value or an expression, based on the values of other parameters. The system administrator must set the kernel parameters. UNIX security refers to users with access to administrative functions as superusers.

When you first set up an HP-UX or a Solaris machine for JD Edwards EnterpriseOne, you should run SAM for HP-UX or an editor for Solaris, and change the kernel parameters. On an HP-UX system, you can see the current values of kernel parameters by running the kmtune command, or by running SAM. On a Solaris system, type the command sysdef -i to see the current kernel settings.

JD Edwards EnterpriseOne is not the only software to use the resources that the kernel parameters control. Therefore, for each parameter, the requirements for JD Edwards EnterpriseOne are either the minimum defaults provided with HP-UX and Solaris, in addition to the defaults provided with HP-UX and Solaris, or the requirements of other software installed on the system.

Note:

The number of JD Edwards EnterpriseOne users that a machine serves, the number of instances of JD Edwards EnterpriseOne server software running on a machine, and the size of any databases on the machine are primary factors that affect the settings for HP-UX and Solaris kernel parameters. The number of jdenet_n, jdenet_k, and runbatch or runube processes running should reflect this information.

This list provides the definitions of terms essential to the understanding of HP-UX and Solaris kernel parameters:

Parameter Definition
jdenet_n The maximum number of jdenet_n (net) processes that can be created for an instance JD Edwards EnterpriseOne server software running on the system. This is controlled by the maxNetProcesses parameter in the JDENET section of the JDE.INI file for each instance of JD Edwards EnterpriseOne.
jdenet_k The maximum number of jdenet_k (kernel) processes that can be created for an instance of JD Edwards EnterpriseOne server software running on the system. This is controlled by the maxKernelProcesses parameter in the JDENET section of the JDE.INI file for each instance of JD Edwards EnterpriseOne. Note that the maxNumberOfProcesses parameters in the JDENET_Kernel_Def sections do not matter here.

This screen capture provides an example of a Solaris editor that displays information for shared memory segments. The parameter name appears at the end of each line in the editor, such as shmmax at the end of this line: set shmys shminfo_shmmax=4294967295:

3.7.1 Message Queues

Generally, the system clears queues quickly. If a problem arises, you can revise values for these parameters to rectify the situation:

Parameter Description
mesg This value must be 1. System-V style message queues are valid.
msgmni The value of msgmni represents the number of message queue identifiers. These identifiers determine the number of message queues that can exist throughout the system. In addition to the system default value and the requirements of other software, calculate what is needed for the JD Edwards EnterpriseOne installation (per JD Edwards EnterpriseOne instance). You can use these equation to estimate the number of message queues necessary for JD Edwards EnterpriseOne:

1 + jdenet_n + 2 x jdenet_k + (max number of concurrent runbatch, runube, and runprint processes)

msgtql The value of msgtql represents the number of message headers. This number determines the total number of messages that can be in all the message queues at the same time. In addition to the requirements of other software, allow a value equal to 10 x msgmni for the requirements of JD Edwards EnterpriseOne.
msgmap The value for msgmap represents the number of entries in the map of free message segments. The default value of msgtql + 2 should be used. If the value of msgmap is less than the value of msgtql + 2, attempts to create a message queue or to send a message might fail.

Note: This parameter is no longer used in Solaris 8.

msgmnb The value of msgmnb represents the maximum number of bytes that can reside on a single message queue at the same time. You should set the value for msgmnb at only a fraction of msgseg x msgssz. For JD Edwards EnterpriseOne, a value of 32768 is reasonable. You can set a larger value as long as the product of msgseg x msgssz is large enough. The minimum value is 8192. Additional requirements of this parameter might increase the value of msgmnb.
msgmax The value of msgmax represents the maximum size, in bytes, of a single message. Do not set msgmax with a larger value than the value of msgmnb. The recommended setting is msgmax = msgmnb. The minimum value is 1024. Additional requirements of this parameter might increase the value of msgmax.

Inside the HP-UX and Solaris kernels (prior to Solaris 8), messages in message queues reside in message segments. These parameters, which do not apply to Solaris 8, determine the size and number of segments available throughout the system:

Parameter Description
msgssz The value of msgssz represents the size of each message segment in bytes. For JD Edwards EnterpriseOne, a value of 64 is adequate for most situations.
msgseg The value of msgseg represents the number of message segments throughout the system. In addition to the requirements of other software, allow a value equal to 50 x the msgmni requirement for JD Edwards EnterpriseOne, or approximately 4096 per instance.

3.7.2 Semaphores

These definitions apply to semaphores:

Parameter Description
sema This value must be 1. System-V style message queues are valid.
semmni The value of semmni represents the maximum number of semaphore identifiers that can exist throughout the system.

For JD Edwards EnterpriseOne, two identifiers exist for each instance of JD Edwards EnterpriseOne, so the default value supplied with the HP-UX and Solaris systems should suffice.

semmap The value of semmap represents the number of entries in the map of free semaphores. The default value of semmni + 2 should suffice. If you decrease the value of semmap, attempts to create a semaphore set, which occurs during JDEIPC initialization, might fail.

Note: This parameter is not used in Solaris 8.

semmns The value of semmns represents the maximum number of semaphores that can exist throughout the system. Each instance of JD Edwards EnterpriseOne allocates 1000 semaphores by default. However, you can customize this value in the JDE.INI file. In the [JDEIPC] section, modify the parameter maxNumberOfSemaphores to customize the number of semaphores that an instance of JD Edwards EnterpriseOne allocates.

For all releases of JD Edwards EnterpriseOne, the JD Edwards EnterpriseOne requirement is in addition to the requirements of other software. A good starting point for a typical JD Edwards EnterpriseOne installation (single instance) with Oracle should be 2000.

semmnu The value of semmnu represents the maximum number of semaphore undo structures for the entire system. Effectively, this value is the maximum number of semaphores that the system can lock at the same time. For JD Edwards EnterpriseOne, enable one for each JD Edwards EnterpriseOne process that can exist for all installations of JD Edwards EnterpriseOne on the system. Use these equation to determine this value:

1 + jdenet_n + jdenet_k + maximum number of runbatch processes + maximum number of runprint processes + maximum number of runube processes

Note: This equation is similar to the equation used to calculate the value for msgmni. If you will be running a large number of batch queues or print jobs, you might need to increase the value of this parameter.

The number of outstanding print requests at a given time, whether printing or waiting for a printer, determines the number of jdeprint processes. A reasonable estimate for the upper limit of this value is 10. However, this estimate is application-dependent. For example, a large warehouse that constantly prints pick slips might have more requests.

The number of batch processes that run directly on the server, not from a client, determine the number of runube processes. This value depends on the use of the system. Theoretically, this value has no limit.

semume The value of semume represents the maximum number of semaphore undo structures per process. Effectively, this value is the maximum number of semaphores that a given process can lock at the same time. JD Edwards EnterpriseOne requires a minimum value of 4 for semume. This minimum value is not in addition to the system default and the requirements of other software. This value is a simple minimum. The default value provided with the system should suffice.
semmsl The value for semmsl, which applies to Solaris and newer versions of HP-UX, represents the maximum number of semaphores per unique identifier. For JD Edwards EnterpriseOne, this must be set equal to or higher than the maxNumberOfSemaphores setting in the JDE.INI file. For the default installation, you should set this parameter to 1000.

3.7.3 Shared Memory

These definitions apply to shared memory:

Parameter Description
shmem The shmem value must be 1 to enable shared memory.
shmmax The value of shmmax represents the maximum size, in bytes, of a single shared memory segment. The default value provided with the system should suffice. Other software packages, such as Oracle, might require an increase in this value.
shmmni The value of shmmni represents the maximum number of shared memory segments throughout the system. For JD Edwards EnterpriseOne, enable 20 per instance of the JD Edwards EnterpriseOne server software running on the system. This requirement is in addition to the system default value and the requirements of other software.
shmseg The value of shmseg represents the maximum number of shared memory segments to which any one process can attach at a given moment. The default value provided with the system should suffice.

3.7.4 File Descriptors

These definitions apply to file descriptors:

Parameter Description
nfile The value of nfile represents the maximum number of open files, or sockets, throughout the system. The default value should be enough to handle most JD Edwards EnterpriseOne needs. However, you must make explicit allowance for the maximum number of sockets that jdenet_n processes can create to communicate with clients. This number is the sum of all sockets for all instances of JD Edwards EnterpriseOne server software that runs on the system. The maxNetConnections parameter in the [JDENET] section of each JDE.INI file indicates this sum. This requirement is in addition to the system default value and the requirements of other software.
maxfiles (rlim_fd_cur in the Solaris /etc/system file) The value of maxfiles represents the default soft limit on the number of file descriptors that any given process can have. A system call can raise the soft limit of a process as high as maxfiles_lim. For JD Edwards EnterpriseOne, the minimum value for maxfiles should equal at least the largest of all the maxNetConnections values in all the JDE.INI files in use + 10. This requirement is a minimum value, not a value in addition to the system default value and the requirements of other software.

Note: If this parameter is too small, JD Edwards EnterpriseOne might not open the log file to generate an error message.

maxfiles_lim (rlim_fd_max in the Solaris /etc/system file) The value of maxfiles_lim represents the hard limit of file descriptors that any given process can have. For JD Edwards EnterpriseOne, the minimum value for maxfiles should equal at least the largest of all the maxNetConnections values in all of the JDE.INI files in use + 10. This requirement is a minimum value, not a value in addition to the system default value and the requirements of other software.

3.7.5 Processes

This definition applies to processes:

Parameter Description
maxuprc The value of maxuprc represents the maximum number of processes that can run under a single user ID. This number is of particular concern on systems with either a very large JD Edwards EnterpriseOne installation or multiple instances running under the same user ID. You must allow for the total number of JD Edwards EnterpriseOne processes that might run at one time, plus other system processes that the JD Edwards EnterpriseOne user might be running.

3.8 Working with Linux Kernel Parameter Settings

This section provides an overview of Linux kernel parameter settings.

3.8.1 Understanding Linux Kernel Parameter Settings

The Linux operating system uses many of the same kernel parameters as Solaris, but they are managed in a slightly different way. In the Linux 2.4 kernel, IPC parameters are defined and maintained in the /proc file system, in the directory /proc/sys/kernel. They can be modified dynamically by editing the appropriate file, but for enterprise applications, you should override the default parameters at boot time. In RedHat Enterprise Linux, the default parameters can be overridden at boot time by adding entries to the /etc/sysctl.conf file. Use the command ipcs -l to view the current values for IPC resource limits.

3.8.1.1 IPC Resources

These five entries in the /etc/sysctl.conf file affect JD Edwards EnterpriseOne IPC resources:

Parameter Description
kernel.sem This setting controls these four different semaphore limits:
  • Maximum number of semaphores per array (semmsl on Solaris).

  • Maximum number of semaphores in the system (semmns).

  • Maximum operations per semop call (semopm).

  • Maximum number of semaphore arrays (semmni).

For JD Edwards EnterpriseOne, you might need to increase the first value, semaphores per array, particularly if you increase the value of maxNumberOfSemaphores in the jde.ini file. Some database products also require that the fourth value, number of semaphore arrays, be increased from the default value.

kernel.shmmax The default value for this parameter might be sufficient for JD Edwards EnterpriseOne, but some database products recommend that this be set to 256 Mb, or 90 percent of total memory, whichever is greater.
kernel.msgmax This parameter defines the maximum size of a message. The recommendation for JD Edwards EnterpriseOne is 65535.
kernel.msgmnb This parameter defines the maximum number of bytes on a message queue. The recommendation for JD Edwards EnterpriseOne is 65535.
kernel.msgmni This parameter defines the maximum number of message queues (identifiers) in the system. You can use these equation to estimate the number of message queues that are necessary for JD Edwards EnterpriseOne:

1 + jdenet_n + 2 x jdenet_k + (max number of concurrent runbatch, runube, and runprint processes)


3.8.1.2 File Limits

In addition to the IPC resource limits, WebSphere and the JD Edwards EnterpriseOne HTML Server can require a large number of open files. To see the current values, review the file /proc/sys/fs/file-nr. This read-only file contains these three values:

  • Total allocated file handles

  • Currently used file handles

  • Maximum file handles

The first value represents a peak, so when this value approaches the maximum value, consider raising the limit. If the peak value reaches the limit, you will get unpredictable results because processes will not be able to open files. To change the maximum file handle limit, use the fs.file-max setting. This setting controls the maximum number of files that can be simultaneously open throughout the entire system. The recommendation for JD Edwards EnterpriseOne is 32768, and this number might need to be increased to 65536 for larger installations.

3.8.1.3 Example: /etc/sysctl.conf

These lines are from a typical sysctl.conf file that are used to set kernel parameters based on the previous information:

fs.file-max = 32768
kernel.shmmax = 268435456
kernel.sem = 500 32000 32 1024
kernel.msgmax = 65535
kernel.msgmnb = 65535
kernel.msgmni = 1024

3.9 Working with AIX Kernel Parameter Settings for JD Edwards EnterpriseOne

This section provides an overview of AIX kernel parameter settings for JD Edwards EnterpriseOne and discusses how to:

3.9.1 Understanding AIX Kernel Parameter Settings for JD Edwards EnterpriseOne

AIX contains a set of kernel parameters (system parameters) that determine functionality and a separate set of performance parameters (tune parameters) that determine performance.

Setting the kernel parameters requires you to run the system management tool (SMIT). AIX has few configurable parameters that influence JD Edwards EnterpriseOne software; of those that influence JD Edwards EnterpriseOne, just one can cause the software to become inoperable. This parameter is maxuproc. The maxuproc parameter controls the number of processes that a single user can run simultaneously.

3.9.2 Setting the Value of maxuproc

To set the value of maxuproc:

  1. Sign on as the root user.

  2. On the command line, enter this command:

    smit
    
  3. In SMIT, select the System Environments item and then select the Change/Show Characteristics of Operating System item.

  4. Change the value of Maximum number of processes to enable all JD Edwards EnterpriseOne processes that might run at one time, plus any other system processes the JD Edwards EnterpriseOne user might be running.

    Accept the default values for all other system parameters. This table lists these system parameters for general reference:

    Parameter Description
    maxbuf Max pages in block I/O buffer cache.
    maxmbu Max real memory for MBUFS.
    autorestart Automatically reboot after crash.
    iostat Continuously maintain disk I/O history.
    maxpout High water mark for pending write I/O per file.
    minpout Low water mark for pending write I/O per file.
    keylock State of system keylock at boot time.
    fullcore Enable full core dump.
    pre43core Use pre-430 style core dump (AIX 4.3 only).
    logfilesize Error log file size.
    memscrub Enable memory scrubbing.
    dcache Size of data cache in bytes.
    icache Size of instruction cache in bytes.
    realmem Size of usable physical memory.
    primary Primary dump device.
    conslogin System console login.

3.9.3 Viewing the System Parameters

To view the system parameters:

Enter this command:

lsattr-E-lsys0

To change a system parameter, you must navigate to the correct SMIT menu option.

3.9.4 Setting Tune Parameters

Setting the tune parameters requires you to run these commands:

  • For network parameters: no

  • For device parameters: chdev

  • For nfs parameters: chnfs

  • For general tuning parameters: vmtune

Tune parameters can also be kept at their default values. Changes to tune parameters are generally needed only for performance reasons. Proper settings for optimal performance might vary with changes in the underlying database, hardware configuration, and JD Edwards EnterpriseOne configuration.

Performance tuning for AIX running JD Edwards EnterpriseOne or Oracle involves setting parameters that control virtual memory for paging, Raid, disk system types, and CPU scheduling.

3.9.4.1 Example: Disk Striping

Disk striping is the technique of spreading sequential data across multiple disk drives so data can be accessed in parallel from several drives at once. If striping is used, then these tune parameters are set:

Parameter Value
stripe size 64KB
max_coalesce 64KB
minpgahead 2
maxpgahead 16 x number of disk drives
maxfree minfree + maxpgahead

3.10 Running Multiple Instances of the JD Edwards EnterpriseOne Enterprise Server

This section provides an overview of running multiple instances of the JD Edwards EnterpriseOne enterprise server and discusses how to do so.

3.10.1 Understanding Running Multiple Instances of the JD Edwards EnterpriseOne Enterprise Server

Common reasons for running multiple instances of the JD Edwards EnterpriseOne enterprise server are to test a new service pack or to upgrade to a new version of JD Edwards EnterpriseOne. You can run multiple instances of the JD Edwards EnterpriseOne server on the same machine by following a few simple guidelines.

Note:

These steps do not create a new database or any new database tables. Therefore, you will be using the same data tables that are used by the original instance of JD Edwards EnterpriseOne that was installed. If you want to create a completely separate set of database tables, follow the instructions for setting up a new environment.

After you make all of the changes described in this chapter, you can start and stop the new JD Edwards EnterpriseOne instance independently of the original instance.

All existing JD Edwards EnterpriseOne environments will be valid for the new instance, provided that you have copied the corresponding path code directory for a given environment. All current logical data sources and OCM mappings will be recognized by the new instance.

Server Manager fully supports multiple foundations. This includes the installation and management of multiple instances of JD Edwards EnterpriseOne on a single server.

See Also:

3.10.2 Prerequisite

Verify that you have enough disk space to create copies of the current JD Edwards EnterpriseOne system directory and at least one path code directory.

3.10.3 Running Multiple Instances of the JD Edwards EnterpriseOne Enterprise Server

To run multiple instances of the JD Edwards EnterpriseOne enterprise server:

  1. The system administrator should create a new user ID that owns the new JD Edwards EnterpriseOne instance.

    Create the user ID using the appropriate administration tool, such as smit, SAM, admintool, or useradd.

    Note:

    Although you can run multiple instances of the JD Edwards EnterpriseOne server using the same UNIX or Linuxuser ID, it is not recommended. The software depends on certain environment variables to function correctly, and these variables are easier to manage under different user IDs.
  2. Sign on using the new user ID.

  3. Copy the .profile and .psft files from the home directory of the original user ID to the home directory of the new user ID.

  4. Change the .profile file for the new user ID, if appropriate.

  5. Change the .psft file for the new user ID to reference the new directory path in which you will create the new JD Edwards EnterpriseOne instance.

    For example:

    Original .psft file:

    export EVRHOME=/u01/JDEdwards/E900
    

    New .psft file:

    export EVRHOME=/u02/JDEdwards/E900
    
  6. Create the directory in which the new JD Edwards EnterpriseOne instance will reside.

    For example, type these:

    mkdir -p /u02/JDEdwards/E900
    
  7. Copy the system directory, the ini directory, and at least one path code directory from the original instance of JD Edwards EnterpriseOne to the new directory path.

    These sample commands accomplish this:

    cp -R /u01/JDEdwards/E900/system /u02/JDEdwards/E900
    cp -R /u01/JDEdwards/E900/ini /u02/JDEdwards/E900
    cp -R /u01/JDEdwards/E900/DV900 /u02/JDEdwards/E900
    

    Note:

    The path code directories for any environments that you intend to use for this second instance of JD Edwards EnterpriseOne must be copied to the new directory. You cannot share path code directories between two or more instances of JD Edwards EnterpriseOne, as this sharing might corrupt specification files.
  8. Create an empty log directory under the new path using a command such as this:

    mkdir -p /u02/JDEdwards/E900/log
    
  9. In the new JDE.INI file, change all references to the original directory name to the new directory name, including the [INSTALL], [DEBUG], and [BSFN BUILD] sections.

    For example:

    [DEBUG]
    DebugFile=/u02/JDEdwards/E900/log/ jdedebug.log
    JobFile=/u02/JDEdwards/E900/log/jde.log
    
    [INSTALL]
    B9=/u02/JDEdwards/E900
    
    [BSFN BUILD]
    BuildArea=/u02/JDEdwards/E900/packages
    
  10. Change the new JDE.INI file to reference a port number and starting IPC key that are different from the original JD Edwards EnterpriseOne instance.

    The values are defined by these parameters; but the numbers are only examples:

    [JDENET]
    serviceNameListen=6009
    serviceNameConnect=6009
    
    [JDEIPC]
    startIPCKeyValue=9000
    
  11. From the client workstation JDE.INI file, change the serviceName parameters to match those of the server JDE.INI file.