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 30 7368
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)
aka wrote: 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
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)
aka wrote: 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
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.
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.
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)
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)
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)
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)
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
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
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! =-----
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! =-----
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
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
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! =-----
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! =-----
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 ;-)
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 ;-)
> 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?
> 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?
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?
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?
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 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" <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.
"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.
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.
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.
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Marc |
last post by:
Hello,
Newbie here..... Searching and working this for a week now.
We too are having the same problems.
Using MySql 4.0.14 and there are "no problems" at all.
|
by: Claus van de Vlierd |
last post by:
Hello ,
a) in the following script (under RedHat AS3 with PHP 4.3.2 ) I make
a "DB::connect" to an existing "mysql" database named
"docu_files_of_cvdv" .
The strange thing is : it works --...
|
by: Mike |
last post by:
Related to another topic I just posted, I wanted to discuss ways to optimize
the validation of very large (>100MB) XML documents.
First, I have no idea if something like this already exists; it...
|
by: D. Dante Lorenso |
last post by:
I have a simple table that I'd like to query to pull
out a heirarchy from a tree relationship. What is the
best way to do this without a 'CONNECT BY' clause like
Oracle has?
Example
mytable...
|
by: aka |
last post by:
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...
|
by: Marcus |
last post by:
I have a function that simply returns TRUE if it can connect to a
particular Sql Server 2005 express, or FALSE if it cannot. I am getting
some strange error codes returned when the computer that...
|
by: jordo |
last post by:
I have an asp.Net app that connects to the WSS 2.0 list web service.
I'm having issues with IIS and .Net configurations and hope that
someone can help me. My ideal configuration is:
asp.net:...
|
by: daft |
last post by:
Hi guys
Following on from an issue a couple of years back, now archived:
http://www.thescripts.com/forum/thread208561-tabledef.connect.html
I'm having the same problems.
I can update the...
|
by: Flash08 |
last post by:
Hi all,
I'm having some trouble with connecting to SQL server instance lately
without adding a port number. I used to be able to always connect to
instance without having to input...
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |