From: B.Gilli/G.Filippi
                                                        Date: 10 Feb 1999

             VLT-SW-FEB99 - PORTABILITY GUIDELINES
             =====================================


The following is a brief check list on how to make an application Year2000
compliant. A more complete discussion about Y2K compliance can be found in
the VLT-TRE-ESO-17210-1704, issue 1.1, "Technical Report on YEAR 2000
compliance, Guidelines for VLT Control Software", (available
from patchedFiles/y2k_tre1.1.ps).


1) Identify places for potential problems:
=========================================
Wherever time and date is accessed or manipulated, there is a potential 
problem.  

Some tools are provided to help in identifying such potential problems.
Install the y2kt module:

 - get the y2kt module (available from ESO cmm archive or
                        or from patchedFiles/y2kt_1.1.tar)
 - install the y2kt module
        cd y2kt/src
        make all man install

The y2kt module provides: 

 - a list of known potentially dangerous patterns (file "compat.JAN2000.config")
   to be used by the standard compat utility that searches in SOURCE files
   See compat(7) man-page for how to use the utility on your application code.
   Applicable to both SUN & HP.

 - binary checkers (only for SUN solaris)
     - y2000
       makes a report of the BINARIES that have dependencies on a group of 
       time related functions.
     - y2000_usage
       makes a report of the BINARIES that have dependencies on a group of
       time related functions with dangerous arguments or format srings.

For a more detailed description of these tools look at the y2kt man-page.


2) Check for necessary changes:
==============================
For every identified potential problem, inspect the code and decide on a case 
basis if changes are required. The basic rule is to avoid any ambiguity that 
could produce future mis-interpretation, and remove usage of obsolete features.
If possible, usage of obsolescent features should also be avoided.
The following is a list of known cases:

* STRUCTURES
------------
 - The usage of struct tm, field tm_year is potentially dangerous. Use 
   ccsTIMEVAL structures for LCC/CCS based applications or at least 32-bit 
   signed or better unsigned time_t types. This will insure proper behavior
   until year 2038. (64 bits will be necessary later on!)
 - Two digit year representation: yy-mm-dd is forbidden. Always use ISO 
   8601 standard: ccyy-mm-dd with the 4 digits format to express the year 
   in all ASCII representation of a date.


* FUNCTIONS
-----------
 - strptime() and getdate() shall be avoided, in particular without the 
   format specifier %Y(capital). Rather use CCS/tims functions with the 
   following restrictions:
   . timsTimeToString(3) is not compliant, is now obsolescent and 
     will become obsolete with OCT99 release. Use timsTimeToIsoString(3)
   . timsStringToTime(3) is not compliant, is now obsolescent, 
     and will become obsolete with the OCT99 release. Use timsIsoStringToTime(3)

* SCRIPTS & SYSTEM COMMANDS
---------------------------
 - date command: avoid the %y (lowercase) specifier. Rather use the 
   %Y(uppercase) one.
 - troff scripts avoid formatting with \n(yr as yr will be a 2 digit 
   year.
 - clock format command for Tcl: avoid %y(lowercase) specifier. Use 
   only %Y(uppercase).

pay attention to the usage of the following commands:

 - date should have been upgraded to accept optional century digits (%Y 
   specifier accepted).
 - prs,get will never accept century digits. They will rather use the 
   rule that years in the range [69-99] refer to twentieth century while values 
   within [00-68]refer to twenty-first one.
 - touch is presently not always able to handle -t option with dates 
   later than midnight January 1 2000 should be upgraded with OS patches.


3) Remove obsolescent VLTSW functions.
====================================== 
Some VLTSW functions have been declared obsolescent, i.e. they are not 
available by default and will be removed in the OCT99 version. 

Obsolescent functions are still included in libraries, but their
prototype are declared as:

      ifdef NOT_Y2K
          obsolescentFunction(....)
      endif

They will be completely removed on OCT99 release.

Existing applications should replace such functions with the proper
new ones. Nevertheless, to allow compilation of existing applications,
the flag NOT_Y2K has been added.

If NOT_Y2K environment variable is defined, all compilation
get -DNOT_Y2K 


4) test the modified applications & redeploy it.
===============================================
The proper behavior of the application should be tested, including 
identification of possible backwards incompatibilities. The critical dates to 
be tested are:
rollover from 31/12/1999 to 1/1/2000
rollover from 28/2/2000 to 29/2/2000 and next one to 1/3/2000 (Year 2000 is a 
leap year)

                         ____oOo____