MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Checking runmqsc Status Codes with Unix Scripting

By Tim Zielke posted Mon November 23, 2020 01:13 PM

  

Checking runmqsc Status Codes with Unix Scripting

 

One of the things that is easy to overlook with Unix scripting is checking the status code of a command. For example, if you use the runmqsc -c (client) command in a script, it is a good idea to check the status code to make sure that the runmqsc command returned a successful status code. Here is an example of what I am talking about from a Linux shell prompt:

 

> echo "dis qmgr ccsid" | runmqsc -c QM1

5724-H72 (C) Copyright IBM Corp. 1994, 2020.

Starting MQSC for queue manager QM1.

 

 

     1 : dis qmgr ccsid

AMQ8408I: Display Queue Manager details.

   QMNAME(QM1)             CCSID(1208)

2 command responses received.

 

> echo $?

0

 

By printing out the “$?” variable immediately after the runmqsc -c command, I can see that the runmqsc command returned a successful zero status code. If the runmqsc -c command encountered an error, the $? variable should show a non-zero value. From some of my own testing with the runmqsc client, I have found this to be the case that it returns a non-zero status code when it has encountered an error. However, one common use case of an "error" is when there are no objects to return from your mqsc command (e.g. DIS CHL(BLAH) returns no results). In this case, 10 is returned by runmqsc as the status code, so you will probably want to recognize that as an acceptable return code.

 

The following blog post covers a Unix script called mqsc-qmgrs which is a wrapper around the runmqsc client and provides the capability to take a runmqsc command (e.g. DIS CHLAUTH(*) ALL) and execute this command against a group of queue managers and then collect the result data into files that makes it easier to search and work with the result data.

 

https://community.ibm.com/community/user/middleware/blogs/tim-zielke1/2020/07/09/mqsc-qmgrs-script

 

Here is a snippet from the mqsc-qmgrs script that I recently enhanced to check the status codes of the runmqsc client invocations. If any error status code is found, the script stops processing and reports the error. High level, this part of the script calls the runmqsc client against a list of queue managers in the QMGR_GROUPS, and then records the pid of each runmqsc client invocation. It then executes a wait command against each pid and records the status code (i.e. $?) of each runmqsc client invocation. Finally, it steps through all the individual status codes and if it finds an unacceptable status code, it prints out the queue manager that hit the error and exits the script with a non-zero value.

 

# execute in parallel runmqsc -c against qmgrs in our qmgr group

echo Initiating runmqsc calls for queue managers in group $1

for QMGR in $QMGR_GROUPS

do

runmqsc -c $QMGR < mqsc-qmgrs-$2-input > mqsc-qmgrs-$2-output$QMGR$PID.txt &

WAIT_PIDS+=($!)

QMGR_HOLD+=($QMGR)

done

 

# wait for all runmqsc -c processes to finish, and store each process's exit code into array STATUS[].

for pid in ${WAIT_PIDS[@]}; do

wait ${pid}

STATUS+=($?)

done

 

# after all processes finish, check their exit codes in STATUS[].
# 0 (sunny day scenario) and 10 (objects not found) will be acceptable exit codes.

i=0

for st in ${STATUS[@]}; do

if [[ ${st} -ne 0 ]] && [[ ${st} -ne 10 ]]; then

echo "runmqsc -c for ${QMGR_HOLD[i]} failed! exiting!"

exit 1

fi

((i+=1))

done

 

There have been some other blog posts in the recent past about issues with the MQ command server not being able to get all the reply messages properly back to a client like the runmqsc client.

 

https://t-rob.net/2018/05/14/command-server-gotcha/

 

If you are working with Unix scripting that uses the runmqsc client and it has the check of the status code of the runmqsc client command, I believe you will have a way to catch this type of issue. At least, that is what I have validated with my own testing. 



#IBMMQ
#MQ
0 comments
28 views

Permalink