Integration Points Documentation

Overview

The Insurance Management System (INSMASTR) employs a hybrid integration architecture combining sequential file processing with relational database persistence. The system interfaces with upstream and downstream systems through eight sequential files and maintains persistent state in DB2 database tables. All integration points follow batch processing patterns typical of mainframe environments, with no real-time or online transaction processing capabilities.

Integration Architecture Summary

The system operates on a batch-oriented integration model with the following characteristics:

• File-based input/output: Decoupled from source systems through sequential files
• Database persistence: Transactional data stored in DB2 for long-term management
• Scheduled execution: JCL-controlled batch processing with configurable modes
• Asynchronous processing: No real-time integration or event-driven capabilities
• Transaction management: Commit points every 500 records with rollback support

Processing Modes

The system supports four distinct processing modes controlled via JCL PARM parameter:

File-Based Integration Points

File Integration Overview

The system processes eight sequential files organized into three input files, three output files, one error file, and one reporting file. All files use fixed-length record formats with sequential organization and access patterns optimized for mainframe batch processing.

File Record Layout Diagram

┌──────────────────────────────────────────────────────────────────┐
│                    FILE INTEGRATION ARCHITECTURE                  │
└──────────────────────────────────────────────────────────────────┘

UPSTREAM SYSTEMS                 INSMASTR PROGRAM              DOWNSTREAM SYSTEMS

┌─────────────────┐              ┌──────────────┐              ┌─────────────────┐
│  Policy System  │──────────────┤ POLICY-IN    │              │                 │
│                 │  800 bytes   │ (POLFILE)    │              │                 │
└─────────────────┘              └──────────────┘              │                 │
                                        │                       │                 │
                                        ▼                       │                 │
┌─────────────────┐              ┌──────────────┐              │                 │
│ Renewal System  │──────────────┤ RENEWAL-IN   │              │                 │
│                 │  600 bytes   │ (RENFILE)    │              │                 │
└─────────────────┘              └──────────────┘              │                 │
                                        │                       │                 │
                                        ▼                       │                 │
┌─────────────────┐              ┌──────────────┐              │                 │
│  Claims System  │──────────────┤ CLAIM-IN     │              │                 │
│                 │  900 bytes   │ (CLMFILE)    │              │                 │
└─────────────────┘              └──────────────┘              │                 │
                                        │                       │                 │
                                        ▼                       │                 │
                                 ┌────────────────┐             │                 │
                                 │   PROCESSING   │             │                 │
                                 │   VALIDATION   │             │                 │
                                 │   CALCULATION  │             │                 │
                                 │   DB2 OPS      │             │                 │
                                 └────────────────┘             │                 │
                                        │                       │                 │
                    ┌───────────────────┼───────────────────┐   │                 │
                    ▼                   ▼                   ▼   │                 │
              ┌──────────────┐    ┌──────────────┐   ┌──────────────┐            │
              │ POLICY-OUT   │    │ RENEWAL-OUT  │   │  CLAIM-OUT   │            │
              │ (POLOUT)     │───▶│  (RENOUT)    │──▶│  (CLMOUT)    │───────────▶│ Processing
              │  500 bytes   │    │  500 bytes   │   │  500 bytes   │            │ Systems
              └──────────────┘    └──────────────┘   └──────────────┘            │
                                        │                                         │
                                        ▼                                         │
                                  ┌──────────────┐                                │
                                  │  ERROR-FILE  │───────────────────────────────▶│ Error
                                  │  (ERRFILE)   │                                │ Management
                                  │  250 bytes   │                                │
                                  └──────────────┘                                │
                                        │                                         │
                                        ▼                                         │
                                  ┌──────────────┐                                │
                                  │ REPORT-FILE  │───────────────────────────────▶│ Reporting
                                  │  (RPTFILE)   │                                │ Systems
                                  │  133 bytes   │                                │
                                  └──────────────┘                                │
                                                                                  │
                                                                  └───────────────┘

1. POLICY-INPUT-FILE (POLFILE)

Interface Characteristics

Data Format and Structure

The policy input file contains new insurance policy applications with comprehensive customer and policy information:

Record Types:

• HD (Header): File header record (skipped during processing)
• DT (Detail): Policy application detail record
• TR (Trailer): File trailer record (skipped during processing)

Key Data Elements:

• Customer identification: Number (10 digits), Name (50 chars), SSN (9 digits)
• Demographics: Date of birth, Gender, Marital status
• Address: Street, City, State, ZIP, Country
• Contact: Phone numbers, Email
• Insurance details: Type (HEALTH/LIFE/AUTO/PROPERTY/DENTAL/VISION)
• Financial: Coverage amount, Deductible, Out-of-pocket maximum, Payment method
• Risk factors: Smoker flag, Pre-existing conditions, Occupation, Annual income
• Additional: Beneficiary information, Agent code, Promotional codes

Processing Flow

1. File opened during initialization (1100-OPEN-FILES section)
2. Records read sequentially in 800-byte chunks
3. File status checked after each read operation
4. EOF detected via file status '10'
5. Each valid detail record processed through 2100-PROCESS-POLICY-RECORD
6. File closed during finalization (9200-CLOSE-FILES section)

Error Handling

• File Status '00': Success, continue processing
• File Status '10': End of file, set POL-END-OF-FILE flag
• Other Status: Invoke error handler (8000-ERROR-HANDLER), may abort if critical
• Validation Errors: Logged to ERROR-FILE, processing continues with next record
• Critical Errors: File open failures result in return code 12 and program abort

2. RENEWAL-INPUT-FILE (RENFILE)

Interface Characteristics

Data Format and Structure

The renewal input file contains policy renewal requests for existing customers:

Record Types:

• HD (Header): File header record
• DT (Detail): Renewal request detail record
• TR (Trailer): File trailer record

Key Data Elements:

• Policy identification: Existing policy number (15 digits)
• Customer identification: Customer number (10 digits), Name (50 chars)
• Renewal type: Standard (ST), Upgrade (UP), Downgrade (DN), Multi-year (MY)
• Terms: Current expiry date, Renewal term (12/24/36 months)
• Coverage modifications: Requested coverage amount, New deductible
• Riders: Array of up to 5 rider codes
• Payment: Payment method, Auto-renewal flag
• Discounts: Loyalty years, No-claims years, Multi-policy flag
• Discount codes: Array of up to 5 discount codes with percentages

Processing Flow

1. File opened during initialization if processing mode includes renewals
2. Records read sequentially in 600-byte chunks
3. Each renewal validated against existing policy in database
4. Renewal premium calculated with applicable discounts
5. New policy created with updated terms
6. Old policy status updated to 'RENEWED'
7. EOF detected and file closed during finalization

Error Handling

• Policy Not Found: Error logged, record skipped
• Invalid Renewal Type: Validation error, record rejected
• Database Errors: Automatic rollback, error logged
• File Status Errors: Standard file error handling

3. CLAIMS-INPUT-FILE (CLMFILE)

Interface Characteristics

Data Format and Structure

The claims input file contains insurance claim submissions with comprehensive claim details:

Record Types:

• HD (Header): File header record
• DT (Detail): Claim submission detail record
• TR (Trailer): File trailer record

Key Data Elements:

• Claim identification: Claim number (15 chars), Policy number (15 digits)
• Customer: Customer number, Name
• Claim type: MEDICAL, HOSPITAL, EMERGENCY, DENTAL, VISION, AUTO, PROPERTY
• Dates: Incident date, Claim date, Report date
• Financial: Claim amount, Currency code (USD)
• Provider information: Code, Name, Type, Network flag, Tax ID
• Medical details: Diagnosis code/description, Procedure code/description, DRG code
• Hospital: Admission/discharge dates, Length of stay, Emergency flag
• Auto claims: Police report number, Other party info, Damage estimate
• Documentation: Receipt, Invoice, Prescription, X-ray, Lab results flags
• Authorization: Pre-auth code, Referral code, Override code

