The question I have is related to the following message when a request is forced off by the DB2 Governor on UDB on AIX (DB2 on the mainframe, using the RLF, returns a -905). I want to trap the -30081 return code and not the -99999 code which is what is happing today.

-IF (&RETCODE LT 0) GOTO SQL_ERROR;
-*I get the -99999 in &RETCODE

(FOC1400) SQLCODE IS -30081 (HEX: FFFF8A7F)
: [40003] [IBM][CLI Driver] SQL30081N A communication error has been dete
: cted. Communication protocol being used: "TCP/IP". Communication API b
: eing used: "SOCKETS". Location where the error was detected: "xx.xxx.xx
: x.xx". Communication function detecting the error: "recv". Protocol sp
: ecific error code(s): "*", "*", "0". SQLSTATE=08001
(FOC1407) SQL FETCH CURSOR ERROR. : SQLOUT
(FOC1400) SQLCODE IS -99999 (HEX: FFFE7961)
: [40003] [IBM][CLI Driver] CLI0108E Communication link failure. SQLSTATE
: =40003
(FOC1408) SQL CLOSE CURSOR ERROR. : SQLOUT

I'm afraid what you're seeing may be the typical behavior for the values in &RETCODE as well as &FOCERRNUM. From your post, I see two entries with a FOC1400. The first one showed the -30081 and the second one showed the value of -99999. Unfortunately, the values in these amper variables is the last value given, which in this case is the -99999. If I'm correct here, then I don't believe there is anyway for you to capture the -30081.

Can you prefix each request with a short db2 request that returns the required retcode and does not consume much resource.

Also there's a setting to pass sql return codes that you could check the setting of to see if it needs to be turned on.

Another approach may be to set session monitor on (if this still works) save the output and then scan for the code that you want to look for.

Used to do this on FOCUS 5.5 so would be interested to see if it is still working!