Legacy Parity Book a call

Demo · Parity Lab · Online screen

A mainframe green screen and its web replacement, side by side.

Type an account number. AWS runs CardDemo's original account screen, an unchanged COBOL program written for CICS, and asks the new Java service the same question. You get the 3270 screen the COBOL sent, the web page built from the Java service's answer, and a field-by-field check of whether the two agree.

Try: an ordinary account · two cards · account record missing · customer missing · a credit limit of 9,999,999,999.99 · short number · . The test data is CardDemo's 50 sample accounts (00000000001 to 00000000050) plus the four test records above.

Java side's data the COBOL always uses record files
Fixes Java side only

With no fixes, the Java service should fill every field of the original screen exactly as the COBOL does. Each fix changes one behavior the tests found in the original.

How it works

An online CICS program, without a mainframe

CICS is the mainframe system that runs online transactions such as this screen. There is no CICS here: the program's CICS commands are replaced with calls to small stand-ins, and the rest of the program runs as written under GnuCOBOL.

Your browser
Amazon CloudFrontthis site and /api
Amazon API Gatewaywith request limits
AWS Lambdachecks the request, starts the runner
AWS Lambda containerCOBOL screen and Java service
Amazon S3result, deleted after a day
Amazon Aurora ServerlessPostgreSQL; pauses when idle

  1. The COBOL, one key press at a time

    Each CICS command in the program (reading a file, sending the screen, receiving what was typed, returning with its saved data) becomes a call to a stand-in. A small driver plays the terminal: it starts the transaction, types your account number into the field and presses Enter, as a new task each time, the way CICS runs it. The screen the program sends is drawn from its own screen definition (the BMS map): positions, labels and colors.

  2. The Java service and the web page

    The service looks up the account, its card and its customer and returns JSON; the web page on the right is drawn from that JSON. For the comparison, the same answer is laid onto the original screen layout, and every field, color and the cursor position are compared with what the COBOL sent.

  3. What the tests found in the original

    An account with more than one card cannot be opened: the program treats the file system's "duplicate key" answer as an error. A card whose account record is missing still shows its customer, with account amounts from storage the program never filled. Messages show internal codes and are cut off at 75 characters. Amounts of a billion or more lose their first digit on screen. And the full Social Security number, government id and bank account are shown to anyone who can open the screen. Each of these is a switch on the Java side, off by default.

GnuCOBOL and the stand-ins are not a mainframe running CICS. The stand-ins are written to the documented behavior of each command, and their assumptions are listed in the case study's engineering record; a run on z/OS with CICS would close that gap.

Read about this slice in the CardDemo case study · Account update screen · Parity Lab: the nightly batch · All demos