Bellacosa Mainframe explorando o ISPF DB e Spufi

☕ Um Café no Bellacosa Mainframe

MIB Entra no CPD — O Dia em que o Agente J Descobriu No Spufi que o Alienígena Era Só um `SELECT` no `SYSIBM`

Ou: como TSO/E, ISPF, o menu DB, DB2I, SPUFI, catálogo Db2, SQLCODE e alguns datasets transformam a primeira tela verde do z/OS em uma investigação digna dos Homens de Preto

Há um momento curioso na vida de praticamente todo iniciante em mainframe.

Ele recebe um USER-ID, abre um emulador 3270, faz logon no z/OS e encontra uma tela cheia de opções, siglas e nomes que parecem ter sido escritos por alguma organização secreta do governo.

TSO.

ISPF.

DB.

DB2I.

SPUFI.

SYSIBM.

Para alguém vindo de Windows, Linux, VS Code, Java, Python ou bancos de dados gráficos, isso pode parecer menos um ambiente de desenvolvimento e mais a porta de entrada de uma base subterrânea dos MIB — Men in Black.

O agente novato olha para a tela.

O agente veterano coloca os óculos escuros.

— Não se preocupe. O alienígena é só um dataset.

E é exatamente assim que começaremos esta missão.

Nosso objetivo é entender, passo a passo, como um programador COBOL iniciante entra no z/OS, passa pelo TSO/E, encontra o ISPF, acessa o menu relacionado ao Db2, chega ao DB2I, entra no SPUFI e finalmente utiliza SQL para investigar o catálogo do próprio banco através das tabelas SYSIBM.

Nada de neuralizador.

Nada de nave espacial.

Só mainframe.

O que, dependendo do dia, pode ser mais assustador.

1. Caso MIB-0001 — afinal, o que é o z/OS?

Antes de investigar o ISPF, precisamos estabelecer a cena do crime.

O z/OS é o sistema operacional utilizado nos mainframes IBM Z.

Ele administra coisas como:

memória;
processadores;
jobs;
datasets;
segurança;
subsistemas;
comunicação;
transações;
bancos de dados;
aplicações críticas.

Ou seja, quando você entra no ambiente, não está “entrando no ISPF”.

Você está entrando em um universo muito maior.

Podemos imaginar:

IBM Z
  │
  ▼
z/OS
  │
  ├── JES2
  ├── TSO/E
  ├── RACF
  ├── Db2
  ├── CICS
  ├── IMS
  └── outras centenas de componentes

O ISPF é apenas uma das formas de interagir com esse universo.

É como a recepção da sede dos MIB.

A sede é enorme.

A recepção é só onde você começa a andar.

2. Primeiro contato: o TSO/E

O usuário normalmente acessa o ambiente através de um terminal ou emulador 3270.

Depois do logon, entra no TSO/E.

TSO significa:

Time Sharing Option

O TSO/E fornece uma interface interativa para usuários do z/OS.

Uma simplificação útil é:

Usuário
   │
   ▼
Emulador 3270
   │
   ▼
TSO/E
   │
   ▼
ISPF

O TSO/E permite executar comandos, iniciar programas e trabalhar de forma interativa.

Mas trabalhar diretamente no TSO seria menos amigável.

Foi aí que o ISPF virou protagonista.

3. Caso MIB-0002 — o que é ISPF?

ISPF significa:

Interactive System Productivity Facility

Ele é um ambiente interativo baseado em painéis, menus, comandos e serviços.

Para um iniciante, a melhor frase é:

ISPF é a bancada de trabalho interativa do usuário no z/OS.

Não é o sistema operacional.

Não é o TSO.

Não é o Db2.

Ele funciona sobre o TSO/E e fornece uma interface muito mais organizada para tarefas do dia a dia.

Pense assim:

z/OS = cidade inteira

TSO/E = seu acesso à cidade

ISPF = seu escritório dentro dela

No ISPF você pode:

editar datasets;
visualizar membros de PDS/PDSE;
trabalhar com JCL;
navegar por utilitários;
chamar ferramentas;
acessar produtos instalados;
executar comandos;
utilizar interfaces de sistemas como Db2.

