A abordagem de correspondência simplifica a introdução de novas linguagens em um computador. O conjunto de instruções MI é semelhante à forma intermediária comum usada em compiladores. Um compilador de linguagem de alto nível gera a forma MI do programa. Um tradutor abaixo dessa forma realiza otimizações e gera as instruções IMPI ou PowerPC. Esse tradutor é bastante semelhante à parte final de um compilador.

O conjunto de instruções MI não substitui completamente a forma intermediária comum em todos os compiladores AS/400. Alguns compiladores AS/400 possuem suas próprias formas intermediárias, enquanto outros não. A descrição dos detalhes internos dos compiladores de linguagem AS/400 ilustra como o MI se insere nas operações gerais do compilador.

Nos primeiros compiladores de linguagem do System/38 e do AS/400, as instruções MI eram geradas de maneira bastante direta. Embora o processo envolvesse um nível de montagem, não existia uma forma intermediária comum dentro do próprio compilador. As instruções MI eram a própria forma intermediária. Exemplos desse tipo de compilador incluem aqueles usados para RPG/400 e CL, a linguagem de comando do AS/400. O modelo de programa para essas linguagens, incluindo a forma do programa abaixo do MI, é denominado Modelo Original de Programa (OPM).

O processo de criação de código IMPI segue uma sequência clara: o compilador da linguagem recebe as instruções de alto nível (junto com descrições de arquivos) como entrada e gera o código IRP, ou Representação Intermediária de um Programa, que é essencialmente a forma de montagem das instruções MI. O próximo passo converte o código IRP nas instruções MI. A operação que realiza essa conversão é chamada Monitor de Resolução de Programas (PRM). O PRM cria um modelo de programa que contém o fluxo de instruções MI e outros dados. Modelos de programa são usados para criar objetos MI. Esse modelo é então processado pelo tradutor para criar o objeto de programa que conterá as instruções IMPI. Este modelo clássico do OPM mostra o compilador gerando a forma de montagem do programa (o IRP) antes que o assembler (o PRM) gere o nível binário da máquina (o modelo do programa). O tradutor funciona como uma etapa adicional nesse processo. A compilação no AS/400 exige esses passos extras, o que explica, em parte, o tempo de execução mais longo em comparação com outros sistemas.

Com a implementação de novas linguagens como C/400 e Pascal no AS/400, foram necessárias algumas extensões ao OPM para acomodar os novos compiladores de linguagem. Esses compiladores são implementados com componentes separados: a frente e a parte final. A forma intermediária comum dentro desses compiladores passou a ser chamada de U-code. Para o AS/400, foi criado um novo backend para compiladores, chamado de Common Use Back End 1 (CUBE-1). O EPM não substituiu o OPM, mas se sobrepôs a ele.

O OPM, baseado no modelo do System/38 e projetado para RPG e COBOL, oferecia suporte limitado para linguagens de programação estruturadas, como C e Pascal. Essas linguagens, estruturadas em blocos, permitem um estilo de programação modular. Em vez de exigir que um programa fosse escrito como uma unidade única, elas possibilitam que o programa seja desenvolvido em blocos menores, interconectados por instruções de chamada. O EPM viabilizou a implementação dessas linguagens, mas, devido à falta de alterações no MI para suportar muitas chamadas, ainda havia uma penalidade de desempenho ao se iniciar ou chamar um programa EPM.

Inicialmente, o único tipo de instrução de chamada suportado pelo MI era a chamada externa. Esse tipo de chamada é dinâmica, o que significa que todas as referências são resolvidas em tempo de execução, um processo conhecido como late binding. Embora as chamadas dinâmicas sejam as mais flexíveis, elas têm impacto no desempenho. Além disso, o OPM só suportava uma linguagem por objeto de programa, o que forçava o uso de chamadas externas entre objetos de programa quando parte do código era escrito em uma linguagem diferente.

Para melhorar o desempenho da programação modular e incentivar seu uso em todas as linguagens, uma melhoria arquitetural no MI e nos objetos abaixo dele foi criada. Introduzida em 1993, essa melhoria ficou conhecida como Ambiente de Linguagem Integrado (ILE). O ILE inclui novos compiladores de linguagem, um tradutor otimizado e um novo mecanismo de ligação para criar programas embalados. O ILE altera a maneira como os programas são criados. Ao contrário do OPM, a saída do tradutor ILE não é um objeto de programa; ela é um novo objeto chamado módulo. O vinculador do ILE agrupa esses módulos para formar programas.

