InfoCenter Home >
8: Problem determination >
8.3: Logs and traces

8.3: Logs and traces

Analyzing logs and traces is a significant step in the problem determination process. This section explains log file formats, types of logs, how to enable logs and trace, when and how to use them.

What are logs and traces?

Logs and traces provide information about the execution of WebSphere Application Server components, including the administrative server and clients, application servers and other processes in the environment.

Logs and traces are basically the same. In other words, traces are just logs. The difference is that traces must be turned on, while logs are always enabled.

Enabling trace

You can enable trace for each Java class in the system through the administrative GUI and through the command line. Trace is transported by an in-memory circular buffer called a ring buffer. A ring buffer must be dumped to a file in order for the trace to be viewed.

Administrative console

To enable trace using the administrative GUI, right click on a node or application server in the topology tree.

The administrative GUI allows you to set the size of the ring buffer, dump the ring buffer, or enable and disable trace for a particular class or group of classes. By using the administrative GUI, you can enable or disable trace dynamically on running managed or administrative servers.

Command line

Most command line trace in WebSphere Application Server support a -traceString option that allows you to specify the startup trace string. Trace strings can be specified to enable diagnostic trace from the command line. -traceOutput often allows you to specify which file to write the trace to, instead of the ring buffer.
Trace string format
The information or command is called a trace string. The following are sample parts of the string:

COMPONENT = [(LEVELS=STATE),...]:[(LEVELS=STATE),...]

Where...
  • Component is the fully qualified Java classname (that is, com.ibm.servlet.engine.ServletEngine) or a Java package (that is, com.ibm.servlet).
  • Levels are one of the following:
    • All
    • EntryExit
    • Debug
    • Event
  • State is either enabled or disabled

Example: com.ibm.ejs.ras.*=all=enabled

This following table lists the components and trace specifications for that component.

Component Name  Trace Specification
AEs/AE Web Admin Application  com.ibm.ejs.sm.web.*
Active objects of the admin system for AE, Trace problems transferring configuration from admin repository to active server  com.ibm.ejs.sm.active.*
Admin Database Manager for AE, Trace SQL calls to admin repository  com.ibm.ejs.sm.util.db.*
Admin GUI Code for AE, Trace client-side admin problems  com.ibm.ejs.sm.client.*
Admin Server Process, Managed Server Process  com.ibm.ejs.sm.server.*
Admin Server Repository Object trace for AE, Trace Admin Problems  com.ibm.ejs.sm.beans.*
Admin Wizard Implements for AE  com.ibm.ejs.sm.tasks.*
Application Assembly Tool  com.ibm.ejs.assembly.*
Application Installation Tooling for AEs/AEd  com.ibm.websphere.install.*
Connection Pooling Manager, Data Sources  com.ibm.ejs.cm.*
Container Server Interface  com.ibm.ejs.csi.*, com.ibm.websphere.csi.*
DynaCache Caching Implementation  com.ibm.servlet.dynacache.*
EJB Container Runtime, Trace EJB problems, Determine root cause of TransactionRolledBackException  com.ibm.ejs.container.*
EJB Persistence Layer  com.ibm.ejs.persistence.*
HTTP Session, User Profile com.ibm.servlet.personalization.*
HTTP Transport Plugin Config Generator  com.ibm.websphere.plugincfg.*
HTTP Transport Server  com.ibm.ws.http.*
and/or  com.ibm.servlet.engine.http11.*
and/or  com.ibm.ws.io.*
J2EE Client  com.ibm.websphere.client.*, com.ibm.ws.client.*
JMS Support  com.ibm.ejs.jms.*
Java Connection Architecture (JCA) Support  com.ibm.ejs.j2c.*
Migration Tooling  com.ibm.websphere.migration.*
Naming Implementation  com.ibm.websphere.naming.*
and/or  com.ibm.ws.naming.*
Performance Monitoring Interface  com.ibm.websphere.pmi.*, com.ibm.ws.pmi.*
Process Launcher Code for AEs/AEd  com.ibm.websphere.install.commands.*
Process Management Code  com.ibm.ejs.sm.util.process.*
Runtime Server Main and Server Initialization  com.ibm.ws.runtime.*
Transaction Management Support  com.ibm.ejs.jts.*
WSCP  com.ibm.ejs.sm.ejscp.*
Web Container  com.ibm.servlet.engine.*
WebSphere Classloader  com.ibm.ws.bootstrap.*, com.ibm.ws.classloader.*
WebSphere Security System  com.ibm.ejs.security.*
and/or  com.ibm.websphere.security.*
and/or  com.ibm.ws.security.*
Workload Management  com.ibm.ejs.wlm.*, com.ibm.ws.wlm.*
XMLConfig tool for AE  com.ibm.websphere.xmlconfig.*

