Skip to content

feat(cobol-to-java): BMS screens -> view models, handlers and web views (#3619) - #3703

Merged
squid-protocol merged 1 commit into
mainfrom
feat/bms-screens-3619
Sep 26, 2026
Merged

squid-protocol merged 1 commit into
mainfrom
feat/bms-screens-3619

Conversation

@squid-protocol

Copy link
Copy Markdown
Owner

Closes #3619. Part of #3625.

What

CICS programs talk to users through 3270 screens defined in BMS maps. The verified skeleton already joins every SEND / RECEIVE MAP to its map's fields (screen_bindings, ledger field BMS screen fields). This PR turns those facts into the application's screen layer.

Always (when a program uses screens):

  • dto.screen.<Map>Screen, one view model per map:

    • a property per named field, with a Javadoc citing its BMS line, POS, LENGTH, ATTRB and symbolic-map names;
    • LAYOUT: every field in screen order, labels included;
    • fromValues / screenValues for form binding.

    It follows the config's Lombok or plain style, and stays a class even under dto_style: record, because a form bean must be mutable.

  • ScreenField / ScreenCell / ScreenModel: ScreenModel.screenCells() turns any screen into positioned cells (labels, outputs, input boxes, OCCURS expanded). The layout logic is compiled Java, not template code.

  • Service handlers:

    • render<Map>(screen) per SEND, and submit<Map>(input, aid) per RECEIVE, where aid is the key pressed (EIBAID). Each cites its COBOL lines, and the business logic is a TODO.
    • A map that no single BMS source defines gets a TODO naming the candidates and, when the mapset is known, the maps it does define.

ui.flavour (new config key, default none):

flavour adds
none nothing more
openapi-only a @RestController per program: GET /api/v1/<program>/screens/<map> renders, POST submits with @Valid (@Size from LENGTH, @Pattern from ATTRB=NUM); springdoc 2.5.0 serves /v3/api-docs and Swagger UI
thymeleaf a @Controller per program, plus one generic templates/screen.html that draws any screen on its 24×80 grid from its cells, with ENTER / PF3 / CLEAR buttons

The needed starters are added to the Maven and Gradle builds. A flavour requires features.services and features.rest_controllers.

Found along the way: a bug in the CBSA sample

BNK1CCS.cbl:236, on CLEAR, sends MAP('BNK1CCM'), which is the mapset's name; its only map is BNK1CC, used by every other SEND and RECEIVE in the program. The generated service says so: … no single BMS source defines it (candidates: none in the repository); mapset BNK1CCM defines BNK1CC.

Evidence

corpus view models fields SEND / RECEIVE sites unresolved
CardDemo 21 585 26 / 21 0
CBSA 9 130 27 / 9 1 (the bug above)
GENAPP 5 74 43 / 9 0
  • Compiles: 45/45 (CardDemo, CBSA and GENAPP × 15 configs, including the new ui-thymeleaf and ui-openapi-plain). Preflight now also compiles CardDemo ui-thymeleaf.
  • Runtime, not just compile. I ran throwaway tests, not committed, in generated CardDemo projects:
    • thymeleaf: the sign-on page renders with its labels and title, USERID is an 8-character input, and a PF3 submit round-trips through the service;
    • openapi-only: JSON render and submit work; an over-long USERID gets 400 from @Valid;
    • the whole generated app boots on H2: /v3/api-docs lists the screen's GET and POST, with maxLength: 8 from the BMS LENGTH.
  • Default config: nothing else moves. The only changes are the new dto/screen package and the services of screen programs (21 / 9 / 5). zECS, zopeneditor and DSF are unchanged, and the refraction snapshots are unchanged.
  • Tests: full suite 11,785 passed. test_bms_screens.py runs a real scan with a label, IC, NUM, DRK and OCCURS fields, a continued BMS macro, an unresolvable map and a mapset-named map, across all three flavours, plus the config validation, manifest and worklist.

Paper trail

  • traceability.json: screen-view-model, screen-field (BMS line and position), screen-send, screen-receive and screen-endpoint entries.
  • Migration worklist: the handlers' TODOs are business logic, and unresolved maps are fact-gaps.
  • Guardrail: the view models are inventoried like any DTO, so an agent adding a field is flagged layout-changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g

…ws (#3619)

Every BMS map a converted program SENDs or RECEIVEs becomes a `<Map>Screen` view model in
dto.screen:
- a property per named field, citing its BMS line, POS, LENGTH, ATTRB and symbolic-map names;
- LAYOUT: every field in screen order, labels included (ScreenField);
- ScreenModel's screenCells(): the positioned cells, OCCURS expanded;
- fromValues / screenValues for form binding.

Services:
- render<Map> per SEND and submit<Map>(input, aid) per RECEIVE (`aid` = EIBAID);
- each cites its COBOL lines, with a business-logic TODO;
- a map no single BMS source defines gets a TODO naming the candidates and, when its mapset
  is known, the maps the mapset defines. This found a real CBSA bug: BNK1CCS sends
  MAP('BNK1CCM'), the mapset's name.

New config ui.flavour (none | thymeleaf | openapi-only; default none):
- openapi-only: a REST controller per program, @Valid bodies (@SiZe from LENGTH, @pattern
  from ATTRB=NUM), springdoc 2.5.0;
- thymeleaf: a web controller per program and one generic templates/screen.html drawing any
  screen on its 24x80 grid, with ENTER / PF3 / CLEAR;
- the starters are added to Maven and Gradle builds.

Everything is recorded in traceability.json; TODOs flow into the worklist; the guardrail
inventories the new classes. Matrix configs ui-thymeleaf and ui-openapi-plain; preflight
compiles CardDemo ui-thymeleaf.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ZsVaAkb86P5r5JXDC2Y9g
@github-actions

Copy link
Copy Markdown
Contributor

🐦‍⬛ Muninn Security Scan

✅ No security issues found.

🐦‍⬛ Powered by Muninn · Skald Lab

@squid-protocol
squid-protocol merged commit 163dffa into main Sep 26, 2026
36 checks passed
@squid-protocol
squid-protocol deleted the feat/bms-screens-3619 branch September 26, 2026 02:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Java conversion: BMS screens + symbolic maps -> view models and (per config) web views

1 participant