sexta-feira, 30 de novembro de 2007

INT, GNT, LBR, EXE ou DLL ?

Se você desenvolve aplicações Window ou UNIX utilizando o Micro Focus COBOL certamente já encontrou diferentes formatos de arquivos executáveis, como int, gnt, lbr, exe, dll, entre outros. Se você tem dúvidas sobre as diferenças entre esses formatos, esse artigo pode esclarecer algumas delas.

INT - Intermediate Code
Esse tipo de código foi introduzido pela Micro Focus por dois motivos principais: tamanho e portabilidade. Para executar esse código intermediário é necessário um interpretador, que fica dentro do Cobol Runtime System. Para entender um código intermediário, imagine uma série de chamadas a sub-rotinas. O interpretador contém sub-rotinas que manipulam cada instrução do código intermediário. Cada instrução lida do código intermediário, faz uma chamada para uma rotina específica no interpretador, que manipula essa instrução. Depois que a instrução é executada, o interpretador retorna o comando ao código intermediário para pegar a próxima instrução.

Assim que um programa é compilado e um código intermediário é gerado, tudo o que é necessário para executá-lo é o COBOL Runtime System. Por isso, se o Runtime System foi portado para uma nova plataforma, a aplicação estará disponível para ser executada sem a necessidade de ser recompilada.

Pelo fato do código intermediário ser interpretado, a performance de aplicações que executam um quantidade considerável de operações pode ser relativamente lenta.

GNT - Generated Code
Arquivos do tipo generated code contém código de máquina nativo, específico do processador que você está usando, diferentemente dos arquivos que usam o intermediate code. Por isso, os compiladores criam otimizações no código gerado para executá-lo o mais rápido possível, fazendo com que a performance das aplicações seja significantemente mais rápida, visto que o Runtime System não precisa interpretar instruções quando as aplicações são executadas.

Apesar dos arquivos generated code possuírem código nativo, eles também necessitam do COBOL Runtime System para serem carregados e executados. Porém, um intepretador não é necessário, pois o COBOL Runtime System oferece o suporte necessário para a execução do programa.

LBR - Library files
Enquanto a organização de aplicações em diversos módulos oferece um gerenciamento mais eficiente de memória, além de possibilitar que equipes de desenvolvimento trabalhem na mesma aplicação efetivamente, como resultado disso uma simples aplicação pode conter uma quantidade enorme de arquivos INT ou GNT a serem distribuídos. Isso traz algumas dificuldades para o gerenciamento da distribuição dessas aplicações, em comparação às aplicações linkadas em um único executável. Dando importância a esse detalhe, a Micro Focus então introduziu o conceito de library (lbr) files. Uma ferramenta chamada Library Manager foi criada permitindo aos desenvolvedores distribuírem diversos arquivos GNT e INT dentro de um único arquivo LBR. Ao invés de múltiplos arquivos INT e GNT, o desenvolvedor tem que distribuir apenas um arquivo LBR (ou mais, se desejar) e o COBOL Runtime System.

DLL - Dynamic Link Library
Em meados de 80, quando a IBM lançou o OS/2, sistema operacional que promovia muitas facilidades no gerenciamento de memória, também foi introduzido o conceito de dynamic link libraries (DLL´s). Uma DLL é um arquivo executável linkado que pode ser carregado dinamicamente por um programa quando necessário. E qual a importância desses arquivos para os desenvolvedores COBOL ? O uso de arquivos INT e GNT é perfeito se você desenvolve unicamente em COBOL e o COBOL Runtime System oferece todo o suporte adicional necessário para isso. Porém, se você deseja utilizar múltiplas linguagens de programação ou se você necessita chamar rotinas do sistema operacional que não são acessíveis utilizando o COBOL Runtime System, compilar programas para INT ou GNT não seria o mais conveniente, como você verá a seguir.

