Este problema é muito complexo como para aborda-lo através de umas poucas páginas WEB, mas nada se perde com ao menos intenta-lo. Uma boa forma de abordar o problema é dividindo-o em pedaços pequenos e vendo em que lugar do quebra-cabeças se encaixa a necessidade de cada usuário.
Existe um importante setor que será afetado pelo Bug do Milênio mas que não me atrevo a discuti-lo por que não conheço nada do assunto. É o caso dos microprocessadores que levam algum tipo de programação de datas em Assembler armazenados em memorais ROM. Estes pequenos dispositivos são utilizados nos lugares mais dispares possíveis, desde bonecas falantes para meninas até ogivas nucleares com múltiplas cabeças. Sinceramente não sei o que aconteceria se um destes chips foi programado ha muito tempo atras e tem uma rotina de data incorreta. A gente pode pensar no pior, e a única coisa que nos resta é esperar que estes profissionais não tenham brigado com o chefe (ou a esposa/marido) no momento em que estavam trabalhando muitos anos atrás.
Somente como uma amostra do que poderia acontecer, digo que algumas versões de sistemas UNIX ficarão malucas às 3:14:08 (hora universal) no dia 19 de Janeiro de 2038, passando a marcar seguidamente as 20:45:52 do dia 13 de Dezembro de 1901. Por que?, por que a data inicial nestes sistemas toma como referencia o dia 1 de Janeiro de 1970, e o registrador interno da máquina tem 32 bits. Como o registrador usa um bit para sinal, e marca um "tic" por segundo, estes sistemas UNIX são como bombas de tempo que devem detonar aos 2^31 = 2147483648 segundos (traduzido para Cristão isto significa uns 68 anos, 0 mês, 19 dias, 3 horas, 14 minutos e 8 segundos - contando os anos bissextos , como podem ver aqui).
Se em lugar de máquinas UNIX pensamos em outros artefatos com cronômetros internos que tem somente dois lugares para colocar o ano, teremos uma idéia da complexidade do problema.
Nos sistemas computacionais convencionais, o problema pode ser dividido em:
A) SISTEMAS OPERACIONAIS (OS)
B) SISTEMAS PROPRIETARIOS ORIENTADOS A "MAINFRAMES"(máquinas de grande porte)
C) SISTEMAS COMPRADOS/ALUGADOS ORIENTADOS A "MAINFRAMES"
D) SISTEMAS PROPRIETARIOS ORIENTADOS A "MICROS" (geralmente IBM-PC compat.)
E) SISTEMAS COMPRADOS/ALUGADOS ORIENTADOS A "MICROS"
Aqui "proprietário" significa "desenvolvido em casa", ao contrario dos sistemas comerciais comprados ou alugados cujos fontes não se encontram em poder do usuário.
Em qualquer uma destas categorias pode aparecer um problema relativo à mudança de datas para o ano 2000, e quanto mais antigo é um sistema, maior é a probabilidade.
A) SISTEMAS OPERACIONAIS
Não ha muito que se possa fazer aqui se existe uma falha, a não ser prever que o problema VAI acontecer (como no caso do UNIX no ano 2038) e mudar o mais rápido possível para uma versão atualizada do sistema. Como os sistemas operacionais estão desenvolvidos por empresas especializadas (as vezes pelos mesmos fabricantes do hardware), o usuário nada pode fazer para corrigir o problema por via da reprogramação, pois não dispõe geralmente do código fonte.
Como detectar um possível erro no sistema?, a resposta mais simples é: ponha o relógio da máquina no dia 31 de dezembro de 1999 às 23:59:30 e espere 30 segundos (experimente com o MS-DOS). Se o relógio automaticamente passa para o dia 1 de Janeiro de 2000, você esta provavelmente a salvo DESTE erro.
E por que um erro no relógio da máquina poderia afetar aos sistemas comerciais ou administrativos?. Por que a maior parte dos sistemas "empresta" do relógio da máquina a informação sobre o calendário através de rotinas internas. Como um sistema de contas a pagar sabe que um crédito foi realizado e registrado na caixa automática no dia 5 de Março às 12:23:55 se ninguém lhe falou?. Por que foi perguntado ao Sistema Operacional através de alguma rotina interna do tipo "call", logo é possível imaginar o que aconteceria se o relógio interno do sistema fica desajustado no 1 de Janeiro de 2000. A partir deste momento todas as transações (e podem ser milhões) realizadas pela máquina começarão a ter datas incorretas. Não custa imaginar o trabalho que dará corrigir depois estas datas.
B) SISTEMAS PROPRIETARIOS ORIENTADOS A "MAINFRAMES"
Aqui o usuário conta com a vantagem de possuir os códigos fonte do sistema, e neste caso pode detectar E corrigir o erro a tempo, embora as vezes esta correção seja onerosa e demorada. O porque e por quanto esta correção é as vezes difícil pode ver na seção O que é o Bug do Milênio?.
Como detectar algum possível erro em sistemas altamente complexos compostos de milhares de programas e arquivos?. Lamentavelmente não ha uma resposta simples para esta pergunta. Sistemas orientados a "mainframes" às vezes executam poucas transações "on-line" (aquelas em que uma pessoa se passa teclando na frente de um terminal), e mais bem se dedicam a processar grandes volumes de dados em sistemas "por lote" (batch). Muitos destes sistemas não acharão aqui o clássico problema de "colocar mais dois lugares na tela para escrever 2000", mas em lugar disto acharão outros problemas ocultos na forma de rotinas de tratamento de datas escondidas em grandes bibliotecas publicas, lotes de processo (JOBs) ha muito criados e cujas datas permanecem no esquecimento intocadas, ou talvez na forma de campos para data em arquivos que por esquecimento não foram alterados para receber o ano com dois dígitos.
Alguns passos básicos podem pelo menos ajudar a detectar o problema:
- Se a sua empresa conta com um Dicionário de Dados ativo (aqueles que guardam tanto a informação sobre o dado quanto os lugares onde é utilizado), terá a tarefa bastante facilitada. Basta perguntar ao dicionário em quais arquivos estão guardadas as datas com dois lugares para o ano e logo quais são os programas que lêem ou escrevem nestes arquivos (façam ou não uso das datas). De posse desta lista de arquivos e programas (que pode ser enorme), é possível ao menos saber sobre o que se deve trabalhar, quanto vai demorar e quanto vai custar a alteração. (As vezes é mais barato fazer o sistema totalmente novo).
- Se a sua empresa NÃO conta com um Dicionário de Dados, somente o fato de SABER o que se deve alterar ou corrigir é uma tarefa assustadora. Provavelmente precisará fazer um levantamento seção por seção dentro da empresa verificando quais arquivos e programas devem ser ou não corrigidos. Esta é uma tarefa manual possivelmente sujeita a erros que podem resultar caros.
Uma vez que localizou os arquivos cujos campos tem datas, verifique se é possível re-escrever a nova data com 4 dígitos para o ano sem necessidade de fazer deslocamentos nos campos. Muitas vezes uma data velha está na forma "dd/mm/aa" mas em formato NÃO compactado (ou seja, se usa um byte para cada número 0 a 9). Verifique se é possível armazenar neste mesmo espaço os números em formato compactado (dois dígitos 0 a 9 em cada byte). Se este for o caso, adote a solução de guardar a data em formato compactado usando o mesmo espaço, pois assim evitará ter que modificar o arquivo por inteiro a causa do deslocamento (e todos os programas associados).
- Faça um levantamento de todas as rotinas específicas que se dedicam a trabalhar com datas. Normalmente as rotinas de uso publico estão sempre num diretório global, de maneira que todos os programas fazem referencia a elas no momento da compilação ou link-edição. Provavelmente encontrará dentro deste diretório rotinas para calcular a diferença entre duas datas, rotinas para calcular o dia da semana, para calcular os feriados por região ou pais, ou mesmo rotinas para ordenar registros por datas.
- Uma vez detectadas as rotinas, escreva especificamente um pacote de programas que chame as mesmas uma e outra vez com diferentes datas, verificando em cada caso se as respostas são convincentes. Por exemplo, nas rotinas que calculam diferenças de datas faça um "pente fino" chamando-a para cada dia do ano 1999 e calculando a diferença com o mesmo dia do ano 2000 (1 de Janeiro de 2000 menos 1 de Janeiro de 1999 = 365 dias, 2 de Janeiro... etc.). Verifique que a partir do 1 de Março a resposta deve ser de 366 dias.
Naquelas rotinas que calculam os dias da semana, faça repetidas provas com datas escolhidas aleatoriamente do ano 1999, 2000 e 2001, verificando que os dias da semana sempre estão corretos. (Por exemplo o dia 20 de Agosto de 2000 DEVE ser um Domingo).
Se algum dia da semana aparece incorreto, deve proceder a uma verificação sobre qual é a formula empregada na programação. Se todas as rotinas estão funcionando corretamente, então é bastante provável que todos os programas que as chamam também estarão a salvo do problema, embora possam existir aqueles programas que saltaram a regra e onde os programadores decidiram fazer as rotinas por conta própria sem usar as de domínio publico.
- Tente entrar em contato com o vendedor do compilador COBOL (ou qualquer outra linguagem) que você utiliza. Muitas vezes uma pequena modificação dentro do compilador pode poupar milhares de dores de cabeça (e Dólares). As vezes é possível alterar o próprio compilador para que o utilize o bit de sinal (+/-, geralmente não usado nas datas) como um indicador se esta pertence ao século XX ou ao século XXI (algo assim como -01/01/99 = 1 de Janeiro de 1999, +01/01/99 = 1 de Janeiro de 2099).
- Verifique se não é possível programar uma rotina de controle centralizado que fareje automaticamente dentro de todos os arquivos com formato "ascii" que circulam nas redondezas (geralmente usados para transferencia de dados temporários) e avise se alguma transferencia está sendo realizada usando o formato "dd/mm/aa" em lugar de "dd/mm/aaaa". Uma transferencia deste tipo poderá acarretar erros no ano 2000 ao passar datas como "01/01/00" a um sistema desatento.
- Construa um pequeno sistema dedicado especificamente ao "Problema do BUG", mantendo atualizados nestes registros quais problemas foram detectados, onde e quem os solucionou e com quem contatar caso surja algum problema inesperado.
C) SISTEMAS COMPRADOS/ALUGADOS ORIENTADOS A "MAINFRAMES"
Neste caso a empresa não dispõe dos códigos fonte do sistema, e o máximo que pode fazer é detectar o problema a tempo, comunicar ao fornecedor do software e rezar para que o mesmo consiga corrigir a tempo todos os problemas.
A única forma de detectar falhas aqui é colocando o sistema a funcionar nas datas críticas, criando um ambiente especial dentro da máquina, iniciando o relógio por exemplo o dia 31 de Dezembro de 1999 e executando todas as tarefas possíveis durante um ou dois dias, verificando o que acontece quando o relógio muda para o ano 2000. Se o sistema apresenta em alguns lugares visivelmente o DIA DA SEMANA (Segunda, Terça etc.), coloque datas aleatórias na máquina (por exemplo 5 de Julho de 2001, 14 de Outubro de 2000) e verifique se o dia da semana está correto. A sincronização correta dos dias da semana com as datas é um forte indicativo que o sistema é consistente nas datas e está a salvo de falhas (por exemplo se você coloca 1 de Janeiro de 2001 e aparece uma TERÇA, então sabe que foi interpretado como 1 de Janeiro de 1901, visto que deveria ser uma SEGUNDA, e assim você sabe que algo ha de errado dentro da máquina).
Uma boa idéia é se manter em comunicação constante com outros usuários do mesmo sistema através dos grupos de Usuário (provavelmente a empresa que vendeu a você o sistema também o vendeu a outras pessoas), e ficar por dentro desta forma dos problemas e soluções que vão aparecendo. Se manter isolado neste problema pode resultar caro.
D) SISTEMAS PROPRIETARIOS ORIENTADOS A "MICROS" (geralmente IBM-PC compat.)
Muitos dos procedimentos citados para "mainframes" também se aplicam aos "micros", visto que boa parte dos mesmos esta hoje em dia interligada em redes dentro da empresa, assim, existem provavelmente bibliotecas publicas de rotinas e as mesmas podem ser testadas da maneira já citada.
O mundo dos "micros" se diversifica no momento em que cada máquina age também como uma estação de trabalho independente (Workstation), podendo executar programas e rotinas que seriam impensáveis no mundo dos "mainframes", como por exemplo planilhas de calculo (SpreadSheet), editoração eletrónica (Desktop Publishing), ou também estações CAD (Computer Aided Design).
Estas funções consomem grande quantidade de recursos computacionais (tempo de CPU e cálculo numérico), e seriam impensáveis de ser executadas numa máquina centralizada por que a mesma teria que dividir o tempo de CPU entre os muitos centenares de pessoas com um resultado mais do que medíocre para cada um deles.
Como cada "micro" tem sua própria memória e CPU (bastante potentes hoje em dia), o uso intensivo de uma aplicação numérica em uma máquina ligada à rede passa despercebida por suas vizinhas, mas por outro lado cria uma quantidade enorme de interfaces e condutos com outras aplicações que estão presentes na rede.
Pense por exemplo numa estação de trabalho executando uma planilha de cálculo e gerando um relatório temporário que sua vez deverá alimentar um sistema centralizado no "mainframe". Este relatório pode conter datas, e a pessoa que o gerou pode ter sido pouco cuidadosa no manuseio de datas referentes ao ano 2000, assim o relatório que irá alimentar os arquivos centrais leva algumas datas do tipo ""27/03/99" e outras "15/02/00" por que o usuário esqueceu de alterar a mascara das datas.
O perigo que encerram estas aplicações está em que cada usuário tem uma grande liberdade de ação para gerar dados que por sua vez alimentam a rede, e esta liberdade de ação pode desencadear uma serie de falhas no momento que as mascaras de transferencia de datas não sejam corretas.
Uma norma razoável é estabelecer que a partir de uma determinada data (por exemplo 1 de Outubro de 1999) não sejam mais aceitas transferencias de datas usando apenas dois dígitos para o ano, e todas as datas geradas em arquivos temporários dentro da rede deverão ter 4 dígitos para o ano.
Não é impossível fazer uma rotina de controle escondida dentro da rede que verifique todos os dados que tenham algum "nn/nn/nn" no seu conteúdo, avisando à pessoa que o criou sobre a inconsistência.
Aqueles sistemas que utilizam SGBD (Sistemas Gerenciadores de Bancos de Dados) como Oracle, Access, dBase-like etc. devem prestar atenção nas relações estabelecidas através de campos de datas. As vezes por descuido se corrige um campo na tabela principal do banco de dados mas se esquece de corrigir as tabelas relacionadas.
Como os "micros" são usados freqüentemente no processamento "on-line" de entrada de dados, (ou seja, uma pessoa tecla sem parar dados de entrada na máquina), uma grande parte do esforço terá que ser dedicado á reformulação das telas de entrada para mudar o formato externo das datas de "dd/mm/aa" para "dd/mm/aaaa".
Aqui é bom um pequeno grito de alerta: não se apresse em trocar TODOS os formatos da forma antiga para a nova em todas as telas, pois algumas soluções intermediárias podem ser muito mais eficientes e fáceis de implementar, como veremos a seguir:
a) Manter o formato inalterado, mudando os programas internamente para compreender que os anos acima de 50 significam "1900" e abaixo de 50 significam "2000".
Veja que esta solução é muito atraente por que poupará dois toques de teclado ao digitador (algo que pode significar muito nas entradas masivas de dados), e o seu sistema pode perfeitamente gravar as datas internamente usando todos os quatro dígitos.
b) Manter o formato inalterado nos campos que são apenas informativos (ou seja, aquelas datas que não se digitam, senão que apenas se olham). Neste caso, é melhor deixar a data como está, pois poupará dois lugares a mais na tela do computador, e pode programar a máquina internamente para que mostre sempre os dois últimos dígitos do ano (como ocorre atualmente).
Nada impede que a pessoa que vê um "01/10/00" saiba que se trata do ano 2000, enquanto que se vê um "04/10/97" saiba que se trata de 1997. A mesma regra do "acima e abaixo de 50" pode ser aplicada aqui. Poupar dois lugares no ano pode parecer ridículo, mas pense naquelas telas tabulares onde existem 5 ou 6 datas, uma ao lado da outra. Com 2 lugares para cada data você estará ganhando um espaço de 10 ou 12 caracteres ao longo da tela. A mesma norma pode ser aplicada aos relatórios tabulares em papel.
E) SISTEMAS COMPRADOS/ALUGADOS ORIENTADOS A "MICROS"
Neste caso valem as advertências feitas para os "mainframes". Muitas vezes não é possível corrigir o problema por não dispor dos códigos fonte, mas é possível prever que um problema ocorrerá e comunicar aos fornecedores para que o corrijam.
Sistemas que executam em computadores pessoais são mais fáceis de testar pois a mudança de data nos sistemas operacionais como MS-DOS ou o UNIX é fácil de realizar. Desta forma é fácil e barato destinar uma ou duas máquinas isoladas para executar intensivamente com os relógios colocados nas datas criticas sem afetar o resto do trabalho dentro da empresa.
Em aqueles sistemas que operam sobre SGBD (Sistemas Gerenciadores de Banco de Dados) como o Oracle, Access etc, efetue um teste sobre os relatórios emitidos num intervalo que contenha partes do ano 1999 e partes do ano 2000 para ver se os resultados aparecem acordes com o esperado (ou seja, primeiro os anos 1999 e depois os anos 2000). Isto pode parecer obvio, mas lembre que não todas as chaves de indexação e ordenamento usam todos os números das datas. Pode muito bem uma data estar armazenada corretamente no banco de dados mas incorretamente ordenada por causa dos "9" e os "0". Se você não pode manipular e corrigir os índices falhos, entre em contato com a empresa que desenvolveu o sistema.
Se deseja saber como serão os computadores no próximo milênio, convido-lhe a ler O Canto do Cisne"
