Hello!

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Hello!

Andy Abate
All,
   I am just introducing myself to the list. My name is Andy Abate and I have been a professional developer for over 30 years. I'm deep into parsing and systems development with Java, C/C++, Assembly and a ton of scripting languages. 

   At the moment, I am working on the DRDA portion of Derby to make it compatible with LUW. I have pretty much everything working except for the validation responses for when a remote stored procedure is being defined. The LUW instance is sending a request for a bogus entry in the syscat.routines table. It is looking for something named AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't exist if the table syscat.routines did. 

   I am defining the Derby database as a DB2/LUW server so it will use the DRDA driver. I'm not really sure how else to do it because I have a specific set of database types from which to choose on the LUW server. 

   Before I do something totally ugly here, I was wondering if anyone had any ideas on how to deal with this. Or at least provide the right answer to the calling LUW. What Derby is sending back right now is TABLE/VIEW doesn't exist. I can dummy the response, but that would mean interrogating all the requests. Not something I really want to do unless I absolutely have to.

Reply | Threaded
Open this post in threaded view
|

Re: Hello!

Rick Hillegas-3
Hi Andy,

Welcome to derby-dev. I'm not sure what you're trying to do: 1) Replace
a DB2/LUW server with a Derby server for use by a remote application
which uses a DRDA driver? 2) Wire a Derby server into a distributed
query processor based on DB2/LUW? Some responses inline...

On 8/30/18 9:32 PM, Andy Abate wrote:

> All,
>    I am just introducing myself to the list. My name is Andy Abate and
> I have been a professional developer for over 30 years. I'm deep into
> parsing and systems development with Java, C/C++, Assembly and a ton
> of scripting languages.
>
>    At the moment, I am working on the DRDA portion of Derby to make it
> compatible with LUW. I have pretty much everything working except for
> the validation responses for when a remote stored procedure is being
> defined. The LUW instance is sending a request for a bogus entry in
> the syscat.routines table. It is looking for something named
> AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't
> exist if the table syscat.routines did.
Derby stores metadata for user-defined routines in SYS.SYSALIASES, along
with metadata for other user-defined schema objects like datatypes and
aggregates. The intricate details of each object are kept in an
org.apache.derby. catalog.AliasInfo object, which serializes into the
byte array stored in the ALIASINFO column of SYS.SYSALIASES. For more
information, see the section on that system table in the Derby Reference
Manual: http://db.apache.org/derby/docs/10.14/ref/rrefsistabs28114.html

You can run queries directly against the metadata catalogs, but that
entails a lot of joining. At this point in your processing, do you have
an active Derby session and therefore a JDBC connection? If so, it might
be simpler to work with a java.sql.DatabaseMetaData object.

Hope I'm not talking past your real question,
-Rick

>
>    I am defining the Derby database as a DB2/LUW server so it will use
> the DRDA driver. I'm not really sure how else to do it because I have
> a specific set of database types from which to choose on the LUW server.
>
>    Before I do something totally ugly here, I was wondering if anyone
> had any ideas on how to deal with this. Or at least provide the right
> answer to the calling LUW. What Derby is sending back right now is
> TABLE/VIEW doesn't exist. I can dummy the response, but that would
> mean interrogating all the requests. Not something I really want to do
> unless I absolutely have to.
>

Reply | Threaded
Open this post in threaded view
|

Re: Hello!

Andy Abate
In reply to this post by Andy Abate
Rick,
   I want to use Derby as a DRDA gateway for temporarily allowing access from z/OS  and JDBC clients during an application migration. I am moving several applications into a cloud environment and will be able to build a fairly large "cluster" to manage the traffic. In that environment my client wants to use an elastically scalable database product which does not support DRDA.

   From what I can see reading the code, the easiest way for me to solve my immediate problem is to change the definition of the SYSCAT schema from being a "system" one to being a normal one. Or, define the ROUTINES table at initialization. 

Sent from my HTC

----- Reply message -----
From: "Rick Hillegas" <[hidden email]>
To: <[hidden email]>
Subject: Hello!
Date: Sat, Sep 1, 2018 17:08

Hi Andy,

Welcome to derby-dev. I'm not sure what you're trying to do: 1) Replace 
a DB2/LUW server with a Derby server for use by a remote application 
which uses a DRDA driver? 2) Wire a Derby server into a distributed 
query processor based on DB2/LUW? Some responses inline...