A utilização de API´s do sistema operacional
O Windows e o OS/2 trouxeram aos desenvolvedores o conceito de interface para programação de aplicações (Application Programming Interface - API). São funções que permitem escrever um programa utilizando uma linguagem de alto nível para acessar diretamente os recursos do sistema operacional. Para oferecer acesso a essa enorme variedade de funções API aos desenvolvedores COBOL, a Micro Focus vem adicionando recursos à linguagem COBOL desde os anos 80, que possibilitam aos desenvolvedores fazerem chamadas diretas às API´s. Porém, o uso de arquivo INT e GNT traziam um problema para acessar essas API´s, pois todas elas se encontram em arquivos DLL. Por padrão, para acessar uma API você precisa linkar a sua aplicação com um import library para a DLL que contém a API. Uma import library contém um código que localiza cada função em tempo de execução e a torna acessível para uma aplicação. Pelo fato de arquivos INT e GNT não serem linkados, teoricamente não seria possível a esses programas localizarem a API desejada. Apesar da teoria, sabemos que a Micro Focus oferece mecanismos alternativos para acessar API´s a partir de arquivos INT ou GNT, mas o modo mais eficiente de acessar uma API seria realmente compilar o programa para um OBJ e linká-lo com a import library correspondente.

Você também achará mais fácil utilizar arquivos DLL se estiver desenvolvendo aplicações que utilizam diferentes linguagens de programação.

E qual formato executável deve ser utilizado ?
Diante de tantos formatos diferentes de arquivos executáveis que você pode criar utilizando o Micro Focus COBOL, pode ser difícil decidir qual deles utilizar. As linhas a seguir podem lhe ajudar na escolha, mas isso também pode depender de alguns detalhes em particular de cada aplicação.

Portabilidade versus performance
Um código escrito em Micro Focus COBOL é praticamente portável sobre todas as plataformas existentes, considerando, é claro, que nenhuma chamada a uma API foi feita para um sistema operacional específico. Para isso, o código-fonte COBOL simplesmente deve ser compilado pelo Micro Focus COBOL para cada uma das plataformas.

Arquivo INT são totalmente portáveis. Um arquivo INT compilado para uma aplicação desenvolvida originalmente em uma plataforma Windows pode ser portado para diversas outras plataformas, como Sun Solaris, HP/UX, Linux e muitas outras plataformas UNIX. Se essa noção de portabilidade parece ser familiar, deve ser porque o JAVA chamou muita atenção com o conceito de "write once, run anywhere" (escreva uma vez, execute em qualquer lugar). Esse conceito não é novo para a Micro Focus, que já possibilitava aos desenvolvedores fazerem isso há mais de 20 anos.

O lado negativo de um arquivo INT é a performance. Pelo fato de ser interpretado, a performance nem sempre á tão boa quanto a de um arquivo GNT. O nível de performance pode variar, dependendo da funcionalidade da sua aplicação. Se sua aplicação gasta um pequeno tempo lendo ou gravando arquivos ou aguardando por alguma digitação do usuário, então a diferença de performance entre o arquivo INT e o arquivo GNT dificilmente deve comprometer a sua aplicação. Porém, se sua aplicação executa uma quantidade expressiva de cálculos e outras operações, então a diferença de performance pode ser muito significante.

Se sua aplicação foi desenvolvida para ser distribuída em diversas plataformas e não faz uso de algum recurso específico de um sistema operacional, então o uso de arquivos INT é recomendável. Apenas você pode determinar se a performance na utilização de arquivos INT atende às suas necessidades.

Arquivos GNT ou DLL ? O que utilizar ?
Se você pretende distribuir sua aplicação em uma plataforma única ou se a performance é um ponto crítico em seu sistema, então não considere a criação de arquivos INT. A próxima decisão é saber quando utilizar arquivos GNT ou DLL.

Se você já utiliza o Micro Focus COBOL há algum tempo e faz uso de arquivos GNT, então mantenha sua opção. Principalmente se você não necessita acessar API´s ou funções escritas em outras linguagens.

