MONVER Users Guide
A Utility to Monitor Memory Locations
Table of Contents
1.0 What is MONVER?
1.1 Installing MONVER
1.2 What MONVER reports
1.3 What Does it Mean?
1.4 Important Notes
1.0 What is MONVER?
MONVER is a diagnostic tool to aid in isolating the source of
random occurrences where stable memory locations change.
Originally, MONVER was developed to isolate occurrences of
the monitor version number getting changed. Usually the monitor
version gets changed as a result of a pointer not being
initialized when a program expects it to be. This can happen
when an XCALL has return status and the program did not provide a
variable to pass it in. It can also happen if a terminal driver
is swapped in place of one with no IMPURE area.
1.1 Installing MONVER
MONVER requires a background job to run under. A small job
with a pseudo terminal attached (much like the old spooler) will
do the trick. The job should have about 10k of memory and must
be logged into OPR:
MONVER will create a file called MONVER.DAT in OPR: This
file will receive all statistics when the location changes. It
is appended to every time the specified location changes thereby
giving you a history of occurrences.
MONVER command format is as follows:
MONVER{/sw} {location}{/sw}{/R times}
'sw' stands for one of the following switches:
/B monitor a byte
/W monitor a word (2 bytes)
/L monitor a longword (4 bytes)
/R Reset address and rerun itself.
Switches may be placed before or after {location}. Location
is the absolute address in memory you with to monitor. This
should be in octal.
Please note when using the word option the address must
reside on an even address (i.e. 0,2,4, etc.). Likewise, when
using the longword option the address must reside on an even
LONGWORD address (i.e. 0,4,10, etc.).
If you do not specify {location}, MONVER will default to
0(ABS) (monitor version area). You must specify a switch of
either B,W, or L for byte,word, or longword or MONVER will not
run.
If you use the /R switch, MONVER will report the address
corruption in the MONVER.DAT file, reset the value at the
specified memory address to what it was before it was corrupted
and then restart itself to test that address again.
Using /R with a numeric argument, as in /R 5, will result in
MONVER resetting itself 5 times before it aborts to the dot.
If you do not use a numeric argument or use 0 as the numeric
argument, MONVER will reset itself forever. Be aware that if you
have a program that is running constantly and is constantly
corrupting the address at the specified memory location, it is
quite possible that you could fill up your disk device with the
reported information when using infinite reset.
To install MONVER the following must be performed in a
TEST.INI file:
Increase JOBS statement by 1
Add a job allocation:
JOBALC MONVER
Add a terminal definition:
TRMDEF MONVER,PSEUDO,NULL,25,25,25
After the final SYSTEM command add:
ATTACH MONVER,MONVER
KILL MONVER
FORCE MONVER
MEMORY 10K
LOG OPR:
(note: add password and/or user name here)
MONVER{/sw} {location} {/sw}{/R times}
<--
WAIT MONVER |
(note the blank line) ----
1.2 What MONVER Reports
MONVER stores various information regarding job context and
program information to the disk file DSK0:MONVER.DAT[1,2] when it
finds the location it was monitoring has changed.
The location is monitored at interrupt level via a TIMER
call. On AMOS 2.0 and later, the location is also checked at
every context switch by the job scheduler. When the location
changes, MONVER interrupt level stores information regarding run
time and wakes up the user level section. The user level section
then writes this information to the disk file and sends a message
to the master terminal noting the change.
The following information is stored in the disk file:
1. date of change
2. time of change
3. size being monitored (byte,word,longword)
4. If reset is active (Yes/No)
5. location being monitored
6. what location was
7. what location changed to
8. who found change (interval timer or context switch)
9. job in control at time of change
10. program the job was running
11. last run block 'FETCH' executed by this job
12. if in RUN or ORUN, the last XCALL that was fetched
by BASIC.
1.3 What Does it Mean?
If jobs seem to be random, and programs are random, or you
have reports of 'no job context', the problem may be in an
interrupt level routine, such as a terminal, interface, or disk
driver. If you are on versions of AMOS prior to 2.0 the context
switch check is not operational. This means that jobs which
enter a wait state right after the corruptions could display the
above behavior. You should allow MONVER to trap further
occurrences. A program being trapped just a bit more often than
the rest could be suspicious. You can use the /R switch to
enable MONVER to reset the memory value and restart itself again.
MONVER will report if reset is set or not by outputing "Yes"
in the -reset- field if the memory value was reset or "No" if the
memory value was left corrupted. MONVER will also be "at the dot"
if reset is not set after it has found a corrupted memory address.
MONVER reports before and after values. Examination of these
values could give you an idea of the data being stored in the
monitored location and hence the program at fault.
The job currently running is reported. In most cases MONVER
is able to examine the location while the job that caused the
problem is still in the run state. This means that, although not
foolproof, the job reported is usually accurate. On AMOS 2.0 or
later this is even more accurate as the location is also checked
at the time of context switch.
The last fetch that occurred which uses the JOBRBK area is
logged. This area is used almost exclusively by the command
processor. The only time this area is typically different from
the 'PROGRAM' reported is in RUN or ORUN where the .RUN name is
listed in the program name area. If the application makes use of
the JOBRBK area, it may be different also.
If the last fetch that occurred was RUN or ORUN, MONVER will
attempt to report the last XCALL that was called by Basic. If
you have reports of an XCALL occurring often, it may not be a
fault in the XCALL. Examine the statements in the reported Basic
programs that invoked the XCALL. You may find that the XCALL is
expecting a variable listed for a status code and the application
did not provide one. XCALL is not filled out for RUNP (BASIC
Plus) as this information is not accessible to MONVER.
1.4 Important Note
MONVER has two internal sections. One runs at user level and
spends most of its time in external wait (EW) state. The other
runs at interrupt level. The interrupt level section is
transparent to the rest of the system.
As of AMOS 2.2C(452)-13 MONVER.LIT 1.2(105) will not work and
may lock your system up due to changes in the monitor. MONVER.LIT
version 1.2J(105) and greater will work on versions of the AMOS
operating system 2.2C(452)-13 and greater.
DO NOT try to use any job reset program on MONVER. In
general job reset programs are dangerous. Not all system
resources are tracked when a job requests them. Doing so would
result in a system spending more time juggling queues than
processing data. Improperly aborting a job to monitor may
leave some of these resources in a locked or invalid state. This
could result in almost any result, from system crash to data
corruption.
One result with MONVER is predictable should a job reset
program be used. The first operation done in that memory space
WILL crash the system. So, DON'T USE A JOB RESET PROGRAM ON _____________________________________
MONVER.
