Hi Bryan,

I'm sorry for missing your comments in creation of a patch - I came back to this issue after a couple of days after reading your comments. Thank you for reminding.

So reading your comments again I think the best way how to implement a test is to add a check to DRDAConnThread object and throw an exception
when the server receives a different RDBNAM in PKGNAMCSN codepoint than the default values of a connection. The test program then could be
the program specified in JIRA - when the client sends different package name, the exception will be thrown ("RDBNAM Mismatch") and query
won't be processed. It is sufficient to add this check only to parsePKGNAMCSN function.

A small extract from DRDA DDM:
---------------------------------------------
With SQLAM level 7, the PKGNAMCSN is changed to an optional instance variable. If specified,
the values are used as the default package name and consistency token for the connection. If not
specified on the command, the PKGSN is required to identify the section number. In this case,
the default package name, consistency token, and specified section number are used for the
request. If PKGNAMCSN was never specified on the connection, a PRCCNVRM is returned.

According to this specification I think it is possible to change the default database name on a connection,
thus theoretically there might exist a request that would require to change a database name through
the PKGNAMCSN codepoint. Thus the question is: Will we add a check or will we allow a change of
the database name on a connection? It makes no sense to allow a database name change for jdbc api...
because AFAIK this stuff is not supported by the jdbc api.

However, I would not recommend allowing a change of the connection just now because connecting
with an old implementation of jdbc client to a new implementation of server will not work when creating
multiple connections to different databases.

So, I will add these things to the patch:

1.) A check of the database name in PKGNAMCSN codepoint.
2.) A test program doing something similar as the d1434.java attached to jira.

Would it be alright then?
And thanks for the detailed analysis of the problem, Julius; it has been
quite illuminating to read your notes.
Thanks... ;-); I liked going through it...

Cheers,

Julo

Reply via email to