Como o Sistema/36 Integrou Tecnologia e Compatibilidade em um Ambiente RISC

Nos anos 70, em Rochester, um código foi estabelecido com base no trabalho realizado com o System/38. As funções desse sistema foram transferidas para o microcódigo do System/38, com o objetivo de garantir a independência tecnológica. O System/32, que seguia o modelo do System/3, utilizava um processador microprogramado para emular o conjunto de instruções do System/3. No entanto, para melhorar o desempenho, diversas funções do sistema operacional foram transferidas do System/3 para o microcódigo do System/32, o que gerou semelhanças entre os dois sistemas. Ambos, System/32 e System/38, tinham partes de seu sistema operacional implementadas diretamente no microcódigo, mas com finalidades distintas.

O System/32 foi projetado para atender a um mercado de entrada, o que lhe conferia um bom desempenho para suas funções principais. Contudo, a emulação das instruções do System/3 não era eficiente, pois o processador subjacente não era de alto desempenho. O processador do System/32, embora não fosse veloz o suficiente para a emulação, executava muito bem as funções do sistema operacional. Interessante notar que o processador utilizado no System/32 tinha uma arquitetura de 16 bits, baseada em registradores, que lembrava os primeiros projetos de hardware RISC.

Para expandir a capacidade de desempenho do System/32, algumas mudanças foram necessárias. Embora o processador original fosse adequado para rodar partes do sistema operacional, ele não conseguia emular com eficiência as instruções do System/3. Então, foi desenvolvido um segundo processador, inspirado no design original do System/3, para executar diretamente essas instruções. Esse processador ficou conhecido como Main Store Processor (MSP), enquanto o processador do System/32 passou a ser chamado de Control Store Processor (CSP), pois buscava suas instruções de uma parte diferente da memória.

Em 1977, foi lançado o primeiro sistema que utilizava essa estrutura de dois processadores: o System/34. Seis anos depois, em 1983, o System/36 foi introduzido, mantendo a arquitetura com dois processadores. O sistema operacional do System/36 era dividido em duas partes: a primeira, o System Support Program (SSP), operava no MSP, enquanto a segunda parte rodava no CSP. Para modelos maiores do System/36, foram adicionados processadores extras, dedicados ao processamento de operações de I/O. Ao longo dos anos, novos modelos do System/36 foram lançados, sempre com a estrutura de dois processadores.

Esse novo modelo do System/36, integrado ao AS/400, foi introduzido em 1994 com um processador RISC de 64 bits e a capacidade de rodar o SSP sem modificações no código das aplicações, garantindo compatibilidade binária com os sistemas anteriores. Embora essa abordagem oferecesse novos desafios de marketing, a resposta do mercado foi positiva, e o Advanced 36, como foi chamado, tornou-se um grande sucesso. Ele demonstrou o poder de integração do AS/400, que foi capaz de manter a compatibilidade com o System/36, enquanto incorporava tecnologias de última geração.

Com o lançamento do Advanced 36, o AS/400 passou a ser um sistema capaz de rodar tanto o OS/400 quanto o SSP simultaneamente, utilizando a arquitetura RISC. Essa integração foi um exemplo claro de como um sistema pode evoluir sem perder compatibilidade com versões anteriores, ao mesmo tempo em que adota novas tecnologias. A adição do System/36 dentro da estrutura do SLIC se tornou um marco na evolução do AS/400, que passou a ter um "System/36 Inside", representando uma síntese perfeita entre o legado de sistemas anteriores e a inovação tecnológica.

Além disso, ao observar essa evolução, é importante entender como a IBM soube equilibrar inovação e legado. O sucesso do Advanced 36 não foi apenas uma questão de avançar para tecnologias mais rápidas e eficientes, mas também de manter uma base sólida e compatível para os clientes que já dependiam do System/36. Essa estratégia de integração, que preserva compatibilidade enquanto evolui, é um aspecto central do design do AS/400 e um modelo valioso para qualquer sistema computacional que precise equilibrar inovação com continuidade.

