Subject: Details of testing of CMVC 2.3.1, Year 2000 readiness Date last update: 05-May-1999 File name: README.year2000.details.txt VM file name: CMVCY2KT.TXT The most up to date version of this file can be found in our ftp site: ftp://ftp.software.ibm.com/ps/products/cmvc/README.year2000.details.txt The purpose of this note is to provide details on the implementation and testing of CMVC 2.3.1.x, which is the version of CMVC that is Year 2000 ready. The CMVC 2.3.1 version-release-modification provides support for the Year 2000 by using 4 digits instead of 2 to represent the year. CMVC 2.3.1.1 was branched out from CMVC 2.3.0.24. For general details on the prerequisites, migration steps, and other high level information about CMVC 2.3.1, see the file ftp://ftp.software.ibm.com/ps/products/cmvc/README.year2000.txt Implementation details ---------------------- * Change to the now() routine to generate the current date The basic and most fundamental change between CMVC 2.3.0 and 2.3.1 is that the year is now represented using 4 digits (such as 1998, 2000) instead of only 2 digits (such as 98, 00). The update was done in the now() function which returns a date time stamp with the format "YYYY/MM/DD HH:MM:SS". Thus, any attribute in the CMVC tables that deals with a date, uses the now() function: addDate, lastUpdate, dropDate, etc. The attributes in the tables that store the information about the date, store only a string with a fixed length. This means that we are not exploiting any DATE type of attributes that might be available from the database management system. * No transitional testing from Dec 1999 to Jan 2000, only steady state In the testing that we conducted for Year 2000 readiness, we focused on the environment being in a steady state in the Year 2000. We did not test the transition from Dec 1999 to Jan 2000. We stopped both the CMVC family and the DBMS system, changed the system date to the new date, then restarted both the DBMS system and the CMVC family. * No real impact at all to the CMVC client The now() function is only used by the CMVC Server and not by the CMVC client. In fact, the CMVC client does not split, parse or manipulate the date information, which it is treated only as a single string of characters. In other words, the Client has NO knowledge that the value provided in the string represents a date. Fortunately, the string size for the date was big enough to accommodate the expansion from 2 to 4 digits. In fact, the GUI can show dates that have 2 digits for the year as well as 4 digits for the year. Thus, there is NO impact to the CMVC client (both line commands and GUI). This means that: a CMVC 2.3.0 client can talk to a CMVC 2.3.1 server, and vice versa, a CMVC 2.3.1 client can talk to a CMVC 2.3.0 server. The only changes to the CMVC 2.3.1 client are purely cosmetic: a) Update of the samples in the Help whenever a date is used. b) Update of the version number in the Copyright information. * Other changes in the server The following functions in CMVC were affected by the readiness with the Year 2000: 1) Release -extract by date: now it parses the 4 digit representation of the year. 2) The dates in the $HOME/audit/log file are now using the 4 digits. 3) Track and Level -commit: because they use the year for query, they needed to be updated. * SCCS issues (outside the scope of CMVC) CMVC has not control over the internal handling of dates by SCCS. The original version of SCCS is not Year 2000 ready. See the file README.year2000.txt for the necessary patches for SCCS to make it Year 2000 ready. The SCCS keywords that deal with dates (such as D, surrounded by %), represent the year with only 2 digits. When an archive file is prepared by SCCS and the date keywords are expanded by SCCS, the expansion shows ONLY 2 digits for the year. CMVC just passes this expanded file as-is to the end user, and CMVC does NOT attempt to correct the SCCS expanded year with 2 digits. The important point is that SCCS must have the necessary fixes/patches to allow it to handle the year 2000 correctly. The 2 digit years were corrected to use the same "window" that the operating system date uses: * where 69 thru 99 is interpreted to be 1969 thru 1999 * where 00 thru 68 is interpreted to be 2000 thru 2068 For more information on SCCS and the Year 2000, you can visit the following URLs: http://www.free-lunch.demon.co.uk/CSSC/manual/cssc_48.html#SEC55 Testing details --------------- This testing was performed during the Summer of 1998 with the versions of operating systems and DBMSs available at that time with CMVC 2.3.1.3. We installed the patches for SCCS as mentioned in the file README.year2000.txt. Without these patches, there will be serious problems in trying to check-in a file. In order to test for the impact of the Year 2000 in CMVC 2.3.1, it is necessary to create several objects in CMVC, at least components, defects, releases, files, tracks and levels. This is the minimum set that will exercise all the issues related to the Year 2000, The basic idea is to populate a CMVC family using a date of 1998, and then stop the CMVC family and the database, change the system date, reboot the machine, restart the database and the CMVC family and create additional objects and manipulate existing ones. We discovered that the database management systems do NOT like to have the system date changed when they are in operation. Thus, we did not tested the transition from Dec 1999 to Jan 2000; we focused our testing attention on a steady state when the system date was already in the Year 2000 and beyond. Furthermore, we wanted to ensure that CMVC will work beyond the year 2000 and we tested for both the Year 2000 and 2005. The reason for this double testing is that there is a potential that some fixes done to the operating system itself are targeted solely for the Year 2000 and might fail with the year 2005; even more, there is a possibility that a fix from the operating system might work fine with the Year 2005, but fail with 2000. A real example: we tested a preliminary fix for SCCS for AIX 3, and we discovered that it only worked for the Year 2000 and failed with 2005; we reported the problem and it was fixed. a) When performing file check-out and check-in operations in the year 2000 or 2005, for files that were created or changed in 1998, we did not see any problems at all. b) When requesting a sorted list of objects from CMVC, the sorting is done by the relational database management system and not by CMVC. However, when sorting dates that have only 2 digits for the year, there is a problem when the Year 2000 is involved: the 00 year is shown first than 98, 99. We chose to exhaustively test the attributes related to dates for Defects. This is sufficient and there is no need to test for the attributes related to dates for every single type of object in CMVC. Thus, we created, accepted, modified and deleted some Defects in 1998 and then we changed the system date to 2005. Then we requested the sorting of dates by year and the order was as expected: 1998, 1999, 2000 c) When we created files in the year 2005 and then did a release extract by date and we got the expected results: * When using a cut off date of 2000, we got only the files that changed after 2000 and not the ones in 1998. d) When we committed tracks and levels that had file changes for both 1998 and 2005, the action went fine and the levels and releases extracted fine. e) We verified that the audit/log and the monitor showed the years using 4 digits. f) We verified the compatibility between a CMVC 2.3.1 client and a CMVC 2.3.0 server, and between a CMVC 2.3.0 client and a CMVC 2.3.1 server. g) The expansion of keywords related to dates shows only 2 digits, which is correct, because this is a limitation of SCCS. *** end ***