Trabalhando com IBM i com IBM Bob

Se você nunca escreveu uma linha de RPG, IBM i é uma das plataformas mais fascinantes para produção em escala. Se você já escreveu alguns milhões de linhas, já sabe onde mora a dor do dia a dia. Este post cobre ambos: um esboço técnico do que torna IBM i único, onde o atrito de modernização realmente aparece, como IBM Bob se encaixa em um workflow IBM i hoje, os passos de configuração para começar e o que vem a seguir no roadmap para a plataforma.

O que IBM i realmente é

IBM i não é um sistema operacional legacy no sentido de "deveríamos reescrever isso". É uma plataforma integrada — o OS, o banco de dados, o modelo de segurança e o runtime são projetados e entregues como uma coisa só — que vem gerando receita para bancos, seguradoras, hospitais, fabricantes e empresas de logística há décadas. Então, deveríamos chamá-lo de lendário.

Alguns detalhes que tendem a surpreender desenvolvedores vendo-o pela primeira vez:

Single-level storage. RAM e disco compartilham um espaço de endereçamento virtual. Object pointers persistem entre reinicializações. O OS trata memória e armazenamento como uma única camada e faz paginação entre eles de forma transparente. A maioria dos sistemas modernos ainda está alcançando isso.
TIMI, o Technology Independent Machine Interface. Binários RPG compilados em hardware dos anos 1990 rodam sem modificação em chips POWER atuais. O OS retraduz contra o novo conjunto de instruções por baixo dos panos. O análogo moderno mais próximo é WebAssembly, décadas antes.
OS baseado em objetos. Programas, arquivos, filas e autoridades são objetos tipados com atributos — não arquivos com metadados adicionados. Segurança é aplicada no nível do objeto.
Db2 for i é integrado, não adicionado. SQL e record-level I/O nativo acessam os mesmos dados. Um arquivo físico de 40 anos pode ser consultado através de uma view SQL moderna sem um projeto de migração.
Source pode viver no sistema ou no Git — sua escolha. Historicamente, source IBM i era armazenado como members dentro de source physical files (QSYS), compilado diretamente no sistema. A plataforma originalmente posicionava a LPAR como fonte da verdade. Mas IBM i evoluiu: os compiladores e o OS agora suportam totalmente workflows modernos centrados em Git, IFS stream files e desenvolvimento local se você escolher. Muitos shops ainda usam bibliotecas QSYS, mas a plataforma te dá opções.

A plataforma também suporta padrões de entrega modernos out of the box: engines REST API nativas como parte do OS, nuvem híbrida através do Power Virtual Server e inferência de IA rodando no mesmo hardware que cargas de trabalho transacionais. RPG, COBOL, CL e SQL coexistem com as práticas de desenvolvimento que o resto da sua organização de engenharia já usa.

A plataforma não é o problema. O atrito está ao redor dela.

Onde o atrito aparece

Quatro padrões aparecem em quase todos os shops IBM i. Nenhum deles é sobre RPG em si — a linguagem está boa — mas sobre o contexto ao redor do código que nunca foi escrito, e a forma como a plataforma armazena e compartilha esse contexto.

