federation and functions

[BobTheDataBaseBoy]

A client has 390/V7 and UDB/V8. It would be useful to use row_number()
when selecting from 390, but that's not supported. It occurs to me (I'm
not in CubeLand, and anyway we upgraded to V8 on z/OS) that federation
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?

thanks

[Knut Stolze]

BobTheDataBaseB oy <"xxx at rcn dot com"wrote:

A client has 390/V7 and UDB/V8. It would be useful to use row_number()
when selecting from 390, but that's not supported. It occurs to me (I'm
not in CubeLand, and anyway we upgraded to V8 on z/OS) that federation
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?

Let me phrase it that way: you can set up a nickname on UDB that points to
DB2 z/OS. Now you could run queries against that nickname and apply the
ROW_NUMBER() function there.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

[BobTheDataBaseBoy]

Knut Stolze wrote:

BobTheDataBaseB oy <"xxx at rcn dot com"wrote:

>A client has 390/V7 and UDB/V8. It would be useful to use row_number()
when selecting from 390, but that's not supported. It occurs to me (I'm
not in CubeLand, and anyway we upgraded to V8 on z/OS) that federation
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?

Let me phrase it that way: you can set up a nickname on UDB that points to
DB2 z/OS. Now you could run queries against that nickname and apply the
ROW_NUMBER() function there.

works like a charm. reading the docs and the ibm infocenter didn't shed
any light on the question of CREATE USER MAPPING... which is that the
password has to be used. looking at Configuration Assistant, one can
choose to authenticate at the client, but would that override
federation/nickname definition? this is, for my corner of CubeLand
theoretical, in that the PHBs haven't figured out the usefulness of
federation. OTOH, for a production environment, federating a z/OS
database to a Windoze one might be considered de facto insecure.

does IBM actually recommend federation? or even DDF?

[Knut Stolze]

BobTheDataBaseB oy <"xxx at rcn dot com"wrote:

Knut Stolze wrote:

>BobTheDataBase Boy <"xxx at rcn dot com"wrote:

>>A client has 390/V7 and UDB/V8. It would be useful to use row_number()
when selecting from 390, but that's not supported. It occurs to me (I'm
not in CubeLand, and anyway we upgraded to V8 on z/OS) that federation
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?

Let me phrase it that way: you can set up a nickname on UDB that points
to
DB2 z/OS. Now you could run queries against that nickname and apply the
ROW_NUMBER() function there.

works like a charm. reading the docs and the ibm infocenter didn't shed
any light on the question of CREATE USER MAPPING... which is that the
password has to be used.

CREATE USER MAPPING is used to tell the federated server with which
credentials to connect to the remote data source. For example, if the
federated server (DB2) does not reside on the same system as the data
source, then DB2 needs to know the respective information.

looking at Configuration Assistant, one can
choose to authenticate at the client, but would that override
federation/nickname definition?

Client authentication is orthogonal to user mappings. It just tells the DB2
server (federated server or data source) which system performs
authentication. There are a few things to consider for client
authentication (trust clients vs. non-trusting).

this is, for my corner of CubeLand
theoretical, in that the PHBs haven't figured out the usefulness of
federation.

PHB?

OTOH, for a production environment, federating a z/OS
database to a Windoze one might be considered de facto insecure.

Depends on your configuration. You can make each system insecure with the
respective configuration, and you can also set up a secure federated
system.

does IBM actually recommend federation? or even DDF?

Why should IBM not do that?

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany

[BobTheDataBaseBoy]

Knut Stolze wrote:

BobTheDataBaseB oy <"xxx at rcn dot com"wrote:

>Knut Stolze wrote:

>>BobTheDataBas eBoy <"xxx at rcn dot com"wrote:

A client has 390/V7 and UDB/V8. It would be useful to use row_number()
when selecting from 390, but that's not supported. It occurs to me (I'm
not in CubeLand, and anyway we upgraded to V8 on z/OS) that federation
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?
Let me phrase it that way: you can set up a nickname on UDB that points
to
DB2 z/OS. Now you could run queries against that nickname and apply the
ROW_NUMBER( ) function there.

works like a charm. reading the docs and the ibm infocenter didn't shed
any light on the question of CREATE USER MAPPING... which is that the
password has to be used.

CREATE USER MAPPING is used to tell the federated server with which
credentials to connect to the remote data source. For example, if the
federated server (DB2) does not reside on the same system as the data
source, then DB2 needs to know the respective information.