Processing Flow

1. File opened during initialization if processing mode includes claims
2. Records read sequentially in 900-byte chunks
3. Policy verified and retrieved from database
4. Duplicate claim check performed
5. Fraud detection analysis executed (4-component algorithm)
6. Claim payment calculated with deductible/copay/coinsurance
7. Claim record inserted into database
8. Policy usage updated (deductible met, out-of-pocket met, claim count)
9. EOF detected and file closed during finalization

Fraud Detection Integration

Claims processing includes sophisticated fraud detection with database queries:

• Claim frequency check: Count claims in last 30 days
• Amount anomaly check: Flag unusually high amounts
• Provider history check: Verify provider fraud score
• Pattern detection: Check for duplicate claim patterns
• Decision logic: Scores >= 70 trigger investigation, >= 50 require manual review

Error Handling

• Policy Not Found: Claim rejected, error logged
• Duplicate Claim: Claim rejected, error logged
• Fraud Threshold Exceeded: Claim flagged for investigation
• Database Errors: Automatic rollback, error logged

4. POLICY-OUTPUT-FILE (POLOUT)

Interface Characteristics

Data Format and Structure

The policy output file contains successfully processed policy records with calculated premium and assigned policy numbers:

Output Data Elements:

• Assigned policy number (generated from POLICY_SEQ)
• Customer information (echoed from input)
• Insurance type and coverage details
• Calculated premium amount
• Risk score (0-100 scale)
• Policy status (ACTIVE)
• Policy start/end dates
• Payment frequency and method
• Processing timestamp

Processing Flow

1. File opened during initialization if processing mode includes policies
2. One record written for each successfully processed policy
3. Written by 2170-WRITE-POLICY-OUTPUT section
4. File status checked after each write
5. File closed during finalization with automatic RLSE (space release)

Error Handling

• Write Failures: Error logged, may trigger rollback
• File Full: Critical error, program may abort
• Successful Write: Counter incremented, processing continues

5. RENEWAL-OUTPUT-FILE (RENOUT)

Interface Characteristics

Data Format and Structure

The renewal output file contains successfully processed renewal records:

Output Data Elements:

• New policy number (generated from POLICY_SEQ)
• Old policy number (from input)
• Customer information
• Renewal type processed
• New premium with discounts applied
• Discount breakdown (loyalty, no-claims, multi-policy)
• New policy start/end dates
• Processing status
• Processing timestamp

Processing Flow

1. File opened during initialization if processing mode includes renewals
2. One record written for each successfully processed renewal
3. Written by 3160-WRITE-RENEWAL-OUTPUT section
4. File closed during finalization

6. CLAIMS-OUTPUT-FILE (CLMOUT)

Interface Characteristics

Data Format and Structure

The claims output file contains successfully processed claim records with payment decisions:

Output Data Elements:

• Claim ID (generated from CLAIM_SEQ)
• Claim number (from input)
• Policy and customer numbers
• Claim type and amount
• Approved amount
• Deductible applied
• Copay/coinsurance amounts
• Insurance payment amount
• Patient responsibility amount
• Claim status (PROCESSING/APPROVED/UNDER REVIEW)
• Approval status (AUTO-APPROVED/MANUAL REVIEW/INVESTIGATION REQUIRED)
• Fraud score and flags
• Processing timestamp

Processing Flow

1. File opened during initialization if processing mode includes claims
2. One record written for each processed claim (success or flagged)
3. Written by 4180-WRITE-CLAIM-OUTPUT section
4. File closed during finalization

7. ERROR-FILE (ERRFILE)

Interface Characteristics

Data Format and Structure

The error file captures all processing errors with detailed diagnostic information:

Error Record Format:

ERROR|<error-code>|<severity>|<error-message>|SQLCODE=<sqlcode>|<timestamp>

Data Elements:

• Error code (4 digits)
• Error severity: WARNING, SEVERE, CRITICAL
• Error message (descriptive text, 100 chars)
• Error paragraph (section where error occurred, 30 chars)
• SQLCODE (if database error)
• SQLERRMC (SQL error message)
• Error timestamp (26 chars)
• Record key causing error (50 chars)

Error Code Ranges

Processing Flow

1. File opened during initialization for all processing modes
2. Written by 8000-ERROR-HANDLER section whenever error occurs
3. All errors logged regardless of severity
4. File closed during finalization
5. Downstream monitoring systems parse error file for alerts

Error Handling

• Write to error file fails: Error displayed to console, processing continues
• Error file full: May cause program abort if critical
• Multiple errors for same record: Each error logged separately

8. REPORT-FILE (RPTFILE)

Interface Characteristics

Data Format and Structure

The report file contains formatted processing statistics and summary information:

Report Structure:

1. Header Section:

   • Program title: "INSURANCE MANAGEMENT SYSTEM"
   • Subtitle: "COMPREHENSIVE PROCESSING REPORT"
   • Date, Time, Program name, Version

2. Detail Section:

   • Column headers: FUNCTION, RECORD ID, STATUS, AMOUNT, MESSAGE
   • Processing details for key transactions
   • Status indicators: SUCCESS, ERROR, REVIEW, FLAGGED

3. Summary Section:

   • Total records read (by file type)
   • Total records processed successfully
   • Total records with errors
   • Processing duration
   • Return code

Carriage Control Characters:

• '1' = Form feed (new page)
• '0' = Double space
• ' ' = Single space
• '-' = Triple space

Processing Flow

1. File opened during initialization for all processing modes
2. Headers written by 1400-WRITE-REPORT-HEADERS section
3. Detail lines written during processing (optional)
4. Summary written by 9100-WRITE-SUMMARY-REPORT section
5. File closed during finalization
6. Typically directed to SYSOUT for printing or DASD for archival

Database Integration

Database Connection Architecture

The Insurance Management System integrates with DB2 for z/OS using embedded SQL through the DB2 precompiler. The database serves as the system of record for all insurance entities and maintains referential integrity across policies, customers, claims, and providers.

Connection Details

DB2 Connection Lifecycle

┌─────────────────────────────────────────────────────────────┐
│                  DB2 CONNECTION LIFECYCLE                    │
└─────────────────────────────────────────────────────────────┘

1000-INITIALIZE-PROGRAM
    │
    ├─► 1200-CONNECT-DB2
    │       ├─► EXEC SQL CONNECT TO INSPROD USER :WS-PROGRAM-NAME
    │       ├─► Check SQLCODE (must be 0 for success)
    │       ├─► Set isolation level CS
    │       ├─► Set lock timeout 30 seconds
    │       └─► Display connection confirmation
    │
    ▼
[PROCESSING PHASE]
    │
    ├─► Policy Processing (2000 series)
    │   ├─► SELECT (duplicate check)
    │   ├─► MERGE (customer)
    │   ├─► INSERT (policy)
    │   └─► COMMIT (every 500 records)
    │
    ├─► Renewal Processing (3000 series)
    │   ├─► SELECT (existing policy)
    │   ├─► INSERT (new policy)
    │   ├─► UPDATE (old policy)
    │   └─► COMMIT (every 500 records)
    │
    ├─► Claims Processing (4000 series)
    │   ├─► SELECT (policy, provider, fraud checks)
    │   ├─► INSERT (claim)
    │   ├─► UPDATE (policy usage)
    │   └─► COMMIT (every 500 records)
    │
    ▼
9000-FINALIZE-PROGRAM
    │
    ├─► 7000-COMMIT-WORK (final commit)
    │       └─► EXEC SQL COMMIT WORK
    │
    └─► 9300-DISCONNECT-DB2
            ├─► EXEC SQL RELEASE ALL
            ├─► EXEC SQL CONNECT RESET
            └─► Check SQLCODE

