| Author |
Message
|
| saurabh25281 |
 Posted: Mon Sep 30, 2019 5:17 am Post subject: |
 |
|
Centurion
Joined: 05 Nov 2006
Posts: 108
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 |
|
 |
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 5:25 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Mon Sep 30, 2019 5:50 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 5:53 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 5:59 am Post subject: |
|
|
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 |
|
|
| saurabh25281 |
| Posted: Mon Sep 30, 2019 11:04 am Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 108
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 |
|
|
| gbaddeley |
| Posted: Mon Sep 30, 2019 4:57 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| gbaddeley |
| Posted: Mon Sep 30, 2019 5:03 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 11:31 pm Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 11:54 pm Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Mon Sep 30, 2019 11:59 pm Post subject: |
|
|
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 |
|
|
| fjb_saper |
| Posted: Tue Oct 01, 2019 3:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
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 |
|
|
| HubertKleinmanns |
| Posted: Tue Oct 01, 2019 5:44 am Post subject: |
|
|
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 |
|
|
| exerk |
| Posted: Tue Oct 01, 2019 5:59 am Post subject: |
|
|
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 |
|
|
| HubertKleinmanns |
| Posted: Tue Oct 01, 2019 6:09 am Post subject: |
|
|
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 |
|
|
|
|
