Kbase P103326: Suggested method of parsing promon output to find out if a quiet point has been enabled
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
7/20/2007 |
|
Status: Verified
GOAL:
Suggested method of parsing promon output to find out if a quiet point has been enabled
GOAL:
How to find out if proquiet -C enable has suceeded?
GOAL:
Why does a quiet point sometimes not get enabled immediately?
GOAL:
Quiet point has been enabled by the broker. (5583)
GOAL:
How to know if a proquiet point has been granted ?
FACT(s) (Environment):
UNIX
Progress 9.1E
OpenEdge 10.0B
OpenEdge 10.1x
OpenEdge 10.2x
FIX:
The only caveat in using proquiet is that you MUST check that the quiet was sucessfully 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, because once all the necessary latches to prevent any type of writes from the database have been aquired 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 $? Moreover, at the time of writting, 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.
In Progress 9.1E and OpenEdge 10.0B the promon activity screen has been enhanced to show *** Quiet Point is Active ***. So a shell script can be created to detect this in a loop is suggested as the first step in finding out if the quiet point has been enabled. If the result fails to return a favourable result after the set itterations, further investigation into what is causing the delay can ensue.
For example:
<shellsnip>
#quiet.sh
DBNAME=dbname
LOOPTIME=10
while true
do
qp=`promon $DBNAME < ./keys.txt 2>/dev
ull | grep "*** Quiet Point" | wc -l`
if test $qp -eq "0"
then echo "no quiet point"
else echo "quiet point's active"
fi
sleep $LOOPTIME
done
</shellsnip>
#keys.txt
5
q
q