Helt tilbage i år 2000 skrev jeg et tip om CAF. I dette tip nævner jeg en passant muligheden for at skifte DB2 subsystem inde fra et program. For at kunne skifte DB2 subsystem med CAF skal der en del ekstra gymnastik til end beskrevet i det nævnte tip. Det er nemlig ikke helt uproblematisk.

Når først CAF interfacet er blevet aktiveret med en OPEN, så er det nærliggende at tro, at efter en CLOSE, så kan man bare lave en ny OPEN mod et andet DB2 subsystem. Men så let synes DB2 CAF interface programmørerne ikke, at det skal være. Nu får man i stedet en OPEN fejl, der fortæller, at man allerede er connected til et andet DB2 subsystem. Med OPEN og CLOSE alene kan man skifte DB2 plan, men ikke DB2 subsystem.

Du skal derfor benytte dig af to ekstra CAF interface kald kaldet CONNECT og DISCONNECT for at skifte DB2 subsystem. Her er et eksempel i PL/I, som forudsætter, at du også kigger på tippet fra år 2000:

dcl caf_function char(12);
dcl caf_ssid char(4);
dcl caf_termecb pointer;
dcl caf_startecb pointer;
dcl caf_ribptr pointer;

caf_ssid = 'MYDB';
caf_termecb = null;
caf_startecb = null;
caf_ribptr = null;
caf_function = 'CONNECT';
call dsnali( caf_function, caf_ssid, caf_termecb, caf_startecb
           , caf_ribptr, caf_retcode, caf_reascode
           );
if caf_retcode = 0
then do;
  /* Put your CAF OPEN here */
  /* Do program processing */
  /* Put your CAF CLOSE here */
  caf_function = 'DISCONNECT';
  call dsnali(caf_function);
end;
else do;
  /* Do some kind of error processing */
  /* Remember to display value of caf_reascode */
end;

Det vigtige er at starte med CONNECT kaldet. Når du efterfølgende udsteder OPEN kaldet for at angive en DB2 plan skal du huske at benytte samme værdi for DB2 subsystemet som på CONNECT kaldet. Efter CLOSE kaldet skal du udføre en DISCONNECT. Du behøver ikke at kontrollere caf returkoderne, da du nok skal få at vide, hvis noget gik galt på det næste CONNECT kald. Desuden kan DISCONNECT godt finde på at give en warning, selv om det går godt og så bliver fejlhåndteringen pludselig mere besværlig.

I beskrivelsen af DISCONNECT står der, at DISCONNECT foretager en implicit CLOSE med option SYNC, hvis der ikke er foretaget en CLOSE. Problemet er bare, at en efterfølgende CONNECT/OPEN fejler, hvis man lader DISCONNECT foretage sin CLOSE. Derfor skal du altid lave et selvstændigt CLOSE kald. Du kan i øvrigt læse alt det andet, der er værd at vide om CAF interfacet i Application programming and SQL guide. Link'et er til DB2 version 7 udgaven.

Lad dig i øvrigt ikke forvirre af de tre pointere til CONNECT kaldet. Det fungerer aldeles fremragende ved at sætte dem til null. Pointerne er mest til glæde for folk, der laver started tasks og gerne vil vide om DB2 er oppe eller nede. Hvis du selv er ude i den slags overvejelser, så lav DISCONNECT, før dit task giver sig til at vente på næste opgave. Lav så en ny CONNECT, når task'et skal løse en ny opgave.