IBM MQ mqrc 2042 - c++

Have an issue with one of MQ queue, where multiple C++ program is trying to access the queue from different host and they receiving 2042 error. I can see they are opening the queue as exclusive INPUT "INPUT(EXCL)" and APPLTAG(mqmessage).
From queue manager side queue is set to shareable and DEFSOPT(SHARED) all looks good.
What are the changes required from C++ program not to open as EXCL input? So that multiple user can access?
Thanks

Openoptions of the C++ application have to be modified.If your c++ application is having "MQOO_INPUT_EXCLUSIVE" as one of the OpenOptions then it has to be removed.
Check this MQOPEN options for removing messages
Following stackoverflow answer is also on the similar lines
IBM WebSphere MQ 2042 error

Related

where is emergency message in veins?

There are two kind of messages in Vanet that are considered as safety messages.Their name are
1.beacon
2.event driven (emergency message).
I am using omnet++ 5.4.1,veins 4.7.1 and sumo-0.30.0. However veins just has BSM(beacon) and WSA and data that all of them are not emergency message.how can I access to the emergency message in veins?
I need to access to the event driven message.
I read stackoverflow over and over but I did not find that.
As of Veins 4.7.1, only generic message types are included with Veins. You can use them to create a simulation according to your needs. The tutorial example illustrates how to send an event triggered message with a defined transmit power and access category. It might be a good starting point to write your simulation.

What does routine HidD_FlushQueue() exactly do?

I am using the USB-Hid Class to communicate with my USB-Device in a C++ Application.
Can someone tell me, what the routine HidD_FlushQueue() exactly does? https://msdn.microsoft.com/en-us/library/windows/hardware/ff538876%28v=vs.85%29.aspx
I am using it to flush the input queue before sending a command. I was told to do so to guarantee the input queue is empty.
This normally works great but in some circumstances, my programm gets stuck in this funtion and does not return.
I am not using some asynchronious methods that acess the queue could block it. Is it possible, that the problem lies on the side of the USB device? Any advices?
A HID device can send Input Reports to the host. Windows accumulates these reports in a queue. HidD_FlushQueue() removes all the reports accumulated by Windows from the queue.
I call the function at the beginning of my reading thread and I've never had a problem, although my device doesn't send reports until they're requested.

Websphere MQ - error with reason code 2042 on a get

We're getting an intermittent error on a ImqQueue::get( ImqMsg &, ImqGetMessageOptions & ); call with reason code 2042, which Should Not Happen™ based on the Websphere documentation; we should only get that reason code on an open.
Would this error indicate that the server could not open a queue on its side, or does it indicate that there's a problem in our client? What is the best way to handle this error? Right now we just log that it occurs, but it's happening a lot. Unfortunately I'm not well-versed in Websphere MQ; I'm kind of picking this up as I go, so I don't have all the terminology correct.
Our client is written in C++ linking against libmq 6.0.2.4 and running on SLES-10. I don't know the particulars for the server other than it's running version 7.1. We're requesting an upgrade to bring our side up-to-date. We have multiple instances of the client running concurrently; all are using the same request queue, but each is creating its own dynamic reply queue with MQOO_INPUT_EXCLUSIVE + MQOO_INPUT_FAIL_IF_QUIESCING.
If the queue is not already open, the ImqQueue::get method will implicitly open the queue for you. This will end up with the MQOO_INPUT_AS_Q_DEF option being used which will therefore use the DEFSOPT(EXCL|SHARED) attribute on the queue. You should also double check that the queue is defined SHARE rather than NOSHARE, but I suspect that will already be correctly set.
You mention that you have multiple instances of the application running concurrently so if one of them has the queue opened implicitly as MQOO_INPUT_AS_Q_DEF resulting in MQOO_INPUT_SHARED from DEFSOPT, then it will get 2042 (MQRC_OBJECT_IN_USE) if others have it open. If nothing else had it open at the time, then the implicit open will work, and later instances will instead get the 2042.
If it is intermittent, then I suggest there is a path through your application where ImqQueue::open method is not invoked. While you look for that, changing the queue definition to DEFSOPT(SHARED) should get rid of the 2042s.

Exchanging messages between two C++ programs

I am new to creating Windows applications in C++. My task is to write two cpp files, one of which will send a number (x) to the other one, the other one will evaluate f(x) and send it back to the first one. I should implement it using Messages. Couldn't get anything specific online, Could someone pls give me a clue, where to start?
Great thanx!
Are you talking about window messages? If so, the sending app could use SendMessage, which would cause the receiving app to get its window procedure executed. Of course, this means that the receiving app needs to create a window whose window handle is somehow made available to the sending app.
You can do it in several ways.
Using WM_COPYDATA message to pass the data
Allocating global memory to pass data and sending your own message, such that second program can read the data from memory
Sending a message (if two ints suit your needs to pass data)
Using named pipes
Using TCP/IP local connection (peer to peer or through a server)
Look at ZeroMQ (http://zeromq.org ; cross-platform, LGPL). It is a very simple, lightweight and powerfull library. From the very basic level you can use it to exchange UDP-style datagrams, but through reliable transport (TCP or some variants). Also you have cancelling support, time-based polling and advanced network schemes (which are non-needed in your case). I've selected it for a similar task, and it performs very well.

Options for inter-service one-way communication

I'm searching for different options for implementing communication between a service and other services/applications.
What I would like to do:
I have a service that is constantly running, polling a device connected to a serial port. At certain points, this service should send a message to interested clients containing data retrieved from the device. Data is uncomplicated, most likely just a single string.
Ideally, the clients would not have to subscribe to receive these messages, which leads me to some sort of event 'broadcast' setup (similar to Windows events). The message sending process should not block, and does not need a response from any clients (or that there even are any clients for that matter).
I've been reading about IPC (COM in particular) and windows events, but am yet to come across something that really fits with what I want to do.
So is this possible? If so, what technologies should I be using? If not, what are some viable communication alternatives?
Here's the particulars of the setup:
Windows 2000/XP environments
'Server' service is a windows service, using VC++2005
Clients would vary, but always be in the windows environment (usual clients would be VC++6 windows services, VB6 applications)
Any help would be appreciated!
Windows supports broadcasting messages, check here. You can SendMessage to HWND_BROADCAST from the service, and receive it in each client.
There are a number of ways to do a broadcast system, but you'll have to either give up reliability (ie, some messages must be lost) or use a proper subscription system.
If you're willing to give up reliability, you can create a shared memory segment and named manual-reset event object. When a new message arrives, write it to the shared memory segment, signal the event object, then close the event object and create a new one with a different name (the name should be in the shmem segment somewhere). Clients open the shmem segment, find the current event object, wait for it to be signaled, then read off the message and new event segment.
In this option, you must be careful to deal with the case of a client reading at the same time as the shmem segment is updated properly. One way to do this is to have two sequence number fields in the shmem segment - one is updated before the new message is written, one after. Clients read the second sequence number prior to reading the message, then re-read both sequence numbers after, and check that they are all equal (and discard the message and retry after a delay if they are not). Be sure to place memory barriers around accesses to these sequence numbers to ensure the compiler does not reorder them!
Of course, this is all a bit hairy. Named pipes are a lot simpler, but a subscription (of a sort) is required. The server calls CreateNamedPipe, then accepts connections with ConnectNamedPipe. Clients use CreateFile to connect to the server's pipe. The server then just loops to send data (using WriteFile) to all of its clients. Note that you will need to create addititonal instance of the pipe using CreateNamedPipe each time you accept a connection. An example of a named pipe server can be found here: http://msdn.microsoft.com/en-us/library/aa365588(v=vs.85).aspx