On 8/30/18 9:32 PM, Andy Abate wrote:
> All,
>    I am just introducing myself to the list. My name is Andy Abate and 
> I have been a professional developer for over 30 years. I'm deep into 
> parsing and systems development with Java, C/C++, Assembly and a ton 
> of scripting languages.
>
>    At the moment, I am working on the DRDA portion of Derby to make it 
> compatible with LUW. I have pretty much everything working except for 
> the validation responses for when a remote stored procedure is being 
> defined. The LUW instance is sending a request for a bogus entry in 
> the syscat.routines table. It is looking for something named 
> AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't 
> exist if the table syscat.routines did.
Derby stores metadata for user-defined routines in SYS.SYSALIASES, along 
with metadata for other user-defined schema objects like datatypes and 
aggregates. The intricate details of each object are kept in an 
org.apache.derby. catalog.AliasInfo object, which serializes into the 
byte array stored in the ALIASINFO column of SYS.SYSALIASES. For more 
information, see the section on that system table in the Derby Reference 
Manual: http://db.apache.org/derby/docs/10.14/ref/rrefsistabs28114.html

You can run queries directly against the metadata catalogs, but that 
entails a lot of joining. At this point in your processing, do you have 
an active Derby session and therefore a JDBC connection? If so, it might 
be simpler to work with a java.sql.DatabaseMetaData object.

Hope I'm not talking past your real question,
-Rick
>
>    I am defining the Derby database as a DB2/LUW server so it will use 
> the DRDA driver. I'm not really sure how else to do it because I have 
> a specific set of database types from which to choose on the LUW server.
>
>    Before I do something totally ugly here, I was wondering if anyone 
> had any ideas on how to deal with this. Or at least provide the right 
> answer to the calling LUW. What Derby is sending back right now is 
> TABLE/VIEW doesn't exist. I can dummy the response, but that would 
> mean interrogating all the requests. Not something I really want to do 
> unless I absolutely have to.
>

Reply | Threaded
Open this post in threaded view
|

Re: Hello!

Andy Abate
In reply to this post by Andy Abate
Rick,
   I didn't answer all your questions. I don't believe that at this point LUW is asking for something real. I think it is expecting to get a NO_DATA_FOUND response. Earlier in the dialog between the machines, it does something similar just trying to prove its talking to a DB2 instance. This looks like more of the same because it is asking for the same information regardless of what procedure I'm trying to define.

Sent from my HTC

----- Reply message -----
From: "[hidden email]" <[hidden email]>
To: <[hidden email]>
Subject: Hello!
Date: Sun, Sep 2, 2018 00:10

Rick,
   I want to use Derby as a DRDA gateway for temporarily allowing access from z/OS  and JDBC clients during an application migration. I am moving several applications into a cloud environment and will be able to build a fairly large "cluster" to manage the traffic. In that environment my client wants to use an elastically scalable database product which does not support DRDA.

   From what I can see reading the code, the easiest way for me to solve my immediate problem is to change the definition of the SYSCAT schema from being a "system" one to being a normal one. Or, define the ROUTINES table at initialization. 

Sent from my HTC

----- Reply message -----
From: "Rick Hillegas" <[hidden email]>
To: <[hidden email]>
Subject: Hello!
Date: Sat, Sep 1, 2018 17:08

Hi Andy,

Welcome to derby-dev. I'm not sure what you're trying to do: 1) Replace 
a DB2/LUW server with a Derby server for use by a remote application 
which uses a DRDA driver? 2) Wire a Derby server into a distributed 
query processor based on DB2/LUW? Some responses inline...

On 8/30/18 9:32 PM, Andy Abate wrote:
> All,
>    I am just introducing myself to the list. My name is Andy Abate and 
> I have been a professional developer for over 30 years. I'm deep into 
> parsing and systems development with Java, C/C++, Assembly and a ton 
> of scripting languages.
>
>    At the moment, I am working on the DRDA portion of Derby to make it 
> compatible with LUW. I have pretty much everything working except for 
> the validation responses for when a remote stored procedure is being 
> defined. The LUW instance is sending a request for a bogus entry in 
> the syscat.routines table. It is looking for something named 
> AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't 
> exist if the table syscat.routines did.
Derby stores metadata for user-defined routines in SYS.SYSALIASES, along 
with metadata for other user-defined schema objects like datatypes and 
aggregates. The intricate details of each object are kept in an 
org.apache.derby. catalog.AliasInfo object, which serializes into the 
byte array stored in the ALIASINFO column of SYS.SYSALIASES. For more 
information, see the section on that system table in the Derby Reference 
Manual: http://db.apache.org/derby/docs/10.14/ref/rrefsistabs28114.html

