Case Study 2: MedClaim Date Calculations and Numeric Validation

Background

MedClaim's claim adjudication system must validate every incoming claim for timely filing, compute aging buckets for accounts receivable, and safely convert alphanumeric amounts from EDI input into numeric fields for pricing. These operations run on every claim — 800,000 per day.

The Problem

The legacy adjudication program used hand-coded date arithmetic (counting days with nested IF statements for month lengths and leap years) and a manual numeric conversion routine that was over 200 lines long. The date arithmetic had a known bug with leap-year February calculations that had been patched three times without a permanent fix. The numeric conversion routine did not handle all EDI amount formats, causing periodic abends.

Solution

James Okafor replaced both routines with intrinsic function calls:

  1. Date arithmetic: FUNCTION INTEGER-OF-DATE and FUNCTION DATE-OF-INTEGER replaced 150 lines of hand-coded date math. The leap year bug was eliminated because the intrinsic functions handle all calendar complexities internally.

  2. Timely filing check: A single COMPUTE statement calculates days since service: cobol COMPUTE WS-DAYS = FUNCTION INTEGER-OF-DATE(WS-TODAY) - FUNCTION INTEGER-OF-DATE(WS-SVC-DATE)

  3. Aging buckets: Claims are categorized into 0-30, 31-60, 61-90, 90+ day buckets using the same date subtraction.

  4. Numeric conversion: FUNCTION TEST-NUMVAL validates EDI amounts before FUNCTION NUMVAL converts them, eliminating all conversion abends.

Results

  • Date arithmetic code reduced from 150 lines to 12 lines
  • Numeric conversion code reduced from 200 lines to 15 lines
  • Leap year bug permanently eliminated
  • Zero conversion-related abends in 6 months of production
  • Processing time reduced by 8% (intrinsic functions are optimized in the compiler runtime)

Lessons Learned

  1. TEST-NUMVAL is essential: EDI data is notoriously inconsistent. Testing before conversion is non-negotiable.
  2. Intrinsic functions are well-tested: IBM's implementation of INTEGER-OF-DATE has been used by thousands of installations for decades. Hand-coded date math cannot match that test coverage.
  3. Code reduction improves maintainability: The new code is readable by any COBOL programmer; the old code required specialized knowledge of its custom date algorithm.

Discussion Questions

  1. What edge cases should be tested when replacing hand-coded date arithmetic with intrinsic functions?
  2. How would you handle the case where an EDI claim has a service date in the future?
  3. What is the performance impact of calling TEST-NUMVAL before every NUMVAL, and is it justified?
  4. Could the aging bucket calculation be further simplified using EVALUATE with computed day ranges?