Uma tela típica pode mostrar algo parecido com:

0  Settings
1  View
2  Edit
3  Utilities
4  Foreground
5  Batch
6  Command
...

Só que existe um detalhe importante.

O ISPF é altamente customizável.

Cada empresa pode adicionar suas próprias opções.

Por isso, você pode encontrar:

DB
SDSF
CICS
IMS
MQ
ENDEVOR
FILEAID
ISPW

e outras opções que não fazem parte necessariamente do menu padrão.

4. Alerta MIB: não confunda 3270 com ISPF

Esse erro é extremamente comum.

O iniciante olha para a tela preta ou verde e diz:

“Estou no ISPF.”

Talvez esteja.

Mas a tela em si é geralmente exibida através de um terminal ou emulador 3270.

O 3270 é uma tecnologia de terminal.

O ISPF é um ambiente de software.

Portanto:

Emulador 3270
       │
       ▼
     TSO/E
       │
       ▼
      ISPF

É como confundir o monitor com o Windows.

O monitor mostra.

O sistema executa.

No mainframe, a diferença também existe.

5. Caso MIB-0003 — o misterioso menu DB

Agora chegamos à parte que mais confunde quem está começando.

Você está no ISPF e alguém diz:

“Digite DB.”

O iniciante pensa:

— Então DB é o Db2?

Não necessariamente.

O DB geralmente é uma opção de menu criada ou configurada pela instalação para chegar a ferramentas relacionadas ao Db2.

Em alguns ambientes pode aparecer como:

DB

Em outros:

DB2

Em outros ainda pode haver uma opção numérica.

Portanto, não existe uma lei universal dizendo:

DB = opção padrão do ISPF

O que normalmente acontece é algo parecido com:

ISPF
  │
  ▼
DB
  │
  ▼
DB2I

Ou seja, DB é a porta.

O Db2 continua do outro lado.

6. DB2I — a sala de equipamentos dos agentes

DB2I significa:

Db2 Interactive

Ele é um conjunto tradicional de painéis ISPF para interagir com funções relacionadas ao Db2 for z/OS.

Dentro dele você pode encontrar opções como:

SPUFI
DCLGEN
PROGRAM PREPARATION
COMMANDS
UTILITIES

Os nomes e números podem variar.

Mas a ideia é:

ISPF
  │
  ▼
DB
  │
  ▼
DB2I
  │
  ├── SPUFI
  ├── DCLGEN
  ├── preparação
  └── outras funções

O DB2I não é o banco.

Ele é uma interface.

Isso precisa ficar muito claro.

7. Caso MIB-0004 — SPUFI entra em cena

Agora encontramos um dos instrumentos mais clássicos do programador Db2 no z/OS:

SPUFI

O nome significa:

SQL Processor Using File Input

O nome é praticamente uma confissão.

Ele processa SQL usando um arquivo de entrada.

Ou, em linguagem mainframe:

um dataset de entrada.

A filosofia é:

dataset com SQL
      │
      ▼
    SPUFI
      │
      ▼
 Db2 for z/OS
      │
      ▼
resultado
      │
      ▼
dataset de saída

Quem vem de ferramentas modernas espera abrir um editor SQL e clicar em “Run”.

No SPUFI, a cultura é outra.

Você informa um dataset com SQL.

O SPUFI lê.

Executa.

E grava o resultado.

MIB aprovaria.

Tudo documentado.

Tudo rastreável.

Nada de clicar em um botão misterioso e esperar o universo colaborar.

8. Como funciona a tela do SPUFI?

Você pode encontrar campos semelhantes a:

INPUT DATA SET NAME  ===> USER.SQLIN

OUTPUT DATA SET NAME ===> USER.SQLOUT

EDIT INPUT           ===> YES

EXECUTE              ===> YES

BROWSE OUTPUT        ===> YES

Algumas telas também incluem opções relacionadas a:

AUTOCOMMIT
CHANGE DEFAULTS

