Re: Year 2000 Survival
Posted in 1997
Topics: Installation, Setup & Upgrades, Platform-Specific Issues
In article <3376C0F0.77F2@netcomuk.co.uk>, Ian Goddard <igoddard@netcomuk.co.uk> writes >Lesley Simpson-ITS wrote: >> ><snip> >> >> You may need to upgrade the Operating system. For instance HP-UX version >> 10.30 is the earliest to be Y2K compliant and this will not be released >> until Nov. 97. There will be patches for the other v10.x releases, but not >> for v9.x. So anyone still on v9.x will have to upgrade and, depending on >> whether Informix will port the older versions of SE to HP-UX 10, may well >> have to upgrade Informix as well. >> > >In what way are earlier versions of HP-UX not Y2K compliant? > >Ian On 13 Apr 1997 18:56:27 GMT, Bill Hassel of the HP Response Center, Atlanta posted this to comp.sys.hp.hpux : Year 2000: How HP-UX Calculates Time ------------------------------------ HP-UX and the year 2000 ----------------------- Virtually every company will be affected by the year 2000 problems. For the most part, the issues are with legacy programs and datafiles which used only 2 digit or single byte values to represent the year with an assumption that the current century is 1900. Unfortunately, these programs and/or the datafiles cannot handle the year 2000 and beyond. Ideally, all these programs will be scrapped and rewritten by that time. However, there are some operating system limitations that will affect even correctly written programs. HP-UX versions prior to 10.20 will not handle the year 2000 correctly. This includes all versions of 9.xx and earlier. The objective of the 2000 Rollover Program in 10.30 is to ensure HP-UX becoming Year 2000 Safe (work beyond year 2000). The scope of this program is at the opsystem core level. It does NOT imply that all applications that are HP-UX based will be year 2000 safe. Here are some of the reasons why: -- It is clear at this point that during the 2000 Rollover Program, one of the major problems was the misinterpretation of the date field by HP-UX code at the core level. Thus, it is highly possible the same kind error lies in the application level code. -- Applications may have their own defined "date" data field. These date fields as well as all of their dependent applications would have to be rewritten in order to avoid the year 2000 problem. So, in order to determine if a particular application is 2000 safe or not, the programmer really needs to look at the code that is built on top of the opsystem calls. This includes date calculations which may overflow or undeflow due to inadequate choices for numeric precision. How HP-UX calculates time ------------------------- HP-UX converts dates from applications to seconds, with 1970 as the starting point (more specifically, January 1, 1970, 0:00:00). In a 32-bit OS, this means that the time counter is "maxed out" in year 2038, with 2037 as the highest year HP-UX supports. Presently, HP-UX 10.20 and earlier will not always calculate dates after 2000 correctly. This shortcoming will be corrected in HP-UX 10.30, due out in 1997. However, because 10.30 is still based on 32-bits internally, it is still subject to the 2037 time maximum. Keep in mind that 2037 is about 40 years away, a time frame where the design of future computers and opsystems can only be guessed. Once HP-UX goes to 64-bit, this maximum time constraint goes away, because the allowed time range increases by 2^32, a very large number. It is doubtful that any HP-UX systems will exist when that 64 bit value reaches the maximum. In summary, the current (unpatched) HP-UX opsystem status is: 9.xx 10.01/.10 10.20 10.30 64-bit+ ---- --------- ----- ----- ------- Calculates post-2000 dates correctly no no no yes yes Handles dates 2037 and beyond no no no no yes Patches to meet Year-2000 compliance no yes yes [END] Hope this answers your question. Paul. -- Paul Colton paulc@catan.demon.co.uk http://www.catan.demon.co.uk/