Database Tables and Operations

Table 1: POLICY_TABLE

Purpose: Master table for all insurance policies (active, renewed, expired)

Primary Operations:

• SELECT: Duplicate policy check, renewal policy retrieval
• INSERT: New policy creation, renewal policy creation
• UPDATE: Policy status changes, usage tracking (claims count, deductible met)

Key Fields:

• POLICY_NUMBER (PK, 15 digits) - Generated from POLICY_SEQ
• CUSTOMER_NUMBER (FK, 10 digits) - Links to CUSTOMER_TABLE
• INSURANCE_TYPE (10 chars) - HEALTH/LIFE/AUTO/PROPERTY/DENTAL/VISION
• POLICY_STATUS (10 chars) - ACTIVE/RENEWED/EXPIRED
• COVERAGE_AMOUNT, DEDUCTIBLE_AMOUNT, OUT_OF_POCKET_MAX (COMP-3)
• PREMIUM_AMOUNT (COMP-3)
• RISK_SCORE, FRAUD_SCORE (COMP-3)
• CLAIMS_COUNT, RENEWAL_COUNT
• RENEWAL_FROM_POLICY, RENEWAL_TO_POLICY (policy lineage)
• CREATED_DATE, CREATED_BY, LAST_UPDATE_DATE, UPDATED_BY (audit)

SQL Operations:

1. Duplicate Policy Check (Lines 1358-1365):

SELECT COUNT(*)
INTO :WS-DUPLICATE-COUNT
FROM POLICY_TABLE
WHERE CUSTOMER_NUMBER = :POL-CUSTOMER-NUMBER
  AND INSURANCE_TYPE = :POL-INSURANCE-TYPE
  AND POLICY_STATUS = 'ACTIVE'

2. Policy Insert (Lines 1697-1719):

INSERT INTO POLICY_TABLE
(POLICY_NUMBER, CUSTOMER_NUMBER, CUSTOMER_NAME,
 INSURANCE_TYPE, POLICY_START_DATE, POLICY_END_DATE,
 POLICY_TERM_MONTHS, POLICY_STATUS,
 COVERAGE_AMOUNT, DEDUCTIBLE_AMOUNT, DEDUCTIBLE_MET,
 OUT_OF_POCKET_MAX, OUT_OF_POCKET_MET,
 PREMIUM_AMOUNT, PAYMENT_FREQUENCY, PAYMENT_METHOD,
 RISK_SCORE, FRAUD_SCORE, CLAIMS_COUNT, RENEWAL_COUNT,
 CREATED_DATE, CREATED_BY)
VALUES
(:HV-POLICY-NUMBER, :HV-CUSTOMER-NUMBER, :HV-CUSTOMER-NAME,
 :HV-INSURANCE-TYPE, :HV-POLICY-START-DATE, :HV-POLICY-END-DATE,
 :HV-POLICY-TERM-MONTHS, 'ACTIVE',
 :HV-COVERAGE-AMOUNT, :HV-DEDUCTIBLE-AMOUNT, 0,
 :HV-OUT-OF-POCKET-MAX, 0,
 :HV-PREMIUM-AMOUNT, :HV-PAYMENT-FREQUENCY, :HV-PAYMENT-METHOD,
 :HV-RISK-SCORE, 0, 0, 0,
 CURRENT_TIMESTAMP, :WS-PROGRAM-NAME)

3. Policy Retrieval for Renewal (Lines 1906-1920):

SELECT CUSTOMER_NUMBER, CUSTOMER_NAME, INSURANCE_TYPE,
       COVERAGE_AMOUNT, PREMIUM_AMOUNT, DEDUCTIBLE_AMOUNT,
       POLICY_STATUS, POLICY_END_DATE, RISK_SCORE,
       CLAIMS_COUNT, RENEWAL_COUNT
INTO :HV-CUSTOMER-NUMBER, :HV-CUSTOMER-NAME, :HV-INSURANCE-TYPE,
     :HV-COVERAGE-AMOUNT, :HV-PREMIUM-AMOUNT, :HV-DEDUCTIBLE-AMOUNT,
     :HV-POLICY-STATUS, :HV-POLICY-END-DATE, :HV-RISK-SCORE,
     :HV-CLAIMS-COUNT, :HV-RENEWAL-COUNT
FROM POLICY_TABLE
WHERE POLICY_NUMBER = :REN-POLICY-NUMBER

4. Policy Status Update on Renewal (Lines 2146-2153):

UPDATE POLICY_TABLE
SET POLICY_STATUS = 'RENEWED',
    RENEWAL_TO_POLICY = :HV-POLICY-NUMBER,
    LAST_UPDATE_DATE = CURRENT_TIMESTAMP,
    UPDATED_BY = :WS-PROGRAM-NAME
WHERE POLICY_NUMBER = :REN-POLICY-NUMBER

5. Policy Usage Update after Claim (Lines 2774-2785):

UPDATE POLICY_TABLE
SET DEDUCTIBLE_MET = DEDUCTIBLE_MET + :WS-DEDUCTIBLE-APPLIED,
    OUT_OF_POCKET_MET = OUT_OF_POCKET_MET + :WS-PATIENT-PAYS,
    CLAIMS_COUNT = CLAIMS_COUNT + 1,
    LAST_CLAIM_DATE = CURRENT_DATE,
    LAST_UPDATE_DATE = CURRENT_TIMESTAMP,
    UPDATED_BY = :WS-PROGRAM-NAME
WHERE POLICY_NUMBER = :CLM-POLICY-NUMBER

Table 2: CLAIM_TABLE

Purpose: Repository for all insurance claims with payment decisions and fraud analysis

Primary Operations:

• SELECT: Duplicate claim check, fraud frequency analysis, pattern detection
• INSERT: New claim record creation

Key Fields:

• CLAIM_ID (PK, 10 digits) - Generated from CLAIM_SEQ
• CLAIM_NUMBER (15 chars) - External claim identifier
• POLICY_NUMBER (FK, 15 digits) - Links to POLICY_TABLE
• CUSTOMER_NUMBER (FK, 10 digits) - Links to CUSTOMER_TABLE
• CLAIM_TYPE (10 chars) - MEDICAL/HOSPITAL/EMERGENCY/etc.
• CLAIM_AMOUNT, APPROVED_AMOUNT (COMP-3)
• DEDUCTIBLE_APPLIED, COPAY_APPLIED, COINSURANCE_APPLIED (COMP-3)
• INSURANCE_PAID, PATIENT_RESPONSIBILITY (COMP-3)
• CLAIM_STATUS (20 chars) - PROCESSING/APPROVED/UNDER REVIEW
• APPROVAL_STATUS (20 chars) - AUTO-APPROVED/MANUAL REVIEW/INVESTIGATION REQUIRED
• PAYMENT_STATUS (20 chars)
• PROVIDER_CODE (10 chars) - Links to PROVIDER_TABLE
• DIAGNOSIS_CODE, PROCEDURE_CODE (10 chars)
• FRAUD_FLAG, FRAUD_SCORE, INVESTIGATION_FLAG
• CREATED_DATE, CREATED_BY (audit)

SQL Operations:

1. Duplicate Claim Check (Lines 2437-2442):

SELECT COUNT(*)
INTO :WS-DUPLICATE-COUNT
FROM CLAIM_TABLE
WHERE CLAIM_NUMBER = :CLM-CLAIM-NUMBER

2. Claim Frequency Check (Lines 2460-2466):

SELECT COUNT(*)
INTO :WS-ROW-COUNT
FROM CLAIM_TABLE
WHERE CUSTOMER_NUMBER = :CLM-CUSTOMER-NUMBER
  AND CLAIM_DATE >= CURRENT_DATE - 30 DAYS