A ideia do fluxo é:

EDIT
  │
  ▼
EXECUTE
  │
  ▼
BROWSE

Primeiro você edita o SQL.

Depois executa.

Depois lê o resultado.

Simplicidade antiga.

Mas extremamente eficiente.

9. Primeira missão SPUFI

O primeiro SQL de laboratório pode ser:

SELECT CURRENT DATE,
       CURRENT TIME
FROM SYSIBM.SYSDUMMY1;

Isso testa se:

SPUFI está funcionando;
você está conectado a um Db2;
o Db2 está respondendo;
seu ambiente está minimamente configurado.

SYSIBM.SYSDUMMY1 é uma tabela especial muito usada para executar expressões simples.

Você pode consultar:

SELECT CURRENT USER
FROM SYSIBM.SYSDUMMY1;

ou:

SELECT CURRENT TIMESTAMP
FROM SYSIBM.SYSDUMMY1;

Esses comandos são excelentes para o primeiro contato.

10. E qual Db2 estou usando?

Essa pergunta é ótima.

Num z/OS podem existir vários subsistemas Db2.

Por exemplo:

DB2D  desenvolvimento
DB2H  homologação
DB2P  produção

Esses nomes são apenas exemplos.

O identificador do subsistema é chamado normalmente de:

SSID — Subsystem Identifier

No DB2I você pode encontrar um campo parecido com:

DB2 SUBSYSTEM ID ===> DB2D

Isso ajuda a identificar o subsistema utilizado.

Seu USER-ID pode ter acesso a um e não a outro.

Por exemplo:

USER123
  │
  ├── DB2D → acesso
  ├── DB2H → acesso limitado
  └── DB2P → sem acesso

E isso é muito importante:

acessar um subsistema não significa poder fazer qualquer coisa dentro dele.

11. Identidade dentro do Db2

Depois de entrar no SPUFI, uma boa consulta é:

SELECT CURRENT USER,
       CURRENT SQLID,
       CURRENT SERVER
FROM SYSIBM.SYSDUMMY1;

Isso ajuda a responder:

quem sou eu para o Db2?
qual SQLID está sendo usado?
qual servidor/local location está associado à sessão?

Só tenha cuidado:

CURRENT SERVER não é obrigatoriamente o mesmo nome do SSID.

No mundo Db2, nomes de location, subsystem e ambiente podem ter relações que nem sempre são idênticas.

Não trate tudo como sinônimo.

12. Caso MIB-0005 — o que é SYSIBM?

Agora começa a investigação de verdade.

O Db2 não guarda apenas dados de negócio.

Ele também guarda informações sobre os próprios objetos.

Imagine uma aplicação com:

CLIENTES
CONTAS
PEDIDOS
PRODUTOS

Essas tabelas guardam dados.

Mas o Db2 também precisa saber:

quais tabelas existem;
quais colunas possuem;
quais índices existem;
quais views existem;
quais constraints foram definidas;
quais tipos de dados existem;
quem criou determinados objetos.

Essas informações são chamadas de:

metadados

E boa parte desses metadados está registrada em tabelas de catálogo.

Muitas delas estão associadas ao schema:

SYSIBM

Portanto:

Dados
│
├── CLIENTES
├── PEDIDOS
└── CONTAS

Metadados
│
└── SYSIBM
     ├── SYSTABLES
     ├── SYSCOLUMNS
     ├── SYSINDEXES
     └── ...

Uma analogia excelente:

SYSIBM é como a biblioteca administrativa do Db2.

Lá o banco guarda informação sobre o próprio universo.

13. SYSTABLES — “mostre-me os objetos”

Uma das tabelas mais importantes é:

SYSIBM.SYSTABLES

Podemos consultar:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'SYSIBM'
FETCH FIRST 20 ROWS ONLY;

Isso permite visualizar objetos cadastrados no catálogo.

Aqui aprendemos três partes fundamentais do SQL:

SELECT
FROM
WHERE

Ou seja:

SELECT → o que quero ver
FROM   → de onde quero buscar
WHERE  → quais registros quero

