Collect troubleshooting data for problems with IBM WebSphere Data Interchange. Gathering this information before calling IBM support will help familiarize you with the troubleshooting process and save you time.
Resolving the problem
This document is for collecting troubleshooting data specifically for when WebSphere Data Interchange MultiPlatform server is running on AIX or Windows and does not complete successfully or produces unexpected results.
Command Line Processor (ediservr)
The WDI utility program (ediservr) can be executed via a command prompt or as part of a script involving other back-end application programs. If running WDI via the ediservr command line processor, please gather the required information:
1) ediserver command file being executed, e.g. sample.cmd
PERFORM TRANSFORM WHERE INFILE(XMLFILE) OUTFILE(OUTFILE)
SYNTAX(X) CLEARFILE(Y) XMLSPLIT(N)
2) STDOUT and STDERR from ediservr. To capture, rerun ediservr as follows:
ediservr <sample.cmd >stdout.txt 2>stderr.txt
3) If abnormal termination occurred, capture the core file (AIX) or userdump (Windows). See section below for "Crash" on the applicable platform.
4) Since Data Transformation or Translation is typically involved, include an export of the associated map as described under MustGather - WDI Mapping
5) Go to section below, "Submitting information to IBM Support"
Triggering from a WebSphere MQ queue - Advanced Adapter (wdiserver)
The WDI Advanced Adapter (wdiserver) is designed to provide a WebSphere MQ trigger interface to WebSphere Data Interchange. If running WDI via the Advanced Adapter, please gather the required information:
1) wdi.properties - Important note: do not send the "userpassword" if present therein, i.e. we only need adapter settings that were in place at time of failure. And, ideally, set "tracelevel=2" in the wdi.properties to capture the finest level of detail. Note: a greater tracelevel will significantly increase the size of the logs.
2) STDOUT and STDERR from wdiserver. To capture, restart the adapter as follows:
wdiserver >stdout.txt 2>stderr.txt
Or, better yet, if at WDI Server Fix Pack 8 or above, restart the adapter as follows:
wdiserver -f wdiserver.log >stdout.txt 2>stderr.txt
And include "wdiserver.log" along with "stdout.txt" and "stderr.txt"
3) WDIService.log from all WDI Translator Command Queue folders, e.g. WDITransCmdQ_00010
and any other files stored within this folder.
4) Contents of the Adapter runtime "archive" folder for the associated WMQ message. If not currently being saved, you can force WDI to keep the archive by setting "keeparchive=always" in the wdi.properties file. The adapter will need to be restarted for the changes to take effect.
5) If abnormal termination occurred, capture the core file (AIX) or userdump (Windows). See section below for "Crash" on the applicable platform.
6) Since Data Transformation or Send/Receive Translation is typically involved, include an export of the associated map as described under MustGather - WDI Mapping
7) "Export to file" the following WDI artifacts specific to your Advanced Adapter issue:
- Service profiles
- MCD profiles, if applicable
- Mailbox profiles
- Network Profiles
- Queue profiles
- WMQ queue definitions via "runmqsc" command: DISPLAY QLOCAL(generic_q_name)
8) Go to section below, "Submitting information to IBM Support"
Crash on AIX
Your WDI server terminated without warning or a core file is generated but you are not sure what data to collect. The following MustGather will assist you in collecting the critical data to troubleshoot issues with an IBM WDI Server crash on the AIX platform.
Locate the system core, with the filename core* . Rename the system core so it does not get overwritten.
If you encounter the crash when running the ediservr command line processor, the core file would be in the working directory.
If you encounter the crash when using the Advanced Adapter, the core file would be located in the WDITransCmdQ_* directory of the translator that experienced the crash.
In addition to the core dump file, please provide the stack trace of the failing module. This can be accomplished as follows:
a. Change directory to location of core file and execute the following commands:
b, dbx /opt/IBM/WDIServer/V3.3/bin/<name of failing module> (i.e. WDIService)
c. where > stacktrace.txt
If a core file is not found, follow these steps:
1. Setting Ulimits
To set ulimits on the core and file sizes to unlimited, run these two commands as the user who starts WDI Advanced Adapter:
|ulimit -c unlimited
ulimit -f unlimited
You can run ulimit -a to verify current ulimit settings.
Ulimits can also be altered at a global level by editing the /etc/security/limits file. In the stanza for the user that runs the process, set fsize = -1 and core = -1. Setting these values to -1 changes the setting to unlimited.
Even with all ulimit settings set to unlimited, core files are truncated at 2GB?
This is a limitation on 32-bit processes. You can avoid this issue if you enable large file support on the operating system. Refer to AIX operating system documentation for additional details.
Make sure enough file space is available for the generation of system cores. The size of the core depends on your JVM's heap settings. And make sure proper file permissions are set.
2. Configuring the Operating System for Full Core Generation
If you do not have access to the SMIT administration tool, the following flag can be set from the command line (as the root user):
To set full core generation:
|chdev -a fullcore=true -lsys0|
To verify full core is set:
|lsattr -Elsys0 | grep full|
Crash on Windows
Your WDI server terminated without warning or a userdump is generated but you are not sure what data to collect. The following MustGather will assist you in collecting the critical data to troubleshoot issues with an IBM WDI Server crash on the Windows platform.
Locate the userdump, with the filename *.dmp. By default *.dmp is generated in the following location:
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson
Rename the userdump so that it is not overwritten.
Submitting information to IBM Support
After a PMR is open, you can submit diagnostic MustGather data to IBM. If using Service Request (SR), update the PMR to indicate that data has been sent.
MustGather - WDI Mapping
MustGather - WDI Client database errors
MustGather - WDI z/OS Batch (JCL) processing
MustGather - WDI CICS processing
Explanation of properties in wdi.properties and Queue Trigger Attributes for WDI Advanced Adapter
Exchanging information with IBM Technical Support
Featured documents for WebSphere Data Interchange