ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Unable to run DLQ-Handler as a service

Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next
 Unable to run DLQ-Handler as a service « View previous topic :: View next topic » 
Author Message
saurabh25281
PostPosted: Mon Sep 30, 2019 5:17 am    Post subject: Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
Location: Bangalore

fjb_saper wrote:
you did not specify what the access to the rule file was...

-rwxr-xr-x 1 mqm mqm 2290 Sep 29 22:42 mq-dlh.rul
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 5:25 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

saurabh25281 wrote:
Please check my initial post. All the Linux/platform based consideration are taken care off.

Regards
Saurabh


Sorry, this was a (too) quick reply to your last post.


I've got a general remark:

A DLQH should run either

1. run once, process each message and stop then or

2. be permanently on the DLQ and process each incoming message.

I case "1." the DLQH should somehow be started - e. g. by a triggered DLQ. The service then could be of type "COMMAND" instead of "SERVER" - and a wrapper would work.

In case "2." your rule file needs a WAIT value, otherwise the DLQH would permanently run and use CPU.

When you ran the DLQH on the command line, this was like a "COMMAND SERVICE" would work - run once and end.


Another remark about processing the arguments - especially the "less" sign:

On Windows each program is responsible to handle control characters such as wild cards (e. g. "*") or redirection signs (e. g. "<"). On Unix this is done by the shell before passing these to the application.

So on Windows the behaviour depends on the applications and may differ for each app. On Unix the behaviour is the same for all apps (e. g. expanding of wild cards).

On Windows some characters are not allowed to be part of the file Name (e. g. "<", ">", "|", "*", "/", "\", ...). On Unix any characters except the slash are allowed.

So I assume, that on Linux the "less" sign is taken as a part of the file name and the service looks for a file named "</home/mqm/mq-dlh/mq-dlh.rul', which is not found on the system. On Windows the "less" sign cannot be a part of the file name and so the DLQH itself interprets this as a redirection request.

The Windows version of "runmqdlq" must interpret the "less" sign as a redirection request. The Unix version of "runmqdlq" does not interpret the "less" sign and needs even not to know about it. This is done by the shell.

So that your configuration works on Windows as you want, this is more a bug than a feature. It corresponds to the differences between Windows commands and Unix shells.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Mon Sep 30, 2019 5:50 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

I don't think you pasted the whole error you received; I just tried it on a test queue manager and got the same failure as you, except for:

Quote:
syntax error on line 1
...09/30/2019 02:32:13 PM AMQ8758E: 1 errors detected in input to runmqdlq.
09/30/2019 02:32:13 PM AMQ8709I: Dead-letter queue handler ending.


Something is wrong somewhere...

...so try it again with the sample rules file below:

Code:
RETRYINT(30) WAIT(YES)

REASON(MQRC_Q_FULL) ACTION(DISCARD) RETRY(5)
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)


_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 5:53 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

In other words:

On Windows the "<" and ">" are not shell redirections, but arguments to the application instead, which are interpreted by the application, to take the next argument as a file name, where the data is read from or written too.

On Unix the shell reads the content of the file following after the "<" sign and passes this content to the application. The ">" on the other hand means, that the Unix program sends the data to the shell, which this then writes to the file.

So on Windows the program (runmqdlq) opens the rule file and reads the rules from the file, whereas on Unix the program (runmqdlq) reads the data from standard input (stdin) - not from the file.

The Windows version of "runmqdlq" just simulates a shell redirection behaviour, which doesn't really exist in Windows.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 5:59 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

exerk wrote:
I don't think you pasted the whole error you received


It seems that saurabh25281 posted just an extract of the sample DLQ rule file in the knowledge center. I don't think, that this is the real rule file (unfortunately), saurabh25281 used.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
saurabh25281
PostPosted: Mon Sep 30, 2019 11:04 am    Post subject: Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
Location: Bangalore

exerk wrote:
I don't think you pasted the whole error you received; I just tried it on a test queue manager and got the same failure as you, except for:

Quote:
syntax error on line 1
...09/30/2019 02:32:13 PM AMQ8758E: 1 errors detected in input to runmqdlq.
09/30/2019 02:32:13 PM AMQ8709I: Dead-letter queue handler ending.


Something is wrong somewhere...

...so try it again with the sample rules file below:

Code:
RETRYINT(30) WAIT(YES)

REASON(MQRC_Q_FULL) ACTION(DISCARD) RETRY(5)
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)


I got exactly the same error. I used your .rul file and still got the same issue. Did it work for you using your .rul file?

HubertKleinmanns wrote:
exerk wrote:
I don't think you pasted the whole error you received


It seems that saurabh25281 posted just an extract of the sample DLQ rule file in the knowledge center. I don't think, that this is the real rule file (unfortunately), saurabh25281 used.
It doesn't matter what .rul file we use. The problem lies somewhere else, maybe related to "<" as you have pointed out. Strange that it is not documented by IBM after all these years.

Regards
Saurabh
Back to top
View user's profile Send private message Send e-mail Yahoo Messenger
gbaddeley
PostPosted: Mon Sep 30, 2019 4:57 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Quote:
On Windows systems, the last rule in the table must end with a carriage return/line feed character. You can achieve this by ensuring that you press the Enter key at the end of the rule, so that the last line of the table is a blank line.

I believe this statement is made because if you create a file using the Windows Notepad app, and do not press Enter after the last record, and save the file, there will not be CR LF line terminator characters on the end of the last record.
Hard to believe, but its true.
_________________
Glenn
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon Sep 30, 2019 5:03 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

HubertKleinmanns wrote:
...
On Windows the "<" and ">" are not shell redirections, but arguments to the application instead, which are interpreted by the application, to take the next argument as a file name, where the data is read from or written too.

