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

Hi,

I am trying to setup DB2 in a multi-partition setup. But due to some
local configuration problems, We are not in a position to use an NFS.

Is there some way to install the multi-partition setup without having to
use the NFS?

--Sundeep Narravula.

Nov 12 '05 #4

Nov 12 '05 #5

aka

Hi Blair,

thanks for your answer...I'm DBA in a big health isurance company and it
takes me about a week or so to get a new fixpack or db2 instance
installed...
we have DB2/390 v6.1.2 on MVS Host
DB2/SUN v7.2.9 on SunFire Cluster, there is also DB2 Connect EE and SNA is
installed
and we use Solaris and AIX as DB2 Servers from v6.1 to v7.2.9 and also EEE
v7.2.9 on 8 AIX SP2 nodes for data warehouse...
now I have my first v8.1 FP 5 instance on AIX maschine and try to get a
connection to the Host System...

you say SNA/APPC support is limited, so i will first try to get the setup
for v8.1 FP5 on the connect instance
it will then be a second task to follow your tip to exchange APPC with
CPIC...I will let you know

in the above configuration we make connections to MVS host via Solaris
gateway (with DB2 connect EE) and I don't know how long it takes to upgrade
the host system with tcp/ip

in the meantime I read the manuals and wonder about the SQL1334N message I
get, when I try to connect in the same environment to host from v8.1

I thougt I need a DB2 Connect as gateway to access Host DB2 but from the SQL
message it is said that DRDA databases can only connect directly, so another
question is: can I connect to Host system without using the connect gateway?
Thanks
aka

SNA / APPC support is extremely limited inb Version 8.

Recommendations:

1. drop SNA and try TCP/IP only
or
2. upgrade to the latest fixpak of DB2 v8, and try CPIC support (v8
equivalent of APPC / SNA)

Nov 12 '05 #6

aka

SNA / APPC support is extremely limited inb Version 8.

Recommendations:

1. drop SNA and try TCP/IP only
or
2. upgrade to the latest fixpak of DB2 v8, and try CPIC support (v8
equivalent of APPC / SNA)

Nov 12 '05 #7

Larry

I think the explanation for error msg SQL1334N isn't exactly clear, but
take my word for it, if you want to connect to a DB2 V6 database on
OS/390 ... you need either a DRDA gateway (DB2 COnnect EE), a DRDA
client (DB2 Connect Personal Edition), or the new type 4 JDBC driver in
DB2 Connect V8 (which will allow direct connections from a type 4 JDBC
client, but still requires a DB2 Connect license) ... and I'm not
entirely sure whether the type 4 JDBC driver in V8 will support either
DB2/390 V6 or SNA.

The description of your environment is not exactly clear to me. Where do
you receive this error msg? On the client? Gateway Server? What exactly
is the client configuration, and the gateway server configuration?

My advice is get off SNA asap.

Larry Edelstein

aka wrote:

Hi Blair,

thanks for your answer...I'm DBA in a big health isurance company and it
takes me about a week or so to get a new fixpack or db2 instance
installed...
we have DB2/390 v6.1.2 on MVS Host
DB2/SUN v7.2.9 on SunFire Cluster, there is also DB2 Connect EE and SNA is
installed
and we use Solaris and AIX as DB2 Servers from v6.1 to v7.2.9 and also EEE
v7.2.9 on 8 AIX SP2 nodes for data warehouse...
now I have my first v8.1 FP 5 instance on AIX maschine and try to get a
connection to the Host System...

you say SNA/APPC support is limited, so i will first try to get the setup
for v8.1 FP5 on the connect instance
it will then be a second task to follow your tip to exchange APPC with
CPIC...I will let you know

in the above configuration we make connections to MVS host via Solaris
gateway (with DB2 connect EE) and I don't know how long it takes to upgrade
the host system with tcp/ip

in the meantime I read the manuals and wonder about the SQL1334N message I
get, when I try to connect in the same environment to host from v8.1

I thougt I need a DB2 Connect as gateway to access Host DB2 but from the SQL
message it is said that DRDA databases can only connect directly, so another
question is: can I connect to Host system without using the connect gateway?
Thanks
aka

SNA / APPC support is extremely limited inb Version 8.

Recommendations:

1. drop SNA and try TCP/IP only
or
2. upgrade to the latest fixpak of DB2 v8, and try CPIC support (v8
equivalent of APPC / SNA)

Nov 12 '05 #8

Larry

Hi Blair,