Além de suportar as chamadas dinâmicas do OPM, o ILE introduziu a capacidade de vinculação em tempo de compilação. Essa vinculação antecipada (early binding) reduz a sobrecarga associada às chamadas dinâmicas externas, tornando as chamadas estáticas mais rápidas.

Para melhor compreender os termos envolvidos no ILE, é necessário entender algumas definições: Procedimento é uma sequência de declarações de código que pode ser chamada em um ponto de entrada com parâmetros opcionais. Módulo é um objeto que contém o código gerado pela compilação de ILE, sendo não executável e podendo conter um ou mais procedimentos. Programa é uma unidade executável de código composta por um ou mais módulos, podendo ter apenas um ponto de entrada e realizando chamadas estáticas dentro de si. Já o Serviço de Programa é uma unidade executável composta por um ou mais módulos, sendo ativado como uma unidade, mas tratado como um conjunto de procedimentos, podendo ter múltiplos pontos de entrada.

Esses conceitos definem o funcionamento modular e flexível do ILE, que trouxe melhorias no desempenho e na estruturação de programas. Esse modelo possibilita uma maior reutilização de código e facilita o desenvolvimento de sistemas complexos.

Como os Arquivos Lógicos Facilitam a Independência dos Dados e a Segurança em Sistemas AS/400

No ambiente AS/400, os arquivos lógicos oferecem uma maneira eficiente de separar a descrição dos dados do programa que os manipula. Isso permite uma flexibilidade considerável, tanto para os desenvolvedores quanto para os administradores de sistema, promovendo a independência dos dados em relação aos programas que os utilizam. O processo de criação de arquivos lógicos é realizado com o comando CRTLF, que utiliza as declarações DDS de um arquivo físico fonte como modelo para gerar o arquivo lógico. Esse arquivo lógico então conterá os números relativos dos registros de dados nos arquivos físicos nos quais se baseia, apresentando os dados no formato definido pelas descrições de campo do arquivo lógico.

Ao contrário dos arquivos físicos, que armazenam os dados efetivamente, os arquivos lógicos têm um papel mais voltado à organização e apresentação desses dados, possibilitando sua transformação, reordenação e filtragem. Em um arquivo lógico criado por meio de DDS, a estrutura dos dados pode ser completamente redefinida, permitindo, por exemplo, que campos específicos sejam excluídos ou reorganizados conforme a necessidade do programa. Já quando o arquivo lógico é criado usando SQL, a criação de vistas (views) e índices realiza operações de ordenação ou formatação, mas sem a mesma flexibilidade para reestruturar os dados como no método DDS.

Além disso, a interação com dados em sistemas AS/400 é facilitada por um componente essencial: o dicionário de dados. No contexto da interface nativa, esse dicionário é uma entidade que contém todas as descrições de componentes de arquivos físicos e lógicos no sistema. Ele serve como uma base centralizada de informações sobre a estrutura do banco de dados, permitindo aos desenvolvedores e usuários consultarem as características dos dados de qualquer parte do sistema. Em sistemas SQL, essa função é desempenhada pelo catálogo, que tem uma função semelhante, permitindo uma visão abrangente e organizada de todos os componentes de banco de dados. O catálogo no SQL, além de fornecer detalhes sobre os dados, também permite que desenvolvedores criem catálogos adicionais específicos para cada coleção SQL, permitindo uma organização ainda mais detalhada.

A independência entre os dados e os programas foi um dos pilares fundamentais no design do AS/400 e dos sistemas predecessores, como o System/38. Essa separação oferece uma flexibilidade vital, permitindo que programas operem com dados de diferentes formatos sem precisar conhecer os detalhes de sua implementação física. Essa abordagem é conhecida como "dados externamente descritos", o que significa que o programa não precisa conter as descrições dos dados, tornando possível a utilização de diferentes formatos de armazenamento sem que o código precise ser alterado.

