is it possible to connect to db2/390 without having db2 connect?

[aka]

Hi

I have a DB2 v8.1 on AIX and DB2 Connect EE on Solaris wich is connected to
OS/390 DB2 subsystems via APPC / SNA. I have cataloged the DB2 Connect
instance as tcpip node and then the Host DB cataloged on that node...this
works from v7.2 Fixpack 11 clients and servers, but with v8.1 server I get
SQL1334N.
Does anyone has an idea?

Thanks
aka

[aka]

> So it looks like you are trying to connect a V8 client over TCP/IP to a

V7 DB2 Connect EE, which in turn, uses SNA to talk to DB2 V6 on 390.

Are there all 32-bit environments?

You ought to open a PMR with IBM for this. I'm not sure if this is
supported. Unless someone else has a suggestion.

Larry Edelstein

Yes Larry, all are 32 bit and that's exactly what I'm trying to do :) it
seems to me a good first try in walking the way towards v8 (remember, when I
only use v7 client in this config, all works fine)...now I understand that
there is some potential difficulties in this configuration, as Blair stated
earlier, so my next step would be to get the gateway upgraded to v8, wich in
turn introduces the need to change the environment from APPC/SNA to CPIC (if
I got this right) also on the gateway machine, and I don't know, if that
would cause more changes on the mainframe.

I would be glad hearing from someone who managed connection to DB2/390 in
such a multi tier environment from v8 as client and how this could be done.

Thx
aka

by the way...the type 4 connection requires TCP/IP on the mainframe, is that
right?

[Alex Kizub]

IBM is so bad and proprietary. Only M$ is worse!
It took 1 (one) year for me to obtain working JDBC connection directly to
mainframe DB2 (without DB2 Connect).
I will not mention my endless and helpless searches for it. IBM made everything
to hide it as deep as possible...

