O GLOBO - Informática Etc. - Carlos Alberto Teixeira
Artigo: 190 - Escrito em: 1994-08-31 - Publicado em: 1994-11-07

A maldição dos seis dígitos

A gente vai deixando o tempo passar e nem se apercebe de que o século está quase acabando. Quantas esperanças e sonhos para depois do ano 2000. Dentro de seis aninhos, bum: será o colapso das datas. O fenômeno já é esperado há muito tempo, mas começou a preocupar algumas figuras do meio BBSzeiro mundial. Na Europa, começaram uma discussão em 1991, mas que acabou dando em nada, posto que ainda faltava "muito" para a virada do século. Agora em meados de agosto passado, um mancebo chamado Tansin A. Darcos, de Silver Spring, Maryland, EUA, voltou a abordar o problema.

Talvez a síndrome de deixar as coisas para a última hora não seja tão grave em outros lugares como cá em terras brasileiras, mas no final das contas, em qualquer lugar, sempre acaba havendo um corre-corre para resolver pepinos iminentes que já haviam sido previstos, mesmo com grande antecedência.

O problema que o cavalheiro Tansin aponta é o da Grande Virada das Datas. É bem verdade que o caso ficou menos grave com o advento dos IBM PC's, que suportam datas além do ano 2100. A coisa pega mesmo com os sistemas que se utilizam de datas com seis dígitos, como por exemplo, 02/11/94, ou a invertida 941102, como é armazenada em muitos casos.

Cabe aqui um pequeno parêntese, visando ilustrar que o buraco é mais embaixo. Muitos programas ainda em pleno uso, especialmente nos mainframes (máquinas de grande porte), foram escritos há dez, quinze ou mesmo vinte anos atrás. Estas aplicações foram produzidas segundo uma metodologia que servia perfeitamente para resolver os problemas de então.

Tal longevidade pode parecer lorota nesses tempos em que os softwares são peças quase descartáveis, mudando de versão em questão de meses. Entretanto, no mundo inteiro ainda existem velhos programas gigantescos e monstruosos rodando sem parar, lembrando o poderoso e anciente Master Control Program do filme Tron, da Disney. Segundo recentes mensagens postadas no newsgroup alt.cobol da Usenet, há diversos exemplos como o de uma grande firma norte-americana cuja aplicação "carro-chefe" é um programa em Cobol com dois milhões de linhas de código, contendo 500 módulos que requerem 50 programadores alocados, num esforço constante de manutenção, cuidados e alimentação de dados. Nos últimos anos, a referida empresa gastou mais de 15 megadólares para manter o monstro rodando.

É claro que estes programas ciclópicos são de importância capital para o funcionamento destas empresas. São as jóias de coroa, de tal forma que, se algo sair errado na execução da aplicação, a firma pode literalmente ir para o beleléu, amargando terríveis prejuízos ou sofrendo alguma pesada represália ou ação jurídica por parte dos clientes.

O brabo da coisa é que, a princípio, estes imensos programas não podem ser reescritos, pois o custo de uma operação assim seria demasiado alto. E também não podem ser desativados, pois as companhias não sobreviveriam sem eles. Portanto, a menos que algo muito grave aconteça para motivar as empresas a mudarem estes sistemas antigos, é de esperar que eles continuem rodando por outros cinco ou dez anos. Em alguns casos, estes colossais programas são tão complicados e mal escritos que ninguém sabe tudo que eles fazem: fica além da capacidade de uma só pessoa, conhecer todas as funções de cada interface e de cada módulo e entender como estas peças se comunicam entre si.

Voltando à vaca fria, a grande maioria deste programas trata informações de data como números de 6 dígitos. Quando estamos comparando datas do mesmo século, tudo bem, sem problemas. Pensando na notação invertida (ano-mes-dia), encontrar quantos dias existem entre as datas 940727 e 940816 é moleza. Mas e na virada do século? Sexta-feira, 31 de dezembro de 1999, será a data 991231. O Sábado seguinte já será a data 000101. É aí que a coisa começa a complicar. Por exemplo, a diferença entre as datas 15/11/99 e 02/12/99 é de cerca de duas semanas. Mas e a diferença entre 15/12/99 e 03/01/00? Do jeito que a informação é armazenada nos antigos programas e da maneira que os cálculos são feitos na maioria das aplicações, em alguns casos esta outra diferença pode dar como resultado 99 anos!

Agora imagine os efeitos de uma inconsistência assim em programaços antigos que controlem transações de cartões de crédito, cálculos de juros, processamento de lotes químicos em instalações petroquímicas, manutenção de usinas nucleares e outras aplicações tão ou mais sérias.

O Tansin propõe um truque matemático, já muito usado em sistemas mais modernos, para fazer caber uma data de oito dígitos, tipo 28/09/2005, no espaço hoje ocupado por uma data de seis dígitos. A mutreta se baseia numa codificação em base numérica 32 e é suficientemente cabeluda para me dissuadir da idéia de tentar explicá-la aqui nesta modesta coluninha. Segundo o Tansin, de qualquer maneira o pessoal vai ter que por mãos à obra alterando zilhões de rotinas nestes imensos "Cobóis" (plural asqueroso de Cobol), mas sua abordagem da questão poderá fazer desta trabalheira a menor possível. Se você está envolvido em uma epopéia semelhante e quer saber maiores detalhes sobre o assunto, trate de conseguir algum amigo interneteiro que lhe faça um ftp-anônimo do site ftp.digex.net, diretório /pub/access/tdarcos/0026. Ou então procure nos BBS da cidade, o arquivo DATEPROB.ZIP que tem o texto integral do Tansin.

Este é o artigo BBS-Mania número 190. Cento e noventa! Daqui a 10 semanas teremos o número 200 e a festança vai ser grande, aguarde.

[ Voltar ]