|
Hi Bob, Sorry for the delay, blame those pesky clients ( who believe our 24/7 claims ) and the Olympics. I thought I had been reasonably clear before, but I'll step through it. A few things first: * Read the binary file with no encoding specified. This still uses the default encoding, but the net effect is no translation of the binary data. That's what you want, because you will be converting the data yourself. * Don't use BinaryConverter. As I mentioned in my previous message, it doesn't understand BCD and the effective output for this purpose is garbage. * Read the API's. AS400PackedDecimal wants the number of digits, not the field length. Steps: Get a FileInputStream ( with buffering for efficiency ) on the binary file. Loop until read receives -1 for EOF. Read for the record length into a record-sized byte array. For Strings, use the constructor that takes a byte array, offset, length and encoding. I use "Cp500", but whatever works for you. For the packed fields, use an AS400PackedDecimal variable with the proper number of digits and decimal positions. From your example, use a4PD = new AS400PackedDecimal( 7, 0 ); Then use AS400PackedDecimal.toDouble(byte[] as400Value, int offset) and cast to an int or use AS400PackedDecimal.toObject(byte[] as400Value, int offset) and get the intValue() from the returned BigDecimal. Repeat as appropriate for each field in the record. end of Loop. Joe Sam Joe Sam Shirah - http://www.conceptgo.com conceptGO - Consulting/Development/Outsourcing Java Filter Forum: http://www.ibm.com/developerworks/java/ Just the JDBC FAQs: http://www.jguru.com/faq/JDBC Going International? http://www.jguru.com/faq/I18N Que Java400? http://www.jguru.com/faq/Java400 ----- Original Message ----- From: <b.szemethy@xxxxxxxxxxx> To: "Java Programming on and around the iSeries / AS400" <java400-l@xxxxxxxxxxxx> Sent: Tuesday, August 24, 2004 9:00 AM Subject: Re: Help w/ Packed Decimal > Thanks Joe and Mark - > First a little background: The field is 4 bytes long packed, 7 unpacked. It's an integer value, so no decimals (Although I have dollar amounts to deal with if I get past this). I've tried the below code three different ways: > 1) Reading the file that had been converted to ASCII > 2) Reading the binary file, with encoding set to "IBM1047" > 3) Reading the binary file, with no encoding. > Here's the code I'm using: > String strValue = rec.substring (from-1, to); > System.out.println("strValue = " + BinaryConverter.bytesToString (strValue.getBytes () )); > AS400PackedDecimal pd = new AS400PackedDecimal (4,0); > double pdNum = pd.toDouble (BinaryConverter.stringToBytes (strValue)); > System.out.println ("Packed Decimal = " + pdNum); > And the result (From all three attempts) : > strValue = 0000000C > java.lang.NumberFormatException > at com.ibm.as400.access.BinaryConverter.stringToBytes(BinaryConverter.java:531) > at com.ibm.as400.access.BinaryConverter.stringToBytes(BinaryConverter.java:485) > at com.ibm.as400.access.BinaryConverter.stringToBytes(BinaryConverter.java:478) > at gcs.ParseCAT_GLS.parseRecord(ParseCAT_GLS.java:142) > at gcs.ParseCAT_GLS.parseRecord(ParseCAT_GLS.java:160) > at gcs.ParseCAT_GLS.parseRecord(ParseCAT_GLS.java:160) > at gcs.ParseCAT_GLS.getNextRecord(ParseCAT_GLS.java:117) > at gcs.TransformCAT_GLS.main(TransformCAT_GLS.java:44) > Exception in thread "main" > I thought about trying to create a SequentialFile object along with a RecordFormat object, but that requires a connection to a server. > -------------- Original message -------------- > > > > > Hi Bob, > > > > You need to bring the file across as binary and then do a field by field > > conversion using the String and > > com.ibm.as400.access.AS400PackedDecimal classes. > > > > If you bring it down as text, each byte, typically, is converted to > > ASCII. That doesn't work for true numeric fields because they aren't > > characters but binary values that don't map to a character set. The same is > > true for a non-EBCDIC file that contains numbers and characters, and is why > > trying to just use an encoding translation on that kind of file doesn't > > work. > > > > As Mark indicated, BinaryConverter doesn't understand that C, D and/or F > > are sign indicators and takes them at their hex value. While we are > > accustomed to 'F' for positive values on the '400, 'C' is an explicit > > positive used often on mainframes. If my recollection is correct, any value > > other than 'D' is taken as positive. > > > > Have fun, > > > > > > Joe Sam > > > > Joe Sam Shirah - http://www.conceptgo.com > > conceptGO - Consulting/Development/Outsourcing > > Java Filter Forum: http://www.ibm.com/developerworks/java/ > > Just the JDBC FAQs: http://www.jguru.com/faq/JDBC > > Going International? http://www.jguru.com/faq/I18N > > Que Java400? http://www.jguru.com/faq/Java400 > > > > > > ----- Original Message ----- > > From: "Bob Szemethy" > > To: > > Sent: Monday, August 23, 2004 10:51 PM > > Subject: Help w/ Packed Decimal > > > > > > > Hi all - > > > > > > A quick question about a flat file built on a S/390, that I am trying to > > > process on a Windows box using JTOpen. > > > > > > I have access to the file only though an FTP applet that our HQ > > > maintains, and I pulled the file down as text and as binary. When I'm > > > processing the file, I have no trouble with the text fields, but there > > > are some packed decimal fields that are not coming across. > > > > > > I also was able to parse the binary file when I set the encoding to > > > "IBM1047", but had the same problem with the packed fileds. > > > > > > I tried the BinaryConverter class, and the method to convert to Hex > > > string for the byte array, and for the text and binary files, it returns > > > the following sting for a 4 byte number : "0000000C", which I understand > > > to be 12, but I know the number should be 1. > > > > > > So my question is this: Can I parse a packed-decimal field in a file > > > that has been translated to ASCII or Unicode? Thanks for any help. > > > > > > Bob > > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.