3. Pattern Anomaly Detection (Lines 2513-2521):

SELECT COUNT(*)
INTO :WS-ROW-COUNT
FROM CLAIM_TABLE
WHERE CUSTOMER_NUMBER = :CLM-CUSTOMER-NUMBER
  AND CLAIM_TYPE = :CLM-CLAIM-TYPE
  AND CLAIM_AMOUNT = :CLM-CLAIM-AMOUNT
  AND CLAIM_DATE >= CURRENT_DATE - 90 DAYS

4. Claim Insert (Lines 2718-2747):

INSERT INTO CLAIM_TABLE
(CLAIM_ID, CLAIM_NUMBER, POLICY_NUMBER, CUSTOMER_NUMBER,
 CLAIM_TYPE, INCIDENT_DATE, CLAIM_DATE,
 CLAIM_AMOUNT, APPROVED_AMOUNT,
 DEDUCTIBLE_APPLIED, COPAY_APPLIED, COINSURANCE_APPLIED,
 INSURANCE_PAID, PATIENT_RESPONSIBILITY,
 CLAIM_STATUS, APPROVAL_STATUS, PAYMENT_STATUS,
 PROVIDER_CODE, PROVIDER_NAME,
 DIAGNOSIS_CODE, PROCEDURE_CODE,
 FRAUD_FLAG, FRAUD_SCORE, INVESTIGATION_FLAG,
 CREATED_DATE, CREATED_BY)
VALUES
(:HV-CLAIM-ID, :CLM-CLAIM-NUMBER, :CLM-POLICY-NUMBER, :CLM-CUSTOMER-NUMBER,
 :CLM-CLAIM-TYPE, :CLM-INCIDENT-DATE, :CLM-CLAIM-DATE,
 :CLM-CLAIM-AMOUNT, :WS-APPROVED-AMOUNT,
 :WS-DEDUCTIBLE-APPLIED, :WS-COPAY-AMOUNT, :WS-COINSURANCE-AMOUNT,
 :WS-INSURANCE-PAYS, :WS-PATIENT-PAYS,
 :HV-CLAIM-STATUS, :HV-APPROVAL-STATUS, :HV-PAYMENT-STATUS,
 :CLM-PROVIDER-CODE, :CLM-PROVIDER-NAME,
 :CLM-DIAGNOSIS-CODE, :CLM-PROCEDURE-CODE,
 :HV-FRAUD-FLAG, :WS-FRAUD-SCORE, :HV-INVESTIGATION-FLAG,
 CURRENT_TIMESTAMP, :WS-PROGRAM-NAME)

Table 3: CUSTOMER_TABLE

Purpose: Master customer repository with demographics and risk profile

Primary Operations:

• MERGE: Upsert customer information (insert new or update existing)

Key Fields:

• CUSTOMER_NUMBER (PK, 10 digits)
• CUSTOMER_NAME (50 chars)
• DOB, SSN, GENDER, MARITAL_STATUS
• ADDRESS (200 chars) - Composite field
• PHONE, EMAIL
• STATUS (10 chars) - ACTIVE/INACTIVE
• RISK_PROFILE (10 chars) - LOW/MEDIUM/HIGH
• CREDIT_SCORE (COMP-3)
• FRAUD_ALERT (Y/N)
• CREATED_DATE, CREATED_BY, LAST_UPDATE_DATE, UPDATED_BY (audit)

SQL Operations:

1. Customer MERGE (Lines 1597-1629):

MERGE INTO CUSTOMER_TABLE AS C
USING (VALUES(
    :POL-CUSTOMER-NUMBER,
    :POL-CUSTOMER-NAME,
    :POL-DATE-OF-BIRTH,
    :POL-SSN,
    :POL-GENDER,
    :POL-MARITAL-STATUS,
    :HV-CUST-ADDRESS,
    :POL-PHONE-PRIMARY,
    :POL-EMAIL,
    'ACTIVE',
    :HV-CUST-RISK-PROFILE,
    0
)) AS S(
    CUSTOMER_NUMBER, CUSTOMER_NAME, DOB, SSN, GENDER,
    MARITAL_STATUS, ADDRESS, PHONE, EMAIL, STATUS,
    RISK_PROFILE, CREDIT_SCORE
)
ON C.CUSTOMER_NUMBER = S.CUSTOMER_NUMBER
WHEN MATCHED THEN
    UPDATE SET
        CUSTOMER_NAME = S.CUSTOMER_NAME,
        ADDRESS = S.ADDRESS,
        PHONE = S.PHONE,
        EMAIL = S.EMAIL,
        LAST_UPDATE_DATE = CURRENT_TIMESTAMP,
        UPDATED_BY = :WS-PROGRAM-NAME
WHEN NOT MATCHED THEN
    INSERT (
        CUSTOMER_NUMBER, CUSTOMER_NAME, DOB, SSN, GENDER,
        MARITAL_STATUS, ADDRESS, PHONE, EMAIL, STATUS,
        RISK_PROFILE, CREDIT_SCORE, FRAUD_ALERT,
        CREATED_DATE, CREATED_BY
    )
    VALUES (
        S.CUSTOMER_NUMBER, S.CUSTOMER_NAME, S.DOB, S.SSN, S.GENDER,
        S.MARITAL_STATUS, S.ADDRESS, S.PHONE, S.EMAIL, S.STATUS,
        S.RISK_PROFILE, S.CREDIT_SCORE, 'N',
        CURRENT_TIMESTAMP, :WS-PROGRAM-NAME
    )

Table 4: PROVIDER_TABLE

Purpose: Healthcare and service provider registry with fraud scoring

Primary Operations:

• SELECT: Provider verification and fraud score retrieval

Key Fields:

• PROVIDER_CODE (PK, 10 chars)
• PROVIDER_NAME (50 chars)
• PROVIDER_TYPE (10 chars) - HOSPITAL/CLINIC/DOCTOR/LAB
• NETWORK_FLAG (Y/N) - In-network status
• ACTIVE_FLAG (Y/N) - Provider active status
• FRAUD_SCORE (COMP-3, 0-100) - Historical fraud indicator
• RATING (COMP-3, 1-5 with decimals) - Provider quality rating

SQL Operations:

1. Provider Fraud Check (Lines 2491-2496):

SELECT FRAUD_SCORE, ACTIVE_FLAG
INTO :HV-PROV-FRAUD-SCORE, :HV-PROV-ACTIVE-FLAG
FROM PROVIDER_TABLE
WHERE PROVIDER_CODE = :CLM-PROVIDER-CODE

DB2 Sequences

The system uses DB2 sequences for generating unique identifiers:

POLICY_SEQ

Purpose: Generate unique policy numbers for new and renewal policies

Usage:

SELECT NEXT VALUE FOR POLICY_SEQ
INTO :WS-POLICY-NUMBER
FROM SYSIBM.SYSDUMMY1

Invoked in:

• Policy creation (Lines 1645-1649)
• Renewal policy creation (Lines 2055-2059)

CLAIM_SEQ

Purpose: Generate unique claim IDs for new claims

Usage:

SELECT NEXT VALUE FOR CLAIM_SEQ
INTO :WS-CLAIM-ID
FROM SYSIBM.SYSDUMMY1

Invoked in:

• Claim creation (Lines 2675-2679)

DCLGEN (Data Declarations Generator)

The program uses DCLGEN-style host variable structures for type-safe database integration. All host variables are defined in WORKING-STORAGE with naming convention HV-* (host variable prefix):

• HV-POLICY-TABLE: Lines 640-664
• HV-CLAIM-TABLE: Lines 669-696
• HV-CUSTOMER-TABLE: Lines 701-715
• HV-PROVIDER-TABLE: Lines 720-727

