Demo · Parity Lab · Online update
Change an account on the mainframe screen and on its replacement.
CardDemo's Update Account screen is its largest program: 4,236 lines of COBOL that check about forty fields and write two records together. Pick an account and some changes. AWS runs the unchanged program and the Java service on fresh copies of the same data, presses Enter and then F5 on both, and compares every screen and every byte they save.
What was saved
Field-by-field comparison
The Java side on the original screen layout
For the comparison the Java's answer is laid onto the original screen, field by field.
How it works
A screen that writes, compared on what it writes
The update screen reads an account and its customer, checks every field you change, asks you to confirm with F5, then reads both records again for update, checks that nobody changed them in the meantime, and rewrites both. If the second write fails, the first is undone.
The COBOL, with its writes
As for the account view, the program's CICS commands go to small stand-ins and the rest runs as written under GnuCOBOL. New here: READ UPDATE, REWRITE and SYNCPOINT (with ROLLBACK). The stand-in keeps a before-image of every rewritten record, so a rollback really puts the old record back. A terminal stand-in types into the fields as a 3270 would, and refuses to type into protected ones.
The Java service and the database
The rules are carried over one by one, in the program's order and with its messages. Saving is one database transaction with row locks (
SELECT … FOR UPDATE): both rows change or neither does. After the run, every record the two sides changed is compared byte for byte, the database's rows exported back to the record layout first.What the tests found
The account group is saved where the zip code belongs and the real group field is blanked, so a new group never shows again. A day typed as one digit is saved as
2014-11-5, a date the database refuses. Zip codes that start with 0 (Connecticut, Massachusetts, New Jersey and five more) can never be saved: the program's table holds the wrong two digits. Cleared fields are written as binary zeros. When the customer record cannot be locked, the screen shows the error and also "Changes committed to database", though nothing was written. And none of CardDemo's 50 sample accounts passes the program's own checks as stored.
GnuCOBOL and the stand-ins are not a mainframe running CICS. Where GnuCOBOL and IBM's compiler may differ (a field of digits that holds a blank, for one), the engineering record says so.
Read about this slice in the CardDemo case study · Account view screen · Parity Lab: the nightly batch · All demos