Deprecated syntax is the vocabulary your programs should unlearn before Broadcom 11.6 becomes the only compiler in the data center. Not every obsolete construct triggers a dramatic syntax error—some linger as warnings, some compile cleanly until a PTS removes support, and some alter runtime behavior in ways parallel testing alone reveals. CA Plus 6.x manuals describe FILE options, PARM keywords, and REPORT hooks that Release Difference notes later mark unsupported or replaced. Options table entries your systems programmer set fifteen years ago may map to nothing in EZOPTBL conversion output. Beginners encounter deprecated syntax as cryptic message codes in SYSPRINT; experienced maintainers recognize them as signs of portfolio age. This page categorizes common deprecation patterns, shows replacement strategies, and ties compile diagnostics to migration workflow so you fix root causes instead of patching one program at a time forever.
Broadcom publishes deprecation in Release Notes, Release Difference guides, options conversion utility reports, and Language Reference footnotes on individual statements. Internal audit should mirror those sources: when a construct appears in Release Difference as unsupported on 11.6, add it to your shop migration checklist even if test compile still accepts it today.
Site-wide defaults live in the options table: buffer sizes, abend exit behavior, sort product delegation, listing characteristics, and compatibility toggles. CA 6.x tables do not copy verbatim into 11.x EZOPTBL files. The conversion utility emits warnings for keywords with no target mapping. Operations must reconcile warnings before developers chase phantom program bugs caused by unlike runtime defaults between test and production.
| Step | Action | Typical owner |
|---|---|---|
| Export 6.x table | Capture current production values | Systems programming |
| Run converter | Generate EZOPTBL candidate | Systems programming |
| Review warnings | Replace or drop unsupported keys | Lead developer + ops |
| Pilot jobs | Compare runtime behavior | Application team |
| Promote | Update procs with EZOPTBL DD | Change control |
Compile PARM strings control listings, maps, compatibility mode, and debug expansion. Deprecated PARM tokens may be ignored silently or rejected with message codes. Standardize one approved migration PARM profile for compile-all sweeps—DEBUG with PMAP DMAP XREF for discovery, production PARM trimmed per site policy. When release notes rename a PARM keyword, update internal compile procs before individual developers inherit stale templates from personal libraries.
12345Migration compile profile (example — verify on your FMID): PARM DEBUG(PMAP DMAP XREF) LIST FILE Production profile (example): PARM LIST NODATA * Remove DEBUG after migration sign-off
FILE declarations accumulate organization-specific options over decades: obsolete ACCESS spellings, buffer keywords superseded by options table defaults, or vendor-specific clauses from pre-Plus migrations. For each FILE error in pilot compile, open 11.6 Language Reference FILE chapter and rebuild the statement from supported parameters only. Prefer moving repeated clauses into maintained macros so FILE deprecation fixes propagate across the portfolio.
SQL FILE deprecations appear separately: older explicit SELECT styles may remain supported while simplified forms are preferred for new code. Do not mix styles in one program without readability standards—pick the supported pattern your DBAs certify for 11.6.
Report layout hooks and DISPLAY variants change names or semantics between releases. DISPLAY NEWPAGE versus DISPLAY TITLE alignment in 11.x is a documented compatibility adjustment—reports depending on legacy page-break side effects need visual diff review. BEFORE-LINE and AFTER-LINE family statements should match current Language Reference spelling; Plus PDFs may use labels refactored in TechDocs. When a hook name disappears from Language Reference, locate the replacement hook in Programming guide migration sections or release notes rather than guessing from memory.
Classic-era control flow—certain GOTO patterns, obsolete loop constructs, or pre-Plus macro invocations—may compile with compatibility switches then fail when function mode is enabled site-wide. Refactor to structured IF/ELSE and documented PERFORM/PROC patterns supported in 11.6. Programs with tangled unlabeled flow are migration risks even before syntax is strictly deprecated: they resist regression testing and onboarding.
| Symptom | Likely cause | First fix |
|---|---|---|
| Unknown PARM keyword message | Deprecated compile option | Compare PARM to 11.6 compile options doc |
| Invalid FILE parameter | Obsolete ACCESS or buffer clause | Rebuild FILE from Language Reference |
| Reserved word conflict on field | New 11.6 keyword (not always deprecated syntax) | Rename field; see migration-new-reserved-words |
| Clean compile, wrong totals | Options table or DISPLAY semantic change | Parallel compare; read release difference |
| Options utility warning | Unsupported 6.x table entry | Map to supported EZOPTBL keyword or default |
Deprecated syntax concentrated in FILE and PROC macros multiplies pain across hundreds of reports. Inventory macros before member-level edits. Version-control macro libraries with migration tags (for example, a suffix indicating 11.6-ready layouts). One macro fix clearing fifty compile errors beats fifty copy-paste member edits that drift out of sync within weeks.
12345* After macro fix — programs invoke updated layout %INCLUDE PAYROLL-FILE-11 JOB INPUT PAYROLL ADD GROSS TO DEPT-TOTAL REPORT DEPT-SUMMARY
When you suspect deprecation but Language Reference is silent, log the construct to your team research file with program ID, FMID, listing snippet, and message code. MainframeMaster maintains EASYTRIEVE_FUNCTION_RESEARCH_LOG.txt for community follow-up. Do not block migration on single anomalies—escalate with evidence while the portfolio compile sweep continues on known fixes.
Deprecated syntax is like old words teachers say not to use anymore because new textbooks prefer different ones. Your story might still make sense with the old word, but the new teacher marks it wrong. Learn the new words from the official dictionary (Language Reference) and fix them in shared flashcards (macros) so the whole class updates together.
1. Deprecated syntax in Easytrieve migration means:
2. The first place to find deprecated Easytrieve options is usually:
3. When a deprecated FILE option appears in source, you should:
4. Fixing deprecated syntax in shared macros:
5. Deprecated DISPLAY behavior often requires:
Deprecated syntax includes statement options, PARM keywords, options table entries, and report hooks that Broadcom documents as obsolete or unsupported in 11.x. Some still compile with warnings; others fail immediately on the target compiler.
No. Some deprecated features compile but behave differently or may be removed in a future PTS. Migration projects should eliminate deprecated constructs proactively rather than waiting for hard failures.
Run the Broadcom options table conversion utility in test and read its warning report. Compare output EZOPTBL against production behavior before cutover.
Classic-era verbs absent from 11.6 Language Reference are migration targets regardless of history. Pilot compile on 11.6 surfaces them with syntax error diagnostics.
Yes. When Language Reference is ambiguous, log the construct in your team research file with program name and listing snippet. Update tutorials and standards when Broadcom guidance confirms replacement spelling.