O Bug do Ano 2000

Ana Carolina T. Murgel <murgel@na-cp.rnp.br>
Cybelle Suemi Oda Oyama <cybelle@na-cp.rnp.br>

Rede Nacional de Ensino e Pesquisa (RNP)

Introdução
Abrangência
Principais problemas
Guia de ações
Considerações finais
Referências

Este artigo apresenta um panorama geral sobre o problema conhecido como o bug do ano 2000 e traça um plano de ações para pequenas e médias empresas voltadas a redes.

A motivação para elaborar este documento foi a necessidade de fornecer ao leitor um guia básico sobre como se planejar para enfrentar o problema do bug do ano 2000. Como existem várias publicações sobre o assunto, a idéia foi pegar o conceito geral de todos eles e resumi-lo em um documento de fácil entendimento.

Introdução

"Por que foi que cegámos, Não sei, talvez um dia se chegue a conhecer a razão, Queres que te diga o que penso, Diz, Penso que não cegámos, penso que estamos cegos, Cegos que vêem, Cegos que, vendo, não vêem."
José Saramago, in Ensaio Sobre a Cegueira

Nos anos 60, quando se usavam cartões para programação, o custo de 1 MB de memória era de U$ 10.000. Com cada caractere valendo um byte, os programadores procuravam economizar onde fosse possível. Escrever uma data como, por exemplo, 18 de janeiro de 1968 era algo totalmente inviável, pela quantidade de caracteres que consumiria num cartão. Escrevendo-se 18/01/1968 ainda custaria caro: 10 caracteres somente em uma data! Daí pra frente todos adivinham o que aconteceu: a data em questão passou a ser escrita com 6 caracteres (180168) e, posteriormente, com 8 (18/01/68). Os programadores, na época, sabiam que os custos deveriam cair, e com os 40 anos que faltavam para o ano 2000 haveria tempo de sobra para corrigir o problema. Como sabemos, não foi o que aconteceu.

O hábito foi herdado pelos novos programadores, assim como as antigas aplicações- o que se fazia de novo ainda tinha dois dígitos na marcação de ano, e os programas herdados ganhavam novas versões, todas sempre construídas em cima das anteriores, mantendo-se assim o problema das datas.

Problema? Qual o problema dessas aplicações serem baseadas em dois dígitos? Qual o problema de, ao invés das máquinas saberem que é 2000 acharem que é 1900?

Para início de conversa, 1900 não foi bissexto e 2000 é. Uma chamada de telefone na virada do ano 2000 pode ser cobrada como uma ligação de 99 anos. E, fato verídico: uma senhora com mais de 100 anos foi convidada a ingressar no próximo ano no jardim de infância em uma cidade dos Estados Unidos!

Abrangência

O bug pode aparecer em harware, software (sistemas e aplicativos), bases de dados, arquivos, scripts, enfim, onde houver processamento de datas, ali pode estar o problema.

No caso dos computadores e programas, a solução é relativamente simples (se não considerarmos os custos) - atualização (upgrade) de software, hardware e utilização dos remendos (patches) que estão sendo lançados pelos fabricantes.

O agravante é quando se trata de microprocessadores - estão em toda parte, do forno de microondas até os satélites que controlam mísseis e comunicação, da cafeteira que deixa o café pronto pra quando você acordar até a geração, transmissão e distribuição de energia elétrica. Alguns exemplos do que pode falhar com a virada do ano:

Videocassetes;
Microondas;
Robôs de fábricas;
Marcapassos;
Equipamentos hospitalares;
Cartões bancários e de crédito;
Bombas de gasolina;
Sinais de trânsito;
Aparelhos de fax e telefônicos;
Portões eletrônicos e elevadores;
Automóveis;
Copiadoras;
Parques informáticos;
Energia elétrica;
Sistema mundial de telecomunicações;
GPS;
Etc.

Principais problemas

