JDE package build failed: how to find the real cause

Find and read the package build failure

1. 1In the Package Build Workbench, open the package definition and check the build status and the build machine it ran on (deployment server name).
2. 2Log on to that deployment server and locate the package's share, typically under the path code, e.g. \\deploymentserver\B9\PackageName.
3. 3Open the log subdirectory under the package name and look for the build log first - it lists each major phase (spec merge, table conversion, business function compile, table/index build) with pass or fail markers.
4. 4If the failure is in the table conversion phase, open the table conversion log for that package and search for the specific table (F number) that failed.
5. 5If the failure is in the compile phase, check for a separate compile errors log - this usually points to a specific custom C business function or a missing include file.
6. 6Confirm the OMW project for anything included in the package was actually checked in and transferred to the correct path code before the build started.
7. 7Check available disk space on the deployment server share - package builds fail silently partway through when the drive fills up mid-build.
8. 8If a table conversion failed because the table was in use, confirm no interactive or batch job had that table open on the target environment during the build window, then resubmit.
9. 9For a Full Package, if only one object caused the failure, consider whether a smaller Update Package targeting just that object is faster to debug than rebuilding the whole Full Package again.

The build phases and their logs

; typical deployment server package share layout
\\deploymentserver\B9\PackageName\
  log\buildlog.txt
  log\tablecnvlog.txt
  log\compileerrors.log
  obj\ (compiled objects for deployment)

Full vs Update package considerations

Common pitfalls

• !Reading the workbench status and stopping there instead of opening the actual log files on the deployment server.
• !Not checking which deployment server or build machine the package actually ran on when more than one exists in the environment.
• !Retrying a Full Package build repeatedly without isolating the single failing object into a smaller Update Package first.
• !Forgetting to check deployment server disk space before assuming the failure is a code or data issue.
• !Assuming a table conversion failure means data corruption, when it is usually a lock, permissions, or a data type mismatch that a custom conversion routine needs to handle.
• !Not confirming the OMW project was checked in and transferred to the target path code before the build ran, leaving the build working from stale specs.