Simples.

Mas poderoso.

14. SYSCOLUMNS — “agente, descreva o suspeito”

Encontramos uma tabela.

Agora queremos saber quais colunas ela possui.

Consultamos:

SYSIBM.SYSCOLUMNS

Por exemplo:

SELECT TBCREATOR,
       TBNAME,
       NAME,
       COLNO,
       COLTYPE,
       LENGTH
FROM SYSIBM.SYSCOLUMNS
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES'
ORDER BY COLNO;

Agora o próprio Db2 está descrevendo uma tabela do próprio catálogo.

É quase um interrogatório recursivo.

E isso é extremamente útil quando recebemos um programa COBOL antigo.

15. SYSINDEXES — seguindo as pegadas

Se queremos investigar índices:

SYSIBM.SYSINDEXES

Podemos usar algo semelhante a:

SELECT CREATOR,
       NAME,
       TBCREATOR,
       TBNAME
FROM SYSIBM.SYSINDEXES
WHERE TBCREATOR = 'SYSIBM'
  AND TBNAME = 'SYSTABLES';

Agora conseguimos responder:

existem índices relacionados a esta tabela?

Para manutenção de aplicações, isso é uma informação valiosa.

16. O catálogo como ferramenta de investigação

É aqui que o iniciante começa a crescer.

Em vez de perguntar:

“Onde está a tabela CLIENTES?”

ele pode procurar:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE NAME = 'CLIENTES';

Ou se não souber o nome completo:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE NAME LIKE '%CLIENT%';

Você começa a investigar.

E investigar é uma das competências mais importantes de qualquer profissional de mainframe.

17. LIKE — procurando alienígenas parcialmente identificados

O operador LIKE permite buscar padrões.

Por exemplo:

WHERE NAME LIKE 'EMP%'

significa:

começa com EMP

Enquanto:

WHERE NAME LIKE '%EMP%'

significa:

contém EMP

WHERE NAME LIKE '%EMP'

significa:

termina com EMP

MIB chama isso de busca por descrição parcial do extraterrestre.

Db2 chama de SQL.

18. FETCH FIRST — não abra todos os arquivos secretos

Evite iniciar sua carreira com:

SELECT *
FROM SYSIBM.SYSTABLES;

Em ambientes grandes isso pode trazer uma quantidade enorme de informação.

Prefira:

FETCH FIRST 20 ROWS ONLY

ou outro limite adequado.

É uma excelente disciplina.

Especialmente para iniciantes.

Regra prática:

investigue aos poucos.

19. ORDER BY — se a ordem importa, diga

Nunca confie na ordem natural dos resultados.

Se quer ordenar por posição de coluna:

ORDER BY COLNO;

Se quer por nome:

ORDER BY NAME;

Sem ORDER BY, você não deve assumir que os dados virão sempre na mesma ordem.

Essa regra vale no SPUFI.

Vale no COBOL.

Vale na produção.

Vale no universo inteiro.

20. SQLCODE — o relatório da investigação

Quando executamos SQL, o Db2 informa o resultado através de códigos.

O mais famoso é o:

SQLCODE

Por exemplo:

SQLCODE = 0

normalmente significa sucesso.

Um clássico:

SQLCODE = +100

é associado à condição de nenhuma linha encontrada em determinados contextos.

Valores negativos geralmente representam erros.

Por exemplo:

-204

normalmente indica problema relacionado a objeto não encontrado ou não definido no contexto esperado.

Mas não decore cegamente.

O reflexo correto é:

SQL falhou
   │
   ▼
ler SQLCODE
   │
   ▼
ler SQLSTATE
   │
   ▼
ler mensagem
   │
   ▼
investigar

Não faça manutenção por astrologia.

21. Erro proposital é ferramenta de aprendizado

No laboratório, você pode executar algo propositalmente errado:

SELECT XPTO
FROM SYSIBM.SYSTABLES;

Se XPTO não existir, o Db2 reclamará.

Isso permite treinar a leitura de mensagens.

O iniciante que aprende a interpretar erros vale muito mais do que aquele que só consegue repetir exemplos que funcionam.

