Java mapping for COBOL comp and comp-3 fields

Question

I am invoking DB2 stored procedure created using COBOL from my java application.

input macro (type varchar):

01 SP1-INPUTS.
    05 FIELD-1      PIC X(03).
    05 FIELD-2      PIC S9(09) COMP.
    05 FIELD-3      PIC S9(15)V9(02) COMP-3.
    05 FIELD-3X     REDEFINES  FIELD-3 PIC X(09)

To test the stored procedure, I know only value for FIELD-1. For other fields, to fill the packed portions how many zeros should I put? Please see the code which I wrote and confused in passing dummy values.

String field1="abc";
String field2="000000000"; // 9 zeroes, correct?
String field3="00...0" // should I give 18 zeroes or 9 zeroes?

How much characters totally for the input macro ?

Answer 1

COBOL does not have strings, it has fixed-length fields with no terminators.

So for FIELD-1 you have three "characters". A PICture of X can allow any of the 256 possible bit-values, but would typically contain human-readable values.

FIELD-2 is a binary field. You could consider it to be a four-byte integer.

However, the way it is defined there, COMP, with an S, it has a maximum value of 999,999,999 positive and a minimum value of 999,999,999 negative.

If it were defined as COMP-5, it could contain the full range for all bits in those four bytes. Note that compiler option TRUNC(BIN) would modify the behaviour of COMP to COMP-5 anyway, so you need to check with the Mainframe side what compile option is used for TRUNC (other values are STD and OPT).

On an IBM Mainframe a native binary field is Big Endian. On your local machine a native binary value would be Little Endian. For instance, a value of 16906090 would be stored as X'01020304'.

FIELD-3 is packed-decimal. It is nine bytes long, but each byte contains two decimal digits, except for the low-order (right-most) byte which contains one digit followed by a sign specifier (the PICture uses S, so the sign should be C for positive and D for negative, base-16). There is an implied decimal point (the V) and two decimal places.

FIELD-3X is another X field. It could again contain any bit-pattern in each of the bytes. You'd need to know what the intended use of that field was (there's not even the slightest clue from the names, as with the others, which is a bad way to do things).

The design is wrong. It is completely nuts to send binary and packed-decimal fields from the Mainframe to somewhere else, or vice versa. If all the fields were defined as X or 9 without the USAGE (implied) of COMP or COMP-3, then you'd have a very easy ride.

There's a required full-stop/period missing on the final definition, but that's likely a pasto.

   01  SP1J-INPUTS. 
       05  a-meaningful-name               PIC X(03). 
       05  another-meaningful-name         PIC S9(09) 
                                            SIGN LEADING SEPARATE.
       05  a-third-meaningful-name         PIC +9(15).9(02). 
       05  yet-annother-meaningful-name 
           REDEFINES a-third-meaningful-name 
                                           PIC X(19). 

This shows two ways to deal with the sign, either with the SIGN clause, or by using a numeric-edited definition. The . in the numeric-edited definition is an actual decimal-point, rather than an implied one, with the V.

All the data is now "text" or "character" data, which should be easy for you to deal with. EBCDIC (IBM Mainframe encoding) to ASCII (your local machine encoding, likely) is easy and can be done at data level, not field level.

For your to-and-fro communication, the above would be much easier for you, much less error-prone and more easily auditable. Internally the COBOL program can easily convert to/from those for its own internal use.

If you don't get them to change your interface to "character" then you'll have all sorts of extra coding and testing to do, for no advantage.

And example of that layout with ABC, 123456789 (negative) and 123456789012345.67 (positive) would be

ABC-123456789+123456789012345.67

Note that in addition to no field-delimiters, there are no data/record delimiters either. No "null"s.

There is an alternative to the actual decimal-point, which would be to provide a scaling factor. Further, you could "hard-code" the scaling in your program.

I assume the above data would be easy for you to both accept and create. Please try to get your interface changed. If they refuse, document with your boss the impact in extra code, and that the extra code is just to be able to "understand" the data before you even get to think about using it. Which is silly.

To create the easy-format data for you, the COBOL program needs to do this:

MOVE FIELD-1                  TO a-meaningful-name 
MOVE FIELD-2                  TO another-meaningful-name
MOVE FIELD-3                  TO a-third-meaningful-name

To receive the easy-format data from you, the COBOL program needs to do this:

MOVE a-meaningful-name        TO FIELD-1 
MOVE another-meaningful-name  TO FIELD-2     
MOVE a-third-meaningful-name  TO FIELD-3

If the REDEFINES has a purpose, it would require specific code for the fourth field, but that's difficult for me to guess, but not difficult to code once the actual need is known.

Nothing onerous, and vastly simpler than what you have to code otherwise.