This document addresses year 2000 support with regard to the 4700 Controller Resource Manager (Product Number 5668-753). The 4700 Controller Resource Manager will utilize a "fixed window" approach to achive correct operation. After applying this update, the years 00-69 are designated as year 20xx and years 70-99 mean 19xx. The changes affect signon functions and date/time rollover from 12/31/99 to 01/01/00 (at midnight). This document identifies each change that was made. In addition, there are some tips to keep in mind when evaluating potential changes to your applications. Changes to the product. ======================== 1-The data specification entry DBDATYY was changed from a range of 84-99 to a range of 00-99. The ARLYGSMG group was then updated. This allows an operator to sign on and specify any 2 digit year, not just 84-99. 2-In addition to changing the audits for DBDATYY, ARMYSTR changed to determine if the century is either 19 or 20. The year specification of 00-69 will cause the century to be displayed as 20. Years entered as 70-99 will cause the century to be displayed as 19. 3-ARMYSDAT was changed to allow for roll over at midnight on 12/31/99 to 01/01/00. Prior to this change, the date rolled to the same dates but the century was considered to be 19, and this change considers the century as 20. 4-The copyright date was changed to reflect the current date. This was done to map IBD1STBY(PLEASE STANDBY message at SIGNON). IBD1STBY is part of ARLYGSMG. 5-The source for the ARLYPN (Pin Verification) sample program was changed to illustrate how to code for a fixed window. (this assumes that expiration dates on media will remain as 2 digit years, and not include century digits). 6-The GTF diskettes have been updated to reflect the above updates. In addition, the latest level of microcode was utilized. (EC 325267) 7-The sample source CPGENS have been updated to include the MODIF=7 parameter on the STARTGEN macro. This is a required parameter for EC 325267. 8-Dates that appear on paper and display output are in the form mmddyy. This will not change. Potential User impact ===================== The Generalized Transaction Facility must be replaced with the diskettes supplied with the PTF. Customers that use GTF as originally distributed simply need to use the new diskettes. Customers that use a customized version, need to rebuild the image using the new modules supplied with this update. If you have a customized CPGEN, be sure to code the MODIF=7 parameter on the STARTGEN macro. This is a required parameter for EC 325267. All User written RM applications ================================ RM applications need to be evaluated for accuracy of date usage. As shipped, date fields are expressed as mmddyy. The variable VBTXTDTE contains the data. If your applications use this variable you need to ensure that your application anticipates the change of century from 19 t0 20 and takes appropriate action that is consistent with the fixed window mentioned above. Your applications may also have been written using user defined date fields. These fields also need to be checked for any potential problems as the century changes from 19xx to 20xx. The Electronic Journal ====================== When an operator signs on, a Journal is created and the date (MMDDYY) is placed in the first record of the file. This is the header portion of the Journal. This date will remain in this format. Spanning the century will not cause problems when doing Journal searches. For example, an operator can sign on in December of 99 and in January of 00, and each Journal still has it's own unique identity. If however, you have an application whose purpose is to search all Journals within an operator specified date range, your application must be smart enough to interpret the user specified inputs and understand that the century is not part of the date in the Journal. For example, you may have an application that queries the journal(s) for transactions that occurred during a specfic time period. Your application may request operator supplied dates to be entered on a terminal. The dates may be in MMDDYY format. Your application must be able to accept 2 digit years beyond 99 (ie.,00,01,etc) and recognize them as greater than 99. The GTF contains a variable called VBTXDTTM. This is a 14 byte field containgng the date and time. This was defined as a type "B" (date/time) key using screen 2.5 in AMG. The format of the field is mm/dd/yy/hhmmss. As operators perform transactions, the operator's Journal is updated to reflect the operation. If you are using GTF, the VBTXDTTM variable is written as part of the record. Since this field was defined as a type "B" key, you may have written applications that specify this as the key field on an ARLJREAD macro. These applications must be evaluated to ensure proper use of the variable when Journals have records with years 99 and 00. For non-GTF users, applications need to be evaluated to determine how Journal records are processed with regards to dates, both at the 4700 controller and at the host after the records are forwarded. RM is a product that utilizes the 4700 controller. In order for the 4700 controller's microcode to be Year 2000 Ready, it must have EC 325267 installed with the latest year 2000 patches. End of Document