These structures use COBOL data types compatible with DB2 column types:

• PIC 9(n): INTEGER or DECIMAL
• PIC X(n): CHAR or VARCHAR
• COMP-3: DECIMAL (packed decimal)
• COMP: INTEGER (binary)

Transaction Management

Commit Strategy

Commit Frequency: Every 500 records (configurable via WS-COMMIT-FREQUENCY constant)

Rationale:

• Balances transaction log size with recovery granularity
• Reduces lock contention on DB2 resources
• Enables restart from last commit point
• Prevents long-running transactions

Commit Logic (Lines 2852-2867):

7000-COMMIT-WORK SECTION.
    EXEC SQL
        COMMIT WORK
    END-EXEC

    IF SQLCODE NOT = 0
        MOVE 'DB2 COMMIT FAILED' TO WS-ERROR-MESSAGE
        MOVE 7001 TO WS-ERROR-CODE
        PERFORM 8000-ERROR-HANDLER
    ELSE
        MOVE ZERO TO WS-COMMIT-COUNT
        MOVE 'N' TO WS-COMMIT-FLAG
        DISPLAY 'COMMIT SUCCESSFUL - RECORDS COMMITTED'
    END-IF.

Rollback Strategy

Automatic Rollback: Triggered on any database error (SQLCODE not 0 or 100)

Rollback Logic (Lines 2928-2933):

IF SQLCODE NOT = 0 AND SQLCODE NOT = 100
    EXEC SQL
        ROLLBACK WORK
    END-EXEC
    MOVE ZERO TO WS-COMMIT-COUNT
    DISPLAY 'ROLLBACK EXECUTED DUE TO SQL ERROR'
END-IF

Impact:

• All database changes since last commit are reversed
• Commit counter reset to zero
• Processing continues with next record (unless critical error)

Isolation Level: Cursor Stability (CS)

Configuration (Lines 1040-1044):

EXEC SQL
    SET CURRENT ISOLATION = CS
END-EXEC

Characteristics:

• Locks released as cursor moves to next row
• Prevents dirty reads
• Allows concurrent access
• Balances consistency with concurrency

Lock Timeout: 30 Seconds

Configuration (Lines 1046-1050):

EXEC SQL
    SET CURRENT LOCK TIMEOUT = 30
END-EXEC

Behavior:

• Wait up to 30 seconds for lock acquisition
• SQLCODE -911 (deadlock) or -913 (timeout) on failure
• Error handler invoked, automatic rollback triggered

External System Interfaces

Upstream Systems

While the Insurance Management System does not directly interface with external systems via APIs or middleware, it receives data from upstream systems through file-based integration. The following assumptions are made about upstream systems:

1. Policy Management System

Assumed Characteristics:

• Generates POLICY-IN file with validated customer applications
• Performs initial data entry and validation
• Assigns customer numbers (10-digit identifier)
• Collects customer demographics and insurance requirements
• Applies business rules for policy eligibility

Data Quality Expectations:

• Valid date formats (YYYY-MM-DD)
• Numeric fields properly formatted
• Required fields populated
• Customer numbers unique and consistent

2. Renewal Management System

Assumed Characteristics:

• Generates RENEWAL-IN file with renewal requests
• Tracks policy expiration dates
• Identifies customers eligible for renewal
• Calculates loyalty and no-claims years
• Determines discount eligibility

Data Quality Expectations:

• Policy numbers must exist in POLICY_TABLE
• Customer numbers must match policy records
• Renewal dates within acceptable range
• Discount percentages within valid ranges (0-100)

3. Claims Processing System

Assumed Characteristics:

• Generates CLAIM-IN file with claim submissions
• Collects medical/provider documentation
• Validates claim authorization codes
• Ensures completeness of claim information
• Assigns unique claim numbers

Data Quality Expectations:

• Policy numbers must be active in POLICY_TABLE
• Provider codes should exist in PROVIDER_TABLE
• Claim amounts reasonable for claim type
• Required documentation flags set appropriately
• Diagnosis/procedure codes valid (ICD/CPT format)

Downstream Systems

1. Policy Administration System

Consumes: POLICY-OUTPUT-FILE (POLOUT)

Expected Actions:

• Import new policy records
• Update customer policy portfolios
• Generate policy documents
• Initiate premium billing
• Notify agents of new policies

Interface Characteristics:

• Sequential file processing
• Daily/weekly batch import
• Error reconciliation with ERROR-FILE

2. Renewal Confirmation System

Consumes: RENEWAL-OUTPUT-FILE (RENOUT)

Expected Actions:

• Update policy status (old to RENEWED, new to ACTIVE)
• Generate renewal confirmation documents
• Adjust billing schedules
• Update agent commission records
• Send customer notifications

Interface Characteristics:

• Monthly/quarterly batch processing
• Links old and new policy numbers
• Discount tracking for future renewals

3. Claims Payment System

Consumes: CLAIMS-OUTPUT-FILE (CLMOUT)

Expected Actions:

• Process approved claims for payment
• Route flagged claims to fraud investigation
• Route manual review claims to adjusters
• Generate explanation of benefits (EOB)
• Update provider payment records

Interface Characteristics:

• Daily batch processing (high frequency)
• Multiple approval workflows based on status
• Integration with payment processing systems

4. Error Management/Monitoring System

Consumes: ERROR-FILE (ERRFILE)

Expected Actions:

• Parse error records
• Categorize errors by severity
• Generate alerts for CRITICAL errors
• Track error trends and patterns
• Initiate remediation workflows

Interface Characteristics:

• Real-time or near-real-time monitoring
• Integration with incident management systems
• Dashboard reporting

5. Reporting and Analytics System

Consumes: REPORT-FILE (RPTFILE)

Expected Actions:

• Archive processing reports
• Generate management dashboards
• Track processing metrics
• Identify processing trends
• Support audit requirements

Interface Characteristics:

• Post-processing analysis
• Historical trending
• Compliance reporting

No Real-Time Integration

Important Limitation: The Insurance Management System does not support:

• Real-time APIs (REST, SOAP, GraphQL)
• Message queues (MQ, Kafka)
• Event streaming
• Online transaction processing (OLTP)
• Synchronous request/response integration
• Web services
• Microservices architecture

Architectural Implications:

• All integration is asynchronous via batch files
• Processing delays inherent in batch schedule
• No immediate feedback to upstream systems
• Reconciliation required for error scenarios

JCL-Based Scheduling and Execution

JCL Control Structure

The Insurance Management System is invoked through Job Control Language (JCL) on z/OS, which controls:

• Program execution parameters
• File allocations (DD statements)
• Database connectivity
• Resource allocation
• Error handling
• Output disposition

Processing Mode Parameter

PARM Specification:

The processing mode is specified via the PARM parameter in the JCL EXEC statement:

//RUNINS   EXEC PGM=INSMASTR,PARM=''

Valid PARM Values:

• POLICY - Process only policy input/output
• RENEWAL - Process only renewal input/output
• CLAIM - Process only claims input/output
• ALL - Process all three file types (default)

Example: Process Only Policies

//POLRUN   EXEC PGM=INSMASTR,PARM='POLICY'
//STEPLIB  DD DSN=LOADLIB.PROD,DISP=SHR
//         DD DSN=DSN1210.DSNLOAD,DISP=SHR
//POLFILE  DD DSN=INPUT.POLICY,DISP=SHR
//POLOUT   DD DSN=OUTPUT.POLICY,DISP=(NEW,CATLG),
//         UNIT=SYSDA,SPACE=(TRK,(100,50),RLSE)
//ERRFILE  DD DSN=OUTPUT.ERRORS,DISP=(NEW,CATLG),
//         UNIT=SYSDA,SPACE=(TRK,(50,25),RLSE)
//RPTFILE  DD SYSOUT=*

