 |
| 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
E:
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.
