Millennium Compliance Statements

INTRODUCTION

A number of queries have been raised by our Resellers and Users regarding Global and the Year 2000. This bulletin is intended to summarise the current situation.

WEB SITE

As many of you will be aware, compliance statements for Global, Global 2000 and Global 3000 product ranges are available at http://www.global3000.com/issues.html. These statements are continuously updated.

If there are significant changes to the statements on the Web site we will issue a bulletin advising you of these.

We have not included too much technical detail in the statements on the Web site as they are intended for external publication.

It is worth pointing out that each compliance statement on the Web site has a disclaimer statement and that we cannot give any legally-binding guarantees for Year 2000 compliance; everything that we are doing is on a "best efforts" basis.

"BEST EFFORTS"

If any of your users are wanting you to sign a declaration it might be worthwhile reading a document produced by the Bank of England in February this year entitled "Financial Sector Preparations for the Year 2000".

In this document it states:

"A common problem has been to know how much weight can be put on assurances of Year 2000 compliance from suppliers, clients and service providers: and conversely, how to deal with requests for such assurances from others. All institutions and service providers have received a proliferation of questionnaires about Year 2000 compliance. Some are still at the level of "Do you have a Year 2000 compliance programme?", but recently such questionnaires have tended to become more detailed, including demands for legally-binding guarantees of Year 2000 compliance.

It is not normal business practise to give a general certification of total reliability or availability, and it would be unrealistic to expect one to be given, in a meaningful way, in relation to Year 2000 compliance. The problem is so extensive and pervasive, and its impact in some cases so difficult to identify (eg where the origins of certain computer components or software are unknown), that Year 2000 compliance can really be confirmed only on a "best efforts" basis."

Below is a more detailed explanation of the background to Global's approach to the millennium which could be of use to those resellers who have developed their own products or who have clients who require more background information.

GLOBAL DATE HANDLING

Global as a development environment can handle dates in the range 1063 to 2699 using the internal date format. The standard date handling routines convert external dates as input to the internal dates held on file. Prior to Version 7.0 of both GSM runtime and the Cobol/Speedbase development environment the standard date routines always converted these dates to 19xx.

GSM 7.0 introduced the concept of a century start date. This allows the start year of a hundred year span of dates to be set at a system wide level. New date handling routines within the Global development environments V7.0 or later recognised this new system variable.

For example, if the century start date is set to say 1960 (the default), the date handling routines will convert a two digit year date entered as 70 to 1970 and similarly one entered as 20 to 2020.

Although V7.0 of the development environment was never officially released most resellers who develop their own applications have been using this version or later for some time. The first external release of the development environment to include the new date routines was V8.1.

Thus, if an application has been developed using the standard date handling routines of Global Cobol V7.0 or later and the runtime version of GSM is 7.0 or later there will be no problems with the Year 2000. There are, however, a number of potential pitfalls that resellers should be aware of.

POSSIBLE ISSUES

There could be old applications that use a pre-V7.0 version of the date handling routines. This was the case with some of our older applications like Global Finder. In these circumstances either the product can be recompiled using the new date handling routines, or, as we did with Global Finder, a program zap can be used to patch the application to use the new routine. If you have applications that have been coded using the old version of the date handler we suggest you contact your account manager who may be able to provide some assistance.

An application or, more likely, one program or routine within an application has not been coded to use the standard date handling routines. If this is the case and the alternative coding technique does not cater for dates beyond 2000 then the application, program or routine will have to be recoded.

We have recently discovered a problem with GSM Start-up when the date is taken from either the underlying operating system or, in the case of GSM/BOS, the BIOS. This problem has been fixed in version 8.0, 8.1g, 8.1h and later versions of GSM. These fixes have been supplied via repackaged components. Below is a table showing the date of the components that have been altered to correct this problem.

Note 1 - some versions of Unix are not millennium compliant. We strongly recommend that you check full compliance with the authors of any Unix operating system being used. A document detailing what we have found out about the compliance of various flavours of Unix is available from our Web site.

Note 2 - GSM V7.0 is not capable of converting the native system date at startup. This problem has been fixed in later versions of GSM but if your client insists on remaining on GSM V7.0 the problem can be overcome by deleting %.J5D, %.JWD or %.C2D. This will result in the date having to be provided to GSM by the user each time GSM is bootstrapped.

Note 3 - Novell have a "Product Readiness Table" on their Web site which we suggest you consult if any of your users are running GSM on Novell.

There is also a potential problem with GSM(BOS) systems that could be perceived as a Global problem. This problem is that the BIOS of the computer running GSM may not be millennium compliant. Full details regarding the compliance of any given BIOS is beyond the scope of this document. If a computer's BIOS is not millennium compliant then, with GSM(BOS), there is an option to delete %.J5D from SYSRES. This will remove GSM's dependence on the BIOS for date/time.

WHAT TESTING HAS GLOBAL BUSINESS SYSTEMS PERFORMED?

The other area regarding Year 2000 compliance that has recently become apparent is that some clients - or more frequently, consultants working on behalf of clients - want to know what testing has been done by the software authors and/or can the system be proven to be Year 2000 compliant.

GBS has checked all currently supported products to ensure that they are using post V7.0 date conversion routines. This has shown that Global Finder, Global 2000 Nominal Ledger, Autoclerk, Global Writer, Global Speller, Global Organiser and Global Notepad are not using the post V7.0 date routines throughout the product. We have produced zaps for Global Finder and Global Nominal Ledger and Autoclerk and are in the process of producing fixes for the other products.

It should be noted that no matter what testing we carry out it is possible that there will be issues that we have not foreseen. Should such a situation occur it is our intention that they would be fixed within the terms of our standard service agreement. It is possible that within Global products we have used non-standard date handling routines and we have scheduled a number of projects during March and April this year to carry out a series of tests that refer to the CSSA's draft document "Definition of Year 2000 Software Product and System Testing Best Practice".

WHAT CHECKING CAN THE USER PERFORM?

For sites that do not have GSM (PM) the system date can easily be set to some date after the Year 2000 and the products in use tested for compliance.

With GSM (PM), which has an annual rental fee and an expiry date after which the software will not run, we have set special dates which will bypass the expiry date checking. These dates can only be set using $D. The date check at the bootstrapping of GSM remains. For Global 3000 users, a program to advance data through a number of financial years/periods is available. You may find it useful to advance a test copy of your live data to say the Year 2000 and then set your GSM system date accordingly.

However should your users want to test their software, we recommend you ensure they are aware of two points. Advise your users that they do not accidentally enter any data into their live Global system. Ensure your user has checked with their hardware and operating system supplier for Year 2000 compliancy before commencing any tests. (Although we are sure that we can cope with any problems associated with Global and the Year 2000, we cannot take any responsibility for any underlying hardware or operating systems.)