Enabling trace on the application client

To enable logging of message events or trace on the application client, add the following property to the startup script: -DtraceSettingsFile=filename. The file (named by fileName) must be a properties file placed in the classpath of the application client. A sample file is provided in <product_install_dir>/properties/TraceSettings.properties.

There are two related functions provided by this file:

  1. traceFileName property
    This should be set to the fully qualified name of a file to which you want output written. For example, traceFileName=c:\\MyTraceFile.log. This property must be specified, otherwise no visible output is generated.
  2. Trace string
    If a file name is specified and no trace string is specified, only message events are written to the specified file. If a file name is specified and a trace string is specified, both message events and diagnostic trace entries are written to the specified file. If a filename is not specified, nothing is written, irregardless of the state of the trace string.

Tracing application code

The trace subsystem does not trace application code (that is, servlets or EJB components) unless System.err.println or System.out.println statements are added to the code. Output from the println statements is displayed either in the application server stdout or stderr logs. See the stdout and stderr logs description for more information on stdout and stderr logs. Beginning with WebSphere Application Server Version 3.0, an object level debugger is provided with the product to trace and debug user code. See the Object Level Tracing and Debugging (OLT and OLD) section for information on object level tracing.

Trace and log entry format

WebSphere Application Server supports multiple log and trace formats which are specified by the user. There are three formats:

Basic log or trace output

A log entry and a trace entry have the same format. The following example of a log entry illustrates the basic format:

Log entry example: [00.07.11 22:47:12:191 EDT] 53ccc3c5 ActiveEJBCont W Could not create bean table xxx

The table below describes the parts of the basic output format using the log entry example above:

[00.07.11 22:47:12:191 EDT] 53ccc3c5 ActiveEJBCont             W
TS:   The timestamp in fully qualified date (YYMMDD), Time (Millisecond precision), and Time zone format. TID:   The thread ID or the hash code of the thread issuing this message. COMPONENT:   The short name of component issuing this message. LEVEL:   The level of the message or trace. Possible levels are:
  • > Entry to a method (debug)
  • < Exit a method (debug)
  • A Audit
  • W Warning
  • X Error
  • E Event (debug)
  • D Debug (debug)
  • T Terminate (exits process)
  • F Fatal (exits process)
  • I Informational

Advanced log or trace output

The following is a sample of the advanced format:

[01.07.23 10:01:483 CDT] 3e139d54 AdminServer F ADMS0007E:
Could not load database

The table below describes the parts of the advanced output format using the log entry example above:

[01.07.23 10:01:483 CDT] 3e139d54 AdminServer ADMS0007E F
TS: The timestamp in fully qualified date (YYMMDD), Time (Millisecond precision), and Time zone format. TID: The thread ID or the hash code of the thread issuing this message. PROCESS NAME: The name of the process COMPONENT: The short name of component issuing this message. LEVEL: The level of the message or trace. Possible levels are:
  • > Entry to a method (debug)
  • < Exit a method (debug)
  • A Audit
  • W Warning
  • X Error
  • E Event (debug)
  • D Debug (debug)
  • T Terminate (exits process)
  • F Fatal (exits process)
  • I Informational

Note: Organization, product and component can be set on JRas loggers. For existing WebSphere runtime code, defaults are provided for the organization and product, and do not display a component.

The property com.ibm.ws.ras.MessageFilterLevel allows you to set a filter level for which categories of message events are logged by any of the system logging facilities. If audit is selected, all SeriousEvents (audit, warning, error, fatal, terminate) are logged. If Warning is selected, audit messages are not logged. If error is selected, neither audit nor warning messages are logged.

This property is located in the <install_dir>/properties/logging.properties file. A process must be restarted for the change to take effect.

Loganalyzer log or trace output

The Log Analyzer is a graphical utitlity that facilitates viewing and analyzing log files. The loganalyzer format is compatible with Log Analyzer combining and correlating traces from multiple server processes. Move all the tracefiles to a directory on a single system. The tracefiles must have been generated in loganalyzer format. Launch the Log Analyzer and use File->Open to navigate to that directory and open one of the tracefiles. Next, use the File->Merge with and select another tracefile. This will merge the contents of the two files in the Log Analyzer display.

