✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe um roadmap para começar uma carreira em IBM
☕ Um Café no Bellacosa Mainframe
🚀 Quer Começar uma Carreira em IBM Mainframe?
Parte I — Os Primeiros Passos do Programador COBOL Padawan na Academia da Frota Estelar
"A lógica é o começo da sabedoria, não o fim." — Sr. Spock
Introdução — A Primeira Missão
Imagine que você acaba de receber uma carta de admissão para a Academia da Frota Estelar. Seu sonho sempre foi explorar o espaço, conhecer novas civilizações e operar a nave mais avançada da Federação: a USS Enterprise.
Agora troque a Enterprise por um IBM Z.
A Academia da Frota Estelar pelos programas gratuitos da IBM.
Os oficiais veteranos pelos especialistas em Mainframe.
E você...
...é o novo Programador COBOL Padawan.
Muita gente acredita que aprender Mainframe significa apenas decorar comandos COBOL ou escrever alguns JCLs. Essa é uma visão tão limitada quanto imaginar que o Capitão Kirk passa o dia apenas apertando botões na ponte de comando.
Na realidade, um profissional IBM Z entende como dezenas de tecnologias trabalham em perfeita harmonia para processar milhões — e, em muitos casos, bilhões — de transações diariamente.
A boa notícia é que nunca foi tão fácil começar.
Hoje existem cursos gratuitos, laboratórios online, desafios gamificados, documentação oficial e uma comunidade global pronta para ajudar novos talentos.
Neste artigo, vamos explorar os melhores caminhos para iniciar essa jornada.
Pegue seu café.
Ajuste seu terminal 3270.
E prepare-se para embarcar.
Por que aprender Mainframe em 2022?
Existe um mito muito comum:
"Mainframe é tecnologia antiga."
Nada poderia estar mais distante da realidade.
O IBM Z evolui continuamente e incorpora recursos modernos como:
Inteligência Artificial
Computação Quântica integrada por APIs
Linux
Kubernetes
Containers
DevOps
Git
VS Code
Open Source
APIs REST
Cloud híbrida
Criptografia avançada
Computação confidencial
Enquanto startups surgem e desaparecem, bancos, seguradoras, bolsas de valores, empresas aéreas, governos e operadoras continuam confiando no IBM Z para executar cargas críticas com disponibilidade próxima de 100%.
É por isso que aprender Mainframe continua sendo uma excelente decisão de carreira.
A Academia Oficial da Federação (IBM)
Se Star Trek possui a Academia da Frota Estelar, o universo IBM possui um equivalente: um conjunto de plataformas gratuitas de aprendizado.
Elas foram criadas para formar a próxima geração de profissionais IBM Z.
O Mainframe também participa do mundo Open Source.
O Open Mainframe Project reúne iniciativas importantes como:
Zowe
COBOL Programming Course
Feilong
Modernização
Ferramentas DevOps
Comunidade internacional
É uma excelente forma de acompanhar a evolução do ecossistema IBM Z além das soluções comerciais.
O Primeiro Plano de Estudos
Se eu estivesse começando hoje, seguiria esta sequência:
Conceitos de Mainframe
IBM Z Mainframe Skills Depot
IBM Z Xplore
Learning COBOL Programming with VS Code
IBM SkillsBuild
IBM Developer
Open Mainframe Project
IBM Redbooks
Com essa base, você já terá uma visão consistente do ecossistema IBM Z antes de mergulhar em tecnologias específicas.
Curiosidades da Engenharia Estelar
O IBM Z é capaz de processar volumes gigantescos de transações com altíssima disponibilidade.
COBOL continua sendo uma das linguagens mais utilizadas em sistemas financeiros de missão crítica.
Muitos ambientes IBM Z modernos utilizam Git, VS Code, APIs REST, containers e práticas DevOps.
Há iniciativas abertas que permitem aprender e desenvolver para Mainframe utilizando ferramentas modernas, aproximando o ecossistema IBM Z do universo open source.
Café com Spock ☕
Se o Sr. Spock fosse mentor de um programador COBOL, provavelmente diria:
"Não tente aprender tudo ao mesmo tempo. A lógica vem antes da sintaxe. Domine os fundamentos, e as ferramentas deixarão de parecer misteriosas."
Essa é uma excelente filosofia para quem está começando. Não se preocupe em decorar centenas de comandos ou utilitários. Construa uma base sólida, pratique com frequência e avance em etapas.
Conclusão da Parte 1
Toda grande jornada começa com um primeiro passo. No universo IBM Mainframe, esse passo é aproveitar os recursos gratuitos que hoje estão disponíveis para qualquer pessoa interessada em aprender. O IBM Z Mainframe Skills Depot, o IBM Z Xplore, o curso oficial de COBOL com VS Code, o IBM Training, o IBM SkillsBuild, o IBM Developer e o Open Mainframe Project formam uma verdadeira academia de treinamento, capaz de transformar um iniciante em um profissional preparado para enfrentar desafios reais.
Na Parte 2, embarcaremos em uma nova missão: conheceremos em detalhes as principais tecnologias do ecossistema IBM Z — COBOL, JCL, VSAM, QSAM, Db2, CICS, IMS, RACF e z/OS — entendendo como cada uma funciona e por que elas continuam sendo a espinha dorsal dos sistemas corporativos mais importantes do mundo. Afinal, como em uma nave da Federação, cada componente tem uma função essencial para que a missão seja cumprida com sucesso. 🖖
----------------
☕ Um Café no Bellacosa Mainframe
🚀 Quer Começar uma Carreira em IBM Mainframe?
Navegue pelas quatro partes da série e acompanhe a jornada do
Programador COBOL Padawan, dos primeiros cursos até a construção
de uma carreira no universo IBM Z.
Parte I
Os primeiros passos do Programador COBOL Padawan
Cursos gratuitos, IBM Z Xplore, Skills Depot e as primeiras
coordenadas para entrar no universo Mainframe.
SPUFI sem Mistérios: do Primeiro SELECT ao Dataset de Saída no Db2 for z/OS
O guia do programador COBOL Padawan para entender SQL, datasets, isolamento, CCSID, commit, JCL e tudo o que acontece por trás da tela verde
Imagine a cena.
Você acabou de entrar no TSO, abriu o ISPF, navegou até o DB2I e escolheu a opção SPUFI. Diante de você aparece aquela clássica tela preta, com letras verdes e azuis, campos numerados e algumas opções que parecem inocentes:
O programador COBOL Padawan olha para aquilo e pensa:
“Eu só queria executar um SELECT. Por que preciso informar dataset, volume, senha, isolamento, formato, espaço primário, espaço secundário, LRECL, BLKSIZE e CCSID?”
Essa pergunta é perfeita.
Ela revela uma diferença fundamental entre o mundo distribuído e o universo IBM Mainframe.
Em muitas ferramentas modernas, você abre uma janela, digita SQL e recebe o resultado em uma grade gráfica. No z/OS, entretanto, cada etapa foi construída para ser explícita, controlável, auditável e reutilizável. O SPUFI não trabalha apenas com uma “caixa de texto”. Ele trabalha com datasets reais, parâmetros de execução, formatos de registro, controle transacional e integração direta com o subsistema Db2.
O SPUFI é simples na aparência, mas por trás daquela tela existe uma pequena cadeia de processamento digna de uma aplicação batch.
Prepare o café, abra o caderno de anotações e ajuste os óculos de programador Jedi. Vamos desmontar o SPUFI peça por peça.
Bellacosa Mainframe o que é o Spufi?
1. O que é SPUFI?
SPUFI significa:
SQL Processor Using File Input
Em uma tradução livre:
Processador SQL usando um arquivo como entrada.
Esse nome descreve exatamente o que a ferramenta faz.
O SPUFI:
lê comandos SQL de um dataset;
envia esses comandos ao Db2;
recebe o resultado;
grava as mensagens e linhas retornadas em outro dataset;
opcionalmente abre o resultado para consulta.
Seu fluxo básico é:
Programador
|
v
Dataset com SQL
|
v
SPUFI
|
v
Plano/Pacote do DB2I
|
v
Subsistema Db2
|
v
Parser + Otimizador + Executor
|
v
Dataset de saída
Perceba um detalhe importante: o SPUFI não é o banco de dados, nem o otimizador e nem o mecanismo responsável por acessar as tabelas.
Ele é uma interface.
Quem realmente valida, otimiza e executa o SQL é o Db2.
2. Por que o SPUFI continua importante?
Mesmo existindo ferramentas gráficas, IDEs, plugins para VS Code, interfaces web e utilitários distribuídos, o SPUFI continua extremamente útil porque:
executa SQL diretamente dentro do ambiente z/OS;
usa a autenticação do usuário TSO;
acessa o subsistema Db2 local;
não depende de configuração ODBC ou JDBC externa;
grava a entrada e a saída em datasets;
facilita auditoria e repetição dos testes;
funciona bem em ambientes restritos;
é familiar para DBAs, sysprogs e desenvolvedores veteranos.
Além disso, o SPUFI é uma excelente escola.
Quem aprende SPUFI acaba aprendendo, mesmo sem perceber:
PDS e membros;
datasets sequenciais;
atributos DCB;
alocação em DASD;
CCSID;
terminadores SQL;
níveis de isolamento;
commits;
planos e pacotes;
códigos SQL;
organização de scripts.
Portanto, o SPUFI não é apenas uma ferramenta antiga. Ele é uma ponte entre SQL e a cultura operacional do mainframe.
3. A primeira tela: o painel principal do SPUFI
Na tela mostrada, temos algo semelhante a:
SPUFI SSID: DB9G
Enter the input data set name:
1 DATA SET NAME ... ===> 'IBMUSER.WORKBOOK.SQL(SELCOPA)'
2 VOLUME SERIAL .... ===>
3 DATA SET PASSWORD ===>
Enter the output data set name:
4 DATA SET NAME ... ===> 'INEFE00.OUTPUT.SAIDA'
Specify processing options:
5 CHANGE DEFAULTS .. ===> YES
6 EDIT INPUT ....... ===> YES
7 EXECUTE .......... ===> YES
8 AUTOCOMMIT ....... ===> YES
9 BROWSE OUTPUT .... ===> YES
For remote SQL processing:
10 CONNECT LOCATION . ===>
No canto superior direito aparece:
SSID: DB9G
SSID significa Subsystem Identifier.
É o identificador do subsistema Db2 ao qual o DB2I está conectado.
Em uma instalação, podem existir vários subsistemas:
DB2D Desenvolvimento
DB2T Testes
DB2H Homologação
DB2P Produção
DB9G Laboratório ou ambiente específico
O nome não possui significado universal. Cada empresa define sua convenção.
Um Padawan deve sempre observar o SSID antes de executar qualquer comando destrutivo.
Um DELETE no ambiente errado pode transformar uma aula tranquila em uma reunião extraordinária com DBA, gestor, auditoria, segurança e provavelmente alguém perguntando por que não havia WHERE.
4. Campo 1 — DATA SET NAME de entrada
No exemplo:
'IBMUSER.WORKBOOK.SQL(SELCOPA)'
Esse nome possui duas partes:
IBMUSER.WORKBOOK.SQL
É o dataset.
SELCOPA
É o membro.
Isso indica que o dataset provavelmente é um PDS ou PDSE.
Com YES, o SPUFI abre a tela de parâmetros padrão.
Com NO, utiliza os valores já salvos no perfil do usuário ou na configuração da instalação.
Essa opção é útil quando você precisa alterar:
nível de isolamento;
número máximo de linhas;
terminador SQL;
atributos do dataset de saída;
largura das colunas;
formato dos cabeçalhos.
Para uma consulta simples, você pode usar NO.
Para aprender ou ajustar comportamento, use YES.
10. Campo 6 — EDIT INPUT
EDIT INPUT ===> YES
Com YES, o SPUFI abre o membro de entrada no editor ISPF antes da execução.
O fluxo será:
SPUFI
|
+--> abre ISPF Edit
|
+--> você grava o SQL
|
+--> pressiona PF3
|
+--> SPUFI executa
Com NO, ele executa diretamente o conteúdo atual do dataset.
Isso é útil quando o script já está pronto e não precisa ser revisado.
Exemplo de SQL para iniciantes
SELECT CURRENT DATE,
CURRENT TIME,
CURRENT TIMESTAMP
FROM SYSIBM.SYSDUMMY1;
A tabela SYSIBM.SYSDUMMY1 é uma tabela especial com uma única linha, muito usada para testar expressões.
É o equivalente Db2 de uma pequena bancada de laboratório.
11. Campo 7 — EXECUTE
EXECUTE ===> YES
Com YES, o SQL será enviado ao Db2.
Com NO, o SPUFI pode permitir que você apenas edite o input sem executar.
Parece inútil, mas é interessante quando o SPUFI está sendo usado apenas como uma forma rápida de localizar e modificar um membro SQL.
12. Campo 8 — AUTOCOMMIT
AUTOCOMMIT ===> YES
Esse é um dos campos mais perigosos da tela.
Com YES, o SPUFI confirma automaticamente uma unidade de trabalho bem-sucedida.
Exemplo:
UPDATE CORP.CLIENTE
SET STATUS = 'I'
WHERE CLIENTE_ID = 100;
Se o comando funcionar e AUTOCOMMIT=YES, a alteração será confirmada.
Um ROLLBACK posterior não desfará essa atualização.
Para SELECT
Em consultas, o risco é pequeno.
Para INSERT, UPDATE e DELETE
Atenção máxima.
Durante testes, uma prática mais segura é:
AUTOCOMMIT ===> NO
E incluir comandos explícitos:
UPDATE CORP.CLIENTE
SET STATUS = 'I'
WHERE CLIENTE_ID = 100;
SELECT CLIENTE_ID,
STATUS
FROM CORP.CLIENTE
WHERE CLIENTE_ID = 100;
ROLLBACK;
Assim você verifica o resultado e depois desfaz.
Quando estiver absolutamente certo:
UPDATE CORP.CLIENTE
SET STATUS = 'I'
WHERE CLIENTE_ID = 100;
COMMIT;
Cuidado especial com DELETE
Nunca execute casualmente:
DELETE FROM CORP.CLIENTE;
Sem WHERE, todas as linhas elegíveis podem ser removidas.
Antes de executar um DELETE, transforme-o em SELECT:
SELECT *
FROM CORP.CLIENTE
WHERE STATUS = 'I';
Confira a quantidade.
Depois:
DELETE
FROM CORP.CLIENTE
WHERE STATUS = 'I';
Esse pequeno ritual salva carreiras.
13. Campo 9 — BROWSE OUTPUT
BROWSE OUTPUT ===> YES
Com YES, o dataset de saída é aberto automaticamente após a execução.
Com NO, o resultado é gravado, mas você precisará abri-lo manualmente.
Por exemplo, usando:
ISPF 3.4
ou um comando:
BROWSE 'IBMUSER.OUTPUT.SPUFI'
Usar YES é conveniente para testes interativos.
Usar NO pode ser útil quando o resultado é muito grande ou quando o processamento será revisado posteriormente.
14. Campo 10 — CONNECT LOCATION
CONNECT LOCATION ===>
Esse campo permite direcionar a execução para uma localização Db2 remota.
Em ambientes distribuídos, o Db2 pode usar DRDA para comunicação entre subsistemas.
Exemplo conceitual:
Db2 local DB2D
|
| DRDA
v
Db2 remoto DB2P
O valor usado depende da configuração de localização no catálogo Db2.
Para consultas locais, deixe em branco.
15. O aviso DSNE345I e a guerra dos CCSIDs
Na segunda tela aparece:
DSNE345I WARNING: DB2 DATA CORRUPTION CAN RESULT
FROM THIS SPUFI SESSION BECAUSE THE
CCSID USED BY THE TERMINAL IS NOT THE
SAME AS THE CCSID USED BY SPUFI
TERMINAL CCSID: 37
SPUFI CCSID : 1047
Esse não é um simples aviso cosmético.
CCSID significa:
Coded Character Set Identifier
Ele identifica a tabela de codificação de caracteres.
No mundo z/OS, “EBCDIC” não é uma única tabela universal. Existem diferentes variantes.
Entre elas:
CCSID 37;
CCSID 500;
CCSID 1047;
CCSID 1140.
O terminal está usando CCSID 37, enquanto o SPUFI espera 1047.
Caracteres alfabéticos simples podem aparecer corretamente, mas símbolos especiais podem ocupar posições diferentes.
Os maiores suspeitos são caracteres como:
[
]
{
}
|
\
^
~
Imagine uma expressão SQL com texto:
INSERT INTO TESTE.TABELA
(DESCRICAO)
VALUES ('ARQUIVO [TEMP]');
Se houver conversão incorreta, os colchetes podem ser gravados como outros símbolos.
Em um SELECT, você pode apenas ver uma saída estranha.
Em um INSERT ou UPDATE, porém, dados incorretos podem ser persistidos.
O que fazer?
O aviso diz:
NOTIFY THE DB2 SYSTEM ADMINISTRATOR
Isso significa que a solução definitiva normalmente envolve revisar:
configuração do emulador 3270;
code page da sessão;
parâmetros do DB2I;
CCSID do subsistema;
perfil do usuário;
configuração do SPUFI.
No emulador TN3270, procure opções relacionadas a:
host code page;
EBCDIC code page;
character set;
CCSID;
language;
keyboard mapping.
Não altere aleatoriamente em produção. Uma mudança incorreta pode resolver um símbolo e quebrar outro.
16. A tela CURRENT SPUFI DEFAULTS
A terceira tela apresenta os parâmetros internos do SPUFI.
CURRENT SPUFI DEFAULTS
Vamos examinar cada um.
17. SQL TERMINATOR
SQL TERMINATOR ===> ;
O ponto e vírgula indica o fim de cada instrução SQL.
Exemplo:
SELECT COUNT(*)
FROM SYSIBM.SYSTABLES;
Vários comandos:
SELECT CURRENT DATE
FROM SYSIBM.SYSDUMMY1;
SELECT CURRENT TIME
FROM SYSIBM.SYSDUMMY1;
Alterando o terminador
Em alguns scripts, especialmente com rotinas SQL PL, o ponto e vírgula também aparece dentro de blocos.
Pode ser conveniente trocar o terminador externo:
SQL TERMINATOR ===> #
Então:
CREATE PROCEDURE TESTE.PROC1()
LANGUAGE SQL
BEGIN
INSERT INTO TESTE.LOG
VALUES (CURRENT TIMESTAMP);
UPDATE TESTE.CONTROLE
SET STATUS = 'F';
END
#
O # encerra a instrução completa, enquanto os pontos e vírgulas continuam dentro do bloco.
18. ISOLATION LEVEL
Na tela:
ISOLATION LEVEL ===> CS
Os valores mais comuns são:
UR
CS
RS
RR
UR — Uncommitted Read
É a leitura com menor compromisso de consistência.
Permite ler dados que outra transação modificou, mas ainda não confirmou.
Exemplo:
SELECT *
FROM CORP.MOVIMENTO
WITH UR;
Vantagens:
poucos locks;
boa concorrência;
útil para relatórios não críticos.
Riscos:
dirty read;
dados podem desaparecer após rollback;
totais podem não representar um estado confirmado.
Use UR para consultas informativas, nunca como base cega para decisões financeiras ou atualizações dependentes.
CS — Cursor Stability
É o valor mostrado na tela.
O Db2 protege a linha atualmente posicionada pelo cursor e libera locks conforme a navegação, dependendo do plano e da execução.
É um bom equilíbrio entre:
consistência;
concorrência;
desempenho.
É muito comum em aplicações online.
RS — Read Stability
Garante maior estabilidade para as linhas qualificadas já lidas.
Evita que elas sejam modificadas de forma conflitante durante a unidade de trabalho.
Pode manter mais locks.
RR — Repeatable Read
É o nível mais restritivo.
A mesma consulta dentro da unidade de trabalho tende a reencontrar um conjunto estável de linhas, de acordo com as regras do isolamento.
Pode gerar:
muitos locks;
contenção;
timeout;
deadlock;
escalonamento de locks.
Comparação conceitual
Isolamento
Consistência
Concorrência
Locks
UR
baixa
muito alta
mínimos
CS
equilibrada
alta
moderados
RS
alta
média
maiores
RR
muito alta
menor
elevados
19. MAX SELECT LINES
MAX SELECT LINES ===> 250
Esse parâmetro limita a quantidade de linhas exibidas pelo SPUFI.
Ele funciona como um cinto de segurança.
Imagine:
SELECT *
FROM SYSIBM.SYSCOLUMNS;
Dependendo do ambiente, isso pode retornar milhares de linhas.
O SPUFI interrompe a exibição ao atingir o limite configurado.
Atenção: isso não significa necessariamente que o Db2 sempre acessará apenas 250 linhas em todas as circunstâncias. O limite controla principalmente o processamento e apresentação do resultado pelo SPUFI.
Para consultas grandes, prefira filtros:
SELECT NAME,
CREATOR,
TYPE
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'IBMUSER'
ORDER BY NAME;
20. ALLOW SQL WARNINGS
ALLOW SQL WARNINGS ===> NO
SQL warnings são avisos que não representam necessariamente falha fatal.
O SQLCA pode trazer:
SQLCODE positivo
Exemplos comuns incluem:
truncamento;
eliminação de valores nulos em agregações;
nenhuma linha em certas operações;
condições especiais de processamento.
Com NO, o SPUFI pode interromper ou tratar de maneira mais conservadora.
Com YES, ele pode continuar buscando linhas após avisos.
Para aprendizado, deixar NO ajuda a perceber que algo especial ocorreu.
21. CHANGE PLAN NAMES
CHANGE PLAN NAMES ===> NO
O SPUFI executa sob estruturas Db2 previamente definidas, incluindo planos e pacotes do DB2I.
Essa opção permite trabalhar com nomes alternativos em configurações específicas.
Para o programador iniciante, a recomendação é manter:
NO
Alterar planos exige conhecimento de:
BIND;
PACKAGE;
PLAN;
COLLECTION;
autorização;
compatibilidade do ambiente.
22. SQL FORMAT
SQL FORMAT ===> SQL
Esse campo define o tratamento do conteúdo SQL.
As opções podem variar conforme versão e configuração, mas geralmente distinguem formatos como:
SQL convencional;
SQL com comentários;
SQL PL.
Para consultas normais:
SQL
é suficiente.
23. SPACE UNIT
SPACE UNIT ===> TRK
Define a unidade usada para alocar o dataset de saída.
Valores comuns:
TRK
CYL
TRK significa track.
CYL significa cylinder.
Para resultados pequenos, tracks são suficientes.
Para saídas muito grandes, cylinders podem ser mais apropriados.
24. PRIMARY SPACE e SECONDARY SPACE
PRIMARY SPACE ===> 6
SECONDARY SPACE ===> 5
O espaço primário é alocado inicialmente.
O secundário é solicitado quando o espaço inicial se esgota.
Neste exemplo:
SPACE=(TRK,(6,5))
Conceitualmente:
aloque 6 tracks inicialmente;
quando necessário, expanda em blocos de 5 tracks.
Muitas extensões pequenas podem causar fragmentação e atingir limites de extents.
Por outro lado, uma alocação primária exagerada desperdiça espaço.
O tamanho ideal depende do volume esperado.
25. RECORD LENGTH
RECORD LENGTH ===> 4092
É o LRECL do dataset de saída.
Como o resultado pode incluir colunas extensas, o SPUFI usa registros largos.
Um VARCHAR(2000) ou a combinação de várias colunas pode exigir linhas grandes.
Se o LRECL for pequeno demais, a saída pode ser truncada ou a alocação pode falhar, dependendo do cenário.
26. BLOCK SIZE
BLOCK SIZE ===> 4096
O BLKSIZE indica o tamanho dos blocos físicos usados na gravação.
Blocos reduzem a quantidade de operações de I/O.
Em alocações modernas, frequentemente usamos:
BLKSIZE=0
para permitir que o sistema determine um valor eficiente.
Na tela do SPUFI, valores predefinidos podem ser usados conforme a configuração local.
27. RECORD FORMAT
RECORD FORMAT ===> VB
VB significa:
Variable Blocked
Os registros possuem tamanho variável e são agrupados em blocos.
Isso é apropriado para resultados SQL, porque uma linha pode ter 20 bytes e outra 800 bytes.
Outros formatos citados na tela:
F
FB
FBA
V
VB
VBA
F: fixo;
FB: fixo blocado;
FBA: fixo blocado com controle ASA;
V: variável;
VB: variável blocado;
VBA: variável blocado com controle ASA.
28. DEVICE TYPE
DEVICE TYPE ===> SYSDA
SYSDA é um nome genérico de unidade DASD.
O sistema e o SMS determinam o volume apropriado.
Em ambientes gerenciados por SMS, vários parâmetros físicos podem ser escolhidos automaticamente por classes de armazenamento.
29. MAX NUMERIC FIELD
MAX NUMERIC FIELD ===> 33
Define a largura máxima usada para apresentar campos numéricos.
Isso evita que números muito extensos destruam o alinhamento da saída.
Por exemplo:
SELECT DECIMAL(12345678901234567890,20,0)
FROM SYSIBM.SYSDUMMY1;
A configuração controla quanto espaço poderá ser reservado para exibição.
30. MAX CHAR FIELD
MAX CHAR FIELD ===> 80
Define a largura máxima de apresentação das colunas de caracteres.
Imagine uma coluna:
DESCRICAO VARCHAR(1000)
Sem limite, uma única coluna tornaria a saída enorme.
Com máximo 80, a apresentação fica mais administrável.
Atenção: isso pode significar que você não verá todo o conteúdo visualmente na linha formatada.
Quando precisar analisar o valor integral, selecione a coluna isoladamente ou use funções como:
SELECT LENGTH(DESCRICAO),
SUBSTR(DESCRICAO,1,200)
FROM TESTE.PRODUTO;
31. COLUMN HEADING
COLUMN HEADING ===> NAMES
Opções comuns:
NAMES
LABELS
ANY
BOTH
NAMES
Usa o nome técnico da coluna.
CUST_ID
CUST_NAME
LABELS
Usa o label definido no catálogo, se existir.
Código do Cliente
Nome do Cliente
BOTH
Pode mostrar nome e label.
Para desenvolvedores, NAMES costuma ser mais útil porque corresponde ao SQL e ao DCLGEN.
Para relatórios destinados a usuários, labels podem ser mais amigáveis.
32. Primeiro laboratório SPUFI: SELECT simples
Crie um membro chamado TESTE01 com:
SELECT CURRENT SERVER AS SERVIDOR,
CURRENT DATE AS DATA_ATUAL,
CURRENT TIME AS HORA_ATUAL,
CURRENT TIMESTAMP AS TIMESTAMP_ATUAL
FROM SYSIBM.SYSDUMMY1;
SELECT CREATOR,
NAME,
TYPE
FROM SYSIBM.SYSTABLES
WHERE CREATOR = 'IBMUSER'
ORDER BY NAME;
O catálogo Db2 é um conjunto de tabelas que descreve os objetos do banco.
Ele contém informações sobre:
tabelas;
colunas;
índices;
tablespaces;
pacotes;
planos;
privilégios;
estatísticas.
Consultar o catálogo é como abrir o mapa interno do reino Db2.
34. Terceiro laboratório: UPDATE seguro com ROLLBACK
SELECT CLIENTE_ID,
STATUS
FROM TESTE.CLIENTE
WHERE CLIENTE_ID = 100;
UPDATE TESTE.CLIENTE
SET STATUS = 'I'
WHERE CLIENTE_ID = 100;
SELECT CLIENTE_ID,
STATUS
FROM TESTE.CLIENTE
WHERE CLIENTE_ID = 100;
ROLLBACK;
SELECT CLIENTE_ID,
STATUS
FROM TESTE.CLIENTE
WHERE CLIENTE_ID = 100;
Configure:
AUTOCOMMIT ===> NO
A sequência demonstra:
estado inicial;
alteração;
estado dentro da unidade de trabalho;
rollback;
restauração do valor anterior.
Esse é um excelente laboratório para compreender transações.
35. Executando SQL no Db2 por JCL
O SPUFI é interativo, mas o SQL também pode ser executado em batch usando o utilitário DSNTEP2 ou DSNTEP4, dependendo da instalação.
Exemplo:
//SQLBATCH JOB (ACCT),'EXECUTA SQL',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB DD DISP=SHR,DSN=DSN.V13R1M0.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DB9G)
RUN PROGRAM(DSNTEP2) PLAN(DSNTEP13) -
LIB('DSN.V13R1M0.RUNLIB.LOAD')
END
/*
//SYSIN DD *
SELECT CURRENT SERVER,
CURRENT DATE,
CURRENT TIME
FROM SYSIBM.SYSDUMMY1;
SELECT COUNT(*) AS TOTAL_TABELAS
FROM SYSIBM.SYSTABLES;
/*
IKJEFT01
//STEP01 EXEC PGM=IKJEFT01
IKJEFT01 permite executar comandos TSO em batch.
É como criar uma sessão TSO controlada pelo JCL.
DYNAMNBR
DYNAMNBR=20
Reserva capacidade para alocações dinâmicas.
STEPLIB
//STEPLIB DD DISP=SHR,DSN=DSN.V13R1M0.SDSNLOAD
Aponta para a biblioteca de load modules do Db2.
O nome real varia conforme a instalação.
SYSTSIN
DSN SYSTEM(DB9G)
Inicia o command processor do Db2 e conecta ao subsistema DB9G.
RUN PROGRAM(DSNTEP2)
Executa o programa DSNTEP2.
PLAN(DSNTEP13)
Informa o plano associado.
O nome também varia conforme versão e instalação.
LIB('DSN.V13R1M0.RUNLIB.LOAD')
Informa a biblioteca onde o programa será localizado.
SELECT CREATOR,
NAME
FROM SYSIBM.SYSTABLES
WHERE NAME = 'CLIENTE';
Use o nome qualificado:
SELECT *
FROM CORP.CLIENTE;
SQLCODE -206
Coluna não encontrada.
Possíveis causas:
erro de digitação;
coluna pertence a outra tabela;
alias incorreto.
Verifique:
SELECT NAME,
COLNO,
COLTYPE
FROM SYSIBM.SYSCOLUMNS
WHERE TBNAME = 'CLIENTE'
AND TBCREATOR = 'CORP';
SQLCODE -104
Erro de sintaxe.
Exemplo incorreto:
SELECT NOME
CLIENTE;
Faltou FROM.
Correto:
SELECT NOME
FROM CLIENTE;
SQLCODE -551
Usuário sem autorização.
Pode faltar:
SELECT;
INSERT;
UPDATE;
DELETE;
EXECUTE;
uso de package ou plan.
A solução deve ser tratada com o administrador de segurança ou DBA.
SQLCODE -811
Um SELECT INTO retornou mais de uma linha.
No SPUFI isso aparece principalmente em testes de SQL que posteriormente serão usados em COBOL.
A consulta deveria retornar uma linha, mas encontrou várias.
Use filtro mais seletivo ou cursor.
SQLCODE -911
Rollback causado por deadlock ou timeout.
O Db2 desfez a unidade de trabalho.
Possíveis ações:
reduzir duração da transação;
acessar tabelas em ordem consistente;
melhorar índices;
revisar isolamento;
executar commit mais frequente;
investigar concorrência.
SQLCODE -913
Deadlock ou timeout sem rollback automático completo em certos contextos.
Exige análise semelhante ao -911.
38. SPUFI e programas COBOL
O SQL testado no SPUFI pode ser levado para um programa COBOL.
SPUFI:
SELECT FIRSTNME,
LASTNAME
FROM DSN8C10.EMP
WHERE EMPNO = '000010';
COBOL:
EXEC SQL
SELECT FIRSTNME,
LASTNAME
INTO :WS-FIRST-NAME,
:WS-LAST-NAME
FROM DSN8C10.EMP
WHERE EMPNO = :WS-EMPNO
END-EXEC.
A diferença está nas host variables:
:WS-FIRST-NAME
:WS-LAST-NAME
:WS-EMPNO
O SPUFI ajuda a validar:
nomes de tabela;
nomes de coluna;
joins;
filtros;
funções;
acesso esperado.
Mas ele não substitui os testes dentro do programa COBOL, porque o programa ainda envolve:
tipos de dados;
variáveis indicadoras;
SQLCA;
cursores;
commit;
lógica de tratamento de erro;
concorrência;
package e bind.
39. Curiosidades e easter eggs
O SPUFI é mais “batch” do que parece
Apesar de ser usado interativamente, sua lógica é baseada em arquivos de entrada e saída.
Ele se parece com uma pequena rotina batch controlada por painéis ISPF.
O dataset é parte da documentação
Como o SQL permanece salvo no PDS, ele pode servir como:
evidência de teste;
histórico;
material de treinamento;
script reutilizável;
base de automação.
O catálogo é o “Google interno” do Db2
Quando você não sabe se uma tabela existe, qual é a coluna, quem criou um índice ou qual package está ligado, o catálogo geralmente possui a resposta.
IEFBR14 não cria datasets sozinho
O programa é apenas uma moldura. A alocação ocorre pela interpretação do JCL.
Um SELECT também pode causar impacto
Muitos iniciantes acreditam que SELECT é sempre inofensivo.
Não é.
Um SELECT ruim pode:
fazer tablespace scan;
consumir CPU;
ler milhões de páginas;
ocupar buffer pools;
segurar locks;
gerar sort;
afetar outros usuários.
Leitura também é trabalho.
WITH UR não é magia de desempenho
Ele reduz locking de leitura, mas não corrige:
falta de índice;
predicado não indexável;
join ruim;
cardinalidade incorreta;
estatísticas antigas.
40. Checklist do Padawan antes de pressionar Enter
Antes de executar:
1. Estou no SSID correto?
2. O dataset de entrada é o membro correto?
3. O output pode ser sobrescrito?
4. O AUTOCOMMIT está adequado?
5. Existe UPDATE, DELETE ou INSERT?
6. O WHERE foi revisado?
7. Testei o filtro com SELECT?
8. O limite de linhas está razoável?
9. Existe aviso de CCSID?
10. Estou autorizado a executar isso?
Para comandos destrutivos, acrescente:
11. Tenho backup ou possibilidade de rollback?
12. Sei quantas linhas serão afetadas?
13. A unidade de trabalho está controlada?
14. Estou fora do horário crítico?
15. O DBA precisa ser avisado?
Conclusão
O SPUFI é uma das ferramentas mais didáticas do ecossistema Db2 for z/OS.
Na superfície, ele parece apenas uma tela para executar SQL. Em profundidade, porém, ele ensina quase todo o vocabulário operacional do mainframe:
datasets de entrada e saída;
PDS, PDSE e membros;
arquivos sequenciais;
DCB;
RECFM;
LRECL;
BLKSIZE;
espaço primário e secundário;
terminadores SQL;
planos;
pacotes;
isolamento;
commit e rollback;
CCSID;
catálogo;
SQLCODE;
execução interativa;
execução batch por JCL.
Para o programador COBOL Padawan, dominar o SPUFI é aprender a conversar diretamente com o Db2 antes de colocar o SQL dentro de um programa.
É nele que você experimenta.
É nele que você erra com segurança — desde que o AUTOCOMMIT esteja corretamente configurado.
É nele que você descobre que um SQL aparentemente simples pode esconder acesso a milhões de linhas.
E é nele que você começa a enxergar o banco não apenas como um lugar onde os dados vivem, mas como um sistema completo de armazenamento, concorrência, transações, segurança e otimização.
No mundo Bellacosa Mainframe, a tela verde nunca é apenas uma tela verde.
Cada campo é uma porta.
Cada parâmetro conta uma história.
Cada mensagem DSNE é um mestre antigo tentando impedir que o Padawan corrompa caracteres, bloqueie uma tabela ou execute um DELETE sem WHERE.
Do código-fonte aos copybooks: entendendo o que realmente acontece antes da compilação
Introdução
Todo programa COBOL começa como uma ideia de negócio.
Pode ser o cálculo dos juros de um financiamento, a atualização do saldo de uma conta, o processamento de uma folha de pagamento ou a leitura de milhões de registros durante a madrugada.
O programador transforma essa regra em código-fonte:
IDENTIFICATION DIVISION.
PROGRAM-ID. PGMCLI01.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-NOME PIC X(40).
01 WS-IDADE PIC 9(03).
PROCEDURE DIVISION.
DISPLAY 'INICIO DO PROGRAMA'
MOVE 'PADAWAN COBOL' TO WS-NOME
MOVE 25 TO WS-IDADE
DISPLAY WS-NOME
DISPLAY WS-IDADE
STOP RUN.
Para o iniciante, o programa parece pronto.
Mas a CPU do IBM Z não entende diretamente comandos como MOVE, DISPLAY, READ, PERFORM ou COMPUTE.
O código ainda precisará atravessar uma verdadeira linha de montagem industrial antes de se transformar em algo executável.
Nesta primeira parte, conheceremos o código-fonte, os copybooks e os elementos que formam a matéria-prima de uma aplicação COBOL.
1. O código-fonte COBOL
O código-fonte normalmente fica armazenado em uma biblioteca particionada, como um PDS ou PDSE.
Exemplo:
EMPRESA.SISTEMA.COBOL
Dentro dessa biblioteca existem membros:
PGMCLI01
PGMCLI02
PGMREL01
PGMCALC
Cada membro pode representar um programa.
Assim:
EMPRESA.SISTEMA.COBOL(PGMCLI01)
significa que PGMCLI01 é um membro da biblioteca de fontes.
O código-fonte é legível para seres humanos, mas ainda não está em linguagem de máquina.
Podemos comparar o fonte com uma receita.
A receita explica:
quais ingredientes serão usados;
quais operações deverão ser realizadas;
em que ordem;
quais decisões precisam ser tomadas;
qual resultado deverá ser produzido.
Porém, possuir uma receita não significa que o prato já esteja pronto.
2. O que é um copybook?
O copybook é um fragmento reutilizável de código COBOL.
Ele pode conter:
layouts de registros;
áreas de comunicação;
estruturas de arquivos;
campos utilizados por vários programas;
códigos de retorno;
estruturas de mensagens;
dados recebidos de outros sistemas;
definições de tabelas;
áreas utilizadas por CICS, Db2, IMS ou Adabas.
Imagine que vários programas utilizem o mesmo registro de cliente:
Se dois copybooks tiverem o mesmo nome, o primeiro localizado poderá ser utilizado.
É por isso que a configuração da compilação precisa ser controlada.
7. Um programa pode depender de muitos componentes
Mesmo antes de ser compilado, um fonte COBOL pode depender de:
Código-fonte
Copybooks
Layouts de arquivos
Áreas de comunicação
Definições de mensagens
SQL embutido
Comandos CICS
Interfaces IMS
Interfaces Adabas
Opções do compilador
Isso explica por que não basta copiar apenas o fonte de um ambiente para outro.
O programa também depende do ecossistema ao redor dele.
8. O primeiro mapa mental
Nesta etapa, temos:
Regra de negócio
↓
Código-fonte COBOL
↓
Copybooks e estruturas reutilizadas
↓
Fonte completo para processamento
Ainda não existe um executável.
Existe apenas uma descrição estruturada do que o sistema deverá fazer.
Bellacosa Maifnrame e o fluxo da compilacao cobol
Conclusão da Parte I
O programa COBOL nasce como fonte, geralmente dentro de uma biblioteca PDS ou PDSE.
Os copybooks fornecem estruturas reutilizáveis e funcionam como contratos entre programas, arquivos e subsistemas.
Porém, a CPU ainda não consegue executar esse material.
Antes da compilação, alguns programas precisam passar por tradutores e pré-compiladores especializados.
Comandos como:
EXEC CICS
EXEC SQL
não pertencem diretamente à linguagem COBOL.
Eles precisam ser transformados antes que o compilador possa fazer seu trabalho.
No próximo capítulo
Na Parte II, entraremos no território dos comandos CICS, SQL Db2, chamadas IMS e interfaces Adabas.
Veremos por que um programa pode precisar ser traduzido ou pré-processado antes da compilação e entenderemos o papel de cada subsistema nessa grande linha de montagem.
PARTE II — CICS, Db2, IMS e Adabas
Os tradutores, pré-compiladores e interfaces que preparam o COBOL para os subsistemas corporativos
Introdução
Na primeira parte, vimos que o programa COBOL nasce como código-fonte e pode reutilizar estruturas armazenadas em copybooks.
Agora surge uma nova pergunta:
O compilador COBOL consegue entender tudo o que aparece dentro de um programa corporativo?
A resposta é não.
Comandos como:
EXEC CICS
SEND TEXT
END-EXEC.
ou:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
END-EXEC.
não são comandos COBOL tradicionais.
Eles pertencem a outros ambientes.
Por isso, o programa precisa ser preparado para que o compilador consiga processá-lo.
1. Programas COBOL com CICS
O CICS é um monitor de processamento de transações.
O Nucleus é o componente central que recebe e processa as solicitações.
Durante a linkedição, o programa pode precisar das interfaces fornecidas para comunicação com o ambiente Adabas.
13. O princípio comum dos subsistemas
CICS, Db2, IMS e Adabas possuem arquiteturas diferentes.
Entretanto, existe uma ideia comum:
O programa COBOL não executa tudo sozinho.
Ele solicita serviços a componentes especializados.
COBOL → regra de negócio
CICS → transações
Db2 → banco relacional
IMS → banco hierárquico e mensagens
Adabas → gerenciamento de dados
Essa separação torna os sistemas mais controlados e escaláveis.
Conclusão da Parte II
Antes de chegar ao compilador, um programa pode precisar ser traduzido ou pré-processado.
O CICS traduz seus comandos embutidos.
O Db2 processa o SQL e produz um DBRM.
O IMS fornece interfaces DL/I e estruturas de controle.
O Adabas oferece seus próprios blocos e módulos de comunicação.
Depois dessa preparação, o fonte finalmente estará pronto para ser transformado em código objeto.
No próximo capítulo
Na Parte III, veremos o coração técnico do processo:
compilação;
código objeto;
linkedição;
Binder;
chamadas estáticas e dinâmicas;
load modules;
load libraries.
É nesse momento que o código começa verdadeiramente a se transformar em um programa executável.
PARTE III — Compilação, Linkedição e Load Library
Como o fonte COBOL se transforma em um módulo executável no IBM Z
Introdução
Depois que copybooks foram incluídos e comandos CICS ou SQL foram devidamente preparados, o programa está pronto para entrar na linha de montagem principal.
Agora o compilador COBOL analisará o fonte e produzirá código objeto.
Em seguida, o Binder reunirá esse objeto com interfaces e módulos necessários, criando o executável.
Essa é a etapa em que o programa deixa de ser apenas texto e começa a se aproximar da linguagem compreendida pelo processador.
1. O que é compilação?
Compilar significa transformar o código-fonte COBOL em código objeto.
O FILE STATUS ajuda o programa a compreender o resultado de uma operação.
Exemplos conhecidos:
00 → operação concluída
10 → fim do arquivo sequencial
22 → possível chave duplicada
23 → registro não encontrado
35 → problema de abertura ou arquivo ausente
A interpretação exata deve considerar o contexto e a documentação.
O compilador não consegue prever esses erros.
Eles dependem dos dados e do ambiente de execução.
Durante a execução, o JCL conecta o programa aos dados.
Essa separação permite grande flexibilidade operacional.
9. O que o JES2 faz?
JES2 significa Job Entry Subsystem 2.
Ele gerencia a entrada, a fila e a saída dos jobs.
Fluxo simplificado:
SUBMIT do JCL
↓
JES2 recebe o job
↓
Job entra no spool
↓
Classe e prioridade são avaliadas
↓
Job aguarda execução
↓
Initiator seleciona o job
↓
Steps são executados
↓
Saídas voltam ao spool
↓
Usuário consulta no SDSF
O JES2 não compila o COBOL.
Ele também não executa diretamente as instruções na CPU.
Sua função é organizar e administrar o fluxo dos jobs.
10. O spool
O spool é uma área em disco usada para armazenar entrada e saída.
O loader coloca o programa no ambiente de memória.
O z/OS administra recursos.
O WLM ajuda a orientar prioridades.
O dispatcher entrega tempo de processador.
A CPU executa as instruções de máquina.
QSAM, VSAM, CICS, Db2, IMS e Adabas fornecem serviços especializados.
O iniciante enxerga apenas um programa.
O especialista enxerga uma cadeia completa de engenharia.
Palavra final do Mestre Bellacosa
Quando alguém disser:
“É só compilar e executar”,
lembre-se de tudo o que existe por trás desse simples comando.
No IBM Z, o programa precisa atravessar uma arquitetura construída para processar milhões de transações com segurança, disponibilidade, controle e previsibilidade.
O Padawan acredita que a jornada termina quando escreve o último STOP RUN.
O especialista sabe que, naquele momento, a verdadeira jornada está apenas começando.
☕
“O COBOL descreve a regra. O compilador constrói o caminho. O Binder reúne as peças. O z/OS prepara o terreno. E a CPU transforma décadas de conhecimento de negócio em processamento real.”
Laboratório Forense Bellacosa Mainframe
CSI z/OS:
Da Compilação à Execução
de um Programa COBOL
Cinco arquivos de evidências revelam como o código-fonte COBOL
atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load
library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.
CASO: COBOL-2022-EXECEVIDÊNCIAS: 05 ARTIGOSAMBIENTE: IBM Z / z/OSSTATUS: ARQUIVO ABERTO
Esta investigação técnica apresenta o ciclo completo de um
programa COBOL no mainframe IBM Z. A série explica o
nascimento do código-fonte, o uso de copybooks, a preparação de comandos
CICS e SQL, a geração de código objeto, a atuação do Binder, o
armazenamento em load libraries e a execução por JCL, JES2, loader,
Language Environment, dispatcher e CPU. Selecione uma evidência abaixo
para ler o artigo correspondente dentro do visualizador.
Evidência selecionada
Parte I — Código-fonte, bibliotecas e copybooks
A primeira parte acompanha a transformação da regra de negócio em
código-fonte COBOL, explica o papel das bibliotecas e mostra por que
copybooks funcionam como contratos de dados compartilhados entre
programas.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