Se você está migrando para o Micro Focus COBOL ou se possui uma aplicação que faz uso de API´s ou funções de outras linguagens, então você deve considerar o link de sua aplicação em um arquivo EXE e seus sub-programas em arquivos DLL.

Minhas considerações
O texto escrito acima foi traduzido e resumido do seu original, no site da Micro Focus (www.microfocus.com). O texto é de autoria de Wayne Rippin. É um texto do ano de 2002 e de lá pra cá muita coisa mudou no compilador da Micro Focus, nos equipamentos, nas linguagens. Eu, particularmente, já utilizei quase todos os tipos de arquivos descritos anteriormente. A opção atual em minha empresa é a utilização de um executável principal (EXE) e a chamada às minhas sub-rotinas é feita em arquivos GNT. As classes que crio em minhas aplicações (POO) também são geradas em arquivos GNT. Algumas bibliotecas de funções específicas dos meus sistemas encontram-se em arquivos DLL. O "mix" entre todas essas opções de arquivos é perfeitamente possível, como você pode observar. Resta ao desenvolvedor determinar que tipo de arquivo melhor se encaixa de acordo com as necessidades de cada aplicação. Eu diria até que seria extremamente válido experimentar cada um desses tipos e saborear aquele que melhor gosto teve para o desenvolvedor.

Agora eu aguardo as considerações de vocês. As opiniões serão muito bem vindas.

6 comentários:

Anônimo disse...

Meu Caro Amigo Alexandre.
Que Matéria foi essa ??
Parabéns !!!! Continue assim.
Seu blog já está no meu Favorito e o consulto sempre que preciso de alguma ajuda.

Valeu !!!!

André R. Bononi
Sertãozinho - SP

Antonio João disse...

Good, very very good!

E eu diria mais:

Good, very very good!

Faz um tempo que eu quero perguntar isso no clube.

Obrigado!

Anônimo disse...

Oi, achei seu blog pelo google está bem interessante gostei desse post. Gostaria de falar sobre o CresceNet. O CresceNet é um provedor de internet discada que remunera seus usuários pelo tempo conectado. Exatamente isso que você leu, estão pagando para você conectar. O provedor paga 20 centavos por hora de conexão discada com ligação local para mais de 2100 cidades do Brasil. O CresceNet tem um acelerador de conexão, que deixa sua conexão até 10 vezes mais rápida. Quem utiliza banda larga pode lucrar também, basta se cadastrar no CresceNet e quando for dormir conectar por discada, é possível pagar a ADSL só com o dinheiro da discada. Nos horários de minuto único o gasto com telefone é mínimo e a remuneração do CresceNet generosa. Se você quiser linkar o Cresce.Net(www.provedorcrescenet.com) no seu blog eu ficaria agradecido, até mais e sucesso. If is possible add the CresceNet(www.provedorcrescenet.com) in your blogroll, I thank. Good bye friend.

Anônimo disse...

Nossa,

Perfeito o artigo. Já estou estudando a possibilidade de migrar o sistema para arquivos GNT.

Obrigado pelos esclarecimentos

Unknown disse...

Alex
Estou utilizando sua idéia de interceptar o "extfh" e "maperar" os "reads", "writes", etc para Sql acessando atualmente Mysql e Postgres. Para isto construi duas interfaces em C, uma para cada banco. Uso para "comunicação" entre o Cobol e o C um sistema de "mensageria" baseado em arquivos "fifo". O sistema funciona de modo "estável", mas "muito lento", principalmente no Windows, que preciza da "emulação do bash" para executar. Para resolver o problema, eu acho que a melhor solução seria o programa em Cobol chamar diretamente (call), tanto na plataforma Linux como no Windows os programas em C, só que não sei como fazer isto.
Voce poderia me ajudar?
Grato
Sergio. netmorais@bol.com.br

Anônimo disse...

mas dá para editar aquivos .int?