Useful information when using the advanced and loganalyzer formats

If the startup trace is not enabled, the stdout.log and stderr.log files are always generated in basic format. If startup trace is enabled and sent to a user specified file, then the stdout.log and stderr.log files are generated in basic format and the user-specified file is generated in the format specified by the user.

If startup trace is enabled and sent to stdout.log or stderr.log, then that file is generated in the format specified by the user. The ring buffer is always generated in the format specified by the user.

Product logs

WebSphere Application Server provides many error logs to help you diagnose run-time problems. The logs are:

The tools required to process some of these logs (as well as some of the trace logs) are described in Using Internal Tools. You can also refer to Problem determination hints and tips for additional tips on the use and processing of some of these error logs. If you need to report a problem to IBM, you might need to gather some of these error logs and send them to IBM for diagnosis; for more information, refer to getting help from IBM.

Activity log for problem determination

The activity log is a file wherein events that show the history of WebSphere Application Server activities are captured. Some of the entries in the log are informational, while others report on system exceptions, such as returned CORBA exceptions.

When you encounter WebSphere Application Server run-time errors, you will often find it useful to use Log Analyzer to read the activity log and try to diagnose the problem yourself.

Location of the activity log

There is one activity log for each host machine. The activity.log file resides in the logs directory of where the product is installed. All application servers, including the administrative server, write error records to this file. The activity.log file is a binary file and cannot be viewed with an ascii editor. You can view the activity.log file in one of two ways:

NOTE:The activity.log file should NOT be edited. If sections are deleted from this file the file will become corrupted.

How to view the activity.log file with the Log Analyzer

  1. Change the directory to:
    product_installation_root/bin
  2. Run the waslogbr script file, which is called:
    • waslogbr.bat on Windows NT
    • waslogbr on Unix systems
    If the bin directory is not set in the PATH environment variable, it needs to be run from the bin directory listed above.
    This will start the Log Analyzer graphical interface.
  3. In the interface:
    1. Select File > Open.
    2. Navigate to the directory containing the activity.log file (for example: <websphere...root> > logs > activity.log)
    3. Select the activity.log file.
    4. Select Open.

How to view the activity.log file on a remote machine using showlog

If you plan to transfer the activity.log file to a remote machine, you must transfer the file using a tool like FTP if the remote file systems are not mounted locally. The file must be transferred in binary mode, otherwise the log file could corrupt and will not be readable.

The Log Analyzer cannot be used to view remote files unless the remote file systems are mounted locally using utilities like NFS or SAMBA. An alternate tool named showlog can be used instead of Log Analyzer to format the activity.log file for viewing when no GUI display capabilities are available.

showlog.bat or showlog.sh is a script/batch file that can be found in the bin directory of the WebSphere Application Server installation. Follow these instructions to use showlog:

  1. Change directory to:
    product_installation_root/bin
  2. Run the showlog tool with no parameters to display the usage instructions:
    • On Windows NT, run showlog.bat
    • On Unix systems, run showlog.sh
Examples:
  • To direct the activity log contents to stdout, use the invocation:
    showlog activity.log
  • To dump the activity.log to a text file that can be viewed using a text editor, use the invocation:
    showlog activity.log > textFileName

Changing activity.log file size

The activity.log file grows to a predetermined size and then wraps. The default size is 1MB. You might want to change the size of the log to fit your installation and needs, depending on how frequently messages are logged or how much historical data you want to retain. Follow these steps to change the log size:

In the course of using Log Analyzer, you might have to set the maximum activity.log file size. The activity.log file grows to a predetermined size and then wraps. The default size is 1MB. Follow these steps to change the log size:

  1. Open the properties file in a text editor:
    product_installation_root/properties/logging.properties
  2. For the com.ibm.ws.ras.ActivityLogSize property, specify the value you would like in Kilobytes (KB). If an individual size is entered, the default size is used.
    • Example: To change the log size to 2MB, enter in the line:
      com.ibm.ws.ras.ActivityLogSize=2048 (do not use spaces)

The size change will take effect at the next server startup.

The activity log uses a lock file named activityLog.lck, located in the same directory as the activity log, to synchronize acces to the activity log. If you use either showlog or the Log Analyzer, you must have write access to the <product_install_dir>/logs/directory. These programs must lock the activity log while making a copy of it. In order to do this, the programs must be able to create the lock file in this directory which requires write access.

stderr and stdout logs for problem determination

