Accessing mainframe DB2 in Java.

[zalek]

Hello,

I am a mainframe Cobol programmer (yes - Cobol programmers are still
around, mostly in caves) and I am writing a java code to access DB2.
In a Cobol world after each SQL command we are checking for return
conditions like success (sqlcode=0), not found (sqlcode = +100),
duplicates (sqlcode=803) and more.
How do you check for this conditions in Java?

Thanks,

Zalek

 

[Arne Vajhøj]

I am a mainframe Cobol programmer (yes - Cobol programmers are still
around, mostly in caves) and I am writing a java code to access DB2.
In a Cobol world after each SQL command we are checking for return
conditions like success (sqlcode=0), not found (sqlcode = +100),
duplicates (sqlcode=803) and more.
How do you check for this conditions in Java?

Usually (possible always) the JDBC driver will throw an SQLException
if not success.

Arne

 

[zalek]

Usually (possible always) the JDBC driver will throw an SQLException
if not success.

Arne

Yes - I know - but I would like to know what exactly happen. For
example - if I try to access a table using a variable as a key - I
would like to know "not found conditions" occurred to display correct
message. If database was down - I would like to know it too. Is there
a way in a java world to find it?

Thanks,

Zalek

 

[Mark Space]

Hello,

I am a mainframe Cobol programmer (yes - Cobol programmers are still
around, mostly in caves) and I am writing a java code to access DB2.

Run Zalek!

Run to the light!

 

[Mark Space]

Hello,

I am a mainframe Cobol programmer (yes - Cobol programmers are still
around, mostly in caves) and I am writing a java code to access DB2.
In a Cobol world after each SQL command we are checking for return
conditions like success (sqlcode=0), not found (sqlcode = +100),
duplicates (sqlcode=803) and more.
How do you check for this conditions in Java?

Thanks,

Zalek

I'm going to guess:

I see SQLException has a constructor that takes a vendor specific return
code ("vendorCode"). I think you'll have to either 1) parse the
toString() result (or similar string result) or 2) use reflection to
peek at the internal vendorCode variable.

Ugly as it is, I think the second method might actually be more reliable.

 

[Arne Vajhøj]

Yes - I know - but I would like to know what exactly happen. For
example - if I try to access a table using a variable as a key - I
would like to know "not found conditions" occurred to display correct
message. If database was down - I would like to know it too. Is there
a way in a java world to find it?

e.getErrorCode() will give you SQLCODE number.
e.getSQLState() wil give you SQLSTATE number.
e.getMessage() will give you the entire message.

Example:

} catch (SQLException e) {
System.out.println(e.getErrorCode());
System.out.println(e.getSQLState());
System.out.println(e.getMessage());

print:

-104
42601
DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC:
END-OF-STATEMENT;SELECT x* FROM T1;<table_expr>

Arne

 

[Mark Space]

e.getErrorCode() will give you SQLCODE number.

Duh. You know I looked right at that in the Javadocs and because it
didn't say "getVendorCode" I didn't read any further? Ouch.

 

[i.dont.need]

Hello,

I am a mainframe Cobol programmer (yes - Cobol programmers are still
around, mostly in caves) and I am writing a java code to access DB2.
In a Cobol world after each SQL command we are checking for return
conditions like success (sqlcode=0), not found (sqlcode = +100),
duplicates (sqlcode=803) and more.

If you intend to write to the db directly, rather than via ORM, then I'd
recommend using Spring's JDBC facilities. Their approach to this issue
is to rethrow much more specific exceptions outlining what went wrong. I
find this to be marginally better, but the real benefit of Spring here
is getting rid of all that horrid boiler plate code that one must write
with straight JDBC. If your intent is to learn, then try a few methods
both ways and see for yourself.

 

[Mickey]

Run Zalek!

Run to the light!

As verbose and ungainly as Cobol is, I'd prefer it any day to Java.
Then again, I'd prefer a sharp object in the eye to Java.

Mickey - Rexx rules ))))

 

[Alex.From.Ohio.Java]

As verbose and ungainly as Cobol is, I'd prefer it any day to Java.

And you are right! Stay in your world.
It's wonderful and amazing.
Never saw anything like this one.
They even blame Java in their own faults...

We had project where we had connection to at least half of dozen
different database platforms. But only DB2 Connect tried to charge us
for $6,000 for single query. From mainframe side, of course. And they
killed this project because it was "too expensive to connect to DB2".

It was very efficient to connect to DB2 with Cobol (but they didn't
tell us what price would it be). However it was impossible to connect
to other databases from mainframe side and project was finally
canceled as impossible to create.

Alex.
http://www.myjavaserver.com/~alexfromohio/