DevOps & Modernization Troubleshooting
Link-edit resolves wrong module
Link-edit resolves wrong module is the pipeline telling you its own machinery is broken. Fix the factory before blaming the product.
What it means
- CI agents are the workers that run pipeline steps - an unavailable or misconfigured agent fails every job assigned to it.
- Dependency versions are a contract - one floating version can break a build that worked the day before.
- A pipeline without post-deployment verification only proves the files moved, not that the system works.
Common causes
- Build agent offline, out of disk, or missing a required tool such as the compiler or Zowe CLI.
- Dependency or plugin version drift: a new version pulled automatically that is incompatible.
- Emergency fix stuck behind a release approval gate designed for planned releases.
- No smoke test after deploy, so a bad deploy is discovered by users instead of the pipeline.
- Automated restart logic re-running a failed batch job that should have stayed failed for investigation.
- Alerts firing without the job name, return code, or log location needed to act on them.
How to diagnose
- Check agent status and capacity in the CI tool before re-running anything.
- Pin the dependency versions from the last good build and diff them against the failing one.
- Read the pipeline log at the first failed step - later steps fail as a consequence.
- Verify what the deploy step actually copied: file names, timestamps, and target libraries.
- Confirm whether the change record maps the real dependencies or just the headline change.
How to fix it
- Bring the agent back - disk space, service restart - or route the job to a healthy agent.
- Pin dependency versions; upgrade them deliberately, not automatically.
- Create a documented emergency lane in the approval process with the same audit trail.
- Add a post-deploy smoke test, one transaction or one batch step, that gates the release as done.
- Disable blind auto-restart for failed production work and require human review first.
Example: Smoke-test a deploy before calling it done
zowe zos-jobs submit data-set "PROD.JCL(SMOKE)" --wfo
zowe zos-jobs list jobs --owner MYUSER --prefix SMOKE
Submit one known-good job and watch its return code - the cheapest post-deployment verification there is.
Interview tip
- Q: Every build worked until this morning, and nobody changed the source. Link-edit resolves wrong module - where do you look?
- A: I look at what the pipeline pulls in automatically: dependency and plugin versions. I diff the resolved versions against the last green build and pin the one that moved. Unpinned dependencies are the usual suspect when the source has not changed.
Prevention checklist
- Pin all dependency versions and upgrade them on a schedule, not by surprise.
- Monitor agent health and disk space with alerts, not user complaints.
- Every deploy ends with an automated smoke test; a deploy is not done until it passes.
- Alerts must include the job name, return code, and where the log lives.
