Update for MCP 60 Preparation for post 2035 changes to time(6) format
If a database was to be ignored due to the setting of the DBC_RESTRICTED config variable, a message of: DBCONTROL WILL NOT BE RUN DUE TO COMPRESONLY SETTING The message displayed is now: DBCONTROL WILL NOT BE RUN DUE TO DBC_RESTRICTED SETTING
CompResOnly referred to an earlier method of restricting databases.
Values on the Database Performance Analysis screen which were greater than 99999999 were truncated. Values greater than 999999999 are now divided by 1000000 and displayed with a suffix of M. Values between 1000000 and 999999999 are divided by 1000 and displayed with a suffix of K. Values less than 1000000 are display with a suffix of W.
The default values of CUMAX and CUMIN may now be set via config variables DBC_CUMAX and DBC_CUMIN. These will be added to the Install program at a later date but may be set via Supervisor at present.
Eg TT / ($DBC_CUMAX.CONFIG:="123456789") TT / ($DBC_CUMIN.CONFIG:="54321")
Previously CUMAX and CUMIN could only be set to 10 digit numbers, whether via AX to the Monitor program. 12 digit numbers are now accepted.
This minor change reflects that DBCONTROL is compatible with MCP 58.1
Change ACONLY default to True for new trials.
Increase CUMIN and MAX defaults.
This minor change reflects that DBCONTROL is compatible with MCP 54.1.
DBCONTROL will now recognise the effects of a SM STATISTICS RESTART command issued to any database. As this command causes many counter values (such as transactions, forced and normal overlays) to be reset to zero, DBCONTROL would insert incorrect sample values into its statistics file and show negative values for the memory statistics displayed in a DBCONTROL monitor window.
This problem has been fixed; DBCONTROL will now recognise that the counters have been reset and adjust the statistics accordingly.
This change fixes a display problem on the DBControl monitor window. On some systems, some decimal values displayed with the first digit after the decimal point shown as U with an umlaut. This problem has been detoured.
Previously, it was possible for DBCONTROL to erroneously call a MAGUS entrypoint to track critical waiting entries (such as WORDS REQUIRED) instead of checking for these entries itself. This only occurred under circumstances where a second DBCONTROL was manually run whilst another copy was already active and running correctly. This behaviour caused DBCONTROL to give multiple programdumps with the message:
DBCONTROL: FAULTED IN GETSTATUS RSVP HANDLING
The problem would only occur while there was more than one waiting entry active.
Previously, DBCONTROL would give the following MCP warning during MCS initialisation:
"Warning 146: MCS may not be able to handle data returned in MCS"
This warning has now been eliminated; DBCONTROL functionality and operation is otherwise unaffected by this change.
Previously, DBCONTROL could have taken a maximum of the INTERVAL time (Default 2 minutes) to detect the initiation of a new database. Now, DBCONTROL uses database freeze SUMLOG entries to detect new initiations in real-time, triggering efforts to link to new databases to commence monitoring.
On very busy systems, it may be possible for DBCONTROL to occasionally fail to link to a new DMSUPPORT library as it may not yet be active; on these occasions, there will be the usual INTERVAL delay before database monitoring can start, as in the previous implementation.
The change described in DNote 510.02 caused ALLOWED and CURRENT core statistics to be displayed as real values instead of integer in DBCONTROL's statistics screen for an individual database. This would occur if the number of samples per time slot was greater than 1 and has now been changed to again only show the averaged values as integers.
DBCONTROL now supports the fine tuning change for database and system overlay rate handling, as described in MAGUS DNote 510.04. This change will now depict both system and database overlay rates to two decimal places in the statistics files and in the various DBCONTROL monitor screens. Theses changes allow DBCONTROL to better respond to system and database overlay rates that were actually non-zero but regarded by DBCONTROL as zero.
This is an internal change to reflect 5.1 MCP compatibility and to default DBCONTROL handling of mix numbers to a MORETASKS environment. This changes all GETSTATUS and SETSTATUS calls to use type 6 calls instead of type 0.
When DBControl keys expire. DBControl will now continue to run but in 'Restore' Mode. A DBControl task will run for any database coming into the mix, but the only action it will take is to restore the database parameters to the value they had before DBControl adjusted them. The Restore file for a database is removed after the database is restored. For any subsequent run of the database DBControl will report that the restore was not done , due to a missing restore file.
The NORESTORE option can now be reset using the syntax AX NoRestore -
DBCONTROL will now use the maximum of a database's current ALLOWEDCORE setting and the default CUMAX (500000 words) when run against a database for the first time. This allows databases with very large ALLOWEDCORE settings to be assigned reasonable CUMAX values after DBCONTROL installation.
This change is only to change the version number to 48. Version 470.08 is valid on MCP 48.
If there were more than 255 databases in the Mix then DBControl could fault with an invalid index. This restriction has been removed.
The changes in Dbcontrol 470.05 and 470.06 affected the search mechanism used for linking to DMSUPPORT libraries on MCP 45.1 or earlier. The DBCONTROL son would subsequently abort with CANNOT FIND DMSUPPORT library. This problem, which did not occur on MCP 46.1 or later, is now fixed.
As part of this change, the trapping and reporting of MCP-generated GETSTATUS errors (that might be generated during DBCONTROLs examination of the library and database mix subsets) has been much improved
The "BLOCKED BY FILE" mechanism is a simple way of preventing DBCONTROL from running against a specified database. When the DBCONTROL task starts, it will search for a disk file (on the system family) called
*METALOGIC/DBCONTROL/<dbuser>/<dbname>
if such a file is found and its FILEKIND is *not* DCALGOLCODE then DBCONTROL assumes that this database should not be monitored.
This mechanism was affected by the fix applied in Dbcontrol 470.05; although the blocking worked, the main DBCONTROL task would try to invoke a new monitor son every 2 minutes, displaying the same "blocked" message instead of marking the database as excluded. This problem is now fixed.
Previously, DBCONTROL could have invoked multiple DBCONTROL tasks for individual databases that were entering and leaving the mix multiple times but staying for only a few seconds. The second task can appear if the DBCONTROL son trying to connect to the appropriate DMSUPPORT library for the database he had been assigned but which had already been superceded by a new invocation of the database.
In such circumstances, but depending on the DBCONTROL interval timer (default 2 minutes), these additional tasks would remain active unless manually quit. We have seen this problem severely exacerbated if the interval timer is set to value less than 10 seconds.
DBCONTROL now performs significant checking on the active state of a database whilst trying to connect to the database. If such a transient database is detected, the DBCONTROL son will either abort himself (if no new database exists) or will attach himself to the "new" database if one is present. The following messages may be seen in such circumstances: DBC: TRY:(TST)TESTDB2:(TST)TESTDB2 - CANNOT FIND DMSUPPORT DBC: TRY:(TST)TESTDB1:ABORT:DATABASE has already gone to EOJ DBC: TRY:(TST)TESTDB1:ABORT:DATABASE already active DBC: TRY:(TST)TESTDB1:Database mix substitution detected for DBNAME
The first three messages are associated with an abort of the DBCONTROL son. The last message indicates a successful switch from a database already gone to EOJ to a new invocation of the same database.
Also, a problem where DBCONTROL could fault with SEG ARRAY ERROR when trying to determine database family substitution is now fixed.
MCP 46.189.8633 introduced a bug where DBCONTROL might not identify DBControl tasks already running on a Database and would therefore start another.
DBCONTROL now has a DUMP command, issued via the AX command, which can be used to force a programdump of the main library stack.
When DBCONTROL detects a new database, a new DBCONTROL process is invoked to start database monitoring. During the startup, if one of the GETSTATUS calls used to get database mix information failed then no adequate error recovery was performed. In this case, the DBCONTROL son was left active and a subsequent mix check by the main DBCONTROL stack caused a second process to be invoked for the same database. This second process would work fine but, although the original process was inactive, it caused problems when trying to close the database.
The original GETSTATUS problem has not been reproducible on Metalogic systems; it is believed that the problem may have been induced at the customer site by the mixture of 44.2 DMS and 46.1 MCP.
DBCONTROL has been changed to try and avoid this problem and to generate additional diagnostic information. If this situation is encountered, DBCONTROL will try 3 times to get a successful GETSTATUS result; if unsuccessful, DBCONTROL will abort the current son:
DBC:METATAPELIB4:ABORT DUE TO GETSTATUS MIX ERROR
If task switch SW6 is set on the DBCONTROL codefile, then DBCONTROL will, in addition, give a diagnostic dump and message on the first GETSTATUS error. With SW6 set, this action will still occur even if the subsequent retry is successful. DBCONTROL will retry the same database when the next monitor interval has passed.
To set the switch:
MODIFY METALOGIC/DBCONTROL;SW6
Then restart and run as normal.
Due to a minor bug in DBCONTROL's date handling routines, the current date displayed on several MONITOR form screens was incorrect for the year 2000.
This problem did not affect any other date routines and is now fixed.
DBCONTROL now supports the Unisys MORETASKS implementation allowing the provision of mixnumbers up to 65535. This is achieved by setting the system options MORETASKS (OP+MORETASKS), halt-loading and changing the MAX command.
The DBCONTROL MONITOR library and TT DBC interfaces have also been enhanced to support this change.
After the recent Y2K transition, a problem has been identified where DBCONTROL is unable to access its own statistics files from the DBCONTROL monitor window, when using STATS from the Action line for an individual database. This was because DBCONTROL was not correctly comparing the current date and the statistics file creation date.
This problem is now fixed.
