• Jobs
  • Support
Sign in
  • Jobs
  • Support
    • Developer Overview
  • Business Context

    • Business Overview
    • Business Rules Summary
    • Business Glossary
  • Architecture Documentation

    • System Architecture
      • Introduction
      • High-Level System Architecture
      • Technology Stack
      • Major System Components
      • Deployment Architecture
      • Integration Patterns
      • AWS M2 Modernization
      • Performance Characteristics
      • Security Architecture
      • Scalability Considerations
      • Key Design Decisions
    • Component Catalog
    • Data Flow
    • Database Schema
    • Integration Points
  • Sign in
DocumentationCode Explorer
Loading...
Hypercubic

© Copyright 2025. All rights reserved.

On this page

  1. Introduction
  2. High-Level System Architecture
  3. Technology Stack
  4. Major System Components
  5. Deployment Architecture
  6. Integration Patterns
  7. AWS M2 Modernization
  8. Performance Characteristics
  9. Security Architecture
  10. Scalability Considerations
  11. Key Design Decisions

System Architecture Overview

Introduction

The AWS CardDemo application is a comprehensive mainframe credit card management system designed to demonstrate modernization patterns for AWS Mainframe Modernization (AWS M2). The application implements a classic 3-tier mainframe architecture with online transaction processing (CICS), batch processing, and multiple data storage technologies.

High-Level System Architecture

Loading diagram...

Technology Stack

Core Technologies

TechnologyPurposeComponent Count
COBOLBusiness logic39 programs (~28,000 LOC)
CICSOnline transaction processing25 transactions
VSAMPrimary data storage7 KSDS files + 3 AIX
BMSScreen definitions17 mapsets
JCLBatch job orchestration47 jobs

Optional Extension Technologies

TechnologyPurposeUsed In
DB2Relational databaseTransaction types, fraud tracking
IMS DBHierarchical databaseAuthorization storage
IBM MQAsynchronous messagingAuthorization requests, data extraction

Major System Components

1. CICS Online Transaction Processing

Purpose: Real-time user interactions for credit card management

Key Programs:

Loading diagram...

Transaction Categories:

  • Entry & Navigation: CC00, CM00, CA00 (3 programs)
  • Account Management: CAVW, CAUP (2 programs)
  • Card Management: CCLI, CCDL, CCUP (3 programs)
  • Transaction Processing: CT00, CT01, CT02 (3 programs)
  • User Administration: CU00-CU03 (4 programs)
  • Billing & Reports: CB00, CR00 (2 programs)
  • Authorization: CP00, CPVS, CPVD (3 programs - optional)
  • DB2 Extensions: CTLI, CTTU (2 programs - optional)
  • MQ Extensions: CDRA, CDRD (2 programs - optional)

Design Patterns:

  • Pseudo-Conversational: Tasks terminate between user interactions
  • COMMAREA: State management across conversation cycles
  • XCTL: Program chaining without return
  • BMS: 3270 screen handling

2. Batch Processing Subsystem

Purpose: Scheduled background processing for bulk operations

Processing Cycles:

Loading diagram...

Key Programs:

  • Transaction Processing: CBTRN01C, CBTRN02C, CBTRN03C
  • Account Processing: CBACT01C, CBACT02C, CBACT03C, CBACT04C
  • Customer Processing: CBCUS01C
  • Statement Generation: CBSTM03A
  • Utilities: CBIMPORT, CBEXPORT

3. Data Storage Layer

VSAM File Organization:

Loading diagram...

File Specifications:

FileTypeKeyRecord SizePurpose
ACCTDATKSDSACCT-ID (11)300 bytesAccount master
CUSTDATKSDSCUST-ID (9)500 bytesCustomer master
CARDDATKSDSCARD-NUM (16)150 bytesCard master
CCXREFKSDSCARD-NUM (16)50 bytesCard-account xref
TRANSACTKSDSTRAN-ID (16)350 bytesTransaction master
USRSECKSDSUSER-ID (8)100 bytesUser security
DISCGRPKSDSGROUP-ID (10)200 bytesInterest rates

Alternate Indexes:

  • CARDAIX: Access cards by account ID
  • CXACAIX: Access xref by account ID
  • Transaction AIX: Access transactions by timestamp

Deployment Architecture

Modular Architecture

The application uses a modular design with optional extensions:

Loading diagram...

Deployment Variants

