Decimal Point and Scaling Lost Between JSON Service and COMP-3 Amount
Orion Logistics exposes a COBOL batch module as a JSON service through an integration layer. The request contains an order amount as the JSON string "1234.50", a currency code, and an order date. The COBOL copybook defines WS-AMOUNT as PIC S9(9) COMP-3 with no implied decimal places, because the original mainframe sender transmitted amounts in cents. The new integration layer removes the decimal point and sends "123450", which COBOL stores as 123,450.00; finance sees amounts 100 times too high. Some requests send negative adjustments as "-1234.50", and some send one decimal place as "1234.5"; these abend with S0C7. Dates arrive as "2024-03-01"; the mapper strips hyphens, and WS-ORDER-DATE PIC 9(8) displays correctly. The service must support amounts up to 9,999,999.99, negative adjustments, and run on both z/OS and Linux.
1. Diagnose both the 100x inflation and the S0C7 abends.
Read the worked answer
The copybook has no implied decimal places: PIC S9(9) COMP-3 represents an integer. The business value 1234.50 must be represented with two decimal places, either as S9(7)V99 or as an integer number of cents. The integration layer strips the decimal point and sends 123450, which COBOL stores literally as 123,450.00. That is a factor of 100, not a rounding issue.
The S0C7 abends come from moving unvalidated character data into a packed-decimal field. A minus sign and a decimal point are not valid digits in a numeric MOVE. Some compilers may tolerate a leading sign in limited cases, but "-1234.50" and "1234.5" are not in the expected packed format. When the program later uses the corrupted field, the packed digits contain invalid nibbles and the task abends with a data exception. The date path happens to work because stripping hyphens produces eight digits, but it does not follow that the amount path is safe.
2. Evaluate the proposal to change WS-AMOUNT to PIC 9(9) DISPLAY and let COBOL handle the decimal point.
Read the worked answer
That proposal does not solve either problem. PIC 9(9) DISPLAY is unsigned, so negative adjustments cannot be represented. It has no V99, so it still cannot hold cents; the decimal point is not stored in a numeric DISPLAY field. Allowing COBOL to 'handle' a character string containing a decimal point is not a parse operation, and it may still trigger a data exception or silently truncate.
A correct definition is PIC S9(7)V99 COMP-3, which holds up to 9,999,999.99 with a sign and is byte-order independent across z/OS and Linux. The integration contract should either:
- Send a canonical decimal string and have COBOL parse it with
FUNCTION NUMVALorNUMVAL-C, or - Send integer minor units (cents) and have COBOL convert to the packed field with an explicit division or decimal alignment.
Never MOVE the raw JSON string directly into the packed field. Validate the parsed value against the maximum and minimum, use ON SIZE ERROR, and reject malformed inputs before any arithmetic.
3. Design the validation and interface rules you would put in place for portability.
Read the worked answer
Define the interface amount as either a canonical string with an optional leading minus and exactly two decimal places, or as an integer number of cents with a separate currency code. In COBOL, receive the value in a PIC X field, validate its length and characters, then use FUNCTION NUMVAL-C for a signed decimal string or an explicit conversion for cents. Move the result to PIC S9(7)V99 COMP-3 and check ON SIZE ERROR. Reject values outside -9,999,999.99 to +9,999,999.99.
Avoid native binary COMP fields for cross-platform interchange because byte order can differ between z/OS and Linux; packed decimal is portable but is not a JSON-native representation. Keep the JSON layer responsible for JSON syntax and the COBOL layer responsible for business range and sign. Add tests for 1234.50, -1234.50, 0.00, the maximum, one decimal place, a leading plus sign, embedded spaces, and a value one cent over the limit. Validate dates separately and reject impossible dates rather than relying on the eight-digit display.