det: batch file I/O holes in estates without an application JCL job (no CobolFiles), and WRITE ... ADVANCING
Maintainer thường phản hồi trong vòng 1 ngày
Một pull request liên quan đã được merge.
- #6111 của @squid-protocol — đã merge
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start with cobol_to_java_batch_forge.py and det/program.py to trace when batch runtime files and unscheduled main programs are generated, then inspect det/stmt.py around _write() for the trailing phrase handling. Use unit and synthetic COBOL programs to check WRITE ... ADVANCING against the IBM reference, and verify the named holes distinguish unsupported phrases. Done means the specified batch regression checks pass and the translation only survey reports before and after counts.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Why
The 2026-10-22 non-burned translation-only survey (#6064 comment) has two gaps that cover about two-thirds of the hole statements in the local non-burned corpora (dsf, zopeneditor-sample: 124 hole statements over 10 programs):
| hole reason | statements |
|---|---|
<OPEN/READ/WRITE/CLOSE> <file>: the generated project has no batch package (CobolFiles) to run files through |
~50 |
WRITE ADVANCING / other phrases |
33 |
Both are generic batch COBOL, not estate quirks, so they are likely to recur on any unseen batch estate.
1. No batch package unless the estate has an application JCL job
cobol_to_java_batch_forge.py BatchForge.sources() returns {} when self.applications is empty, so the batch runtime (CobolFiles, Sysout, CobolAbend, …) is generated only when the estate holds at least one application JCL job. det/program.py:has_batch() then finds no batch/CobolFiles.java, and every FD gets fd.why = "the generated project has no batch package…" (program.py ~L1029). Every file I/O statement becomes a hole.
dsf has no JCL at all. The unscheduled main-program path (the CardDemo CBTRN01C case: a main program with files, no USING, no COMMAREA) only counts when self.applications is already non-empty (bool(self.applications) and key in self.unscheduled, ~L343/L348).
Fix: emit the batch runtime when the estate has any batch program: an application job or an unscheduled main program with files. Treat a no-JCL estate's file-owning main programs as unscheduled batch steps, as CardDemo's CBTRN01C already is. A CICS-only estate (no FDs in a main program) must still get no batch package, as today.
2. WRITE … ADVANCING
det/stmt.py _write() (~L1000) holes anything after WRITE rec [FROM x]: "WRITE ADVANCING / other phrases". Model BEFORE/AFTER ADVANCING n LINE(S) | mnemonic | PAGE (IBM Enterprise COBOL Language Reference, WRITE statement, sequential files) for line-sequential and printer files: carriage control as IBM defines it for the record (ASA control byte when the file is ADV; the line/page skip otherwise). Refuse by name any phrase still not modelled (AT END-OF-PAGE/EOP with LINAGE, mnemonic names not in SPECIAL-NAMES), as a named hole, never a guess.
Sweep the class in the same PR: _write currently holes every trailing phrase, so check which others the surveys hit (INVALID KEY / NOT INVALID KEY on indexed/relative WRITE, END-WRITE) and model or name them separately, so the hole reason says which phrase.
Evidence constraints
- No burned estate uses
ADVANCING(grep over the 6 burned corpora: 0 files). Part 2 therefore can't reach L2+ on a burned estate: test it with unit and synthetic programs (language-crucible) against the IBM reference, and report it as translation-only until a burned program uses it. Don't build cases ondsf/zopeneditor/census repos (burned-only rule). - Part 1 regression: CardDemo/CBSA/GenApp batch must be unchanged (byte-identical generated estate where they have application jobs); the async credit-card estate (CICS-only, 0 JCL) must still get no batch package.
- Afterwards: re-run the non-burned translation-only survey (
det_survey.py --no-compileoverdsf,zopeneditor-sample) and post the before/after counts here. Baseline: dsf 0 / 7 whole, 231 / 318 statements; zopeneditor-sample 2 / 5 whole, 595 / 632.
- Ngôn ngữ chính
- Python
- Star
- 57
- Fork
- 11
- Merge trung bình
- 1 giờ 20 phút
- Pull request đã merge (30 ngày)
- 985
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của squid-protocol/gitgalaxy
-
claim:nyx enhancement priority: high scope:infra
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
squid-protocol/gitgalaxy#6278 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
claim:melek enhancement era:2 legacy-modernization priority: high scope:core testing
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 24/100
squid-protocol/gitgalaxy#6271 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
claim:nyx core-engine lane:nyx needs:doom-corpus priority: high scope:frontier
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 20/100
squid-protocol/gitgalaxy#6266 · 6 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
claim:nyx enhancement scope:sweep testing
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
squid-protocol/gitgalaxy#6262 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
scope:infra security
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
squid-protocol/gitgalaxy#6239 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của squid-protocol/gitgalaxy
Issue tương tự
-
push_gh-pages fails on master branch on forksCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởgood first issue infrastructure
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
kuznia-rdzeni/coreblocks#1135 ·
-
good first issue server
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation priority: high
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
a-lex-s/mealie-telegram-bot#54 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
type/test
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
SaltedTan/virgil-language-server#218 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
btclib-org/btclib-wallet#541 ·
Maintainer thường phản hồi trong vòng 1 ngày