Troubleshooting tips
The troubleshooting tips provided here are intended as suggestions to help resolve some of the more frequently encountered setup errors.
Issue: Map returns “One or more inputs was invalid” error
Troubleshooting: The compliance check maps never return the “One or more inputs was invalid” error for bad EDI data. If the EDI data is bad, the maps reject the data. An error is then written to the compliance check log to indicate that it cannot be parsed, as X12 or EDIFACT data.
- Use the –TI option on the ccx12 or ccedf map to generate an input trace, which can help you identify which input that WebSphere Transformation Extender considers to be invalid.
- Make sure that your configuration file is valid, and conforms to the XSD. See the sample configuration files in the data directory for valid examples.
- If you are running on a system other than a Windows system, make sure that all files are copied correctly. See the Deploy compliance check maps documentation to see which are to be copied as ascii files, and, which ones are to be copied as binary.
- If you are using z/OS data sets, see the params.parm file in the deploying_to_mvs example to see which inputs use the /VX15 option. This option tells WebSphere Transformation Extender to treat each record break as a new-line character, so the record-oriented input files are4 processed correctly.
- If you are using z/OS data sets, see the readme file in the deploying_to_mvs example for instructions on how to update the map and type tree so that they to point to a DD name for the XSD file.
Issue: Map returns "Input valid but unknown data found" message
Troubleshooting: This issue can occur because there are multiple interchanges in the input EDI data (input card 1), or other data that follows the EDI interchange. The EDI compliance check maps support one interchange at a time in the input EDI data. The first interchange of the input does get processed in this case.
If there is only one interchange in your EDI input, use the -TI option on the ccx12, or ccedf map to generate an input trace. Then, use the trace file to help you identify which input has unknown data at the end.
Issue: Map returns “FAIL function aborted map” error
Troubleshooting: This error occurs if there is a severe error – typically the map is not able to write to the file, queue, or wire terminal. When this type of failure occurs, a framework log edilog.xml is written to the map directory. For these failures, the log is written whether the trace was enabled or not.
Search the framework log for the string "<FrameworkErrorOccurred>". Immediately before this string there is usually some information about the error that occurred, such as an error writing to a specific file, queue, or wire terminal.
When you are writing to file output, the directories must already be created (and have write access) before you can run the map. The map does not create them. Also, be aware that path names are relative to the map directory, not necessarily to the directory you were in when you ran the command.
Issue: Type tree validation map failed (E9002/E9003 error in compliance check log)
Troubleshooting: Make sure the type tree validation map that is listed in the error message was compiled. If you are running on a system other than Windows, make sure that it was copied to the system as binary.
Issue: Segment detail validation map failed (E9015 error in compliance check log)
Troubleshooting: Make sure the segment detail validation map that is listed in the error message was compiled. If you are running on a system other than Windows, make sure that it was copied to the system as binary.
Issue: Exit/DLL call failed (E9010 error in compliance check log)
Troubleshooting: Make sure that the DLL/shared library used for the exit call is copied to the target system (as binary), and that the edicc.ini file has the correct path to it. Path names are relative to the map directory, not necessarily to the directory you were in when you ran the command.