Hi Mr. van der Heij, I inserted that CMECT call you suggested and got this:
IPGATEY0000000009 started. CM CONVERSATION TYPE = CM_BASIC_CONVERSATION CM RETURN CODE = 0 IPGATEY0000000009 Request from DB2USER for USAUTO at 1370 172.16.0.19 IPGATEY0000000010 started. CM CONVERSATION TYPE = CM_BASIC_CONVERSATION CM RETURN CODE = 0 IPGATEY0000000010 Request from DB2USER for CSISQL02 at 1370 172.16.0.19 IPGATEY0000000010 ended. Both SFS and DB2 are making their calls as "Basic Conversation". I'm thinking my problem has something to do with the way IPGATE at the target system is passing or presenting the "DB2USER" UserID to DB2/VM. The request shows up at the target IPGATE looking correct: IPGATEI0000000019 started. (3 3 AF_INET 1076 172.16.57.1) IPGATEI0000000019 User DB2USER from 172.16.57.1 has been accepted for CSISQL02 - IPGATEI0000000019 Thread terminating ... Read rc = 0 (0 ) IPGATEI0000000019 ended. Any suggestions for what I could trace on the target IPGATE that might sh ed some more clues ? Thanks! On Sat, 13 Dec 2008 21:04:54 +0100, Rob van der Heij <rvdh...@gmail.com> wrote: >On Sat, Dec 13, 2008 at 7:37 PM, C. Lawrence Perkins ><vmwiz...@ix.netcom.com> wrote: > >> I have IPGATE working just fine to access a global resource SFS Filepo ol on >> z/VM "System B" from a UserID on "System A", so I have proof-of-concep t. > >IPGATE only supports basic conversations and not mapped conversations. >If DB2 DRDA is using mapped conversations (I don't know enough about >DB2) then that might explain it. > >In an earlier discussion with the author, he replied >"you could insert a call to CMECT in IPGATE1Y MTREXX (line 126) on the >source system: > >address 'CPICOMM' 'CMECT cm convid cm convtype return code' ; say >"CM CONVERSATION TYPE =" CM CONVERSATION TYPE.cm convtype "rc="retur n code > >This would reveal whether it is a mapped conversation. > >-Rob >======================== ========================= ========================
