Migrate CBACT04C (interest calculation) and CBTRN03C (transaction report) to Java

[devanshi-gpta]

Summary

Migrates the two batch programs CBACT04C (INTCALC.jcl) and CBTRN03C (TRANREPT.jcl) into com.carddemo.batch.interest and com.carddemo.batch.report, with the business math isolated in @Service classes and Spring Batch jobs as thin wrappers. Only new files under those two packages, plus an appended row-pair in the README mapping table.

Arithmetic notes worth checking against the COBOL:

• COMPUTE WS-MONTHLY-INT = (TRAN-CAT-BAL * DIS-INT-RATE) / 1200 carries no ROUNDED phrase, so InterestCalculationService.monthlyInterest truncates into S9(09)V99 rather than half-up rounding: 100.00 @ 1.50% -> 0.125 -> 0.12 (and -0.12 for the negative balance, truncation towards zero). CobolUtils.rounded/HALF_UP is therefore deliberately not used here; it would produce 0.13.
• Interest transaction fields of 1300-B-WRITE-TX are preserved verbatim: TRAN-ID = PARM-DATE(10) || 9(06) counter ("2022071800000001"), type 01, category 0005, source System, TRAN-DESC = "Int. for a/c " || ACCT-ID zero-padded to 11, merchant fields zeroed/blanked, card number from the CARDXREF alternate-index read, and both timestamps set to the EEEE-MM-DD-UU.MM.SS.HH0000 DB2 string of Z-GET-DB2-FORMAT-TIMESTAMP.
• DISCGRP miss retries under group DEFAULT (VSAM status 23 path); a miss on the retry throws, mirroring the abend in 1200-A-GET-DEFAULT-INT-RATE.
• CVTRA07Y numeric editing is implemented by hand in TransactionReportFormatter.editedAmount, including comma suppression inside the suppressed region and the all-blank field for a zero value: PIC -ZZZ,ZZZ,ZZZ.ZZ of 1234.56 is " 1,234.56", of 0.56 is " .56", of 0 is 15 blanks. Every line is padded to the 133 bytes of FD-REPTFILE-REC.

Two quirks of the originals are reproduced on purpose (documented in Javadoc, README and asserted by tests) rather than silently "fixed":

• CBACT04C never posts the accumulated interest of the last account in TCATBALF. 1050-UPDATE-ACCOUNT only runs on an account change, and the ELSE branch of the main PERFORM UNTIL that would flush the final account is unreachable because the loop test ends the loop first. The interest transactions of that account are still written.
• CBTRN03C adds the amount of the last transaction a second time at end of file (READ INTO leaves TRAN-RECORD untouched), writes page + grand totals but no closing account total, and NEXT SENTENCE on an out-of-range TRAN-PROC-TS transfers control past the period that closes the whole PERFORM UNTIL — i.e. the first out-of-range record ends the report. Since the surrounding JCL pre-filters the extract with a SORT INCLUDE COND on the same dates, the alternative "skip the record" reading is available as generate(txns, range, /* stopOnOutOfRange */ false); the default is the COBOL-exact behavior.

Tests (mvn -B clean verify green, 39 tests) assert concrete numbers: per-category interest amounts, the resulting account balance (500.00 + 10.00 + 3.86 = 513.86 with both cycle buckets zeroed), the DEFAULT-group fallback, the zero-rate skip, the last-account non-update, page break after 16 detail lines (the four heading lines are counted into WS-LINE-COUNTER), account subtotals on card change, and the page/grand totals including the EOF double count.

Link to Devin session: https://app.devin.ai/sessions/7e9f2314ced941a5a0f00bdf4b49cb50
Requested by: @devanshi-gpta

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring