Hi Mr. Altmark, Thanks for those suggestions. The Redbook chapter on IPGATE doesn't discuss IPGATE TRACE'ing very much, in fact the only help I can find ther e is something called RXSOCKET DEBUG NOTRACE. Can you or someone point me to any other helpful information about tracing IPGATE and its threads?
Since my X'0201' IPCODE came back in the ISQL call, I looked in the DB2/V M Messages book for further enlightenment and found this about X'0201': x’0210’ Database has severed the link. Attempt to reconnect and conti nue processing. ( gee, no kidding ) So I keep coming back to the thought that my DB2/VM server is not recognising the remote UserID correctly since it's coming "second-hand" through IPGATE instead of directly from the UserID on the remote system. Remember, my SFS Filepool access works just fine, so that DB2 engine working under the covers managing the filepool is handling the "second- hand" requests via IPGATE just fine. But a "real" DB2 server isn't. On Mon, 15 Dec 2008 09:55:24 -0500, Alan Altmark <alan_altm...@us.ibm.com > wrote: > >On the surface it sounds like IPGATE doesn't support the APPCVM SENDCNF >verb, but you'd have to look at an IPGATE detail trace to see why it's >complaining. > >It is also possible that the APPCVM SEVER from IPGATE is based on the >results of whatever DB2 issued prior to the CONFIRM. Since IPGATE was >apparently in the middle of a RECEIVE and got "Read rc = 0 (0 )", it >sounds like it is complaining about the CONFIRM. IPGATE's RECEIVE would >have ended with IPWHATRC=IPCNFRM. You need to see the detailed result s of >the APPCVM RECEIVE (CMRCV). > >Alan Altmark >z/VM Development >IBM Endicott >======================== ========================= ========================
