This letter will address the Y2K status of the ARCTOOLS^TM family of products.

ARCTOOLS has been extensively tested for successful Year 2000 processing, both in house and by client sites. ARCTOOLS itself is compliant, but I would like to elaborate. This information should be shared with your IS department and all users of ARCTOOLS.

We are confident that there will be no Y2K related problems caused by ARCTOOLS. This claim is made as long as the machine running ARCTOOLS is at v3r1 or higher of the AS/400 operating system, and as long as the data files being ‘fed’ to ARCTOOLS are Y2K compliant (i.e. the data itself is not corrupt, erroneous or ‘non-compliant’). Further details regarding each of these points follow below.

Regarding the IBM operating system - versions prior to OS/400 V3R1 are known to have compliance issues. Since ARCTOOLS depends on operating system commands, compliance can not be guaranteed prior to V3R1 of the AS/400 operating system.

ARCTOOLS v3.1 performs no date processing except for checking for the expiration of a demo license period. Once the product is licensed, this processing is no longer performed. If you are running ARCTOOLS v3.1, you may skip the rest of this letter.

ARCTOOLS v4.0 and higher include the PurgeWizard^TM feature, which purges and archives data based on record selection tests. Obviously, this can be used to process date related records. The results of this processing depend on the way in which these dates are stored in your data files. If a field contains data that was improperly calculated by a non-compliant application program, or is stored in a non-compliant fashion, ARCTOOLS has no way of knowing that. ARCTOOLS will use the data presented to it and process it in a compliant fashion according to the data field type (i.e. numeric, text, or date field) and the rules of the operating system. To elaborate on this point, if the ‘date’ is stored in a regular numeric field (not a ‘date’ field type) and does not include the century, PurgeWizard will make it’s comparison in a normal, numeric fashion (i.e. 001231 would be less than 981231). If the ‘date’ is stored in a text field, the result would be similar. If the date were stored in a proper date field type, the processing follows the rules of the operating system – date fields including a four digit year will process properly for any year, and date fields with two digit years will be interpreted as spanning the years 1940 through 2039.

These considerations are important, because there are application software packages out there that are presenting themselves as Y2K compliant that may not store their dates in a compliant fashion. These packages may, in fact, process dates correctly but store them in a less than ideal way, such as by using numeric fields instead of date fields.

Keep in mind that the PurgeWizard is a programmer productivity tool. It is intended to be used by people familiar with the contents of the data files and to be tested before being run over the production data files. In the ‘less than ideal’ situation described above, PurgeWizard can still be used successfully by including a selection to cover the data file’s non-compliant data storage method.

As an example, if the PurgeWizard were to be used to purge all order records which were closed prior to January 1, 1995, and the data is known to be stored using regular numeric fields in a format YYMMDD, the purge request should look as follows:

STATUS *EQ "CLOSED"

*AND

CLOSEDATE *LT 950101

*AND

CLOSEDATE *GE 800101

This is the same approach that must (or will have to) be used in your application programs to overcome the data storage issue.

I hope this addresses your concerns. If you have any questions, please contact our tech support department via email at support@arctools.com .

Cordially,

David C. Shea

President, DCSoftware, Inc.