DD Statement Requirements

Input Files

POLFILE (Policy Input):

//POLFILE  DD DSN=,DISP=SHR

• Required when PARM='POLICY' or PARM='ALL'
• Must be allocated with LRECL=800, RECFM=FB
• Sequential organization

RENFILE (Renewal Input):

//RENFILE  DD DSN=,DISP=SHR

• Required when PARM='RENEWAL' or PARM='ALL'
• Must be allocated with LRECL=600, RECFM=FB
• Sequential organization

CLMFILE (Claims Input):

//CLMFILE  DD DSN=,DISP=SHR

• Required when PARM='CLAIM' or PARM='ALL'
• Must be allocated with LRECL=900, RECFM=FB
• Sequential organization

Output Files

POLOUT (Policy Output):

//POLOUT   DD DSN=,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)

• Required when PARM='POLICY' or PARM='ALL'
• Space allocated dynamically with RLSE option
• Can use GDG (Generation Data Group) for versioning

RENOUT (Renewal Output):

//RENOUT   DD DSN=,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)

• Required when PARM='RENEWAL' or PARM='ALL'

CLMOUT (Claims Output):

//CLMOUT   DD DSN=,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)

• Required when PARM='CLAIM' or PARM='ALL'

ERRFILE (Error Log):

//ERRFILE  DD DSN=,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(50,25),RLSE),
//         DCB=(LRECL=250,RECFM=FB,BLKSIZE=0)

• Required for all processing modes
• Should be monitored by operations team

RPTFILE (Processing Report):

//RPTFILE  DD SYSOUT=*

• Required for all processing modes
• Typically directed to SYSOUT for printing
• Can be directed to dataset for archival:

//RPTFILE  DD DSN=,
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(10,5),RLSE),
//         DCB=(LRECL=133,RECFM=FBA,BLKSIZE=0)

Complete JCL Example: Process All Files

//INSMASTR JOB (ACCT),'INSURANCE PROC',
//         CLASS=A,
//         MSGCLASS=X,
//         MSGLEVEL=(1,1),
//         NOTIFY=&SYSUID
//*
//* INSURANCE MANAGEMENT SYSTEM - BATCH PROCESSING
//* PROCESSES POLICIES, RENEWALS, AND CLAIMS
//*
//STEP01   EXEC PGM=INSMASTR,
//         PARM='ALL',
//         REGION=4M,
//         TIME=30
//*
//* PROGRAM LOAD LIBRARIES
//*
//STEPLIB  DD DSN=PROD.LOADLIB,DISP=SHR
//         DD DSN=DSN1210.DSNLOAD,DISP=SHR
//         DD DSN=SYS1.COB2LIB,DISP=SHR
//*
//* INPUT FILES
//*
//POLFILE  DD DSN=INS.POLICY.INPUT(&DATE),DISP=SHR
//RENFILE  DD DSN=INS.RENEWAL.INPUT(&DATE),DISP=SHR
//CLMFILE  DD DSN=INS.CLAIMS.INPUT(&DATE),DISP=SHR
//*
//* OUTPUT FILES - USING GDG FOR VERSION CONTROL
//*
//POLOUT   DD DSN=INS.POLICY.OUTPUT(+1),
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)
//RENOUT   DD DSN=INS.RENEWAL.OUTPUT(+1),
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)
//CLMOUT   DD DSN=INS.CLAIMS.OUTPUT(+1),
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(100,50),RLSE),
//         DCB=(LRECL=500,RECFM=FB,BLKSIZE=0)
//*
//* ERROR AND REPORT FILES
//*
//ERRFILE  DD DSN=INS.ERROR.LOG(+1),
//         DISP=(NEW,CATLG,DELETE),
//         UNIT=SYSDA,
//         SPACE=(TRK,(50,25),RLSE),
//         DCB=(LRECL=250,RECFM=FB,BLKSIZE=0)
//RPTFILE  DD SYSOUT=*
//*
//* SYSTEM OUTPUT
//*
//SYSOUT   DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//*

Scheduling Considerations

Batch Window Requirements

Estimated Processing Times:

• Policy Processing: 1,000-2,000 records/hour
• Renewal Processing: 2,000-3,000 records/hour
• Claims Processing: 500-1,000 records/hour (fraud detection overhead)

Scheduling Recommendations:

1. Daily Claims Processing: High priority, run early in batch window
2. Daily Policy Processing: Medium priority, run after claims
3. Monthly Renewal Processing: Low priority, run during monthly cycle

Restart and Recovery

Current Limitation: The system does not include explicit checkpoint/restart logic.

Recovery Approach:

1. Identify last successful commit (check REPORT-FILE summary)
2. Calculate records processed successfully
3. Extract unprocessed records from input files
4. Re-run with cleaned input files

Future Enhancement Recommendation: Implement checkpoint/restart using:

• DB2 commit frequency tracking
• Input file record counter
• Restart parameter in JCL PARM

Parallel Execution

Supported Parallelism: Multiple job instances can run concurrently with different processing modes:

Example: Parallel Execution Strategy

//JOB1     EXEC PGM=INSMASTR,PARM='POLICY'
//JOB2     EXEC PGM=INSMASTR,PARM='RENEWAL'
//JOB3     EXEC PGM=INSMASTR,PARM='CLAIM'

Benefits:

• Reduced elapsed time
• Maximized CPU utilization
• Independent failure isolation

Considerations:

• DB2 lock contention (minimal with CS isolation)
• I/O channel utilization
• Resource allocation (REGION, CPU)

Integration Sequence Diagrams

Policy Processing Integration Sequence

┌───────────────────────────────────────────────────────────────────┐
│              POLICY PROCESSING INTEGRATION SEQUENCE                │
└───────────────────────────────────────────────────────────────────┘

Upstream System      POLFILE       INSMASTR       DB2        POLOUT      Downstream System
     │                  │             │            │           │              │
     │  Generate        │             │            │           │              │
     │  Policy File     │             │            │           │              │
     ├─────────────────►│             │            │           │              │
     │                  │             │            │           │              │
     │              [JCL Execution]   │            │           │              │
     │                  │   Open      │            │           │              │
     │                  │◄────────────┤            │           │              │
     │                  │   Connect   │            │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │   CONNECT  │           │              │
     │                  │             │    TO      │           │              │
     │                  │             │  INSPROD   │           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │  (Success) │           │              │
     │                  │   Read      │            │           │              │
     │                  │  Record     │            │           │              │
     │                  ├────────────►│            │           │              │
     │                  │   (800 B)   │            │           │              │
     │                  │             │  Validate  │           │              │
     │                  │             │  Input     │           │              │
     │                  │             │            │           │              │
     │                  │             │  Check     │           │              │
     │                  │             │  Duplicate │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │  SELECT    │           │              │
     │                  │             │   COUNT    │           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │  (No dup)  │           │              │
     │                  │             │            │           │              │
     │                  │             │  Calculate │           │              │
     │                  │             │  Risk &    │           │              │
     │                  │             │  Premium   │           │              │
     │                  │             │            │           │              │
     │                  │             │  Get       │           │              │
     │                  │             │  Policy#   │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │  POLICY_SEQ│           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │             │  MERGE     │           │              │
     │                  │             │  Customer  │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │             │  INSERT    │           │              │
     │                  │             │  Policy    │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │             │  Write     │           │              │
     │                  │             │  Output    │           │              │
     │                  │             ├────────────┼──────────►│              │
     │                  │             │            │  (500 B)  │              │
     │                  │             │            │           │              │
     │                  │  [Every 500 records]     │           │              │
     │                  │             │  COMMIT    │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │  [Loop until EOF]        │           │              │
     │                  │             │            │           │              │
     │                  │   EOF       │            │           │              │
     │                  ├────────────►│            │           │              │
     │                  │             │  Final     │           │              │
     │                  │             │  COMMIT    │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │   Close     │            │           │              │
     │                  │◄────────────┤            │           │     Close    │
     │                  │             │            │           ├─────────────►│
     │                  │             │ Disconnect │           │              │
     │                  │             ├───────────►│           │              │
     │                  │             │  CONNECT   │           │              │
     │                  │             │   RESET    │           │              │
     │                  │             │◄───────────┤           │              │
     │                  │             │            │           │              │
     │                  │             │  Write     │           │              │
     │                  │             │  Report    │           │              │
     │                  │             │            │           │              │
     │                  │             │  Return    │           │              │
     │                  │             │   Code 0   │           │              │
     │                  │             │            │           │  Import      │
     │                  │             │            │           │  Policies    │
     │                  │             │            │           ├─────────────►│
     │                  │             │            │           │              │

