Você está em: Soluções » CONNECTware » Qualquer linguagem trata arquivo COBOL a custo zero.
Qualquer linguagem trata arquivo COBOL a custo zero.
Uma dica para os caros colegas COBOLeiros, recomendo ter paciência para ler tudo. A área de TI de muitas empresas pode mudar “da água para o vinho” quando mais profissionais dominarem essa técnica no Brasil.
Não sei se já repararam mas todos os comandos de operação de I/O são convertidos pelo compilador em chamadas a um manipulador padrão de arquivos o EXFFH no caso de acessos locais e o FHRDIR para acesso via Fileshare, bem eu particularmente uso somente o FHREDIR pois ele é mais versátil já que por configuração também acessa arquivos locais, isso é feito com a diretiva de compilação CallFH que define qual manipulador o compilador deve utilizar (CallFH”FHREDIR”).
Bem, isso torna a base de dados da arquitetura do Micro Focus COBOL aberta (vale também para Microsoft COBOL a partir da versão 3), sendo possível então que terceiros possam escrever manipuladores para acessarem outras bases de dados, com os programas permanecendo inalterados a exemplo do que foi feito para BTRIEVE.
Para atender a demanda por acesso a bancos de dados dos clientes da COBOLware, escrevi o manipulador CWSQLC, utilizado da diretiva CallFH “CWSQLC” que no momento da abertura dos arquivos verifica em uma tabela se o arquivo deve ser tratado em ISAM, em Oracle ou em DB2, repassando a tarefa para o manipulador apropriado para o arquivo ou tabela isso me proporcionou a oportunidade de conhecer melhor o processo de tratamento de arquivos e gostaria de compartilhar um pouco desse conhecimento que me parece bem valioso.
No caso de tratamento em ISAM o CWSQLC repassa as tarefas os manipuladores FHREDIR ou EXTFH evitando que o servidor FIleshare trate arquivos de trabalho em memória (Heap files) que ao meu ver devem ser tratados pelas estações e nunca pelo servidor como o FHRDIR faz, realizando de forma configurável e opcional o tratamento automático de erros de File Status. De quebra, os relatórios são capturados e direcionados para spool automaticamente, inspirado no VSE/POWER.
Desse modo, na mesma compilação e com a forma de programar tradicional do COBOL, um programa pode ser utilizado por empresas que tenham Oracle ou DB2 ou não tenham banco nenhum.
O interessante é que este FHREDIR é uma DLL de 32-bit que pode então ser usada também por qualquer “linguagem Windows” Isso é aberto e bem documentado pela Micro Focus, mas creio que por dificuldades com a língua inglesa fazem com que os programadores COBOL e o mesmo de outras linguagens que gostariam ter acesso as bases de dados COBOL em sua maioria desconheçam esse recurso.
Gostaria de fazer uma contribuição para os colegas COBOLeiros e para os interessados em acessar bases COBOL nativas utilizando a FHRDIR.DLL (é isso que faz o Connectware, U/SQL, Relativity e CObjects) com um resumo com dicas e exemplos.
As chamadas a um manipulador padrão Micro Focus (EXTFH, FHREDIR, CWSQLC) são especificados assim:
CALL “manipulador” USING OPCODE FCD
OPCODE é o código da operação a ser realizada e FCD é a File Control Description (uma compilação das declarações da SELECT do arquivo).
Quando o um programa tem declarado por exemplo:
OPEN I-O FileName
O compilador Micro Focus passa para o runtime o equivalente:
SET OP-OPEN-IO TO TRUE
CALL “FHREDIR” USING OPCODE FileName
Repare que o nome do arquivo (FileName) está sendo passado como parâmetro para a chamada ao manipulador, isso equivale a FCD, um programa COBOL pode então passar uma FCD para outro programa COBOL que pode então usar uma lógica padrão para tratar o arquivos sem conhecer previamente a sua estrutura (sem declarações SELECT/FD), coisa normalmente considerada impossível pelos programadores COBOL.
Tendo em mente que COBOL é um assembler disfarçado remova da sua “memória principal” o conceito de que “não dá para fazer isso ou aquilo em COBOL”, dá sim, qualquer coisa que um computador possa fazer pode ser codificada em COBOL, se quiséssemos poderíamos escrever o Window, o Linux, o Delphi, compilador C#, o próprio compilador COBOL, enfim a gente pode não saber fazer ou não valer a pena fazer mas que é possível fazer em COBOL é, as limitações estão na utilização e não na linguagem, talvez seja necessário atualizar sua versão de compilador e/ou seus conhecimentos, mudar de linguagem é tempo perdido.
Feito isso observe esse outro detalhe:
A LINKAGE SECTION, seção de ligação é normalmente utilizada para trocar parâmetros entre programas COBOL <=> COBOL e COBOL <=> outras linguagens, mas a LINKAGE SECTION também pode ser usada para que o programa chamado acesse qualquer posição da memória basta que o programa chamado tenha conhecimento do endereço e do tamanho do que se deseja manipular (isso é assembler) e com esse recurso você pinta e borda na memória e vira qualquer computador do avesso.
Note que o campo FCD-RECORD-ADDRESS tem a USAGE POINTER isso indica que ele é capaz de armazenar o endereço de uma variável, pois bem, quando um campo é definido na LINKAGE SECTION ele é apenas um LAYOUT ele não existe fisicamente na memória da rotina (termo “rotina” apenas porque chamador é muito parecido com chamado), ele existe de fato somente na memória do programa chamador, a cláusula USING utilizada no comando CALL passa os endereços das variáveis do programa chamador para a rotina que com o USING de sua PROCEDURE DIVISION “endereça” seus parâmetros, que passam então a serem acessíveis pelo programa chamado.
Quando uma rotina precisa acessar uma variável pelo endereço já que o nome e o tamanho são definidos somente em tempo de execução definimos então a variável na LINKAGE SECTION com qualquer tamanho, PIC X(1) por exemplo, nesse caso a variável nem precisa ser citada no USING da PROCEDURE DIVISION da rotina nem será referenciada no CALL do programa chamador.
Serão referenciados normalmente é claro as variáveis que contenham o endereço e o tamanho dos itens “indefinidos” a serem tratados.
Um manipulador (Micro Focus pelo menos pois não tenho conhecimento de que outros ambientes ou linguagens usem ou não definições nesse formato) recebe então pela FCD os parâmetros de Identificação da abertura, buffer da FD, label(nome externo do arquivo) e definição das chaves na forma de endereços.
Não é difícil em COBOL obter o endereço de uma variável, utiliza-se o comando SET e a função LENGTH para se obter o tamanho do registro. Quando um manipulador precisa acessar por exemplo o buffer da FD ele faz algo como:
LINKAGE SECTION.
01 OPCODE vide descrição acima.
01 FCD vide descrição acima.
01 REGISTRO PIC X.
ROCEDURE DIVISION USING OPCODE FCD.
SET ADDRESS OF REGISTRO TO FCD-RECORD-ADDRESS
A partir daqui a referencia REGISTRO passa a ser válida para referenciar o buffer da FD do programa chamador
por exemplo; MOVE REGISTRO (1: FCD-CURRENT-REC-LEN) TO ...., registro tem PIC X mas a referencia posicionada é autorizada a acessar toda a memória disponível a partir do endereço, por isso se deve ter cuidado ao se utilizar referencias posicionadas para não invadir memória não autorizada (o famigerado erro 114).
Já o programa que está chamando o manipulador em ”low-level” teria algo como:
SET FCD-RECORD-ADRESS TO ADDRESS OF CADSTRO-REG
MOVE LENGTH CADSTRO-REG TO FCD-CURRENT-REC-LEN
SET OP-operação-desejada TO TRUE
CALL “manipulador” USING OPCODE CADASTRO
Nunca me envolvi com outras linguagens o suficiente para poder ajudar os programadores de outras linguagem a acessarem arquivos ISAM Micro Focus, sempre achei mais prático recomendar o Connectware que via ODBC trata as bases ISAM via SQL que está mais de acordo com a cultura desses programadores. Então indico aqui a documentação em inglês da Micro Focus que detalha como chamar um manipulador de arquivos (File Handler) inclusive com um exemplo em C, bem creio que nessas linguagens mais científicas ou tecnocráticas a forma de chamar o manipulador seja bem parecido com a forma do C.
Exemplo em C:
#define XFH_CLOSE_FILE 0xFA80
#define XFH_OPEN_NEW_INDEX 0x0007
#define XFH_GET_NEXT_REC 0x0008
#define XFH_ADD_KEY_VALUE 0x0009
main()
{
put2ws(op_code,XFH_OPEN_NEW_INDEX);
EXTFH(op_code,&fcd);
put2ws(op_code,XFH_GET_NEXT_REC);
EXTFH(op_code,&fcd);
while(status[0] == '0');
{
get2ws(fcd.key_count,num_keys);
i=0;
while(i num_keys && status[0] == '0')
{
put2ws(fcd.key_id,i++);
put2ws(op_code,XFH_ADD_KEY_VALUE);
EXTFH(op_code,&fcd);
}
put2ws(op_code,XFH_GET_NEXT_REC);
EXTFH(op_code,&fcd);
}
put2ws(op_code,XFH_CLOSE_FILE);
EXTFH(op_code,&fcd);
}
Dizem que sou defensor do COBOL ou vendedor de COBOL, não é bem isso eu apenas e francamente lamento pelo desperdício de inteligência quando um programador opta por outra linguagem “mais moderna” mas que o limita castrando a sua carreira profissional umas porque não rodam no Windows, outras porque não rodam no Linux, outras porque não rodam em Maiframes, e outras porque são muito lentas no tratamento de grandes volumes de dados, outras porque ninguém entendo o programa escrito e na hora da manutenção acaba sendo jogado fora, e COBOL está aí a meio século, oferecendo embrenhado em tudo isso de forma veloz, legível, portável, configurável e durável.
Deixam de conhecer ou até mesmo abandonam a linguagem por falta de conhecimento por que pensam que a linguagem não tem orientação a objetos, ou interface gráfica, ou não acessa bancos de dados ou não tem integração com a Internet o que não faz isso ou aquilo, mas faz e faz bem antes e melhor do que as outras e com várias opções de fornecedor, só o que não “sabe fazer” é se auto-promover, não precisa é a linguagem de programação mais importante, quem perde não é a linguagem COBOL o perdedor é o programador que não a conhece ou a empresa que não teve a sorte de optar por ela.