OK. Here is result.
I installed latest DB2 Connect for Sun Solaris (that's another story), then
installed latest patch and (even it doesn't work) I found working JDBC type 4
driver in installed directory.
Additional brainstorm efforts gave me suggestion to use another jar files from
this instalation as licenses.
And license for mainframe is in the db2jcc_license_ cisuz.jar

So, when you do all this work it would be pretty easy! Write DA.java:
then compile:
javac DA.java
and run it:
java -classpath .:db2jcc.jar:db 2jcc_license_ci suz.jar DA

That's all. And of course you need TCP/IP on mainframe. But these parameters are
the same for DB2 Connect and you can ask your DBAs. For me they are:
("jdbc:db2://big.mainframe.n et:2336/TEST_DBT1","use r","password ");

Unfortunately you still need DB2 Connect but for licesnse purposes only. It is
not necessary to install it or use it when you have these jar files and
licenses.

Alex Kizub.

aka wrote:

So it looks like you are trying to connect a V8 client over TCP/IP to a
V7 DB2 Connect EE, which in turn, uses SNA to talk to DB2 V6 on 390.

Are there all 32-bit environments?

You ought to open a PMR with IBM for this. I'm not sure if this is
supported. Unless someone else has a suggestion.

Larry Edelstein

Yes Larry, all are 32 bit and that's exactly what I'm trying to do :) it
seems to me a good first try in walking the way towards v8 (remember, when I
only use v7 client in this config, all works fine)...now I understand that
there is some potential difficulties in this configuration, as Blair stated
earlier, so my next step would be to get the gateway upgraded to v8, wich in
turn introduces the need to change the environment from APPC/SNA to CPIC (if
I got this right) also on the gateway machine, and I don't know, if that
would cause more changes on the mainframe.

I would be glad hearing from someone who managed connection to DB2/390 in
such a multi tier environment from v8 as client and how this could be done.

Thx
aka

by the way...the type 4 connection requires TCP/IP on the mainframe, is that
right?

[Alex Kizub]

IBM is so bad and proprietary. Only M$ is worse!
It took 1 (one) year for me to obtain working JDBC connection directly to
mainframe DB2 (without DB2 Connect).
I will not mention my endless and helpless searches for it. IBM made everything
to hide it as deep as possible...

OK. Here is result.
I installed latest DB2 Connect for Sun Solaris (that's another story), then
installed latest patch and (even it doesn't work) I found working JDBC type 4
driver in installed directory.
Additional brainstorm efforts gave me suggestion to use another jar files from
this instalation as licenses.
And license for mainframe is in the db2jcc_license_ cisuz.jar

So, when you do all this work it would be pretty easy! Write DA.java:
then compile:
javac DA.java
and run it:
java -classpath .:db2jcc.jar:db 2jcc_license_ci suz.jar DA

That's all. And of course you need TCP/IP on mainframe. But these parameters are
the same for DB2 Connect and you can ask your DBAs. For me they are:
("jdbc:db2://big.mainframe.n et:2336/TEST_DBT1","use r","password ");

Unfortunately you still need DB2 Connect but for licesnse purposes only. It is
not necessary to install it or use it when you have these jar files and
licenses.

Alex Kizub.

aka wrote:

So it looks like you are trying to connect a V8 client over TCP/IP to a
V7 DB2 Connect EE, which in turn, uses SNA to talk to DB2 V6 on 390.

Are there all 32-bit environments?

You ought to open a PMR with IBM for this. I'm not sure if this is
supported. Unless someone else has a suggestion.

Larry Edelstein

Yes Larry, all are 32 bit and that's exactly what I'm trying to do :) it
seems to me a good first try in walking the way towards v8 (remember, when I
only use v7 client in this config, all works fine)...now I understand that
there is some potential difficulties in this configuration, as Blair stated
earlier, so my next step would be to get the gateway upgraded to v8, wich in
turn introduces the need to change the environment from APPC/SNA to CPIC (if
I got this right) also on the gateway machine, and I don't know, if that
would cause more changes on the mainframe.

I would be glad hearing from someone who managed connection to DB2/390 in
such a multi tier environment from v8 as client and how this could be done.

Thx
aka

by the way...the type 4 connection requires TCP/IP on the mainframe, is that
right?

[Jan M. Nelken]

Alex Kizub wrote:

IBM is so bad and proprietary. Only M$ is worse!
It took 1 (one) year for me to obtain working JDBC connection directly to
mainframe DB2 (without DB2 Connect).
I will not mention my endless and helpless searches for it. IBM made everything
to hide it as deep as possible...

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:
"Setting Up the UNIX Java Environment

To run JDBC and SQLJ programs on UNIX with DB2 JDBC support, commands to
update your Java environment are included in the database manager files
db2profile and db2cshrc. When a DB2 instance is created, .bashrc,
..profile, and/or .cshrc are modified so that:

1. THREADS_FLAG is set to "native". (on HP-UX, Linux and Solaris only)
2. CLASSPATH includes:
* "." (the current directory)
* the file sqllib/java/db2java.zip
* the file sqllib/java/db2jcc.jar
* the file sqllib/java/db2jcc_license_ cu.jar

Note:
db2jcc_license_ cisuz.jar is also included in the CLASSPATH for DB2
Connect Personal Edition, DB2 Connect Enterprise Edition, and DB2 ESE.
This provides additional connectivity to DB2 for z/OS and OS/390, DB2
for AS/400 and iSeries, and DB2 for VSE & VM."
Jan M. Nelken

[Jan M. Nelken]

Alex Kizub wrote:

IBM is so bad and proprietary. Only M$ is worse!
It took 1 (one) year for me to obtain working JDBC connection directly to
mainframe DB2 (without DB2 Connect).
I will not mention my endless and helpless searches for it. IBM made everything
to hide it as deep as possible...

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:
"Setting Up the UNIX Java Environment

To run JDBC and SQLJ programs on UNIX with DB2 JDBC support, commands to
update your Java environment are included in the database manager files
db2profile and db2cshrc. When a DB2 instance is created, .bashrc,
..profile, and/or .cshrc are modified so that:

1. THREADS_FLAG is set to "native". (on HP-UX, Linux and Solaris only)
2. CLASSPATH includes:
* "." (the current directory)
* the file sqllib/java/db2java.zip
* the file sqllib/java/db2jcc.jar
* the file sqllib/java/db2jcc_license_ cu.jar

Note:
db2jcc_license_ cisuz.jar is also included in the CLASSPATH for DB2
Connect Personal Edition, DB2 Connect Enterprise Edition, and DB2 ESE.
This provides additional connectivity to DB2 for z/OS and OS/390, DB2
for AS/400 and iSeries, and DB2 for VSE & VM."
Jan M. Nelken

[Alex Kizub]

"Jan M. Nelken" <jn*****@ca.ibm .com> wrote in message news:<c7******* ***@hanover.tor olab.ibm.com>.. .

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:

Jan: Thanks for url.
But it really took one year to get *working* example.
Probably it is easy for IBM guys to find such information (with all
tranings or direct phone calls) but it's really hard for such ordinary
people like me who work with Java only 7 years and have JDBC
experience for 7 eyars too.

With such fragmented documentaion what IBM provides only guys who
wrote it can find necessary parts and unite them to working peaces.
For example, I ran application and had:
Connection failed DB2 SQL error: SQLCODE: -1334, SQLSTATE: ,
SQLERRMC: null
Would you like to send me url which explains this code?
It will be really appreciated. Because in one year on my researches I
didn't find it.

Actually I was very proud when I found the way. I can tell you that
I'm first in our 30,000 people company who did it. Of course not even
minority of my company are Java programmers but you can imagine level.

So, I was happy... Until I had real work. Here I'm not happy at all.
In comparison with Oracle this particular JDBC driver matches year
1998. No more. And speed is awesome! For my task it's 30-50% of
appropiate Oracle on UNIX.

But, of course, we have to support legacy systems and work with what
we have.
And this particular driver helps a lot. When works...
And I'm really happy that I have at leats this one and don't have tpo
write whole application on COBOL.

Thanks again,
Alex Kizub.

[Alex Kizub]

"Jan M. Nelken" <jn*****@ca.ibm .com> wrote in message news:<c7******* ***@hanover.tor olab.ibm.com>.. .

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:

Jan: Thanks for url.
But it really took one year to get *working* example.
Probably it is easy for IBM guys to find such information (with all
tranings or direct phone calls) but it's really hard for such ordinary
people like me who work with Java only 7 years and have JDBC
experience for 7 eyars too.

With such fragmented documentaion what IBM provides only guys who
wrote it can find necessary parts and unite them to working peaces.
For example, I ran application and had:
Connection failed DB2 SQL error: SQLCODE: -1334, SQLSTATE: ,
SQLERRMC: null
Would you like to send me url which explains this code?
It will be really appreciated. Because in one year on my researches I
didn't find it.

Actually I was very proud when I found the way. I can tell you that
I'm first in our 30,000 people company who did it. Of course not even
minority of my company are Java programmers but you can imagine level.

So, I was happy... Until I had real work. Here I'm not happy at all.
In comparison with Oracle this particular JDBC driver matches year
1998. No more. And speed is awesome! For my task it's 30-50% of
appropiate Oracle on UNIX.

But, of course, we have to support legacy systems and work with what
we have.
And this particular driver helps a lot. When works...
And I'm really happy that I have at leats this one and don't have tpo
write whole application on COBOL.

Thanks again,
Alex Kizub.

[aka]

Hi Alex,

good talking...I support your opinion of IBM information hiding when it
comes to get into contact with mainframe systems, also I'm very thankful for
your hints on getting a JDBC working connection...I will try it out.

So the question seems to be answered, that indeed we need DB2 Connect to get
into contact with DB2/390, and even if using SNA protocol...but then I found
this in the publib.boulder Information center:

(...) Other features of DB2 UDB Enterprise Server Edition include:
a.. A data warehouse server and related components.
b.. DB2 Connect(TM) functionality for accessing data stored on midrange
and mainframe database systems such as DB2 for iSeries(TM) or DB2 UDB for
z/OS(TM) and OS/390. DB2 UDB Enterprise Server Edition provides support for
both local and remote DB2 clients.
Use of the DB2 Connect component is limited to five (5) registered users
per server. If additional users are required, a separate DB2 Connect program
must be acquired. Contact your IBM sales representative for more
information.

"Alex Kizub" <ak****@yahoo.c om> schrieb im Newsbeitrag
news:9d******** *************** **@posting.goog le.com...

"Jan M. Nelken" <jn*****@ca.ibm .com> wrote in message

news:<c7******* ***@hanover.tor olab.ibm.com>.. .

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:

Jan: Thanks for url.
But it really took one year to get *working* example.
Probably it is easy for IBM guys to find such information (with all
tranings or direct phone calls) but it's really hard for such ordinary
people like me who work with Java only 7 years and have JDBC
experience for 7 eyars too.

With such fragmented documentaion what IBM provides only guys who
wrote it can find necessary parts and unite them to working peaces.
For example, I ran application and had:
Connection failed DB2 SQL error: SQLCODE: -1334, SQLSTATE: ,
SQLERRMC: null
Would you like to send me url which explains this code?
It will be really appreciated. Because in one year on my researches I
didn't find it.

Actually I was very proud when I found the way. I can tell you that
I'm first in our 30,000 people company who did it. Of course not even
minority of my company are Java programmers but you can imagine level.

So, I was happy... Until I had real work. Here I'm not happy at all.
In comparison with Oracle this particular JDBC driver matches year
1998. No more. And speed is awesome! For my task it's 30-50% of
appropiate Oracle on UNIX.

But, of course, we have to support legacy systems and work with what
we have.
And this particular driver helps a lot. When works...
And I'm really happy that I have at leats this one and don't have tpo
write whole application on COBOL.

Thanks again,
Alex Kizub.

[aka]

Hi Alex,

good talking...I support your opinion of IBM information hiding when it
comes to get into contact with mainframe systems, also I'm very thankful for
your hints on getting a JDBC working connection...I will try it out.

So the question seems to be answered, that indeed we need DB2 Connect to get
into contact with DB2/390, and even if using SNA protocol...but then I found
this in the publib.boulder Information center:

(...) Other features of DB2 UDB Enterprise Server Edition include:
a.. A data warehouse server and related components.
b.. DB2 Connect(TM) functionality for accessing data stored on midrange
and mainframe database systems such as DB2 for iSeries(TM) or DB2 UDB for
z/OS(TM) and OS/390. DB2 UDB Enterprise Server Edition provides support for
both local and remote DB2 clients.
Use of the DB2 Connect component is limited to five (5) registered users
per server. If additional users are required, a separate DB2 Connect program
must be acquired. Contact your IBM sales representative for more
information.

"Alex Kizub" <ak****@yahoo.c om> schrieb im Newsbeitrag
news:9d******** *************** **@posting.goog le.com...

"Jan M. Nelken" <jn*****@ca.ibm .com> wrote in message

news:<c7******* ***@hanover.tor olab.ibm.com>.. .

I am confused - did it take you one year to *find* this information in
online documentation available at
http://publib.boulder.ibm.com/infoce...help/index.jsp,
or did it take you one year to *comprehend* it:

Jan: Thanks for url.
But it really took one year to get *working* example.
Probably it is easy for IBM guys to find such information (with all
tranings or direct phone calls) but it's really hard for such ordinary
people like me who work with Java only 7 years and have JDBC
experience for 7 eyars too.

With such fragmented documentaion what IBM provides only guys who
wrote it can find necessary parts and unite them to working peaces.
For example, I ran application and had:
Connection failed DB2 SQL error: SQLCODE: -1334, SQLSTATE: ,
SQLERRMC: null
Would you like to send me url which explains this code?
It will be really appreciated. Because in one year on my researches I
didn't find it.

Actually I was very proud when I found the way. I can tell you that
I'm first in our 30,000 people company who did it. Of course not even
minority of my company are Java programmers but you can imagine level.

So, I was happy... Until I had real work. Here I'm not happy at all.
In comparison with Oracle this particular JDBC driver matches year
1998. No more. And speed is awesome! For my task it's 30-50% of
appropiate Oracle on UNIX.

But, of course, we have to support legacy systems and work with what
we have.
And this particular driver helps a lot. When works...
And I'm really happy that I have at leats this one and don't have tpo
write whole application on COBOL.

Thanks again,
Alex Kizub.

[Jan M. Nelken]

Alex Kizub wrote:

With such fragmented documentaion what IBM provides only guys who
wrote it can find necessary parts and unite them to working peaces.
The reaon I included URL was that this should be your starting point in
any research. This link points to *current* documentation available.
When there is an update - due to FixPack nn upgrade, the quickest way to
see updated documentation would be to use link I gave you.

My main point in slightly provoking answer was to encourage you to start
your research from that link. There are other people - Xixi comes to
mind - who would start asking questions here *before* consulting
available documentation.
For example, I ran application and had:
Connection failed DB2 SQL error: SQLCODE: -1334, SQLSTATE: ,
SQLERRMC: null
Would you like to send me url which explains this code?
It will be really appreciated. Because in one year on my researches I
didn't find it.

Same location:

Open Reference->Messages->SQL->SQL1300-SQL13199 -> SQL1334:\

SQL1334N The database server cannot be used to route a remote request
to a second database server in this configuration.

Explanation: An attempt was made to route a request through a database
server node using an unsupported combination of client and target
database server. Either a client or target database prior to release
version 2 was used or an attempt was made to route the request from a
DRDA client to a DRDA target database. The request must be routed
directly from the client to the node on which the target database is
running.

User Response: Uncatalog the database at the client machine and then
catalog the database specifying the node on which the database actually
resides. Ensure that the node is also cataloged.
Same result can be achieved using db2 ? sql1334 from DB2 command window.

Now - entirely different question would be - whether explanation given
was helpful in resolving this issue. Only you can answer that. My guess
is that you figured out your cataloguing issues all by yourself.

PS. I switched back to "hidding my e-mail" - since you already got my
e-mail address. I am getting enough SPAM and junk e-mail already.

Jan M. Nelken