Transferability record: first-contact translation on non-burned estates vs the 6 burned (2026-10-22 peek, honest gaps)

Open
  • Is something wrong?
#6,069 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
documentation

Research direction

Read the issue’s recorded survey and evidence for the 2026-10-22 baseline, including the referenced #6064, #6065, and #6066. The issue reports a measurement and assessment; no files or tests are named. Done means documenting the real first-contact scan results for dsf and zopeneditor-sample, with the noted prior-peek caveat.

Written by the indexing model from the issue text.

Description

documentation legacy-modernization metrics priority: medium scope:infra

What this is

An honest record of how far the translator built on the 6 burned estates carries over to code it was not built on. It records one unplanned look at non-burned code on 2026-10-22 and what it showed, so the next first-contact scan has a baseline and nobody mistakes burned-estate numbers for general capability.

Framing (owner, 2026-10-22): the first 6 estates we prepared for did not fully transfer to a 7th. That is expected and fair to say: we have depth on 6 estates and not yet the breadth. This record exists so the claim stays honest.

The peek, stated plainly

On 2026-10-22, while trying to estimate non-burned translation rates, the orchestrator:

  1. Ran det_survey.py --no-compile (translation only, counts only) over the 9 census repos plus the two pinned non-burned corpora dsf and zopeneditor-sample.
  2. Grepped dsf's PL/I files for the era tells of era_tags.py (counts only).
  3. Wrote two issues from what it saw: #6065 (batch file I/O + WRITE ADVANCING) and #6066 (PL/I CICS).

No cases were built and no code was changed. A decision to burn dsf was made and reversed the same evening: dsf and zopeneditor-sample stay non-burned. #6065 is parked in churn (needs owner) and #6066 stays frontier. No fixes derived from these corpora land before their real first-contact scan. We have seen their hole reasons, so that scan isn't fully blind; report it with that caveat.

Numbers (main 082aba881, 2026-10-22)

set programs translated whole statements translated
Burned, 6 estates (evidence report) 129 123 (95%) —
Burned, CICS programs (census baseline) 106 103 (97%) —
Non-burned, 9 census repos 40 8 (20%) 568 / 647 (87.8%)
census, translatable as supplied* 19 8 (42%) —
zopeneditor-sample (batch COBOL) 5 2 595 / 632 (94.1%)
dsf COBOL (batch) 7 0 231 / 318 (72.6%)
dsf PL/I (1,473 files, 575 EXEC CICS) 1,473 0 (COBOL-only translator) 0

* Excludes 3 non-programs (ISPF screen captures, a copy member), 9 source defects (text past column 72) and 9 missing inputs (an absent user copybook; IBM's z/OS Connect BAQRINFO, never shipped).

Over time: non-burned whole-rate was 24% on 2026-10-07 (5 / 21, CICS programs only) and 20% today (8 / 40, all COBOL). In the same two weeks burned CICS went from 70% to 97%. Different denominators, but there's no sign that the burned-estate gains carried over.

Honest assessment of the gaps

  1. Language breadth is the biggest gap. A real production estate (NAV's DSF, 1967–2018) is ~99% PL/I. Our CICS capability today is COBOL CICS; on that estate the translator covers ~0.5% of programs. (#6066)
  2. Batch outside the JCL-driven shape. The generator emits the batch runtime only when an estate holds an application JCL job, so batch programs in an estate without JCL lose all file I/O. Our burned estates all ship JCL, so they never showed this. (#6065)
  3. Statement families the 6 estates never used: WRITE … ADVANCING (0 burned files), JSON GENERATE/PARSE, WEB WRITE HTTPHEADER SESSTOKEN, SQL ROLLBACK inside CICS, variable-length records without RECORD VARYING.
  4. Input completeness: about half of census refusals are missing copybooks or source defects, not the translator. Real estates arrive incomplete; we refuse correctly, but the first-contact rate pays for it.
  5. Era profile. The burned estates lean era 2–4 (RESP, SQL, channels, async). DSF's PL/I CICS is solidly era 1 (HANDLE CONDITION in 254 files, DL/I in 111, HANDLE AID in 67, RESP in 1). Era-1 COBOL work (#5856-class) exists, but era 1 in PL/I is untouched.
  6. What does transfer: the statement core. Where a program translates at all, 82–94% of statements come through; 8 of 19 translatable census programs translate whole on first contact, and the holes are named, not guessed.

Going forward

  • #6064 makes the non-burned rate a scheduled, published number, so transfer is measured continuously, not by accident.
  • dsf / zopeneditor-sample: the next scan is the real first contact. Record it here, then decide on #6065/#6066.
  • Breadth is the fix for transfer: more estates scanned first-contact (the blind 4th-estate draw, #5865 missing systems), not more depth on the six.
Dominant language
Python
Stars
57
Forks
11
Avg merge
1h 35m
Merged PRs (30d)
975

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from squid-protocol/gitgalaxy

All issues in squid-protocol/gitgalaxy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.