When your site upgrades DFSORT (or the sort product supplied with z/OS) to a newer version, existing jobs may be affected. Newer versions can deprecate or remove options, change default behavior, or fix bugs in a way that changes output. To migrate safely, you need to know what changed, which jobs use those features, and how to update and test them. This page explains how to migrate from older DFSORT versions: using release notes and migration guides, handling deprecated and removed options, adjusting for changed defaults, and testing after the upgrade so your batch jobs continue to run correctly.
Software upgrades introduce new features, fix defects, and sometimes remove or change old behavior. DFSORT is no exception. An option that was valid in an older version may be deprecated (still works but scheduled for removal) or removed (no longer accepted). A default that your job relied on (e.g. without coding an option explicitly) may change. Bug fixes can alter output in edge cases. So after an upgrade, some jobs may fail with syntax or option errors, or may produce different results. Migration means identifying those jobs and updating them before or soon after the upgrade.
| Step | Action | Purpose |
|---|---|---|
| 1 | Read release notes and migration guide | Identify deprecated, removed, and changed options |
| 2 | Inventory jobs | List jobs that use affected options |
| 3 | Update control statements | Replace deprecated/removed options with supported alternatives |
| 4 | Test | Run with representative data; compare output |
| 5 | Document | Note changes for future reference |
The first place to look is the product release notes for the version you are moving to. They typically list: new features, deprecated features (with replacement when available), removed features, and incompatible or behavior changes. A migration or compatibility section may summarize what you must do. For DFSORT, this is often part of the z/OS or DFSORT product documentation. APARs (Authorized Program Analysis Reports) may describe specific fixes that change behavior. Read these before the upgrade so you can plan which jobs to change and in what order.
A deprecated option is one that still works but is planned for removal in a future release. You should stop using it and switch to the recommended alternative so that when the option is finally removed, your job does not break. A removed option is no longer accepted; the job will fail (e.g. with an "invalid keyword" or similar message). The release notes usually state the replacement. For example, an old keyword might be replaced by a new keyword with the same effect, or you may need to achieve the same result with a different combination of statements. Update the control cards and test.
Sometimes the default value of an option changes. If your job did not code that option (relying on the default), behavior can change after the upgrade. For example, a default for overflow handling or for record format might change. The release notes should call out such changes. Search for "default" or "behavior" in the release notes. If you rely on default behavior, consider coding the option explicitly so the job is insensitive to future default changes (and is self-documenting).
After upgrading, run your critical DFSORT jobs with representative input. Compare the output to a baseline from the previous version: same record count, same key records (spot-check), same totals or trailers. Pay special attention to jobs that used any deprecated, removed, or changed options—those are the ones most likely to differ. If you have a test environment, run the full batch suite there first. Document any jobs that required changes and keep a short note of what was updated so future maintainers understand.
Product documentation and release notes are the primary source. Your site may have an upgrade project team or a standard process for DFSORT/z/OS upgrades. If a job fails with a message you do not recognize, look up the message in the current version manual; the explanation often tells you what replaced an old option or what changed. For IBM DFSORT, IBM documentation and support channels apply.
When the sort program gets an update, some of the old buttons might be taken off or renamed. The instruction book (release notes) says which buttons are gone and what to use instead. Before you use the new version for real work, you try your usual tasks (testing) to make sure everything still does what you expect. If something breaks, you read the book and change how you push the buttons (update the job).
1. Why should you check release notes when upgrading DFSORT?
2. What is a deprecated feature?
3. How should you test jobs after a DFSORT upgrade?
4. Where do you find what changed between DFSORT versions?
5. What if your job uses an option that is now removed?