Accessing mainframe DB2 in Java.

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

zalek - 22 Mar 2008 22:12 GMT

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

Reply to this Message

Arne Vajhøj - 22 Mar 2008 22:14 GMT

> 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

Reply to this Message

zalek - 22 Mar 2008 22:28 GMT

> > 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.
[quoted text clipped - 7 lines]
>
> 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

Reply to this Message

Arne Vajhøj - 23 Mar 2008 00:02 GMT

>>> 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.
[quoted text clipped - 10 lines]
> 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

Reply to this Message

Mark Space - 23 Mar 2008 00:42 GMT

>>>> 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.
[quoted text clipped - 12 lines]
>
> 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.

Reply to this Message

Mark Space - 22 Mar 2008 22:28 GMT

> 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!

Reply to this Message

Mickey - 25 Mar 2008 19:14 GMT

> > Hello,
> >
[quoted text clipped - 4 lines]
>
> 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 :)))))

Reply to this Message

Alex.From.Ohio.Java@gmail.com - 25 Mar 2008 19:45 GMT

> 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/

Reply to this Message

Mark Space - 22 Mar 2008 22:36 GMT

> Hello,
>
[quoted text clipped - 8 lines]
>
> 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.

Reply to this Message

i.dont.need@any.more.email - 23 Mar 2008 21:22 GMT

> Hello,
>
[quoted text clipped - 3 lines]
> 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.

Signature

Shane

Reply to this Message