22. SELECT que retorna zero linhas não está necessariamente errado

Outro erro conceitual clássico.

Você executa:

SELECT CREATOR,
       NAME
FROM SYSIBM.SYSTABLES
WHERE NAME = 'ET_DE_VARGINHA';

Se nenhuma tabela tiver esse nome, provavelmente retornará zero registros.

Isso não quer dizer que o SQL está errado.

Quer dizer apenas:

comando válido
+
nenhum registro satisfaz a condição

Essa diferença será fundamental quando você trabalhar com COBOL + Db2.

23. SPUFI e COBOL: irmãos mais próximos do que parecem

Depois você encontrará programas como:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTES
    WHERE ID_CLIENTE = :WS-ID
END-EXEC.

Antes de colocar um SQL dentro do COBOL, é muito comum testar a consulta primeiro no SPUFI.

Por exemplo:

SELECT NOME,
       SALDO
FROM CLIENTES
WHERE ID_CLIENTE = 123;

Se funcionar, você já validou parte da lógica SQL.

Depois transforma isso em embedded SQL no programa.

24. O que são host variables?

No COBOL, o Db2 precisa trocar dados com variáveis do programa.

Por isso aparecem:

:WS-NOME
:WS-SALDO

O : identifica uma host variable.

Ou seja:

Db2
 │
 ├── NOME  ───────► WS-NOME
 └── SALDO ───────► WS-SALDO

No SPUFI você não precisa pensar nisso inicialmente.

E esse é um dos motivos pelos quais SPUFI é tão bom para aprendizado.

Primeiro:

SQL puro

Depois:

SQL + COBOL

25. O DCLGEN espreita na sala ao lado

No DB2I você também pode encontrar o:

DCLGEN

Ele ajuda a gerar declarações relacionadas às tabelas Db2 para utilização em programas.

Ou seja:

Tabela Db2
   │
   ▼
DCLGEN
   │
   ▼
estrutura compatível com programa COBOL

Esse será um próximo passo natural depois de dominar SPUFI e catálogo.

26. O pipeline COBOL + Db2

Mais adiante você aprenderá:

COBOL + SQL
     │
     ▼
PRECOMPILE
   /    \
  ▼      ▼
COBOL   DBRM
  │      │
  ▼      ▼
COMPILE BIND
  │      │
  ▼      ▼
OBJ    PACKAGE

É aí que o Db2 deixa de parecer apenas “um banco acessado pelo SPUFI” e passa a fazer parte da execução de aplicações corporativas reais.

27. AUTOCOMMIT — botão vermelho da sala MIB

SPUFI também pode executar comandos de alteração:

INSERT
UPDATE
DELETE

E aí entra uma palavra importantíssima:

COMMIT

Dependendo da configuração de AUTOCOMMIT, alterações podem ser confirmadas automaticamente.

E isso é perigoso para iniciantes.

Imagine:

UPDATE CLIENTES
SET STATUS = 'I';

Sem WHERE.

Parabéns.

Você pode ter atualizado a tabela inteira.

Portanto a regra Bellacosa é simples:

SELECT primeiro

COUNT depois

confira o alvo

somente então considere UPDATE

Especialmente em ambiente real.

Produção não é laboratório.

28. Como descobrir o Db2 disponível para seu USER-ID

Quando entrar num novo ambiente, siga esta sequência.

Primeiro:

TSO/E
  │
  ▼
ISPF
  │
  ▼
DB / DB2I

Veja qual SSID está configurado.

Depois entre no SPUFI.

Execute:

SELECT CURRENT USER,
       CURRENT SQLID,
       CURRENT SERVER
FROM SYSIBM.SYSDUMMY1;

Isso ajuda a entender sua identidade e contexto dentro do Db2.

Depois:

SELECT CURRENT DATE,
       CURRENT TIME
FROM SYSIBM.SYSDUMMY1;

Se funcionar, há comunicação.

Depois explore:

SELECT CREATOR,
       NAME,
       TYPE
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'SYSIBM'
FETCH FIRST 20 ROWS ONLY;