What I haven't found out, which I could do by just changing the z/OS
password, but that would break other things; is whether the
Nickname/federated database will be accessible after that. In my
corner, it's RACF and new password every 30 days or so. Or, put another
way, does the password used during CREATE USER MAPPING... persist on the
connection? Or only to authenticate at the time of creating the
mapping? Docs didn't say, near as I can tell. Does the authentication
chosen from Client Configuration (GUI or not) affect the execution of
the mapping thenceforth? Again, I looked, but couldn't find an answer.

>

>looking at Configuration Assistant, one can
choose to authenticate at the client, but would that override
federation/nickname definition?

Client authentication is orthogonal to user mappings. It just tells the DB2
server (federated server or data source) which system performs
authentication. There are a few things to consider for client
authentication (trust clients vs. non-trusting).

>this is, for my corner of CubeLand
theoretical, in that the PHBs haven't figured out the usefulness of
federation.

PHB?

Pointy Haired Boss. Dilbert, man. ya gotta read the newspapers.

>

>OTOH, for a production environment, federating a z/OS
database to a Windoze one might be considered de facto insecure.

Depends on your configuration. You can make each system insecure with the
respective configuration, and you can also set up a secure federated
system.

>does IBM actually recommend federation? or even DDF?

Why should IBM not do that?

They should, far more than they seem to do; at least from where I sit.
I think they should, umm prod, the clients to use DB2, especially z/OS
versions, as a database rather than a collection of (VSAM) files. In my
corner of CubeLand, which resides in the generic industry known as
Financial Services, that's what goes on. A little prodding from IBM,
rather than vacant head-nodding when clients say they just serially
query tables and run the results through endless COBOL cursors, would go
a long way toward moving those folks nearer Dr. Codd's goal.
Admittedly, not your job; the customer engineers' job. OTOH, if the XML
loonies steal *All* the mindshare, there won't be nobody doin no
databases.

Just a thought. And a tip of the Hatlo hat, thanks.

[Knut Stolze]

BobTheDataBaseB oy <"xxx at rcn dot com"wrote:

Knut Stolze wrote:

>BobTheDataBase Boy <"xxx at rcn dot com"wrote:

>>Knut Stolze wrote:
BobTheDataBa seBoy <"xxx at rcn dot com"wrote:

A client has 390/V7 and UDB/V8. It would be useful to use
row_number( )
when selecting from 390, but that's not supported. It occurs to me
(I'm not in CubeLand, and anyway we upgraded to V8 on z/OS) that
federatio n
(on UDB/V8) might support functions on those 390/V7 tables. Is this
known?
Let me phrase it that way: you can set up a nickname on UDB that points
to
DB2 z/OS. Now you could run queries against that nickname and apply
the ROW_NUMBER() function there.

works like a charm. reading the docs and the ibm infocenter didn't shed
any light on the question of CREATE USER MAPPING... which is that the
password has to be used.

CREATE USER MAPPING is used to tell the federated server with which
credentials to connect to the remote data source. For example, if the
federated server (DB2) does not reside on the same system as the data
source, then DB2 needs to know the respective information.

What I haven't found out, which I could do by just changing the z/OS
password, but that would break other things; is whether the
Nickname/federated database will be accessible after that. In my
corner, it's RACF and new password every 30 days or so. Or, put another
way, does the password used during CREATE USER MAPPING... persist on the
connection?

You will have to change the user mapping.

Or only to authenticate at the time of creating the
mapping?

No. The mapping is stored in the DB2 catalog (not with a plan password, of
course). The thing is that the federated server may shut down.
Afterwards, it can still/again establish a new connection to the remote
data source. For that, it needs the credentials again.

Docs didn't say, near as I can tell. Does the authentication
chosen from Client Configuration (GUI or not) affect the execution of
the mapping thenceforth? Again, I looked, but couldn't find an answer.

Which authentication method are you talking about? The federated server is
just another application from the perspective of the data source. So
everything relating to authentication at the data source is applicable
right as it is for all other applications. From the perspective of the
federated server, we are talking about a regular application (your own,
possibly).

>PHB?

Pointy Haired Boss. Dilbert, man. ya gotta read the newspapers.

I'm well aware of this basic daily lecture for any engineer. I just didn't
connect this. ;-)

>>does IBM actually recommend federation? or even DDF?

Why should IBM not do that?

They should, far more than they seem to do; at least from where I sit.

Different story. I have my personal opinions there, which I won't explain
in detail now. ;-)

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany