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. .