Como Funciona o Acesso ao Banco de Dados no Sistema AS/400

No ambiente de sistemas como o AS/400, o acesso aos dados de banco de dados é feito de maneira precisa e estruturada, garantindo que a integridade e a segurança da informação sejam mantidas. O sistema AS/400 utiliza um conceito de "cursor", que desempenha um papel fundamental na leitura, atualização e manipulação dos dados armazenados. Este mecanismo, embora tecnicamente complexo, serve a vários objetivos, incluindo o gerenciamento de grandes volumes de dados de maneira eficiente e segura.

O cursor pode ser visto como uma ferramenta que aponta diretamente para o espaço de dados, ou então, pode acessar esses dados por meio de um índice, oferecendo a flexibilidade necessária para trabalhar com diferentes tipos de acessos. Ele permite que os dados sejam lidos sequencialmente ou de maneira aleatória, dependendo do tipo de indexação disponível no banco de dados. Além disso, um único cursor pode abranger múltiplos espaços de dados, permitindo o acesso simultâneo a diferentes segmentos de informações, o que é crucial em operações complexas que envolvem grandes quantidades de registros.

Um ponto importante a ser destacado é que o cursor também é responsável pela seleção e filtragem dos registros. Isso é feito por meio de expressões aritméticas ou de strings de caracteres, permitindo que dados específicos sejam recuperados de acordo com critérios predefinidos. Esses critérios podem ser estabelecidos por meio de cláusulas WHERE em instruções SQL, limitando o conjunto de dados visível ao usuário e, assim, proporcionando uma camada adicional de segurança ao banco de dados. Esse controle é essencial, especialmente em sistemas onde o acesso a dados sensíveis deve ser rigidamente restrito.

O funcionamento do cursor envolve dois segmentos principais: o segmento base e o segmento associado. O segmento base contém os endereços dos espaços de dados e dos índices de dados, sendo capaz de identificar até 32 espaços e 32 índices. Esse sistema de endereçamento eficiente é o que possibilita o uso de múltiplos índices para otimizar a recuperação de informações, especialmente em casos onde junções entre arquivos lógicos são necessárias. O segmento associado, por sua vez, armazena o texto e os atributos do membro, elementos cruciais para a execução das operações de leitura e manipulação.

A maneira como o sistema de acesso ao banco de dados é projetado no AS/400 reflete a necessidade de separar a execução dos processos de acesso aos dados da complexidade do gerenciamento interno do banco. Isso é feito por meio de uma instrução no MI (Machine Interface), que ativa ou desativa o cursor, associando-o ao processo do usuário. Esse modelo garante que um único processo possa gerenciar múltiplos cursos, mantendo o controle sobre o acesso simultâneo, sem que haja interferência entre diferentes operações.

Outro aspecto fundamental do AS/400 é o conceito de cursors permanentes e temporários. Cada membro de arquivo tem um cursor permanente associado, enquanto cursors temporários são criados quando múltiplos processos precisam acessar o mesmo arquivo. Esse mecanismo permite uma alocação de memória mais eficiente, já que os cursors temporários não armazenam informações como o código de mapeamento ou de seleção, mas sim apontam para o cursor permanente, que contém essas informações.

O sistema AS/400 adota ainda um protocolo específico para o gerenciamento de dados temporários, utilizando a instrução CRTDUPOBS para criar cópias temporárias de cursors permanentes. Essa estratégia assegura que, apesar da criação de múltiplos cursors temporários, o sistema conserve a consistência e a integridade dos dados, sem comprometer a performance ou o uso excessivo de recursos.

