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. Hardware System interconnects such as Expand over Fox and Supercluster (Expand over ServerNet) do not provide byte rates.
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.
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.