Correct. And then I see yesterday on a local news site an article with a suggestive title like: a lot of fuzz, but hardly any problems really occurred.
The article itself has a little more nuance, but it is still nice food for title hunters (useful if your business model exists of getting as much people as possible to generate advertisement hits). Kees. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jeremy Nicoll Sent: 03 January 2020 15:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: it was 20 years ago today On Fri, 3 Jan 2020, at 00:49, Joel C. Ewing wrote: > The problem for us was not "how" to fix a single instance of the > problem, but finding "where" to fix an unknown number of instances of > the problem in 1000's of lines of in-house code and in associated data sets. I think how complex this was depended a lot on how old a site's applications were. It also depended on how long the 'tail' or archived data was. Suppose you identified all the instances of a single date data column in a single current file that might be read and rewritten by umpteen programs. If you changed all the programs you'd also need either to change the data in all the archived files as well, or make the program able to decide whether it was running in pre-change or post-change mode. But you'd also need to change all the other programs that also read those old archive files. And that might have knpck-on effects on other files that they manipulated. While doing this, you also had to make sure that - if your change failed - you could back it out and create/recreate all the related files. It's rapidly obvious that you can't change all old files in sync with a series of program changes and still allow all your old, or not-yet-changed programs to process the old files (because you changed those). That's why the date-window approach got used. The as-yet-unchanged programs could contine to read all the archived data, while the updated programs could handle the old-format data more intelligently. If I remember correctly, one of the changes that happened (to customer TS&Cs) was that we no longer supported customers aged > 100. I have no idea what they were meant to do with their money. Where I worked (a UK bank), Y2K was a big deal. A colossal amount of work was done in the two or so years beforehand, and on the night the computer centre was heavily staffed - not quite as many of us as on a normal day, but nevertheless lots. We had by then run simulated workloads back and forth across the date change many times, as well as checking things like how end-of-financial/ tax year/calendendar year processing could be expected to go (at eg end of March 2000, 5/6 April 2000, 31 Dec 2000) and I expect beyond that as eg programmes doing 2-year, 5-year etc historical reports and those doing forecasting that might not run until some months later also needed to be thought to be ok. -- Jeremy Nicoll - my opinions are my own. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ******************************************************** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
