Distributed Connections Question

[login to unmask email]

Distributed Connections Question
First of all I would like to thank the people involved in the effort of making
this List happen. This is a valuable service that the DB2 community has learned
to learn with. The perspective of loosing this support brought me some
nightmares. Thanks!

Dear DB2 fellows,

Once again I have a puzzling situation I cannot understand and that the manuals
do not teach. Hence I hope one of you have already came across a similar
situation and can bring some light to this issue.
We are running three DB2 (Version 5.1, level 99something), in different OS/390
(version 2.6) regions each, with distributed connection between them. Those
connections are supported in the traditional way, that is LU 6.2. (no TCP/IP),
and we use some REXX procedures to connect between different environments using
the three-level-qualifier support (hence, DB2 private protocol, no DRDA). The
situation I am describing was experienced with this REXX procedures and with
SPUFI indistinctly.

This connection has been up and running until yesterday, when I experienced some
troubles. On the client system we received a -904 with reason 00D3001D and in
the server we received a 'DDF PROCESSING FAILURE' with reason 00D3443A.
Both this reasons point to a missing entry in SYSIBM.SYSUSERNAMES, but I could
find the entry for my primary auth-id associated to the client LU (LINKNAME) and
INBOUND translation in that table. What was more puzzling was that on the client
the user associated with the message 'DDF PROCESS FAILURE' was not my own userid
but DB2TADM.
DB2TADM has at least three different uses in this installation: it is the
INSTALL SYSADM for the Client DB2, is one of the RACF groups to which my own
userid is connected, hence one of my SECONDARY AUTH-IDS on the Client side and
also the one of the SUPERIOR RACF GROUP for all the RACF GROUPS generated to
provide authority to the DB2 users. This is the usage for the Id DB2TADM I can
remember and that might have something to do with this problem.
Nevertheless I would not expect it to be passed from the Client DB2 to the
Server Db2. I do not see in any of the previous usage description nothing that
would justify it...
Contributing to make this more interesting is that another user, not connected
to DB2TADM RACF Group, and trying to connect from the client to the Server was
receiving the same symptom and the message on the server side was also
complaining for the DB2TADM not in the USERNAMES table. The only connection this
user has with the DB2TADM id is that some of the RACF groups to which the user
id is connected have DB2TADM as superior group.
In the mean time I found that another colleague has removes the DB2TADM from
SYSIBM.USERNAMES on the server DB2 quite recently and I associate this delete
with the problems we are experiencing. Once I have inserted a row in the SERVER
USERNAMES table with the DB2TADM id, the connections worked without problem.
Then I removed my own id from the SERVER USERNAMES table and I got the same
problem, but now the message on the SERVER SIDE refers to my own user-id and not
to the DB2TADM as previously.

Describing the Distributed set-up:
DB2 OS/390 V5.1
Connection thru LU6.2
Only Three DDF tables are used: LOCATIONS, LUNAMES, USERNAMES
entry to the server DB2
In LUNAMES table SECURITY_OUT is 'A' for the server connection
DB2 OS/390 V5.1
Connection thru LU6.2
Only Three DDF tables are used: LOCATIONS, LUNAMES, USERNAMES
In LUNAMES table SECURITY_IN is 'A' for the client connection
INBOUND translation - USERNAMES column in LUNAMES has value 'I' for the entry to
the client DB2
Several entries in USERNAMES table with the Client LINKNAME. In all these
entries the NEWAUTHID and PASSWORD columns are empty (spaces).
One entry to my own userid and another for the other userid that experienced the
Another entry to DB2TADM Authid. Without this entry neither myself nor my
colleague could access the server DB2 from the client side. The message on the
referred the DB2TADM auth id.
With the DB2TADM entry, without my userid entry, and with my colleague authid
entry I cannot access the server from the client but my colleague can.

IMPORTANT - during all this problem and the tests that resulted in the
resolution of the problem the DDF was never refreshed (STOP/START).

My knowledge of the distributed environment set up indicated that we would need
only one entry in USERNAMES table to allow the connection in this configuration.
Surprisingly it seems that the DB2TADM is also mandatory, but I do not know WHY.
Does anybody know WHY?

I have plans to test this situation using the other DB2 subsystem. But
unfortunately I cannot change the DDF definitions in these two environments
while they are in use...

I would appreciate if someone can enlighten this problem. In case you need more
information I can supply the list the contents of the DDF tables and any other
configuration information.
Whoever replies to this message could put my own email ([login to unmask email]) in
copy. I receive only the Digest format of the list and it will take 24 hours I
can read the reply...


Vitor Pacheco Moreira
aMaDEUS Data Processing GmbH
Berghamer Str. 6
D-85435 Erding Germany

voice: +49-8122-43(3952)
fax: +49-8122-43(3260)
email: [login to unmask email]