 |
| Bellacosa Mainframe apresenta SMP/E Restore |
Se APPLY é instalar e ACCEPT é oficializar, RESTORE é o botão de “desfaz” do SMP/E.
Mas não se engane: RESTORE não é CTRL+Z. Ele exige entendimento profundo de dependências, níveis de serviço e do que está no target versus no distribution.
Vamos destrinchar isso no melhor estilo Bellacosa Mainframe: sem romantismo, com realidade de produção.
O RESTORE permite remover um ou mais SYSMODs aplicados no target, reinstalando o nível existente nos DLIBs (distribution libraries) de volta para as target libraries.
📌 Ponto-chave
RESTORE só funciona para SYSMODs que foram APPLIED e ainda NÃO ACCEPTED.
Na prática:
Algo foi aplicado
Quebrou, gerou erro, impacto funcional ou regressão
Você precisa voltar o código para o último nível aceito
RESTORE entra em ação.
RESTORE é sempre direcionado a um Target Zone:
Esse target zone:
Identifica as target libraries
Mapeia qual distribution zone (DZONE) contém o backup válido
Será atualizado com os metadados corretos após o restore
📦 O SMP/E não inventa código
Ele reinstala exatamente o que está nos DLIBs.
Durante o processamento, o SMP/E:
✔ Substitui os elementos do target pelos elementos do DLIB
✔ Reexecuta link-edit se necessário
✔ Copia FMID, RMID e UMID do DZONE para o TZONE
✔ Atualiza o CSI
✔ Remove registros do SYSMOD restaurado (dependendo das opções)
Ou seja:
O target volta a refletir o último nível oficialmente aceito.
| APPLY | RESTORE |
|---|---|
| Usa SMPPTS | Usa DLIBs |
| Entrada: Global Zone + SMPPTS | Entrada: DZONE + DLIBs |
| Instala novo código | Reinstala código anterior |
| Avança nível | Retrocede nível |
👉 Ambos atualizam Target Libraries e Target Zone, mas com propósitos opostos.
Se o SYSMOD a ser restaurado possui inline JCLIN, o SMP/E precisa do SMPCDS.
Por quê?
Porque o SMPCDS contém:
Backup da estrutura do TZONE
Informações necessárias para restaurar corretamente macros, source e datasets
Sem isso, o RESTORE pode:
Falhar
Ou deixar o ambiente inconsistente
Exemplo básico:
Define quais SYSMODs você quer remover.
No RESTORE, o GROUP funciona ao contrário do APPLY.
APPLY: GROUP busca pré-requisitos ausentes
RESTORE: GROUP busca SYSMODs que DEPENDEM do selecionado
👉 Se um SYSMOD depende do que você quer remover, ele também precisa ser restaurado.
CHECK:
Não altera nada
Analisa dependências
Mostra mensagens do tipo GIM35922I
📌 Dica Bellacosa:
Raramente o primeiro RESTORE CHECK resolve tudo.
Rode, leia os relatórios, ajuste o SELECT, rode de novo.
Temos 7 PTFs aplicados:
Somente UP00001 foi ACCEPTED.
🎯 Objetivo: restaurar UP00003
Pergunta clássica de prova e produção:
Posso restaurar só o UP00003?
❌ Não.
Você também precisa restaurar:
UP00005
UP00007
Porque dependem diretamente dele.
1️⃣ Mensagens SMP/E (ex: GIM35922I)
2️⃣ SYSMOD Status Report
3️⃣ CAUSER SYSMOD SUMMARY REPORT ← o mais importante
Esse relatório explica:
Por que o RESTORE falhou
Quais SYSMODs estão bloqueando
O que falta no SELECT
Se NOREJECT = OFF:
Remove entrada do SYSMOD no Global Zone
Remove MCS do SMPPTS
Remove SMPTLIBs (se existirem)
⚠️ HOLD DATA NÃO É REMOVIDA
Se NOREJECT = ON:
Remove apenas APPID do Target Zone
RESTORE pode se tornar complexo quando:
Muitos PTFs aplicados
DLIB muito atrás do Target
Cadeias longas de dependência
👉 É comum rodar:
Até fechar todo o quebra-cabeça.
RESTORE é:
Uma ferramenta poderosa
Um salva-produção
Um teste de maturidade do system programmer
Quem domina RESTORE:
✔ Entende dependências
✔ Entende níveis de serviço
✔ Não entra em pânico quando APPLY quebra
APPLY instala. ACCEPT oficializa. RESTORE ensina humildade.
No próximo módulo, o foco sai do SMP/E operacional e entra no product build — onde o código nasce antes de virar SYSMOD.
 |
