NT4 -> ODBC -> OS/390

NT4 -> ODBC -> OS/390

Post by robe » Sun, 28 Apr 2002 00:54:53



i've been trying alternatives to Command Center,
Control Center.  currently Advance Query Tool.  like
it a lot, but it's crashed a few times with the
dreaded 'memory cannot be read  0x0000000' message.
neither Dr. Watson log nor AQT's debug log showed
anything.  

now, when DB2 was installed on this machine, it was
client and server.  i was told not to call out ODBC
on the OS/390 datasources in Client Configuration
Assistant. CC/CC don't need them, i guess.  AQT does,
of course, so i did (* boy).

DB2Connect is operating on a server on our net, but
while i've been told that my access is through same,
i see no evidence of this connection on my machine.
is DB2Connect material to the NT -> ODBC -> OS/390
communication path?  how to determine this?

it would seem that the ODBC driver is misbehaving.
Control Panel says it is 7.00.01.41.  but, of
course, there is no db2cli.dll on the machine; so i can't
tell whether i have the current version or not.  the
ibm site doesn't seem to have any way of telling
me, and, of course, db2 just says it is version 7.

we have 7.1 fixpacks through 5, but i've no idea which,
if any, have been installed to this machine.

so:  is it known that NT -> ODBC -> OS/390 doesn't
work?  if it does, what incantations must be muttered
to get it to work; without crashing, that is?

toodles,
robert

 
 
 

NT4 -> ODBC -> OS/390

Post by Larry Edelstei » Sun, 28 Apr 2002 06:59:21


An ODBC connection to DB2 on the mainframe requires a middleware product
like DB2 Connect. You cannot simply connect from any ODBC driver. If you
have DB2 Connect operating on a server on your network, you must have a
capable DB2 client on the machine on which you have the ODBC driver. You
must then make the proper catalog entries on the client so that access
to the db alias name that you connect to is directed to the DB2/390 db
via the DB2 Connect server. This can be done manually (see the DB2
Connect documentation) or via the CCA.

Larry Edelstein


> i've been trying alternatives to Command Center,
> Control Center.  currently Advance Query Tool.  like
> it a lot, but it's crashed a few times with the
> dreaded 'memory cannot be read  0x0000000' message.
> neither Dr. Watson log nor AQT's debug log showed
> anything.

> now, when DB2 was installed on this machine, it was
> client and server.  i was told not to call out ODBC
> on the OS/390 datasources in Client Configuration
> Assistant. CC/CC don't need them, i guess.  AQT does,
> of course, so i did (* boy).

> DB2Connect is operating on a server on our net, but
> while i've been told that my access is through same,
> i see no evidence of this connection on my machine.
> is DB2Connect material to the NT -> ODBC -> OS/390
> communication path?  how to determine this?

> it would seem that the ODBC driver is misbehaving.
> Control Panel says it is 7.00.01.41.  but, of
> course, there is no db2cli.dll on the machine; so i can't
> tell whether i have the current version or not.  the
> ibm site doesn't seem to have any way of telling
> me, and, of course, db2 just says it is version 7.

> we have 7.1 fixpacks through 5, but i've no idea which,
> if any, have been installed to this machine.

> so:  is it known that NT -> ODBC -> OS/390 doesn't
> work?  if it does, what incantations must be muttered
> to get it to work; without crashing, that is?

> toodles,
> robert


 
 
 

NT4 -> ODBC -> OS/390

Post by Mark Yudki » Mon, 29 Apr 2002 16:30:13


From experience I can say that ODBC from NT4 to OS/390 works just fine (when
correctly set up). You need DB2 Connect (e.g. on a server) and the
corresponding DB2 Runtime client on the NT4. You sert up the host database
on the Connect server and catalogue the Connect database on the client use
the CCA (i.e. ignore the  "I was told not to..."). Before trying to conenct
with the client, verify that you have full function connectivity on the
server.

You can tell that Connect "is relevant" from the fact that you catalogue the
Connect database on the client.

I am not aware of any ODBC problems. (However, the IBM ADO driver is badly
broken, so you should avoid using it).