Por fim, a segurança e a integridade dos dados são fortemente reforçadas por meio de um mecanismo de journaling, que registra todas as alterações feitas no banco de dados. Esse processo é gerido por dois objetos principais no MI: os "journal ports" e os "journal spaces". O journal port gerencia a definição do journal, enquanto o journal space armazena as entradas do journal, registrando alterações de dados e garantindo que, em caso de falha, o sistema possa ser restaurado ao seu estado anterior.

É importante compreender que, apesar da complexidade desses mecanismos, o objetivo do AS/400 é proporcionar um ambiente de processamento de dados robusto, seguro e eficiente. O acesso aos dados, através dos cursors e da implementação do journaling, garante não apenas que as informações sejam manipuladas de maneira eficiente, mas também que todas as operações sejam transparentes e seguras, minimizando os riscos de corrupção ou perda de dados.

Como Funciona o Sistema de Segurança e Autorização no AS/400

O AS/400, um sistema de computação da IBM, adota uma estrutura robusta e detalhada para gerenciar o acesso e a segurança dos usuários. O gerenciamento dessa segurança é centrado no perfil do usuário, que contém informações essenciais sobre os direitos de acesso e as permissões relacionadas aos objetos e funções dentro do sistema. A seguir, vamos explorar os diferentes aspectos que definem a segurança e a autorização no AS/400.

Quando o AS/400 é inicialmente configurado, um perfil de usuário é criado para cada classe. A partir daí, a responsabilidade de atribuir funções e direitos a cada usuário é do cliente, que pode designar múltiplas funções a uma única pessoa, dependendo das necessidades da instalação.

Os objetos no AS/400 possuem diferentes tipos de autoridade que podem ser atribuídos aos usuários. São oito tipos de autoridade, que se referem a operações como a leitura, adição, alteração, exclusão e gerenciamento de objetos. Além disso, o sistema agrupa essas autoridades em quatro combinações principais para simplificar o entendimento dos usuários: "ALL" (todas as autoridades), "CHANGE" (operações e modificações), "USE" (operações básicas e leitura), e "EXCLUDE" (sem autoridade). A combinação "EXCLUDE" tem um peso especial, pois prevalece sobre quaisquer outras autoridades, seja pública ou de grupo, devido à ordem de busca das permissões.

Outro aspecto importante na administração de segurança é a existência de instruções privilegiadas e autoridades especiais. Cada perfil de usuário contém informações sobre quais instruções privilegiadas e autoridades especiais ele pode executar. Algumas instruções, como a que permite desligar o sistema, são exclusivas para usuários com privilégios específicos, como o Security Officer. Essas instruções e autoridades especiais podem ser agrupadas em categorias como controle de spool, controle de trabalhos em execução, e administração do sistema.

O perfil de usuário é, portanto, o elemento central da segurança no AS/400, determinando o acesso do usuário a praticamente todos os recursos do sistema. No entanto, existem mecanismos que permitem aos usuários adquirir autoridade adicional sem ter que modificar diretamente seus perfis. Um exemplo disso é a Adoção de Autoridade por Programas, que permite que um programa execute operações em nome do usuário, assumindo temporariamente as permissões do proprietário do programa. Esse recurso elimina a necessidade de conceder permissões adicionais diretamente aos usuários, mantendo a segurança controlada.

A segurança no AS/400, portanto, é uma estrutura complexa que depende de perfis de usuário, permissões sobre objetos, e mecanismos de administração centralizados. Embora o sistema seja altamente configurável, é essencial que os administradores compreendam como cada elemento interage e afeta a segurança geral do sistema.

É fundamental, para qualquer administrador ou usuário com privilégios no AS/400, compreender que a segurança não se limita ao gerenciamento de permissões estáticas. Ela também envolve uma constante revisão e auditoria das permissões atribuídas, além de garantir que os usuários não possuam mais autoridade do que a necessária para suas funções. Uma boa prática é sempre minimizar os privilégios concedidos e adotar um modelo de "menor privilégio", onde os usuários têm apenas os acessos necessários para desempenhar suas funções.