The stderr and stdout logs capture events presented through two of the three standard I/O streams, or:

  • stdin - arguments entered with a command or program
  • stdout - output displayed to the user
  • stderr - errors thrown by the code

The location and names of these files are specified in each server's property page in the administrative console.

In WebSphere Application Server, the stdout and stderr logs are created for:

  • Application servers

The application server stderr and stdout logs contain application server communication. Output from System.err.println and System.out.println statements in the servlet code also appear in the application server stdout and stderr logs.

New Version 4.06 feature: Wrapping System.out and System.err log files

A Java Virtual Machine (JVM) provides two output streams to which Java code can print or write: system.out and system.err streams. A JVM runs in a native process, which also provides two output streams to which process native code can write. These are the process stdout and stderr streams. By default, data written to the JVM system.out and system.err streams is forwarded to the process stdout and stderr streams respectively. WebSphere Application Server supports the redirection of stdout and stderr streams to log files. The installation default is to redirect these streams to files that are located in the <WASHOME>/logs directory. These log files grow without bound and you must stop a server process in order to perform log file maintenance.

This feature supports the JVM system.out and system.err streams of any server process to redirect to self-managing log files, which are independent of the process stdout and stderr files. The process stdout and stderr files are retained, but have no data written to them under normal operating conditions. Activate this feature on a per-server basis. New configuration data in the Ras properties file (logging.properties) is required. A new version of the logging.properties file is available with the product installation. The wrapping feature is disabled by default. If wrapping is activated, the new self-managing log files for system.out and system.err streams manage themselves based on file size. When a self-managing log file is configured, you can specify a name, maximum file size in megabytes, and archive size. When the server starts, the specified stream is redirected to this file. When this file approaches the specified maximum size, logging is temporarily suspended. The current file is closed, renamed, and put into the archive. The system generates a new file name, based upon the original file name, plus the timestamp at which the rename occurred. A new, empty file with the original name is opened and logging resumes to that file. When the number of files in the archive exceeds the specified size of the archive, the system deletes the oldest archive file. No messages are lost while this maintenance occurs.

How to activate Wrapping

  1. Shut down WebSphere Application Server. All server processes must be stopped. For Advanced Edition, this shut down includes both application servers and the administrative server.
  2. Archive the existing stdout and stderr logs for all server processes. The default location for these log files is the <WASHOME>/logs directory. For Advanced Single Edition, the default log names are default_server_stdout.log and default_server_stderr.log. For Advanced Edition, the default log names are tracefile and AdminServer_stderr.log for the administrative server, and AppServerName_stdout.log and AppServerName_stderr.log for the application servers. Moving these log flies to an archive directory is recommended.
  3. Locate the current Ras properties file. By default, this file is named logging.properties and is found in the <WASHOME>/properties directory. Typically, all server processes on a node share a single copy of this file. If coexistence support is enabled, every server process has its own private copy of this file. If coexistence support is in use, it is recommended that you make a backup copy of all existing Ras properties files at this time.
  4. Create a copy of the logging.properties file for each server configured to use the wrapping log files. It is recommended that you use the server names in naming the copy. For Advanced Edition, this recommendation includes both application servers and the administrative server. If coexistence support is in use, each server process now has two Ras properties files defined. Merge these files into a single file. The new properties file is a proper superset of the old. The new version of the Ras properties file has added properties, but none are deleted. Copy the new properties to the existing Ras properties files for each server.
  5. Change the properties setting for the System.out and System.err logs in each of the Ras properties files. Each log has four properties that you can potentially modify.

    The four properties for the System.out log are listed below. A similar set of properties exists for the System.err log.

    • com.ibm.ws.ras.SystemOutLogEnable
      Set this property to true, to enable this log. The default value is false.

    • com.ibm.ws.ras.SystemOutLogName
      Set this property to a unique, fully qualified file name. The recommended value is <WASHOME>/logs/<ServerName>_SystemOut.log. Ensure the specified file name is in a valid format for the platform. If a non-default directory is specified, create the directory before you start the server process. In addition, WebSphere Application Server must have write access to this directory.

    • com.ibm.ws.ras.SystemOutLogRollover
      Specify the maximum size of the log file, in megabytes. The default is 1 (one megabyte). This number must be positive.

    • com.ibm.ws.ras.SystemOutLogBackups
      Specify the maximum number of archive files to retain. The default is 1. This number must be positive.

  6. Configure each server process to use its private copy of the Ras properties file, instead of the shared (logging.properties) file. Use the com.ibm.ws.ras.RasProperties system property for this purpose. The name of the properties file specified using the com.ibm.ws.ras.RasProperties must be relative to the class path. Store the properties files in the properties directory, since this directory is on the class path.

    Following is an example of how to configure an Advanced Edition Single Server, an Advanced Edition administrative server, and an Advanced Edition application server to use a properties file named ServerName.properties. The ServerName.properties file resides in the <WASHOME>/properties directory.

    • Advanced Edition Single Server
      1. Select the server XML configuration file in the Web console.
      2. Click Nodes > <node_name> > Application Servers.
      3. Click Server > Process Definition > JVM Settings.
      4. Click SystemProperties in Advanced Settings.
      5. Click New.
      6. Add com.ibm.ws.ras.RasProperties for the name field, ServerName.properties for the value field.
      7. Save the configuration.

    • Advanced Edition administrative server
      1. Edit the admin.config file in the <WASHOME>/bin directory.
      2. Add -Dcom.ibm.ws.ras.RasProperties=ServerName.properties to the com.ibm.ejs.sm.util.process.Nanny.adminServerJvmArgs statement.

    • Advanced Edition application server
      1. Start the administrative server and the administrative console.
      2. Expand nodes > <node_name> > Application Servers.
      3. Click Application Servers.
      4. Click JVM Settings.
      5. Click Add in System Properties. Add com.ibm.ws.ras.RasProperties for the name field, ServerName.properties for the value field.
      6. Click Apply.
      7. Verify that the generated property is correct
        (-Dcom.ibm.ws.ras.RasProperties=ServerName.properties) in the Generated Command Line Arguments section.

  7. Restart the application servers.

Plug-in log for problem determination

The native.log file is created by the plug-in running in the Web server process. This file are located in the ./logs directory of the WebSphere installation. This log contains error and informational messages generated from the Web server plug-in. This information reflects server startup and server status change requests (start/stop/restart).

The default log file mask setting for the plug-in log is error. If this log has a file length of zero, no error messages were generated during the server status change requests.

Windows NT Identifierwasdb2 log

This log is created when the DB2 database, was, is configured. Review this log to determine if the was database was created correctly and if WebSphere Application Server can connect to it. Errors creating the system management repository tables will be logged in this file.

Windows NT Identifierwssetup log

This log is created during the install process. Review this log to ensure the install process was successful. The install process consists of:

  • Verifying prerequisites
  • Downloading files
  • Updating the configuration files for both WebSphere Application Server and the Web server

UNIX identifierWebSphere.instl

On AIX and Solaris, a native installation of WebSphere Application Server generates the WebSphere.instl log that is located in the product_installation_root directory.

Information on the WebSphere Application Server install process on HP is placed in the HP system log, swagent.log, that is located in the/opt/WebSphere/AppServer/var/adm/sw directory.

FatalErrorserver_name log

If a fatal error occurs, the serious error log file may be produced. This log contains the server name and text that reads FatalError.

This log file will be placed in the product_installation_root directory and will have the following name: <server_process_name>FatalError<ts>.log where <server_process_name> is the name of the server process that encountered the fatal error and <ts> is a timestamp when the fatal error occurred.

Types of traces

The following are the traces you will find in WebSphere Application Server:

View the following graphic for a description of the log and trace points in WebSphere Application Server:

tracepoints graphics

tracefile

The tracefile provides trace entries on the interaction of various WebSphere Application Server components with the administrative server. Use the tracefile to identify a problem and to review events preceding the error situation.

Note: Always review trace entries prior to the error. Trace entries recorded after the error has occurred represent program recovery and will not help with problem determination.

UNIX identifierNanny trace

On UNIX platforms, the nanny process starts the administrative server. The nanny.maxtries parameter in the admin.config file tells the nanny process how many times it should attempt to restart the administrative server.

On Windows NT, the nanny service is part of the IBM WebSphere Administrative Server service that is registered with the operating system. Starting the IBM WebSphere Administrative Server service invokes adminservice.exe. If the service does not start, verify that:

  • The service was installed and is available from Start > Settings > Control Panel > Services
  • The user ID under which WebSphere Application Server was installed has service privileges

If the nanny process fails to start the administrative server on UNIX or if the IBM WebSphere Administrative Server service does not start on Windows NT, you can bypass the nanny function and just start the administrative server. Follow these steps to start the administrative server:

  1. Go to the <WAS_root>bin/bin directory
  2. Invoke adminserver.sh on UNIX or adminserver.bat on Windows NT

    Note: Starting the administrative server without using the nanny function means that nothing is monitoring the administrative server. If it fails in this state, nothing will restart it.