Claims Processing Integration Sequence (with Fraud Detection)

┌───────────────────────────────────────────────────────────────────┐
│        CLAIMS PROCESSING INTEGRATION SEQUENCE (FRAUD CHECK)        │
└───────────────────────────────────────────────────────────────────┘

Claims System     CLMFILE       INSMASTR       DB2        CLMOUT      Payment System
     │               │             │            │           │              │
     │  Generate     │             │            │           │              │
     │  Claims File  │             │            │           │              │
     ├──────────────►│             │            │           │              │
     │               │             │            │           │              │
     │           [JCL Execution]   │            │           │              │
     │               │   Open      │            │           │              │
     │               │◄────────────┤            │           │              │
     │               │   Connect   │            │           │              │
     │               │             ├───────────►│           │              │
     │               │             │◄───────────┤           │              │
     │               │   Read      │            │           │              │
     │               │  Claim      │            │           │              │
     │               ├────────────►│            │           │              │
     │               │   (900 B)   │            │           │              │
     │               │             │  Validate  │           │              │
     │               │             │  Input     │           │              │
     │               │             │            │           │              │
     │               │             │  Get       │           │              │
     │               │             │  Policy    │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  SELECT    │           │              │
     │               │             │  POLICY    │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │            │           │              │
     │               │             │  Check     │           │              │
     │               │             │  Duplicate │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  SELECT    │           │              │
     │               │             │  COUNT     │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │  (No dup)  │           │              │
     │               │             │            │           │              │
     │               │             │ [FRAUD DETECTION]      │              │
     │               │             │            │           │              │
     │               │             │  Frequency │           │              │
     │               │             │  Check     │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  SELECT    │           │              │
     │               │             │  COUNT 30d │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │  (+10 pts) │           │              │
     │               │             │            │           │              │
     │               │             │  Provider  │           │              │
     │               │             │  Check     │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  SELECT    │           │              │
     │               │             │  PROVIDER  │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │  (+20 pts) │           │              │
     │               │             │            │           │              │
     │               │             │  Pattern   │           │              │
     │               │             │  Detection │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  SELECT    │           │              │
     │               │             │  90d match │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │  (+30 pts) │           │              │
     │               │             │            │           │              │
     │               │             │  Score: 75 │           │              │
     │               │             │  FLAGGED!  │           │              │
     │               │             │            │           │              │
     │               │             │  Calculate │           │              │
     │               │             │  Payment   │           │              │
     │               │             │            │           │              │
     │               │             │  Get       │           │              │
     │               │             │  Claim ID  │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  CLAIM_SEQ │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │            │           │              │
     │               │             │  INSERT    │           │              │
     │               │             │  Claim     │           │              │
     │               │             ├───────────►│           │              │
     │               │             │  (FRAUD    │           │              │
     │               │             │   FLAG=Y)  │           │              │
     │               │             │◄───────────┤           │              │
     │               │             │            │           │              │
     │               │             │  UPDATE    │           │              │
     │               │             │  Policy    │           │              │
     │               │             ├───────────►│           │              │
     │               │             │◄───────────┤           │              │
     │               │             │            │           │              │
     │               │             │  Write     │           │              │
     │               │             │  Output    │           │              │
     │               │             ├────────────┼──────────►│              │
     │               │             │            │  (500 B)  │              │
     │               │             │            │ Status:   │              │
     │               │             │            │ INVEST.   │              │
     │               │             │            │           │  Route to    │
     │               │             │            │           │  Fraud Unit  │
     │               │             │            │           ├─────────────►│
     │               │             │            │           │              │

Interface Summary Table

Input Interfaces

Output Interfaces

Database Interfaces

Error Handling and Recovery

File Error Handling

File Open Errors

Detection: File status codes other than '00' during file open operations

Severity: CRITICAL (error codes 1101-1199)

Response:

1. Error logged to console (ERRFILE not yet open)
2. Error message displayed with file name and status code
3. Return code set to 12
4. Program terminates immediately (9999-ABORT-PROGRAM)

Recovery:

• Verify DD statement allocation
• Check file existence and accessibility
• Validate file attributes (LRECL, RECFM)
• Retry job execution after correction

File Read Errors

Detection: File status codes other than '00' or '10' during READ operations

Severity: SEVERE (varies by file)

Response:

1. Error logged to ERROR-FILE
2. File processing terminated for that file type
3. EOF flag set
4. Processing continues with other file types (if PARM='ALL')

Recovery:

• Review ERROR-FILE for specific error
• Validate input file format and content
• Extract and reprocess failed records

File Write Errors

Detection: File status codes other than '00' during WRITE operations

Severity: CRITICAL (may trigger rollback)

Response:

1. Error logged to ERROR-FILE (if possible)
2. Database rollback triggered
3. Commit counter reset
4. Processing may continue or abort based on error nature

Recovery:

• Check output file space allocation
• Verify output file permissions
• Review SPACE parameter in JCL
• Retry with larger space allocation

Database Error Handling

Connection Errors

Detection: SQLCODE not equal to 0 during CONNECT

Severity: CRITICAL (error code 1150)

Response:

1. Error logged to console (ERRFILE not yet open)
2. SQLCODE and SQLERRMC displayed
3. Return code set to 12
4. Program terminates immediately

Recovery:

• Verify DB2 subsystem availability
• Check database name (INSPROD)
• Validate user permissions
• Review DB2 connection parameters

SQL Execution Errors

Detection: SQLCODE < 0 (negative values) or SQLCODE = 100 (not found) in unexpected context

Severity: SEVERE (error codes vary by operation)

Response:

1. Error logged to ERROR-FILE with SQLCODE and SQLERRMC
2. Automatic ROLLBACK WORK executed
3. Commit counter reset to zero
4. Processing continues with next record (unless critical)

Common SQLCODES:

• -803: Duplicate key (primary key violation)
• -911: Deadlock or timeout
• -913: Deadlock/lock timeout
• +100: Row not found (may be acceptable in some contexts)

Recovery:

• Review ERROR-FILE for specific SQL error
• Check database table constraints
• Verify lock timeout settings
• Analyze transaction conflicts
• Retry after resolving conflicts

Transaction Errors

Detection: SQLCODE errors during COMMIT or ROLLBACK

Severity: CRITICAL

Response:

1. Error logged with SQLCODE
2. Additional ROLLBACK attempted
3. Program may abort if recovery not possible

Recovery:

• Check DB2 transaction log space
• Verify database connectivity
• Contact DBA for transaction log analysis

Business Logic Error Handling

Validation Errors

Examples:

• Age out of range (18-85)
• Invalid insurance type
• Invalid date format
• Negative amounts
• Missing required fields

Severity: WARNING (varies)

Response:

1. Error logged to ERROR-FILE
2. Error counter incremented for that record type
3. Record skipped, processing continues with next record
4. No database operations performed for invalid record

