Search results for query: *

Samples are included with MQ itself. Look in the samples directory on a machine with MQ installed.

Which system are the messages being put onto the queue from?

It begs the question....why do you want to stop it? Use DISCINT on the channel definition and it will go inactive itself. A stopped channel cannot be restarted using triggering, if fact it can only be restarted manually.

Try the IBM website itself. It may have some, apart from that ... good luck. Terms and conditions of taking the test forbid disclosure of the questions. Best bet is to search the IBM website I am pretty sure there were some there last time I looked.

Run a RUNMQSC and input display channel(SYSTEM.ADMIN.SVRCONN) It should be created when the queue manager is but it may have been deleted on your system to prevent client attachments. Do you know if you are using SSL?

oh...and does the qmgr have a SYSTEM.AUTO.SVRCONN definition?

Are you getting any errors in the AMQERR logs?

You need to do a display QMGR and check that the value for CHAD is enabled...if not...then enable it and try again.

OK...next thing....look to see that the QMGR has Channel Auto Definition enabled.

A SRVCONN is a channel type defined on the QMGR that you want to client in to. You will need one defined before you are able to Client connect to the qmgr. DEFINE CHANNEL(xxxxx) CHLTYPE(SVRCONN) TRPTYPE(TCP) + DESCR('Server-connection')

The trigger monitor will sit and watch the initiation queue. When a message lands of your triggered queue and prividing all the trigger conditions are met, then MQ will generate a trigger message internally and drop it on the initiation queue. The trigger monitor will read that message and...

This may sound a little obvious but...have you defined the SRVRCONN channel on the server correctly?

Use triggering to kick the program off. I think triggering is described in chapter 14 of the Application Programmers Guide.

IIRC you have to restart the client machine before the change to the MQSERVER variable takes effect. I could be wrong, but I would give it a shot.

Why do you need to check for queues? You shouldn't need to do anything like that. If you try and issue an open for a non-existing queue you will get the return code of 2085 so you will know it isn't there. What exactly is the requirement?

You really have no choice but to download a trial version if you don't have access to a server. If you had access you could use the MQ Client. You could download the MQ Client and this would enable you to develop the code but you would not be able to successfully do any MQ calls so it wouldn't...

It depends on your trigger type.

How did you create the channel table?

I would recommend that you do the install properly otherwise you may run into lots of problems. Version 6.0 is available and I would certainly recommend installing that on any new servers.

You do know why MQPUT1 worked and MQPUT didn't though right?