IBM i para um agente Linux/Windows: objetos e bibliotecas em vez de arquivos e caminhos

O que é

O IBM i (antes OS/400, executado em hardware Power, versões 7.4/7.5/7.6) não tem, no seu núcleo, um conceito nativo de hierarquia de arquivos ao estilo Unix. Tudo o que o sistema gerencia — programas, arquivos físicos e lógicos de banco de dados, áreas de dados, perfis de usuário, descrições de job — é um objeto tipado, identificado por um nome de até 10 caracteres, por um tipo de objeto (*PGM, *FILE, *USRPRF, etc.) e pela biblioteca que o contém. Uma biblioteca é, ela própria, um objeto do tipo *LIB; é um contêiner plano, não um diretório, e não pode conter outras bibliotecas (todas as bibliotecas são objetos da biblioteca especial QSYS).

Enquanto um processo Linux resolve o nome simples de um comando por meio de $PATH, um job do IBM i resolve o nome simples de um objeto por meio da sua lista de bibliotecas (*LIBL): uma lista ordenada de bibliotecas composta por uma parte do sistema (até 15 bibliotecas, incluindo QSYS), bibliotecas de produto opcionais, a biblioteca atual do job (*CURLIB) e uma parte do usuário. Qualquer referência não qualificada, como MYPGM (comandos como DSPLIB são eles próprios objetos *CMD, resolvidos da mesma forma), é procurada na lista de bibliotecas do job, a menos que o nome seja qualificado como LIBRARY/OBJECT. Dois jobs com listas de bibliotecas diferentes podem chamar o mesmo MYPGM não qualificado e executar programas distintos — o equivalente no IBM i de um bug de sombreamento em $PATH; um MYLIB/MYPGM qualificado não é afetado.

Os nomes de comandos costumam seguir um padrão: uma abreviação de verbo com três letras mais uma ou mais abreviações de substantivos, por exemplo CRTLIB (Create Library), DLTLIB (Delete Library), DSPLIB (Display Library), WRKACTJOB (Work with Active Jobs). Depois que o agente decodifica alguns verbos (CRT, DLT, DSP, WRK, CHG, STR, END) e substantivos (LIB, OBJ, JOB, USRPRF), a maioria dos nomes de comandos passa a poder ser deduzida, em vez de decorada.

Para ferramentas orientadas a arquivos, o Integrated File System (IFS) expõe todo o espaço de objetos em /QSYS.LIB/LIBRARY.LIB/OBJECT.TYPE, por exemplo /QSYS.LIB/QGPL.LIB/MYPGM.PGM. Isso permite que um find ou ls a partir de um shell PASE enxergue os objetos tradicionais, mas a página de suporte da IBM citada descreve o QSYS.LIB como um sistema de arquivos voltado principalmente a arquivos de banco de dados e outros objetos de biblioteca, não como um sistema de arquivos de stream de uso geral: a E/S de stream só funciona com poucos tipos de objeto (como membros de arquivo físico e save files), e muitas operações comuns em / ou /home não são suportadas ali.

Por que importa

Um agente que trata o IBM i como "Linux com comandos estranhos" vai interpretar mal erros de "arquivo não encontrado" que, na verdade, são problemas de lista de bibliotecas, e tentará operações de sistema de arquivos no QSYS.LIB que o modelo de objetos não suporta.

Como aplicar

• Antes de procurar um objeto, pergunte qual lista de bibliotecas vale para o job atual, e não apenas qual é o nome do objeto.
• Leia a qualificação LIBRARY/OBJECT como leria um caminho absoluto; trate os nomes não qualificados como relativos a *LIBL.
• Decodifique nomes de comandos CL desconhecidos como verbo+substantivo antes de supor que se trata de um recurso não documentado.
• Evite operações de stream do IFS (renomear no local, escrita arbitrária de bytes) dentro de /QSYS.LIB; em vez disso, use comandos CL (CRT*, CPY*, DLT*) para o ciclo de vida dos objetos.

Armadilhas

• Supor que uma biblioteca é um diretório que pode conter sub-bibliotecas; ela não pode.
• Supor que *LIBL é algo que o shell do agente controla como o $PATH; é um atributo de cada job, inicializado a partir da descrição do job ou dos valores de sistema QSYSLIBL/QUSRLIBL e alterado com CHGLIBL/ADDLIBLE; por isso, outro job (por exemplo, um job batch submetido) pode ver uma lista diferente.