Variant 1: Base (VSAM Only)

  • Components: Core CICS + VSAM + Batch
  • Complexity: Low
  • Use Case: Pure rehosting
  • Migration Effort: Minimal

Variant 2: Base + DB2

  • Components: Core + Transaction Type DB2 Extension
  • Complexity: Medium
  • Use Case: Gradual data modernization
  • Migration Effort: Medium

Variant 3: Base + MQ

  • Components: Core + MQ Integration Extension
  • Complexity: Low-Medium
  • Use Case: Service enablement
  • Migration Effort: Low

Variant 4: Full Integration

  • Components: Core + All Extensions (DB2 + IMS + MQ)
  • Complexity: High
  • Use Case: Comprehensive modernization demo
  • Migration Effort: High

Integration Patterns

1. CICS to VSAM (Synchronous)

Loading diagram...

Characteristics:

  • Direct file I/O via EXEC CICS
  • Record-level locking
  • ACID compliance via CICS
  • Synchronous operations

2. CICS to DB2 (Embedded SQL)

Loading diagram...

Characteristics:

  • Static embedded SQL
  • Two-phase commit
  • Cursor processing
  • SQLCA error handling

3. MQ Message Processing (Asynchronous)

Loading diagram...

Characteristics:

  • Asynchronous messaging
  • Request/response pattern
  • Message correlation
  • Decoupled processing

4. IMS Database Access (Hierarchical)

Loading diagram...

Characteristics:

  • Hierarchical navigation
  • Parent-child relationships
  • Position-based access
  • Two-phase commit with CICS

AWS M2 Modernization

Rehosting to AWS M2

Loading diagram...

Migration Options:

  1. Replatform (Lift and Shift)

    • Target: AWS M2 with Micro Focus
    • COBOL code: Minimal changes
    • Data: VSAM emulation or conversion
    • Timeline: 3-6 months
  2. Replatform + Optimize

    • Target: AWS M2 with database backend
    • Replace VSAM with Amazon RDS
    • Maintain COBOL business logic
    • Timeline: 6-12 months
  3. Refactor (Blu Age)

    • Target: Java/Spring Boot
    • Automated COBOL to Java conversion
    • Modern UI (Angular/React)
    • Timeline: 12-18 months

AWS Service Mapping

Mainframe ComponentAWS ServicePurpose
CICS RegionAWS M2 RuntimeTransaction processing
VSAM FilesAmazon RDS / DynamoDBStructured data
DB2Amazon RDS PostgreSQLRelational database
IMSAmazon RDSHierarchical to relational
IBM MQAmazon MQMessage queuing
JCL JobsAWS Batch / Step FunctionsBatch orchestration
3270 TerminalTN3270 Emulator / Web UIUser interface
SYSOUT/LogsCloudWatch LogsLogging

Performance Characteristics

Online Processing

MetricTargetNotes
Transaction Response Time< 2 secondsEnd-to-end
VSAM Random Access< 10msSingle record read
DB2 Query Response< 100msSimple lookup
Concurrent Users100+Pseudo-conversational design

Batch Processing

JobFrequencyTypical DurationVolume
Transaction PostingDaily2-5 minutes1K-10K transactions
Interest CalculationMonthly5-15 minutesAll active accounts
Statement GenerationMonthly15-30 minutesAll cards

Security Architecture

Authentication Flow

Loading diagram...

Security Features:

  • VSAM-based user authentication
  • Role-based access (Admin/User)
  • Transaction-level authorization
  • Password validation
  • Session management via COMMAREA

Data Security

  • VSAM: Share options control concurrent access
  • DB2: Row-level security via SQL predicates
  • Encryption: Can be enabled at storage level
  • Audit: Transaction logging in CICS

Scalability Considerations

Horizontal Scaling

  • Multiple CICS regions
  • Load balancing across regions
  • Shared VSAM files with proper share options
  • Connection pooling for DB2

Vertical Scaling

  • CICS region size (memory)
  • Database buffer pools
  • Batch job parallelization
  • File system performance tuning

Key Design Decisions

  1. VSAM for Core Data: Fast indexed access, proven reliability
  2. DB2 for Reference Data: Easier maintenance, SQL capabilities
  3. Pseudo-Conversational CICS: Optimal resource utilization
  4. Modular Extensions: Incremental modernization support
  5. Batch Window Approach: Separate online and batch processing
  6. GDG for Versioning: Historical data retention
  7. XCTL for Navigation: Memory-efficient program chaining

Was this page helpful?