Você está em: Soluções » Rehosting
Conversão de sistemas Unisys COBOL-74 e banco de dados DMSII para Micro Focus COBOL e banco de dados Oracle.
Temos como principal objetivo oferecer subsídios que ajudem a prever fatores que causam impacto na performance, nos custos, nos prazos, no resultado final e na viabilidade. Dentre dezenas de outros projetos de perfis diferentes dos quais participamos, na desativação mainframes UNISYS com o apoio da nossa tecnologia: Acreditamos que tal base de experiência nos credencia a proporcionar relatos importantes preservando as ligações entre os projetos e os eventos.
Para atender as empresas com equipamentos Mainframe Unisys, a COBOLware desenvolveu um método automatizado de conversão.
Um projeto dessa natureza geralmente induz as pessoas a considerarem que, como será necessário rever todo o parque de sistemas legados, poderíamos aproveitar tal empreitada para obter produtos há muito tempo desejados, com uma melhor e mais apurada documentação dos sistemas, uma interface mais amigável com os usuários, a remodelagem da base de dados e, quem sabe, a adoção da linguagem em moda ou de nossa preferência.
Este é o primeiro item de impacto que pode atentar contra a viabilidade do projeto. O foco do projeto, em primeira prioridade, deve se ater a como livrar a organização do “atoleiro” com que está prestes se deparar. Muitas vezes a retirada dos mainframes já está com data marcada. Como a organização simplesmente depende destes equipamentos e sistemas para continuar operando, a substituição da plataforma se torna um procedimento delicado como um “transplante de coração”.
A rigor, a dependência tecnológica reside nos equipamentos (Hardware) proprietários e nos sistemas que fazem parte do Software. Como o elemento que está deixando de ter disponivilidade é o hardware, esse deve ser o alvo.
Na primeira fase a empresa deve substituir apenas a plataforma transportando os sistemas de modo a se tornarem compatíveis com sistemas abertos.
Nessa nova situação temos vantagens importantes: Os altos custos de se manter mainframes em funcionamentos são rapidamente eliminados. Saiba mais...
Os sistemas são de domínio da organização, mas, da forma como se encontram hoje, estão dependentes do hardware que está prestes a “morrer”. Afortunadamente, foram predominantemente desenvolvidos em linguagem de programação COBOL (COmmon Business Oriented Language – Linguagem Orientada ao Negócio Comum) está se encontra disponível em TODAS as plataformas de hardware.
Portanto, os sistemas poderiam ser “transplantados” de uma plataforma proprietária para plataformas abertas se mantida a mesma linguagem de programação.
Embora seja a mesma linguagem e tenha sido concebida em 1958 justamente para que os sistemas com ela produzidos fossem portáveis, na prática isso não se comprova, pois cada plataforma oferece recursos computacionais exclusivos e o compilador COBOL disponibilizado pelo fabricante conta com comandos específicos para tratá-los dando origem aos chamados “dialetos de COBOL”.
O desafio assume grandes proporções em função da imensa quantidade de código COBOL em pleno funcionamento e, portanto já confiável que teria que ser adaptado a um dialeto da plataforma aberta por profissionais altamente qualificados. Tal procedimento implica em proporcional consumo de tempo, recurso extremamente escasso em tal circunstância.
A solução encontrada para neutralizar o peso do elemento quantidade de linhas de código foi investir em mecanização do processo. A tarefa de tradução requer mão-de-obra qualificada. É um trabalho preso a detalhes, porém, repetitivo e enfadonho.
Percebemos que a produtividade seria muito maior se os esforços fossem direcionados para o objetivo de produzir programas tradutores ao invés de traduzir diretamente. Assim, surgiu uma metodologia e tecnologia especializada em tratar projetos de re-hosting são tradutores, escritos em linguagens de script de modo a que os programas são alterados da mesma forma como seriam manualmente por programadores, ou seja, o programa não é todo analisado e entendido para produzir um novo programa. O método consiste em tratar apenas o que a plataforma de destino não aceita. A lógica do programa permanece inalterada.
A grande vantagem é que a probabilidade de imprecisões no resultado final é drasticamente minimizada. Obviamente tradutores podem estar errados e falhar, muitos comandos aceitos pela plataforma de destino podem ser interpretados de maneira diferente, tais problemas são identificados nos testes e sanados com ajustes nos tradutores e o processo de tradução é repetido até que se obtenha conformidade de comportamento com a versão original. Com este método, as aplicações são transferidas de uma para outra plataforma mantendo as mesmas características que tinham originalmente.
Os usuários pouco percebem que houve uma mudança de plataforma. Características específicas de novos projetos que gerem barreiras são rapidamente sanadas, pois a linguagem de scripts oferece agilidades na escrita de tradutores. Isso associado com uma vasta experiência em projetos assemelhados nos permite produzir soluções em tempo hábil para a retirada dos mainframes.
Pessoas que produzem os tradutores são especializadas neste objetivo e não têm condições de se envolver nas regras de negócios que os aplicativos executam, ou seja, os tradutores não entendem o que estão traduzindo pois estão orientados a tratar os recursos funcionais, sintáticos e semânticos dos comandos. Uma atividade suficientemente complexa que exige dedicação extrema ao assunto.
Mas para que se certifique que a nova versão do programa vai atender às necessidades dos usuários da mesma forma que a versão original, o programa precisa ser chancelado por alguém que conheça a sua funcionalidade. Nesse momento precisamos valorizar os analistas que atualmente estão responsáveis pela manutenção dos sistemas. Sem essa colaboração o projeto não tem condições de fluir com produtividade. Considerar a terceirização dessa tarefa para que possa ser feita por alguém que conheça apenas a linguagem e a plataforma de destino produz um severo fator de risco ao projeto.
Há que se ter em mente que quem estará fazendo a migração é a proprietária dos sistemas e não uma empresa ou consorcio contratado. Existem elementos que não podem ser delegados e os que podem, devem ser ativamente fomentados e gerenciados pelo principal beneficiário do sucesso do projeto. As empresas contratadas devem ser tratadas como complementos especializados para o sucesso do projeto e jamais como executoras do projeto.
Essa recomendação tem como base a observância de projetos anteriores. A complexidade do projeto envolve bastante a relação desenvolvedor/usuário com aplicações que já estão em plena produção. Isso difere bastante do desenvolvimento de uma nova aplicação que conta com mais tranqüilidade e prazo. A expectativa do usuário é que o seu trabalho não seja prejudicado por um processo tecnocrata que ele não compreende bem. “Tudo funcionava corretamente! O que estão fazendo que está causando tantos problemas ?”.
Projetos desta natureza exigem intensa colaboração dos analistas de sistemas responsáveis pela manutenção das aplicações ora em produção tendo em mente que quem está fazendo a migração é a organização cliente e não a COBOLware, que estará fornecendo tecnologia, suporte, treinamento e orientação sem se envolver nas regras de negócios tratados ou seja o foco não é o que os sistemas fazem mas sim como tratam os recursos específicos das plataformas proprietárias e como traduzi-los para o equivalente nas plataformas abertas.
Sendo assim, visando o bom andamento do projeto, a organização cliente deve assumir a gerência do projeto, orientando o que deve ser convertido e o que deve ser descartado, homologando a nova versão realizando testes conclusivos visando acusar as falhas de funcionalidade que por ventura sejam detectadas e provocadas pelo processo de tradução ou por diferenças de interpretação entre as plataformas de modo que a COBOLware possa corrigir os tradutores ou desenvolver novos módulos de tradução e utilitários que removam os obstáculos para que os programas possam ser traduzidos e testados novamente.
Esse processo deve ser gerenciado por quem tenha condições de advertir ou substituir aqueles analistas que não tenham condições de executar o trabalho. Deixar essa tarefa para uma empresa de fora produz um cenário potencialmente conturbado e conflitante.
Seria interessante evitar, também, a “mistura de estações”. Já participamos de situações desgastantes como, por exemplo: Foi considerado que recuperar dados históricos em fita magnética para que tais dados estejam disponíveis para eventuais consultas futuras deveria ser tratado pelo mesmo projeto que realiza a tradução dos programas. Pois bem, lá pelas tantas se descobre que muitas das fitas estão deterioradas pelo tempo e que são de difícil leitura exigindo equipamento sofisticado para a recuperação e que, além disso, ninguém havia preservado os lay-outs dos arquivos da época em que estes arquivos haviam sido salvos. Isso provocou uma série de reuniões de checkpoint envolvendo todos os participantes do projeto.
Consideremos os aborrecimentos e desgastes que estas reuniões causam às pessoas que estão responsáveis pelos testes, às que estão atarefadas com simulação de rotinas, substituição de utilitários de apoio e o desenvolvimento de funções de tradução especificas. Esse pessoal não deve ser estressado nem perder noites de sono com assuntos que não têm nada a ver com suas especialidades. Seus talentos devem ser preservados para que possam estar “afiados” para dar conta de suas tarefas que já são suficientemente complexas e a melhor forma de preservar esse pessoal é dividir as atividades em equipes e reuniões de acordo com o segmento em que se especializou. A mesma segmentação seria conveniente no perfil de terceirização.
Por mais importante que seja, uma necessidade que não seja vital para desligamento do mainframe não deve causar impacto nesse processo. Tais problemas devem ser tratados em outra fase. Os testes, por exemplo, não podem ficar parados ou prejudicados até que consiga ler uma fita mofada. Tal fita pode ser lida depois que o sistema já esteja rodando na nova plataforma. Caso não de consigna ler a fita, perdem-se os anéis mas salvam-se os dedos.
Espera-se que, “no final das contas”, a nova plataforma proporcione, no mínimo, o mesmo desempenho que se contava com o mainframe. Normalmente este resultado é obtido, mas não é possível prever qual vai ser o ganho ou garantir matematicamente que não vai haver perdas em determinadas situações.
Isso se deve à expressiva diferença entre as arquiteturas envolvidas no processo. Em um mainframe a CPU só é requisitada quando o usuário tecla “XMIT”. Enquanto o usuário está digitando alguma coisa, apenas o terminal ou o emulador está tratando alguma informação e a CPU fica livre para atender a outros processos. No ambiente de arquitetura Unix e Windows uma CPU precisa tratar cada tecla pressionada pelo usuário. Como se isso não bastasse, o DMSII é um banco Hierárquico enquanto que o Oracle é um banco relacional e que no caso de uma migração terá que simular os recursos requisitados por aplicações escritas com lógica não-relacional.
Tentar prever o resultado final da performance não passaria de “um chute de olhos vendados”. Somente durante os testes é que será possível começar a contabilizar os reais ganhos e eventuais perdas que o processo vai resultar. O resultado final e real , será conhecido quando tivermos a carga de usuários acessando o sistema simultaneamente de acordo com a rotina de trabalho da organização.
Felizmente, as arquiteturas abertas são escalares e o processamento pode ser distribuído em diferentes níveis e/ou camadas sem que seja necessário alterar linhas de código, entre inúmeras CPUS a um custo bem mais acessível do que o observado na plataforma mainframe. Isso oferece uma efetiva base para termos tranquilidade e segurança de que não vai haver trabalho perdido.
Devido a preferência do mercado brasileiro pelo Micro Focus COBOL, a COBOLware tem experiência sólida com o Micro Focus COBOL bem como uma série de utilitários e rotinas de apoio escritas especificamente para este ambiente. A escolha de outro compilador a priori não inviabilizaria o projeto mas certamente exigiria um considerável aumento nos esforços e nos prazos para se obter os resultados desejados.
Rotinas (libraries) Além de COBOL, também se faz necessário tratar módulos de apoio e utilitários desenvolvidos em outras linguagens como JCL, WFL, Assembler, Algol e outras nestes casos a COBOLware produz conversores específicos ou desenvolve utilitários substitutos.
Bases de dados DMSII: Para serem migradas para Oracle ou DB2, foi desenvolvido um módulo de tradução que lê as especificações DASDL que produz para cada Dataset encontrado. Os dados são transformados em tabelas relacionais.
Tradução dos programas LINC: Estes produtos são geradores de código COBOL, ou seja, são COBOL “disfarçado”. A COBOLware não possui tradutores já prontos para tratar estes componentes mas está plenamente capacitada para produzi-los rapidamente desde que conte com a orientação dos desenvolvedores que possuam os conhecimentos práticos nos produtos.
Manutenção: Uma grande vantagem da conversão mecanizada é que não será preciso interromper a manutenção dos aplicativos no mainframe nem replicar estas manutenções no material já traduzido. Só será necessário que haja um controle de quais componentes foram alterados ou criados de modo que possam ser reenviados para nova tradução.
Implantação: Antes que seja viabilizada a ativação da nova plataforma é preciso verificar se não resta algum usuário operando com terminais TB27 físicos. Estes terminais devem ser substituídos por estações de trabalho emulando terminal e o emulador de terminais para Unix deve ser instalado em todas as estações. Assim, todos os usuários estarão equipados para operar com as duas plataformas. Dessa forma, quando os aplicativos estiverem todos testados e certificados poderão ser apresentados aos usuários em uso experimental para um crivo final.
É recomendável agendar algum tempo (por exemplo, um final de expediente) para acesso experimental por todos os usuários simulando a rotina de trabalho. Desta forma será possível observar o tempo de resposta e avaliar se a dimensão dos equipamentos está adequada para suportar a carga de processamento em tempo hábil de se expandir essa estrutura, se necessário. Com todas estas etapas cumpridas e de posse dos aplicativos funcionalmente certificados, com o desempenho satisfatório e sendo conhecidos os tempos consumidos pela extração/transferência/carga da base de dados passa então a ser viável marcar a data da entrada em operação do sistema e constatada a sua estabilização desligar os mainframes.