Essa independência se estende aos arquivos lógicos, que funcionam como uma camada adicional que pode redefinir o formato do registro para que o programa os processe da maneira que espera. Um exemplo simples dessa flexibilidade pode ser observado em um arquivo lógico que altera a ordem de apresentação dos campos ou que omite determinados campos, oferecendo ao programa apenas as informações relevantes para sua operação. Essa característica também é crucial para implementar segurança a nível de campo, permitindo que certos usuários ou programas acessem apenas os dados que são autorizados a ver.

Outro ponto de destaque é a capacidade dos arquivos lógicos de compartilharem dados entre programas diferentes sem a necessidade de duplicação dos dados. Isso significa que qualquer atualização feita por um programa no arquivo físico será imediatamente visível para todos os outros programas que acessam o mesmo arquivo lógico, garantindo que os dados estejam sempre atualizados e consistentes em tempo real.

Em relação à segurança, a arquitetura do AS/400 permite que os dados sejam protegidos tanto no nível de registro quanto de campo. Além da possibilidade de omitir ou reordenar campos em arquivos lógicos, os desenvolvedores podem aplicar critérios de seleção para garantir que apenas registros específicos sejam acessados por determinados usuários. Caso um usuário tente acessar um caminho de acesso não autorizado, como um campo de informações sensíveis, o sistema falhará ao impedir o acesso, tornando os dados seguros contra acessos não autorizados.

A combinação de arquivos lógicos e a gestão de autorizações do sistema operacional AS/400 permite um controle robusto sobre a segurança dos dados. Através da gestão de permissões, é possível definir quem tem acesso a quais dados, seja no nível de operação de arquivos completos ou em funções específicas, como leitura ou gravação. Essa abordagem facilita a implementação de políticas de segurança refinadas, adaptadas às necessidades de cada usuário ou aplicação.

O papel dos arquivos lógicos no AS/400, portanto, vai muito além de simples mecanismos de organização de dados. Eles são a chave para a flexibilidade, a independência dos dados e a segurança no sistema, oferecendo aos desenvolvedores e administradores as ferramentas necessárias para gerenciar grandes volumes de dados de forma eficiente, segura e adaptável às necessidades das aplicações. A estrutura flexível dos arquivos lógicos, aliada ao controle rigoroso de acessos e à separação entre dados e programas, proporciona um ambiente robusto e eficiente para o desenvolvimento e a operação de sistemas corporativos complexos.

Como são implementadas as funções de banco de dados no AS/400?

A implementação das funções de banco de dados no AS/400 ocorre em uma arquitetura dividida, localizada em torno da fronteira do MI (Machine Interface). Como discutido anteriormente, grande parte do banco de dados está implementada no DB2 para OS/400, acima do MI, mas também existem objetos do sistema no nível do MI que são fundamentais para o funcionamento do banco de dados. Esses objetos MI são manipulados, em parte, por componentes do SLIC (System Licensed Internal Code), que fica abaixo do MI. Embora seja impossível detalhar todas as funções e características do banco de dados nesta análise, algumas das mais importantes e interessantes serão abordadas, destacando especialmente a implementação do índice da máquina (machine index), um componente crítico usado por diversas partes do AS/400.

O banco de dados suportado pelo SLIC é impressionantemente robusto, com limites técnicos notáveis: arquivos físicos podem chegar a até 240 gigabytes, com mais de 2 bilhões de registros por arquivo, índices de até 4 gigabytes e chaves de até 2.048 bytes. Esses limites são impostos pela implementação atual do SLIC, que é dependente da tecnologia utilizada. O MI, por sua vez, é tecnologicamente independente e, portanto, não impõe limitações intrínsecas ao tamanho dos objetos do sistema. Isso é resultado do fato de que estruturas internas do SLIC têm campos de tamanho fixo, o que cria limites máximos, porém o design prevê espaço para expansão conforme necessário.

Os objetos do sistema MI que dão suporte ao banco de dados são três: data spaces, índices de data spaces e cursores. Cada um desses objetos ocupa múltiplos segmentos na memória de nível único (single-level store). Cada objeto possui um segmento base com cabeçalhos específicos (segment header, EPA header e um cabeçalho customizado), além de segmentos associados, como os de espaço e os de registros.

