Helmsman
Since the previous update:
This page has the objective of keeping our product customers up-to-date about what Ultracomp is doing, and the progress we are making in ensuring that all our supported products achieve year 2000 compliance.
All our products have been written since 1980 and are designed for use into the 21st century. However to ensure that there are no problems, we have set up a project team to audit, test and, if necessary to amend, all our supported products.
In common with other software suppliers, our software has to interact with hardware and software components not directly controlled by Ultracomp. These other elements must also be Year 2000 compliant to ensure the correct operation of our products and you will need to take steps to make certain that this is so.
To assist you, we intend to publish information revealed by our audit process as to the compliance of third party products, insofar as is relevant to the support of our own products.
This page will be updated regularly with information about the progress of our Year 2000 project and also with any relevant information about third party products on which Ultracomp products rely.
Please visit this page from time to time to get your Ultracomp Millennium update.
The project has been set up to achieve Year 2000 compliance for the following products:
Ultracomp has taken the BSI's definition of Year 2000 Conformity Requirements as the basis for our Year 2000 project 's product audits. These requirements are specified in the BSI document:
DISC PD2000-1 A Definition of Year 2000 Conformity Requirements
This document in summary states that:
In particular:
No value for current date will cause any interruption in operation.
Date-based functionality must behave consistently for dates prior to, during and after Year 2000.
In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inferencing rules.
Year 2000 must be recognised as a leap year.
Ultracomp's Year 2000 audit for each product is being conducted in several phases:
A complete code inspection examining the handling of all aspects of date related data. During this phase, any code corrections that are found to be necessary will be produced.
A review of user documentation relating to date handling to ensure that the rules are defined clearly and in full. As with code inspection, any amendments that are required will be produced during the review.
Full testing in operating environments around the Year 2000. These tests will conform as closely as possible to the CSSA document "Definition of Year 2000 Software Product and System Testing Best Practice" as it evolves.
Initially, testing is being carried out on Ultracomp's in-house systems. However, we are planning further testing at selected customer sites. We will be assisting them to trial their workloads with our products in simulated Year 2000 environments.
Later releases of compliant products
Ultracomp's policy of continual improvement of its products means that between now and the Year 2000 there will be at least one release of most products. Once products achieve full Year 2000 compliance, we will ensure continuing compliance in later releases as part of our normal product validation procedures.
The Year 2000 Compliance Status of each of Ultracomp's supported products will change until it reaches "Fully compliant". To allow you to find out about the current compliance status of any Ultracomp product, we have created a Year 2000 Compliance Status Register which will be updated on a regular basis. For each product, the register shows:
Product name and current version(s).
The current status of each version indicating its progress to full Year 2000 Compliance.
In addition to the compliance register, there are notes giving more detail for particular products. These will be updated as the project progresses.
The current Year 2000 compliance status of each Ultracomp product is shown in the table below.
| Product | Version | Year 2000 Compliance Status |
| Helmsman | 2.5 | Compliant (See product notes) |
| Vigilant | 2.26 | Audits complete; ready for formal testing |
| VC/R (VME) | 1.2 | Audits complete; ready for formal testing |
| Red Box | Client: 2.nn
Server: 1.35 |
Formal validation under way. |
| Sceptre and Overlord (VME) | 5.0 | Audits complete; correction under way |
| Sceptre UNIX | 1.26 | Audits complete; correction under way |
| Snapshot Viewer | 1.24 | Audits complete; ready for formal testing |
| VC/R (UNIX and VMS) | UNIX: 1.25
VMS: 1.25 |
Audits complete; correction under way |
| Battleboard | 1.3 | Documentation audit complete |
| BattleView | 1.0 | Documentation audit complete |
Current status
Helmsman 2.5 is fully compliant as long as Amendment 108 [in the File Area] is applied. The amendment fixes a bug whereby Helmsman's date validation routines could under certain circumstances intermittently cause incorrect century inferencing.
Millennium Test Licences may be ordered for Helmsman, at £500 each. These licences, which are only necessary for sites wishing to simulate Helmsman running outside its current licence period, allow Helmsman to run on a machine with the system clock set within the range 1/12/1999 to 31/1/2001. (The clock setting may be real, or virtual by using the ICL Virtual Dates and Century Windows Package). Further Helmsman patches are needed if a test licence is purchased, to alter the licensing screens to allow the additional licence information to be input. Details will be supplied with each test licence.
Helmsman's use of dates
All dates input to Helmsman with 2-digit years are converted to dates within the range 1980 to 2079. Thus, 31/12/99 is interpreted as 31/12/1999 and 01/01/00 as 01/01/2000. Dates input with 4-digit years are not subject to this constraint.
Dates within Helmsman are stored as number of days since 31/12/1899, or as a microsecond time value from that point. Thus they are absolute values and not affected by any problems with century inferencing. The sizes of the fields used to store these absolute values are such that there is no problem with overflow for 5 million years (dates held as day values) and 300,000 years (dates held as microsecond values). There may be underlying hardware limits that are hit earlier (current Series 39 processors will experience overflow in 2048).
Dates output by Helmsman sometimes use 2-digit years and sometimes 4-digit. There should be no problem in interpreting these.
Helmsman correctly treats 2000 as a leap year and so allows use of 29/02/2000. It therefore infers the correct day of the week for dates before, on and after that date.
There are no aspects of Helmsman where file names or generation numbers include date-derived information that would lead to an incorrect sort-order.
Helmsman's reliance on VME library procedures
VME General Library repairs GL15 and GL16 are essential for the running of all Ultracomp VME products. If you have a version of VME with the ICL Year 2000 enabling kit, then version 500.2 of GENLIB, which does not include these repairs, will have been supplied. It is therefore necessary to apply these repairs once you install the enabling kit. Amendment 110 [in the File Area] gives details, including a reference to the ICL PC-Paris SKE 93697.
VME provides a number of ways of setting up century inferencing rules which are used by various library procedures. Helmsman uses the following date handling VME library procedures:
1 ICL9LGGDAYS
This returns the number of days since 31/12/1899. It is not affected by century inferencing.
2 ICL9LGGNEWDATE
This returns a date which is the specified number of days before or after the current date. It is not affected by century inferencing.
3 ICL9LGGDATEC2B
This converts a character string representing a date into the number of days since 31/12/1899. For date with 2-digit years, the routine is subject to VME century inferencing rules. However, Helmsman always converts dates input with 2-digit years to have 4-digit years within the range 1980 to 2079 before presenting them to this procedure and so independent of any installation-specific rules.
4 ICL9LGGDATEB2C
This converts a date held as the number of days since 31/12/1899 into character form. It is not affected by century inferencing.
Current status
Code and documentation audits have finished. Vigilant appears to be Year 2000 compliant (as long as it is run on a compliant PC, of course). Pre-validation tests are currently being run by the development team. However, changes must be made to the licensing code in order to allow Millennium testing by customers, and these are under way.
Until the licensing changes are available, customers should not attempt to run Vigilant with the system clock wound forward. This is because Vigilant's licensing control system prevents Vigilant from running at an earlier date than any previous run, so after a test run with the system clock set to December 1999, for example, Vigilant would become unusable in a live environment until after that date.
Current status
All audits have been completed, and no problems were found. VC/R VME is about to enter formal validation.
VC/R’s reliance on VME library procedures
VME General Library repairs GL15 and GL16 are essential for the running of all Ultracomp VME products. If you have a version of VME with the ICL Year 2000 enabling kit, then version 500.2 of GENLIB, which does not include these repairs, will have been supplied. It is therefore necessary to apply these repairs once you install the enabling kit. Amendment 133 [in the File Area] gives details, including a reference to the ICL PC-Paris SKE 93697.
Current status
The Red Box code audit has been completed, as has the code testing, finding 2 areas of non-compliance and a few other minor date handling problems. No problems were found which would affect existing data or require any remedial actions other than an upgrade to the software. Formal validation is now underway.
The non-compliances affect
1) The passing of events between agents and managers in Operations Control, whereby a 2 character year field will overflow to 100 in the year 2000 and so distort the message headers.
2) Some standard Summary and CSV reports on incidents will incorrectly assign 28 days to February 2000, so distorting the figures they produce.
Fixes for these problems are currently in validation, and will be available as part of release 2.1. Compliance testing of release 2.1 has started.
Red Box's use of dates
Red Box interprets dates with 2-digit years as being in the range 1980 to 2079.
All date fields are represented on the database as Oracle dates. This permits dates in the range 4712 BC to 4712 AD, which are stored without the need for century inferencing.
The format of displayed dates depends on the Windows settings on the PC. This means that if the PC is set to display 2-digit years all dates will be displayed in that form, and so you will not be able to confirm that the correct century has been inferred when you enter a date value with a 2-digit year.
Current status
Our code audit has confirmed that there are places where Sceptre does not use 4-digit years internally. Also, six digit dates are used for file generation numbers, which could lead to problems with purging those files. Corrections to these problems are currently being implemented.
Sceptre's use of dates
Sceptre interprets dates with 2-digit years as being in the range 1980 to 2079.
Sceptre’s reliance on VME library procedures
VME General Library repairs GL15 and GL16 are essential for the running of all Ultracomp VME products. If you have a version of VME with the ICL Year 2000 enabling kit, then version 500.2 of GENLIB, which does not include these repairs, will have been supplied. It is therefore necessary to apply these repairs once you install the enabling kit. Amendment 634 [in the File Area] gives details, including a reference to the ICL PC-Paris SKE 93697.
Current status
Code and documentation audits are complete, and minor corrections have been identified. However, Sceptre interacts at a detailed level with the operating system, and so requires individual port onto each supported platform. Also, the porting must be done on a Year 2000 compliant version of each operating system. The different implementations of compliant Sceptre will be made available in a phased way.
Customers are strongly recommended to ensure that they have plans in place to move to a compliant operating system in good time for the millennium.
Current status
All audits are complete, and no problems have been identified. Snapshot Viewer will enter formal validation along with VC/R for UNIX and VMS.
VC/R for UNIX and VMS
Current status
As for Sceptre UNIX
Current status
Our pre-audit assessment has established that:
1 Battleboard does not require date input.
2 BattleView accepts 2- or 4-digit years and interprets 2-digit years as being in the range 1980 to 2079.
3 Data passing through IADD is passed transparently so there are no issues with dates.