Did this article resolve your question/issue?



Suggested method of parsing the database log file to find out if a quiet point has been enabled

« Go Back


TitleSuggested method of parsing the database log file to find out if a quiet point has been enabled
URL NameP102939
Article Number000126968
EnvironmentProduct: Progress
Version: 9.1
Product: OpenEdge
Version: 10.1x, 10.2x, 11.x
OS: Unix Linux
Question/Problem Description
What is the best way to determine if the PROQUIET point has been enabled?
Suggested method of parsing the database log file to find out if a quiet point has been enabled
How to find out if PROQUIET -C enable has succeeded?
Why does a quiet point sometimes not get enabled immediately?
How to know if PROQUIET has been granted?
Steps to Reproduce
Clarifying Information
Error MessageQuiet point has been enabled by the broker. (5583)
Defect Number
Enhancement Number
When a user issues a PROQUIET command, a quiet point flag is set when an Enterprise Database License is in use. Customers with mirrored systems often break the mirror immediately after issuing the PROQUIET command or check for a success return code from the _mprshut executable. This can result in the mirror splitting before the quiet point has actually been enabled. One way to get around this limitation is to parse the database log file for the 5583 message before breaking the mirror.

The only caveat in using PROQUIET is that you must first check that the quiet was successfully started | stopped before undertaking any further operations against the database and not assume that it has been as soon as the "proquiet -C enable | disable" command has been run.

Unless there are specific reasons at the time that the "proquiet -C enable" cannot establish a quiet point, there is no point in running a script to query return codes other than 0 (success).  Once all the necessary latches to prevent any type of writes from the database have been acquired by the broker, we acknowledge through shared memory that the quiet point was enabled. This is communicated to the requester process and it is then free to print the enabled message (5583) and return to the (quiet point requester) user with an appropriate return code = 0. As soon as the user session has been granted the PROQUIET, it exits (453) and is no longer visible in (say) a:  ps -ef | grep "_mprshut -C quiet enable" | echo $?  There are no VST available to query the PROQUIET state.

For example:
QUIET   5: Quiet point request login by <user> on <ttyxxx>. (5569)
BROKER  0: Quiet point has been enabled by the broker. (5583)
QUIET   5: Logout by <user> on <ttyxxx>. (453)

One of the reasons that the (5583) may take longer than expected to return is because resources held by a dead user (for example) are not available until TCP/IP timeout's kick in or the Watchdog utility cleans these up. ie: a client that is holding an update TXE latch and causing the request for quiet point to wait as it should, by design, on the TXE latch being released. 

Parsing the database log file

Parsing the database lg file for matching message sets in a loop is suggested as the first step in finding out if the quiet point has been enabled:

Quiet point has been enabled by the broker. (5583)
Quiet point has been disabled by the broker. (5584)
  • If the result fails to return a favorable result after the set iterations, further investigation into what is causing the delay can ensue.  
  • The script snippet below will result in the entire database log file being parsed. 
  • It may be more beneficial to copy off the last days worth of log activity or make use of the UNIX tail command to capture the last 100+  or more lines and redirect them into another file.  The script could then be modified to run against this subset of data instead of the entire log file.

while true
q1=`more ${DBNAME}.lg | grep "(5583)" | wc -l`
q2=`more ${DBNAME}.lg | grep "(5584)" | wc -l`

if test $q1 -eq $q2
 then echo "DB does NOT have a quiet point"
 else if test $q1 -gt $q2
       then echo "quiet point HAS been enabled on the DB"
       else echo "DB.log's been shrunk or modified"
Last Modified Date11/20/2020 7:37 AM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.