Case Study 26.1: GlobalBank's C Date Library Integration

Background

GlobalBank's core banking system stored dates in a packed decimal Julian format (YYYYDDD) — a legacy of the original 1987 design. While this format was efficient for storage and sorting, it made date arithmetic difficult. Calculating the number of days between two dates, determining the day of week, or formatting dates for the new web portal required complex COBOL paragraphs that had accumulated bugs over three decades.

When the web portal project began, Priya Kapoor identified date handling as a critical integration point. The Java-based portal needed ISO 8601 dates ("2025-03-15"). The COBOL system produced Julian dates ("2025074"). Converting between formats was error-prone, especially around leap years and year boundaries.

The Decision

Rather than writing another COBOL date conversion module or duplicating date logic in Java, Priya proposed a C date utility library that could be called from both COBOL (on z/OS) and Java (through JNI). The library would serve as the single source of truth for date operations.

Maria Chen was skeptical: "We already have date conversion paragraphs. Why add another language to the mix?"

Priya's response: "Because the C standard library's mktime and strftime functions handle every edge case — leap years, leap seconds, daylight saving time. Our COBOL paragraphs have had three bugs in the last two years, all related to leap year calculations. The C library has been tested by millions of programs."

Implementation

Derek Washington led the implementation, his first inter-language project:

Phase 1: C library development (1 week) - Four functions: validate_date, get_day_of_week, days_between, format_iso_date - Unit tested with 500+ test cases covering edge cases - Compiled on z/OS with XL C and on Linux with GCC for portal-side use

Phase 2: COBOL interface (3 days) - Binary interface using PIC S9(9) COMP for date integers - Julian-to-Gregorian conversion in COBOL before calling C (C functions expected YYYYMMDD integers) - Comprehensive SQLCODE-style return codes (0 = success, negative = error)

Phase 3: JNI wrapper (2 days) - Thin Java native methods wrapping the same C functions - Java LocalDate to integer conversion in the JNI layer

Phase 4: Testing (1 week) - End-to-end tests: COBOL → C → verify result in Java - Edge cases: Feb 29 in leap/non-leap years, Dec 31/Jan 1 boundaries, dates before 1970, dates after 2038

The Bug

During testing, Derek discovered that dates before January 1, 1970 produced incorrect results from mktime on z/OS. The Unix epoch starts at 1970, and mktime behavior for earlier dates is implementation-defined.

GlobalBank had accounts opened in the 1960s. Their Julian dates predated the Unix epoch.

The fix: add a special case for pre-1970 dates using a manual calculation (Zeller's formula for day-of-week, manual day counting for days_between). This added 40 lines to the C library and three weeks of additional testing.

Maria Chen's lesson: "This is why you test at the boundaries — not just the language boundaries, but the data boundaries. The C library was 'correct' by C standards. It just wasn't correct for our data."

Results

After six months in production: - Zero date conversion bugs (compared to three in the previous two years) - Web portal and COBOL system producing identical date outputs - 12% reduction in date-related ABEND incidents - The C library became a shared enterprise component, reused by three other systems

Discussion Questions

  1. Derek's first instinct was to rewrite the COBOL date logic in Java. Why was the C library approach better? Under what circumstances would the Java rewrite have been the right choice?
  2. The pre-1970 date bug was not caught until integration testing. What unit test cases should have been written to catch it earlier?
  3. Maria Chen was initially skeptical of adding C to the mix. Evaluate her concern: does adding another language increase system complexity? When is that complexity justified?
  4. The C library became a "shared enterprise component." What governance challenges does this create? Who owns the library? What happens when one system needs a change that might affect others?