MainframeSupports
tip week 45/2010:

I have noticed that many MQ programs does not use the informaion provided by receiving a MQ REASON 2002 from a MQCONN call. As you may already know it is not necessary to issue MQ connect in CICS, because CICS issues this call itself. It is fully legal to issue a MQ connect anyway and it will result in a MQ REASON 2002, which you just ignore as it does not affect the MQ connection in any way.

In batch you must issue a MQCONN in order to tell the following calls to MQ which MQ manager will process the calls. In batch you can connect to more than one MQ manager, but only one at a time, because you will receive a MQ REASON 2002 if you try to start a new connection while another one is active.

The above knowledge is of course important to understand, but what can you actually use it for? First thing is: you can build MQ programs that works both in batch and in CICS. An example:

...
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)
...

The above code will make your program work equally well in batch as in CICS. The real neat thing about the above example is that it can be used in any sub program and leave the calling program unharmed no matter whether the calling program connected to MQ or not. The only problem is if the sub program requires to be connected to a certain MQ manager (for instance MQGET only works on local MQ queues). In this case the sub program will only work correctly if the calling program has connected to the correct MQ manager or did not connect at all. Generally it is a requirement that the application runs on a MVS where the involved MQ managers are running.

Previous tip in english        Sidste danske tip        Tip list