There are currently four RTV* commands that provide either system wide or data group level status data.
RTV Functioning normally
RTV Apply session not active
RTV Apply session backlog
RTV Data group status not active
RTV Communications failure
RTV Data area poller not active
RTV Database apply not active
RTV Database send not active
RTV Database send backlog
RTV File entries held error
RTV File entries not active
RTV Files not journalled on source
RTV Files not journalled on target
RTV IFS entries held error
RTV IFS entries held not error
RTV IFS entries not active
RTV IFS entries not journalled on source
RTV IFS entries not journalled on target
RTV Object entries held error
RTV Object entries held not error
RTV Object entries not journalled on source
RTV Object entries not journalled on target
RTV Object send not active
RTV Object send backlog
RTV Object retrieve not active
RTV Object retrieve backlog
RTV Container send not active
RTV Container send backlog
RTV Status send not active
RTV Object apply not active
RTV Object apply backlog
RTV Objects failed distribution
RTV Failed object entries
RTV Object beyond retry duration
User supplied values allow you to write programs to add new data types to the monitor. You can have as many user supplied values as you like.
You write a program that fetches the data required. The program should use command MONAPUPD or MONTXUPD to pass the value to the monitor. Use MONAPUPD for numeric elements and MONTXUPD for text items.
Between collections, use the command MONAPWAT to wait for the next collection cycle.
Here is a minimal example program to demonstrate the idea:
DCL VAR(&INC) TYPE(*DEC) LEN(15 5) /* Increment amount */
DCL VAR(&VALUE) TYPE(*DEC) LEN(9 2)
LOOP: MONAPUPD VALUE(&VALUE)
MONMSG MON0000 *N RETURN
CHGVAR &VALUE (&VALUE + &INC)
This program simply accepts an amount by which to count and keeps adding that value to the current value of the element.
Note the MONMSG for message MON0000 on the MONAPWAT command. MONAPWAT will issue an escape message when the monitor is ended. The program should monitor for this and end as shown.
Once your program is ready, create a new element in the usual way. Select one of the user supplied data types:
In the above example, we've attempted to show how the QSystem Monitor definitions could be used to monitor the size of a critical file within the MIMIX application. If this were a history file then automation could be used to purge the file when the threshold was reached.
In the above example, we've attempted to show how the QSystem Monitor definitions could be used to monitor that critical jobs within the MIMIX application are active and running under the correct profile and in the correct status. If any jobs are not in their required status a message is sent in addition to the visual and audible alarms.
The disk summary allows the user to group together libraries into applications. In the above example, you can see how this could be used to monitor the size of the MIMIX application/data group.
Both the Disk Summary and History Summary modules have a multi-print option which allows you to compare the statistics of a number of systems on the one graph. In the above example, you can see how this could be used to compare the size of the PRODUCTION application on two systems.
Here we can see how the QMessage Monitor Event Monitor can be used to ensure that critical jobs complete by a designated time. In this instance, a message is sent to warn the operators that the job has not yet completed; an alternative approach might be to start an escalation procedure.
Here we have a simple escalation procedure that can either be attached to a message ID or an event, or started manually by an operator. The procedure will page two users, waiting five minutes between each page for the user to reply. If the message is still unanswered after this period, the product will issue a default reply.
Here, one simple specification will prevent all messages up to and including severity 30 from being forwarded to the operators screen.
Here, we've defined MMX0006 as an automatic response. In the second image, we've identified the fact that we want this message forwarded to the central console and have also made it an inquiry message within QMessage Monitor.
In addition to that, we've also indicated that we wish to run the escalation procedure MMXSUPPORT when the message arrives as shown in the third image.
This is how the message would appear to the operator viewing the console whilst the escalation procedure is running:
QRemote Control allows customers to write their own programs that can retrieve information and send it as an SMS message to a mobile phone. An example within a MIMIX application could be to retrieve the status of the Journal Manager as shown above.
Still have questions? We can help. Submit a case to Technical Support.