Contexto implícito, by design. Um programa RPG funcional pode abranger quatro gerações de linguagem em um source — RPG II, RPG IV, /COPY copybooks (declarações compartilhadas incluídas no momento da compilação) e free-format procedures — com sintaxe sensível a colunas e indicators numerados (*IN01–*IN99) fazendo o trabalho que fluxo de controle estruturado e booleanos nomeados fazem na maioria das outras linguagens. A sintaxe é aprendível em uma semana; as convenções e regras de negócio ao redor dela vivem nas cabeças dos engenheiros seniores.
Mudança nunca é local. O tipo de um campo não é declarado no programa que o usa — ele é declarado na própria tabela do banco de dados, em um arquivo source separado (um member DDS). Cada programa que lê ou escreve essa tabela herda essas definições simplesmente referenciando o arquivo no topo. Então alongar uma coluna de 10 para 12 dígitos nunca é uma edição de um programa: se propaga através de cada programa que toca o arquivo, e a lista desses programas raramente está escrita em algum lugar. Cada mudança em uma carga de trabalho crítica portanto carrega risco de continuidade, e a modernização estagna.
Source raramente vive onde ferramentas modernas esperam. A cópia canônica de um programa está no sistema, não em um repo Git em um laptop. Ler código que outra pessoa escreveu quinze anos atrás começa com encontrá-lo na LPAR, exportá-lo e então decidir se a exportação é a cópia canônica — um workflow que qualquer ferramenta assumindo uma árvore de trabalho local tem que ser adaptada antes de ganhar seu lugar.
RPG fixed-form não se parece em nada com código moderno. A maioria do RPG de produção foi escrito em fixed-form: sintaxe sensível a colunas onde operation codes vivem nas colunas 26–35, Factor 1 em 12–25 e comentários só cabem após a coluna 80. Lê como linguagem assembly para qualquer um treinado em Python ou JavaScript. IBM reinventou a linguagem com RPG completamente free-format (RPG IV, mais tarde apenas "RPG"), que parece e se comporta como uma linguagem procedural moderna — blocos estruturados, variáveis nomeadas, expressões padrão. A lacuna de sintaxe é real, mas a própria linguagem evoluiu. O atrito é que décadas de código funcional ainda estão em fixed-form, e reescrevê-lo carrega um risco que a maioria dos shops não pode justificar.

O que Bob faz em uma aplicação RPG para IBM i

Aponte Bob para um programa RPG e comece no modo Ask:

"Me guie através do que este programa faz e quais arquivos ele toca."
"Onde CUSTNO é definido e quais programas o leem depois disso?"
"O que quebraria se eu mudasse o comprimento deste campo?"

Mude para o modo Plan quando você tiver uma mudança em mente: uma conversão free-format, uma migração SQL para fora de record-level I/O ou quebrar um monolito em módulos. Bob produz um plano, as dependências que tocou e os passos que pretende tomar, antes de qualquer arquivo ser modificado.

Mude para o modo Code para aplicar a mudança. Bob:

Converte RPG fixed-format para free-format usando padrões repetíveis, arquivo por arquivo.
Migra record-level I/O para embedded SQL onde apropriado.
Gera suítes de teste RPGUnit contra procedures existentes para que a conversão seja verificável, não apenas compilável.
Produz documentação em linguagem simples e diagramas Mermaid do source — artefatos pesquisáveis e compartilháveis que sobrevivem a qualquer engenheiro individual.

O mesmo workflow lida com RPG II/III/ILE, CL, DDS, SQL e COBOL, então um novo contratado lendo um programa escrito antes de nascer não está mais bloqueado pela sintaxe.

Torne seu source IBM i pronto para Bob

Bob hoje trabalha contra source no seu computador local. A configuração é curta:

Baixe seu source. Exporte seus members RPG, RPGLE, CL, DDS e SQL para uma pasta local. O Code for i Project Explorer documenta a exportação de physical file members: migrate source
Abra a pasta no Bob. File → Open Folder na raiz do source. Bob indexa a codebase na primeira abertura.
Instale a toolchain IBM i. Do painel Extensions, adicione o IBM i Development Pack (o bundle Code for i) e um renderizador Mermaid para os diagramas que Bob produz.
Inicie uma sessão no modo Ask. Escolha um único programa — idealmente um que ninguém na equipe entende completamente — e peça ao Bob para explicá-lo. Essa é a forma mais rápida de ver se Bob ganha seu lugar no seu workflow.

Se sua equipe está vindo do SEU ou RDi, a migração é principalmente o passo de exportação acima mais a instalação da extensão. A superfície de edição é um ambiente moderno da família VS Code com destaque de sintaxe, completação de código e o workflow de IA descrito anteriormente; números de linha ainda estão disponíveis para engenheiros que os querem.