Quote:> i've been trying alternatives to Command Center,
> Control Center.  currently Advance Query Tool.  like
> it a lot, but it's crashed a few times with the
> dreaded 'memory cannot be read  0x0000000' message.
> neither Dr. Watson log nor AQT's debug log showed
> anything.

> now, when DB2 was installed on this machine, it was
> client and server.  i was told not to call out ODBC
> on the OS/390 datasources in Client Configuration
> Assistant. CC/CC don't need them, i guess.  AQT does,
> of course, so i did (* boy).

> DB2Connect is operating on a server on our net, but
> while i've been told that my access is through same,
> i see no evidence of this connection on my machine.
> is DB2Connect material to the NT -> ODBC -> OS/390
> communication path?  how to determine this?

> it would seem that the ODBC driver is misbehaving.
> Control Panel says it is 7.00.01.41.  but, of
> course, there is no db2cli.dll on the machine; so i can't
> tell whether i have the current version or not.  the
> ibm site doesn't seem to have any way of telling
> me, and, of course, db2 just says it is version 7.

> we have 7.1 fixpacks through 5, but i've no idea which,
> if any, have been installed to this machine.

> so:  is it known that NT -> ODBC -> OS/390 doesn't
> work?  if it does, what incantations must be muttered
> to get it to work; without crashing, that is?

> toodles,
> robert

 
 
 

NT4 -> ODBC -> OS/390

Post by robe » Mon, 29 Apr 2002 23:20:43



> From experience I can say that ODBC from NT4 to OS/390 works just fine (when
> correctly set up). You need DB2 Connect (e.g. on a server) and the
> corresponding DB2 Runtime client on the NT4. You sert up the host database
> on the Connect server and catalogue the Connect database on the client use
> the CCA (i.e. ignore the  "I was told not to..."). Before trying to conenct
> with the client, verify that you have full function connectivity on the
> server.

> You can tell that Connect "is relevant" from the fact that you catalogue the
> Connect database on the client.

> I am not aware of any ODBC problems. (However, the IBM ADO driver is badly
> broken, so you should avoid using it).

in general, works fine.  i started by trying to find the information
needed to confirm which ODBC driver was in use, and whether a later
version would work better.  i have found that 7.1 fp3 is installed, but
fp5 is not.  my dim recollection of the fp install was that everybody
had to be at the same level, or nothing worked, so my understanding
is that i can't install fp5 to get later ODBC, if that were a
good idea.

