I think we can bypass the platform problem by making a command executable generically
called. I wrote a small Java program as an example. I think it will work on Windows,
Solaris, Linux and AIX without any problem. But of course it won't work on OS/390
(and others) since the commands are not available. I just plan on having this type of
program triggered and first get the "cmd" from the request queue as a string and then
put the "output.toString" back on a reply queue. It's working for mqver, dspmq and
netstat (a big output test).
Still testing....
String cmd = ("mqver") ;
Process p = Runtime.getRuntime().exec(cmd);
InputStream pin = p.getInputStream();
BufferedReader br = new BufferedReader(new InputStreamReader(pin));
String line;
StringBuffer output = new StringBuffer();
while ((line = br.readLine()) != null)
{
output.append(line);
output.append("\n");
}
System.out.println(output.toString());
-----Original Message-----
From: Wyatt, T. Rob [mailto:[EMAIL PROTECTED]
Sent: Friday, August 22, 2003 1:27 PM
To: [EMAIL PROTECTED]
Subject: Re: mqver remotely? Maybe MO71?
Hmm...some new commonality across all our shops? At one time everyone was
writing wrappers around MQ. Now it seems many of us are writing agents to
do some of the things that IBM left out and more.
We have the luxury in my division of the company of having a pretty
homogenous shop. Almost all of my MQ servers are on platforms supported by
ActiveState Perl. We got a copy of the Perl Dev Kit and compile our agent
scripts so they can be deployed without regard to installation dependencies.
Our agent scripts provide access to the error logs and FDC files, run shell
commands (Win and Unix), set and display auths and can even receive and
deploy compiled exits. To get around platform inconsistencies and to add
security, the scripts do not run commands directly but instead take a
generic command ("deploy exit" for example) and translate it to the
appropriate system-specific action (copy to /var/mqm/exits or c:\program
files\...\exits").
Perl is great because the script can open and read our command queue and
write the responses directly to the response queue. The MQSeries Perl
module understands basic messages and PCF commands so it has direct access
to all the message fields and does not rely on AMQSGET/AMQSPUT. The script
can also execute shell commands directly without writing intermediate files.
After we bought AppWatch we showed our scripts to Reconda because we wanted
the functionality integrated. My understanding is that several agent
functions are planned for an upcoming release. Hopefully, IBM will still be
giving away copies (http://www-3.ibm.com/software/integration/mqreconda/)
when the new version comes out.
MSDW, the people who maintain the Perl MQSeries module, built a wrapper
around IBM's command server. Their wrapper intercepts PCF commands,
executes those it understands and passes the remainder on to IBM's command
server for processing. Their agent implementation makes ours look like
"Hello World".
IBM - take note! We are all out here writing agents to do things that
should have PCF equivalents such as dumping log files, getting the
version/CSD level, displaying auths and starting/stopping components. I
know there is a formal request process for this but I also know you all take
notice when a substantial part of the community starts writing the same
enhancement to the base code.
-- T.Rob
-----Original Message-----
From: McCarty, Brian [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 6:25 PM
To: [EMAIL PROTECTED]
Subject: Re: mqver remotely? Maybe MO71?
You say that you built a script that started by triggering and then reads
the application queue that has messages that the body contains a command to
run? Just looking for clarification because I think we would like to do
this also for more than just mqver. Does the script actually call a program
that does the get then put (of the command output)?, or did you write the MQ
part into the script also?
Did you have any other problems or gotcha's that we should look for?
Thanks in advance for any other input.
B
-----Original Message-----
From: John Matoba [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 11:03 AM
To: [EMAIL PROTECTED]
Subject: Re: mqver remotely? Maybe MO71?
We created a script that is triggered by an MQ message and assumes the
message body contains a unix command. When the script is triggered, it
runs the unix command and returns the output in a reply message. From a
hub queue manager, we can send an mqver command to all our queue
managers and generate a report of all the version info on all our queue
managers.
Such a script is fairly simple to write and as you might imagine, is
quite useful in centrally issuing other unix commands.....
John Matoba
Information Systems
Northwestern Mutual Life
414-665-4160
-----Original Message-----
From: Peter.Potkay [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 10:02 AM
To: MQSERIES
Subject: Re: mqver remotely? Maybe MO71?
Paul, I am forwarding your reply to my IBM rep Tom Kruczek. Maybe he can
push this request over to Hursley officially.
-----Original Message-----
From: Paul Clarke [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 21, 2003 10:50 AM
To: [EMAIL PROTECTED]
Subject: Re: mqver remotely? Maybe MO71?
>Is there anyway to get the MQ version of a box without having to
actually
>log onto the box? MQExplorer? QPASA? MO71?
>It is a pain having to log onto individual boxes just to run the mqver
>command when you want to see what CSDs have been applied.
>Paul, would there be anyway for MO71 to do this in a future version?
MO71 pretty much only talks to the command server, this is so it doesn't
require an agent running on the target machine. Consequently if you want
MO71 to be able to tell you the CSD level it really means that we need a
command server version of the MQVER command. It doesn't seem an
unreasonable requirement to me to have one added but this isn't really
my
area.
Cheers,
P.
Paul G Clarke
WebSphere MQ Development
IBM Hursley
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy
all copies.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