You can run queries directly against the metadata catalogs, but that 
entails a lot of joining. At this point in your processing, do you have 
an active Derby session and therefore a JDBC connection? If so, it might 
be simpler to work with a java.sql.DatabaseMetaData object.

Hope I'm not talking past your real question,
-Rick
>
>    I am defining the Derby database as a DB2/LUW server so it will use 
> the DRDA driver. I'm not really sure how else to do it because I have 
> a specific set of database types from which to choose on the LUW server.
>
>    Before I do something totally ugly here, I was wondering if anyone 
> had any ideas on how to deal with this. Or at least provide the right 
> answer to the calling LUW. What Derby is sending back right now is 
> TABLE/VIEW doesn't exist. I can dummy the response, but that would 
> mean interrogating all the requests. Not something I really want to do 
> unless I absolutely have to.
>

Reply | Threaded
Open this post in threaded view
|

Re: Hello!

Rick Hillegas-3
In reply to this post by Andy Abate
Thanks for that additional information, Andy. One response inline...

On 9/1/18 10:10 PM, [hidden email] wrote:
Rick,
   I want to use Derby as a DRDA gateway for temporarily allowing access from z/OS  and JDBC clients during an application migration. I am moving several applications into a cloud environment and will be able to build a fairly large "cluster" to manage the traffic. In that environment my client wants to use an elastically scalable database product which does not support DRDA.

   From what I can see reading the code, the easiest way for me to solve my immediate problem is to change the definition of the SYSCAT schema from being a "system" one to being a normal one. Or, define the ROUTINES table at initialization.
This may be relevant: Derby does not let you define a user schema which begins with the SYS prefix. SYS flags a reserved schema namespace which can only be used for Derby-internal metadata. It probably wouldn't be hard to hack Derby to lift this restriction, but the devil is in the details. For instance, one of the side-effects of this limitation is that objects in the SYS* namespace have read-only access--this may not affect you though.

Hope this helps,
-Rick

Sent from my HTC

----- Reply message -----
From: "Rick Hillegas" [hidden email]
To: [hidden email]
Subject: Hello!
Date: Sat, Sep 1, 2018 17:08

Hi Andy,

Welcome to derby-dev. I'm not sure what you're trying to do: 1) Replace 
a DB2/LUW server with a Derby server for use by a remote application 
which uses a DRDA driver? 2) Wire a Derby server into a distributed 
query processor based on DB2/LUW? Some responses inline...

On 8/30/18 9:32 PM, Andy Abate wrote:
> All,
>    I am just introducing myself to the list. My name is Andy Abate and 
> I have been a professional developer for over 30 years. I'm deep into 
> parsing and systems development with Java, C/C++, Assembly and a ton 
> of scripting languages.
>
>    At the moment, I am working on the DRDA portion of Derby to make it 
> compatible with LUW. I have pretty much everything working except for 
> the validation responses for when a remote stored procedure is being 
> defined. The LUW instance is sending a request for a bogus entry in 
> the syscat.routines table. It is looking for something named 
> AMP.TESTFEDERTAION which of course won't exist. Or at least wouldn't 
> exist if the table syscat.routines did.
Derby stores metadata for user-defined routines in SYS.SYSALIASES, along 
with metadata for other user-defined schema objects like datatypes and 
aggregates. The intricate details of each object are kept in an 
org.apache.derby. catalog.AliasInfo object, which serializes into the 
byte array stored in the ALIASINFO column of SYS.SYSALIASES. For more 
information, see the section on that system table in the Derby Reference 
Manual: http://db.apache.org/derby/docs/10.14/ref/rrefsistabs28114.html

You can run queries directly against the metadata catalogs, but that 
entails a lot of joining. At this point in your processing, do you have 
an active Derby session and therefore a JDBC connection? If so, it might 
be simpler to work with a java.sql.DatabaseMetaData object.

Hope I'm not talking past your real question,
-Rick
>
>    I am defining the Derby database as a DB2/LUW server so it will use 
> the DRDA driver. I'm not really sure how else to do it because I have 
> a specific set of database types from which to choose on the LUW server.
>
>    Before I do something totally ugly here, I was wondering if anyone 
> had any ideas on how to deal with this. Or at least provide the right 
> answer to the calling LUW. What Derby is sending back right now is 
> TABLE/VIEW doesn't exist. I can dummy the response, but that would 
> mean interrogating all the requests. Not something I really want to do 
> unless I absolutely have to.
>