Mostrando postagens com marcador Runtime. Mostrar todas as postagens
Mostrando postagens com marcador Runtime. Mostrar todas as postagens

quinta-feira, 31 de janeiro de 2008

O segredo do External File Handler

Aprendendo sobre alguns recursos do compilador Microfocus, é possível acessar bancos de dados sem mexer numa única linha de código dos seus programas que acessam arquivos indexados. Sim, isso é possível. Continue usando "read", "start", "open", mas tenha em suas mãos o banco de dados de sua preferência.

Esse artigo foi escrito baseado na versão 3.0 e 3.1 do NetExpress.

Conhecendo o External File Handler
Quando escrevemos em nossos programas comandos de acesso a um arquivo, um "open", um "read" ou um "start", o compilador converte esses comandos em chamadas para o executável EXTFH.EXE. Esse é o executável do runtime que realiza todas as operações de arquivos no compilador Microfocus. As chamadas são feitas exatamente como no código a seguir:

call "EXTFH" using Operacao DadosDoArquivo

Um código específico é enviado ao EXTFH quando efetuamos, por exemplo, um "open" em um arquivo. Além do código específico da operação, os dados do arquivo são passados através de uma estrutura de dados, que se encontra no arquivo XFHFCD.CPY, um "copybook file" que pode ser copiado em qualquer fonte Cobol. Esse arquivo encontra-se na pasta SOURCE, dentro da pasta de instalação do NetExpress.

A estrutura de dados XFHFCD.CPY
No arquivo de ajuda do Microfocus NetExpress não existem muitas informações sobre a estrutura de dados encontrada no arquivo XFHFCD.CPY, infelizmente. Porém, com um pouco de paciência, o desenvolvedor vai encontrar a descrição de alguns dos campos dessa estrutura, além da relação completa dos códigos que identificam as operações de arquivos passadas para o EXTFH.

Criando seu próprio External File Handler
O compilador Microfocus permite que o desenvolvedor crie seu próprio External File Handler. Assim, todas as chamadas das operações de arquivos serão feitas para esse programa. Com esse recurso, o desenvolvedor pode "interceptar" as operações de um determinado arquivo e intepretá-las da forma que desejar. A diretiva CALLFH indica qual programa deve ser chamado para interpretar as operações de arquivo:

$SET CALLFH"MEUFH"

Com essa diretiva definida em um programa, todas as operações de arquivos nesse programa serão convertidas para o código a seguir:

call "MEUFH" using Operacao DadosDoArquivo

O programa MEUFH.CBL
No exemplo a seguir, o programa MEUFH.CBL recebe os dados do programa chamador e simplesmente faz a chamada para o EXTFH, que é o External File Handler padrão da Microfocus, sem fazer qualquer alteração nas operações de arquivos:

program-id. MEUFH.

linkage section.
01 lnkOperacao pic xx.
01 lnkDadosDoArquivo.
copy "XFHFCD.CPY".

procedure division using lnkOperacao lnkDadosDoArquivo.

....call "EXTFH" using lnkOperacao lnkDadosDoArquivo
....exit program.

Obtendo outras informações do arquivo
Adicionando algumas linhas, poderíamos obter outras informações do arquivo:

program-id. MEUFH.

working-storage section.
77 wsTamanhoDoRegistro pic 9(09) comp-5.

linkage section.
01 lnkOperacao pic xx.
01 lnkDadosDoArquivo.
copy "XFHFCD.CPY".

01 lnkNomeDoArquivo pic x(1024).
01 lnkRegistro pic x(32767).

procedure division using lnkOperacao lnkDadosDoArquivo.
....*> Para saber o nome do arquivo
....set address of lnkNomeDoArquivo to fcd-filename-address

....*> Para saber o tamanho do registro
....move fcd-current-rec-len to wsTamanhoDoRegistro

....*> Para pegar o conteúdo do registro que foi passado
....set address of lnkRegistro to fcd-record-address

....call "EXTFH" using lnkOperacao lnkDadosDoArquivo
....exit program.

Acessando tabelas de um banco de dados
Com as informações básicas descritas acima, o desenvolvedor poderia identificar qual operação foi requisitada e em qual arquivo essa operação seria efetuada. Identificada a operação, bastaria efetuar no mesmo programa MEUFH.CBL, chamadas a parágrafos ou rotinas que processariam a operação específica, porém, utilizando a tabela correspondente em um banco de dados. utilizando e atualizando a variável que corresponde ao registro do arquivo, ao retornar para o programa chamador, todos os dados estariam devidamente atualizados, sem a necessidade real de qualquer alteração no programa que contém os comandos "open", "read" ou "start".

Exemplos práticos
Aos desenvolvedores que pesquisarem sobre esse assunto e conseguirem resultados práticos, sintam-se à vontade para enviarem seus materiais, projetos e programas, para que eu possa publicá-los e assim ajudar a outros desenvolvedores que desejam utilizar os mesmos recursos. Compartilhando a informação, teremos sempre o melhor do que a linguagem pode nos oferecer. Estarei sempre contando com a colaboração de vocês.

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.