| Bellacosa Mainframe apresenta o comando Perform em COBOL |
🔥 PERFORM no COBOL: você manda ou ele manda em você?
(Um café no Bellacosa Mainframe, para padawans e cavaleiros Jedi do z/OS)
Você já deu o spoiler certo: PERFORM é o maestro do COBOL.
Quem domina PERFORM escreve código legível, previsível, auditável e aceito em produção.
Quem não domina… acaba criando um GO TO disfarçado com terno e gravata 😅
Vamos organizar, aprofundar e elevar o nível do que você trouxe — com exemplos reais, pegadinhas, DB2, CICS e dicas de campo.
 |
| COBOL e o Perform |
Nos anos 70, COBOL sofreu com o “spaghetti code” (muito GO TO).
O PERFORM surgiu como a resposta estruturada, permitindo:
Modularidade
Fluxo previsível
Testabilidade
Facilidade de manutenção (sim, o auditor agradece)
👉 Regra de ouro mainframe:
“Se dá pra fazer com PERFORM, NÃO use GO TO.”
 |
| Comando Perform e suas variações em COBOL |
Executa um parágrafo uma única vez.
Sempre crie o -EXIT
Facilita debug, tracing e manutenção futura
Loop com contador explícito.
❌ Alterar WS-CONT dentro do parágrafo executado
✔️ Deixe o controle só no PERFORM
Repete até a condição ser verdadeira
(atenção: condição é avaliada antes)
Batch
VSAM
Sequential files
DB2 cursors (já já)
Executa um bloco N vezes, sem contador explícito.
Simulações
Inicializações
Processos fixos
Quando você precisa do índice (use VARYING)
Executa uma sequência contínua de parágrafos
Nunca coloque código fora da sequência THRU
Senão…
🔥 comportamento imprevisível
🔥 bugs fantasma
🔥 chamado em produção às 3h da manhã
👉 Padrão de ouro DB2 COBOL
✔ Modular
✔ Legível
✔ Fácil de testar
| Erro | Impacto |
|---|---|
| PERFORM THRU mal delimitado | Execução inesperada |
| Alterar contador no parágrafo | Loop infinito |
| Falta de EXIT | Debug caótico |
| GO TO misturado com PERFORM | Código ilegível |
🥚 Em COBOL antigo, PERFORM THRU era o padrão absoluto
🥚 Auditores AMAM código com PERFORM bem estruturado
🥚 Muitos shops ainda proíbem GO TO por norma interna
🥚 PERFORM é um dos motivos do COBOL sobreviver tão bem até hoje
Se você entende PERFORM, você entende o fluxo do COBOL.
Se entende o fluxo, domina Batch, DB2 e CICS.
 |
