Using Comp-3 value in Java

[ramki srini]

We have a requirement as below in our project.
We will be downloading a Flat file from Host mainframe which has some COMP-3 (packed decimal) field.
Could anyone please explain me how to handle with this COMP-3 field. We need to uncompress this field do some check against each byte and depending on that different actions to be taken.
Pls let me know how to uncompress, compress and read COMP-3
values.

[Frank Carver]

Please don't post the same message to mroe than one forum. You obviously read more than one forum. SO do the people who might answer your question.
I have closed all the other versions and pointed them to this one.

[Cindy Glass]

ramki431,
Please change your name to be compliant with JavaRanch's naming policy.
Your displayed name should be 2 separate names with more than 1 letter each. We really would prefer that you use your REAL name.
You can change your name: here.
Thanks,
Cindy

[Tim Holloway]

COMP-3 is IBM's packed decimal format. On the S/360 and later CPUs of that descent it's directly manipulable via machine instructions. A similar capability exists on Intel's x86 and Motorola's M68K families, but very little code on those machines uses it.
Specifically, a packed-decimal number consists of a set of from 1 to 16 bytes which each byte subdivided into 2 nybbles of 4 bits each. Each nybble contains the binary value of a single decimal digit. There's always an odd number of digits represented - the rightmost nybble of all (no byte-swapping on S/360!) is reserved for the sign, which is normally either binary 1100, 1101, or 1111 (hexadecimal C, D, or F). There are no "unused" nybbles, leading zeroes fill the number out.
Examples:
The value 257 as a hex representation of a binary number is 0x101. Its packed-decimal equivalent is
257C in hex. An actual COBOL spec implies the size of the number in memory/disk, so a field definition like:
77 PACKED-NUMBER PIC S9(5) COMP-3 VALUE -332.
Would appear in RAM as 00332D.
C and F indicate positive values, D indicates a negative value. Rules exists for interpreting other values, but in actual practive anything other than one of the above should never be seen.

[Thomas Paul]

See this:
http://digilander.libero.it/foxes/Packed_Decimal.htm
Interesting note:
== Attention == COMP-3 fields should not be converted from EBCDIC to ASCII or vice-versa. If the usual EBCDIC-to-ASCII alphanumeric conversion were performed on the bytes in a packed-decimal field, the data would be corrupted.

[Thomas Paul]

If it was up to me, I would write a COBOL program to uncompress the comp-3 fields and use the output of that program.

[Cindy Glass]

I remember once when we were migrating from a Univac machine which was ASCII Octal to an IBM EBCIDIC hex machine. Do you KNOW what havoc can be caused by the fact that a negative zero is interpreted differently in those environments .

[Tim Holloway]

Originally posted by Thomas Paul:
See this:
http://digilander.libero.it/foxes/Packed_Decimal.htm
Interesting note:
== Attention == COMP-3 fields should not be converted from EBCDIC to ASCII or vice-versa. If the usual EBCDIC-to-ASCII alphanumeric conversion were performed on the bytes in a packed-decimal field, the data would be corrupted.

Ah yes. I've been burned more than once by the fact that MS-Windows' FTP defaults to text-translated downloads

[Carl Berndt]

Here is a code snippet

I passed a single byte to the byteToString, and it returns the 2 char string.
Only need to do this for the ebcdic packed decimal bytes...
String s1 = byteToString(byteArrRecvdMsg[2]);
System.out.println("s1 = " + s1);
/**
* Description: Read ebcdic byte, and get its
* 4 bit pairs.
*/
private static String byteToString(byte inhexbyte) throws IOException {
System.out.println("Read in byte " + inhexbyte);
//ebcdic to java string
//String hex = Integer.toHexString(-107); //ebcdic 95
String hex = Integer.toHexString(inhexbyte);
StringBuffer digits = new StringBuffer("??");
int j = hex.length();
if (j >= 2) {
char c1 = hex.charAt(j - 2);
char c2 = hex.charAt(j - 1);
digits.setCharAt(0, c1);
digits.setCharAt(1, c2);
}

return digits.toString();
}

[muthukum palan]

I was reading this thread "Using Comp-3 value in Java " and found it very useful.I am in the process of converting an ASCII decimal string to Packed decimal(comp-3) and wondering if you could help me.
For eg) I need to convert "12" to a single byte 0x12.
I would really appreciate if you could send me a code snippet in java that does the above.

[Stan James]

I'd start with something along the lines of:

x = 12;
resultByte = resultByte | ( x % 10 );        // puts "2" in the right nibble
resultByte = resultByte | (( x / 10 ) << 4 ) // puts 1 in the left nibble

then try to generalize it to handle longer numbers.

while x > 0
   nibble = x % 10
   "or" the nibble into the correct side of the correct byte
   x = x / 10

Sounds CPU intensive and crude. Are there clever ways to do this?

[muthukum palan]

Hi,
Thanks much for responding to my question and it really helps.
I tried your suggestion and it works if the number is 12.However in the case of the sign and also for numbers like 81 or greater,it needs some modification.
I tried for several hours and couldn't make it work.Do you have any suggestions?

Thanks.

[Rajni Patel]

Hi,

I have same requirement as posted here. Please can you post code if you have it? or please can you guide me how to unpack packed field created by mainfram comp-3?

Thanks.

[Rob Spoor]

We are NotACodeMill, so you won't get any full code. But that doesn't mean others can't guide you on your way.