Jeg har lagt mærke til, at mange MQ programmer ikke benytter sig af den information, der ligger i at få MQ REASON 2002 på et MQCONN-kald. Som du måske ved, så er det ikke nødvendigt at udstede MQ connect i CICS, da CICS selv sørger for dette. Derfor kan du godt udstede MQCONN alligevel. Det resulterer bare i en MQ REASON 2002, som du kan ignorere, da kaldet ikke har påvirket MQ på nogen måde.

I batch er MQCONN til gengæld nødvendigt for at fortælle de efterfølgende MQ-kald, hvilken MQ manager de skal behandles af. I batch kan man altså connecte til flere forskellige MQ managere, men kun een ad gangen, da man får MQ REASON 2002, hvis man forsøger at starte en ny connection, mens man har gang i en anden connection.

Ovenstående er selvfølgelig vigtigt at vide, men hvad kan du så bruge disse informationer til. For det første så kan du lave MQ programmer, der virker lige godt om de kører i batch eller under CICS. Et eksempel:

...
CALL mqconn(mqManagerName, mqmHandle, mqRC, mqReason)
IF mqReason = 0
  disconnectFromMq = 'Y'
ELSE
  IF mqReason = 2002
    disconnectFromMq = 'N'
  ELSE
    ... Perform errorHandling
... Perform other MQ calls
IF disconnectFromMq = 'Y'
  CALL mqdisc(mqmHandle, mqRC, mqReason)
...

Med ovenstående kode vil dit program virke lige godt i batch og under CICS. Det rigtig fikse ved ovenstående eksempel er, at det kan benyttes i et hvilket som helst underprogram og holde det kaldende program skadesløst uanset om det kaldende program har connectet til MQ eller ej. Det eneste problematiske er, hvis underprogrammet kræver at være connectet til en bestemt MQ (MQGET virker eksempelvis kun på en lokal kø). I dette tilfælde vil underprogrammet kun virke korrekt, hvis hovedprogrammet har connectet til den af underprogrammet krævede MQ eller slet ikke har connectet. Helt generelt er det selvfølgelig en forudsætning, at programkomplekset kører på en MVS, hvor den/de nødvendige MQ managere er tilgængelige.