Semana passada nós estávamos conversando sobre a evolução do hardware e a evolução do software. Tudo leva a crer que o ritmo de desenvolvimento do software não tem sido suficiente, ou seja, os desenvolvedores não são tão caprichosos atualmente como poderiam. Isso me fez lembrar um episódio muito interessante que aconteceu há anos atrás que ajuda a ilustrar este ponto de vista de forma surpreendente.

No começinho de década de 90 eu trabalhava na Proceda, uma empresa que era “bureau” de serviços de informática do grupo Bunge Y Born e que também vendia serviços de processamento de dados baseado em mainframe para outras empresas do mercado. A Proceda tinha uma área de processamento de contas de fundo de garantia, usando programas que já vinham sendo usados desde a década de 60!!!Nessa época a empresa tinha um mainframe que era o “supra-sumo” da época, um IBM 3090 com 6 módulos processadores atendendo cerca de 6000 terminais (locais e remotos). Na ocasião só a Petrobrás e Embraer tinham mainframes mais potentes no Brasil. Além disso havia um ambiente de desenvolvimento, totalmente separado usando um ambiente muito mais modesto, embora ainda muito custoso. Tudo no mundo dos mainframes custa milhões de dólares!

(foto ilustrativa-IBM 3090 modelo mais simples)

Definido o cenário, preciso explicar o que fazia eu nesse contexto. Eu me desenvolvi desde o começo de minha carreira profissional na área de microcomputadores. Mas como tinha desenvolvido um projeto de comunicação micro-mainframe eu tive um ponto de intersecção com este outro mundo da informática. Como os custos relacionados a mainframe são muito altos, a empresa apostou em um projeto que eu tive a felicidade de iniciar, que era a implantação de um ambiente de desenvolvimento para mainframe baseado em rede local de microcomputadores. Havia uma simulação de CICS, CMS, IMS e tantas outras engenhocas de mainframe de forma a baratear e agilizar os custos de operação. Para vocês terem uma idéia, os programadores da época economizavam compilações de programa, pois sabiam que usavam preciosos ciclos de CPU a cada rodada. Se o programa funcionava o custo de fazer os testes, mesmo no ambiente de desenvolvimento (no mainframe) eram também elevados. Por isso fazia total sentido trazer para a rede de PCs o trabalho de desenvolvimento. Compilações e testes ilimitados a custo zero ou quase zero se comparado com o mesmo trabalho feito no mainframe.

Isso define bem o que fazia eu neste processo. Voltando ao assunto, existia um tal processamento de contas de fundo de garantia que era muito pesado. Toda vez que entrava consumia cerca de 0,25% de CPU do sistema. Não se esqueça que era uma HIPER máquina com 6 módulos de processamento só pior que o mainframe das duas estatais citadas anteriormente. Um belo dia a Proceda herdou de um outro bureau o processamento das contas de fundo de garantia do extinto banco Comind, que falira há alguns anos. Outros lotes de processamento de outras origens eram muito mais pesadas e já era tratadas pelo tal programa. Iria ser fácil engolir mais esses milhares de contas.

Para surpresa geral, na primeira vez que as novas contas foram agregadas para o processamento (vários milhares frente quase um milhão que já eram processadas) a CPU “entrou em parafuso”!!! Quase 40% de uso uma CPU gigante como aquela era assombroso!!! Afinal o que acontecera???

A área de análise e programação não conseguia descobrir. Eles estavam muito céticos frente àquela rede local ser utilizada para desenvolvimento. Falando em bom português eu sentia que apesar deles virem a ter um grande aumento na qualidade de seu trabalho no ambiente da rede local, eles se sentiam sendo “diminuídos” deixando de usar aqueles terminais 3270 ligados à “mamãe IBM”.

Nessa hora eles de forma muito “perspicaz” (para não dizer sacana), falaram que se aquela engenhoca era tão boa, nós seríamos capazes de achar o problema. Ou seja, como não conseguiram resolver o assunto, passaram a “batata quente” para frente. Se desse certo o trabalho teria seria feito em benefício deles. Se desse errado serviria de pretexto para falar mal da solução. Situação ingrata fomos colocados.

O que eles não sabiam que “apesar” de rodar em micro, aquela solução já dispunha de recursos inimagináveis para os desenvolvedores de mainframe. Só para citar dois recursos, os famosos “breakpoint” e “profiler” foram suficientes para achar o problema. O profiler é um recurso que “mapea” o consumo de recursos por trechos do programa. Conseguimos uma massa de testes de 1% do tamanho original, suficiente para investigar o nefasto fenômeno. Localizado o trecho “vilão”, usamos o recurso de breakpoint para fazer interromper o programa e executar passo a passo olhando o código fonte do programa. Arrisco-me a dizer que nem hoje, quase 15 anos depois, existem estes recursos para desenvolvimento em mainframe. Indo direto ao ponto, achamos o problema, a despeito da torcida contra. Vou explicar o que aconteceu.

O programa original, feito em 1965, e alterado por uma ou duas dezenas de pessoas ao longo do tempo, previa uma tabela para processamento de lançamentos de exceções. Esta tabela era relativamente pequena, com alguns poucos milhares de registros. Em uma manutenção feita em 1976 um brilhante programador resolveu acessar os dados dessa tabela em uma outra ordem e por isso incluiu um comando de ordenação dessa tabela. Até aí nada de mais, certo? Quase. Ele na pressa de fazer o seu trabalho incluiu este comando de ordenação dentro de um loop de processamento principal. Assim a cada registro processado essa tabela auxiliar era novamente ordenada. Apesar desse erro conceitual a catástrofe ainda não tinha sido estabelecida, pois como disse essa tabela auxiliar era pequena. Quando a Proceda herdou o processamento do finado Comind, no processo de migração de dados por algum motivo obscuro, alguém decidiu “para separar bem as coisas”, usar a tal tabela de lançamentos de exceções para este fim. Esta tabela subiu de 5 mil registros para 125 milhões de um dia para outro!!!! Imagine essa tabela imensa sendo ordenada cerca de 200 milhões de vezes. Achado o “absurdo”, deslocamos o comando de ordenação para ser executado fora do loop principal.

Para resumir o final da história o programa original teve feita a mudança recomendada pela minha equipe e de o uso do mainframe caiu 40%, para 0,12% apenas por esta simples mudança!!! Menos que o consumo de CPU pré Comind. Mas nada valeu mais a pena que ver a expressão incrédula da equipe que era responsável por este sistema, que tinham certeza que não conseguiríamos, ao ver o resultado da empreitada.

Alguns meses depois eu saí da empresa e soube que motivos políticos fizeram inviabilizar aquele belo projeto. Como não estava mais lá, não cabe a mim julgar se a decisão foi certa ou errada. A experiência foi muito rica e a lição aprendida foi grande. Mas em sua opinião o problema foi causado por um problema de projeto ou mau uso do sistema?

Comentários (11)   Visitas (12801)

JorgeR

Ótimo "causo"... são testemunhos como este que nos ajudam a compreender a evolução da nossa área (da qual a idade não me permitiu participar ).
Como tudo em informática tem que ser para ontem, deve ter havido pressa para desenvolver o sistema, mas acredito que mesmo assim, com um bom projeto o problema não teria ocorrido.

JorgeR - Santo Ângelo / Santa Rosa (RS) - 28/02/2005 - 18:26 - Responder no fórum

T-Rodman

Ele na pressa de fazer o seu trabalho incluiu este comando de ordenação dentro de um loop de processamento principal.
Não entendo muito de programação, mas essa é uma das grandes limitações do Paradox em relação ao SQL, por exemplo (lendo certa vez um artigo de como aplicar os dois bancos de dados em ambientes multi-usuários). O Paradox trabalha sempre com uma tabela ordenada - algo que não consome recursos de CPU, mas numa rede com mais de 10 PC's - todos utilizando o mesmo DB ao mesmo tempo, a rede fica sobrecarregada - enquanto a pesquisa do SQL só funciona quando requisitada - aumentando a carga da CPU nesse momento - mas não sobrecarregando a rede a toda hora.
Falando em evolução de hardware/software, estamos fazendo um artigo a respeito, que em breve estará numa review por aqui, no forum. Aguardem.

