Informing the IBM Community

WRKRDBDIRE part 2 – MYSELF and DDMDRDA

1
(1)

Some of you may remember an article I wrote in December 2019 about using WRKRDBDIRE and DDM to get data from a V5R4 system. Recently I came across a couple of extra scenarios when pulling data from systems, so it seems a perfect opportunity for a part 2 article.

First off, what if I want to test DDM connectivity but I only have one server/partition available? Well luckily IBM have thought of this and there are two special names that can be used. The full article is here but to summarise the key point:

If you want to make a DRDA connection to the local system database, such as for program testing, there are two special RDB names that can be used for that purpose: ME and MYSELF

Using the ADDRDBDIRE command that we discussed last time, you can set up an entry such as:

ADDRDBDIRE RDB(MYSELF) RMTLOCNAME(loopback *IP)

You can then prefix your statements with ‘myself’ to pull from the local machine. Again, using my example from the last article:

 select * from mnis820.shearsd.emlrolk 

Becomes

 select * from myself.shearsd.emlrolk 

This is an edge case scenario, but one that’s useful to keep in your back pocket for the day you suddenly find yourself needing it. In most situations, if you wanted data from the local machine, you wouldn’t be going through DDM to get it.

A second scenario, which is more of a shortcut than anything else, is QDDMSERVER and QDDMDRDASERVER.

These are two special values that can be used in the ADDSVRAUTE command. If you don’t have a specific server auth entry for a given system, the connection will be attempted with the credentials on this entry. Again, IBM do quite a nice detailed breakdown if you’re interested.

QDDMDRDA is the better choice normally as it was PTF’d back to V5R4. I mention QDDM here for those of you who find yourself on an old system that doesn’t have the relevant PTFs, or maybe never got to V5R4 (they’re still out there!) I’m sure someone in the comments will correct me if I’m wrong on the PTFs.

Using the ADDSVRAUTE command I add the DDMDRDRA entry:

 ADDSVRAUTE USRPRF(SHEARSD) SERVER(QDDMDRDASERVER) USRID(SHEARSD) PASSWORD()

Meaning my DSPSVRAUTE command now has the original server specific entry, and my new generic one.

When I connect to MNIS820 it’ll still use the specific entry, but any other server I try to touch will use the new entry. In most cases, I’d recommend using specific entries where possible, as clearly, you’re not sharing passwords across partitions/servers. But if you have a use case where you’re replicating between multiple servers/partitions then this can save you having to create multiple entries on each one.

Hopefully this is helpful to some people out there who come across these edge cases, what other scenarios have you found for RDBDIRE and authorisation? Do you have a preferred method that hasn’t been discussed yet?

How useful was this post?

Click on a star to rate it!

Average rating 1 / 5. Vote count: 1

No votes so far! Be the first to rate this post.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *