works with PIC S9(13) COMP-3 in a string
Status: Beta
Brought to you by:
dubwai
Menu
▾
▴
hello.
I have a problem. I have to convert a PIC S9(13) COMP-3 in a string that I get for jdbc.
this toolkit work for this?
I am pleased to see a project to address the integration of cobol with java:)
The use case that I designed this tool for was for parsing a number of fields based on a copybook. So the normal first step would be to provide that copybook for your data and then parse it.
You question makes me realize that I have made a mistake, in my opinion. I've not allowed the classes to be used outside of the context above. I think that I am going to make the necessary methods public so that a single piece of data can be parsed or so that anyone can build a parse model in any way they see fit.
For now, you can download the source for the library and make the constructor and parse method of Packed public. If you run into issues, feel free to respond to this post with more questions.
thanks for your interest,
-James
I made changes as recommended but not resulted, perhaps I did something wrong.
Here is the code:
.....
str = vhrc.getXcontem1().substring(14, 21) ;//String by jdbc acess to mainframe z/os with db2;
converte(str);
static void converte(String str){
Packed p = new Packed("value:", 10, 1, "S9(13)");
Data data = p.parse(str.getBytes());
System.out.println("conversion:" + data.getName() + ": " + data.getValue());
}
.....
If you could help
thanks.
Rui Simões
A few questions:
What is an example input and what is the expected result?
What is the result you are getting?
What environment are you running in? Is it zOS?
If so, did you set your encoding?
thanks,
-James
"What is an example input and what is the expected result?
What is the result you are getting? " ->i will send you the files.
"What environment are you running in? Is it zOS? "->Environment: db2 in a zOS; cb2java in win xp; access to data by jdbc.
And in your 1º post you said "You question makes me realize that I have made a mistake ....", in my opinion this is not a mistake is a missing feature :) I will try to help you.
thanks,
Rui Simoes
Hi Rui-
One thing you can try before on your own is making sure you set the encoding to the proper value. If the data was created on zOS, it will have been created using an ebcdic encoding. The encoding name will be "ibm-" + the ebcdic codeset. For example, for American English, we use "ibm-37". As I'm typing this, I'm starting to question whether this will matter for packed numbers but you should make sure to set it anyway. The other thing that comes to mind is an issue another user reported with whether the sign defaults to trailing to leading in different environments. cb2java needs to support both but I think there is only currently support for leading.
I'll respond to your other post directly.
thanks,
-James
Hi Rui,
Can you change the Packed.parse() method as the following:
Data parse(byte[] input)
{
//original: sign leading (first nybble contains the sign)
//boolean negative = signed() && (input[0] & 0x0F) == 0x0D;
//change to: sign trailing (last nybble contains the sign)
byte lastByte = input[input.length -1];
boolean negative = signed() && (lastByte & 0x0F) == 0x0D;
....
If it works, then the default for your environment is sign trailing.
-Trung
Hi Rui,
I have received your data and copybook files. The data file (rs.data) contains 2 packed fields. Looking at the data with hex editor, the first packed field is 00 00 00 00 01 DA 40, which is not a valid packed data. And the second field: 00 00 00 00 00 13 3C, which is 133.
So, you need to double check the program that generates rs.data file.
Hope this helps!
-Trung
Hi Trung,
noticed that the FTP client that I use, automatically converts the file in ASCII(EBCDIC->ASCII) , make FTP in BINARY mode solve the problem, getting the correct conversion.
Now I will try to convert PIC S9 (13) COMP-3 in a string from jdbc connection.
I will put the results here
Thanks
Rui
Hi.
I am try to convert PIC S9 (13) COMP-3 in a string from jdbc connection.
case 1:
Using copybook(rs2.cpy)
01 WS-TAB-2.
05 WS-TAB-OCU-2 OCCURS 11.
10 WS-1 PIC X(02).
10 WS-2 PIC X(12).
10 WS-3 PIC S9(13) COMP-3.
10 WS-4 PIC X(01).
10 WS-5 PIC X(01).
file rs2.data(FTP in BINARY mode) works well.
case 2:
Using copybook(rs2.cpy same used in case 1 )
....
PreparedStatement ps = conn.prepareStatement(sql);
ResultSet rs = ps.executeQuery();
rs.next();
try {
Copybook document = CopybookParser.parse("simple", new FileReader("rs2.cpy"));
Record documentData = document.parseData( rs.getBinaryStream(16));
....
DEFINITION OF the table column 'CHAR(253) NOT NULL' (DB2)
fist 3 values ok, the next 7831C is converted to 7832(wrong) and i received 78322(hex) and the next numbers are also wrong.
Any clue?
Thanks
Rui Simoes
Rui-
The best I can offer for help is to ask you to add this method somewhere in your code, call it with both the InputStream from the file and from the JDBC and compare the output. I haven't compiled or tested this, but I think you should be able to resolve any such issues. Let us know once you find the differences.
void printOutput(InputStream stream) {
for (int b; (b = stream.read()) >= 0;) {
System.out.print(Integer.toHexString(b));
System.out.print(' ');
}
System.out.println();
}
-James
by jdbc:
c4 c5 40 40 40 f1 f1 f7 f0 f4 f2 f0 f1 f4 0 0 0 0 2 25 3c f1 c3 c4 c5 40 40 40 f1 f2 f5 f4 f9 f5 f5 f2 f2 0 0 0 0 12 71 9c f1 c3 c4 c5 40 40 40 f1 f8 f5 f8 f4 f9 f6 f6 f7 0 0 0 0 19 81 4c f1 c3 c4 c5 40 40 40 f1 f8 f7 f2 f1 f6 f2 f0 f8 0 0 0 0 7 83 22 f1 c3 c4 c5 40 40 40 f1 f9 f1 f7 f6 f3 f2 f6 f0 0 0 0 0 87 16 6b f1 c3 c4 c5 40 40 40 f8 f1 f1 f1 f7 f5 f4 f9 f0 0 0 0 0 5 76 4c f1 c3 c4 c5 40 40 40 f8 f1 f2 f5 f7 f2 f1 f9 f3 0 0 0 0 27 99 22 f1 c3 c4 d2 40 40 40 40 f2 f5 f8 f6 f0 f2 f7 f6 0 0 0 0 7 86 7c f1 c3 c5 e2 40 40 40 c1 f3 f7 f0 f4 f4 f6 f8 f2 0 0 0 0 2 4d 3c f1 c3 c6 d9 40 f6 f8 f3 f1 f4 f3 f9 f7 f7 f1 f2 0 0 0 0 22 73 6c f1 c3 c6 d9 40 f9 f1 f6 f7 f8 f5 f0 f1 f1 f2 f3 0 0 0 0 2e f1 4c f1 c3
by file(this is the correct):
c4 c5 40 40 40 f1 f1 f7 f0 f4 f2 f0 f1 f4 0 0 0 0 2 25 3c f1 c3 c4 c5 40 40 40 f1 f2 f5 f4 f9 f5 f5 f2 f2 0 0 0 0 12 71 9c f1 c3 c4 c5 40 40 40 f1 f8 f5 f8 f4 f9 f6 f6 f7 0 0 0 0 19 81 4c f1 c3 c4 c5 40 40 40 f1 f8 f7 f2 f1 f6 f2 f0 f8 0 0 0 0 7 83 1c f1 c3 c4 c5 40 40 40 f1 f9 f1 f7 f6 f3 f2 f6 f0 0 0 0 0 87 8 2c f1 c3 c4 c5 40 40 40 f8 f1 f1 f1 f7 f5 f4 f9 f0 0 0 0 0 9 76 4c f1 c3 c4 c5 40 40 40 f8 f1 f2 f5 f7 f2 f1 f9 f3 0 0 0 0 27 99 1c f1 c3 c4 d2 40 40 40 40 f2 f5 f8 f6 f0 f2 f7 f6 0 0 0 0 7 86 7c f1 c3 c5 e2 40 40 40 c1 f3 f7 f0 f4 f4 f6 f8 f2 0 0 0 0 2 28 3c f1 c3 c6 d9 40 f6 f8 f3 f1 f4 f3 f9 f7 f7 f1 f2 0 0 0 0 22 73 6c f1 c3 c6 d9 40 f9 f1 f6 f7 f8 f5 f0 f1 f1 f2 f3 0 0 0 0 6 31 4c f1 c3
Rui,
Can you post the results from James' suggestion? Also, I recall that there was an issue with Copybook.parse(InputStream). Can you change your code to use Copybook.parse(byte[]) instead? Basically,
CHANGE
. Record documentData = document.parseData(rs.getBinaryStream(16));
TO
. InputStream is = rs.getBinaryStream(16);
. byte[] rawData = new byte[is.available()];
. is.read(rawData);
. Record documentData = document.parseData(rawData);
Thanks,
-Trung
Rui,
The comp-3 data for the 4th row is 00 00 00 00 07 83 22. This is definitely not a valid comp-3 data. You need to make sure that the source data from the DB table are correct.
Thanks,
-Trung
Yeah, I see some subtle differences in the data from ftp and from jdbc. The first thing to do is to check that the DB has the right data through a separate, reliable means.
Hi All,
Can you please let me know if COMP-3 is supported by the utility ?
Thanks
Sanket