Has Y2K windowing been addressed by banks or is Y2.02K a risk?

A method used in the late 1990s to prepare for potential problems caused by Y2K could be an immediate issue for big banks in the New Year if they have not updated legacy systems.

Using a method known as windowing, banks were able to continue to use two digits to specify the date in programs, with the method able to identify the century using a reference year.

Windowing was used as a temporary fix, expected to work for a couple of decades, with the expectation that legacy systems would be replaced. Two-digit years were used in the 1970s when CPU, memory and storage were very limited and expensive. Windowing was chosen to remedy this for Y2K because it was quicker and cheaper than re-engineering entire legacy systems to work with four digits

One senior IT professional in the UK financial services sector, who was involved in several different Y2K projects at banks, said many of the legacy systems they expected to be defunct by now are still in use.

“One of the popular solutions was called windowing, which involved leaving the years as two-digits and using a reference year to determine which century a two-digit year was in,” said the IT professional, who wished to remain anonymous.

“The figure of 20 was used in many cases, but other figures were also used depending on the systems and products involved. Typically, this work applied to old code written around the 1970s in languages such as PL/1 and COBOL running on mainframes. A lot of this code is still in use today around the big banks and other large organisations that adopted computers in the early days.”

If the reference year was set as 20, when 2020 is reached, the system will think it is 1920. “The risk today is that the remedial work was done about a quarter of a century ago, many of the people involved have long since retired and the system documentation may not be perfect,” they said. “If those who followed in their footsteps have overlooked the legacy of the Y2K solutions put in place all those years ago, we might all be in for a nasty surprise on 010120 if critical systems read that as 1 January 1920.”

For example, a customer’s age could cause problems. If they were born in the year ‘84, it is correctly calculated to be 1984 and the current year is calculated correctly up until the preset figure (reference year) is reached, at which point the wrong century is applied to the two-digit year and the current year drops backwards by 100 years, so 2020 becomes 1920.

“Once this happens, date calculations go wrong and in this example our customer is correctly aged 35 in 2019 but then has an age of minus 64 in the year 2020. This is clearly impossible and the impact could stop systems working or cause chaos in financial calculations, not just because the age is the wrong number but because a negative number could cause unpredictable impact in calculations where only a positive number is expected.”

“Those involved in windowing did not expect 30-year-old code to be running for another 20 years and reaching a half-century, but quite a bit of it has,” said the IT professional.

The fundamental wrong assumption was that core banking systems would be updated and replaced far more quickly than has been the case.

“The operations and mathematics of banking have not changed for centuries, only the tools used to do it have changed, so paper ledgers were replaced by computers but the maths remains much the same,” they said.

“The hardware improved and was often upgraded, but there was never a real driver to change the original software as it was still doing the same job that had been done manually since the dawn of banking, and it was still working fine.”

A recent survey of 650 professionals at organisations with over 100 people, carried out by Vanson Bourne for software company LzLabs, found that two-thirds of businesses believe the loss of mainframe skills is a big risk to their entire business.