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 IBM i) 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.
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 IBM i, this location is a library. For non- IBM i 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 IBM i) 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 IBM i)
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/E920/system/bin32 RunOneWorld.sh
and assuming that logging is enabled, the system places the log files in the /u13/JDEdwards/E920/system/bin32 directory. Similarly, on a UNIX machine, if you start JD Edwards EnterpriseOne with this command:
cd /usr/JDEdwards /u13/JDEdwards/E920/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 IBM i) 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.