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

Aperta
  • Qualcosa non va?
#6,069 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
documentation

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Python
Stelle
57
Fork
11
Merge medio
1h 35m
PR unite (30g)
975

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di squid-protocol/gitgalaxy

Tutte le issue di squid-protocol/gitgalaxy

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.