Considerações de portabilidade para programas Natural
Autora: Maria Alexandra V. C. da Cunha
A CELEPAR avança no conhecimento do universo ADABAS/NATURAL em outras plataformas que não IBM.
Estamos testando uma aplicação mainframe em ADABAS/NATURAL sob OS/2 em um PC-486. Na máquina RISC/AIX, o 1º projeto é simularmos o ambiente de desenvolvimento da CELEPAR, tentando que o nosso analista ou programador consiga desenvolver os seus programas neste ambiente via uma estação da Rede Novell, de forma transparente. Em desenvolvimento, uma parceria HP, CONSIST e CELEPAR, cujos objetivos são:
- Adquirir conhecimento na migração de aplicações Adabas do mundo IBM para o mundo UNIX;
- Avaliação do desempenho da aplicação no novo ambiente;
- Transparência de acesso (um terminal 3270 IBM acessar uma aplicação no UNIX de forma transparente, e vice-versa) e
- Processamento cooperativo entre aplicações IBM e UNIX.
Neste contexto, julgamos oportuno a reprodução do artigo da Trends e News, a publicação técnica da Consist, em janeiro de 1993.
"O NATURAL é uma linguagem portável. Essa portabilidade diz respeito a uma variedade de ambientes distintos, como IBM mainframe, VAXes e Pcs com OS/2.
Contudo, para obter esta portabilidade de modo total, deve-se ter em mente alguns detalhes ao projetar e codificar suas aplicações.
Esses detalhes não surgem em função das diferenças na implementação do NATURAL, mas sim em função das diferenças nos hardwares e na maneira de representar e armazenar informações.
CONSTANTES EM HEXADECIMAL
Esse é o caso mais comum e óbvio. Ao se preencher campos alfanuméricos com constantes em hexa, seu significado será diferente entre máquinas que usem EBCDIC ou ASCII. Por exemplo: um branco é representado por H'20' em ASCII e por H'40' em EBCDIC.
O mesmo é válido para leituras seqüenciais. Em máquinas que usam ASCII, números são menores que caracteres, em EBCDIC são maiores. Assim, um comando codificado num IBM do tipo
"READ arquivo BY campo = 'AA' THRU '99"'
não funcionará adequadamente num VAX ou num PC.
REDEFINIÇÃO EM CAMPOS HEXADECIMAIS
Existe uma diferença importante na maneira em que são armazenados os campos hexa em EBCDIC e ASCII.
Por exemplo:
"MOVE 1 TO B-FIELD (B2) REDEFINE B-FIELD (FIRST-BYTE (B1)
LAST-BYTE (B1))
DISPLAY FIRST-BYTE LAST-BYTE"
Este código vai mostrar '01 00' em máquinas que usam ASCII e '00 01' em máquinas que usam EBCDIC.
O que há de errado neste tipo de programação não é usar-se campos binários, mas sim redefini-los! A redefinição sempre depende de como o hardware armazena seus dados.
CAMPOS BINÁRIOS EM SUPER-DESCRITORES
Se você usa campos alfanuméricos e binários em super-descritores, pode surgir outro problema. O super-descritor terá formato alfanumérico, o que quer dizer que será tratado da esquerda para a direita.
Em ASCII, campos binários devem ser tratados da direita para a esquerda.
Por exemplo:
fontes NATURAL usam superdescritor composto de:
LIBRARY (A8)
MEMBER (A8)
SEQUENCE (B2)
onde SEQUENCE varia de H'0000' a H' F F F F ' para programas com mais de um registro no ADABAS. Em máquinas que usam ASCII, se você começa uma seqüência com H'0000' e soma 1 para obter o próximo registro, o resultado será H'0100'.
Assim, se você tiver campos binários como parte de super-descritores, deve tomar cuidado com esse detalhe.
CAMPOS BINÁRIOS E NET-WORK
Ao usar o NETWORK em redes heterogêneas consistidas de máquinas que utilizem ASCII e EBCDIC, o NET-WORK faz a conversão devida para os campos numéricos e alfanuméricos. Até então, tudo certo. Porém, se algum campo alfanumérico contém dados binários, porque foi redefinido, e é usado de modo diferente do declarado na FDT, os resultados serão inesperados.
Na versão atual do NET-WORK, os super-descritores alfanuméricos são convertidos como tal. Isso significa que se ele tiver algum componente binário, não poderá ser usado corretamente via NET-WORK (espera-se correção para versão futura).
ALGUMAS DICAS ADICIONAIS
Procure evitar truques ou recursos de programação não documentados, pois será grande a probabilidade de não funcionarem em outros ambientes.
Atenção para o modo como os objetos NATURAL são armazenados. É diferente para cada ambiente. Por exemplo, fontes NATURAL usam dois bytes para número de linha no IBM, um byte no VAX.
No UNIX e OS/2 sequer são armazenados no ADABAS.
Não use os nomes ADABAS de dois caracteres para programação. Há problemas de interpretações diferentes para os Format Buffers, podendo causar erro. Programe usando o nome de campo que estiver na DDM e não haverá problema."
Maria Alexandra da Cunha - GPT
Extraído do Trends & News - CONSIST jan/93
A CELEPAR avança no conhecimento do universo ADABAS/NATURAL em outras plataformas que não IBM.
Estamos testando uma aplicação mainframe em ADABAS/NATURAL sob OS/2 em um PC-486. Na máquina RISC/AIX, o 1º projeto é simularmos o ambiente de desenvolvimento da CELEPAR, tentando que o nosso analista ou programador consiga desenvolver os seus programas neste ambiente via uma estação da Rede Novell, de forma transparente. Em desenvolvimento, uma parceria HP, CONSIST e CELEPAR, cujos objetivos são:
- Adquirir conhecimento na migração de aplicações Adabas do mundo IBM para o mundo UNIX;
- Avaliação do desempenho da aplicação no novo ambiente;
- Transparência de acesso (um terminal 3270 IBM acessar uma aplicação no UNIX de forma transparente, e vice-versa) e
- Processamento cooperativo entre aplicações IBM e UNIX.
Neste contexto, julgamos oportuno a reprodução do artigo da Trends e News, a publicação técnica da Consist, em janeiro de 1993.
"O NATURAL é uma linguagem portável. Essa portabilidade diz respeito a uma variedade de ambientes distintos, como IBM mainframe, VAXes e Pcs com OS/2.
Contudo, para obter esta portabilidade de modo total, deve-se ter em mente alguns detalhes ao projetar e codificar suas aplicações.
Esses detalhes não surgem em função das diferenças na implementação do NATURAL, mas sim em função das diferenças nos hardwares e na maneira de representar e armazenar informações.
CONSTANTES EM HEXADECIMAL
Esse é o caso mais comum e óbvio. Ao se preencher campos alfanuméricos com constantes em hexa, seu significado será diferente entre máquinas que usem EBCDIC ou ASCII. Por exemplo: um branco é representado por H'20' em ASCII e por H'40' em EBCDIC.
O mesmo é válido para leituras seqüenciais. Em máquinas que usam ASCII, números são menores que caracteres, em EBCDIC são maiores. Assim, um comando codificado num IBM do tipo
"READ arquivo BY campo = 'AA' THRU '99"'
não funcionará adequadamente num VAX ou num PC.
REDEFINIÇÃO EM CAMPOS HEXADECIMAIS
Existe uma diferença importante na maneira em que são armazenados os campos hexa em EBCDIC e ASCII.
Por exemplo:
"MOVE 1 TO B-FIELD (B2) REDEFINE B-FIELD (FIRST-BYTE (B1)
LAST-BYTE (B1))
DISPLAY FIRST-BYTE LAST-BYTE"
Este código vai mostrar '01 00' em máquinas que usam ASCII e '00 01' em máquinas que usam EBCDIC.
O que há de errado neste tipo de programação não é usar-se campos binários, mas sim redefini-los! A redefinição sempre depende de como o hardware armazena seus dados.
CAMPOS BINÁRIOS EM SUPER-DESCRITORES
Se você usa campos alfanuméricos e binários em super-descritores, pode surgir outro problema. O super-descritor terá formato alfanumérico, o que quer dizer que será tratado da esquerda para a direita.
Em ASCII, campos binários devem ser tratados da direita para a esquerda.
Por exemplo:
fontes NATURAL usam superdescritor composto de:
LIBRARY (A8)
MEMBER (A8)
SEQUENCE (B2)
onde SEQUENCE varia de H'0000' a H' F F F F ' para programas com mais de um registro no ADABAS. Em máquinas que usam ASCII, se você começa uma seqüência com H'0000' e soma 1 para obter o próximo registro, o resultado será H'0100'.
Assim, se você tiver campos binários como parte de super-descritores, deve tomar cuidado com esse detalhe.
CAMPOS BINÁRIOS E NET-WORK
Ao usar o NETWORK em redes heterogêneas consistidas de máquinas que utilizem ASCII e EBCDIC, o NET-WORK faz a conversão devida para os campos numéricos e alfanuméricos. Até então, tudo certo. Porém, se algum campo alfanumérico contém dados binários, porque foi redefinido, e é usado de modo diferente do declarado na FDT, os resultados serão inesperados.
Na versão atual do NET-WORK, os super-descritores alfanuméricos são convertidos como tal. Isso significa que se ele tiver algum componente binário, não poderá ser usado corretamente via NET-WORK (espera-se correção para versão futura).
ALGUMAS DICAS ADICIONAIS
Procure evitar truques ou recursos de programação não documentados, pois será grande a probabilidade de não funcionarem em outros ambientes.
Atenção para o modo como os objetos NATURAL são armazenados. É diferente para cada ambiente. Por exemplo, fontes NATURAL usam dois bytes para número de linha no IBM, um byte no VAX.
No UNIX e OS/2 sequer são armazenados no ADABAS.
Não use os nomes ADABAS de dois caracteres para programação. Há problemas de interpretações diferentes para os Format Buffers, podendo causar erro. Programe usando o nome de campo que estiver na DDM e não haverá problema."
Maria Alexandra da Cunha - GPT
Extraído do Trends & News - CONSIST jan/93