| Bellacosa Mainframe e a lei sincronicidade |
SUBMIT no JCL sem te avisarVou falar em primeira pessoa, como bom mainframeiro raiz que já viu coisa demais acontecer “por acaso” para ainda chamar tudo de coincidência.
Carl Gustav Jung, psiquiatra suíço, parceiro intelectual (e depois desafeto) de Freud, criou o termo Sincronicidade para explicar algo simples e profundo:
Eventos que não têm relação de causa e efeito,
mas possuem significado para quem vivencia.
Não é misticismo barato. Jung era sistemático. Ele só percebeu que a psique humana e o mundo externo às vezes parecem rodar no mesmo clock.
Pense assim:
Não houve CALL
Não houve PERFORM
Não houve TRIGGER
Mas dois eventos acontecem juntos e fazem todo o sentido naquele contexto.
👉 Isso não é bug.
👉 É evento correlacionado por significado, não por lógica.
Eu já vivi várias:
Pensar numa pessoa e ela aparecer
Procurar uma resposta e tropeçar num livro, num artigo, numa conversa
Estar travado num problema técnico e a solução surgir fora do terminal
No mundo IBM Z:
você sai pra tomar café… e o problema se resolve na sua cabeça.
Clássico.
Jung discutiu sincronicidade com Wolfgang Pauli, físico quântico
Matrix usa isso o tempo todo (o déjà-vu do gato 🐈)
Evangelion e Steins;Gate vivem disso
No Japão, a ideia dialoga com:
En (縁) – laços invisíveis
Ma (間) – o espaço entre eventos
Ki (気) – fluxo
Sincronicidade:
Não responde quando você exige
Não aparece para quem tenta controlar tudo
Surge quando você para de forçar
É quase um RACF do universo:
acesso concedido só quando você está no grupo certo 😄
Não dá pra forçar.
Mas dá pra perceber:
Observe padrões
Escute mais
Desligue o excesso de ruído
Anote coincidências estranhas
Quanto mais atento, mais frequentes elas parecem.
Importante:
Sincronicidade não substitui lógica
Não invalida ciência
Não explica tudo
Ela complementa.
Nem tudo no mundo roda em batch previsível.
Ela nos lembra que:
Nem tudo é controle
Nem tudo é causa e efeito
Sentido também é uma forma de ordem
Na vida, no trabalho, na criação:
quando as coisas começam a encaixar sem esforço excessivo, talvez seja hora de parar de lutar contra o fluxo.
Sincronicidade é aquele momento em que você pensa:
“Isso foi coincidência demais…”
E sorri, porque sabe:
o sistema da vida rodou certo sem precisar de restart.
Às vezes, o universo não fala.
Ele alinha.
Se existe um refrigerante que pode ser chamado de “SPOOL da infância brasileira”, esse refrigerante é a Tubaína. Ela não é apenas uma bebida: é um dataset cultural distribuído em milhares de versões, cada uma com seu label caseiro, sua micro-história e seus segredos de sabor guardados como PDS protegido no RACF.
Mas afinal… de onde veio essa lenda?
A Tubaína surgiu no interior do estado de São Paulo, entre o fim dos anos 1930 e início dos anos 1940. Não existe um único inventor, nem uma fábrica original certificada como “a primeira”.
E é justamente isso que faz parte do charme.
Tubaína nasceu como:
bebida artesanal,
produzida em pequenas fábricas e engarrafadoras familiares,
que usavam xaropes de frutas, açúcar e gás carbônico para criar um refrigerante barato e acessível.
O nome “Tubaína” teria duas origens possíveis:
Registros linguísticos apontam que “tubaina” aparece como variação de palavras indígenas relacionadas a bebida local ou fruta macerada.
Outra versão, muito forte entre historiadores de indústria, diz que Tubaína era originalmente o nome de um xarope-base distribuído para fábricas pequenas, que passaram a engarrafar refrigerantes com essa marca — e com o tempo, “virou sinônimo de qualquer refrigerante barato do interior”.
Um clássico caso Aspirina / Gilete / Maizena / Xerox.
Entre as primeiras e mais conhecidas estão:
Tubaína Zarco – Piracicaba/SP
Tubaína Bacharel – São João da Boa Vista/SP
Turbaína Ferraspari – Jundiai/SP
Tubaína Joaninha – Taubaté/SP
Tubaína Arco Íris – Mococa/SP
Tubaína Vivi – diversas cidades do interior
Sanbra/J. Macedo, que vendia xaropes Tubaína para engarrafadores
Essas pequenas fábricas se espalharam como jobs submitting in batch, cada uma com sua receita própria — mais doce, mais artificial, mais frutada ou mais “doce de bar”.
O sabor da Tubaína era, e é, uma alquimia:
ramalhete de frutas artificiais,
base de guaraná ou tutti-frutti,
açúcar para adoçar a vida,
e cor âmbar ou avermelhada, levemente translúcida.
Era um sabor que gritava: “sou simples, sou barata, sou boa!”
Em muitos lugares, Tubaína era bebida em garrafa de 600 ml, com tampa de metal que você abria na quina da mesa, e com aquele som clássico que parecia um IEFC001I anunciando início do serviço.
Simples:
Era barata (metade do preço dos grandes refrigerantes).
Era local (tradição regional fortíssima).
Era familiar (produzida por fábricas do bairro).
Era democrática (vendida no bar, no campinho, no mercadinho).
Era saborosa de um jeito despretensioso.
E claro:
Toda cidade tinha “a melhor Tubaína do mundo”.
Cada uma com seu fã-clube.
Acredite:
Algumas versões de Tubaína tinham teor alcoólico leve, por causa da fermentação natural dos xaropes artesanais.
Era tão discreto que ninguém falava disso… mas todo mundo sabia.
Tipo um dataset uncataloged que só o operador raiz conhecia.
Hoje, a Tubaína:
segue viva em centenas de microfábricas pelo Brasil,
tem festivais próprios (como o Tubaína Fest, em São Paulo),
virou produto gourmet em algumas versões,
e ganhou um renascimento nostálgico nas redes sociais.
Marcas atuais de destaque:
Tubaína São João
Dore
Frevo
Itubaína Retrô (da Schin) – a versão industrial mais famosa
Tubaína Xereta
🔸 “Tubaína” é praticamente um open-source beverage — cada região fez sua fork.
🔸 Garrafas retornáveis de Tubaína foram ícones dos anos 50 a 90.
🔸 Em muitos lugares, “Tubaína” virou sinônimo de qualquer refri de garrafa marrom, mesmo que o rótulo dissesse outro nome.
🔸 Tubaína é considerada por alguns historiadores como o primeiro refrigerante realmente popular do Brasil, antes da Coca dominar tudo.
🔸 Existe um museu informal da Tubaína, com rótulos de mais de 700 marcas coletadas pelo interior paulista.
Tubaína é memória líquida.
É o refrigerante da infância, do boteco, do campinho, da padaria com balcão de mármore, do mercadinho com cheiro de madeira e sabão em pedra.
Ela não veio de corporações gigantes.
Ela nasceu como obra de milhares de pequenos criadores, todos querendo fazer uma bebida gostosa, barata e acessível — um verdadeiro cluster de boa vontade e criatividade.
A origem exata pode ser múltipla.
Mas a essência é uma só:
Tubaína é o sabor do Brasil raiz.
Há endereços que não são somente coordenadas — são portais. A casa da Estrada Mogi das Cruzes, número 115, pertencia a essa categoria rara: lugar que não se visita, mas se atravessa como quem entra em outra dimensão, uma dungeon cheia de níveis, salas secretas e tesouros guardados pela memória.
Ali moravam Pedro e Anna — avós de braços largos, olhos cheios de história, cozinhas quentes e quintais infinitos. No ar, cheiro de fruta madura, de bolo recém-assado e de terra molhada. No fundo, o chiqueiro com dois leitões crescendo ao ritmo do ano, engordados para o Natal e o Ano Novo — rituais da família Bellacosa que eram quase sagrados. As míticas festas de final de ano, onde cada uma delas guardavam momentos únicos e felizes com toda a família reunida.
A pedido do meu avô Pedro, os meninos do bairro, recolhiam e vinham com sacas com restos da feira de rua, vegetais que iriam para o lixo, mas recebendo moedas em troca, ajudavam a alimentar os leitões. Nada era desperdício: tudo virava vida, sustento, festa. Porque naquela casa sempre havia festa. Era aniversário meu, do tio Pedrinho, de algum primo, ou então a grande festa junina — bandeirinhas, fogueira, milho quente e a onomástica de São Pedro iluminando a noite.
Cada cômodo era um capítulo.
Cada parede, um segredo.
Cada tarde, uma aventura nova.
Havia o balanço, as pipas que rasgavam o céu, a laje onde se soltavam balões e se assistia à queima de fogos ou simplesmente ao pôr do sol que parecia nunca ter pressa. E havia histórias épicas, como a minha irmã Vivi presa no banheiro junto de Marcelo e Duzinho — até que meu pai, Wilson, com um único murro, abriu um buraco na porta. Para pânico geral dos primos e gargalhada da memória futura.
Essa casa não era apenas casa.
Era reino. Era mapa. Era infância.
Era o lugar onde o tempo não passava — ele acontecia.
Hoje ela vive no espaço onde as casas verdadeiramente importantes moram: não no concreto, mas dentro de quem as viveu.
E eu vivi — profundamente.
Lembro também em algum lugar dos anos 1970, quando enfim a SABESP trouxe água encanada para a vila Rio Branco, meu avô Pedro foi intimado a fechar o profundo posso, não sei a profundidade, mas para uma criaturinha pequena como eu, ver o meu pai no fundo, pequenino minusculo. Uma força tarefa com todos os homens adultos da família trabalhando duro na empreita. O poço parecia ir até o centro da terra, caminhões de entulho e muito trabalho até aquele gigante, que durante décadas trouxe água pura a família Bellacosa, ser silenciado, fechado e entupido.
.JPG)
Outra indiscrição, meu pai um atentado mor, piadista de piadas sujas, gozador e brincalhão; Cismava em provocar o povo, às vezes, até mostrando revistas pornográficas para os padres, dois irmãos gêmeos da paróquia da Ponte Rasa, para horror e raiva da minha avó Anna, que corria com a vassoura atrás do pouco pudico filho primogênito.
As festas outra doce lembrança, refrigerantes, barris de chops, batidas de amendoim, coco e maracujá. Vinho tinto que não podia faltar em uma casa napolitana.
Teve também alguns desastres, tipo a colisão dos fusquinhas vermelhos em dia de festa, claro que meu pai tinha que estar envolvido, porém, desta vez como vítima... Teve a panela de pressão que explodiu ao cozinhar feijão, destruindo a cozinha da vó Anna, primeiro tristeza e prejuízo financeiros, depois mais uma história para o clã Pedro Bellacosa eternizar em histórias de família.
E agora, está registrado e compartilhado contigo, caro leitor, destas linhas deste escriba do século XXI, que rememora com carinho antigos eventos.
 |