"Não deixa de ser irônico que a confiança excessiva na tecnologia tenha acabado por gerar tamanha incerteza. Os milenaristas que esperavam que o mundo acabasse no ano 1000 nos parecem vítimas ingênuas de uma alucinação coletiva. Hoje, em vários lugares do mundo, grupos de pessoas estão se preparando enfrentar o bug como se fosse a última versão do apocalipse: fugindo das cidades, estocando comida e trocando dinheiro por ouro. Daqui a alguns anos, o comportamento delas também deverá soar como loucura. As previsões sobre o bug só carecem de um elemento das profecias apocalípticas: Deus, substituído pelos computadores."
Maria Ercília - O Dia do Prejuízo Final - Caderno Especial Folha de São Paulo, 23/02/1999

ONDE ESTÁ O PROBLEMA

Ninguém sabe ou pode afirmar. A maioria absoluta dos especialistas em informática espera grandes problemas na virada do ano, mas ninguém consegue garantir nada porque realmente não se sabe a abrangência. Os equipamentos informatizados são globalizados no sentido literal da palavra - basta abrir uma CPU para ver a quantidade de fabricantes de diferentes partes do mundo que cabem ali dentro. Dizer que pode acontecer uma grande catástrofe não seria errado, como também não seria errado dizer que os problemas serão mínimos. O Senado americano escreveu um relatório otimista sobre o assunto, e termina esse relatório dizendo, em tom de brincadeira, que os americanos mais precavidos podem estocar alimentos. A Casa da Moeda dos Estados Unidos está imprimindo 50 bilhões de dólares considerando que os americanos vão tirar seu dinheiro dos bancos. A Cruz Vermelha Americana (http://www.redcrooss.org) fez seu documento aconselhando que as pessoas se previnam estocando alimentos e remédios, como fazem para o caso de furacões e nevascas.

No caso dos microprocessadores, para alguns fabricantes pode ficar mais barato adquirir um padrão, com data, do que encomendar um novo somente porque seu equipamento não necessita de contagem de tempo. E, como esse microprocessador utiliza a data para seu funcionamento, até mesmo objetos e sistemas onde não se esperam problemas podem falhar.

INCREDULIDADE QUANTO À EXTENSÃO PROBLEMA

Esse ponto é chave. Como ninguém pode afirmar se os problemas realmente ocorrerão, o bug do ano 2000 fica com cara de ficção científica. É comum lermos nos jornais respeitáveis comentaristas afirmarem que é bobagem, mas se assim fosse porque o temor entre os especialistas?

Essa mesma incredulidade faz com que a maioria das empresas e governos não coloquem as ações de correção do bug como prioridade. Na verdade, sem que o mais alto superior de cada empresa ou governo abrace pessoalmente o projeto, é muito difícil que as correções sejam feitas a tempo, e a chance de acontecerem falhas cresça de forma preocupante. Corrigir o problema exige gastos, em alguns casos, de grandes somas de dinheiro - com isso, os únicos realmente interessados em corrigir os problemas são os que podem perder grandes somas - daí o empenho das as instituições financeiras. Em países mais adiantados, como Estados Unidos e Inglaterra, foram, respectivamente, Bill Clinton e Tony Blair que abraçaram a campanha pela correção - o restante dos países, incluindo o Brasil, limitou-se a colocar um órgão do governo para cuidar do assunto e a editar portarias responsabilizando juridicamente o funcionário que coordenar o projeto em cada área se alguma coisa não funcionar.

ÊNFASE DO GOVERNO RESTRITO ÀS ÁREAS FINANCEIRAS

Em todo mundo, o termômetro utilizado para medir as correções do bug vem sendo as instituições financeiras - no Brasil, é o que nos dá a honrosa posição de segundo grupo em correções no mundo, junto com países como a Alemanha e o Japão. No entanto, se tomarmos como exemplo o setor de saúde, todos os países cairiam para o grupo 4, onde os problemas podem ser severos. Em tempos em que o dinheiro é virtual e o capital a religião, os governos centram fogo apenas no aspecto financeiro, preocupados com as perdas que possam ocorrer nessa área.

EFEITO DOMINÓ

O efeito dominó é o maior temor entre os especialistas. Podemos arrumar nossas redes, nossos micros pessoais, trocar equipamentos e, na virada do ano, descobrirmos que o mesmo não ocorreu com a companhia elétrica responsável pelo fornecimento de luz em nossa região. Essa mesma companhia pode provocar blecaute em outras companhias - sem luz, o fornecimento de água é interrompido, as bombas de gasolina param de operar e o caos estará formado.

COMPATIBILIDADE DOS PRODUTOS

É dado pelas empresas fabricantes - a grande maioria se nega a colocar no papel que seu produto é 100% compatível, por temor a futuros processos. As correções são lentas, e no caso do Brasil, onde a maioria dos software utilizados são americanos, as correções são ainda mais demoradas - os fabricantes estão naturalmente privilegiando seus países nas conversões, já que é onde se concentra seu maior mercado.

Guia de ações

"A questão toda do ano 2000 é como ter alguém que lhe diga que você não parece estar bem - mas você se sente ótimo! Você não vai ao médico até que esteja realmente doente!"
Extraído do documento "Testing for The Year 2000 Deadline"

Posto que nosso ramo de atividade é a Internet, apresentamos aqui um guia de como abordar a questão do bug do ano 2000, considerando principalmente os equipamentos de rede.

ETAPAS

O modelo propõe basicamente 5 etapas:

Conscientização do problema;
Inventário e análise de riscos;
Correções;
Testes;
Contatos com clientes e fornecedores.

CONSCIENTIZAÇÃO DO PROBLEMA

O primeiro passo é se conscientizar da importância e gravidade do bug do ano 2000 e, com isso, não postergar as ações para corrigir o problema. A priori, o problema pode afetar todos os equipamentos eletrônicos que tenham sistemas embutidos e sejam sensíveis a datas. Vale ressaltar que, mesmo um produto que não utilize visivelmente datas pode ter um processador sensível a tempo, isto por razões econômicas - geralmente sai mais barato para o fabricante usar chips de propósito geral do que projetar um com propósitos específicos.

É importante ter uma pessoa ou grupo que seja responsável pelo problema do bug. Estes deverão determinar o plano de ação, estabelecer o cronograma e garantir que este seja cumprido.

INVENTÁRIO E ANÁLISE DE RISCOS

O objetivo desta etapa é fazer um levantamento de tudo que possa ser afetado pelo bug, verificando sua vulnerabilidade e impacto nos serviços prestados. Assim, o que deve ser feito é:

Inventariar todos os serviços, hardware, software e sistemas embutidos sensíveis a data e que, portanto, podem ser afetados pelo bug;
Inventariar os serviços contratados;
Inventariar os sistemas de seguraça (alarmes, catracas eletrônicas, etc.);
Determinar o status de cada um dos ítens acima, em relação ao bug;
Determinar as áreas críticas que podem ser afetadas pelo problema. Por exemplo, serviços de acesso a rede, serviço de cadastro de clientes e funcionários, serviço de cobranças, etc.;
Coletar e guardar documentos que atestem que o produto está em conformidade com o ano 2000. Podem ser adquirido através de sites WWW de fabricantes ou diretamente com os fornecedores;
Gerar um relatório com as informações coletadas.

A seguir, são indicados alguns tópicos que podem ser usados como base para o inventário local.

Hardware

Conexão de Rede

Roteadores;
Switches;
Bridges;
Hubs;
Servidores de comunicação;
Modems.

Energia Elétrica

No-break;
Estabilizadores.

Telefonia

Central telefônica;
Aparelhos telefônicos (mesa e celulares);
Aparelhos de fax.

Desktops, Servidoras e Acessórios

Microcomputadores;
Notebooks;
Estações de trabalho;
Impressoras;
Scanners.

Outros

Máquinas fotocopiadoras;
Aparelhos de videocassete;
Aparelhos de som;
Aparelhos de ar condicionado com timer;
Alarmes.

Software

Básico (Sistemas operacionais e drivers)

UNIX (Solaris, AIX, Linux, etc);
WinXX (Win95, Win98, WinNT, etc);
Netware;
DOS;
Drivers (rede, twains, jetdirect, etc).

Aplicativos

Plataforma Win/DOS:
- MS Office;
- Leitor de mail (Eudora, Outlook, Pegasus, etc.);
- Browser WWW;
- PGP;
- Terminais telnet;
- Compressores de dados (Winzip, etc.);
- Anti-vírus (Viruscan, etc.);
- Cliente de tempo (D4, etc.);
- ICQ;
- Cliente FTP;
- Lotus Organizer;
- Adobe Acrobat;
- Coreldraw;
- Frontpage;
- Lview;
- etc.
Plataforma UNIX
- GNU (tar, gcc, make, patch, etc);
- Leitor de mail (pine, elm, etc);
- Perl;
- Mhonarc;
- Xview;
- Ghostscript;
- Ghostview;
- traceroute;
- gzip/zip;
- etc.

Programas Caseiros

Scripts UNIX;
Aplicações desenvolvidas para atender demanda local. Por exemplo, desenvolvimento de banco de dados e relatórios em Access.

Serviços

Serviço de nomes (Bind);
Serviço de correio eletrônico (Sendmail, POP, IMAP);
Serviço FTP (WU-FTP);
Serviço WWW/WWW+SSL (Apache, mod-ssl, SSLeay, etc.);
Serviço de listas (Listproc, Majordomo, etc.);
Serviço proxy (Squid);
Serviço de arquivos (NFS, Samba);
Serviço NIS/NIS+;
Serviço de tempo (NTPD);
Serviços de segurança;
Firewall (IPFW);
Software de seguraça (ssh, TCPwrapper, PGP, cracker, etc.).

Obs.: Não esquecer de verificar as dependências do aplicativo em relação a outros softwares.

Fornecedores

Serviço de fornecimento de água;
Serviço de fornecimento de energia elétrica;
Serviço telefônico;
Suprimentos de escritório;
Suprimentos de informática;
Transportadoras.

Serviços

Embora haja uma certa redundância, é importante inventariar os serviços internos e externos importantes na organização, verificando os softwares e hardwares envolvidos na prestação do serviço. Seria um complemento dos inventários de hardware e software, porém numa perspectiva top-down.

Serviço de acesso à rede;
Serviço de hosting;
Serviço de backup;
Serviço de cadastro de clientes e funcionários;
Serviço de contabilidade;
Serviço de controle de estoque, etc.

Outros ítens

Sistemas de alarme anti-furto e incêndio;
Elevadores, etc.

CORREÇÕES

Determinar qual será a correção para cada um dos ítens que não esteja em conformidade com o ano 2000, levantados durante a etapa de inventário. Estas correções podem ser:

Desativação;
Troca;
Upgrade;
Correção (patches);

Abaixo, encontram-se algumas dicas extraídas do documento "Testing for The Year 2000 Deadline", que apesar de serem voltadas para software, podem ser aplicadas também para hardware.

No caso de software, a seguinte estratégia pode ser adotada:

Se uma aplicação não é mais necessária, livre-se dela;
Se você está usando atualmente uma aplicação que planeje desativar antes do ano 2000, então comece a fazê-lo gradualmente;
Se uma aplicação for considerada em conformidade com o ano 2000, realize alguns testes preliminares e passe para o próximo software;
Contacte seu fornecedor de software para verificar se pode ser feito o upgrade das aplicações;
Determine se o software pode ser trocado por um outro pacote adequado e faça a cotação do mesmo;
Se você tiver alguma aplicação que precise ser convertida, comece imediatamente;
Estabeleça um plano para ajudá-lo a navegar por tudo que precisa ser feito, e imponha uma linha de tempo rígida para cada uma das atividades.

Atividades:

Determinar as correções que devem ser aplicadas a cada elemento com problemas;
Determinar os custos para a solução;
Gerar um relatório de custos;
Priorizar e aplicar as correções com base na análise de riscos;
Documentar as correções aplicadas para cada um dos ítens;
Caso as correções afetem outros setores, comunicá-los sobre os planos de correção;
Estabelecer planos de contingência para os elementos chaves, para o caso de haver problemas na passagem para o ano 2000;
- Estabelecer processos manuais para processos automatizados;
- Manter cópias impressas de informações importantes;
- Garantir o processo de backup;
- Deixar um estoque razoável de materiais, prevendo falhas nos fornecedores (Ex.: toner de impressoras, papéis para impressão, disquetes, fita DAT, material de escritório, água potável, baterias, pilhas, materiais de limpeza, etc.).

TESTES

"Alguns podem se perguntar - por que tenho que testar produtos que já se dizem em conformidade com o ano 2000? - Por uma razão: alguns fabricantes de software reportaram que seus produtos estão prontos para o ano 2000, mas não estão. Segundo, sistemas de informação não consistem apenas de uma aplicação ou um conjunto de aplicações. São a integração de aplicação, sistemas e software de gerenciamento, bem como hardware, middleware, infra-estrutura e comunicações. A integração de todos estes componentes deve trabalhar impecavelmente."
Extraído do documento "Testing for The Year 2000 Deadline"

É importante que, mesmo após aplicadas as correções, os equipamentos e software sejam testados para garantir que funcionem adequadamente durante e após a virada para o ano 2000. E isto deve ser feito com pelo menos 2 meses de antecedência ao dia 31/12/99 para se ter tempo de procurar outras soluções caso ocorram falhas nos testes. Os planos de contingência também devem ser testados com a mesma antecedência. Assim, o que deve ser feito é:

Definir o que precisa ser testado;
Estabelecer um plano de testes;
Sempre que possível, não fazer os testes em ambiente de produção;
Utilizar as ferramentas de testes de conformidade antes e depois das correções para comparar os resultados;
Não esquecer de fazer os backups do sistema e dos dados antes dos testes ;
Caso tenha parceiros ou fornecedores com os quais troque dados eletrônicos, estabeleça, em conjunto, um plano de teste dos sistemas envolvidos;
Nos testes de mudança de datas, não utilizar ambiente de produção. Ficar atento a ítens que possam deixar de funcionar após testes de datas, por exemplo: senhas e programas que tenham data prevista para expirarem ou programas de remoção automática de arquivos que tomem como base a data de criação;
Testar as seguintes datas críticas:
- 09/09/1999 (quinta-feira);
- 31/12/1999 (sexta-feira);
- 01/01/2000 (sábado);
- 03/01/2000 (segunda-feira);
- 31/01/2000 (segunda-feira);
- 29/02/2000 (terça-feira - ano bissexto);
- 01/03/2000 (quarta-feira);
- 31/03/2000 (sexta-feira);
- 31/12/2000 (domingo);
Documentar o que foi testado, como foi testado e os resultados obtidos.

CONTATOS COM CLIENTES E FORNECEDORES

"Crie uma planilha de todos os seus fornecedores e parceiros. Identifique aqueles com os quais são trocados dados eletrônicos. Neste caso, identifique as aplicações afetadas pelas transações. Priorize a lista baseada na importância do fornecedor ou parceiro para o seu negócio."
Extraído do documento "Testing for The Year 2000 Deadline"

Não se esqueça de entrar em contato com fornecedores para verificar se estão compatíveis com o bug. Recomenda-se ter em mãos documentos por escrito, por parte dos fornecedores, atestando a conformidade de seus produtos e serviços. Contactar os clientes, passando instruções e orientações sobre o bug do ano 2000.

Considerações finais

Lembre-se: a grande complexidade do problema do bug do ano 2000 é a sua magnitude e o efeito em cadeia que pode ocorrer. Por isso, é importante que sua organização esteja preparada; bem como seus clientes, parceiros e fornecedores. Faça as suas correções e cobre de seus parceiros e fornecedores o mesmo.

Referências

Aufderheide, Steven; Degiglio, Maria A.; Andrews, David H.Testing for The Year 2000 Deadline, D.H.Andrews Group, Julho 1998.
http://32.97.242.17/smallbusiness/us/smbusapub.nsf/detailcontacts/
Home1D1D?OpenDocument

Cruz Vermelha Americana
http://www.redcross.org/disaster/safety/y2k.html

Fabriani, Maria - Inseto Indigesto - Internet.BR No. 47
http://www.internetbr.com.br

Knapp, John; Aufderheide, Steven. Contingency Planning For The Year 2000, D.H.Andrews Group, Abril 1999.
http://32.97.242.17/smallbusiness/us/smbusapub.nsf/Files/ContY2K4/
$File/ContY2K4.pdf

O Dia do Prejuízo Final - Caderno Especial da Folha de São Paulo
http://www.uol.com.br/fsp/especial/inde230299.htm

Página sobre o Ano 2000 da Rede Nacional de Pesquisa, com links e referências para fabricantes de hardware e software.
http://www.rnp.br/ano2000

Prokjeto Ano 2000 da IDG - Gartner Group atualiza relatório mundial com novos números sobre o Bug
http://www.uol.com.br/idgnow/2k/hot1999-04-12d.htm

Small Business Home
http://32.97.242.17/smallbusiness/us/smbusapub.nsf/detailcontacts/
Home1D1D?OpenDocument

The Prudential Year 2000 Action Plan, The Prudential Insurance Company of America, 1999.
http://www.prudential.com/corporate/techatpru/y2k/cotyz1006.html

Y2K Supply Chain Readiness Kit, D.H.Andrews Group.
http://www.dhagroup.com/y2ksmbkit.htm

Year 2000 Computing Crisis: Business Continuity and Contingency Planning , GAO (Accounting and Information Management Division), Agosto 1998.
http://www.gao.gov/special.pubs/bcpguide.pdf

ANEXO - EXEMPLOS DE PLANILHAS/TABELAS PARA O INVENTÁRIO

Hardware - energia
Data última atualização: dd/mm/aaaa

Equipamento	Marca	Modelo	No. Série	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Certificação
Estabilizador	SMS	ECC 1200BI	NNNN	OK		XXXX	Pendente
Estabilizador	SMS	ECC 1200BI	NNN2	OK		XXXX	Pendente
No break	APC	SMART UPS 1250	NNNN	OK		XXXX	Pendente
No break	APC	SMART UPS 2000	NNNN	OK		XXXX	Pendente
No break	APC	SMART UPS 2000	NNN2	OK		XXXX	Pendente

Hardware - telefonia
Data última atualização: dd/mm/aaaa

Equipamento	Marca	Modelo	No. Série	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Certificação
Aparelho de Fax	ITAUTEC	IFAX3000S	NNNN	OK		XXXX	Pendente
Aparelho de Fax	TOSHIBA	E05429A	NNNN	PDT		XXXX	Pendente
Aparelho Telefônico	EQUITEL	E-310ST	NNNN	PDT		XXXX	Pendente
Central Telefônica	EQUITEL	Saturno 40 E	NNNN	OK		XXXX	Pendente
Central Telefônica	PHILIPS	SOPHO IS-3030	NNNN	NOK	Upgrade do software SSW300 >= 300.30	XXXX	Pendente

Hardware - rede
Data última atualização: dd/mm/aaaa

Equipamento	Marca	Modelo	Hostname/ IP	No. Série	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Certificação
Roteador	CISCO	2514	xyz/N.N.N.N	NNNN	NOK	Upgrade do IOS para >= 11.0	XXXX	OK
Switch	3COM	3C200500	xyz/N.N.N.N	NNNN	OK		XXXX	OK
Servidor de Comunicação	CAYMAN	Gator Access.MP	xyz/N.N.N.N	NNNN	OK		XXXX	Pendente
Hub	3COM	3C250-TX/I	xyz/N.N.N.N	NNNN	OK		XXXX	OK
Modem	Digitel	DT34		NNNN	OK		XXXX	OK

Hardware - desktop/acessórios
Data última atualização: dd/mm/aaaa

Equipamento	Marca	Modelo	Hostname/ IP	No. Série	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Serviços Suportados	Certificação
Estação de trabalho	DIGITAL	Alpha Server 1200	xyz/N.N.N.N	NNNN	OK		XXXX	WWW e FTP	Pendente
Estação de trabalho	DIGITAL	Prioris MX 6200	xyz/N.N.N.N	NNNN	OK		XXXX	NFS - Home usuários	Pendente
Estação de trabalho	IBM	7011-25T	xyz/N.N.N.N	NNNN	OK		XXXX	Gerência de redes	OK
Estação de trabalho	Sun	Hyper SPARC 20	xyz/N.N.N.N	NNNN	OK		XXXX	NIS, NFS, backup	Pendente
Microcomputador	COMPAQ	ProLinea 5/90 CDS	xyz/N.N.N.N	NNNN	NOK	Upgrade de BIOS	XXXX	Banco de dados	OK

Hardware - outros
Data última atualização: dd/mm/aaaa

Equipamento	Marca	Modelo	No. Série	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Certificação
Forno Microondas	PROSDÓCIMO	MP700	NNNN	PDT		XXXX	Pendente
Forno Microondas	SHARP	RB4A33	NNNN	PDT		XXXX	Pendente
Máquina copiadora	XEROX	5614	NNNN	OK		XXXX	Pendente
Microsystem	SONY	FHB900	NNNN	PDT		XXXX	Pendente
Pager	MOTOROLA	Advisor	NNNN	OK		XXXX	Pendente
Televisor	SHARP	STC-2877	NNNN	PDT		XXXX	Pendente

Software - básico
Data última atualização: dd/mm/aaaa

Fabricante	Nome	Versão	No. Licença	Status Y2K	Estratégia de Correção	Fabricante/ Fornecedor	Certificação
Sun	Solaris	2.5.1	nnnn	OK		XXXX	Pendente
Microsoft	Windows 95	4.00.950	nnnn	PDT		XXXX	Pendente
Microsoft	Windows NT Server	4.0 SP4	nnnn	NOK	Aplicação de update	XXXX	Pendente
Microsoft	MS-DOS	6.22	nnnn	PDT		XXXX	Pendente

Software - aplicativos
Data última atualização: dd/mm/aaaa

Fabricante	Nome	Versão	No. Licença	Status Y2K	Estratégia de Correção	Certificação
Microsoft	Access 97	8.0	nnnn	NOK	Aplicação de patch Jet35sp2.exe	Pendente
Microsoft	Excell 97	8.0	nnnn	NOK	Aplicação do Year2000 update	Pendente
Microsoft	Internet Explorer	4.0.1	nnnn	OK		Pendente
Corel	CorelDRAW	8.0	nnnn	OK		Pendente
McAfee	ViruScan for Windows95	2.0	nnnn	NOK	Upgrade para versão >= 3.1.0	Pendente
GNU	Tar	1.12		OK		Pendente
Netscape	Netscape navigator	4.05	nnnn	OK		Pendente

Software - caseiro
Data última atualização: dd/mm/aaaa

Nome	Softwares Utilizados	Versão	Status Y2K	Estratégia de Correção	Serviços Implementados	Nome do Responsável
Script de backup	Perl 5.005_02, gnu-tar 1.12	1.0	NOK	Mudar formato da data para DD/MM/YYYY	Serviço de backup automático	João
Relatório de Clientes	Access 97		NOK	Aplicação do patch Jet35sp2.exe	Serviço de cadastro de clientes	Maria
Planilha de custos - material de escritório	Excell 97		NOK	Aplicação do Year2000 update	Serviço de contabilidade	Maria

Software - serviço
Data última atualização: dd/mm/aaaa

Fabricante	Nome	Versão	No. Licença	Status Y2K	Estratégia de Correção	Serviços Implementados	Software Associado	Certificação
	Bind	8.2		OK		Serviço de nomes		Pendente
	Sendmail	8.9.0		NOK	Upgrade para versão 8.9.3	Serviço de correio eletrônico	NewDB	Pendente
	TCPWrapper	7.6		OK		Serviço de segurança		Pendente
	Mirror	2.9	nnnn	NOK	Trocar por similar	Serviço de espelhamento		NOK
	WUFTP	2.4		NOK	Upgrade para versão 2.4.2	Serviço FTP		Pendente
	Apache	1.3.4		OK		Serviço WWW		Pendente
	Apache-SSL	1.31		NOK - não foi testado pelo fabricante	Trocar pelo software MOD-SSL	Serviço WWW+SSL	SSLeay	NOK

Fornecedor de Equipamentos/Serviços
Data última atualização: dd/mm/aaaa

Fornecedor	Serviço/Equipamento	Endereço	Pessoa de Contato	Certificação
Universidade ACME	Acesso à Internet	Cx.P. NNNN, Cidade Universitária, São Paulo - SP, CEP: nnnnn-nnn	Pedro de Sá Borba	OK
COMPAQ Computer Brasil Indústria e Comércio Ltda.	Microcomputadores COMPAQ Prolinea 5/90 CDS	R. Maria Izabel, 45, São Paulo - SP, CEP: nnnnn-nnn	Serviço de atendimento ao consumidor	Pendente
XXXXXXX	Cisco 2514	xxxxxxxxx	xxxxxxxxx	Pendente

Serviços
Data última atualização: dd/mm/aaaa

Serviço	Hardwares Associados	Softwares Associados	Status Y2K
Serviço de acesso à rede	Cisco 2514	IOS nn	NOK - cisco (upgrade)
	Modem DT34
	Switch 3C20050	IES nn
	Linkbuilder FMSII 12T

Serviço de acesso discado	Gator Access MP	Radius	OK

Serviço WWW	Hyper Sparc 20	Solaris 2.5.1	OK
		Servidor Apache 1.3.2
		Scripts Perl
Serviço FTP	Hyper Sparc 20	Solaris 2.5.1	NOK - wu-ftp (upgrade), mirror (sem posição do fabricante)
		WU-FTP 2.4
		Mirror 2.9

Serviço de cadastro de clientes	Prolinea 5/90 CDS	Windows 95	NOK - Excell e Windows requerem upgrade e correções
		Excell

Legenda:

Equipamento: Tipo do equipamento
Marca: Marca do equipamento
Modelo: Modelo do equipamento
No. Série:Número de série do equipamento
Status Y2K:Status de conformidade com o ano 2000
Estratégia de Correção: Aplicações de correções, upgrade, desativação ou troca
Fabricante/Fornecedor: Nome do fabricante ou fornecedor do equipamento/software
Certificação: Status de aquisição do certificado de conformidade (Pendente - aguardando retorno do fabricante; OK - certificado adquirido; NOK - sem certificação do fabricante)
Hostname/IP: Nome e endereço IP do equipamento
Serviços Suportados: Serviços que estão implementados no equipamento
Fabricante: Fabricante do software
Nome: Nome do software
Versão: Versão do software ou aplicativo
No. Licença: Número da Licença
Softwares Utilizados: Softwares utilizados como base para a aplicação desenvolvida
Serviços Implementados: Serviços que as aplicações implementam
Nome do responsável: Nome da pessoa responsável pela manutenção da aplicação
Softwares Associados: Softwares utilizados no serviço ou outros que são utilizados pelo software de serviço
Serviço/Equipamento: Serviço ou equipamento contratado
Endereço: Endereço do fornecedor
Pessoa de Contato: Nome da pessoa de contato no fornecedor
Serviço: Nome do serviço oferecido
Hardwares Associados: Hardwares utilizados no serviço