sean/rpg-lemonade
Watch
2
0
Fork
You've already forked rpg-lemonade
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
55 commits 2 branches 19 tags 161 KiB
  • Shell 52.8%
  • Python 36.9%
  • RPGLE 7.3%
  • CLIPS 1.9%
  • SQLPL 0.8%
  • Other 0.3%
Find a file
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Sean OMeara a8df01a000
 docs: the release stages the loss profile the deploy applies 
The Binjovi deploy stage reads the flat release repository, so the routine
loss profile is now staged in each release as `loss-profile.json`, and the
deploy applies that copy with the pipeline's engine. This release is the
first one that carries the staged profile.

Claude-Session: https://claude.ai/code/session_01HPdKaFBKQVs8hzfgXMrnwV
2026-09-14 15:23:52 +02:00
.vscode feat: Lemonade Stand for the 5250 green screen (ibmi-rpg) 2026-06-30 17:30:39 +02:00
docs feat(loss): add the routine mode the deploy applies after every deployment 2026-09-14 14:05:31 +02:00
fixture feat(native): add persistent mixed RPG business application and safe capture scope 2026-09-09 19:04:32 +02:00
native fix(recovery): preserve exact records and require verified restore capability 2026-09-14 00:05:07 +02:00
QDDSSRC docs: rewrite documentation to ASD-STE100 2026-08-07 18:34:33 +02:00
QRPGLESRC docs: rewrite documentation to ASD-STE100 2026-08-07 18:34:33 +02:00
recovery feat(loss): add the routine mode the deploy applies after every deployment 2026-09-14 14:05:31 +02:00
scripts feat(loss): add the routine mode the deploy applies after every deployment 2026-09-14 14:05:31 +02:00
tests feat(loss): add the routine mode the deploy applies after every deployment 2026-09-14 14:05:31 +02:00
.gitattributes fix(cicd): auto-resolve CHANGELOG land conflicts via .gitattributes merge=union 2026-07-05 12:14:42 +00:00
.gitignore feat(lemonade): add journaled business recovery fixture 2026-09-09 18:04:03 +02:00
CHANGELOG.md docs: the release stages the loss profile the deploy applies 2026-09-14 15:23:52 +02:00
extract.sh feat: Lemonade Stand for the 5250 green screen (ibmi-rpg) 2026-06-30 17:30:39 +02:00
Makefile fix(recovery): preserve exact records and require verified restore capability 2026-09-14 00:05:07 +02:00
README.md docs: the release stages the loss profile the deploy applies 2026-09-14 15:23:52 +02:00
test-1-open-for-business.sh feat: environment libraries — LIB-targeted compile (CHGCURLIB in-job) + objects.env manifest 2026-07-03 21:25:06 +02:00
test-2-cannot-afford.sh feat: environment libraries — LIB-targeted compile (CHGCURLIB in-job) + objects.env manifest 2026-07-03 21:25:06 +02:00
test-3-closing-time.sh feat: environment libraries — LIB-targeted compile (CHGCURLIB in-job) + objects.env manifest 2026-07-03 21:25:06 +02:00
VERSION chore(trunk): open v0.1.6-dev dev cycle 2026-07-03 22:31:25 +00:00

README.md

rpg-lemonade

This project is a playable Lemonade Stand game for the IBM i green screen. It is a reimplementation of the classic Apple II and MECC business simulation. The game uses RPG and DDS. It runs over the 5250 protocol through the zelnet client. The project is a "crowd-pleaser" showcase for the ibmi-rpg pipeline. The pipeline compiles the game on a real IBM i host (pub400) over the zelnet Host Server client. It also tests the greenscreen game headless with zelnet --play.

Why Lemonade Stand? This game already fits the shape of a 5250 app. Each day, you read the weather. Then you set the number of glasses to make, the number of advertising signs, and the price. The program simulates demand and returns a profit-and-loss report. The game is pure block-mode and turn-based, with a character-cell display. It uses no game engine. It is just a business simulation.

What it is

  • Greenscreen: QDDSSRC/LEMSCR.dspf holds four records. TITLE shows the splash screen. PLAY sets glasses, signs, and price. RESULT shows the day's profit-and-loss report. ENDGAME shows the final standing.
  • Program: QRPGLESRC/LEMONADE.rpgle runs the game loop. It also runs a documented, seedable economic model. Weather and random events drive demand. The program generates random numbers with CEERAN0. You can seed this with an entry parameter. This makes the --play behavior test give the same result each time.

