I wanna know how to unpack the input file that is in packed No sign format. Su[ppose The Acct Number that is packed length is only 7 and i wanna unpack that Acct Number to get the length 16. Im doing the project on Credit Cart system that is having all the packed Numbers.
Let me know plzzz. I the file is in EBCDIC format that is packed how to unpack.
Thanx & Regards
Habeeb
Packed decimal numbers simply pack two digits per byte, one in the top nyble, one in the bottom. You just to translate each into a character digit, then you can convert them to binary or whatever. If this is the old "comp-3" format then the final nybble will be a sign indicator, 0xC for +, -0xD for - and 0xF for unsigned.
(It's amazing people are still using these formats).
Don't know how you can get 16 digits from 7 bytes this way. I'd expect 13 digits plus sign flag.
The unpacking process would look something like:
StringBuffer digits = new StringBuffer(14);
boolean negative = false;
for(int i = 0; i < 7; i++) {
int ch = in.get();
int top = ch >> 8;
if(top >= 10)
throw new NumberFormatException();
int bottom = ch & 0xff;
digits.append(Character.forDigit(top, 10));
if(bottom < 10)
digits.append(Character.forDigit(bottom, 10));
else if(i != 6)
throw new NumberFormatException();
else
switch(bottom) {
case 0xf:
case 0xc:
break;
case 0xd:
negative = true;
break;
default:
throw new NumberFormatException();
}
}
}
> Ewww.
>
> Just my 2c
Takes me back nearly 30 years. Still, packed decimal probably makes sense for compact storage of things like credit card numbers, which are composed of digits but aren't really numbers, in the sense that doing arithmatic on them is meaningful.
Back then conversion between binary and decimal was considered fairly expensive. In fact the IBM mainframes had assembler language instructions for doing arithmatic on packed decimal values, as well as for packing/unpacking them.
In my first job using binary numbers was rare.
*grateful for the historical reminder* We covered packed decimal in some of my earlier college classes, if I remember correctly... particularly the introductory COBOL course. (My degree is not yet two years old but the Computer Science department is fond of training students for maintaining old business apps.)
In a modern context, though, it doesn't seem that it would be effective to store the values in that manner. A credit card is sixteen digits, which can produce a maximum value of 10^16 < 2^54. Packing the digits four bits to a digit would allow the number to be stored in 8 bytes, whereas one could use a 7 byte space to store it in binary. The other advantage of using a binary value would be that, in Java memory, the value could be represented by a native data type (long).
Admittedly, more work would have to be done in displaying the value... but usually, credit card numbers are checked and not displayed from records (in my personal experience).
I also remember, now that I think about it, that our Microprocessor Architecture and Design teacher mentioned the thing about machine instructions for working on packed decimals...
Just for fun, here's another way to do it:
public intbinaryValue(int bcd)
{
longx = bcd;
x -= (x & 0xf0f0f0f0)*(0x10-10) >> 4;
x -= (x & 0xff00ff00)*(0x100-100) >> 8;
x -= (x & 0xffff0000)*(0x10000-10000) >> 16;
return (int)x;
// or String.valueOf(x);
}
