This a follow-up based on MQ (Websphere 7) persist message to file system.
How do you set up an .exe program from an MQ support pack (such as the Q utility in MA01) to execute each time a message is received? Can this be setup in MQ Explorer? (We are using 7.0 on Windows 2008/R2).
There are a few ways to do this.
Set the application up under Windows control (since you mentioned the QMgr is on Windows.) The app would run as a service, with recovery options to restart it if the service fails. The application would be programmed (or configured in the case of Q) to process the queue using GETs with a VERY long wait period. Some additional error handling is required to do something sensible when the QMgr is not available. This works great for copying messages to multiple queues but isn't appropriate for queue-to-file since the file would never close.
Run the application as a WebSphere MQ service. Defining the SERVICE object using CONTRIL(QMGR) causes MQ to start the service when the QMgr boots and stop it when the QMgr is shut down. Since the service is a child process of the QMgr, no need to worry about how to handle errors when the QMgr isn't available.
Trigger the program based on non-zero queue depth. Define a process object describing the command to be executed, enable triggering on the queue with TRIGTYPE(FIRST) and run a trigger monitor. Whenever the queue has depth > 0 and no open input handles, the process object fires and executes the command. The thing you start must know how to parse the command line so the easiest thing to do if you have someone else's executable is use a script to start it. The script parses the trigger message and fires off the executable. Or perhaps the script ignores the trigger message and just runs the exe. I generally use Korn Shell or Perl and both are available on Windows.
I wrote an article showing how to keep event queues from filling using a triggered version of Q. The article assumes you want the queues to remain mostly full so uses triggering on depth of about 80%. The same techniques could be used (in a much simpler implementation, by the way) to fire off the Q program whenever the queue depth became non-zero.
UPDATE
Probably should have linked the article. ;-)
Mission:Messaging: Easing administration and debugging with circular queues
Related
When do I need a message loop in a Windows application?
For example, for a Windows service do I need a message loop for every thread that I created or just for the main service process?
while(true)
{
GetMessage(&messageHandle, 0, 0, 0);
DispatchMessage(&messageHandle);
}
Every native Windows programs contains at least one message loop (often called a "message pump") like the one you give an example of.
This is to enable the handling of Windows events initiated by the program itself, other applications or the operating system.
Example of Windows events can be for timers, socket communication, GUI actions, clipboard, etc.
Many APIs and frameworks implement a message loop for you. This will depend on what you are using in your particular case.
(Check the answers in this Stack Overflow question for more information on message loops/message pump.)
Now to the gist of your question: many or most programs will work fine with one message-loop. The cases where you would want more than one is typically if processing a Windows event can take a long time (i.e. it locks the current thread) and there are requirements that require you too keep processing new window events. I can think of two concrete examples:
One is in a GUI application where you're showing a modal dialog (which usually freezes the main message pump and spins up a new one for the dialog)
A service of some kind where processing of I/O events can take a long time because of external dependencies and timeliness of processing of new I/O events is critical
In (1) this is very often a consequence of the GUI framework you are using and not something you have to do explicitly. In (2) a better way of handling it would be to asynchronously "do the work" of each event rather than blocking the message pump.
In conclusion: it depends. :-) In most cases you shouldn't need to use more than one message loop, but if you have to, do it!
Apps:
Essentially, when the thread is going to create and manage windows. This includes 'hidden' windows that support COM STA and the like.
No windows, no windows messages, no message loop required.
Services:
Service manager needs to handle the service messages, and so requires a service message loop for Start/Stop/whatever.
For other threads started in a service, no message loop is required.
We have a system where there are typically two processes running on the same system. One process handles the GUI and the other runs like a service (although for historical reasons, it's not a service, just an exe with no visible window).
The two processes undertake IPC mainly via registered messages asynchronously - i.e. we use RegisterWindowMessage() in both processes to define a large'ish set of messages that effectively form the API to the server process.
I have written a "hands-free" monitoring application that uses SetWindowsHookEx() to monitor and display the message queues of both processes and provide some level of decoding of the way the API is being utilised and how notifications are being propagated to the GUI process (each individual window can subscribe to notifications from the server directly).
So, there are a large number of messages in both directions so I have filtering and summary counts etc. so I can focus on particular activity. All this can be done without affecting the live code, which is good.
This all works well, but it now would be very useful to be able to "tag" a message originating in the GUI so I can trace the same message when it's processed by the server. This would be enormously useful for debugging and diagnosing system issues, but I can't find a clean way (actually I can't find any way!) of doing this without adding such support to our registered message API, which would be a lot of work and involves more risk than I'm comfortable with at the moment. It gets further complicated by the fact that the server pre-processes some messages and then does a PostMessage() back to itself to perform the action, so the originating message can get "lost".
Has anyone here tackled this type of problem? If so, can you give me some pointers? If not, then are there any documented or undocumented ways of adding a small block of data to a Windows message and retrieving it later? I've looked at SetMessageExtraInfo() but that seems to be per-queue rather than per-message.
FindWindow or FindWindowEx will give you the details of the GUI Window. Compare the details with message intercepted
I want to check the status of a Mainframe CICS region whether it is active or inactive by using a JCL or it is even better if one can suggest me a way to check the status of the CICS region through a shell script. This script/JCL will be used to send a mail to a group saying that the region is active/inactive at a scheduled time.
Please help me with the PROC/UTILITY to be used incase of a JCL or help me with an example of shell script to achieve it
Solution:
I executed the below command on the main screen
TSO STATUS <job-name>
and it gave me whether the job is running or not not. I have executed the same TSO command in my job and taken the output into a dataset.
Just thinking about this briefly I see three alternatives, all involve use of SDSF (System Display and Search Facility).
SDSF in batch
SDSF from Rexx
SDSF from Java
Note that not all mainframe shops license SDSF, which is an IBM product. There exist ISV alternatives; I am aware of these but unfamiliar with them.
If this were being done in the shop where I work, I'd establish an SSH session with the mainframe and submit a batch job to execute the Rexx code described at the link. The batch job could check the status of the CICS region and send the email. My preference comes from having done all those things previously, I've just not put them together like this.
Your mainframe folks may have a ban on Rexx, or not allow SSH connections to their machine, or be unwilling to set up the Rexx interface to SDSF. They may feel similarly about Java.
There may be security implications, the logonID and password will be in your script, yes? What will that ID be authorized to do? How will the script be secured? Is the password for the ID required to expire periodically?
All of which is to say that you must work with (probably multiple) mainframe staff in order to make this process function correctly. None of these questions is designed to stop you from accomplishing your goal; your goal must be accomplished without compromising system security and integrity.
Some other things to think about...
Why are you checking to see if the CICS region is up? If it is because, (e.g.) you will begin a batch process to send messages to the region if it is up and notify someone if it is down, then you are best served building the error handling into your batch process instead.
Mainframe shops typically have some automation software in place to notify people when a significant event occurs - bells ring, lights flash, pagers go off, emails are sent, etc. Maybe what you're trying to do is already being handled in a different manner.
A couple of other options:
You can also run the Status (ST) command - just run TSO background (IKJEFT01) and issue the status command see Status command for the appropriate job names.
You could try running a Cics Command from a batch job see Batch Cemt New copy. If it works CICS is up, fails CICS is not up, I would suggest an inquiry rather than a New Copy though.
One method is to add a job step to the CICS region. Define this job step to ALWAYS run, or even better define it to run ONLY if the CICS job step fails.
In this job step invoke the program that sends e-mails to everyone in the interested parties group.
This way, when the CICS region abends everyone gets a notification, but if the job is brought down cleanly as part of regular operations, no one gets an e-mail.
Alternatively, you might want to always send out an e-mail when the region comes down regardless of the reasons.
This solution avoids having to poll the region to see if it is up. For example, what happens if the region name is changed? The scripts have to be changed! Or what if a second or third production region is added? Again, all the scripts have to be changed.
Finally, you could add a step zero to the region so that everyone gets notified when the region comes UP!!
I need one way IPC method for 2 Windows applications (both on the same machine).
Which one is better in case that my applications are CLI based + windows service.
P.S. I've implemented message queue in destination process (CLI application) in separate thread. And posting my message from source process (GUI application) via PostThreadMessage.
So. When both applications were run from the same user - everything is OK. When I'm running my destination application via Task Scheduler under Local Service user I'm getting 1444 error code (Wrong Thread ID).
Any ideas?
P.P.S. From MSDN
This thread must have the SE_TCB_NAME privilege to post a message to a thread that belongs to a process with the same locally unique identifier (LUID) but is in a different desktop. Otherwise, the function fails and returns ERROR_INVALID_THREAD_ID.
This thread must either belong to the same desktop as the calling thread or to a process with the same LUID. Otherwise, the function fails and returns ERROR_INVALID_THREAD_ID.
So. I should determine how to setup SE_TCB_NAME to my thread from my source process.
WM_COPYDATA message or custom message code (if you don't plan to transfer text or binary data) would work. WM_COPYDATA message lets you transfer binary data and Windows does copying across process boundaries itself.
In GUI -> CLI application you would need to create an invisible window in CLI process to receive messages (if you want messages to be SENT and not POSTed from the GUI application). If you just POST messages from GUI to CLI, then PostThreadMessage() function would be enough and there's no need for a window.
In CLI -> GUI direction there are no complexities at all as the window is already (usually) present in GUI application.
There is also nice solution - Message Queue from boost library.
I need to track to a log when a service or application in Windows is started, stopped, and whether it exits successfully or with an error code.
I understand that many services do not log their own start and stop times, or if they exit correctly, so it seems the way to go would have to be inserting a hook into the API that will catch when services/applications request a process space and relinquish it.
My question is what function do I need to hook in order to accomplish this, and is it even possible? I need it to work on Windows XP and 7, both 64-bit.
I think your best bet is to use a device driver. See PsSetCreateProcessNotifyRoutine.
Windows Vista has NotifyServiceStatusChange(), but only for single services. On earlier versions, it's not possible other than polling for changes or watching the event log.
If you're looking for a user-space solution, EnumProcesses() will return a current list. But it won't signal you with changes, you'd have to continually poll it and act on the differences.
If you're watching for a specific application or set of applications, consider assigning them to Job Objects, which are all about allowing you to place limits on processes and manage them externally. I think you could even associate Explorer with a job object, then all tasks launched by the user would be associated with your job object automatically. Something to look into, perhaps.