thanks for your answer...I'm DBA in a big health isurance company and it
takes me about a week or so to get a new fixpack or db2 instance
installed...
we have DB2/390 v6.1.2 on MVS Host
DB2/SUN v7.2.9 on SunFire Cluster, there is also DB2 Connect EE and SNA is
installed
and we use Solaris and AIX as DB2 Servers from v6.1 to v7.2.9 and also EEE
v7.2.9 on 8 AIX SP2 nodes for data warehouse...
now I have my first v8.1 FP 5 instance on AIX maschine and try to get a
connection to the Host System...

you say SNA/APPC support is limited, so i will first try to get the setup
for v8.1 FP5 on the connect instance
it will then be a second task to follow your tip to exchange APPC with
CPIC...I will let you know

in the above configuration we make connections to MVS host via Solaris
gateway (with DB2 connect EE) and I don't know how long it takes to upgrade
the host system with tcp/ip

in the meantime I read the manuals and wonder about the SQL1334N message I
get, when I try to connect in the same environment to host from v8.1

I thougt I need a DB2 Connect as gateway to access Host DB2 but from the SQL
message it is said that DRDA databases can only connect directly, so another
question is: can I connect to Host system without using the connect gateway?
Thanks
aka

SNA / APPC support is extremely limited inb Version 8.

Recommendations:

1. drop SNA and try TCP/IP only
or
2. upgrade to the latest fixpak of DB2 v8, and try CPIC support (v8
equivalent of APPC / SNA)

Nov 12 '05 #9

aka

Larry thank you for answering

I think the explanation for error msg SQL1334N isn't exactly clear, but
take my word for it, if you want to connect to a DB2 V6 database on
OS/390 ... you need either a DRDA gateway (DB2 COnnect EE), a DRDA
client (DB2 Connect Personal Edition), or the new type 4 JDBC driver in
DB2 Connect V8 (which will allow direct connections from a type 4 JDBC
client, but still requires a DB2 Connect license) ... and I'm not
entirely sure whether the type 4 JDBC driver in V8 will support either
DB2/390 V6 or SNA.
yes that's my option also. I have a piece of java code to test the type 4
connect:

