S-Series systems are not configured with the number of processors expected in the system. From a system configuration perspective, the operating system is always ready to accept (software wise) a maximum of 16 processors.
MOMI, when first started, uses the numerically highest 'up' processor in the system as the number of processors for up/down determination. For example, if the numerically highest 'up' processor is 5, which indicates 6 CPUs numbered 0 through 5, and processor 4 crashes, processor 4 is reported as down.
Additional processors added to the system while MOMI is operating automatically increase the numerically highest 'up' processor determination. In the above example, if an additional two processors were added, processors 6 and 7, MOMI now assumes the system is 8 processors numbered 0 through 7.
This determination is made every time MOMI is started.
Byte rates for Expand lines are generally only available for Expand over TCP/IP . Byte rates for other types of lines such as Expand over X.25 are estimated by using the Frame rate times the average bytes per frame. Expand over Fox and Supercluster (Expand over ServerNet which is reported as a NAM connection) do not provide a byte rate.
The MOMI PC Client screen Enscribe / Locks does not function on systems prior to G06.26 as a precaution to prevent a possible CPU halt when using the Guardian procedure FILE_GETLOCKINFO_.
Operating Systems prior to G06.24 do not provide the exact Operating System version as known by Users (i.e. G06.21) via supported system calls. You can determine the major portion (i.e. G06), but not the minor portion (i.e. .21). The documented System procedure call PROCESSOR_GETINFOLIST_ has an item code defined to return the minor version number, but it always returns zero. To work around this limitation MOMI reads an undocumented file $SYSTEM.SYSNN.RLSEID. This file appears to be used by the utility SYSINFO and by TACL to obtain this information.
On Operating Systems G06.24 and later, the documented System procedure PROCESSOR_GETINFOLIST_ correctly returns the minor version number. The undocumented file $SYSTEM.SYSNN.RLSEID is not accessed.
The TNS/E Integrity System must use the RLSEID file. This may be removed in a future O/S release.
Secondary partitions on SQL/MP files do not always show up under this measurement. This is due to MEASURE not providing data. Try the DiskOpen Entity in this situation.
The SQL/MP screens may display various SQL error codes, with 4060 as the most common. The appearance of these codes may indicate a discrepancy in the SQL catalog itself. MOMI assumes that the catalog structure and data within the catalog has full integrity.
In the PC Client, on the SQL/MP / Catalog screen, the column Status Message shows an error code if a simple query of that catalog fails. Any Status Message displayed here indicates that MOMI will have problems with SQL/MP reporting. This is the first place to check and perhaps identify the catalog in question.
We suggest consulting with your DataBase Administrator (DBA) if you have any integrity issues with your SQL/MP catalogs.
Below are some additional steps you can perform to check your catalog integrity. From a TACL prompt:
1) SQLCI GET CATALOG OF SYSTEM;exit
2) Volume to this location.
3) SQLCI SELECT * FROM CATALOGS;exit
4) The first column (CATALOGNAME) in the output consists of all of the catalogs on your system registered to SQL. For each of those entries do a fileinfo of the $vol.subvol.*
5) If a $vol.subvol is listed in the CATALOGS table that does not exist, or does not contain SQL catalog objects, an inconsistency is present. Consult with your DBA and/or HP to resolve the problem.
If your SQL/MP catalogs do not show a problem, please send us an email with a screen shot and description of the SQL/MP error encountered.
Virtual memory configuration and statistics are not available from either the Guardian Operating System procedures nor MEASURE. To work around this limitation, MOMI starts a copy of NSKCOM and periodically parses its text output to determine the amount of virtual memory available, the highest usage (i.e. high water mark), and the current usage.
Some users have reported that they were unable to alter the virtual memory on their system due to NSKCOM reporting:
"... ZSYSCFG is locked by another user..."
Note: The file in question is really $SYSTEM.SYSTEM.KMSFLOCK
They corrected this problem by stopping MOMI, making changes via NSKCOM and then restarting MOMI.
MOMI does not make any changes to virtual memory but just uses NSKCOM for 'reading' virtual memory status. However, we believe this situation may occur if a delete of a swapfile is pending after a system cold-load and the NSKCOM started by MOMI is the first instance of this utility.
The suggested work-around is to start an NSKCOM, under a super.group user id, rather early in your system startup files after all processors have been loaded but before MOMI is started. The purpose of this NSKCOM is to cleanup any pending operations after the cold-load. It is possible that the pending operation may take some time if a great deal of cleanup is involved. A simple command to consider in your system startup file is:
NSKCOM EXIT == (start NSKCOM and simply exit)
Another work-around is to not run MOMI in the super group (i.e. .super.*).