Essa retrospectiva não é sobre o decorrer desse ano, mas de uma atípica virada de ano. Quem já passou por mais de 50 viradas de ano como eu tem motivos para não lembrar de todas, mas equipes de TI e usuários envolvidos lembrarão do ‘bug do milênio’.
Nenhuma grande catástrofe ocorreu na virada do ano de 1999 para 2000 como se preconizava: queda de aviões, pane nos transportes e serviços públicos de luz e água pela já dependência de sistemas computadorizados.
No entanto, a percepção de que esse medo coletivo não tinha fundamento algum é parcial. Se existiu a percepção de que houve uma supervalorização do tema para alavancar consultorias, é inegável também a real necessidade de ações genuínas antecipando seus problemas decorrentes. E só por isso é que houve uma percepção de normalidade ao iniciar o novo milênio.
O problema
Nos primórdios da computação, o armazenamento de informações era proporcionalmente muito mais caro que hoje: coisa inimaginável para a geração Z em diante, acostumado a gravar na nuvem de forma ‘gratuita’. Herdado dos anos 60, para economizar espaço nos arquivos, o ano das datas muitas vezes era armazenado com dois dígitos ao invés dos quatro. Dessa forma, na virada do milênio, comparar o dia 01/01/2000 corria o risco de ficar menor que 31/12/1999, com as datas armazenadas respectivamente como 000101 e 991231 no formato ano-mês-dia em algumas estruturas de dados (arquivos tratados pelo Cobol, utilizado desde os anos 60, por exemplo!!).
Sistemas financeiros
Especificamente onde eu atuava nessa época, o sistema que calculava rendimentos de aplicações subtraía datas para apurar a quantidade de dias e corrigir proporcionalmente seus valores, da data de aplicação até a data da valorização e resgate. O ano mantido com dois dígitos retornaria uma quantidade de dias negativo ou nem calcularia, paralisando o processamento ou podendo retornar valores negativos no primeiro cálculo de 2000.
Não só na base de dados, mas a revisão envolvia também todas ‘variáveis de trabalho’ (conjunto de armazenamentos temporários dentro dos programas). Além da homologação de todos os sistemas, a conversão da base de dados deveria ser planejada para ser sincronizada com a substituição simultânea de todos os programas da versão compatível.
Um ano de trabalho
Esse processo foi realizado no decorrer de um ano de trabalho, em paralelo à evolução que os mesmos sistemas exigiam nesse período. Isto é, a cada nova funcionalidade incluída no sistema ainda na versão de ‘2 dígitos no ano’, essa mesma funcionalidade teria de ser replicada em sua cópia já convertida para ‘4 dígitos no ano’: quanto maior evolução da versão antiga, o que é benéfico, por outro lado, gerava maior retrabalho em transportá-la para sua cópia na versão nova.
Estouro do espumante como todos os anos
Em alguns casos, essa a conversão da base de dados e substituição de programas poderia até ser feita antecedendo a virada de ano, dando possibilidade a mais de uma tentativa e volta da versão anterior.
Fato é que não tivemos notícia de grandes danos alardeados pelo tal ‘bug do milênio’. Em parte, porque não havia esse cenário desastroso mesmo. Mas em boa parte, porque foi antecipado pela imensa maioria de equipes de TI e usuários envolvidos. Mas isso só quem se dedicou a esse trabalho faz ideia do quanto se antecipou para que todos pudessem estourar seu espumante tanto quanto sempre fizeram em todos os anos. Até ficamos de ‘plantão’, mas no geral pudemos brindar com todos da forma habitual.
Uma boa passagem de ano a todos.
Yoshio Hada
Sócio administrador da B3Bee Consultoria e Sistemas, licenciando sistemas dos dados abertos (Demonstrações Financeiras, Pilar 3 e Canais de Atendimento), CADOC’s (DLI 2062, COS 40XX, 5011, ETF 80XX, DF 9011/9061, SVR 9800, ESG 2030, RCP 4076), FGC405, conversão de layouts (ETL), controle de limites, calendário de obrigações (envio de arquivos regulatórios ou rotinas administrativas), validação e envio de CADOCs.