Recovery:

• Review ERROR-FILE for validation failures
• Correct source data in upstream system
• Extract failed records and regenerate input file

Duplicate Detection

Examples:

• Duplicate active policy (same customer + insurance type)
• Duplicate claim number

Severity: WARNING

Response:

1. Error logged indicating duplicate
2. Record skipped
3. No database operations performed

Recovery:

• Investigate source of duplicate
• Determine if legitimate duplicate or data error
• Remove duplicates from input file if erroneous

Policy/Customer Not Found

Examples:

• Renewal for non-existent policy
• Claim for non-existent policy

Severity: SEVERE

Response:

1. Error logged with missing identifier
2. Record rejected
3. Processing continues

Recovery:

• Verify policy number accuracy
• Check timing (policy may not be created yet)
• Coordinate with upstream system

Recovery Procedures

Restart After Failure

Current System Limitation: No automatic checkpoint/restart

Manual Restart Procedure:

1. Review REPORT-FILE to identify last successful commit point
2. Calculate records processed successfully (from counters)
3. Extract unprocessed records from input files
4. Create restart input files starting at failure point
5. Re-execute job with restart files
6. Reconcile output with previous run to avoid duplicates

Future Enhancement: Implement checkpoint/restart using:

• VSAM checkpoint dataset
• Restart parameter in JCL PARM
• Database-persisted checkpoint records

Error Reconciliation

Daily Process:

1. Review ERROR-FILE from batch run
2. Categorize errors (validation, system, database)
3. Extract failed record keys
4. Research error causes in upstream systems
5. Correct source data
6. Create correction file
7. Re-run specific processing mode (POLICY/RENEWAL/CLAIM)

Database Rollback Recovery

Automatic Rollback Scenarios:

• Any database error (SQLCODE < 0 or unexpected +100)
• File write failure
• System abend

Impact:

• All database changes since last commit are lost
• Commit counter reset
• Processing continues from next record

Recovery Consideration:

• Records processed between last commit and rollback must be reprocessed
• Output files may contain records for rolled-back database transactions
• Reconciliation required between output files and database

Integration Assumptions

Upstream System Assumptions

1. Data Quality:

   • Input files conform to documented record layouts
   • Required fields are populated
   • Numeric fields contain valid numeric data
   • Date fields follow YYYY-MM-DD format
   • Amount fields are positive (or zero where appropriate)

2. File Delivery:

   • Input files delivered before scheduled batch window
   • Files are complete (not truncated)
   • File naming conventions followed
   • Files allocated with correct DCB attributes

3. Data Consistency:

   • Customer numbers are unique and consistent across files
   • Policy numbers referenced in renewals and claims exist
   • Insurance types are valid and supported
   • Provider codes exist in PROVIDER_TABLE

4. Timing:

   • Renewal files generated before policy expiration
   • Claims files contain claims for active policies
   • Files synchronized (e.g., policy must be created before renewal)

5. Volume:

   • File volumes within expected ranges for batch window
   • Sufficient time for processing within scheduled window
   • Database capacity sufficient for peak volumes

Downstream System Assumptions

1. File Consumption:

   • Downstream systems monitor for output file arrival
   • Files processed shortly after generation
   • Failed records in ERROR-FILE are reviewed and reprocessed

2. Data Processing:

   • Output files consumed in entirety
   • No partial file processing
   • Downstream systems handle policy status transitions

3. Error Handling:

   • ERROR-FILE monitored for CRITICAL and SEVERE errors
   • Alerts generated for high error rates
   • Remediation workflows initiated for errors

4. Reconciliation:

   • Downstream systems reconcile counts with REPORT-FILE
   • Discrepancies investigated and resolved
   • Audit trails maintained

5. Fraud Investigation:

   • Claims flagged for investigation routed to fraud unit
   • Manual review claims assigned to adjusters
   • Investigation results fed back to update CLAIM_TABLE

Database Assumptions

1. Availability:

   • DB2 subsystem (INSPROD) available during batch window
   • Database tables exist and are accessible
   • Sequences (POLICY_SEQ, CLAIM_SEQ) configured and operational

2. Performance:

   • Database response time adequate for batch processing
   • Indexes exist on frequently queried columns
   • Lock contention minimal with CS isolation level

3. Capacity:

   • Table spaces have sufficient space for new records
   • Transaction log space adequate for batch processing
   • Commit frequency (500 records) appropriate for environment

4. Referential Integrity:

   • Foreign key relationships maintained
   • Cascade rules defined appropriately
   • Constraint violations prevent invalid data

5. Backup and Recovery:

   • Regular database backups performed
   • Point-in-time recovery available
   • Rollback segments sufficient for transaction management

Operational Assumptions

1. JCL Execution:

   • JCL scheduler (e.g., Control-M, TWS) configured correctly
   • Job dependencies defined
   • Conditional execution based on previous job completion codes

2. Resource Availability:

   • Sufficient CPU resources for concurrent processing
   • Adequate disk space for output files
   • SYSOUT space available for reports

3. Monitoring:

   • Batch jobs monitored by operations team
   • Return codes checked and acted upon
   • CRITICAL errors escalated immediately

4. File Retention:

   • Input files retained for reconciliation period
   • Output files archived according to retention policy
   • ERROR-FILE retained for audit requirements

5. Version Control:

   • Program load modules deployed to correct libraries
   • DB2 bind plans current with program version
   • JCL procedures synchronized with program requirements

Security Assumptions

1. Authentication:

   • INSMASTR user ID has necessary DB2 privileges
   • File datasets protected by appropriate security rules
   • Batch job runs under authorized user ID

2. Authorization:

   • SELECT, INSERT, UPDATE privileges on DB2 tables
   • USAGE privilege on sequences
   • CONNECT privilege to INSPROD database

3. Data Protection:

   • Input files contain PII/PHI (SSN, medical data)
   • Files encrypted at rest and in transit (if required)
   • Output files protected with equivalent security

4. Audit:

   • Database audit trails enabled
   • File access logged
   • ERROR-FILE and REPORT-FILE available for compliance review

Future Integration Considerations

As the Insurance Management System evolves, consider the following integration enhancements:

1. Real-Time APIs:

   • Expose policy, renewal, and claims operations via REST APIs
   • Enable online transaction processing
   • Support customer self-service applications

2. Event-Driven Architecture:

   • Publish events on policy creation, renewal, claim adjudication
   • Enable downstream systems to react in real-time
   • Support workflow orchestration

3. Data Lake Integration:

   • Export audit data to data lake for analytics
   • Enable machine learning for enhanced fraud detection
   • Support predictive modeling for risk assessment

4. Cloud Integration:

   • Hybrid architecture with cloud-based services
   • API gateway for external partner integration
   • Cloud storage for archival and disaster recovery

5. Microservices Decomposition:

   • Extract fraud detection as independent microservice
   • Risk scoring service with real-time API
   • Premium calculation engine as reusable service

Conclusion

The Insurance Management System implements a robust batch-oriented integration architecture leveraging sequential file processing and DB2 database persistence. The eight-file integration model (three input, three output, one error, one report) provides clear separation of concerns and facilitates upstream/downstream system integration. Database integration through embedded SQL ensures transactional consistency with commit/rollback support.

Key integration strengths include:

• Clear file-based interface contracts
• Comprehensive error logging and reporting
• Transactional database operations with rollback capability
• Flexible processing modes via JCL PARM
• Fraud detection integrated with claims processing

Areas for future enhancement:

• Checkpoint/restart capability for improved recovery
• Real-time integration via APIs
• Event-driven architecture for downstream notification
• Enhanced monitoring and observability

The integration architecture effectively balances mainframe batch processing constraints with modern business requirements for reliable, auditable insurance operations processing.