Os data spaces contêm os registros do banco de dados, que são homogêneos e de comprimento fixo, armazenados na ordem de chegada. Registros excluídos continuam a ocupar espaço dentro do data space. Esse objeto é composto por até 120 segmentos de registros, além do segmento base e do segmento de espaço associado, que contém uma tabela descritiva dos campos (field descriptor table) e áreas de trabalho usadas pelo OS/400, como ponteiros para cursores lógicos.

Cada registro em um segmento de data space é identificado por um número ordinal, que indica sua posição dentro do segmento, começando do zero. É importante distinguir esse número ordinal do número relativo do registro, usado no nível do OS/400 para localizar dados em arquivos físicos. Como os registros são de tamanho fixo, o número ordinal permite calcular diretamente a posição do registro na memória sem necessidade de armazenamento explícito dessa informação.

Os índices de data space fornecem uma ordenação alternativa dos registros, utilizando para isso uma estrutura de árvore binária do tipo radix. Essa árvore suporta chaves de tamanho variável, que podem ser calculadas usando diversos operadores como concatenação, soma, subtração e multiplicação. Um índice pode cobrir até 32 data spaces, com opções de ordenação que incluem ascendente, descendente, numérico e valor absoluto. Além disso, existem opções para manutenção dos índices, permitindo que atualizações sejam aplicadas imediatamente ou adiadas, o que pode otimizar o desempenho quando o índice não está em uso constante.

O segmento base do índice de data space contém atributos que definem a sequência de colação alternativa, uma tabela lógica que descreve como o índice interpreta cada campo do registro e endereços dos data spaces abrangidos. A árvore binária radix pode se estender para além do segmento base, com até 64 segmentos adicionais dedicados à árvore. Cada chave na árvore armazena um valor em bytes seguido de um endereço relativo composto pelo número do data space, identificação do segmento e número ordinal, que juntos identificam unicamente o registro associado.

Os cursores são objetos do sistema MI que fornecem o mecanismo para visualizar e acessar os dados armazenados nos data spaces. Todo acesso aos dados ocorre via cursores, que podem ser sequenciais ou roláveis, conforme o padrão SQL de 1992. Embora o conceito de cursor MI seja distinto do cursor SQL usado pelo DB2, o cursor MI serve como base para implementar o comportamento do cursor SQL.

Além disso, é fundamental compreender que o modelo de dados do AS/400 integra-se profundamente ao sistema operacional e à arquitetura do hardware, resultando em uma implementação que garante alta eficiência e confiabilidade. A existência do SLIC abaixo do MI possibilita que o sistema aproveite características específicas do hardware sem perder a portabilidade e flexibilidade providas pela camada de abstração do MI.

Compreender os detalhes da implementação do banco de dados no AS/400 revela a complexidade e a sofisticação dessa plataforma, onde cada componente é otimizado para desempenho, escalabilidade e integridade dos dados. O uso de estruturas como árvores radix binárias e a divisão em múltiplos segmentos em uma memória de nível único refletem um projeto cuidadosamente elaborado para atender às demandas de aplicações empresariais críticas.

Além disso, é importante considerar o impacto dessas implementações na gestão do armazenamento e na recuperação dos dados, especialmente no que se refere à manutenção de índices e ao gerenciamento do espaço ocupado por registros excluídos. O design do AS/400 proporciona mecanismos para balancear a eficiência da consulta com a otimização do uso do espaço, garantindo uma operação estável mesmo em bases de dados de grande porte.

Por fim, o leitor deve reconhecer que a arquitetura do AS/400, com sua separação clara entre camadas independentes da tecnologia e camadas dependentes, é um exemplo notável de engenharia de sistemas, onde a modularidade e a abstração criam um ambiente robusto, flexível e duradouro, capaz de evoluir conforme as necessidades tecnológicas futuras.

A Influência de Lenin sobre a Direção da Literatura Soviética: Princípios, Métodos e Desafios
Como a Deformação de Manakov do Corpo Rígido em SO(n) Demonstra a Integrabilidade Algébrica
O Papel dos LVADs como Ponte para Transplante e Terapia Destino
Como Navegar com Segurança e Maximizar a Utilização dos Navegadores e Motores de Busca Menos Convencionais
Qual é o papel da detecção por conversão direta na evolução da imagiologia médica?