On Unix the shell reads the content of the file following after the "<" sign and passes this content to the application. The ">" on the other hand means, that the Unix program sends the data to the shell, which this then writes to the file.

So on Windows the program (runmqdlq) opens the rule file and reads the rules from the file, whereas on Unix the program (runmqdlq) reads the data from standard input (stdin) - not from the file.

The Windows version of "runmqdlq" just simulates a shell redirection behaviour, which doesn't really exist in Windows.

Hi Hubert, you may wish to verify your statements about Windows. Windows programs can read data from standard input, just like UNIX programs. Such programs do not open any files, they just read from the stdin file descriptor. The command line arguments for "<", ">", ">>", "2>" etc are not visible to the program. The OS does the stdin & stout redirection under the covers. The same applies to "|" piping of stdin & stout between programs on the same command line.
_________________
Glenn
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 11:31 pm    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

gbaddeley wrote:
Hi Hubert, you may wish to verify your statements about Windows. Windows programs can read data from standard input, just like UNIX programs. Such programs do not open any files, they just read from the stdin file descriptor. The command line arguments for "<", ">", ">>", "2>" etc are not visible to the program. The OS does the stdin & stout redirection under the covers. The same applies to "|" piping of stdin & stout between programs on the same command line.


Ok, I've verified it. You are right : The command shell handles the redirection attributes on Windows too (but the shell doesn't handle the wildcards - so I'm partially right ).

But the main statement is, that the differences in the behaviour of "runmqdlq" aren't caused by the application, but by the operating system - especially the shell (at least for redirections). So sameone cannot expect the same behaviour.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 11:54 pm    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

saurabh25281 wrote:
It doesn't matter what .rul file we use. The problem lies somewhere else, maybe related to "<" as you have pointed out. Strange that it is not documented by IBM after all these years.

Regards
Saurabh


Hmm, IBM just doesn't mention, that redirections are not supported in the STARTARG or STOPARG attributes - but why should they? These are arguments to the program - and as I described earlier, redirection operators are not arguments to the program (and as I learned now, this is true for Windows too).

The define command gives you a hint:
Code:
def service

AMQ8427I: Valid syntax for the MQSC command:

  DEFINE SERVICE( service_name )
   [ CONTROL( MANUAL | QMGR | STARTONLY ) ]
   [ DESCR( string ) ]                     [ LIKE( service_name ) ]
   [ REPLACE | NOREPLACE ]                 [ SERVTYPE( SERVER | COMMAND ) ]
   [ STARTCMD( string ) ]                  [ STARTARG( string ) ]
   [ STOPCMD( string ) ]                   [ STOPARG( string ) ]
   [ STDOUT( string ) ]                    [ STDERR( string ) ]


So redirection of stdout and stderr is handled by separate attributes. Why do you expect, that this is different for stdin?

You could raise a RFE to add an attribute for stdin too.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
HubertKleinmanns
PostPosted: Mon Sep 30, 2019 11:59 pm    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

saurabh25281 wrote:
2. We want to trigger the runmqdlq directly, not as a wrapper, because we want to configure the stop service as well.
If we use a wrapper, the stop services is passed with the process id of the wrapper script which the MQ queue manager service amqsstop can't stop.


Why don't you create a wrapper script, which runs the DLQ in an endless loop (with waits between, to reduce CPU usage)? Then you could create a stop command, which just stops this wrapper script.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Tue Oct 01, 2019 3:21 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

No need for a stop command. Just get inhibit the DLQ and allow get again.
The get inhibit will stop the DLQ Handler... Generally, shutting down the queue manager will stop the DLQ handler...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
HubertKleinmanns
PostPosted: Tue Oct 01, 2019 5:44 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

fjb_saper wrote:
No need for a stop command. Just get inhibit the DLQ and allow get again.
The get inhibit will stop the DLQ Handler... Generally, shutting down the queue manager will stop the DLQ handler...


When you - as I suggested - run a wrapper script as a service and the wrapper script itself calls "runmqdlq" in a loop, you need a stop command for the wrapper script. Otherwise the wrapper script would run the DLQ handler again in the next cycle .
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Tue Oct 01, 2019 5:59 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

HubertKleinmanns wrote:
fjb_saper wrote:
No need for a stop command. Just get inhibit the DLQ and allow get again.
The get inhibit will stop the DLQ Handler... Generally, shutting down the queue manager will stop the DLQ handler...


When you - as I suggested - run a wrapper script as a service and the wrapper script itself calls "runmqdlq" in a loop, you need a stop command for the wrapper script. Otherwise the wrapper script would run the DLQ handler again in the next cycle .

The 'stop' command for the wrapper script is the GET(DISABLED) on the queue - my wrapper scripts ends when the DLQ Handler ends...

...but I'm not sure what you mean by '...calls "runmqdlq" in a loop...'.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
HubertKleinmanns
PostPosted: Tue Oct 01, 2019 6:09 am    Post subject: Reply with quote

Shaman

Joined: 24 Feb 2004
Posts: 732
Location: Germany

exerk wrote:
...but I'm not sure what you mean by '...calls "runmqdlq" in a loop...'.


My idea was, that the wrapper script calls "runmqdlq", waits a few seconds, calls it again, waits a few seconds, etc. Something like this:

Code:

while [ 1 ]
do
   runmqdlq ...

   sleep 5
done


This script wouldn't end when the DLQ has been GET(DISABLED). It would just call the DLQ handler again and again.
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3  Next Page 2 of 3

MQSeries.net Forum Index » General IBM MQ Support » Unable to run DLQ-Handler as a service
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.