| Bellacosa Mainframe apresenta SMP/E Apply Processing |
Se o RECEIVE é quando o código chega na casa e o ACCEPT é quando ele vira herança oficial, o APPLY é o momento crítico: quando o código realmente entra em produção técnica, nos target libraries.
É aqui que o SMP/E deixa de ser teoria, CSI e HOLDDATA… e começa a mexer em load modules, macros, fontes, JARs, HFS e dados reais do sistema.
No estilo Bellacosa Mainframe: APPLY não é comando — é cirurgia.
O comando APPLY:
Instala elementos fornecidos por SYSMODs nas Target Libraries
Atualiza o Target Zone (TZONE) com o novo estado do sistema
Garante que nenhum serviço seja regredido
Controla dependências, pré-requisitos, co-requisitos e IF-REQs
Invoca utilitários reais do sistema (Binder, IEBCOPY, IEBUPDTE, BPXCOPY, etc.)
📌 Importante:
APPLY NUNCA deve ser feito diretamente em produção. Sempre em clone, test system, shadow libraries.
Target Libraries: onde vivem os executáveis, macros, fontes e dados usados pelo sistema
Target Zone (TZONE): o mapa vivo do que está instalado e em qual nível
Distribution Libraries (DLIB): código base, mantido pelo ACCEPT
Distribution Zone (DZONE): mapa do código base
👉 APPLY mexe apenas em Target Libraries e TZONE.
Antes do APPLY:
SET BDY(TARGET1)
APPLY ...
Cada Target Zone mapeia um conjunto específico de bibliotecas.
💡 Estratégia clássica:
APPLY no sistema de teste
Validação
Promoção do clone para produção
A seleção é controlada pelos operandos do APPLY:
SELECT
EXCLUDE
FORFMID
FUNCTION
PTF
APAR
USERMOD
SOURCEID
EXSRCID
Se nenhum tipo for especificado:
👉 default = apenas PTFs
Inclui automaticamente:
Pré-requisitos (PRE)
Co-requisitos (REQ)
IF-requisitos
Exemplo:
UL9 → requer UL7 e UL8
UL7 → requer UL5
UL8 → requer UL6
👉 APPLY com GROUP seleciona UL9, UL7, UL8, UL5 e UL6
Vai além:
Resolve HOLDs automaticamente
Procura SYSMODs que supersedem erros ou requisitos faltantes
Pesquisa no GZONE e PTS
⚠️ Pode ser restringido:
NOAPARS
NOUSERMODS
Quando uma condição geraria erro fatal, o BYPASS manda o SMP/E ignorar.
Exemplos:
BYPASS(ID)
BYPASS(HOLD)
BYPASS(XZIFREQ)
BYPASS(HOLDFIXCAT)
⚠️ Use com extremo cuidado
Todo desastre em SMP/E começa com alguém que confiou demais no BYPASS.
APPLY CHECK ...
O CHECK:
Não atualiza bibliotecas
Não altera CSI
Simula seleção, dependências e validações
Detecta regressões
🚨 CHECK não valida espaço em disco
📌 Dica Bellacosa:
CHECK sempre com BYPASS(HOLDSYSTEM,HOLDID)
Usado quando:
Biblioteca foi restaurada de backup antigo
Fix aplicado se perdeu
APPLY SELECT(AZ81463) REDO
👉 Reinstala mesmo que já conste como aplicado
COMPACTA bibliotecas alvo
Pode ser:
Por DDNAME
ALL
Default = YES
Reage a erros de espaço
Usa lista definida no GZONE (RETRYDDN)
⚠️ Pegadinha clássica:
CHECK + COMPRESS ALL não faz sentido
CHECK não atualiza nada → COMPRESS não ocorre.
Depois da seleção:
Verifica se o FMID pertence ao Target Zone
Valida PRE, REQ e IF-REQ
Verifica HOLDs (SYSTEM, ERROR, USER, FIXCAT)
Executa cross-zone IFREQ (XZIFREQ)
Determina ordem de processamento
Ordem padrão:
Functions
PTFs
APARs
USERMODs
Funções podem ter:
++VER DELETE
Efeito:
Remove elementos da função antiga
Remove entradas no TZONE
Remove serviços dependentes
👉 DELETE explícito e implícito
JCLIN:
É processado durante o APPLY
Cria estrutura no TZONE
Define MOD, LMOD, SYSLIB, LKEDCNTL
📦 Resultado:
SMP/E sabe como montar o load module
Indica linkagens implícitas
Binder é chamado duas vezes
Usa SMPMTS para restore futuro
Cada elemento é rastreado por:
FMID – quem introduziu
RMID – quem substituiu
UMID – quem atualizou
SMP/E usa:
++VER PRE
++VER SUP
Para garantir:
Nenhum APPLY reduz o nível atual do elemento
Dependendo do tipo:
MOD → Binder (link-edit)
MAC / SRC → IEBCOPY / IEBUPDTE
JAR → COPY ou GIMDRS
DATA / HFS → COPY / BPXCOPY
Permitem empacotar elementos não FB80
Reconversão automática no APPLY
Após o APPLY:
Atualiza entradas de elementos no TZONE
Atualiza FMID, RMID, UMID
Cria SYSMOD entry no TZONE
Atualiza APPID no GZONE
📌 Regra de ouro:
Status de APPLY se verifica no TZONE, não no GZONE
Principais relatórios:
SYSMOD Status Report
Element Summary Report
Causer SYSMOD Summary (Root Cause)
Regression Report
Unresolved HOLD Report
HOLDDATA Summary
DDs importantes:
SMPRPT
SMPHRPT (HOLDDATA separado)
FIXCAT permite:
Expressar interesse por categorias
Bloquear APPLY se serviço crítico faltar
Automatizar PSP buckets
Exemplo estratégico:
FIXCAT(IBM.ProductInstall-RequiredService)
👉 Garante instalação de todo serviço recomendado
APPLY é onde o SMP/E deixa de ser administrativo e vira operacional.
Quem domina APPLY:
Não quebra produção
Não regride serviço
Não depende de sorte
No mainframe, conhecimento não é poder — é sobrevivência.
No próximo capítulo: ACCEPT – quando o código vira base do sistema.