/*+----------------------------------+*/
/*! initialize JDBC/ODBC environment !*/
/*+----------------------------------+*/
try
{
// choose driver...
if (in_host_name.length() > 0 && in_port_number.length() > 0)
{ // use NET driver
db2_class = "COM.ibm.db2.jdbc.net.DB2Driver";
db2_url = "jdbc:db2://" + in_host_name + ":" + in_port_number + "/"
+ in_source_db_name;
}
else
{ // use APPlication driver
db2_class = "COM.ibm.db2.jdbc.app.DB2Driver";
db2_url = "jdbc:db2:" + in_source_db_name;
}
Driver myDBDriver = (Driver)Class.forName (db2_class).newInstance();

// get db connection
System.out.println ("DB2_Class=" + db2_class);
System.out.println ("Connect_URL=" + db2_url);
if (in_usr_name.equals("")) db_conn = DriverManager.getConnection
(db2_url, "", "");
else db_conn = DriverManager.getConnection (db2_url, in_usr_name,
in_usr_pw);
The description of your environment is not exactly clear to me. Where do
you receive this error msg? On the client? Gateway Server? What exactly
is the client configuration, and the gateway server configuration?
The sql message is kind of misleading, eh? Ok I try to describe the
environment more exactly...

(I) Host with MVS and DB2 v6.1.2
Subsystem called DB2T
I call this a server

(II) Solaris machine with DB2 Connect EE v7.2.9
Instance: GWMVS
Host DB cataloged at APPN node as DB2T
I call this gateway

(III) AIX machines with DB2 EEE v7.2.9
Instance: DB2TEST
cataloged GWMVS as TCPIP node
cataloged Host DB at TCPIP node GWMVS as DB2T
this is DB2 server but acts as client against host DB2

In this environment the connection to DB2T from machine (III), instance
DB2TEST works just fine. Now I got another instance V8TEST installed on
machine (III) with DB2 v8.1.5. With the same cataloging I get SQL1334N when
connecting to DB2T. I thought that DB2 v8 already has DRDA included, so the
only thing that is missing would be perhaps SNA...or that the gateway isn't
needed anymore when the host gets TCP/IP? This is primarily not a question
of licenses.
My advice is get off SNA asap.
yep. I told that since two years or so...
Larry Edelstein

Regards
aka

Nov 12 '05 #10

aka

Larry thank you for answering

I think the explanation for error msg SQL1334N isn't exactly clear, but
take my word for it, if you want to connect to a DB2 V6 database on
OS/390 ... you need either a DRDA gateway (DB2 COnnect EE), a DRDA
client (DB2 Connect Personal Edition), or the new type 4 JDBC driver in
DB2 Connect V8 (which will allow direct connections from a type 4 JDBC
client, but still requires a DB2 Connect license) ... and I'm not
entirely sure whether the type 4 JDBC driver in V8 will support either
DB2/390 V6 or SNA.
yes that's my option also. I have a piece of java code to test the type 4
connect:

/*+----------------------------------+*/
/*! initialize JDBC/ODBC environment !*/
/*+----------------------------------+*/
try
{
// choose driver...
if (in_host_name.length() > 0 && in_port_number.length() > 0)
{ // use NET driver
db2_class = "COM.ibm.db2.jdbc.net.DB2Driver";
db2_url = "jdbc:db2://" + in_host_name + ":" + in_port_number + "/"
+ in_source_db_name;
}
else
{ // use APPlication driver
db2_class = "COM.ibm.db2.jdbc.app.DB2Driver";
db2_url = "jdbc:db2:" + in_source_db_name;
}
Driver myDBDriver = (Driver)Class.forName (db2_class).newInstance();

// get db connection
System.out.println ("DB2_Class=" + db2_class);
System.out.println ("Connect_URL=" + db2_url);
if (in_usr_name.equals("")) db_conn = DriverManager.getConnection
(db2_url, "", "");
else db_conn = DriverManager.getConnection (db2_url, in_usr_name,
in_usr_pw);
The description of your environment is not exactly clear to me. Where do
you receive this error msg? On the client? Gateway Server? What exactly
is the client configuration, and the gateway server configuration?
The sql message is kind of misleading, eh? Ok I try to describe the
environment more exactly...

(I) Host with MVS and DB2 v6.1.2
Subsystem called DB2T
I call this a server

(II) Solaris machine with DB2 Connect EE v7.2.9
Instance: GWMVS
Host DB cataloged at APPN node as DB2T
I call this gateway

(III) AIX machines with DB2 EEE v7.2.9
Instance: DB2TEST
cataloged GWMVS as TCPIP node
cataloged Host DB at TCPIP node GWMVS as DB2T
this is DB2 server but acts as client against host DB2

In this environment the connection to DB2T from machine (III), instance
DB2TEST works just fine. Now I got another instance V8TEST installed on
machine (III) with DB2 v8.1.5. With the same cataloging I get SQL1334N when
connecting to DB2T. I thought that DB2 v8 already has DRDA included, so the
only thing that is missing would be perhaps SNA...or that the gateway isn't
needed anymore when the host gets TCP/IP? This is primarily not a question
of licenses.
My advice is get off SNA asap.
yep. I told that since two years or so...
Larry Edelstein

Regards
aka

Nov 12 '05 #11

Ian

Sundeep Narravula wrote:

Hi,

I am trying to setup DB2 in a multi-partition setup. But due to some
local configuration problems, We are not in a position to use an NFS.

Is there some way to install the multi-partition setup without having to
use the NFS?

You can, but this requires a clustered file system (this is usually a part
of a HA cluster, like HACMP or Sun Cluster). This is much more
challenging than NFS, as it has software and hardware dependencies.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Nov 12 '05 #12

Ian

Sundeep Narravula wrote:

Hi,

I am trying to setup DB2 in a multi-partition setup. But due to some
local configuration problems, We are not in a position to use an NFS.

Is there some way to install the multi-partition setup without having to
use the NFS?

Nov 12 '05 #13

Larry

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

aka wrote:

Larry thank you for answering

I think the explanation for error msg SQL1334N isn't exactly clear, but
take my word for it, if you want to connect to a DB2 V6 database on
OS/390 ... you need either a DRDA gateway (DB2 COnnect EE), a DRDA
client (DB2 Connect Personal Edition), or the new type 4 JDBC driver in
DB2 Connect V8 (which will allow direct connections from a type 4 JDBC
client, but still requires a DB2 Connect license) ... and I'm not
entirely sure whether the type 4 JDBC driver in V8 will support either
DB2/390 V6 or SNA.

yes that's my option also. I have a piece of java code to test the type 4
connect:

/*+----------------------------------+*/
/*! initialize JDBC/ODBC environment !*/
/*+----------------------------------+*/
try
{
// choose driver...
if (in_host_name.length() > 0 && in_port_number.length() > 0)
{ // use NET driver
db2_class = "COM.ibm.db2.jdbc.net.DB2Driver";
db2_url = "jdbc:db2://" + in_host_name + ":" + in_port_number + "/"
+ in_source_db_name;
}
else
{ // use APPlication driver
db2_class = "COM.ibm.db2.jdbc.app.DB2Driver";
db2_url = "jdbc:db2:" + in_source_db_name;
}
Driver myDBDriver = (Driver)Class.forName (db2_class).newInstance();

// get db connection
System.out.println ("DB2_Class=" + db2_class);
System.out.println ("Connect_URL=" + db2_url);
if (in_usr_name.equals("")) db_conn = DriverManager.getConnection
(db2_url, "", "");
else db_conn = DriverManager.getConnection (db2_url, in_usr_name,
in_usr_pw);

The description of your environment is not exactly clear to me. Where do
you receive this error msg? On the client? Gateway Server? What exactly
is the client configuration, and the gateway server configuration?

The sql message is kind of misleading, eh? Ok I try to describe the
environment more exactly...

(I) Host with MVS and DB2 v6.1.2
Subsystem called DB2T
I call this a server

(II) Solaris machine with DB2 Connect EE v7.2.9
Instance: GWMVS
Host DB cataloged at APPN node as DB2T
I call this gateway

(III) AIX machines with DB2 EEE v7.2.9
Instance: DB2TEST
cataloged GWMVS as TCPIP node
cataloged Host DB at TCPIP node GWMVS as DB2T
this is DB2 server but acts as client against host DB2

In this environment the connection to DB2T from machine (III), instance
DB2TEST works just fine. Now I got another instance V8TEST installed on
machine (III) with DB2 v8.1.5. With the same cataloging I get SQL1334N when
connecting to DB2T. I thought that DB2 v8 already has DRDA included, so the
only thing that is missing would be perhaps SNA...or that the gateway isn't
needed anymore when the host gets TCP/IP? This is primarily not a question
of licenses.

My advice is get off SNA asap.

yep. I told that since two years or so...

Larry Edelstein

Regards
aka

Nov 12 '05 #14

Larry

Larry thank you for answering

I think the explanation for error msg SQL1334N isn't exactly clear, but
take my word for it, if you want to connect to a DB2 V6 database on
OS/390 ... you need either a DRDA gateway (DB2 COnnect EE), a DRDA
client (DB2 Connect Personal Edition), or the new type 4 JDBC driver in
DB2 Connect V8 (which will allow direct connections from a type 4 JDBC
client, but still requires a DB2 Connect license) ... and I'm not
entirely sure whether the type 4 JDBC driver in V8 will support either
DB2/390 V6 or SNA.

yes that's my option also. I have a piece of java code to test the type 4
connect:

/*+----------------------------------+*/
/*! initialize JDBC/ODBC environment !*/
/*+----------------------------------+*/
try
{
// choose driver...
if (in_host_name.length() > 0 && in_port_number.length() > 0)
{ // use NET driver
db2_class = "COM.ibm.db2.jdbc.net.DB2Driver";
db2_url = "jdbc:db2://" + in_host_name + ":" + in_port_number + "/"
+ in_source_db_name;
}
else
{ // use APPlication driver
db2_class = "COM.ibm.db2.jdbc.app.DB2Driver";
db2_url = "jdbc:db2:" + in_source_db_name;
}
Driver myDBDriver = (Driver)Class.forName (db2_class).newInstance();

// get db connection
System.out.println ("DB2_Class=" + db2_class);
System.out.println ("Connect_URL=" + db2_url);
if (in_usr_name.equals("")) db_conn = DriverManager.getConnection
(db2_url, "", "");
else db_conn = DriverManager.getConnection (db2_url, in_usr_name,
in_usr_pw);

The description of your environment is not exactly clear to me. Where do
you receive this error msg? On the client? Gateway Server? What exactly
is the client configuration, and the gateway server configuration?

The sql message is kind of misleading, eh? Ok I try to describe the
environment more exactly...

(I) Host with MVS and DB2 v6.1.2
Subsystem called DB2T
I call this a server

(II) Solaris machine with DB2 Connect EE v7.2.9
Instance: GWMVS
Host DB cataloged at APPN node as DB2T
I call this gateway

(III) AIX machines with DB2 EEE v7.2.9
Instance: DB2TEST
cataloged GWMVS as TCPIP node
cataloged Host DB at TCPIP node GWMVS as DB2T
this is DB2 server but acts as client against host DB2

In this environment the connection to DB2T from machine (III), instance
DB2TEST works just fine. Now I got another instance V8TEST installed on
machine (III) with DB2 v8.1.5. With the same cataloging I get SQL1334N when
connecting to DB2T. I thought that DB2 v8 already has DRDA included, so the
only thing that is missing would be perhaps SNA...or that the gateway isn't
needed anymore when the host gets TCP/IP? This is primarily not a question
of licenses.

My advice is get off SNA asap.

yep. I told that since two years or so...

Larry Edelstein

Regards
aka

Nov 12 '05 #15

Hi,

Basically the problem I have is that, In our cluster we do not have open
super access to the NFS. So I am not able to execute the "db2icrt" to
create an instance.

Is there a way to create an Instance without super-user access on the
NFS?

--Sundeep.

On Sat, 24 Apr 2004, Ian wrote:

Sundeep Narravula wrote:
Hi,

I am trying to setup DB2 in a multi-partition setup. But due to some
local configuration problems, We are not in a position to use an NFS.

Is there some way to install the multi-partition setup without having to
use the NFS?

You can, but this requires a clustered file system (this is usually a part
of a HA cluster, like HACMP or Sun Cluster). This is much more
challenging than NFS, as it has software and hardware dependencies.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Nov 12 '05 #16

Sundeep Narravula wrote:
Hi,

I am trying to setup DB2 in a multi-partition setup. But due to some
local configuration problems, We are not in a position to use an NFS.

Is there some way to install the multi-partition setup without having to
use the NFS?

You can, but this requires a clustered file system (this is usually a part
of a HA cluster, like HACMP or Sun Cluster). This is much more
challenging than NFS, as it has software and hardware dependencies.

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

Nov 12 '05 #17

Darin McBride

Sundeep Narravula wrote:

Hi,

Basically the problem I have is that, In our cluster we do not have open
super access to the NFS. So I am not able to execute the "db2icrt" to
create an instance.

Is there a way to create an Instance without super-user access on the
NFS?

No, and even if there were, you would still need privileged
(super-user) access via NFS for the instance to run.

From what I've read in a number of places, there are some
recommendations for a cluster that may alleviate some of this headache
(promptly replacing it with other headaches).

1. Your cluster should have a private network. For it to be useful,
one or more of these machines must also be on the "public" network
(which itself may be a private intranet), possibly all machines. Each
machine on the public network would thus have two (or more) network
cards - one (or more) for the public network, and one for the private
cluster network.

2. You only need to enable non-root-squash on your NFS exports for this
private network, not for the world at large.

3. In fact, these NFS cross-mounts should probably be on a separate
export line from the rest of your NFS sharing. That is, you explicitly
share /database, rather than putting your instance in /home/database
and sharing /home.

4. Even more ideally is if you have one (or more) machine(s) in your
private cluster network which is not on your public network, use that
machine as your NFS server for the instance. This does not mean that
another machine cannot serve NFS shares for other things, only that you
end up with a share that can only be accessed by machines that
physically have access to a private network.

All of this is likely to be an even harder sell to your IT department.
But it may just convince them to open up the root access on NFS for you
since it's easier ;-)

Nov 12 '05 #18

Darin McBride

Sundeep Narravula wrote:

Hi,

Basically the problem I have is that, In our cluster we do not have open
super access to the NFS. So I am not able to execute the "db2icrt" to
create an instance.

Is there a way to create an Instance without super-user access on the
NFS?

Nov 12 '05 #19

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?

Nov 12 '05 #20

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

Nov 12 '05 #21

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:db2jcc_license_cisuz.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.net:2336/TEST_DBT1","user","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?

Nov 12 '05 #22

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?

Nov 12 '05 #23

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

Nov 12 '05 #24

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

Nov 12 '05 #25

"Jan M. Nelken" <jn*****@ca.ibm.com> wrote in message news:<c7**********@hanover.torolab.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.

Nov 12 '05 #26

"Jan M. Nelken" <jn*****@ca.ibm.com> wrote in message news:<c7**********@hanover.torolab.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:

Nov 12 '05 #27

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.com> schrieb im Newsbeitrag
news:9d*************************@posting.google.co m...

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

news:<c7**********@hanover.torolab.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.

Nov 12 '05 #28

aka

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

news:<c7**********@hanover.torolab.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.

Nov 12 '05 #29

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

Nov 12 '05 #30