AWS's open-source CardDemo mainframe application — CICS online plus batch COBOL, VSAM, Db2, IMS, MQ and BMS 3270 screens — running on the SteelFrame engine from its official source. This page explains what CardDemo is, states plainly what was and was not changed to run it here, and serves as an operations manual: signing on, the menus and transactions, the batch jobs and the data files. Every transaction, job, option and dataset below is drawn from the official repository and the members installed on this engine.
← back to the terminal all manuals compiling programs conformance REST admin API
CardDemo is the open-source mainframe sample application published by Amazon Web Services to exercise mainframe migration and modernization tooling. It is a credit-card management system: customers, accounts, cards and the cross-reference between them, transactions and transaction types, bill payment, statements and reports, and an admin side for user security. It was written to look like a real estate rather than a toy — pseudo-conversational CICS programs with BMS 3270 maps, a batch cycle driven by JCL, VSAM KSDS files with alternate indexes, and optional extensions on Db2, IMS DB and MQ.
Upstream source, published by AWS under the Apache-2.0 licence:
github.com/aws-samples/aws-mainframe-modernization-carddemo ↗CardDemo is AWS's work and AWS's copyright. SteelFrame is not affiliated with, sponsored by or endorsed by Amazon Web Services; the application is used here as the independent, publicly available test subject it was designed to be.
| Layer | In CardDemo |
|---|---|
| Online | CICS COBOL programs, BMS mapsets, pseudo-conversational menus (sign-on, user menu, admin menu) |
| Batch | JCL-driven cycle: file refresh, transaction posting, interest, statements, reports; SORT, IDCAMS, IEBGENER, GDGs, an internal-reader flow, a timed wait step |
| Data (base) | VSAM KSDS: accounts, cards (+ AIX by account), customers, card cross-reference (+ AIX), transactions, transaction types and categories, disclosure groups, category balances, user security |
| Db2 (optional) | Transaction-type management: CARDDEMO.TRANSACTION_TYPE and TRANSACTION_TYPE_CATEGORY, online list/update (CTLI, CTTU), batch maintenance and extract |
| IMS DB + Db2 + MQ (optional) | Pending credit-card authorizations: an MQ-triggered authorization program, IMS summary/detail screens, Db2 fraud table, a batch purge |
| MQ (optional) | Request/response inquiries: system date (CDRD) and account details (CDRA) |
The point of running CardDemo here is not that it is a large application — it is that it is
somebody else's application, written for real z/OS, with no knowledge of SteelFrame. So we
did not port it. SteelFrame takes the official repository in as-is — the COBOL programs, BMS
mapsets, copybooks, JCL, CSD definitions, Db2 DDL and IMS DBD/PSB source — and compiles and runs it
with the same standard z/OS job streams a mainframe shop would use: IGYWCL for the
COBOL, DFHBMSCP for the maps, DBDGEN/PSBGEN for IMS, DSNTEP/DSNTIAUL
for Db2. All 44 programs and all 21 mapsets compile and run from the official source.
CARDDEMO.JCL(RELDPADB),
the IMS database reload job — CardDemo ships the unload job (DBPAUTP0) and its
unloaded data, but no job to load that data back, so we wrote the mirror image (§E). Every other
member, including the scheduler definitions, is the official one.| Member | The bug | The correction |
|---|---|---|
| CBEXPORT, CBIMPORT COBOL |
RECORD KEY IS EXPORT-SEQUENCE-NUM names a field that exists only in
WORKING-STORAGE (COPY CVEXPORT); the file's own record is a plain
01 … PIC X(500). The COBOL Language Reference requires the key to be described
within a record description entry of that file — Enterprise COBOL fails it with
IGYPS2121-S. |
The key is declared inside the FD record, at the same offset and length. The record image
and every READ/WRITE are untouched. |
| CBEXPORT.jcl JCL |
The IDCAMS DEFINE says KEYS(4 28); IDCAMS offsets are 0-based and
the key sits at 27, so the cluster's key would not match the program's and the file would not
open. |
KEYS(4 27). |
| CBIMPORT.jcl JCL |
No CARDOUT DD for the program's card output file. |
The DD added. |
The corrected members are marked at the point of change so anyone can diff them against upstream. A platform that accepts everything is not a compatible one; catching what the IBM compiler would catch is part of running the application faithfully.
CICSSFRM CONNECTED.DUSRSECJ):
| User ID | Password | Type | Lands on |
|---|---|---|---|
| ADMIN001 | PASSWORD | Admin (A) | Admin menu, transaction CA00 |
| USER0001 | PASSWORD | User (U) | Main menu, transaction CM00 |
Layout sketch of the sign-on header (not a capture — the real map also carries CardDemo's ASCII-art banner):
Keys. F1–F12 send PF1–PF12, Shift+F1–F12 send PF13–PF24, Esc sends CLEAR, Enter is Enter. Alt+1 is PA1 and is the one key handled locally: it leaves the 3270 session and returns to ISPF. Inside CardDemo, F3 steps back one screen (from a menu it returns to the sign-on), a menu option is its number plus Enter, and list screens page with F7/F8. Every screen prints its transaction and program in the top-left, which is the quickest way to know where you are.
CardDemo is pseudo-conversational: each screen is a separate transaction and program, and the menus
XCTL to the option you pick. The option lists below are the ones compiled into the menu
programs (copybooks COMEN02Y and COADM02Y); the transaction-to-program mapping
is the CSD as installed on this engine.
| Transaction | Program | Mapset | Function |
|---|---|---|---|
| CC00 | COSGN00C | COSGN00 | Sign-on; routes admin users to CA00, regular users to CM00 |
CM00 / COMEN01C (regular users)| Option | Title | Transaction | Program | Mapset |
|---|---|---|---|---|
| 1 | Account View | CAVW | COACTVWC | COACTVW |
| 2 | Account Update | CAUP | COACTUPC | COACTUP |
| 3 | Credit Card List | CCLI | COCRDLIC | COCRDLI |
| 4 | Credit Card View | CCDL | COCRDSLC | COCRDSL |
| 5 | Credit Card Update | CCUP | COCRDUPC | COCRDUP |
| 6 | Transaction List | CT00 | COTRN00C | COTRN00 |
| 7 | Transaction View | CT01 | COTRN01C | COTRN01 |
| 8 | Transaction Add | CT02 | COTRN02C | COTRN02 |
| 9 | Transaction Reports | CR00 | CORPT00C | CORPT00 |
| 10 | Bill Payment | CB00 | COBIL00C | COBIL00 |
| 11 | Pending Authorization View | CPVS | COPAUS0C | COPAU00 |
Option 9 (Transaction Reports) submits the TRANREPT batch job through the internal
reader — the online side asks for a date range, batch produces the report. Option 11 belongs to the optional
IMS/Db2/MQ authorization feature; its detail screen is CPVD / COPAUS1C /
COPAU01, and the MQ-triggered processor is CP00 / COPAUA0C.
CA00 / COADM01C (admin users)| Option | Title | Transaction | Program | Mapset |
|---|---|---|---|---|
| 1 | User List (Security) | CU00 | COUSR00C | COUSR00 |
| 2 | User Add (Security) | CU01 | COUSR01C | COUSR01 |
| 3 | User Update (Security) | CU02 | COUSR02C | COUSR02 |
| 4 | User Delete (Security) | CU03 | COUSR03C | COUSR03 |
| 5 | Transaction Type List/Update (Db2) | CTLI | COTRTLIC | COTRTLI |
| 6 | Transaction Type Maintenance (Db2) | CTTU | COTRTUPC | COTRTUP |
Options 5 and 6 read and update the Db2 tables created by CREADB21. Option 5 lists the
seven shipped transaction types and pages with F7/F8:
"REVERAL" is spelled that way in the official load data; it is reproduced, not corrected.
| Transaction | Program | Feature | Function |
|---|---|---|---|
| CDRD | CODATE01 | MQ | Inquire system date via an MQ request/response |
| CDRA | COACCT01 | MQ | Inquire account details via MQ |
| CP00 | COPAUA0C | IMS + Db2 + MQ | MQ-triggered authorization request processor (IMS insert/update, Db2 fraud table) |
| CPVS | COPAUS0C | IMS + Db2 + MQ | Pending authorization summary (IMS + VSAM) |
| CPVD | COPAUS1C | IMS + Db2 + MQ | Pending authorization detail (IMS update, Db2 insert) |
The JCL lives in CARDDEMO.JCL; the batch load library is AWS.M2.CARDDEMO.LOADLIB.
Submit from ISPF (option 6, SUBMIT 'CARDDEMO.JCL(POSTTRAN)') or from the edit panel, and read
the output in SDSF. The order below is the one AWS documents for a full cycle; the program column is taken
from each member's EXEC statements as installed.
| # | Job | Program | Purpose | Feature |
|---|---|---|---|---|
| 1 | CLOSEFIL | SDSF | Close the VSAM files in CICS before batch touches them | |
| 2 | ACCTFILE | IDCAMS | Define and load the account master from sample data | |
| 3 | CARDFILE | IDCAMS | Define and load the card master (+ AIX by account) | |
| 4 | XREFFILE | IDCAMS | Load the customer–card–account cross reference (+ AIX) | |
| 5 | CUSTFILE | IDCAMS | Define and load the customer master | |
| 6 | TRANBKP | IDCAMS | Create the transaction master (first run) / back it up (later runs) | |
| 7 | TRANEXTR | DSNTIAUL | Extract the latest transaction types and categories from Db2 into GDGs | Db2 |
| 8 | TRANCATG | IDCAMS | Copy the transaction category file to VSAM | |
| 9 | TRANTYPE | IDCAMS | Copy the transaction type file to VSAM | |
| 10 | DISCGRP | IDCAMS | Load the disclosure-group file | |
| 11 | TCATBALF | IDCAMS | Load the transaction-category balance file | |
| 12 | DUSRSECJ | IEBGENER + IDCAMS | Load the user security file (the sign-on users above) | |
| 13 | POSTTRAN | CBTRN02C | Core transaction posting — validates each daily transaction, posts to accounts and category balances, writes rejects | |
| 14 | INTCALC | CBACT04C | Interest calculation by category balance and disclosure group | |
| 15 | TRANBKP | IDCAMS | Back up the transaction master | |
| 16 | COMBTRAN | SORT + IDCAMS | Combine system-generated transactions with the daily ones | |
| 17 | CREASTMT | CBSTM03A | Produce statements (text and HTML) per customer | |
| 18 | TRANIDX | IDCAMS | Define the alternate index on the transaction file | |
| 19 | OPENFIL | SDSF | Re-open the files in CICS | |
| 20 | WAITSTEP | COBSWAIT | Timed wait step (scheduler demonstration) | |
| 21 | CBPAUP0J | DFSRRC00 → CBPAUP0C | Purge expired authorizations | IMS + Db2 + MQ |
| Job | Program | Purpose |
|---|---|---|
| READACCT / READCARD / READCUST / READXREF | CBACT01C / CBACT02C / CBCUS01C / CBACT03C | Read-and-print utilities for the four masters; READACCT also reformats dates through the assembler routine COBDATFT |
| TRANREPT | SORT + CBTRN03C | Transaction report for a date range — normally submitted from the online Transaction Reports option |
| TRANFILE | IDCAMS | Initialise the transaction KSDS from the daily transaction data |
| CBEXPORT / CBIMPORT | CBEXPORT / CBIMPORT | Export the five masters into one keyed export file, and import them back into normalized files (§B) |
| CREADB21 | IKJEFT01 (DSNTIAD / DSNTEP4) | Create the Db2 database, tablespaces, tables, indexes; load 7 transaction types and 18 categories |
| MNTTRDB2 | IKJEFT01 → COBTUPDT | Batch maintenance of the transaction-type table from a 53-byte action deck (add / update / delete) |
| DEFGDGB / DEFGDGD | IDCAMS (+ IEBGENER) | Define the GDG bases used by the backups and the Db2 extracts |
| DEFCUST, ESDSRRDS, REPTFILE, DALYREJS, PRTCATBL | IDCAMS / SORT | Dataset setup: customer define, ESDS/RRDS examples, report file, daily-reject file, category-balance print |
| INTRDRJ1 / INTRDRJ2 | IDCAMS + IEBGENER | Internal-reader demonstration (job that submits a job) |
| CBADMCDJ | DFHCSDUP | CSD utility deck for the CardDemo resource group |
| FTPJCL, TXT2PDF1 | FTP, IKJEFT1B | Transfer and PDF-conversion utilities as published |
| DBPAUTP0 | DFSRRC00 → DFSURGU0 | IMS HD Reorganization Unload of the authorization database DBPAUTP0 (as published; its output is the shipped AWS.M2.CARDDEMO.IMSDATA.DBPAUTP0) |
| RELDPADB | DFSRRC00 → DFSURGL0 | The one member we authored — the HD Reorganization Reload that CardDemo does not ship: loads the shipped unload back into DBPAUTP0 (22 authorization summaries, 202 details). Run it once after install; the IMS screens (CPVS/CPVD) and the purge job then have data. |
| UNLDPADB, LOADPADB, UNLDGSAM | DFSRRC00 | IMS flat-file unload/load through GSAM. As published these expect datasets produced at your site (the flat files one job writes for the other) — run UNLDPADB first. |
CardDemo does not only ship the jobs — it ships its production schedule, in both formats a
mainframe shop exports: a CA-7 LJOB,LIST=ALL report (CardDemo.ca7: the
17-job trigger graph — CLOSEFIL triggers the readers, the statement run, the purge; each
of those triggers the next; three schedule-id variants 030/031/032) and a Control-M folder export
(CardDemo.controlm: four SMART folders — DAILY-TransactionBackup,
WEEKLY-TransactionTypesDBRefresh, WEEKLY-DisclosureGroupsRefresh,
MONTHLY-InterestCalculation — chained by IN/OUT conditions, one folder waiting on another's
condition). SteelFrame's scheduler imports both definition files verbatim: 32 job definitions
naming 23 scheduled jobs over 21 JCL members — their triggers, conditions and schedule-ids are AWS's,
not ours.
The schedule is active on this system and the batch actually runs under it. The verified result, cycle by cycle:
| Mechanism | What ran | Result |
|---|---|---|
| CA-7 trigger closure SCHID=030 | CLOSEFIL → TRANTYPE, READACCT→READCARD→READCUST→READXREF, CREASTMT→TXT2PDF1, CBPAUP0J→POSTTRAN → WAITSTEP → OPENFIL | every trigger fired in order; 9 of the 12 jobs RC 0; TXT2PDF1 and CBPAUP0J fail (below), and because CBPAUP0J is POSTTRAN's only trigger, CA-7 leaves POSTTRAN waiting — demanded on its own it ends RC 4 |
| CA-7 SCHID=031 | CLOSEFIL1 → TRANCATG → WAITSTEP → OPENFIL → CLOSEFIL → PRTCATBL | all RC 0, cycle ended OK |
| CA-7 SCHID=032 | CLOSEFIL2 → TCATBALF → WAITSTEP | all RC 0, cycle ended OK |
| Control-M folders | DAILY: CLOSEFIL→TRANBKP→WAITSTEP→OPENFIL · WEEKLY-TT: MNTTRDB2→TRANEXTR · WEEKLY-DG: (waits on the weekly MNTTRDB2 condition) CLOSEFIL→DISCGRP→WAITSTEP→OPENFIL · MONTHLY: CLOSEFIL→INTCALC→COMBTRAN→WAITSTEP→OPENFIL | all four folders ran to ENDED-OK; the cross-folder condition released the dependent folder; every job RC 0 except COMBTRAN RC 4 |
Of the 23 scheduled jobs, 19 end RC 0 and two end RC 4 by design: POSTTRAN (see the
return-code note below) and COMBTRAN (its IDCAMS REPRO into the transaction file
reports IDC3013I DUPLICATE RECORD for records the daily run had already posted — the same
condition code a z/OS run gives once the file holds them). The two that fail are not scheduler
faults and are reported exactly as they happen:
CBPAUP0J (the nightly authorization purge, an IMS BMP) reads the reloaded database,
deletes every expired detail under a summary, then deletes the summary — and abends U1041.
The detail loop ends on a GNP that returns GE, and IMS's rule is that a
DLET must directly follow a Get-Hold, so the summary DLET gets status
DJ — a status EXEC DLI does not return to a batch program; it abends U1041 instead. That
sequence is in CardDemo's CBPAUP0C source; SteelFrame reproduces it rather than hides it.TXT2PDF1 ends in a JCL error: its STEPLIB names
AWS.M2.LBD.TXT2PDF.LOAD, the load library of the third-party TXT2PDF utility, which CardDemo
does not ship (it is not a CardDemo program) — the same JCL error a z/OS shop without that product gets.To drive the schedule yourself: PGM=ZWSCHED,PARM='DEMAND,JOB=CLOSEFIL,SCHID=030'
demands a CA-7 job and its trigger closure; PARM='ORDER,FOLDER=DAILY-TransactionBackup'
orders a Control-M folder; the scheduler page shows each cycle's jobs, triggers, conditions and log.
WAITSTEP really waits — COBSWAIT calls the MVSWAIT timer for the
36 seconds its SYSIN asks for — so a full cycle takes a few minutes.
POSTTRAN ends with RC 4 when it rejects transactions — the
shipped daily data deliberately contains transactions that fail validation, so RC 4 with a non-empty
reject file is the expected result, not a failure. INTCALC, TRANREPT and
CREASTMT likewise return 0 or 4 by design.| CICS FILE | Dataset | Content |
|---|---|---|
| ACCTDAT | AWS.M2.CARDDEMO.ACCTDATA.VSAM.KSDS | Account master |
| CARDDAT | AWS.M2.CARDDEMO.CARDDATA.VSAM.KSDS | Card master |
| CARDAIX | AWS.M2.CARDDEMO.CARDDATA.VSAM.AIX.PATH | Cards by account (alternate index path) |
| CUSTDAT | AWS.M2.CARDDEMO.CUSTDATA.VSAM.KSDS | Customer master |
| CCXREF | AWS.M2.CARDDEMO.CARDXREF.VSAM.KSDS | Card → customer → account cross reference |
| CXACAIX | AWS.M2.CARDDEMO.CARDXREF.VSAM.AIX.PATH | Cross reference by account (alternate index path) |
| TRANSACT | AWS.M2.CARDDEMO.TRANSACT.VSAM.KSDS | Posted transactions |
| USRSEC | AWS.M2.CARDDEMO.USRSEC.VSAM.KSDS | User security (sign-on users) |
Batch-only VSAM: AWS.M2.CARDDEMO.TRANTYPE, TRANCATG, DISCGRP,
TCATBALF (all .VSAM.KSDS), plus the sequential twins (ACCTDATA.PS,
DALYTRAN.PS, the TRANBKP / TRANTYPE.BKUP / TRANCATG.PS.BKUP
generation groups) and the export file AWS.M2.CARDDEMO.EXPORT.DATA.PS.
| Library | Holds |
|---|---|
| CARDDEMO.SOURCE | The 44 COBOL programs (online and batch, base and optional features) |
| CARDDEMO.BMS | The 21 BMS mapsets |
| CARDDEMO.COPYLIB | Record layouts, menu tables, symbolic maps, DCLGENs, IMS PCB masks, MQ copybooks |
| CARDDEMO.JCL | All jobs in §E |
| CARDDEMO.CSD | The four official CSD decks (CARDDEMO, CRDDEMOD, CRDDEMOM, CRDDEMO2) |
| CARDDEMO.DDL | Db2 DDL: TRNTYPE, TRNTYCAT, AUTHFRDS and their indexes |
| CARDDEMO.IMS.DBDSRC / PSBSRC | IMS DBD and PSB source (four each); generated into OEM.IMS.IMSP.DBDLIB / PSBLIB |
| AWS.M2.CARDDEMO.LOADLIB | Batch load modules (STEPLIB of the shipped JCL) |
| AWS.M2.CARDDEMO.CNTL | Control cards for the Db2 jobs (DB2CREAT, DB2FREE, DB2LTTYP, DB2LTCAT, …) |
| Table | Rows shipped | Used by |
|---|---|---|
| CARDDEMO.TRANSACTION_TYPE | 7 | CTLI, CTTU, COBTUPDT, TRANEXTR |
| CARDDEMO.TRANSACTION_TYPE_CATEGORY | 18 | TRANEXTR |
| CARDDEMO.AUTHFRDS | 0 (no data shipped) | COPAUS1C, COPAUS2C |
To recompile anything, the compiling manual covers the procedures;
CardDemo programs compile with IGYWCL and SYSLIB pointing at
CARDDEMO.COPYLIB, the CICS ones through the CICS translator and the Db2 ones through the
precompiler, exactly as their headers expect.
CardDemo is developed and published by Amazon Web Services at github.com/aws-samples/aws-mainframe-modernization-carddemo under the Apache License 2.0. The copy on this engine was taken from that repository. The source corrections in §B are ours, made under that licence, marked in the affected members, and described here so that anyone can compare the installed members with upstream. We have not modified the application in any other way, and we do not represent this work as AWS's. If you are evaluating SteelFrame, the strongest test is the one CardDemo was built for: bring the official source, compile it here, and compare the results with your own system.