as to the specific error i am getting:  clicking <double-clicking>
on either a folder in the schema tree or table icon leads to the
hard crash.  looks like a rogue pointer into the IVT (at least that's
what's in low memory in the DOS versions of windoze).

this has never happened using CC/CC when ODBC hadn't been set in CCA.
post hoc, ergo propter hoc:  ODBC is misbehaving.

toodles,
robert

 
 
 

NT4 -> ODBC -> OS/390

Post by Mark Yudki » Wed, 01 May 2002 14:53:40


IIRC, your dim recollection is not accurate. You may mix fixpaks, and even
versions (with some restrictions).

You may need to adjust the PATCH1 / PATCH2 options for correct function.

Quote:> as to the specific error i am getting:  clicking <double-clicking>
> on either a folder in the schema tree or table icon leads to the hard

crash.

Since this function is not part of the base ODBC function, you may well have
a different problem. ODBC is nothing but a driver, if passed rubbish, it
will crash, but it isn't the problem. Sometimes the PATCHn vars can help, if
not correctly set they can definitely lead to major problems, including
crashes!



Quote:> > From experience I can say that ODBC from NT4 to OS/390 works just fine
(when
> > correctly set up). You need DB2 Connect (e.g. on a server) and the
> > corresponding DB2 Runtime client on the NT4. You sert up the host
database
> > on the Connect server and catalogue the Connect database on the client
use
> > the CCA (i.e. ignore the  "I was told not to..."). Before trying to
conenct
> > with the client, verify that you have full function connectivity on the
> > server.

> > You can tell that Connect "is relevant" from the fact that you catalogue
the
> > Connect database on the client.

> > I am not aware of any ODBC problems. (However, the IBM ADO driver is
badly
> > broken, so you should avoid using it).

> in general, works fine.  i started by trying to find the information
> needed to confirm which ODBC driver was in use, and whether a later
> version would work better.  i have found that 7.1 fp3 is installed, but
> fp5 is not.  my dim recollection of the fp install was that everybody
> had to be at the same level, or nothing worked, so my understanding
> is that i can't install fp5 to get later ODBC, if that were a
> good idea.

> as to the specific error i am getting:  clicking <double-clicking>
> on either a folder in the schema tree or table icon leads to the
> hard crash.  looks like a rogue pointer into the IVT (at least that's
> what's in low memory in the DOS versions of windoze).

> this has never happened using CC/CC when ODBC hadn't been set in CCA.
> post hoc, ergo propter hoc:  ODBC is misbehaving.

> toodles,
> robert

 
 
 

NT4 -> ODBC -> OS/390

Post by robe » Tue, 07 May 2002 21:29:09


i kept track of my use last week.  about half and half UDB/DB2-390.
total time, about one hour.  4 crashes, all 390, all clicking either
a schema or table icon.  no problems with UDB (on NT, either local
or remote server).  no crashes through CC/CC.

UDB-7.1 fp3  DB2 - 6.1.1

crashes only ODBC to DB2/390.  there IS something wrong with the
ODBC.  would somebody at ibm please look at this; it's not going
to go away by denying it.  you'll just*off your customers that
little bit more.

toodles,
robert


> IIRC, your dim recollection is not accurate. You may mix fixpaks, and even
> versions (with some restrictions).

> You may need to adjust the PATCH1 / PATCH2 options for correct function.

> > as to the specific error i am getting:  clicking <double-clicking>
> > on either a folder in the schema tree or table icon leads to the hard
> crash.

> Since this function is not part of the base ODBC function, you may well have
> a different problem. ODBC is nothing but a driver, if passed rubbish, it
> will crash, but it isn't the problem. Sometimes the PATCHn vars can help, if
> not correctly set they can definitely lead to major problems, including
> crashes!





> > > From experience I can say that ODBC from NT4 to OS/390 works just fine
>  (when
> > > correctly set up). You need DB2 Connect (e.g. on a server) and the
> > > corresponding DB2 Runtime client on the NT4. You sert up the host
>  database
> > > on the Connect server and catalogue the Connect database on the client
>  use
> > > the CCA (i.e. ignore the  "I was told not to..."). Before trying to
>  conenct
> > > with the client, verify that you have full function connectivity on the
> > > server.

> > > You can tell that Connect "is relevant" from the fact that you catalogue
>  the
> > > Connect database on the client.

> > > I am not aware of any ODBC problems. (However, the IBM ADO driver is
>  badly
> > > broken, so you should avoid using it).

> > in general, works fine.  i started by trying to find the information
> > needed to confirm which ODBC driver was in use, and whether a later
> > version would work better.  i have found that 7.1 fp3 is installed, but
> > fp5 is not.  my dim recollection of the fp install was that everybody
> > had to be at the same level, or nothing worked, so my understanding
> > is that i can't install fp5 to get later ODBC, if that were a
> > good idea.

> > as to the specific error i am getting:  clicking <double-clicking>
> > on either a folder in the schema tree or table icon leads to the
> > hard crash.  looks like a rogue pointer into the IVT (at least that's
> > what's in low memory in the DOS versions of windoze).

> > this has never happened using CC/CC when ODBC hadn't been set in CCA.
> > post hoc, ergo propter hoc:  ODBC is misbehaving.

> > toodles,
> > robert

 
 
 

NT4 -> ODBC -> OS/390

Post by blair kenneth adamach » Tue, 07 May 2002 23:54:19


This newsgroup is unmoderated and not sponsored by IBM, so this is not the best place to report bugs. If your
company has DB2 on OS/390, you almost certainly have a Service Contract with IBM which allows you to report
defects officially to IBM. Check out these web sites for help:

http://www.veryComputer.com/

http://www.veryComputer.com/


> i kept track of my use last week.  about half and half UDB/DB2-390.
> total time, about one hour.  4 crashes, all 390, all clicking either
> a schema or table icon.  no problems with UDB (on NT, either local
> or remote server).  no crashes through CC/CC.

> UDB-7.1 fp3  DB2 - 6.1.1

> crashes only ODBC to DB2/390.  there IS something wrong with the
> ODBC.  would somebody at ibm please look at this; it's not going
> to go away by denying it.  you'll just*off your customers that
> little bit more.

> toodles,
> robert


> > IIRC, your dim recollection is not accurate. You may mix fixpaks, and even
> > versions (with some restrictions).

> > You may need to adjust the PATCH1 / PATCH2 options for correct function.

> > > as to the specific error i am getting:  clicking <double-clicking>
> > > on either a folder in the schema tree or table icon leads to the hard
> > crash.

> > Since this function is not part of the base ODBC function, you may well have
> > a different problem. ODBC is nothing but a driver, if passed rubbish, it
> > will crash, but it isn't the problem. Sometimes the PATCHn vars can help, if
> > not correctly set they can definitely lead to major problems, including
> > crashes!





> > > > From experience I can say that ODBC from NT4 to OS/390 works just fine
> >  (when
> > > > correctly set up). You need DB2 Connect (e.g. on a server) and the
> > > > corresponding DB2 Runtime client on the NT4. You sert up the host
> >  database
> > > > on the Connect server and catalogue the Connect database on the client
> >  use
> > > > the CCA (i.e. ignore the  "I was told not to..."). Before trying to
> >  conenct
> > > > with the client, verify that you have full function connectivity on the
> > > > server.

> > > > You can tell that Connect "is relevant" from the fact that you catalogue
> >  the
> > > > Connect database on the client.

> > > > I am not aware of any ODBC problems. (However, the IBM ADO driver is
> >  badly
> > > > broken, so you should avoid using it).

> > > in general, works fine.  i started by trying to find the information
> > > needed to confirm which ODBC driver was in use, and whether a later
> > > version would work better.  i have found that 7.1 fp3 is installed, but
> > > fp5 is not.  my dim recollection of the fp install was that everybody
> > > had to be at the same level, or nothing worked, so my understanding
> > > is that i can't install fp5 to get later ODBC, if that were a
> > > good idea.

> > > as to the specific error i am getting:  clicking <double-clicking>
> > > on either a folder in the schema tree or table icon leads to the
> > > hard crash.  looks like a rogue pointer into the IVT (at least that's
> > > what's in low memory in the DOS versions of windoze).

> > > this has never happened using CC/CC when ODBC hadn't been set in CCA.
> > > post hoc, ergo propter hoc:  ODBC is misbehaving.

> > > toodles,
> > > robert

 
 
 

1. OLEDB or ODBC => DB2 (OS/390)

    Hi

    I would want to know if someone of you know a good and cheap driver(s)
that works
    against DB2 databases located on OS/390, MVS?

    I have tested
    HIT => Worked OK but problem getting Stored Procedures to Work.
    DB2Cli (DB2Connect) => OK, but need alot of runtime files if you want to
distribute your application with DB2Cli driver.
                IBM recommends to send the whole DB2Connect client (100MB)
with your application,
                imagine if you have 20.000 users.!!
    NEON => Did not work at all.

    I would like to know if you know other drivers that works with
DB2/OS/390/MVS?

    It should be cheap, not cost the shirt each year if we need to
distribute our 5MB sized application to 20.000 users
    and it also should be easy to include with our 5MB sized Visualbasic
application without including > 10MB of data access files.

    Regards, Jim

2. Currency data type with MSFLexGrid

3. Oracle ->DB2 on Amdahl using OS/390

4. joining databases

5. VB6 -> OS/390 DB/2

6. Problems by setting DB-Connect-Timeout with "SQLSetConnectAttr"

7. DB2CLI->OS/390 CodePage errors

8. Confused about security on WebServer Apps

9. Delphi>>>>>>>

10. >>>SYBASE/UNIX ENIGNEERS WANTED>>>>Bay Area, CA.

11. Check out the Web below for great Computer Prices >>>>>>>>>>>>

12. >>>>>>UNIX/SYBASE ENGINEERS WANTED>>>>>> Bay Area, CA