Troubleshooting the Enterprise Server

This chapter provides an overview of enterprise server troubleshooting and discusses how to:

• View enterprise server logs from the workstation.

• Set up the enterprise server jde.log.

• Set up the enterprise server jdedebug.log.

• Set up the <batch process>.log file.

• Troubleshoot the enterprise server.

• Troubleshoot the iSeries enterprise server.

• Troubleshoot the UNIX/Linx enterprise server.

• Troubleshoot the Microsoft Windows enterprise server.

• Troubleshoot web servers.

Understanding Enterprise Server Troubleshooting

Using these techniques, you can troubleshoot batch applications and business functions that process on the Oracle JD Edwards EnterpriseOne enterprise server. Platform-specific procedures are presented in other sections of this guide.

You might encounter these types of general problems on a JD Edwards EnterpriseOne enterprise server. The information presented applies to all operating systems:

• Communication failure when submitting a UBE or when trying to run business function logic on the server.

• Error message appearing at the bottom of a form (press F8 or click Bitmap to view an error description).

You should be familiar with the various logs used to troubleshoot problems on the server. Using these logs, you can troubleshoot batch applications and business functions that are executing on the enterprise server.

Types of Enterprise Server Log Files

In general, logs on JD Edwards EnterpriseOne enterprise servers are classified as either logic processing logs or batch processing logs.

Logic Processing Logs

You can use these two major log file sources for troubleshooting processing faults on the enterprise server:

• jde.log

  This log displays fatal errors. It can track any fault that might occur within JD Edwards EnterpriseOne.

• jdedebug.log

  This log tracks API calls and SQL statements as well as other messages. You can use this file to determine the point in time when normal execution stopped. The system does not use jdedebug.log to track errors; instead, this log is used to track the timing of JD Edwards EnterpriseOne processes.

Batch Processing Logs

You can use the batch process log to identify faults in JD Edwards EnterpriseOne processing related to batch processes. This log can contain event rule (ER) references, batch application process flow, and SQL statements, as well as other messages.

The Enterprise Server jde.log File

You can use the enterprise server jde.log to track fatal error messages generated by batch applications and business functions that are executing on the enterprise server. The jde.log tracks any fault that might occur within JD Edwards EnterpriseOne. When you are looking for startup errors, you should read the jde.log from the top down. For other errors, you should read from the bottom up.

If jde.log is enabled, a uniquely identified log file is created each time you start a JD Edwards EnterpriseOne job (including JD Edwards EnterpriseOne startup) on the enterprise server. These logs are associated with an enterprise server process ID (Job Number for iSeries).

The process ID (Job Number for iSeries) is appended to the file name, before the .log extension, with an underscore character (for example, jde_442.log).

jde.log File Creation

The enterprise server jde.log file is created (if it does not exist) or overwritten (if it exists) at the start of every JD Edwards EnterpriseOne session. For a Microsoft Windows enterprise server jde.log file, JD Edwards EnterpriseOne appends new information to the end of the jde.log.

Troubleshooting: Enabling and Disabling jde.log

Normally, the enterprise server should be set to enable the jde.log and disable the jdedebug.log. This example has combinations for the jde.ini parameter setting for enabling or disabling server logs.

Enable jde.log

This is an example of the jde.log file with debug logging enabled:

[DEBUG]
Output=NONE
LogErrors=1
JobFile=valid location/name (1)
DebugFile=valid location/name (2)

Enable jde.log and jdedebug.log

This is an example of the jde.log file with debug logging enabled and output to a file:

[DEBUG]
Output=FILE
LogErrors=1
JobFile=valid location/name (1)
DebugFile=valid location/name (2)

Disable jde.log

This is an example of the jde.log file with debug logging disabled:

[DEBUG]
Output=NONE
JobFile=blank/invalid location/name (1)
DebugFile= blank/invalid location/name (2)

Files and members generated by the jde.log will be located in JobFile. JD Edwards EnterpriseOne uses these naming conventions:

jde_process_ID.log

Where jde is the file or member name prefix, process_ID is a uniquely named process ID, and log is the file or member suffix or extension.

For non-iSeries enterprise servers, files generated by the jdedebug.log will be located in DebugFile. JD Edwards EnterpriseOne uses these naming conventions:

jdedebug_process_ID.log

Where jdedebug is the file name prefix, process_ID is a uniquely named process ID, and log is the file suffix or extension.

Note. Verify whether the paths for the JobFile and the DebugFile settings are valid. If the paths for these settings are invalid, JD Edwards EnterpriseOne does not create logs.

For iSeries enterprise servers, the members generated by jdedebug will be located in DebugFile. JD Edwards EnterpriseOne uses these naming conventions:

jdedebug_process_ID

Where jdedebug is the file name prefix and process_ID is a uniquely named process ID.

Troubleshooting: Recommendations for the Enterprise Server jde.log

You can create a normal (successful) jde.log by signing on to JD Edwards EnterpriseOne and then immediately signing off. Use this log of successful startup statements to compare against logs that have a problem.

You can also rename the log to indicate the nature of the problem. For example, you might delete the jde.log and then run a report that causes an error condition. Then you could rename the jde.log to report.log.

If you are the only user running an instance of JD Edwards EnterpriseOne, you can add comment lines to the jde.log indicating the sequence of events you are performing. For example, you might be running an application that you know causes an error. Before you run the application, you could edit the jde.log to add a comment line stating you are about to start the suspect application.

Troubleshooting: Recommendations for Setting Up Server Locations

JD Edwards EnterpriseOne recommends that you create a separate directory on the enterprise server for logs. You should set up the jde.ini file to explicitly direct log files to that directory. For jde.log, the location and name of the log file are controlled by this default setting:

[DEBUG]
JobFile=jde.log

Files generated by the jde.log are located in JobFile. JD Edwards EnterpriseOne uses this syntax for naming files:

jde_process_ID.log (jde_jobnumber.log for iSeries)

If you do not specify a location, JD Edwards EnterpriseOne places the log files in the directory where you ran the JD Edwards EnterpriseOne startup executable (the default). On a UNIX machine, if you start JD Edwards EnterpriseOne with these commands and if logging is enabled, the system places the log files in the /u13/JDEdwards/E812/system/bin32 directory:

cd /u13/JDEdwards/E812/system/bine32
RunOneWorld.sh

If you start JD Edwards EnterpriseOne with these commands and if logging is enabled, the system places the log files in the /usr/JDEdwards directory because that is the working directory:

cd /usr/JDEdwards

/u13/JDEdwards/E812/system/bin32/RunOneWorld.sh

If you set up the UNIX machine to automatically start JD Edwards EnterpriseOne when the machine is started, it is especially important that you specify the full path of the log file in the jde.ini file.

Naming Conventions for jde.log

JD Edwards EnterpriseOne processes create logs as jde_processID.log (jde_JobNumber.log for iSeries), where processID is the process ID of the process that creates the log.

Non-iSeries JD Edwards EnterpriseOne processes move logs for batch jobs to the PrintQueue directory and rename them as report_version_date_time.log, where report is the report name and version is the version name; for example, R014021_XJDE0001_D990312_T161854215.log.

Example: Enterprise Server jde.log

This example of the jde.log from the enterprise server displays errors caused by signon tables that were not properly closed after fetching data. Normally, the only way this can happen is if a business function program did not close the table. Therefore, generated code applications cannot have this problem.

Most entries in the jde.log file are significant, and you should examine them closely. This information is also used by developers to indicate problems with the application that need to be addressed.

Troubleshooting: Recommendations for the Enterprise Server jde.log when a fatal crash occurs

If a fatal crash occurs on a JD Edwards EnterpriseOne Windows Server the Call Stack will be automatically be dumped into the jde.log file. This information in the jde.log file will contain a fully qualified path to the system install location. Therefore, you should take the necessary steps to ensure that the install path information is secured.

The Enterprise Server jdedebug.log File

You can use the enterprise server jdedebug.log to determine the point in time when normal execution stopped. The system does not use jdedebug.log to track errors. Instead, it uses this log to track the timing of JD Edwards EnterpriseOne processes. The log contains API calls and SQL statements as well as other messages.

You can use jdedebug.log to find out where a process ended. For example, log data can include what ODBC was trying to connect to, the SQL statement that was being executed for a specific table, and whether memory has been freed.

If jdedebug is enabled, each jdenet_n job and batch process started on a server creates a uniquely identified jdedebug.log. These logs are associated with an enterprise server process ID. Each time JD Edwards EnterpriseOne is started on the enterprise server and each time a batch process job is executed on the enterprise server, a new jdedebug.log is created.

For enterprise servers, the process ID (Job Number for iSeries) is appended to the file name with an underscore character before the .log extension. For example, the file name might be jdedebug_442.log. The enterprise server jdedebug.log is created (if it doesn't exist) or overwritten (if it exists) at the start of every JD Edwards EnterpriseOne session. For a Microsoft Windows enterprise server jde.log file, JD Edwards EnterpriseOne appends new information to the end of jde.log.

Note. Server administrators are responsible for clearing and deleting jde.log and jdedebug_*.log files from the enterprise server.

Troubleshooting: Reading the jdedebug.log

If the process failed and you have logging turned on, look in the jdedebug.log for these messages:

• Not Found

• Failure

Also, look at the end of the log to see what task was executed last. In general, important lines in the log are:

• SELECT

  The SELECT lines indicate which table you are selecting. The log tells you where the table resides. For the iSeries, this location is a library. For non- iSeries servers, this location is an environment. You should verify that the selected libraries and environments are correct.

• ODBC Version

  The ODBC lines indicate whether you are having problems connecting to the driver.

Troubleshooting: Enabling and Disabling jdedebug.log

Normally, the enterprise server should be set to enable the jde.log and disable the jdedebug.log. This example has valid setting combinations for enabling or disabling server jdedebug.log.

Troubleshooting: Enabling and Disabling jdedebug.log

These are the settings for enabling the jdedebug.log file:

[DEBUG]
Output=FILE
LogErrors=1
JobFile=valid location/name (1)
DebugFile=valid location/name (2)

Enable jde.log and jdedebug.log

These are the settings for enabling the jde.log and jdedebug.log files:

[DEBUG]
Output=BOTH
LogErrors=1
JobFile=valid location/name (1)
DebugFile=valid location/name (2)

Disable jdedebug.log

These are the settings for disabling the jdedebug.log file:

[DEBUG]
Output=NONE
LogErrors=0
JobFile=valid location/name (1)
DebugFile=valid location/name (2)

The [DEBUG] section of the jde.ini file contains the files and members generated by the jde.log. JD Edwards EnterpriseOne uses these naming conventions:

jde_<pid>.log

Where jde is the file or member name prefix and <pid> is a uniquely named process ID.

For enterprise servers, the files generated by the jdedebug.log will be located in the jde.ini file. JD Edwards EnterpriseOne uses these naming conventions:

jdedebug_<pid>.log (jdedebug_<JobNumber>.log)

Troubleshooting: Recommendations for the Enterprise Server jdedebug.log

You can create a normal (successful) jdedebug.log (JDEDEBUG for iSeries) by logging on to JD Edwards EnterpriseOne and then immediately logging off. Use this log of successful start up statements to compare against logs that have a problem.

You can also rename the log to indicate the nature of the problem. For example, you might delete the jdedebug.log and then run a report that causes an error condition. Then you could rename the jdedebug.log to report.log.

Another alternative is to add comment lines to the jdedebug.log that indicate the sequence of events you are performing. For example, you might be running an application that you know causes an error. Before you run the application, you could edit the jde.log to add a comment line stating that you are about to start the suspected application.

Troubleshooting: Recommendations for Setting Up Server Locations

We recommend that you create a separate directory on the enterprise server for logs. You should set up the jde.ini file to explicitly direct log files to that directory. For jdedebug.log, these setting controls the location:

 [DEBUG]
DebugFile=jdedebug.log

For enterprise servers, the files generated by the jdedebug.log will be located in DebugFile. JD Edwards EnterpriseOne uses these naming conventions:

jdedebug_process_ID.log (jdedebug_JobNumber.log for iSeries)

Where jdedebug is the file name prefix and process_ID is a uniquely named process ID.

By default, JD Edwards EnterpriseOne places the log files in the directory where you ran the startup executable. For example, on a UNIX machine, if you start JD Edwards EnterpriseOne with this command:

cd /u13/JDEdwards/E812/system/bin32 RunOneWorld.sh

and assuming that logging is enabled, the system places the log files in the /u13/JDEdwards/E812/system/bin32 directory. Similarly, on a UNIX machine, if you start JD Edwards EnterpriseOne with this command:

cd /usr/JDEdwards /u13/JDEdwards/E812/system/bin32 RunOneWorld.sh

and assuming that logging is enabled, the system places the log files in the /usr/JDEdwards directory. This is the working directory. If you set up the UNIX machine to automatically start JD Edwards EnterpriseOne when the machine is booted, it is especially important that you specify the full path of the log file.

Naming Conventions for jdedebug.log on the Enterprise Server

JD Edwards EnterpriseOne processes create logs as jdedebug_process_ID.log, where process_ID (Job Number for iSeries) is the process ID of the process creating the log. For example, a batch report running on a UNIX server as process 123456 would produce a file named jdedebug_123456.log.

The Batch Process Log File

Whenever you run a batch process requested from a workstation, an individual log file is created in the JD Edwards EnterpriseOne print queue directory (E812\PrintQueue) on that workstation. For any batch process request issued from a workstation, this file is created even if you have specified that the batch process report is to run on the enterprise server. For batch processes requested from a server, the jdedebug.log file is created on the server in the print queue directory.

Based on the setting of the UBESaveLogFile parameter in the [UBE] section of the jde.ini file, this log file is deleted or saved on successful completion of batch processes. This log file displays different types of messages that can help track errors in the batch process. The messages are:

• Section Level Process

• Object Level Process

• ER Level Process

• DB Level Process

The batch process log can contain ER references, batch process flow, and SQL statements, among other messages. You can use the batch process log file to determine when normal execution stopped.

The batch process log file displays the process flow in batch processes. This example describes the event flow within the batch engine and provides sample messages that would be written to the log at each point in the event flow, assuming UBEDebugLevel is set to 6. Note that each message written to the log file displays the error level of that message in brackets. For example, -UBE--[2]-indicates a section-level message.

When a UBE processes a section, it begins by opening the business view for that section within the INIT section event. As a result, a SELECT statement follows directly after the INIT section for each section.

--UBE--[2]-- 355/392 Process Init Section
--UBE--[2]-- 355/392 InitSection for Business Unit Report Driver
--UBE--[2]-- 355/392 InitSection for Business Unit Report LBH
--UBE--[4]-- 355/392 SELECT T0.MCMCU, T0.MCSTYL, T0.MCLDM, T0.MCCO, T0.MCAN8, 
T0.MCCNTY, T0.MCADDS, T0.MCFMOD, T0.MCDL01, T0.MCDL02, T0.MCDL03, T0.MCDL04, 
T0MCRP01, T0.MCRP02, T0.MCRP03, T0.MCRP04, T0.MCRP05, T0.MCRP06, T0.MCRP07, 
T0.MCRP08, T0.MCRP09, T0.MCRP10, T0.MCRP11, T0.MCRP12, T0.MCRP13, T0.MCRP14, 
T0.MCRP15, T0.MCRP16, T0.MCRP17, T0.MCRP18, T0.MCRP19, T0.MCRP20, T0.MCRP21, 
T0.MCRP22, T0.MCRP23, T0.MCRP24, T0.MCRP25, T0.MCRP26, T0.MCRP27, T0.MCRP28, 
T0.MCRP29, T0.MCRP30, T0.MCPECC, T0.MCALS, T0.MCALCL, T0.MCSBLI, T1.CCCO,
 T1.CCNAME, 
T1.CCRCD FROM F0006 T0,F0010 T1 WHERE ( T1.CCCO=T0.MCCO ) ORDER BY T0.MCCO ASC,
T0.MCMCU ASC

After INIT Section, the engine calls Advance Section to retrieve a record from the SELECT statement:

--UBE--[2]-- 355/392 Process Adv Section
--UBE--[2]-- 355/392 Processing Adv Section for Page Header

After the retrieve, the engine performs the DO Section processing. This includes any event rules attached to the DO Section event:

--UBE--[2]-- 355/392 Process DO Section
--UBE--[2]-- 355/392 Processing DO Section for Page Header
--UBE--[4]-- 355/392 --ER: Line(1): Loading Data Structure for BSFN
--UBE--[4]-- 355/392 --ER: Line(1): Processing BSFN : GetCompanyAndReportDesc
--UBE--[4]-- 355/392 --ER: Line(1): Done Processing BSFN : GetCompanyAndReportDesc
--UBE--[4]-- 355/392 --ER: Line(1): Unloading Data Structure for BSFN
--UBE--[4]-- 355/392 --ER: Line(1): Done Processing ER BSFN

Within DO Section, each object is processed and eventually printed in INIT, DO, and END object order:

--UBE--[3]-- 355/392 Process Init Object
--UBE--[3]-- 355/392 Processing Init Item SystemTime in Section Page Header
--UBE--[3]-- 355/392 Process DO Object
--UBE--[3]-- 355/392 Processing Do Object SystemTime in Section Page Header
--UBE--[6]-- 355/392 Printing Object Value = 14:35:46
--UBE--[3]-- 355/392 Process End Object
--UBE--[3]-- 355/392 Process Init Object
--UBE--[3]-- 355/392 Processing Init Item SystemDate in Section Page Header
--UBE--[3]-- 355/392 Process Do Object
--UBE--[3]-- 355/392 Processing Do Object SystemDate in Section Page Header
--UBE--[6]-- 355/392 Printing Object Value = 3/6/00
--UBE--[3]-- 355/392 Process End Object

After all the objects for a section have been processed, the engine calls Process Last Object and then begins processing for the next section in the report:

--UBE--[3]-- 355/392 Processing Do Object 
ModelAccountsandConsolid in Section Page Header
--UBE--[6]-- 355/392 Printing Object Value = MD
--UBE--[3]-- 355/392 Process End Object
--UBE--[3]-- 355/392 Process Last Object
--UBE--[2]-- 355/392 Process End Page Header Section
--UBE--[2]-- 355/392 Process Do Section
--UBE--[2]-- 355/392 Process Do Section for Business Unit Report Driver

When all sections have been processed, if the report finishes without errors, these messages are displayed at the end of the log:

--UBE--[6]-- Successfully Finishing Engine
...
UBE Job Finished Successfully.

The level of detail provided by the batch process log is controlled by the UBEDebugLevel parameter of the jde.ini file. These are values for UBEDebugLevel:

See Also

Working with Servers

Understanding Executable Files on the Workstation

Understanding Server Administration for iSeries

Viewing Enterprise Server Logs from the Workstation

You must log on to the server to view logs for the server. You can also view portions of log files from the workstation that initiated the calls to the server.

To view server logs from the workstation:

1. In the [DEBUG] section of the enterprise server jde.ini file, set the ClientLog parameter to 1.

   This setting enables the server to send logs to workstations. For example:

    [DEBUG]
   ClientLog=1

2. In the [DEBUG] section of the Workstation jde.ini file, set the ServerLog parameter to 1.

   This setting enables the workstation to receive log information from the enterprise server. For example:

    [DEBUG]
   ServerLog=1

Setting Up the Enterprise Server jde.log

To set up the enterprise server jde.log:

1. Locate the enterprise server jde.log file (JDE member for iSeries) using Server Manager.

   •  

   •  

2. In Server Manager, in the Management Console, select the Logging hyperlink from the Configuration pane.

3. In the Error and Debug Logging pane, enable or disable the logging of errors to the jde.log file by modifying the Enable JDE.LOG field.

   Setting	Purpose
   Enable JDE.LOG	A parameter controls whether the logging function is enabled. Valid values are: Disabled (Default) Enabled

4. Click the Apply button to save the changes.

See Also

8.97 Server Manager Guide on Customer Connection.

Setting Up the Enterprise Server jdedebug.log

To set up the enterprise server jdedebug.log:

1. Locate the enterprise server jdedebug.log file (JDE member for iSeries) using Server Manager.

2. In Server Manager, in the Management Console, select the Logging hyperlink from the Configuration pane.

3. In the Error and Debug Logging pane, verify or change the name for the debug file using the JDEDEBUG.LOG Filename parameter field.

   The JDEDEBUG.LOG Filename specifies the name of the jdedebug.log file (JDEDEBUG member for iSeries). For non-iSeries enterprise servers, the default value is jdedebug.log. For iSeries enterprise servers, the default value is JDEDEBUG.

4. In the Error and Debug Logging pane, enable or disable the logging of errors to the jde.log file by modifying the Enable JDE.LOG field.

   Setting	Purpose
   Enable Debug Logging	A parameter controls whether the logging function is enabled. Valid values are: NONE — No Debug Logging FILE — Enable Debug Logging

5. Click the Apply button to save the changes.

See Also

8.97 Server Manager Guide on Customer Connection.

Setting Up the <batch process>.log File

To set up the <batch_process>.log file:

1. Locate the workstation jde.ini file.

   The JD Edwards EnterpriseOne setup program places this file in the working Windows directory (for example, c:\WINNT40\jde.ini). If you are unsure of the workstation's working Microsoft Windows directory, use the Find command to locate the jde.ini file.

2. Use an ASCII editor (such as Microsoft Notepad or Microsoft Wordpad) to open the file.

3. Set the level of batch report debugging information that you want written to the batch process log file and whether you want the file to be saved.

   These settings are controlled by these parameters in the [UBE] section:

   Setting	Purpose
   UBEDebugLevel=	A parameter that specifies the level of UBE debug logging. Valid values are: 0 (default): No error messages. 1: Warnings and high-level information. 2: Section-level messages (plus Level 1 messages) 3: ER messages and database mapping messages (plus Level 1-2 messages) 4: SQL statements (plus Level 1-3 messages) 5: Database output (plus Level 1-4 messages) 6: Batch process function calls and printed output values (plus Level 1-5 messages)
   UBESaveLogFile=	A parameter that specifies whether the batch_report.log file will be saved. Valid values are: 0: The batch_report.log file is not saved. 1: The batch_report.log file is saved in the workstation's JD Edwards EnterpriseOne print queue directory (E812\PrintQueue).

4. Save the changes and close the jde.ini file.

Troubleshooting the Enterprise Server

This section discusses how to:

• Troubleshoot general problems.

• Troubleshoot communication problems.

• Troubleshoot deadlock collision problems.

• Troubleshoot server map problems.

Troubleshooting General Problems

You can troubleshoot general enterprise server problems using the Server Manager which enables you to monitor server components, processes, and resources.

To troubleshoot general problems:

1. Use Server Manager to verify that you are looking at the correct port and the server is operational on that port.

2. Verify the netTrace setting in the enterprise server jde.ini file:

    [JDENET]
   netTrace=0/1 (disabled/enabled)

   When the variable netTrace=0, JD Edwards EnterpriseOne does not generate Net log information. When netTrace=1, JD Edwards EnterpriseOne generates Net log information.

   Note. Using Server Manager, you can turn logging on or off for a particular kernel process.

3. Return to JD Edwards EnterpriseOne and duplicate the problem.

   The trace facilities write debugging information to the jde.log and jdedebug.log files.

4. After running the business function again, look at the jde.log files on the server.

   Search for these message (you must search for lower case): “jdenet_n process.”

   If you cannot find this message, bring the server down and back up. If you do find this message, look at the jde.log file with the same process ID as the net process.

5. Verify that the user is running in the correct environment or path code; for example PD812 or DV812.

   If this environment is not set up on the server, you receive errors on the workstation jde.log as well as the enterprise server jde.log.

6. In the jde.logs on the enterprise server, look for a JDENET_SendMSg Failed Error=12 message.

   This message means that the JDENET server is down and you must restart it.

7. In the jde.log file on non-iSeries enterprise servers, look for any "Unable to connect to Oracle" messages. Search on ORA-.

   If you find messages, they indicate problems connecting to Oracle. You get an indication of an Oracle connection problem if, in a business function, you select find/browse, data is not found, and no errors are received from the application. You need help from an Oracle database administrator at this point. To debug this problem, see the section in this document about sql.log.

8. Look in the jdexxx.log file (where xxx is the ID of the process that created the log) on the server for these message: “Could not find symbol in the <BSFN dll name>.”

   If present, this message might mean that the business function did not build on the enterprise server.

9. If you have not found a problem indicating why you are unable to run an application on the enterprise server, you will need to debug it on the server.

   Note. For Microsoft Windows enterprise servers, if you cannot identify a problem by reading the log, you need to put the business function through debug on the server. This action requires knowledge of C++ and how to debug. See Microsoft documentation for Debugging C++.

Troubleshoot Communication Problems

When you submit an application to an enterprise server through an override of the master business function set in Object Configuration Manager, you might experience communication problems with the enterprise server. The business function then runs locally on the client workstation. JD Edwards EnterpriseOne displays a window to inform you that the business function is running in a new location.

To troubleshoot communication problems:

Note. Use this procedure if JD Edwards EnterpriseOne displays a window to inform you that a business function is running in a new location.

1. Check the jde.ini on the workstation to make sure the JDENET service name (port number) is correct and valid.

   This port number must match the settings in the server jde.ini file, and the JD Edwards EnterpriseOne server must be running to successfully submit reports or to run business logic on a server. Security services and transaction management services also require the JD Edwards EnterpriseOne server to be running:

    [JDENET]
   serviceNameListen=service name
   serviceNameConnect=service name

   If serviceNameListen=service name specifies the communications service port on the TCP/IP network, JD Edwards EnterpriseOne uses this port address to listen for requests on the network. Using a file called services, you can associate the port number with a unique name. The default value is jde_server (port number 6003).

   If serviceNameConnect=service name specifies the communications service port on the TCP/IP network, JD Edwards EnterpriseOne uses this port address to connect to the network. Using a file called services, you can associate the port number with a unique name. The default value is jde_server (port number 6003).

2. On the workstation, exit JD Edwards EnterpriseOne and turn logging on in the jde.ini.

3. Run the application on the server again, and then check the jde.log file to see if any of these errors are logged:

   • JDENET_SendMsg Failed Error=8

     This error can mean you are not using the correct TCP/IP service port or that the enterprise server does not have that JDENET listing.

   • JDENET_SendMsgFailed Error=5, 11, or 12

     These errors can mean that the message is being sent to the correct port, but the enterprise server JDENET is down.

4. From within Server Manager, change the port address to determine if both the workstation and server are using the same port.

5. Check the services file on the workstation (located in the operating system directory\System32\drivers\etc for Windows).

   Ensure that a blank line exists at the end of the file and that you have the service name mentioned in Step 1 (for example, jde_server) going to the correct port address on the server. Verify the port address with the server administrator.

6. If you receive a Communication Failure message, try resubmitting the application.

   A time-out may have occurred.

    [JDENET]
   netTrace=0/1 (disabled/enabled)

7. Look in the log file for this message:

   Could not find symbol in the <BSFN dll name>

Troubleshooting Server Map Problems

If you change the Object Configuration Manager or the Data Source Master files in the Server Map data source, you can test the changes using the PORTTEST program. This test is designed to validate the environments.

See the section specific to the platform type for more information about the PORTTEST program.

Troubleshooting the iSeries Enterprise Server

This section provides an overview of iSeries enterprises server troubleshooting and discusses how to:

• Troubleshoot iSeries enterprise server installation.

• Troubleshoot multiple release setup.

• Troubleshoot JDBNET.

• Troubleshoot interprocess communications.

• Troubleshoot jde.ini file.

Understanding iSeries Enterprise Server Troubleshooting

This subsection explains how to troubleshoot problems that can occur on an iSeries enterprise server. When troubleshooting, follow these guidelines:

• Try to narrow the definition of any problem that you have, particularly when communicating the issue to someone, such as JD Edwards Worldwide Customer Support Services.

  For example, rather than reporting that the batch application failed, explain how the batch application failed. The more specific the information, the faster the problem can be solved. Rather than reporting that "The report had the wrong data," say that "The batch status is E."

• When communicating an error message to someone, be sure to include all parts of the error message exactly as they appear in the log file or on the screen.

  Parts of the message that might not seem important might actually hold the key as to why an error occurs. Also, distinguish between characters that might be misinterpreted, for example, the capital letter "O" and the numeral zero.

• As soon as you notice an error, examine the log files.

  Messages near the end of the log files sometimes reveal the most important information about the cause of the error.

• Before you restart JD Edwards EnterpriseOne on the server, either delete or move all the files from the log directories. Refer to the JDE.INI file for the locations of the log files.

• When you first try to get JD Edwards EnterpriseOne running, verify that you have logging turned on. Examine the jde.log and jdedebug.log files carefully.

• Carefully examine the JOBLOGs and jde.log files of the JD Edwards EnterpriseOne jobs to ensure that authorities and OCM are set correctly. Look for messages such as these in the jde.log files:

  JDB3100011 - Failed to get location of table F983051 for environment PD812
  Look for messages similar to these in the JOBLOGs:
  File F98306 not found in library PRODDTA.

You might want to temporarily modify the job description of the JD Edwards EnterpriseOne user profile to always write the joblog until you are satisfied that all setup is correct.

Note. To complete the resolutions provided for this issues, you must sign on to the enterprise server using an account that has administrative privileges.

Troubleshooting iSeries Enterprise Server Installation

This section explains topics that might create issues during the installation of an iSeries enterprise server.

Troubleshooting: Library Installation Verification

Troubleshooting: Database Table Configuration

Troubleshooting: Setting up the iSeries .INI File

Troubleshooting: You Cannot Find the Log Files

The logging is performed to the iSeries Integrated File System (IFS). The naming convention is similar to that of the UNIX enterprise servers. That is, the default names of the files are JDE_AS400JobNumber.log, JDEDEBUG_AS400JobNumber.log, and JDETS.LOG, where AS400JobNumber is the iSeries Job Number of the job that generated the file. The system creates these files automatically, but the path to the files must exist before logging begins. The created log file directory should match the JOBLOG and JDELOG settings in the JDE.INI file.

The path to the log files stored in the IFS can be created by performing successive calls to the iSeries command MKDIR. For example, to create the path /PSFT812/LogFiles, enter this command:

MKDIR DIR('/PSFT812') DTAAUT(*RWX) OBJAUT(*ALL)

Followed by:

MKDIR DIR('/PSFT812/LogFiles') DTAAUT(*RWX) OBJAUT(*ALL)

Logging might be turned off in the .INI. Activate logging in the .INI using these settings in the [DEBUG] section:

[DEBUG]

LogErrors=1

Output=FILE

Where variable names and descriptions are as follows:

LogErrors values are:

0 = Do not generate logs.

1 = Create logs.

Output values (always in upper case) are:

NONE = Do not write debug messages to any output device.

FILE = Write messages to log files.

Troubleshooting: Not Enough Relevant Information Is Written to the Log Files

Additional logging information may need to be turned on in the .INI. Set these keys in the .INI for additional information to be output to the log files:

[JDENET]

netTrace=1

[JDEIPC]

ipcTrace=1

[DEBUG]

TAMTraceLevel=1

[UBE]

UBEDebugLevel=6

[TCEngine]

TraceLevel=10

Where variable names and descriptions are as follows:

netTrace values are:

0 = Do not generate JDENet error messages (that is, communication between platforms).

1 = Generate JDENet error messages.

ipcTrace values are:

0 = Do not generate Interprocess Communication (IPC) error messages (that is, communication between processes on a single platform).

1 = Generate IPC error messages.

TAMTraceLevel values are:

0 = Do not generate Table Access Management (TAM) error messages (that is, regarding specification files).

1 = Generate TAM error messages.

UBEDebugLevel values are:

0 = Do not generate batch application error messages.

1-6 = Generate increasingly detailed error messages (1 indicates the least specific message; 6 indicates the most detailed message).

TraceLevel values are:

0 = Do not generate Table Conversion (TC) error messages.

1-10 = Generate increasingly detailed error messages (1 indicates the least specific message; 10 indicates the most detailed message).

Note. Because NetTrace and ipcTrace messages are written to the debug log associated with that job, the [DEBUG] section of the jde.ini file requires the Output=FILE setting.

Troubleshooting: Testing with PORTTEST

In general, activate logging when running the PORTTEST program. Review the jde.log and jdedebug members generated by running the PORTTEST program. Also review the iSeries job log generated by running the PORTTEST program. These logs provide valuable information about the JD Edwards EnterpriseOne iSeries configuration and setup.

Troubleshooting: Running JDENET

Troubleshooting: Testing JD Edwards EnterpriseOne by Submitting a Report

Troubleshooting: Shutting Down JDENET

Running the iSeries command CLRIPC immediately after shutdown (that is, after running the iSeries command ENDNET) each time you shut down will help you avoid most restart problems.

Troubleshooting: Email and PPAT

See Also

Understanding the iSeries Library Structure for JD Edwards EnterpriseOne

Troubleshooting the JDE.INI File

Troubleshooting Multiple Release Setup

This table explains how to troubleshoot problems that can occur with multiple releases on the iSeries:

Troubleshooting JDBNET

This table explains how to troubleshoot problems that can occur with JDBNET:

Troubleshooting Interprocess Communications

This subsection explains how to troubleshoot problems that can occur with Interprocess Communication (IPC).

Troubleshooting the JDE.INI File

This section explains how to troubleshoot problems that can occur with the JDE.INI file. These notes apply to the .INI file in the E812SYS library:

• It is composed of several sections.

  The section names are enclosed in square brackets, for example [JDENET].

• Within each section are one or more keys or settings.

  The key name is on the left side of the equals sign, and the value of the key is on the right side.

• Do not include spaces in the names or values of the keys unless you know that a space is required.

  Do not include spaces immediately before or after the equals sign.

• Keys may be commented out by adding a semicolon (;) at the start of the key name.

• We recommend that you place any incidental comments on a separate line adjacent to the key to which the comment applies.

  Be sure to include a preceding semicolon. Comments can be included at the end of the key's values, but these comments can be wrongly interpreted if they are not separated from the keys' values by enough white space. Because the amount of white space needed between the keys' values and the comments is not strictly defined, we recommend that you do not place comments after the values of the keys.

• The section and key names are not case sensitive.

• Many key values are case sensitive.

• Although all of the following values may be used to turn a feature on, they may not be interchangeable as values in the .INI. Use a value that is comparable to the default value provided in the original .INI. Also, many values are case sensitive. If you have any questions about values, contact JD Edwards Global Support Center.

  • YES

  • ON

  • TRUE

  • 1

Likewise, these values may be used to turn a feature off. They are not necessarily interchangeable as values in the .INI.

• NO

• OFF

• FALSE

• NONE

• 0

If you are told by JD Edwards Worldwide Customer Support Services to modify a key that does not exist, you can add the key. Just be sure that it is in the correct section.

Troubleshooting the UNIX/Linux Enterprise Server

This section provides an overview for UNIX/Linux enterprise server troubleshooting and discusses how to:

• Troubleshoot the jde.ini file.

• Troubleshoot JD Edwards EnterpriseOne file copying to a server.

• Troubleshoot database table configuration.

• Troubleshoot printer setup.

• Troubleshoot email.

• Troubleshoot multiple release setup.

• Troubleshooting report file output location.

• Troubleshoot JDBNET server not found.

• Troubleshoot JD Edwards EnterpriseOne testing.

Understanding UNIX/Linux Enterprise Server Troubleshooting

This section discusses some typical problems that you might encounter and their solutions. When troubleshooting, follow these guidelines:

• Check the logs.

  Many times, the logs point to the problem. As soon as you notice an error, examine the log files. Messages near the end of the log files will probably reveal the most important information about the cause of the error.

• Try to narrow down the definition of any problem that you may have, particularly when communicating the issue to someone, such as JD Edwards Worldwide Customer Support Services.

  For example, rather than reporting that the batch application failed, explain how the batch application failed. The more specific the information, the faster the problem can be solved. For example, rather than reporting that "The report had the wrong data," say that "The batch status is E."

• When communicating an error message to someone, include all parts of the error message exactly as they appear in the log file or on the screen.

  Parts of the message that may not seem important may actually hold the key as to why an error occurred. Also, distinguish between characters that might be misinterpreted, such as the capital letter O and the numeral zero (0).

• Before you restart JD Edwards EnterpriseOne on the server, either delete or move the jde_xxx.log and jdedebug_xxx.log files (where xxx is a number).

  Do not rename the log files because it is easier to work with logs that use the standard naming convention (jde_xxx.log and jdedebug_xxx.log). If you need to save the log files until the problem is solved, then create a temporary directory and move the files.

• Clear the log directory regularly to avoid filling the file system.

  If the file system fills up, then the specification files can become corrupted.

• Always keep a backup of the specification files handy in case they become corrupted.

  Specification files should be backed up regularly for easy recovery of specification installs. If spec files have to be replaced, all specification installations will be lost if backups are not kept.

• To find problems that occur due to server failure, go to the system/bin32 directory:

  grep -n failed *log* > problems.txt

  The file problems.txt will contain a list of errors with the file and line number.

• Remember that UNIX is case-sensitive: jde.ini is not the same file as JDE.INI.

  Important! To complete the resolutions provided for this issues, you must sign on to the UNIX enterprise server using an account that has administrative privileges.

Troubleshooting the JDE.INI File

To locate the JDE.INI file, search in the system/bin32 subdirectory. For example, /u01/JDEdwards/E812/ini/JDE.INI. These notes apply to the JDE.INI:

• It is composed of several sections.

  The section names are enclosed in square brackets; for example, [JDENET].

• The environment variable $JDE_BASE should contain the location of the JDE.INI file.

• If you copy the JDE.INI file to other directories (for example, the $SYSTEM/bin32 directory), the JD Edwards EnterpriseOne programs could read the wrong JDE.INI file.

  This error occurs because some programs might look for the JDE.INI file in the current directory before looking at the JDE_BASE environment variable.

• Each section contains one or more keys.

  The key name is on the left side of the equal sign, and the value of the key is on the right side.

• Do not include spaces in the key names or key values unless you know that a space is required.

  Do not include spaces immediately before or after the equal sign.

• Keys can be commented out by adding a semicolon (;) at the start of the key name.

• We recommend that you place incidental comments on a separate line adjacent to the key to which the comment applies.

  Be sure to include a preceding semicolon. Comments can be included at the end of the key value, but these comments can be incorrectly interpreted if they are not separated from the values of the keys by sufficient white space. Because the amount of white space between the values of the keys and the comments is not strictly defined, we recommend that you do not place comments after the values of the keys.

• Section and key names are not case sensitive.

• Many key values are case sensitive.

• Although all of the following values activate a feature, they may not be interchangeable as values in the JDE.INI.

  Use a value that is comparable to the default value provided in the original JDE.INI. Also, many of these values are case sensitive. If you have any questions about values, contact JD Edwards Worldwide Customer Support Services.

  • YES

  • ON

  • TRUE

  • 1

These values turn a feature off. They are not necessarily interchangeable as values in the JDE.INI.

• NO

• OFF

• FALSE

• NONE

• 0

If you are told by JD Edwards Worldwide Customer Support Services to modify a key that does not exist, you can add the key. Ensure that the key is in the correct section and entered with the correct spelling and case.

Troubleshooting JD Edwards EnterpriseOne File Copying to a Server

If you cannot copy files from the deployment server to the temporary directory on the enterprise server, this could be because ftp cannot connect. See the system administrator.

Troubleshooting Database Table Configurations

If results or errors occur that imply that OCM is not set up correctly, review the description in this guide of how OCM is used by JD Edwards EnterpriseOne.

Troubleshooting Printer Setup

If reports do not print from a server, verify the name of the default printer. Send a simple text file to the default printer using the lp command. If you get an error similar to these, then the printer is not configured on the server or is not online:

"lp: destination aPrinter non-existent"

Contact the system administrator for assistance.

For Linux, do not set up a print queue that translates files to postscript. The Linux print queues that are used by JD Edwards EnterpriseOne should generally be "raw" print queues that simply redirect the output of the file to the printer.

Troubleshooting Email

If the report, server package installation, or table conversion log file (in the PrintQueue directory) displays the message DoSendMessage Error: User 5600427 does not exist in the address book file (F0101), the particular user might not be found in the F0101 table. Add the user to the F0101 table.

Troubleshooting Multiple Release Setup

Each installed release of JD Edwards EnterpriseOne has its own JDE.INI in its ini directory. Point the user entries in the JDE.INI files to the directories of the log and other files. If the log files do not go to separate directories, change the appropriate keys in one or both JDE.INI files to point to unique directories for each installed instance of JD Edwards EnterpriseOne.

Troubleshooting Report File Output Location

If you cannot find the report output files, consider this information:

• The location is specified as the OutputDirectory key of the [NETWORK QUEUE SETTINGS] section in the JDE.INI on the server.

  If this key is not found, the location is the PrintQueue subdirectory of the JD Edwards EnterpriseOne base directory (for example, /u01/JDEdwards/E812SYS/PrintQueue).

• The JDE.INI file on the workstation may have the SaveOutput key of the [NETWORK QUEUE SETTINGS] section set to FALSE.

  This is because a problem after the report has been printed. After the report is printed, then the record will be deleted, as will the .PDF file. Change the value of the SaveOutput key of the [NETWORK QUEUE SETTINGS] section in the JDE.INI on the workstation to TRUE.

Troubleshooting JDBNET Server Not Found

If you get an error that the data source on the JDBNET server is not found, the correct data source on the JDBNET server might not exist. Create a data source on the server that will be used by JDBNET. This is a normal configuration for a server data source that can be accessed by JDENet running on that server. Note the data source name (OMDATP) that will be used for the JDBNET client configuration.

If you get an error that the data source on the JDBNET client is not found, the correct data source on the JDBNET client might not exist. Create a JDBNET data source in the F98611 table using this information:

• Data source name (OMDATP field).

  Used to access tables as specified in the F986101 table.

• Server name (OMSRVR field).

  Identifies the JDBNET server.

• Database name (OMDATB field).

  Matches exactly the data source name (that is, the OMDATP field) to be used by the JDBNET server.

• Shared library name (OMDLLNAME field).

  Identifies the JDBNET client .DLL. (libjdbnet.sl on HP-UX, libjdbnet.so on AIX).

• All other columns must match the values in the corresponding columns of the server data source.

Set this data source as an active override in the F986101 table for all tables that will be accessed through JDBNET.

Troubleshooting JD Edwards EnterpriseOne Testing

If the PORTTEST program does not run successfully after startup:

• If you have Oracle or UDB running on the enterprise server and the database and JD Edwards EnterpriseOne services are set to start automatically at system startup, JD Edwards EnterpriseOne services may start before the database is running completely.

  You must ensure that the database software is running before starting any JD Edwards EnterpriseOne processes.

• If JD Edwards EnterpriseOne loses the connection to the database because either the network or database went down, you should see some sort of network or database error in the log files.

• Stop the JD Edwards EnterpriseOne services, clear the logs, and then restart the JD Edwards EnterpriseOne services to see if the problem is resolved.

Troubleshooting the Microsoft Windows Enterprise Server

This section provides an overview of Microsoft Windows enterprise server troubleshooting and discusses how to:

• Troubleshoot JD Edwards EnterpriseOne account setup.

• Troubleshoot JD Edwards EnterpriseOne file copying to a server.

• Troubleshoot database table configuration.

• Troubleshoot printer setup.

• Troubleshoot jde.ini file setup.

• Troubleshoot finding the log files.

• Troubleshoot testing with the PORTTEST program.

• Troubleshoot running JD Edwards EnterpriseOne manually.

• Troubleshoot finding report files.

• Troubleshoot testing JD Edwards EnterpriseOne by submitting a report.

• Take ownership of a printer.

• Stop all JD Edwards EnterpriseOne processes.

• Stop all JD Edwards EnterpriseOne processes without rights.

• Troubleshoot email.

Understanding Microsoft Windows Enterprise Server Troubleshooting

This section discusses some typical problems that you might encounter and their solutions. When troubleshooting, follow these guidelines:

• Narrow the definition of any problem that you might have, particularly when communicating the issue to someone, such as JD Edwards Worldwide Customer Support Services.

  For example, rather than reporting that the batch application failed, explain how the batch application failed. The more specific the information, the faster the problem can be solved. For example, rather than reporting that "The report had the wrong data," say that "The batch status is E."

• When communicating an error message to someone, be sure to include all parts of the error message exactly as they appear in the log file or on the screen.

  Parts of the message that may not seem important may actually hold the key to why an error occurs. Also, distinguish between characters that might be misinterpreted (for example, the capital letter O and the number 0).

• As soon as you notice an error, examine the log files.

  Messages near the end of the log files sometimes reveal the most important information about the cause of the error.

• Before you restart JD Edwards EnterpriseOne on the server, either delete or move the jde_xxx.log and jdedebug_xxx.log files (where xxx is a number).

  Do not rename the log files; it is easier to work with logs that use the standard naming convention (jde_xxx.log and jdedebug_xxx.log). If you need to save the log files until the problem is solved, create a temporary directory and move the files there.

• Clear the log directory regularly to avoid filling the file system. If the file system fills up, the specification files become corrupt.

• Always keep a backup of the specification files in case they become corrupt.

  Specification files should be backed up regularly for easy recovery of spec installs. If specification files have to be replaced, all specification installations are lost unless backups are kept.

  Note. To complete the resolutions provided for this issues, you must sign on to the Microsoft Windows enterprise server using an account that has administrative privileges.

Troubleshooting JD Edwards EnterpriseOne Account Setup

If you cannot set up any accounts in the User Manager program, the account you are logged into in Microsoft Windows may not have the privileges to modify or add accounts. Log out of Microsoft Windows and log back on under the Administrator account or an account in the Administrators group.

Troubleshooting JD Edwards EnterpriseOne File Copying to a Server

If you cannot copy files from the CD to the JD Edwards EnterpriseOne directory on the enterprise server, verify that the CD is in the CD-ROM drive. Another cause is that one or more of the files to be copied is currently open on the CD:

• Close any files on the CD that are open.

• Close any applications that may have files open on the CD.

If one or more of the files that will be overwritten in the target directory is open:

• Close any files in the target directory that are open.

• Close any applications that may have files open in the target directory.

If the target disk is full:

• Delete or move files from the target disk.

• Copy JD Edwards EnterpriseOne to a different disk.

Troubleshooting Database Table Configuration

If the OCM is not set up correctly and errors occur, run the VerifyOCM program to ensure that the OCM tables are set up correctly.

Troubleshooting Printer Setup

If you cannot set up a printer:

• The printer may not be attached (local printer) or the print server may not be available (network printer).

  Attach to the local printer or determine why the print server is not available.

• The printer drivers may not be installed.

  Install the correct printer drivers.

Troubleshooting jde.ini File Setup

If you cannot find the jde.ini file:

• Search in the system\bin32 subdirectory in the JD Edwards EnterpriseOne tree. For example, z:\JDEdwards\E812\ddp\system\bin32\ jde.ini.

• Make sure you have access rights to the system\bin32 directory by logging on to Microsoft Windows as a user who has administrative rights.

Troubleshooting Finding the Log Files

If you cannot find the log files:

• Log files are listed in the DebugFile and JobFile keys in the [DEBUG] section of the jde.ini.

  If there are no paths, the logs are in the system\bin32 directory. The log files are named according to these scheme:

  An underscore (_) and the process ID of the process that creates the log file are inserted before the period for example, jde_123.log or jdedebug_123.log for a process with an ID of 123.

  The log file associated with the DebugFile key contains the sequence of JD Edwards EnterpriseOne events. The default value for this key is jdedebug.log. The log file associated with the JobFile key contains error messages that occur in JD Edwards EnterpriseOne. The default value for this key is jde.log.

• When a batch application is run and the jde.ini on the workstation has [NETWORK QUEUE SETTINGS] SaveOutput=TRUE, the jde_xxx.log and jdedebug_xxx.log files for the runbatch that processed the batch application is copied to a file in the PrintQueue directory.

  The root name of the files are the same as the name of the PDF file. The extension is .jde.log and .jdedebug.log. The duplication of these log files does not occur if the batch application runbatch.exe dies before duplication.

• Verify that logging in the jde.ini is turned on using these settings in the [DEBUG] section:

  [DEBUG]
  LogErrors=1
  Output=FILE
  Variables and their descriptions:
  LogErrors
  0 = Do not generate logs.
  1 = Create logs.
  Output
  NONE = Do not write messages to any output device.
  AUX = Write messages to a console window.
  FILE = Write messages to log files.
  BOTH = Write messages to log files and console window.

If not enough relevant information is written to the log files, this could be because additional logging information needs to be turned on in the jde.ini. Set these keys in the jde.ini for additional output to the log files:

[JDENET]
netTrace=1
[JDEIPC]
ipcTrace=1
[DEBUG]
TAMTraceLevel=1
[UBE]
UBEDebugLevel=6
[TCEngine]
TraceLevel=10

These are the variables that you use to set logging options::

• netTrace

• 0 = Do not generate JDENet error messages (that is, communication between platforms).

• 1 = Generate JDENet error message.

• ipcTrace

• 0 = Do not generate Interprocess Communication (IPC) error messages (that is, communication between processes on a single platform).

• 1 = Generate IPC error messages.

• TAMTraceLevel

• 0 = Do not generate Table Access Management (TAM) error messages (that is, regarding specification files).

• 1 = Generate TAM error messages.

• UBEDebugLevel

• 0 = Do not generate batch application error messages.

• 1 = Generate increasingly detailed error messages (1 gives the least specific messages, whereas 6 gives the most detailed messages).

• TraceLevel

• 0 = Do not generate Table Conversion (TC) error messages.

• 1-10 = Generate increasingly detailed error messages (1 gives the least detail, whereas 10 gives the most detail).

Troubleshooting Testing with the PORTTEST Program

If an error with the security server occurred:

• Verify the JD Edwards EnterpriseOne network is running either as a service or started from a command prompt.

• If the security server is inactive, or if it is active on a server and port that is different from the ones the PORTTEST program uses, perform one of these tasks:

  Start JD Edwards EnterpriseOne net on the server and port where the PORTTEST program is being run. The security server key in the [SECURITY] section of the jde.ini specifies the security server, and the serviceNameListen and serviceNameConnect settings in the [JDENET] section specify the ports.

  Change the name of the security server or the names of the ports, or both, in the jde.ini file to point to the correct security server.

• Make sure that the JD Edwards EnterpriseOne network and the PORTTEST program are running under the same account:

  To determine under which account PORTTEST is running, press the Control, Alt, and Delete keys at the same time. If the JD Edwards EnterpriseOne network is running as a service, determine under which account it is running. To do this, select the service in Microsoft Windows Control Panel, then go to Services and click Startup.

  For initial testing, you can stop the JD Edwards EnterpriseOne network service, open a Windows command prompt, cd to the system\bin32 directory, run jdenet_n without any parameters, and rerun the PORTTEST program. When finished, stop jdenet_n from the Microsoft Windows Task Manager.

  To run the PORTTEST program under the same account as the JD Edwards EnterpriseOne network service, log out of Windows, log into the same account under which the service is running, open a Microsoft Windows command prompt, cd to the system\bin32 directory, and rerun the PORTTEST program.

• To make sure the supplied user name and password, or both, match names and passwords, or both, in the JD Edwards EnterpriseOne security table:

  Run the PORTTEST program with a valid user name and password. Add the given user name and password to the JD Edwards EnterpriseOne security table.

If you get the message Invalid parms PORTTEST: <USER> <PWD> <ENV>, the correct number of arguments to PORTTEST may not have been included. Use these arguments:

• User - A valid JD Edwards EnterpriseOne account name.

• Password - Password for the JD Edwards EnterpriseOne account.

• Environment - A valid JD Edwards EnterpriseOne environment.

• Fewer than 99 records are written to the screen by PORTTEST.

If PORTTEST failed, examine the log files.

If fewer than 99 records exist in the F0902 table, this is not an error. You should review the log files for errors.

If the F0902 table is not accessible, verify that you can query the F0902 table using SQL.

If an error initializing the environment occurs in the log file, the environment may not have been set up correctly. See the chapter Understanding the JD Edwards EnterpriseOne Initialization for Windows in this guide for more information about how JD Edwards EnterpriseOne programs use OCM. Any errors in the affected jde.ini keys or database tables could cause the JD Edwards EnterpriseOne initialization to fail. The environment that PORTTEST uses is passed as a command line argument.

Troubleshooting Running JD Edwards EnterpriseOne Manually

• If the JD Edwards EnterpriseOne network is not running, start the JD Edwards EnterpriseOne network service.

• Verify the JD Edwards EnterpriseOne network is running by doing these:

  • The JD Edwards EnterpriseOne network should either be running as a service or from a Windows command prompt.

  • If it is running as a service, determine under which account it is running.

    To do this, select the JD Edwards EnterpriseOne network service in Microsoft Windows Control Panel, select Services, and then select Startup. Note the account name. If you are using Microsoft Windows 2000, select the JD Edwards EnterpriseOne network service in the Windows Control Panel, select Services, and then select Properties.

  • If it is run from a command prompt, the network is running under the Microsoft Windows account you signed on to.

    When you log off Microsoft Windows, network processes started from a command prompt and all child processes will terminate.

• If the setup of some part of JD Edwards EnterpriseOne, such as the jde.ini file or OCM, is incorrect, determine if PORTTEST runs correctly.

  If not, correct those problems and then try running JD Edwards EnterpriseOne manually.

If an error initializing the environment occurs in the log file, the setup for some part of JD Edwards EnterpriseOne, such as the jde.ini file or OCM, may be incorrect. Examine the applicable problems in the “Testing with the PORTTEST Program” section in this chapter. Determine if the PORTTEST programs runs correctly. If not, correct those problems, and then try running JD Edwards EnterpriseOne manually.

Troubleshooting Finding the Report Files

If you cannot find the report output files:

• Check the OutputDirectory key of the [NETWORK QUEUE SETTINGS] section in the jde.ini file on the server.

  If there is no location, listed, the files are in the PrintQueue directory of the JD Edwards EnterpriseOne base directory. For example, z:\JDEdwards\E812\ddp\PrintQueue.

• Verify that SaveOutput in the [NETWORK QUEUE SETTINGS] section in the jde.ini file on the workstation is TRUE.

Troubleshooting Testing JD Edwards EnterpriseOne by Submitting a Report

• If a time-out occurred because the JD Edwards EnterpriseOne server was started after the client, resubmit the report.

• If a time-out occurred due to heavy network traffic or server load, increase the time-out value in the jde.ini file on the workstation and resubmit the report.

  Use the JDENETTime-out setting in the [NETWORK QUEUE SETTINGS] section.

• If the wrong communications port is being used, perform one of these tasks:

  • Verify that the serviceNameListen value in the [JDENET] section of the jde.ini file on the workstation matches the serviceNameConnect value in the [JDENET] section of the jde.ini file on the server.

    In addition, the serviceNameConnect value in the jde.ini file on the workstation must match serviceNameListen in the jde.ini file on the server. If the values of these keys are strings, the numeric value is retrieved from the services file in the c:\winnt\system32\drivers\etc directory (Microsoft Windows: client or server).

  • The services file contains a list of strings and their corresponding port numbers.

    If the port that you are interested in is on the last line of the services file, be sure to include a return at the end of the line or else the string will not be translated to the corresponding port number.

• If the client is using Dynamic Host Configuration Protocol (DHCP) and the server does not have an entry for itself in its hosts file in the c:\winnt\system32\drivers\etc directory, add an entry for the server in the hosts file on the server.

• These situations can occur:

  • Communications failure error message on the workstation.

  • Restarting Network Service or jdenet_n sometimes gets rid of the error.

  • You can ping the server from the workstation.

  These issues can occur because the server has two network cards, which confuses JDENET when the net communications are initialized between the client and server. One machine tries to connect using one network card, and the other machine connects using the other network card.

  The hosts file on the server should list two different IP addresses for the server--one for each network card. Resolve the error by setting the NetHostName field in the [JDENET] section of the jde.ini to one of the names for the server given in the hosts file. JDENET then uses the IP address associated with the given network card.

• For the error cannot connect to printer in the jde_xxx.log or the log file in the PrintQueue subdirectory:

  • If a general printing error occurred, try to print a text document from Notepad.

    Resolve any issues.

  • If no default printer is set up on the enterprise server, set up a printer using the task Add a new printer or Modify an existing printer in the JD Edwards EnterpriseOne Tools 8.94 Implementation Guide: System Administration.

  • If you do not have privileges to the printer, define the owner as a local or network account.

    The type of account depends on the type of printer. If the printer is a local printer, the owner could be either a local or network account but either type must have privileges to access the printer. If the printer is a network printer, the owner must be a network account with access privileges.

• All jobs sent to this printer using the current server will conform to the selected orientation.

  Note that the report template or other programs may override this default orientation. If you cannot change the printer orientation, you may not have the right to change the orientation. Log on to Microsoft Windows in an account that has administrative rights for the printer. For a local printer, use an account that has administrative privileges. For a network printer, use an account given administrative privileges by a network administrator.

  If the report does not list any data, the data may not exist in the database for the report that you are running, or you do not have access to the data. Perform one or more of these tasks to resolve the data issue:

  • Select a different report.

  • Add data to the database.

  • Change the processing options for the report.

  • Change the OCM and data sources to point to the correct database.

• If the report is launched on the server, verify the vertical tables in the server OCM match those in the workstation OCM.

  If you believe data should have been found, edit the report jdedebug.log found in the PrintQueue subdirectory.

  Search for the SQL select statement used to retrieve data from the database. You must have some idea what data is being read to do this.

  • Copy the SQL statement.

  • Open the specific database SQL command interface - for example, SQL Plus or ISQL_w.

  • Paste the SQL statement into the SQL command interface.

  • Submit the SQL statement.

• If no data is found, one of these conditions may be true:

  • No data exists.

  • The processing options are incorrect.

  • The OCM for either the client or server is pointing to the wrong data source.

  • The data sources for either the client or server are pointing to the wrong database.

  • The SQL statement is incorrect (possibly due to a program bug).

  • The database drivers are out of date.

  • If an error occurred with the report, look in the jde_xxx.log for error messages.

• If an error initializing the environment occurs in the log file, the environment may not be set up correctly.

  Stop JD Edwards EnterpriseOne and determine if the PORTTEST program runs correctly. If not, correct those problems and then run JD Edwards EnterpriseOne manually.

Taking Ownership of a Printer

To take ownership of a printer:

1. From the Microsoft Windows Start menu, select Settings, Printers.

2. Right-click the desired printer.

3. Select Properties,, and then select the Privileges tab.

4. Click Ownership and Take Ownership.

   If the printer drivers are not installed, see the section Database Driver Files in this guide for information about which drivers you need.

   If the report printouts are in portrait mode but should be in landscape mode (or vice versa), verify that the orientation specified in RDA for the report is correct.

   If the default printer is set to the wrong orientation, set the orientation using these task:

5. From the Microsoft Windows Start menu, select Settings, Printers.

6. Right-click the desired printer.

7. Select Document Defaults.

8. Select the desired default orientation.

9. Click OK.

Stopping All JD Edwards EnterpriseOne Processes

If you need to stop the JD Edwards EnterpriseOne processes that you started from the command prompt, for example, jdenet_n, stop any of these processes that are running:

• Jdenet_n.exe

• Jdenet_k.exe

• Runbatch.exe

• ipcsrv.exe

These additional processes, such as jdenet_k and runbatch, are started by jdenet_n and queue kernel.

To stop all JD Edwards EnterpriseOne processes:

1. Run the Microsoft Windows Task Manager.

2. Select the Processes tab.

3. Select one of the running processes.

4. Click End Process.

5. Repeat for each process to be stopped.

Stopping JD Edwards EnterpriseOne Processes Without Rights

Use this task if you do not have the rights to stop the processes.

To stop JD Edwards EnterpriseOne processes without rights:

1. Log on to Microsoft Windows in an account that has rights to stop processes.

2. Stop processes using Visual C++.

3. Run the Microsoft Windows Task Manager.

4. Select the Processes tab.

5. Select one of the running processes.

6. Click Debug Process.

   Visual C++ starts.

7. Click the X in the upper right-hand corner to close Visual C++.

   Do not save the project workspace. This ends the runaway process.

8. Repeat these steps for each runaway process.

   If they still do not end, reboot the machine.

Troubleshooting Email

If the report, server package installation, or table conversion log file in the PrintQueue directory displays the message DoSendMessage Error:

User 5600427 does not exist in the address book file (F0101).

This could be because the particular user is not found in the F0101 table. Add the user to the F0101 table.

Troubleshooting Web Servers

This section provides an overview of web server troubleshooting and discusses how to:

• Troubleshoot IIS and IBM HTTP web servers.

• Troubleshoot JAS.

• Troubleshoot serialized database and generation issues.

• Troubleshoot SQL server issues.

• Troubleshoot problems using log files.

Understanding Web Server Troubleshooting

This section discusses some typical issues you might encounter when using WebSphere and Java Application Server (JAS). It also explains other issues you might encounter with web servers and how to track down problems by using the log files in Server Manager.

Troubleshooting IIS and IBM HTTP Web Servers

If you need to configure with IIS and an IBM HTTP Server, refer to the installation documentation.

If you receive the message Recursive error - page not found, you need to make sure IIS is running for a particular instance of JAS. IIS instances can be stopped easily, and the user may forget to restart them. To make sure IIS is running for the particular instance of JAS, verify IIS instance properties by selecting the appropriate instance, and then right-clicking and choosing Properties. Confirm that the correct paths are listed for the desired JAS code.

Troubleshooting JAS

If no logs appear, verify that the [LOGS] setting in the jas.ini has logging turned on and points the log files to reside in the desired location (for example, ;log=d:\E812\internet\jas.log or ;debuglog=d:\E812\internet\jasdebuglog). If the log file paths are not correctly stipulated, the logs may be writing to a file located elsewhere.

If JAS seems slow, check to see whether jdbcTrace is set to TRUE or FALSE. If tracing is turned on or set to TRUE, the additional logging will dramatically slow JAS performance.

Troubleshooting Serialized Database and Generation Issues

If you receive the message “Form is out of date...most likely needs to be regenerated,” this error usually occurs because the specifications used to construct the serialized database do not match the JAS code. Ensure that the date the JAS code was written matches the date of the jdecom.dll that resides in the E812\system\bin32 directory of the generating machine.

Also be sure to register the jdecom.dll. After you run the regsvr32 jdecom.dll command, the eGenerator recognizes the jdecom.dll and uses it to fetch JD Edwards EnterpriseOne specs and convert them into Java serialized objects.

If the menu does not appear when the user signs on to JD Edwards EnterpriseOne, check for these conditions:

• [JDBC URL] section in jde.ini is set correctly or [JDBC DRIVERS] is set correctly.

  The [JDBC URL] points to the serialized database (the one you just set up).

• Bounce the WebSphere application server.

  Menus are cached, and by bouncing the server you clear the cached information.

• Ensure that the host database for serialized objects is running.

Troubleshooting SQL Server Issues

If SQL Server process or Oracle process consumes excess CPU in a web server environment, the serialized objects for the web server are stored in either SQL server or the Oracle database. The web server must access these tables frequently when running an application. Indexes may be missing, which can cause severe performance problems.

Ensure that all existing JD Edwards EnterpriseOne indexes are created for tables F989998 and F989999. You should have one index for F989998 for columns WBJOBID and WBOID. You should also have one index for F989999 for columns WBUID, WBOID, WBLNGPREF. If these indexes do not exist in the database, generate them using Object Librarian.

Add a new index to the F989999. This index should include columns WBOID, WBUID, and WBJVER. Generate this index over the F9899999 table.

Update statistics on both tables as follows:

• For Oracle, issue these commands in SQL *Plus:

  ANALYZE TABLE owner.F989999 COMPUTE STATISTICS

• For SQL Server, issue these commands:

  UPDATE STATISTICS owner.F989999
  UPDATE STATISTICS owner.F989998

Improvements vary depending on the number of users accessing the serialized database.

Troubleshooting Problems Using Log Files

If you need to view logging information for the Java client, open the Java Console by choosing Java Console from the View menu in Internet Explorer. The Java Console displays all problems that the Java Virtual Machine on the client is having. Errors appear as uncaught exceptions in the console.

Note. You must have the appropriate internet options turned on to view the Java Console.

To enable the Java Console in Internet Explorer, select Tools, and then select Internet Options. In Internet Options, click the Advanced tab, scroll down to the section titled Java VM, and select these options:

• Java Console enabled.

• Java logging enabled.

• JIT compiler for virtual machine enabled.

If you need to troubleshoot errors in web applications:

• Verify that the problem is only a problem on the web.

  Test the fat client version of the same application against the same enterprise server that the web is using. Make sure that you use the same JD Edwards EnterpriseOne accounts and environments.

• Determine whether the problem happens in HTML, Java, or both.

  Since both Java and HTML use the Java runtime engine, they should behave the same. Some variation exists based on the inherent differences between the Portal, HTML page processing and Java interactive processing, but underlying functionality and processing should be the same.

• Re-create the problem on the web server.

  The logs will work in the Portal, HTML, and Java.

• Open a separate Internet Explorer browser and use it to access the Web Server Monitor for the web server being used.

• Check the Standard Error Log (stderr.log) for errors.

  A common error you might see here is BSFN Failed. If you see this error, verify that the enterprise server is up and that the BSFN is not a T1 BSFN.

  T1 refers to Type 1 business functions, which are client-only business functions. They cannot run on a server.

• Check the Standard Output Log (stdout.log) for more information.

  For example, you can view the time and date stamps from the errors found in both the Jas.log and the standard error log to find more detailed information about what was occurring at about the same time that the errors occurred.

If you need more information, enable Debug.log and set Net Trace, which you can do in the [LOGS] section of jas.ini file. Re-create the problem, view the Debug.log, and look for more information.

You can also use the Server Manager to monitor web servers.

Try to find SQL statement information. SQL statements can give you an idea of what values are being passed. Some common failures include:

• Form Interconnects are passing incorrect information.

  Verify that the fat client is working correctly. Watch especially for null, blank, and zero problems, as well as special characters.

• String is too big.

  Note carefully what you did to get this error.

• Null values are being passed.

  The SQL statement information search will result in nothing being found. Check the SQL statements and make sure that correct values were passed. Determine where the failure occurred and make a note of it.

• The application stops responding.

  Check logs for BSFN failures.