Como o AS/400 Mudou o Mundo da Computação e a História da Sua Criação

Entretanto, no final de 1985, um grupo de desenvolvedores de Rochester demonstrou algo que mudaria tudo: foi possível rodar o software do System/36 em um ambiente dentro do System/38. Isso abriu uma nova perspectiva, pois os custos das tecnologias de hardware haviam diminuído a ponto de ser possível construir modelos menores do System/38. Com essa nova abordagem, foi proposto integrar os dois sistemas em uma única máquina. Esse novo projeto foi nomeado Silverlake, e, após intensos esforços, a equipe conseguiu convencer a gestão da IBM de que seria possível criá-lo. Assim nasceu o AS/400.

Lançado após um ciclo de desenvolvimento impressionante de 28 meses, o AS/400 foi apresentado ao mundo como um sistema completamente novo. Mas, nos bastidores, aqueles que conheciam a fundo a arquitetura do sistema sabiam que, em sua essência, o AS/400 ainda era uma continuação do System/38. O sucesso do AS/400 foi imediato. Não apenas recuperou a participação de mercado perdida para concorrentes, mas rapidamente ultrapassou-os, tornando-se o sistema de computador multiusuário mais vendido da história, com mais de 300.000 unidades em operação globalmente.

A grande virada do AS/400 se deu, em parte, pela sua compatibilidade com tecnologias futuras. Em 1991, a IBM, juntamente com a Apple e a Motorola, anunciou a criação de uma nova família de processadores, os PowerPC, que seriam usados em uma vasta gama de dispositivos, de aparelhos portáteis a supercomputadores. Rochester, então, viu a oportunidade de atualizar o AS/400, utilizando esses novos processadores PowerPC para projetar um sistema ainda mais poderoso e eficiente. A adoção do PowerPC representava um marco na evolução do AS/400, garantindo que ele continuasse relevante e capaz de lidar com as crescentes demandas de processamento, sem causar os grandes impactos negativos que outras mudanças de arquitetura causaram a sistemas concorrentes.

Porém, a história do AS/400 não se resume apenas às inovações tecnológicas. A criação do sistema é também um exemplo do poder da liderança visionária. Rochester teve uma série de líderes técnicos e gerenciais excepcionais, mas foram poucos os verdadeiros visionários que souberam não apenas imaginar um futuro inovador, mas também transmitir essa visão e transformá-la em realidade. Em 1972, quando o projeto System/38 ainda estava em sua fase inicial, o arquétipo do "visionário" estava sendo moldado. Dick Bains e Roy Hoffman foram duas dessas figuras fundamentais, que não só lideraram o desenvolvimento da arquitetura do AS/400, mas também convenceram os engenheiros a abraçar um caminho que parecia radical para muitos. A sua capacidade de comunicar uma visão e motivar uma equipe diversa de profissionais foi essencial para o sucesso do projeto.

Além da inovação tecnológica, a história do AS/400 reflete a importância de ter uma base de desenvolvimento sólida, que combine liderança visionária com uma profunda compreensão das necessidades do mercado e das limitações técnicas. A evolução do AS/400 é um testemunho de como a IBM, com sua capacidade de adaptação e inovação, conseguiu não apenas sobreviver a um período de dificuldades, mas também se posicionar na vanguarda de uma nova era da computação empresarial.

Essa trajetória é também um lembrete de que, no desenvolvimento de tecnologias complexas, a flexibilidade e a capacidade de adaptação são tão essenciais quanto a inovação técnica. A experiência do AS/400 ensina que, para que um sistema de TI seja bem-sucedido a longo prazo, ele deve ser projetado de forma a evoluir com as mudanças nas necessidades do mercado e nas tecnologias emergentes, sem comprometer a compatibilidade com os investimentos feitos no passado. Essa lição é válida não apenas para empresas como a IBM, mas para qualquer organização que busque construir soluções tecnológicas duradouras e relevantes no futuro.