Description of Year 2000 Issues =============================== A general summary of how the 4700 operating system has decided to handle 'The Year 2000' problem is outlined in the following three bullets. o The 4700 system will treat expiration dates of 00 - 69 as year 20xx and dates 70 - 99 as year 19xx. o Expiration dates of 12/31/99 and 12/30/99 are treated as no expire dates (just as they do today). If you need to deallocate these datasets, you need to code the current date as 999999. o HTF ADDUSER command will now permit expiration dates of 00 - 69. For more detail of how the 4700 operating system implemented these Year 2000 changes, please read on. We feel that providing this lower level of information about how the 4700 approached and solved the Year 2000 problem may help our users when they formulate plans for their applications. The Year 2000 presents a problem for the 4700 operating system in two specific areas; Area 1, the 4700 Controller Operating System Code and Area 2, the Host Support Program (MVS and VSE) Area 1 Issue - 4700 Controller Operating System Code ==================================================== This issue deals with dataset deallocation. Today's deallocate logic uses a 2 digit year to determine if a dataset has reached an expiration date. This date is specified when the dataset is originally created. For System Datasets, the System Monitor does the creation and specifies 12/30/99 as the expiration date. The Deallocate routine is invoked via the FCL LDKT instruction. This requires that a 'Parameter Date' be specified that is compared against the existing dataset expiration date. A 2 digit value (yy) is always used in this comparison. The 'Parameter Date' must be specified, it is not optional. The logic is as follows: If the date specified in the 'Parameter Date' is less than that dataset expiration date, the system returns a 0420 status indicating that the expiration date has not yet been reached. The user then has the option of re-issuing the LDKT and either 1) specify a date that is equal to or beyond the current expiration date. This will cause the dataset to be deallocated, 2) use a 'Parameter Date' of 999999, that indicates an unconditional deletion of the dataset, or 3) take no action since the dataset has not yet expired. The "year 2000 issue" therefore, is that in 19xx, if an expiration date is specified that is in the next century (example: 02 meaning the year 2002), today's logic will treat the dataset as aleady expired since the 02 is treated as 1902. Likewise, in the year 2002, a dataset with an expiration date of 99xxxx, (YYmmdd), would be treated as greater than the current year, but in all likelihood, would really have been intended to mean 1999, not 2099. In addition, the default expiration dates specified by the system (12/30/99 - System Monitor and 12/31/99 - HTF) add to the problem since as the year 2000 approaches, the time to expire narrows to 0 days. Basic Assumptions ================= The solution consists of changing the 4700 Controller Operating System Code as well as the Host Support Program. The following basic assumptions were considered in preparing the solution. 1-Users have always intended the dates 12/30/99 and 12/31/99 to mean never expire. 2-There may be existing customer datasets with default expiration dates of 12/30/99 or 12/31/99. 3-It is acceptable to designate a range of 00-69 to mean 2000 through 2069, and a range of 70-99 to mean 1970 through 1999. 4-It is acceptable to treat 12/30/99 and 12/31/99 as never expire dates even though at the turn of the century they will be less than the current date. Solution for Area 1- 4700 Controller Operating System Code ========================================================== IBM has developed a solution that is designed to have minimal impact on current customers. We have chosen to keep the 2 digit year, and have developed a 4700 Operating System patch that designates the digits 00 through 69 as 2000 - 2069, and the digits 70 through 99 as 1970 - 1999. The rationale here is that 4700 users would not have datasets with expiration dates prior to 1970 and that expiration dates could be specified out until 2069. Therefore, when user applications issue the FCL LDKT ALLOCATE instruction, the expiration date parameters can continue to specify 00-99 as the year parameter. When an FCL LDKT DEALLOCATE is issued, the 4700 will operate the same, however, datasets having expiration dates with years 00-69, will be treated as 2000 - 2069 and years 70-99 will be treated as 1970 - 1999. If a deallocation is attempted and the dataset expiration date is either 12/30/99 or 12/31/99, the 4700 will return a status of of 0420 indicating the expiration date has not yet occurred. Users must be aware that the default dates generated during dataset allocation (SYSMON=991230 and HTF=991231) will NOT CHANGE. So as part of the solution, the new deallocation logic will continue to treat 12/30/99 and 12/31/99 expiration dates as special. The new logic will consider these dates as "DO NOT DEALLOCATE UNLESS PARM DATE=999999". If the dataset expiration date is either 12/30/99 or 12/31/99 and the parm data is not 999999, then a status of 0420 will be returned to the application. This will allow datasets created after the year 2000 to have either the 'no expire' expiration dates (provided as defaults by HTF or the System Monitor) or the meaningful 2 digit years (00 through 69) intended as 20xx specified by the user. *** WARNING *** *** Please note that IBM utilities are provided that *** *** will deallocate datasets that have expiration dates *** *** of 12/30/99 and 12/31/99. *** *** The Installation Diskette and the UTILSTAT station *** *** will deallocate datasets with these dates if they are *** *** expired or if OVERRIDE EXPIRATION DATE is selected. *** *** Caution should be used with these utilities. *** *** HTF also has the authority to delete any dataset *** *** regardless of the expiration date. Caution should be *** *** used with this function. *** User Impact for Area 1 - 4700 Controller Operating System Code ============================================================== Datasets with expiration dates of 12/30/99 or 12/31/99 will be treated as never expire unless parm=999999. This is assumed to be what the user intended. In the situation where users actually intend datasets with these dates to be deallocated, they will not be. Instead, a 0420 status will be returned to the application. For example, this might happen after 12/31/99 and you run an application that uses the current date as the Parm Field and tries to deallocate datasets with expiration dates equal 12/31/99. Even though the dates have past because the dates are either 12/30/99 or 12/31/99, a status of 0420 will be returned. If a user wants to change the expiration date of a dataset to a more meaningful date (some date in the future), an ALLOCATE of a new dataset with the desired expiration date should be done, then copy the current dataset's data to the newly allocated dataset and then delete the old and rename the new dataset. If datasets with an expiration date of 12/30/99 or 12/31/99 must really be deallocated, use 999999's in the parameter list and they will be unconditionally deallocated. An alternative is to use HTF to delete datasets. This is accomplished by using the DELDSET parameter of the UPDATE command. See Chapter 12 of the Host Support User's Guide (SC31-0020) for more details. Area 2 Issue - Host Support Program (MVS and VSE) ================================================= The second problem area is in the Host Support Program. The ADDUSER command has provisions for entering an expiration date for a dataset. The format is YYMMDD. The program currently allows for digits 60 through 99 as valid years under MVS, and from 96 (today's year) through 99 in VSE. If a date is not specified during allocation, the default expiration date is 12/31/99. (Both MVS and VSE) This results in the inability to specify a date in the year 2000 as an expiration date. Solution for Area 2 - Host Support Program (MVS and VSE) ======================================================== Both versions of the support will be changed to allow digits 00-99 to be specified as valid dates. The remaining leap year and current month and year edits will remain. This will allow specification of dates in the next century. The default date of 12/31/99 will remain in effect. There is no change to the DEFDATA macro since there were no edits performed there. User Impact for Area 2 - Host Support Program (MVS and VSE) =========================================================== There should be no impact except to be aware of how the 4700 Operating System treats expiration dates. Patch and PTF information ========================= 4700 Controller Operating System Patch information EC 325267 patch deck 5 (*) EC 325252 patch deck 40 (*) Patch deck 6 is available, however patch 5 contains the year 2000 updgrade. You can get these patches as part of complete packages by one of the following: 1. From your IBM VM system, REQUEST EC325252 FROM BDSL2 AT CLTVM1 or REQUEST EC325267 FROM BDSL2 AT CLTVM1. 2. From the internet using a web browser at: FTP://FTP.SOFTWARE.IBM.COM/4700/MICROCODE/ Read the README and LICENSE TXT files and then get the desired package (EXE file). Host Support Program (5668-989) APAR PN91206 defines the issue. MVS PTF UN99866 + MVS APAR PQ20729 VSE PTF UN99420 4700 FCL and COBOL Application Program Considerations ===================================================== We strongly recommend that all user written applications be evaluated by their owners to ensure that they will operate correctly at the turn of the century.