O que vem a seguir para Bob no IBM i

O recentemente anunciado Premium Package for i fornece experiência nativa e otimizada para equipes de desenvolvimento IBM i. Premium Package for i estará geralmente disponível em 24 de junho.

Premium Package for i. Com a GA em 24 de junho, Bob se conectará diretamente ao seu IBM i. De uma única sessão você lê source members diretamente do QSYS, os edita com o mesmo workflow acima e executa ciclos de compile e teste contra o sistema diretamente. Junto com a conectividade, Bob pega skills e workflows integrados ajustados ao desenvolvimento IBM i — conversão fixed-to-free, refactoring, geração de documentos — então um prompt inicial em uma codebase RPG aterrissa mais diretamente em convenções IBM i out of the box. Concretamente, isso significa:

Uma sessão Bob conectada a uma LPAR de desenvolvimento; sem loop separado de export-edit-import.
Erros de compile e resultados de teste do IBM i voltam para a conversa que Bob já está tendo.
Skills e workflows integrados para os padrões de refactoring, conversões e geração de testes que shops IBM i executam repetidamente.

Mais adiante — SDLC end-to-end. Três linhas estão em design ativo para versões futuras:

Integração DevOps. Bob participando de build, deploy, monitor e CI/CD para cargas de trabalho IBM i — executando um passe de regressão contra uma LPAR de teste, promovendo uma mudança através de ambientes e trazendo um problema de runtime de volta para uma sessão.
Performance SQL. Análise de dados e otimização de índice como capacidade de primeira classe, além dos padrões de migração embedded-SQL que Bob já produz hoje.
IBM i Knowledge Assistant. Respostas fundamentadas em recuperação através da codebase, documentação de design e tickets — para que o contexto que vive fora do source seja alcançável da mesma conversa.

Para uma equipe adotando Bob hoje, o workflow de arquivo local acima é o ponto de partida certo; os itens nesta seção descrevem como esse workflow encurta e estende conforme a oferta IBM i amadurece.

Referências de clientes

Equipes em saúde, agricultura, TI empresarial e logística estão usando Bob contra codebases IBM i de produção hoje:

MEDHOST. Aplicações de saúde abrangendo múltiplas gerações RPG através de deployments hospitalares dos EUA. A equipe usa Bob para análise de impacto e conversão fixed-to-free, e para onboarding de desenvolvedores mais novos em programas cujos autores originais se foram há muito tempo.
NI+C. Integrador empresarial japonês com programas RPG que estavam rodando sem mudanças por mais de uma década sem documentação de design sobrevivente. Bob produziu docs de design e diagramas Mermaid precisos o suficiente para que engenheiros que previamente ricochetearam de assistentes de IA continuassem usando para trabalho real.
Heartland Co-op. Cooperativa agrícola baseada em Iowa transmitindo dados de sensores IoT em tempo real para seu ambiente IBM i para monitoramento de qualidade de grãos e equipamentos. Bob ajuda desenvolvedores a raciocinar através das interdependências entre o pipeline IoT, contabilidade de grãos e sistemas operacionais centrais, e encurta o ramp-up para novas contratações.
Carreras Grupo Logístico. Um dos primeiros adotantes empresariais de Bob na Espanha, usando-o para explicar lógica de programa legacy, gerar documentação e refatorar através de módulos de uma plataforma logística.

O fio comum entre todos os quatro é o mesmo: a codebase IBM i existente permanece no lugar, e o trabalho de explicação, conversão e documentação roda ao lado do sistema de produção em vez de antes de um projeto de substituição.

Começar

Inicie uma avaliação gratuita
Baixe um programa RPG para uma pasta local e abra-o no Bob.
No modo Ask, solicite um walkthrough e um diagrama Mermaid de seu fluxo de dados.

Essa sessão — um programa, uma conversa — é o caminho mais curto para uma resposta real sobre se Bob se encaixa na forma como sua equipe trabalha.