rpg-hello

This repo has example IBM i software, starting with RPG "hello world". It tests zelnet, a modern TN5250/TN3270 terminal client. IBM i has no stdout. A program's "output" is the 5250 datastream that the terminal renders. So these examples also work as terminal test programs.

Target host: pub400.com (a free public IBM i). Profile SOMEARA.

What's here

Path	What it is
rpg/hello/hello.rpgle	The smallest RPG program. It runs DSPLY 'Hello, World!', a message line at the bottom of the screen.
rpg/helloscreen/HELLOD.dspf	A DDS display file (record format MAINPANEL). It paints Hello World! full-screen, with an F3=Exit prompt.
rpg/helloscreen/helloscr.rpgle	The ILE RPG driver. It runs EXFMT on MAINPANEL until F3.
scripts/deploy.sh	Compiles all three programs on the box, through PASE system.
docs/pub400.md	pub400 specifics: libraries, IFS paths, SSH, and known issues.

The two "hello worlds"

1. DSPLY (one line). This proves the compile-to-CALL loop. Output is a 5250 Write-To-Display message line. On an interactive job, it waits for ENTER.

**FREE
dsply 'Hello, World!';
*inlr = *on;

2. Display file + EXFMT (the real 5250 way). This paints a screen with a record format and reads an AID key. It is the true terminal test. DDS is column-significant: A in column 6, R in column 17, name in column 19, row in columns 39-41, column in columns 42-44, and constant starting in column 45.

     A                                      DSPSIZ(24 80)
     A                                      INDARA
     A                                      CA03(03 'Exit')
     A          R MAINPANEL
     A                                  5  5'Hello World!'
     A                                 23  2'F3=Exit'

**FREE
ctl-opt dftactgrp(*no) actgrp(*new);
dcl-f HELLOD workstn indds(dspind);
dcl-ds dspind qualified;
  exit ind pos(3);   // CA03 (F3)
end-ds;
dow not dspind.exit;
  exfmt MAINPANEL;
enddo;
*inlr = *on;

Build & run

CRTBNDRPG reads IFS source (SRCSTMF). CRTDSPF does not. So the build first copies the DDS into a QDDSSRC member. A display-file (EXFMT) program needs a real 5250 device. Compile over SSH, but CALL the program from a 5250 session.

# from a clone of this repo:
scp -P 2222 -r rpg SOMEARA@pub400.com:/home/SOMEARA/rpg-hello/   # upload source
ssh -p 2222 SOMEARA@pub400.com 'bash -s' < scripts/deploy.sh         # compile on the box

Next, open a 5250 session. Use make powerbunker in the seanfarm repo, or run zelnet pub400.com 992. At the IBM i command line, run:

CALL SOMEARA1/HELLO        → "Hello, World!" at the screen bottom; ENTER
ADDLIBLE SOMEARA1
CALL HELLOSCR              → paints the screen; F3 exits

Running CALL HELLOSCR from zelnet is the milestone. It shows your own RPG screen, painted by your own terminal.

Native Binjovi delivery

Open a feature PR to trunk in Forgejo sean/rpg-hello. Request its Release through Binjovi after the Build passes. Do not merge the PR directly in Forgejo. main holds released revisions. Codeberg remains the off-cluster mirror.

• 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, object records, 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-hello. Recipe changes do not require a Binjovi server deployment. Historical release artifacts remain available.

Native pipeline timing

Native agents coordinate the Build, Release, and pub400-rpg Deploy. IBM i operations remain serialized. The host task profiles do not measure syscalls inside the remote IBM i system.

The local pipeline runs on the ARM canary: the native agent, BuildKit, source checks, terminal client, video renderer, and artifact publisher use ARM64. The RPG compiler and application still run on IBM i at pub400. A successful ARM pipeline does not mean that the RPG application runs on Linux.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Task profiles are above the timeline; select Syscall counts for the automatic call totals. Raw syscall capture is a separate, optional recording. 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-hello --build BUILD_ID --wait. Then use binjovictl status rpg-hello to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.