Pronto.

A investigação começou.

29. Checklist MIB para seu primeiro dia no Db2

Ao receber um USER-ID novo, descubra:

Qual é meu USER-ID TSO?

Qual menu dá acesso ao Db2?

Qual é o SSID?

Consigo entrar no DB2I?

Consigo abrir o SPUFI?

Qual dataset de entrada devo usar?

Qual dataset de saída devo usar?

Qual é meu CURRENT USER?

Qual é meu CURRENT SQLID?

Qual é meu CURRENT SERVER?

Consigo consultar SYSIBM.SYSTABLES?

Consigo consultar SYSCOLUMNS?

Consigo consultar SYSINDEXES?

Se você responde a essas perguntas, já não está mais completamente perdido.

30. Easter egg: o neuralizador do programador COBOL

Todo profissional experiente já viu alguém fazer:

SELECT *

sem filtro.

Depois a tela enche.

O usuário aperta PF3.

Aperta de novo.

Mais uma vez.

Olha para o colega.

O colega olha de volta.

Ninguém fala sobre o que aconteceu.

Esse é o neuralizador oficial do ISPF.

31. Outra curiosidade: o mainframe gosta de saber quem fez o quê

Em sistemas modernos, muita gente vende como novidade:

rastreabilidade;
autenticação;
privilégios;
logs;
identidades;
separação de ambientes;
transações;
controle de acesso.

O mainframe olha e diz:

“Interessante. Fazemos isso há algumas décadas.”

Db2, RACF, JES2 e z/OS foram construídos num mundo em que compartilhamento de recursos, segurança e auditoria não eram acessórios.

E por isso conceitos como USER-ID, autorização, subsystem e catálogo importam tanto.

32. O mapa final da missão

Se você guardar apenas um desenho deste artigo, guarde este:

                    IBM Z
                      │
                      ▼
                    z/OS
                      │
                      ▼
                    TSO/E
                      │
                      ▼
                    ISPF
                      │
                      ▼
                     DB
                      │
                      ▼
                    DB2I
                      │
                      ▼
                    SPUFI
                      │
                      ▼
                 Db2 for z/OS
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      SYSTABLES   SYSCOLUMNS   SYSINDEXES
          │           │           │
          ▼           ▼           ▼
       objetos      colunas      índices

Esse desenho explica praticamente toda a nossa conversa.

Epílogo — agente, bem-vindo ao mainframe

O iniciante olha para o ISPF e vê uma tela antiga.

O especialista olha e vê uma interface para décadas de evolução tecnológica.

O iniciante olha para DB e vê duas letras misteriosas.

O especialista vê uma rota para o Db2.

O iniciante olha para SPUFI e vê uma ferramenta ultrapassada.

O especialista vê uma bancada rápida para testar SQL, investigar catálogo, validar hipóteses e compreender dados.

O iniciante olha para SYSIBM e vê tabelas estranhas.

O especialista vê o mapa do território.

E talvez essa seja a maior lição deste laboratório.

Mainframe não é sobre decorar siglas.

É sobre aprender a navegar.

Quando você entende:

TSO/E
ISPF
DB
DB2I
SPUFI
SYSIBM
SQLCODE

as coisas deixam de parecer uma coleção de artefatos alienígenas.

Elas começam a formar um sistema.

Você entende onde está.

Sabe quem é.

Descobre qual Db2 está acessando.

Investiga seus objetos.

Lê suas mensagens.

Testa SQL.

E depois conecta tudo ao COBOL.

Esse é o ponto em que o agente novato deixa de perguntar:

“Onde eu clico?”

e começa a perguntar:

“Qual componente estou usando, qual informação ele me fornece e qual é o próximo ponto da investigação?”

Nesse momento, os Homens de Preto podem guardar o neuralizador.

O programador COBOL já começou a enxergar o universo.

☕ E no Bellacosa Mainframe, até alienígena precisa de USER-ID, autorização e um bom WHERE.

Translate

sexta-feira, 6 de outubro de 2023