A nanny trace is only available on UNIX platforms.

On Windows NT, use the Event Viewer to view entries related to the WebSphere nanny service. Follow these steps to view the Event Viewer :

  1. Select Start > Programs > Administrative Tools
  2. Select Event Viewer
  3. View events related to WebSphere Application Server

DrAdmin trace function

The DrAdmin function generates thread dumps.

On UNIX platforms, the IBM JDK allows users to send signals to force javacore.txt files to be created in the application server's working directory. The application server continues to run and a sequence of javacore files are created. These files can help in debugging "loop" or "system hang" problems.

To generate thread dumps similar to the javacore files, especially on a Windows NT platform, use the DrAdmin function.

A unique DrAdmin port is generated each time an application server starts. To generate a thread dump for that port:

  1. View the console messages area or the tracefile for message SMTL0018I "DrAdmin available on port."
  2. Enter the following command:
    DrAdmin -serverport <port number> -dumpThreads
  3. Review the stderr log for the thread dump.

Note: A specific DrAdmin port may be configured. If the DrAdmin port is set to -1, which is a default, this indicates that a specific port has not been set and a port will automatically be generated.

After installing and starting WebSphere Application Server, you will see DrAdmin entries in the console messages area. These entries appear regardless of the options specified during installation, and have the following format:
           DrAdmin available on port 1,055

DrAdmin entries are also recorded in the tracefile. To locate the DrAdmin entry in the tracefile:

  1. In the product_installation_root/logs directory, open the tracefile.
  2. Go to the bottom of the tracefile and then scroll up until you locate the following entry: DrAdmin available on port xxxx

What is DrAdmin?

DrAdmin is a service, provided by each of the servers, to enable and disable tracing. Each time a server starts, DrAdmin registers itself on a different (next available) port number. There are no output messages associated with DrAdmin. The DrAdmin entries in the console messages area are generated to tell users the port number where DrAdmin is listening.

When to use DrAdmin?

You should always use the administrative console trace facilities to debug a problem. DrAdmin provides useful lightweight access to several runtime functions, as well as provides access to a number of different processes, including nanny and administrative server processes. Opt to use DrAdmin in the following situations:

  • When input to the administrative console is not accepted
  • When the administrative server is in a wait state
  • When the administrative server is not responding (for example, it is in an infinite loop or hung state)
  • When you have to dump the thread stacks in a server
  • When the administrative client topology tree disappears

Note: DrAdmin is an internal interface that is used to assist users with problem determination. As an internal interface, it is subject to change at any time, and there is no national language support for it.

How to use DrAdmin?

The DrAdmin interface is the same on all platforms. Since DrAdmin is another way of turning on a trace, the tracing mechanism is the same as the one used by the administrative console trace facilities. Therefore, whether you are looking at the tracefile or a DrAdmin output file, the trace entries will have the same format.

See the DrAdmin samples to learn how to invoke DrAdmin.

To specify the DrAdmin trace output in the admin.config file:

  • In the admin.config file located in the product_installation_root/bin directory, append the following property where the file name consists of an absolute path and the file that you want to create: com.ibm.ejs.sm.adminServer.traceOutput=<filename>
  • Restart the administrative server. The tracefile specified in the admin.config file should be created during startup of the administrative server. The administrative server might not start if the path specified for file name does not exist, or if the directory permissions where the tracefile is to be created, are incorrect or insufficient.
  • If the administrative server starts but the tracefile is not created, ensure the traceOutput parameter in the admin.config file is correct, and the path to the file exists.

Use of the admin.config file for trace output does not apply to the single server product. Instead, server trace options are configured through the server configuration file:

INFO_USAGE_LINE_37=(Prepend the tracefile with "!" to cause that file to
INFO_USAGE_LINE_38=be truncated when starting the server. Use the values
INFO_USAGE_LINE_39="stdout" or "stderr" to case trace output to be written,
INFO_USAGE_LINE_40=respectively, to standard output or to standard error.)

DrAdmin Help

DrAdmin has a help file available. You can access the DrAdmin help by using typing on the command line the "- help" option.

Go to previous article: How to View Messages Go to next article: Enabling and Reading ORB Trace

 

 
Go to previous article: How to View Messages Go to next article: Enabling and Reading ORB Trace