T-Rodman - Jau/SP - 03/03/2005 - 10:33 - Responder no fórum

Melvin13

Sou analista de uma área da empresa em que trabalho e minha atuação é Natural/ADABAS... recentemente foi adotado um programa que verifica a utilização de recursos dos programas. Mas acho que descobri algo que pode ser um furo nesta avaliação. O programa não analiza cada rotina a parte, e sim o total de chamadas do dia. Se um dia a rotina não fosse excecutada, não entrava na lista negra, mas se outro dia houvessem 300 chamadas, ela iria encabeçar a lista!

Melvin13 - Curitiba - 03/03/2005 - 11:25 - Responder no fórum

Flavio Xandó

JorgeR causos como esses, embora parceçam anacrônicos não são. Na verdade acabam tendo muita relação com fatos atuais. Causos como estes eu tenho vários se vocês acham que é um assunto legal posso fazer algumas outras colunas nessa direção.

Flavio Xandó - 03/03/2005 - 14:28 - Responder no fórum

Fernando_Celio

Ambientes de mainframes são muito complexos, e geralmente exigem soluções únicas, que uma vez encontradas, geralmente param de ser otimizadas.
Quanto ao problema descrito nesse tópico, o que aconteceu foi que existia um determinado processo que funcionava perfeitamente para um determinado tipo de situação, com um determinado volume de dados e que rodava num tempo aceitável. Ao ver esse volume de dados se alterar, esse processo deixou de ser adequado, precisava de um novo acerto. Isso sempre foi muito comum.
Vivendo há mais de 30 anos nesse ambiente, não era raro para mim, ver por exemplo, uma máquina ser substituída por outra com o dobro da capacidade de processamento e ver o tempo das aplicações que o cliente rodava aumentar. Após um trabalho de "tunning" sério, tanto no sistema quanto nas aplicações, a situação se resolvia.
E na maioria das vezes, sempre foi assim. Qualquer mudança feita sem o devido cuidado, acarreta em desastre, por isso existiam ambientes de desenvolvimento e produção, embora nem mesmo um ambiente de desenvolvimento bem feito garantisse o sucesso da aplicação/sistema quando fosse feita a migração para a área de(...)

Fernando_Celio - Rio de Janeiro - 05/03/2005 - 13:42 - Responder no fórum

Flavio Xandó

Fernando_Celio, muito coerentes e de muito bom senso os seus comentários. Eu mesmo já presenciei este fenômeno de troca de máquina com consequente queda de performance a despeito da máquina nova ser mais potente. Tuning e "condição de contorno" de um problema são fundamentais!! Êta ambiente sensível esse!!!!

Flavio Xandó - 05/03/2005 - 14:29 - Responder no fórum

DexterAMD

o que eu vejo nessa area sao geralmente programadores que não têm conhecimento do processo que estao desenvolvendo.
Exemplo ?
Ja trabalhei com programas para fabricas de roupas em que os desenvolvedores nunca pisaram no chao de uma fabrica de roupas, então as rotinas dos programas eram desenvolvidas de acordo com o que eles "achavam" que aconteciam e com uma lógica em que não dava margem para alterações , como se o usuario fosse tao exato como um processador, o usuario nao podia errar nunca.
Dinheiro gasto em programas inuteis

DexterAMD - Belo Horizonte/MG - 07/03/2005 - 10:20 - Responder no fórum

Fernando_Celio

Colega Dexter,
Essa não é a rotina normal na área de mainframe.
Geralmente quando um setor solicita um aplicativo ao pessoal de desenvolvimento, pessoas desse setor são convidadas a fornecer os insumos necessários para os desenvolvedores poderem criar esse aplicativo. Trata-se de um trabalho que envolve uma certa sinergia entre o pessoal de CPD e as áreas que requisitam o serviço.
E a aplicação geralmente precisa ter o aval do pessoal que a requisitou.
Agora, se os escolhidos do setor são "os amigos do Rei" ............
Aquele abraço.

Fernando_Celio - Rio de Janeiro - 07/03/2005 - 11:32 - Responder no fórum

Mais comentários Acessar o fórum Responder no fórum