Build / test / play

  • Run bash scripts/deploy.sh to compile the DSPF -> RPG chain on pub400. The build treats warnings as errors.
  • Run bash test-1-open-for-business.sh, bash test-2-cannot-afford.sh, and bash test-3-closing-time.sh to drive the greenscreen game headless with zelnet --play. Each test checks one scenario. A full day must post a profit-and-loss report. An over-spend order must be refused. The stand must close correctly. Each test passes no matter what weather the game rolls. This set of tests is the behavior gate.
  • Run bash extract.sh to pull the source members off the box and back into Git. This is the import round-trip.

Branches + environments

  • trunk is the integration branch. Open a feature PR to it. Request its release through Binjovi after the Build passes. Do not merge the PR directly in Forgejo. Only the Binjovi release identity can advance this branch.
  • main holds releases only. The promote step advances it by fast-forward.
  • Environments map to IBM i libraries on pub400. SOMEARA1 is the dev and CI scratch library. SOMEARA2 is staging. It holds trunk builds, behavioral reels, and the SAVF package source. SOMEARAB is prod. It is deploy-only. CRTDUPOBJ promotes objects into it under an integrity gate.

To play the game interactively, run zelnet term pub400.com, then CALL SOMEARAB/LEMONADE. Press F3 to quit. This command calls the PROD deploy. Use CALL SOMEARA2/LEMONADE for staging.

Controlled source loss

Every Binjovi deployment of this application ends with a routine source loss, so the box always carries a decades-old simulation: the routine targets of recovery/loss-profile.json (LM_BASE, LM_SALEUI, LEMONADE, LEMSCR) lose their source members in SOMEARA1, and LM_SALEUI and LEMONADE lose their observability in SOMEARAB and SOMEARA1. Staging (SOMEARA2) is never touched. The originals stay in Git; the next Build re-adds the members and recompiles. The release stage stages the profile as loss-profile.json in the release repository, and the deploy applies that staged copy with the pipeline's own engine (ibmi-rpg-source-loss), which has the same semantics as the routine mode here. The loss report is in the deploy log (ibmi-source-loss-report.v3). The twin repository named by the profile's output_repository (rpg-lemonade-tng) recovers deployable text from that state. See docs/SOURCE-LOSS.md for the routine mode and for the bounded operator exercise, which still needs RSTOBJ.

Native Binjovi delivery

Build compiles the exact PR revision in SOMEARA1 with the pinned ibmi-builder image and its installed zelnet client. Release tests the combined revision in SOMEARA2. It publishes a save file, the object manifest, recordings, MP4 reels, and JPEG previews with digests. Deploy copies the verified release objects to SOMEARAB and rejects a changed staging object set.

Release also saves compiled-objects.txt. Deploy checks the program, bound module, and display-source metadata before and after the copy. A missing or different record fails the Deploy. This is compiler/source metadata proof, not a binary hash.

All phases use native Binjovi agents in the cluster. Shared IBM i work is serialized. Media rendering runs separately. The recipe is in sean/binjovi-plans, under recipes/ibmi-rpg and recipes/rpg-lemonade. Recipe changes do not require a Binjovi server deployment. Historical release artifacts remain available. See docs/pub400.md for the IBM i connection.

Source capture gate

Each development or staging compile uses the baked Zelnet client to make a strict two-pass export of LEMSCR and LEMONADE. The gate checks the manifest, file sizes, hashes, and exact bytes against this Git revision. It fails if native edits change the source during this check. The full recovery experiment and staged deployment plan are kept in rpg-demo/recovery/PLAN.md.

Native development and source recovery

The expanded business application is in native/. It has 14 program components, a display file, a shared parameter member, and the journaled SQL business fixture. It preserves SEU/PDM editing and compilation in SOMEARA1. Temporary SQL tests use separate T1_ names.

The expanded application is not a staging or production release target yet. A complete application restore must pass before source-loss tests start.

Native pipeline timing

Native agents coordinate source capture, compilation, release verification, and pub400-rpg deployment. IBM i operations remain serialized. Remote compiler time appears in task spans; it is not local syscall work.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Cached BuildKit steps still appear as cached work; a missing sample does not prove that a task used no CPU.

Select an exact successful Build with binjovictl release rpg-lemonade --build BUILD_ID --wait. Then use binjovictl status rpg-lemonade to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.