☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 9 de junho de 2019

IBM Mainframe Discovery : Capítulo XVIII — O Guia Nunca Terminou

Bellacosa Mainframe apresenta o ibm mainframe xviii


☕ Um Café no Bellacosa Mainframe

Capítulo XVIII — O Guia Nunca Terminou

As 42 Grandes Lições da Engenharia que o IBM Z Ensinou à Galáxia 


DÉCIMA QUINTA REGRA DOS GRANDES VIAJANTES

Quando terminar uma expedição...

...não volte apenas com fotografias.

Volte com sabedoria.

Porque fotografias envelhecem.

Sabedoria continua viajando.


Você Percebeu?

Talvez não.

Durante dezessete capítulos você acreditou estar lendo um livro sobre computadores.

Na verdade...

este livro nunca foi sobre computadores.

Foi sobre...

boas ideias.

E boas ideias possuem um curioso hábito.

Elas sobrevivem às tecnologias que as criaram.


A Galáxia Está Cheia de Computadores

Imagine uma viagem pela Via Láctea.

Você encontra milhares de mundos.

Cada planeta utiliza um tipo diferente de computador.

Alguns são enormes.

Outros cabem no bolso.

Alguns utilizam processadores quânticos.

Outros processadores ópticos.

Outros tecnologias que sequer conseguimos imaginar.

Mas todos enfrentam exatamente os mesmos problemas.

Como proteger dados?

Como evitar falhas?

Como compartilhar recursos?

Como crescer?

Como integrar sistemas?

Como automatizar?

Como sobreviver ao tempo?

É curioso...

As perguntas continuam exatamente as mesmas.


O Segredo Nunca Foi o Hardware

Durante décadas as pessoas discutiram:

Quem possui a CPU mais rápida?

Quem possui mais memória?

Quem possui mais discos?

Enquanto isso...

os grandes engenheiros faziam outra pergunta.

"A arquitetura está correta?"

Porque uma boa arquitetura continua funcionando...

mesmo quando o hardware muda completamente.


A Nave Nunca Foi Importante

Imagine um explorador.

Ele atravessa centenas de planetas.

No final da viagem alguém pergunta:

"Qual nave você utilizou?"

Ele responde:

"Isso foi a parte menos importante."

O importante foi:

o mapa.

o conhecimento.

as descobertas.

o caminho.

O IBM Z nunca foi apenas uma máquina.

Sempre foi uma coleção de soluções para problemas difíceis.


A Grande Ironia da História

Existe algo extremamente curioso.

Vamos fazer uma viagem no tempo.

Década de 1970.

Alguém diz:

"Virtualização."

As pessoas riem.

Década de 1980.

"Alta disponibilidade."

Acham exagero.

Década de 1990.

"Workload baseado em objetivos."

Parece complexo demais.

Década de 2000.

"Segurança por hardware."

Parece caro.

Década de 2010.

"Cloud."

Todos falam.

Década de 2020.

"Containers."

"Kubernetes."

"Resiliência."

"Observabilidade."

"Zero Trust."

"IA."

Curiosamente...

muitos desses princípios já existiam, em diferentes formas, no universo IBM Z há décadas.

A História possui um excelente senso de humor.


O Que Aprendemos?

Vamos organizar nosso diário de bordo.


Lição 1

Nunca confunda:

velho

com

obsoleto.

Uma ponte construída há cem anos pode continuar excelente.

Um software lançado ontem pode nascer ultrapassado.

Idade nunca foi sinônimo de qualidade.


Lição 2

Disponibilidade não acontece por acidente.

Ela é planejada.

Cada cabo.

Cada disco.

Cada CPU.

Cada software.

Cada procedimento.

Tudo faz parte do projeto.


Lição 3

Segurança não é um produto.

É uma cultura.

Firewalls ajudam.

Criptografia ajuda.

RACF ajuda.

Mas segurança começa nas decisões.


Lição 4

Automatize tudo o que for repetitivo.

Porque seres humanos são extraordinários.

Mas repetir exatamente o mesmo procedimento milhares de vezes...

nunca foi nosso maior talento.


Lição 5

Documentação salva civilizações.

Imagine uma nave sem manual.

Boa sorte.


Lição 6

Logs contam histórias.

Todo erro deixa rastros.

Quem aprende a ler logs...

aprende a conversar com os computadores.


Lição 7

Performance nunca depende de apenas um componente.

CPU.

Disco.

Rede.

SQL.

Buffer.

Índices.

Cache.

Tudo coopera.


Lição 8

Escalabilidade começa na arquitetura.

Não na compra de máquinas maiores.


Lição 9

Toda integração é, na verdade, uma tradução.

Não existem sistemas incompatíveis.

Existem tradutores insuficientes.


Lição 10

Nenhuma aplicação é uma ilha.

CICS conversa com Db2.

Db2 conversa com MQ.

MQ conversa com APIs.

APIs conversam com Cloud.

Cloud conversa com IA.

Tudo está conectado.


O Conselho dos Grandes Engenheiros

Imagine uma enorme mesa redonda.

Sentam-se nela:

Gene Amdahl.

Fred Brooks.

Gerrit Blaauw.

John Backus.

Grace Hopper.

Wilhelm G. Spruth.

Milhares de engenheiros anônimos.

Nenhum deles trabalhou sozinho.

Toda tecnologia importante nasce da colaboração.

Essa talvez seja a maior lição da engenharia.


O Universo Também Possui Bugs

Existe uma crença curiosa.

Algumas pessoas imaginam que computadores perfeitos existem.

Infelizmente...

não.

Sempre existirão:

ABENDs.

Deadlocks.

Race Conditions.

Timeouts.

Falhas humanas.

O objetivo nunca foi eliminar completamente os problemas.

Foi construir sistemas capazes de sobreviver a eles.


O Padawan Mudou

Volte ao primeiro capítulo.

Lembra daquele iniciante?

Ele acreditava que Mainframe era:

verde.

antigo.

difícil.

isolado.

Hoje ele conhece:

APIs.

Git.

Python.

IA.

OpenShift.

MQ.

DevOps.

Virtualização.

Sysplex.

USS.

Db2.

CICS.

Talvez o computador tenha mudado pouco.

Quem realmente mudou foi o explorador.


O Futuro Também Será Legado

Esta talvez seja a ideia mais bonita de todo o livro.

Imagine um jovem desenvolvedor criando um microsserviço hoje.

Daqui a quarenta anos...

alguém dirá:

"Esse sistema legado continua funcionando."

Percebe a ironia?

Todo software moderno está apenas esperando sua vez de virar legado.


A Toalha Nunca Foi o Objeto Mais Importante

Durante toda esta jornada carregamos uma toalha imaginária.

Ela representava preparação.

Mas existe outra ferramenta ainda mais importante.

A curiosidade.

Sem ela...

nenhum engenheiro cresce.


As 42 Grandes Lições da Federação

Existe uma curiosa tradição entre viajantes espaciais.

Sempre perguntam:

"Qual é a resposta definitiva?"

Talvez não exista apenas uma.

Talvez existam quarenta e duas pequenas respostas.

Entre elas:

  1. Leia antes de alterar.

  2. Teste antes de implantar.

  3. Automatize antes de repetir.

  4. Documente antes de esquecer.

  5. Observe antes de concluir.

  6. Pergunte antes de assumir.

  7. Simplifique antes de complicar.

  8. Compartilhe antes de esconder.

  9. Planeje antes de crescer.

  10. Aprenda antes de ensinar.

...

E talvez a quadragésima segunda seja simplesmente:

Nunca pare de aprender.


O Último Café

Imagine o salão principal da nave.

A missão terminou.

Os computadores continuam funcionando.

Os operadores observam os painéis.

O Batch começou.

As APIs continuam respondendo.

O MQ transporta mensagens.

O Db2 registra transações.

O WLM redistribui recursos.

O JES organiza milhares de Jobs.

O CICS atende milhões de usuários.

Tudo continua acontecendo.

O universo nunca parou porque fechamos este livro.


O Que Diria o Velho Engenheiro?

Talvez Wilhelm G. Spruth apenas sorrisse.

Durante décadas ele tentou mostrar que o IBM Z era muito mais do que um computador.

Era uma coleção de princípios de engenharia.

Hoje...

esses princípios continuam vivos.

Mais atuais do que nunca.


O Legado Invisível

Existe algo extraordinário na engenharia.

As melhores soluções tornam-se invisíveis.

Ninguém elogia um elevador porque ele não caiu hoje.

Ninguém comemora porque o banco funcionou.

Ninguém publica manchetes dizendo:

"Hoje o pagamento de milhões de aposentados ocorreu exatamente como deveria."

E isso é maravilhoso.

Porque significa que a engenharia cumpriu sua missão.

Quando tudo funciona...

ela desaparece.


O Convite Final

Agora chegou sua vez.

Feche este livro.

Abra um terminal.

Digite seu primeiro comando.

Leia um JCL.

Explore um Dump.

Analise um EXPLAIN.

Monte um Pipeline.

Crie uma API.

Automatize um processo.

Ensine alguém.

Porque conhecimento guardado é apenas armazenamento.

Conhecimento compartilhado transforma civilizações.


Curiosidades do Diário de Bordo

🚀 O IBM Z continua sustentando algumas das operações mais críticas do planeta justamente porque evoluiu sem abandonar seus princípios fundamentais de arquitetura.

📖 Muitas tecnologias consideradas "modernas" representam novas implementações de conceitos clássicos como isolamento, automação, resiliência, integração e gerenciamento inteligente de recursos.

🌍 O maior patrimônio da plataforma IBM Z não é apenas seu hardware ou software, mas o conhecimento acumulado por gerações de engenheiros que documentaram, aperfeiçoaram e transmitiram essas ideias.

☕ A melhor tradição da comunidade Mainframe continua sendo compartilhar conhecimento — seja em cursos, blogs, conferências, comunidades técnicas ou em uma simples conversa durante um café.


Diário Final de Bordo do Oficial da Frota

Se você percorreu toda esta jornada...

parabéns.

Você já não é apenas um Programador COBOL.

Nem apenas um Administrador z/OS.

Nem apenas um Arquiteto.

Você se tornou um Explorador da Engenharia.

Aprendeu que tecnologias passam.

Produtos mudam.

Linguagens evoluem.

Empresas surgem e desaparecem.

Mas boas ideias...

essas atravessam gerações.


A Última Entrada do Holocron Bellacosa

Antes de guardar este livro na biblioteca da nave, registre uma última coordenada:

Os computadores mais extraordinários da galáxia nunca foram aqueles que possuíam o processador mais rápido. Foram aqueles projetados por engenheiros que compreendiam profundamente as pessoas que dependeriam deles.

Porque, no fim da jornada...

o verdadeiro protagonista nunca foi o IBM Z.

Nunca foi o COBOL.

Nunca foi o Db2.

Nem o CICS.

Sempre foi o ser humano que decidiu construir máquinas capazes de tornar a vida de milhões de outros seres humanos um pouco melhor.

E talvez...

essa tenha sido a maior descoberta de toda esta viagem.

Fim?

Um bom explorador sabe que essa palavra significa apenas:

"Até a próxima missão." ☕🚀

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo

sábado, 8 de junho de 2019

O Mistério da Porta que Nunca se Abriu Novamente : Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

 

Bellacosa Mainframe e o misterio da porta que nunsa se abriu novamente

☕ Um Café no Bellacosa Mainframe

O Mistério da Porta que Nunca se Abriu Novamente

Quando um Jovem Programador COBOL Descobriu que uma Escolha entre LINK e XCTL Poderia Decidir o Destino de Milhões de Transações Bancárias

"Existem portas que foram feitas para serem atravessadas duas vezes. Outras... apenas uma."

Era assim que começava um antigo manual não oficial que circulava entre programadores de CICS na década de 1980. Diziam que o autor nunca assinou seu nome. Apenas deixava um pequeno desenho de uma xícara de café ao lado das páginas.

Os veteranos chamavam aquele manuscrito de O Livro das Portas.

Hoje vamos descobrir por quê.

Pegue seu café.

Apague as luzes do escritório.

O letreiro verde do terminal 3270 acaba de acender.

O caso vai começar.


Capítulo 1 — O prédio onde programas conversam

Quem vem do COBOL Batch imagina que um programa vive sozinho.

Ele começa.

Processa.

Termina.

No CICS isso não existe.

Um sistema bancário raramente possui um programa gigante.

Na verdade ele parece uma pequena cidade.

Existe o programa do Login.

O Menu Principal.

Consulta de Saldo.

PIX.

Transferência.

Extrato.

Cartão.

Empréstimos.

Investimentos.

Cada um conhece apenas seu trabalho.

É exatamente como uma delegacia de polícia.

O investigador não faz exame pericial.

O perito não conduz interrogatórios.

O escrivão não prende criminosos.

Cada especialista executa apenas sua função.

No CICS acontece exatamente isso.

Cada programa é especialista em um assunto.

A pergunta é:

Como eles conversam?

A resposta possui apenas quatro letras.

LINK.

Ou...

XCTL.

E é aqui que começa nosso mistério.


Capítulo 2 — O telefone vermelho da IBM

Imagine um antigo escritório bancário dos anos 1950.

Sobre uma mesa existe um telefone vermelho.

Quando o gerente precisa de alguma informação ele liga para outro departamento.

— Preciso do saldo da conta.

O funcionário responde.

— Um instante.

Alguns segundos depois.

— Aqui está.

O gerente continua seu trabalho.

Isso é LINK.

O programa chama outro programa.

Espera.

Recebe a resposta.

Continua exatamente de onde havia parado.

Observe o fluxo.

Programa LOGIN

↓

LINK

↓

Programa CONSULTA

↓

RETURN

↓

LOGIN continua

Nada de mágico aconteceu.

Apenas uma conversa organizada.


A verdadeira mágica

O que ninguém vê é que o CICS precisa guardar tudo.

Enquanto o programa chamado trabalha, o programa chamador fica "congelado".

O CICS preserva:

✔ Registradores

✔ Contexto

✔ Área de memória

✔ Ponto de retorno

✔ COMMAREA

É quase como colocar um marcador dentro de um livro.

Você fecha.

Empresta para alguém.

Quando devolvem...

Você abre exatamente na mesma página.

Essa é a essência do LINK.


Capítulo 3 — A porta sem maçaneta

Agora imagine outra situação.

Você entrega a chave da empresa ao próximo gerente.

Vai embora.

Nunca mais volta.

Esse é o XCTL.

Programa LOGIN

↓

XCTL

↓

MENU

↓

Fim

O LOGIN morreu.

Sua missão terminou.

Ele não existe mais dentro daquela execução.

É uma transferência definitiva.

Os antigos programadores diziam:

"LINK conversa.

XCTL abdica."

Essa frase aparecia escrita em algumas apostilas da IBM nos anos 80.


A analogia da corrida

Imagine uma prova de revezamento.

No LINK...

Você entrega o bastão.

Espera.

Recebe de volta.

Continua correndo.

No XCTL...

Você entrega.

Sai da pista.

Vai tomar café.

Nunca mais participa daquela corrida.


O erro que denuncia um iniciante

Todo entrevistador gosta desta pergunta.

Veja:

EXEC CICS XCTL
     PROGRAM('MENU')
END-EXEC.

DISPLAY "CHEGUEI AQUI".

Pergunta:

Esse DISPLAY será executado?

Resposta:

Jamais.

Nunca.

Nem hoje.

Nem amanhã.

Nem daqui vinte anos.

Depois do XCTL o programa desapareceu.

Essa pequena pegadinha já eliminou centenas de candidatos em entrevistas.


Capítulo 4 — O elevador do edifício CICS

Imagine um prédio com cinquenta andares.

Cada andar possui um programa.

LINK funciona como um elevador.

Você sobe.

Resolve um assunto.

Desce.

Continua trabalhando.

XCTL funciona como mudança definitiva de escritório.

Você pega suas caixas.

Entrega sua sala.

Muda para outro andar.

Nunca mais volta.

Essa imagem ajuda muitos iniciantes.


O segredo escondido dentro do CICS

Muitos acreditam que LINK simplesmente chama outro programa.

Não.

Existe muito trabalho invisível.

Quando executamos:

EXEC CICS LINK

o CICS precisa:

Localizar o programa.

Carregar caso não esteja residente.

Criar ambiente.

Salvar contexto.

Preparar COMMAREA.

Transferir controle.

Esperar RETURN.

Restaurar contexto.

Continuar execução.

Existe um pequeno custo.

Pequeno.

Mas existe.


Já o XCTL...

Observe.

LOGIN

↓

MENU

Pronto.

Não existe necessidade de preservar retorno.

Não existe restauração.

O fluxo ficou linear.

Por isso muitos livros dizem que XCTL possui menor overhead.

Mas cuidado.

Não escolha XCTL apenas porque "é mais rápido".

Escolha porque faz sentido arquiteturalmente.

Essa diferença é importante.


Capítulo 5 — O caso do caixa eletrônico

Vamos imaginar um ATM.

Cliente digita cartão.

Senha.

Programa LOGIN.

Após validar usuário.

O sistema faz

XCTL MENU

Por quê?

Porque ninguém deseja voltar para a tela de login.

O LOGIN cumpriu sua missão.

Agora imagine outra opção.

O cliente escolhe:

Consultar saldo.

O MENU faz:

LINK SALDO

Programa SALDO consulta DB2.

Retorna.

O MENU continua vivo.

Cliente escolhe:

Extrato.

Outro LINK.

Cliente escolhe:

PIX.

Mais um LINK.

Perceba.

O MENU é o maestro.

As funções são músicos.

Cada músico toca.

Depois devolve o palco.


Curiosidade histórica

Nos primeiros grandes bancos brasileiros era comum encontrar verdadeiras árvores de LINK.

Algo semelhante a:

MENU

↓

LINK

CLIENTE

↓

LINK

ENDERECO

↓

LINK

CEP

↓

RETURN

↓

RETURN

↓

RETURN

Era perfeitamente normal encontrar cinco ou seis níveis de chamadas.

Hoje isso ainda existe, mas arquiteturas modernas procuram evitar profundidades excessivas para facilitar manutenção e depuração.


Capítulo 6 — A COMMAREA: o envelope secreto

Imagine um envelope lacrado.

Dentro existem informações importantes.

Cliente.

Conta.

Saldo.

Tipo de operação.

Senha criptografada.

Tudo isso viaja pela COMMAREA.

Ela é o "correio interno" entre programas CICS.

Exemplo:

Programa A

↓

COMMAREA

↓

Programa B

Nada vai para disco.

Nada vai para banco.

Tudo permanece na memória durante a transação.

É extremamente rápido.


Easter Egg Bellacosa ☕

Os veteranos costumavam brincar:

"Se a COMMAREA fosse um carteiro, ela seria o único funcionário dos Correios que nunca perde uma encomenda... desde que você informe o LENGTH corretamente."

E aí está uma das maiores armadilhas dos iniciantes.


O LENGTH que derruba sistemas

Veja:

EXEC CICS LINK
    PROGRAM('CLIENTE')
    COMMAREA(WS-COMMAREA)
    LENGTH(LENGTH OF WS-COMMAREA)
END-EXEC.

Por que informar LENGTH?

Porque o CICS precisa saber exatamente quantos bytes transportar.

Se enviar menos...

Dados truncados.

Se enviar mais...

Lixo de memória.

Em alguns casos...

ABEND.

Simples assim.


Capítulo 7 — LINK parece CALL?

Essa dúvida aparece todos os meses.

Resposta curta:

Não.

CALL pertence ao COBOL.

LINK pertence ao CICS.

CALL apenas transfere execução.

LINK conversa com toda a infraestrutura CICS.

Ele conhece:

Recuperação.

Transação.

Segurança.

Recursos.

Comunicação.

Monitoramento.

É muito mais sofisticado.


Comparando os três irmãos

ComandoRetornaAmbiente
CALLSimCOBOL
LINKSimCICS
XCTLNãoCICS

Capítulo 8 — A arquitetura elegante

Um projeto bem desenhado normalmente parece isto:

LOGIN

↓

XCTL

↓

MENU

↓

LINK

SALDO

↓

RETURN

↓

MENU

↓

LINK

PIX

↓

RETURN

↓

MENU

↓

LINK

EXTRATO

↓

RETURN

Observe como tudo faz sentido.

LOGIN nunca retorna.

MENU permanece vivo.

As funcionalidades entram.

Executam.

Saem.

Essa organização facilita testes, manutenção e reutilização.


Dicas de ouro para iniciantes

✔ Regra número um

Se precisa voltar...

Use LINK.


✔ Regra número dois

Se acabou seu trabalho...

Use XCTL.


✔ Regra número três

Nunca coloque código após XCTL esperando execução.


✔ Regra número quatro

Sempre valide o tamanho da COMMAREA.


✔ Regra número cinco

Evite criar "espaguete de LINK", onde programas chamam programas que chamam outros programas sem um desenho arquitetural claro. Quanto mais profunda a cadeia, mais difícil será depurar um problema às três da manhã.


Curiosidade que pouca gente conhece

Em algumas instalações antigas da IBM existia uma recomendação informal:

"Se um programa não precisa voltar, não o obrigue a voltar."

Essa filosofia influenciou muitos padrões de desenvolvimento CICS e explica por que tantos fluxos de navegação utilizam XCTL entre telas principais e LINK apenas para serviços reutilizáveis.


O Mistério do Detetive Bellacosa

Imagine um investigador chamado Arthur Bellacosa.

Ele recebe um caso.

Vai até o Arquivo Central.

Precisa consultar documentos.

Ele diz ao arquivista:

— Procure a ficha do cliente 458923.

O arquivista vai até o depósito.

Volta.

Entrega os documentos.

Arthur continua investigando.

Isso foi um LINK.

Agora imagine outro cenário.

Arthur resolve entregar todo o caso ao Departamento de Crimes Financeiros.

Entrega as pastas.

Entrega as chaves.

Entrega seu distintivo temporário.

Vai embora.

Nunca mais participa da investigação.

Isso foi um XCTL.

O caso continua.

Mas sem ele.


Perguntas clássicas de entrevista

Qual retorna ao programa chamador?

LINK.


Qual termina definitivamente o programa atual?

XCTL.


Qual é mais indicado para módulos reutilizáveis?

LINK.


Qual costuma ser usado após Login para Menu Principal?

XCTL.


Posso executar código após um XCTL?

Não.


LINK é igual a CALL?

Não. O conceito de retorno é semelhante, mas LINK opera dentro do ambiente gerenciado pelo CICS, com controle de transação, contexto e recursos.


O Cofre dos Programadores (Easter Egg)

Há uma velha lenda entre programadores de mainframe que diz existir uma região CICS esquecida em algum laboratório da IBM, apelidada de REGION-X.

Nela existiria um programa chamado FOREVER, que executou um XCTL em 1987 e nunca mais retornou.

Toda vez que um jovem programador pergunta:

— "Será que esse programa volta?"

Um veterano apenas sorri e responde:

— "Pergunte ao FOREVER..."

Claro, é apenas uma brincadeira de corredor. Mas ela resume perfeitamente o conceito: algumas transferências foram feitas para nunca olhar para trás.


Conclusão — A Porta Certa no Momento Certo

LINK e XCTL possuem a mesma missão: transferir o controle entre programas. No entanto, representam filosofias completamente diferentes de construção de aplicações.

LINK é colaboração. Um programa pede ajuda, recebe o resultado e continua sua jornada. Ele favorece reutilização, modularidade e organização.

XCTL é sucessão. O programa conclui sua missão, entrega o bastão e permite que outro assuma o restante da transação. O fluxo fica mais limpo e evita preservar um contexto que nunca mais será utilizado.

Em sistemas bancários, seguradoras, companhias aéreas e grandes ambientes corporativos, essa decisão acontece milhares — às vezes milhões — de vezes por dia. Um simples comando define se o programa permanece como protagonista da história ou se entrega definitivamente o palco ao próximo ator.

Da próxima vez que você vir um EXEC CICS LINK ou um EXEC CICS XCTL, lembre-se do velho edifício iluminado por terminais verdes. Algumas portas foram feitas para serem abertas, entrar, resolver um assunto e voltar. Outras se fecham atrás de você para sempre.

E, no silencioso universo do CICS, escolher a porta correta é uma das marcas que separam um programador iniciante de um verdadeiro arquiteto de aplicações mainframe.

sexta-feira, 7 de junho de 2019

🎩 CARLITOS EM TEMPOS MODERNOS — QUANDO O COBOL ENTROU NA ESTEIRA DO DEVOPS

 

Bellacosa Mainframe introducao ao DevOps

☕ Um Café no Bellacosa Mainframe

🎩 CARLITOS EM TEMPOS MODERNOS — QUANDO O COBOL ENTROU NA ESTEIRA DO DEVOPS

COBOL, Git, Jenkins, DBB, zAppBuild, testes, CI/CD, DevSecOps, observabilidade, rollback, IA e o dia em que Carlitos descobriu que apertar parafusos mais rápido não significa necessariamente produzir software melhor.



🎬 PRÓLOGO — CARLITOS CONSEGUIU SEU PRIMEIRO EMPREGO NO MAINFRAME

Imagine nosso jovem programador COBOL entrando pela primeira vez em um grande Data Center.

Ele olha para aquelas máquinas, terminais, aplicações, filas, bancos de dados, milhares de jobs e milhões de transações e pensa:

— Finalmente! Aprendi COBOL. Estou preparado!

Do outro lado da sala, sentado diante de um terminal 3270, está Carlitos.

Chapéu-coco.

Bigodinho.

Bengala encostada na mesa.

Ele olha silenciosamente para o jovem programador e aponta para uma enorme esteira imaginária.

Sobre ela passam:

REQUISITO
   ↓
COBOL
   ↓
COPYBOOK
   ↓
JCL
   ↓
BUILD
   ↓
TESTE
   ↓
DEPLOY
   ↓
PRODUÇÃO

O jovem pergunta:

— Isso tudo é programação?

Carlitos balança negativamente a cabeça.

Aponta novamente para a esteira.

Agora aparecem mais peças:

Git
Pull Request
Code Review
DBB
zAppBuild
ZUnit
Quality Gate
Security Scan
SIT
UAT
Deploy
Rollback
Logs
Metrics
Traces

O jovem arregala os olhos.

Bem-vindo aos Tempos Modernos do Mainframe.

Porque conhecer COBOL continua sendo extremamente importante.

Mas COBOL é apenas uma das engrenagens.

O profissional mainframe moderno precisa começar a compreender a fábrica inteira.



⚙️ CAPÍTULO 1 — A FÁBRICA DE SOFTWARE

Em Tempos Modernos, Carlitos trabalha em uma linha de produção.

Sua tarefa parece simples:

apertar parafusos.

Dois parafusos chegam.

Carlitos aperta.

Outros dois.

Aperta novamente.

Mais dois.

Mais dois.

Mais dois.

Até que o homem começa a funcionar como se fosse parte da máquina.

Essa é uma excelente metáfora para um problema que também encontramos no desenvolvimento tradicional.

Durante muito tempo ensinamos programação como uma sequência relativamente isolada:

Receba especificação
        ↓
Altere programa
        ↓
Compile
        ↓
Teste
        ↓
Entregue

Parece perfeitamente razoável.

Mas surge uma pergunta.

Entregue para quem?

Quem controla a versão?

Quem sabe exatamente o que mudou?

Quem verifica as dependências?

Quem recompila?

Quem executa os testes?

Quem gera as evidências?

Quem promove para outro ambiente?

Quem autoriza produção?

Quem observa o sistema depois do deploy?

Quem volta a versão caso algo dê errado?

É nesse momento que entramos no universo do DevOps Mainframe.

DevOps não significa simplesmente instalar Jenkins.

Também não significa substituir ISPF por uma IDE moderna.

Muito menos significa pegar tudo que funciona no mainframe e colocar dentro de containers.

DevOps é fundamentalmente uma abordagem para melhorar o fluxo de entrega de software, aproximando desenvolvimento, testes, segurança e operações através de processos repetíveis, colaboração e automação.

Nossa fábrica começa a ficar interessante.



🏭 CAPÍTULO 2 — O COBOL NÃO SAI SOZINHO DA FÁBRICA

Considere um programa chamado:

PGMPAG01

Ele processa pagamentos.

O programador recebe:

REQ-38271 — Adicionar código identificador da origem da transação.

Parece fácil.

Ele abre o programa:

01 WS-TRANSACAO.
   05 WS-VALOR          PIC 9(09)V99.
   05 WS-CONTA          PIC X(12).
   05 WS-ORIGEM         PIC X(03).

Pronto?

Não.

Talvez WS-ORIGEM tenha vindo de um copybook.

Talvez o programa grave Db2.

Talvez outro programa utilize a mesma estrutura.

Talvez uma transação CICS chame esse programa.

Talvez um batch noturno leia os registros posteriormente.

Talvez exista uma API expondo aquela informação.

Talvez MQ transporte a mensagem para outro sistema.

A pequena alteração tornou-se:

                 COPYBOOK
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       COBOL-A    COBOL-B    COBOL-C
          │         │
          ▼         ▼
         CICS      BATCH
          │         │
          └────┬────┘
               ▼
              Db2
               │
               ▼
              MQ
               │
               ▼
             API

Aqui aparece uma das primeiras lições importantes do DevOps:

O tamanho da alteração não determina necessariamente o tamanho do impacto.

Uma linha pode afetar dezenas de componentes.



🌳 CAPÍTULO 3 — CARLITOS CONHECE O GIT

Carlitos encontra outra máquina na fábrica.

Nela existe uma placa:

GIT

O jovem programador pergunta:

— É onde guardamos os fontes?

Sim.

Mas essa resposta é incompleta.

Ensinar Git apenas como repositório é como ensinar CICS dizendo:

“É aquele negócio que executa COBOL.”

Tecnicamente há alguma verdade.

Pedagogicamente é quase inútil.

Git introduz um modelo importante de gerenciamento de mudanças.

Imagine:

main
 │
 ├──── feature/REQ-38271
 │
 │       ├── alteração COBOL
 │       ├── alteração COPYBOOK
 │       └── alteração teste
 │
 └──── fix/INC-9281

O desenvolvedor trabalha em sua alteração.

Depois:

commit
   ↓
push
   ↓
Pull Request
   ↓
Code Review
   ↓
Merge

Isso cria algo precioso:

rastreabilidade.

Podemos relacionar:

REQUISITO
    ↓
COMMIT
    ↓
BUILD
    ↓
TESTE
    ↓
ARTEFATO
    ↓
DEPLOY

Agora conseguimos responder:

Quem alterou?

Quando?

Por quê?

Qual requisito originou a alteração?

Qual versão foi compilada?

Quais testes passaram?

Qual artefato foi enviado para produção?

Esse tipo de informação é extremamente importante em grandes organizações, especialmente em ambientes sujeitos a controles internos, auditorias e regulamentação.



🧬 CAPÍTULO 4 — UMA COPYBOOK PARA A ESTEIRA

Carlitos está trabalhando tranquilamente quando alguém altera:

COPYB

Na fábrica existem:

PGMA → COPYA
     → COPYB

PGMB → COPYB
     → COPYC

PGMC → COPYD

Pergunta:

Quem precisa ser recompilado?

PGMA utiliza COPYB.

PGMB utiliza COPYB.

PGMC não utiliza COPYB.

Logo:

             COPYB
            /     \
           ▼       ▼
         PGMA     PGMB

Esse exemplo aparentemente simples apresenta ao iniciante um conceito extremamente importante:

dependências.

Em sistemas grandes, recompilar absolutamente tudo após qualquer mudança pode ser caro, demorado e desnecessário.

É aí que conceitos como dependency-based build tornam-se interessantes.

Ferramentas e frameworks de build podem ajudar a determinar quais componentes foram impactados pela mudança e quais precisam ser reconstruídos.

Aqui entram tecnologias como DBB e zAppBuild em determinados ecossistemas de desenvolvimento IBM Z.

Não devemos decorar apenas seus nomes.

Precisamos entender o problema que tentam resolver.


🔨 CAPÍTULO 5 — JENKINS NÃO É O OPERÁRIO

Outra máquina aparece.

Na placa está escrito:

JENKINS

O jovem pergunta:

— Jenkins compila COBOL?

Carlitos olha para ele.

Silêncio.

Jenkins é melhor compreendido como um orquestrador.

Imagine um mestre de cerimônias dizendo:

Pegue código
     ↓
Execute build
     ↓
Execute testes
     ↓
Faça análise
     ↓
Verifique qualidade
     ↓
Gere artefato
     ↓
Promova

Jenkins não precisa executar pessoalmente cada tarefa.

Ele coordena ferramentas, agentes, scripts e etapas.

Essa distinção é importantíssima.

O pipeline pode dizer:

STAGE 1 — CHECKOUT
STAGE 2 — BUILD
STAGE 3 — UNIT TEST
STAGE 4 — STATIC ANALYSIS
STAGE 5 — SECURITY
STAGE 6 — PACKAGE
STAGE 7 — DEPLOY DEV
STAGE 8 — INTEGRATION TEST
STAGE 9 — APPROVAL
STAGE 10 — PROD

De repente nossa fábrica ganhou uma linha de montagem automatizada.

Mas existe um perigo.

Automatizar um processo ruim apenas produz resultados ruins mais rapidamente.


🚧 CAPÍTULO 6 — CARLITOS PUXA A ALAVANCA VERMELHA

Imagine:

BUILD
  │
  ▼
TEST
  │
  ▼
SECURITY
  │
  ▼
DEPLOY

Agora imagine que os testes falharam.

O pipeline continua?

Não deveria.

Precisamos de portões:

SOURCE
  │
  ▼
COMPILE ───── ERROR ─────► STOP
  │
  ▼
TEST ──────── ERROR ─────► STOP
  │
  ▼
SECURITY ──── ERROR ─────► STOP
  │
  ▼
QUALITY ───── ERROR ─────► STOP
  │
  ▼
DEPLOY

São os famosos quality gates.

Aqui está uma ideia que todo iniciante deveria guardar:

Pipeline não existe simplesmente para colocar software em produção mais rapidamente. Pipeline também existe para impedir que software inadequado chegue rapidamente à produção.

A automação é simultaneamente acelerador e freio.


🧪 CAPÍTULO 7 — TESTAR NÃO É EXECUTAR E TORCER

Carlitos aperta um botão.

Luz verde.

O jovem comemora:

— Funcionou!

Carlitos entrega outro conjunto de dados.

Luz vermelha.

Esse é outro salto de maturidade.

Testar software não significa executar o cenário que sabemos que funciona.

Precisamos pensar em:

UNIT TEST
     │
INTEGRATION TEST
     │
SYSTEM TEST
     │
REGRESSION TEST
     │
ACCEPTANCE TEST

No mainframe isso pode envolver diferentes componentes.

Por exemplo:

COBOL
  │
  ├── lógica isolada
  │
  ├── Db2
  │
  ├── VSAM
  │
  ├── CICS
  │
  └── MQ

Testar um cálculo isolado é diferente de testar uma transação completa envolvendo banco, mensageria e outros sistemas.

Ferramentas de unit testing como ZUnit podem participar dessa estratégia.

Mas novamente:

ferramenta não é estratégia.

A ferramenta executa o teste.

O engenheiro precisa saber o que deve ser testado.


🛡️ CAPÍTULO 8 — DEVOPS ENCONTRA SEGURANÇA

Em algum momento alguém pergunta:

— E segurança?

Carlitos aponta para uma porta que deveria estar desde o começo da fábrica.

Esse é o espírito do DevSecOps.

Em vez de pensar:

DESENVOLVE
    ↓
TESTA
    ↓
ENTREGA
    ↓
SEGURANÇA OLHA

tentamos aproximar segurança de todo o ciclo:

PLAN
 ↓
CODE ← SECURITY
 ↓
BUILD ← SECURITY
 ↓
TEST ← SECURITY
 ↓
DEPLOY ← SECURITY
 ↓
OPERATE ← SECURITY

Podemos verificar código, dependências, configurações, credenciais, permissões e vulnerabilidades durante diferentes etapas.

No mainframe isso conversa muito bem com conceitos tradicionais de controle de acesso, segregação de funções, auditoria e RACF.

DevSecOps não deveria destruir os controles do mainframe.

Deveria ajudar a torná-los mais consistentes, verificáveis e automatizados.


🚚 CAPÍTULO 9 — DEV, SIT, UAT, PRE-PROD E PROD

Agora nossa peça precisa atravessar a fábrica.

DEV
 ↓
SIT
 ↓
UAT
 ↓
PRE-PROD
 ↓
PROD

Cada ambiente possui uma finalidade.

DEV permite desenvolvimento e testes iniciais.

SIT concentra testes de integração.

UAT permite validação de aceitação conforme o processo da organização.

PRE-PROD tenta aproximar determinadas características da produção.

Finalmente:

PROD.

Mas promover uma aplicação não significa simplesmente copiar um load module.

Pode haver:

LOADLIB
DBRM
PACKAGE
COPYBOOK
JCL
PROC
DB2 CHANGE
CICS RESOURCE
CONFIG
API

É por isso que deployment de aplicações corporativas precisa ser tratado seriamente.


💥 CAPÍTULO 10 — 03:17

Às 03:17, toca o telefone.

Eis nosso pequeno easter egg.

Produção apresentou problema.

Carlitos acorda.

O deploy realizado anteriormente parece estar relacionado.

Alguém grita:

— ROLLBACK!

Parece simples.

Volte a versão.

Mas espere.

A aplicação atualizou 480 mil registros Db2.

Publicou mensagens MQ.

Outro sistema consumiu algumas delas.

Um batch posterior processou parte dos dados.

Agora entendemos algo fundamental:

Rollback não é necessariamente Ctrl+Z.

Existem mudanças reversíveis facilmente.

Outras exigem planejamento.

Podemos ter:

APPLICATION ROLLBACK
DATABASE ROLLBACK
CONFIGURATION ROLLBACK
MESSAGE COMPENSATION
BUSINESS COMPENSATION

Esse conhecimento aproxima o aluno da realidade.


👀 CAPÍTULO 11 — PRODUÇÃO NÃO É O FINAL

A aplicação voltou.

Tudo verde.

Fim?

Não.

Começa outra etapa:

observabilidade.

Precisamos saber o que está acontecendo.

Três conceitos aparecem frequentemente:

METRICS
LOGS
TRACES

Podemos acrescentar eventos e alertas.

O mainframe já possui uma enorme tradição de telemetria e dados operacionais.

O aluno pode encontrar conceitos relacionados a:

SMF
RMF
JES
SDSF
CICS statistics
Db2 statistics
MQ metrics
application logs

e relacioná-los a ecossistemas modernos envolvendo dashboards, APM, Prometheus, Grafana e OpenTelemetry, dependendo da arquitetura adotada.

A grande pergunta deixa de ser:

O programa está rodando?

E passa a ser:

O sistema está se comportando corretamente?


📊 CAPÍTULO 12 — O PROGRAMA ESTÁ VERDE, MAS O CLIENTE ESTÁ VERMELHO

Imagine:

CPU ........ OK
MEMORY ..... OK
CICS ....... OK
DB2 ........ OK
MQ ......... OK

Tudo verde.

Mas pagamentos estão levando 18 segundos.

Tecnicamente diversos componentes podem estar disponíveis.

Do ponto de vista do cliente, porém, existe problema.

Observabilidade precisa aproximar infraestrutura e experiência do negócio.

Podemos acompanhar:

latência
throughput
taxa de erro
tempo de resposta
fila
CPU
I/O
locks
timeouts
transações

e, quando possível, indicadores de negócio.

Esse é um salto enorme para o programador iniciante.

Ele deixa de pensar exclusivamente no programa e começa a pensar no serviço.


🤖 CAPÍTULO 13 — CARLITOS ENCONTRA UM ROBÔ COM IA

Finalmente chega 2026.

A fábrica recebe uma nova máquina:

GENERATIVE AI

O gerente anuncia:

— Agora ela fará tudo!

Carlitos olha desconfiado.

Com razão.

IA pode auxiliar bastante no ciclo de desenvolvimento.

Pode ajudar a:

explicar código legado
documentar programas
sugerir testes
analisar código
resumir mudanças
investigar logs
produzir documentação
auxiliar code review

Imagine um COBOL antigo com milhares de linhas.

Uma ferramenta assistida por IA pode ajudar o desenvolvedor a compreender estruturas e fluxos.

Excelente.

Mas existe uma regra:

AI OUTPUT
    ↓
HUMAN REVIEW
    ↓
BUILD
    ↓
STATIC ANALYSIS
    ↓
TESTS
    ↓
SECURITY
    ↓
APPROVAL

Quanto mais fácil se torna produzir código, maior pode se tornar a necessidade de mecanismos confiáveis para verificar o código produzido.

Portanto existe uma ironia maravilhosa.

IA não elimina DevOps.

Ela pode tornar DevOps ainda mais importante.


🎓 CAPÍTULO 14 — DEVOPS NÃO DEVERIA SER UMA ILHA NA FORMAÇÃO

Aqui chegamos ao ponto central.

Imagine uma pós-graduação organizada assim:

COBOL
JCL
VSAM
DB2
CICS
IMS
MQ
DEVOPS

Parece razoável.

Mas existe um problema pedagógico.

O aluno pode interpretar DevOps como mais uma caixinha.

Eu faria diferente.

DevOps deveria atravessar várias disciplinas.

Aprendeu COBOL?

COBOL + Git + Test

Aprendeu Db2?

Db2 + migration + test + rollback

Aprendeu CICS?

CICS + deploy + observability

Aprendeu MQ?

MQ + integration test + monitoring

Aprendeu API?

API + OpenAPI + pipeline + security

Assim o aluno percebe que DevOps não está no final da estrada.

DevOps é parte da estrada.


🧑‍🏭 CAPÍTULO 15 — O CODING TANK DE CARLITOS

Eu terminaria essa formação com uma aplicação integradora.

Uma pequena aplicação financeira contendo:

CUSTOMER
ACCOUNT
TRANSACTION
PAYMENT

Tecnologias:

COBOL
JCL
CICS
DB2
VSAM
MQ
API

Então entregaria uma mudança:

Adicionar a origem da transação e disponibilizar a informação para um consumidor externo.

Primeiro o aluno pensa:

— Vou alterar um campo.

Depois descobre:

REQUISITO
     ↓
ANÁLISE DE IMPACTO
     ↓
COPYBOOK
     ↓
COBOL
     ↓
DB2
     ↓
CICS
     ↓
API
     ↓
GIT
     ↓
PULL REQUEST
     ↓
BUILD
     ↓
UNIT TEST
     ↓
INTEGRATION TEST
     ↓
QUALITY GATE
     ↓
SIT
     ↓
UAT
     ↓
APPROVAL
     ↓
PROD
     ↓
OBSERVABILITY

Agora COBOL deixou de ser uma disciplina.

Virou parte de um sistema.


🧠 CAPÍTULO 16 — A GRANDE DIFERENÇA ENTRE PROGRAMADOR E ENGENHEIRO

O objetivo não deveria ser abandonar a figura do programador COBOL.

Muito pelo contrário.

Precisamos valorizar profundamente esse conhecimento.

Mas podemos expandi-lo.

O profissional começa sabendo:

MOVE
IF
EVALUATE
PERFORM
CALL
READ
WRITE

Depois compreende:

JCL
VSAM
Db2
CICS
IMS
MQ

E finalmente enxerga:

              BUSINESS
                  │
                  ▼
             APPLICATION
                  │
      ┌───────────┼───────────┐
      ▼           ▼           ▼
    BATCH       ONLINE       API
      │           │           │
      └───────────┼───────────┘
                  ▼
                 Git
                  │
                  ▼
                CI/CD
                  │
                  ▼
               TESTING
                  │
                  ▼
               SECURITY
                  │
                  ▼
                PROD
                  │
                  ▼
           OBSERVABILITY

Esse profissional começa a se aproximar da ideia de um Mainframe Application Engineer.

Ele não precisa ser especialista em absolutamente tudo.

Isso seria impossível.

Mas precisa entender como as peças conversam.


🎩 EPÍLOGO — CARLITOS SAI DA ESTEIRA

No final de Tempos Modernos, Carlitos percebe que existe algo além daquela fábrica gigantesca.

Nossa metáfora termina de maneira semelhante.

O jovem programador entrou pensando:

Meu trabalho é escrever COBOL.

Depois descobriu:

Meu trabalho é alterar uma aplicação.

Mais tarde percebeu:

Meu trabalho é entregar uma mudança segura.

Finalmente compreendeu:

Meu trabalho faz parte da entrega contínua de um serviço de negócio.

Essa evolução muda completamente a maneira como ensinamos mainframe.

COBOL continua essencial.

JCL continua essencial.

CICS, IMS, Db2, VSAM e MQ continuam essenciais.

Mas precisamos construir as pontes:

LEGADO
   │
   ▼
Git
   │
   ▼
AUTOMAÇÃO
   │
   ▼
TESTES
   │
   ▼
SEGURANÇA
   │
   ▼
CI/CD
   │
   ▼
PRODUÇÃO
   │
   ▼
OBSERVABILIDADE

É por isso que DevOps precisa ganhar muito mais espaço na formação mainframe em 2026.

Não porque Git seja moderno.

Não porque Jenkins seja moderno.

Não porque pipeline seja moderno.

Mas porque o próprio trabalho mudou.

A empresa não precisa apenas de alguém capaz de apertar perfeitamente o parafuso que passa diante dele na esteira.

Ela precisa de profissionais capazes de olhar para as engrenagens e perguntar:

De onde veio esta peça?

Quem a modificou?

Como sabemos que funciona?

Como sabemos que é segura?

Quem autorizou sua passagem?

Como sabemos exatamente o que entrou em produção?

Como descobriremos que existe um problema?

E como voltaremos com segurança se algo der errado?

Carlitos pega sua bengala.

Olha uma última vez para a fábrica.

Em algum lugar, um pipeline fica vermelho.

O relógio marca discretamente:

03:17.

O jovem programador olha desesperado para ele:

— Carlitos! O que fazemos agora?

Ele aponta para o dashboard.

Depois para os logs.

Depois para o último commit.

Depois para o pipeline.

Finalmente aponta para o rollback documentado.

E sorri.

Porque finalmente o jovem entendeu.

Mainframe DevOps não é fazer o COBOL correr mais rápido pela esteira.

É construir uma esteira na qual saibamos o que entrou, quem colocou, por que entrou, como foi testado, como chegou até ali, como está funcionando e como retirá-lo caso alguma engrenagem comece a triturar Carlitos outra vez.

Um Café no Bellacosa Mainframe

Porque até em Tempos Modernos alguém precisa descobrir quem fez deploy direto em produção.

quinta-feira, 6 de junho de 2019

🥪 O Misto Quente da Sé – O Byte Crocante do Centro Velho

 


🥪 O Misto Quente da Sé – O Byte Crocante do Centro Velho
por El Jefe – Bellacosa Mainframe Midnight Lunch Edition

Há comidas que valem por uma lembrança. E há o misto quente de boteco da Sé, que vale por uma madrugada inteira, uma conversa perdida e meio maço de cigarros esquecidos no balcão.
Esse sanduíche simples — pão, queijo, presunto e chapa — é o prompt gastronômico da paulistaneidade.
É o “Hello, World!” da comida de boteco.

🏙️ Origem – Nascido sob o sino da Catedral
Lá pelos anos 1950, quando o coração da cidade ainda pulsava ao som dos bondes e das rotativas dos jornais, a Praça da Sé era um nó vital — onde passava todo tipo de alma: padre, camelô, estudante, repórter e malandro.
Entre o entra e sai das galerias e o sobe e desce das escadas do metrô, havia sempre um boteco — balcão de fórmica, chope trincando e chapa quente fumegando desde o amanhecer.
Ali nascia o misto quente da Sé, o lanche democrático, rápido e infalível.

🔥 A receita que o tempo não corrompeu
O segredo do misto não está nos ingredientes, mas na execução.
O pão francês (ou às vezes de forma, tostado até a borda estalar), o presunto suado de geladeira e o queijo derretendo preguiçoso.
Tudo esmagado na chapa com a espátula de ferro que já fritou três gerações de histórias.
O toque paulistano? Um pingo de manteiga demais e aquele guardanapo transparente que dissolve só de olhar.

🍻 O Misto como ritual urbano
Na Sé, o misto não é só um lanche — é uma pausa existencial.
Ele surge às 7h, quando o trabalhador chega com pressa, e renasce à 1h da manhã, quando o centro dorme com um olho aberto.
É o checkpoint da alma paulistana, onde se come em silêncio e observa a vida passar do outro lado do balcão.

📜 As Lendas da Chapa
Dizem que o primeiro misto lendário da Sé foi servido no antigo Bar do Ponto, logo em frente à catedral, por um português chamado Seu Álvaro, que atendia a todos por “doutor”.
Reza a lenda que cronistas, poetas e repórteres da redação do Diário Popular faziam fila na madrugada para comer o misto enquanto o jornal fechava.
Outros contam que um delegado e um ladrão já dividiram o mesmo misto ali, sem saber — tamanha era a neutralidade sagrada daquele balcão.

🧀 Adaptações e mutações urbanas
Com o tempo, o misto se espalhou. Virou “tostex” nas padarias gourmet, ganhou requeijão, peito de peru e até pão australiano.
Mas o verdadeiro misto quente da Sé continua lá — tostado até a alma, servido no balcão de azulejo, com café pingado em copo americano e jornal amarelado ao lado.

💬 Fofoquices do Centro Velho
Dizem que um dos botecos da Sé manteve a mesma chapa por mais de 40 anos, e que o dono jurava nunca tê-la lavado “pra não perder o tempero histórico”.
Há quem afirme que os primeiros ativistas sindicais dos anos 70 planejavam protestos enquanto devoravam mistos, e que, nos anos 90, os punks do centro trocavam fitas demo ali, no lanche mais subversivo da cidade.

💡 Dicas do Bellacosa
Se quiser sentir o sabor da São Paulo raiz:

  • entre 6h e 7h da manhã, quando o centro acorda e a Sé ainda boceja;

  • Peça um misto e um café pingado — combinação sagrada e imune à inflação;

  • Observe o balconista: ele é o sysadmin do boteco, mantém tudo rodando com precisão e óleo quente.

🖤 Reflexão do El Jefe Midnight Lunch
O misto quente da Sé é o mainframe do café da manhã paulistano — sólido, confiável, sempre online.
Não precisa de login, não trava, não depende da nuvem.
É feito de calor humano, manteiga e conversa de balcão.

Num mundo que serve cafés de 25 reais e pães de fermentação natural, o misto quente da Sé continua lá, humilde e eterno, lembrando a todos que às vezes o melhor reboot da vida cabe entre duas fatias de pão e uma chapa estalando.


🥪 Bellacosa Mainframe – preservando a alma tostada da São Paulo que acorda cedo e dorme tarde.


OS ANDARES DE SHOUJO SHUUMATSU RYOKOU E A JORNADA PELOS ÚLTIMOS LOGS DA CIVILIZAÇÃO

 

Bellacosa Mainframe e analise do mundo em Shoujo Shuumatsu Ryokou

☕🖥️🏙️ OPERADOR, A HUMANIDADE CONSTRUIU UM DATACENTER TÃO GRANDE QUE ESQUECEU COMO SAIR DELE

OS ANDARES DE SHOUJO SHUUMATSU RYOKOU E A JORNADA PELOS ÚLTIMOS LOGS DA CIVILIZAÇÃO

Quando assistimos Shoujo Shuumatsu Ryokou pela primeira vez, uma dúvida surge naturalmente.

Afinal:

O que são aqueles andares?

Por que Chito e Yuuri estão sempre subindo?

Por que a cidade parece não ter fim?

Por que existem elevadores gigantescos?

Por que tudo parece empilhado verticalmente?

A resposta simples é:

Não sabemos.

E essa ausência de resposta é justamente uma das maiores genialidades da obra.

Tsukumizu não construiu apenas um cenário.

Ele construiu uma metáfora.

Uma metáfora tão gigantesca que muitos espectadores passam o anime inteiro sem perceber.


Bellacosa Mainframe e os mapas teoricos de Shoujo Shuumatsu Ryokou

O Mundo Não É Um Mundo

Essa é a primeira coisa importante.

Muita gente imagina que Chito e Yuuri estão viajando por um planeta.

Mas a sensação transmitida pela obra é outra.

O cenário parece uma única megacidade infinita.

Uma estrutura vertical.

Camadas sobre camadas.

Andares sobre andares.

Plataformas sobre plataformas.

Como se a humanidade tivesse continuado construindo para cima durante séculos.

Talvez milênios.

Até perder completamente a escala.


A Cidade Como Um Mainframe

☕🖥️

Imagine um datacenter.

Não um datacenter comum.

Imagine todos os datacenters da humanidade fundidos em uma única estrutura.

Agora empilhe novos andares.

E novos andares.

E novos andares.

Durante centenas de anos.

O resultado seria algo próximo da cidade de Shoujo Shuumatsu Ryokou.

A sensação constante é que ninguém mais entende o sistema inteiro.

Existem apenas fragmentos.

Assim como em muitos sistemas legados.

Os criadores morreram.

Os arquitetos desapareceram.

A documentação foi perdida.

Restaram apenas usuários tentando sobreviver dentro de algo que ninguém mais compreende.


Os Andares Inferiores

Os níveis mais baixos possuem uma característica marcante.

São escuros.

Apertados.

Claustrofóbicos.

Cheios de ferrugem.

Cheios de máquinas.

Cheios de tubulações.

São quase subterrâneos.

Lembram os níveis físicos de uma infraestrutura.

É como caminhar dentro do hardware da civilização.

Ali não existe beleza.

Existe funcionamento.

Motores.

Engrenagens.

Energia.

Logística.

Distribuição.

A impressão é que estamos vendo o esqueleto do sistema.


A Camada da Sobrevivência

Nesses níveis inferiores encontramos algo interessante.

Quase tudo está relacionado às necessidades básicas.

Comida.

Água.

Combustível.

Abrigo.

É como a base da Pirâmide de Maslow.

Antes da arte.

Antes da filosofia.

Antes da religião.

Existe a sobrevivência.

Yuuri se sente extremamente confortável nesses ambientes.

Porque ela representa exatamente isso.

A parte da humanidade que sobrevive.


Os Andares Industriais

À medida que a jornada avança encontramos enormes instalações industriais.

Fábricas.

Máquinas automatizadas.

Linhas de produção.

Equipamentos gigantescos.

Mas existe algo estranho.

Quase ninguém sabe mais para que servem.

As máquinas continuam lá.

Mas seus operadores desapareceram.

É uma imagem assustadoramente semelhante a muitas ruínas industriais reais.

Quem visita antigas minas, siderúrgicas ou fábricas abandonadas frequentemente sente a mesma coisa.

Parece impossível que milhares de pessoas tenham vivido ali.

Mas viveram.

E desapareceram.


A Camada da Produção

☕🖥️

Se a cidade fosse um ambiente mainframe:

Os níveis inferiores seriam o hardware.

Os níveis industriais seriam os jobs batch.

Tudo funcionando.

Tudo processando.

Tudo produzindo.

Mas sem usuários.

Sem propósito.

Sem demanda.

Sem significado.

A produção continua.

Mas ninguém sabe por quê.


Os Andares Urbanos

Esses talvez sejam os mais melancólicos.

Ali vemos:

Escolas.

Residências.

Comércio.

Bibliotecas.

Praças.

Locais onde seres humanos viveram.

Esses andares representam a civilização em seu auge.

São os registros arqueológicos da vida cotidiana.

O curioso é que a destruição parece antiga.

Muito antiga.

A ponto de nem mesmo Chito e Yuuri conseguirem imaginar como aquelas pessoas viviam.


A Biblioteca

Um dos locais mais importantes da jornada.

Quando encontramos livros, encontramos memória.

Quando encontramos memória, encontramos humanidade.

Mas a biblioteca também revela uma verdade dolorosa.

Conhecimento não é imortal.

Ele depende de preservação.

Depende de transmissão.

Depende de leitores.

Sem leitores, uma biblioteca é apenas um depósito de papel.

Essa é uma das mensagens mais brutais do anime.


A Camada da Memória

Chito representa essa camada.

Ela registra.

Anota.

Desenha.

Fotografa.

Questiona.

Quer entender.

Ela é a última bibliotecária do mundo.

Mesmo sem perceber.


Os Andares Militares

Conforme avançamos percebemos algo desconfortável.

O mundo de Shoujo Shuumatsu Ryokou está cheio de vestígios militares.

Armas.

Munições.

Tanques.

Instalações defensivas.

Equipamentos bélicos.

Isso sugere que o colapso não foi natural.

Talvez tenha sido resultado de conflitos.

Talvez guerras sucessivas.

Talvez uma guerra tão grande que ninguém sobreviveu para registrar seu nome.


O Que Aconteceu Com a Humanidade?

A obra nunca responde claramente.

E talvez nunca devesse responder.

O mistério é parte da narrativa.

Mas os indícios sugerem:

  • guerra

  • esgotamento de recursos

  • declínio populacional

  • colapso tecnológico gradual

Não parece um único desastre.

Parece uma longa sequência de falhas acumuladas.


Os Elevadores Gigantes

Os elevadores são fascinantes.

Parecem absurdamente desproporcionais.

Como se tivessem sido construídos para movimentar cidades inteiras.

Isso sugere que a estrutura vertical cresceu tanto que a locomoção comum se tornou impossível.

Os elevadores são os antigos sistemas de transporte da civilização.

São os barramentos de comunicação do sistema.

Os links entre camadas.

As conexões entre módulos.


A Ascensão

Existe algo importante.

Chito e Yuuri estão constantemente subindo.

Fisicamente.

Mas também simbolicamente.

Cada novo nível representa uma camada diferente da experiência humana.

É quase uma peregrinação.

Uma arqueologia vertical.


Os Andares Superiores

Quando finalmente alcançamos níveis mais elevados, a atmosfera muda.

Existe mais luz.

Mais espaço.

Mais céu.

Menos peso.

Menos concreto.

Menos escuridão.

Parece que a cidade está ficando para trás.

Como se estivéssemos saindo das profundezas do sistema.


A Jornada Como Uma Pilha Tecnológica

☕🖥️

Sempre imaginei os andares como uma pilha de software.

Camadas inferiores:

Hardware.

Acima:

Sistema operacional.

Acima:

Middleware.

Acima:

Aplicações.

Acima:

Usuários.

Acima:

Propósito.

O anime faz exatamente o caminho inverso.

Ele começa nos restos da infraestrutura.

E sobe em direção às perguntas fundamentais.


O Último Andar

Talvez a maior sacada de Tsukumizu seja que o último andar nunca foi o objetivo real.

Porque o anime não é sobre chegar.

É sobre compreender.

Se Chito e Yuuri encontrassem uma placa dizendo:

"Fim da jornada."

Nada mudaria.

As perguntas continuariam existindo.


O Significado Filosófico da Subida

Em muitas tradições humanas, subir significa:

  • evolução

  • iluminação

  • transcendência

  • descoberta

Mas Shoujo Shuumatsu Ryokou subverte isso.

Quanto mais alto elas sobem, menos respostas encontram.

O topo não contém conhecimento.

O topo contém silêncio.


A Cidade Como a História Humana

Talvez a interpretação mais interessante seja esta.

Cada andar representa uma camada da própria civilização.

As fundações representam sobrevivência.

Os níveis industriais representam produção.

Os níveis urbanos representam sociedade.

As bibliotecas representam memória.

Os níveis militares representam conflito.

Os andares superiores representam reflexão.

E o topo representa a inevitabilidade do fim.


A Leitura Bellacosa Mainframe

☕🖥️🏙️

Depois de assistir várias vezes, cheguei a uma conclusão curiosa.

A cidade de Shoujo Shuumatsu Ryokou não parece uma cidade.

Ela parece um gigantesco dump da humanidade.

Um snapshot congelado de tudo que fomos.

Cada andar é um dataset.

Cada corredor é um log.

Cada biblioteca é um backup.

Cada fábrica é um job batch abandonado.

Cada elevador é um canal de comunicação entre gerações.

E Chito e Yuuri são as últimas operadoras do ambiente.

Não estão tentando restaurar o sistema.

Não estão tentando reiniciar a civilização.

Não estão procurando um administrador.

Estão apenas percorrendo os registros.

Lendo os logs.

Observando os artefatos.

Tentando entender quem foram os usuários que criaram aquele sistema colossal.

No fim das contas, os andares não são apenas lugares.

São camadas da própria condição humana.

E talvez por isso a jornada seja tão fascinante.

Porque ao subir aqueles níveis não estamos explorando uma cidade.

Estamos explorando a nós mesmos.

E a pergunta silenciosa que ecoa em cada elevador continua sendo a mesma:

"Se toda a humanidade fosse reduzida a ruínas, o que sobraria de nós nos andares superiores da memória?"


quarta-feira, 5 de junho de 2019

Yōjo Senki Gekijōban: O Filme Que Mostra o Que Acontece Quando o RCA é Ignorado Até Virar uma Catástrofe Continental

 

Bellacosa Mainframe e o filme Yojo Senki Gekijoban Tanya

☕💣🚀 PADAWAN, O INCIDENTE ESCALOU PARA GUERRA TOTAL!

Yōjo Senki Gekijōban: O Filme Que Mostra o Que Acontece Quando o RCA é Ignorado Até Virar uma Catástrofe Continental


🎬 Ficha Técnica

Título Original: 幼女戦記 劇場版 (Yōjo Senki Gekijōban)

Título Internacional: Saga of Tanya the Evil: The Movie

Baseado na Obra: Yōjo Senki

Autor Original: Carlo Zen

Ilustrações Originais: Shinobu Shinotsuki

Estúdio: NUT

Diretor: Yutaka Uemura

Roteiro: Kenta Ihara

Data de Lançamento: 8 de fevereiro de 2019 (Japão)

Duração: 101 minutos

Classificação Indicativa: 16+

Gêneros:

  • Isekai

  • Militar

  • Guerra

  • Fantasia

  • Drama

  • Estratégia

  • Política

  • Psicológico


🎯 Sinopse

Depois dos eventos da série de TV, Tanya acredita que finalmente poderá colher os frutos de suas vitórias militares.

Mas existe um problema.

Toda vez que Tanya acha que a produção estabilizou...

O universo abre um novo incidente crítico.

A guerra se expande.

Novos inimigos aparecem.

E surge alguém disposta a destruir Tanya a qualquer custo:

Mary Sioux

Uma jovem movida por vingança e fé absoluta.


☕ Bellacosa Mainframe Resume o Filme

Padawan...

Imagine que você acabou de resolver:

  • Um S0C7

  • Um Abend U4038

  • Um DB2 Deadlock

  • Uma falha de spool JES2

Então você registra:

INCIDENTE ENCERRADO

Cinco minutos depois surge:

PRIORIDADE 1 GLOBAL

Foi exatamente isso que aconteceu com Tanya.


🌎 O Contexto da História

O Império venceu várias campanhas.

Mas como acontece em muitos projetos corporativos...

As vitórias criam novos problemas.

A expansão militar gera:

  • Mais inimigos

  • Mais frentes de batalha

  • Mais custos

  • Mais desgaste político

O filme explora exatamente isso.


👧 Tanya Está Mudando?

Essa é uma das partes mais interessantes.

Na série, Tanya era vista principalmente como:

  • Fria

  • Calculista

  • Eficiente

No filme percebemos algo diferente.

Apesar de negar constantemente, Tanya começa a desenvolver:

  • Responsabilidade pelos subordinados

  • Lealdade

  • Liderança

Ela continua pragmática.

Mas não é mais apenas uma sobrevivente.

Está se tornando uma comandante.


👿 Mary Sioux

O Filme Pertence a Ela

Se Tanya representa:

Razão

Mary representa:

Emoção

Se Tanya representa:

Planejamento

Mary representa:

Impulso

Se Tanya representa:

Ciência

Mary representa:


⚔️ A Grande Guerra Filosófica

Muitos espectadores acreditam que o filme é sobre batalhas.

Na realidade:

As batalhas são apenas a superfície.

O verdadeiro conflito é:

Fé versus Racionalidade


🧠 Tanya e Mary São Dois Sistemas Operacionais

Tanya

Funciona como um ambiente IBM Z.

Tudo é:

  • Planejado

  • Testado

  • Monitorado

  • Controlado


Mary

Funciona como um usuário desesperado em produção.

Tudo é:

  • Emocional

  • Impulsivo

  • Imediato

Ela não quer resolver o problema.

Ela quer vingança.


🚀 O Que o Filme Tem de Diferente da Série?

Escala

A série parece uma operação regional.

O filme parece uma guerra mundial.


Qualidade Visual

O estúdio NUT elevou o nível.

As cenas aéreas estão entre as melhores já produzidas para um anime militar.


Ritmo

A série alterna:

  • Política

  • Estratégia

  • Treinamento

O filme praticamente não tira o pé do acelerador.


Profundidade Psicológica

Mary e Tanya funcionam como espelhos invertidos.

Uma mostra o que acontece quando a razão domina tudo.

A outra mostra o que acontece quando a emoção domina tudo.


💣 A Mensagem Oculta Mais Importante

Pouca gente percebe.

O filme inteiro fala sobre:

Consequências

Tanya acredita que:

Se uma decisão é lógica, ela é correta.

O filme questiona isso.

Porque uma decisão lógica ainda pode gerar:

  • Sofrimento

  • Ódio

  • Ressentimento

Mary é literalmente o resultado das decisões de Tanya.


🎭 A Crítica Política

O filme apresenta uma crítica extremamente sofisticada sobre:

Escalada de Conflitos

Nenhum país quer guerra total.

Mas decisões pequenas criam:

  • Reações

  • Contra-reações

  • Retaliações

Até que ninguém mais controla o processo.

É praticamente um incidente corporativo escalado sem governança.


🏢 O Filme Como Metáfora Empresarial

Carlo Zen trabalhou em ambiente corporativo japonês.

Isso aparece em toda a obra.

O Império funciona como uma empresa gigante.

Os generais funcionam como:

  • Diretores

  • Executivos

  • Gestores

As campanhas militares são projetos.

As tropas são recursos.

As perdas são custos operacionais.


☕ O Verdadeiro Vilão Não é Mary

Nem Tanya.

Nem os Aliados.

Nem o Império.

O verdadeiro vilão é:

A Escalada Automática dos Sistemas Humanos

Uma decisão leva a outra.

Uma vingança leva a outra.

Uma guerra leva a outra.

Ninguém consegue parar a máquina.


🎬 Qualidade Técnica

O estúdio NUT entregou uma produção impressionante.

Destaques:

Animação

Excelente.

Efeitos Visuais

Espetaculares.

Direção

Muito cinematográfica.

Trilha Sonora

Uma das melhores da franquia.

Batalhas Aéreas

Absolutamente memoráveis.


🌍 Impacto Cultural

O filme consolidou Yōjo Senki como um dos isekais mais respeitados da década.

Passou a ser referência para:

  • Isekais militares

  • Protagonistas anti-heróis

  • Narrativas estratégicas

  • Obras de guerra com profundidade filosófica

Também reforçou Tanya como uma das personagens femininas mais icônicas dos animes modernos.


🚨 Houve Censura?

Não houve censura significativa.

Mas a obra gerou discussões por:

  • Uniformes inspirados em exércitos europeus históricos.

  • Forte influência visual do período das guerras mundiais.

  • Temas religiosos.

  • Violência militar explícita.

Alguns críticos interpretaram a obra como militarista.

Na prática ocorre o oposto.

O filme mostra constantemente:

  • O custo humano da guerra.

  • O sofrimento dos envolvidos.

  • As consequências da vingança.


🔥 A Maior Lição Bellacosa Mainframe

Padawan...

O filme ensina algo que todo profissional de TI aprende cedo ou tarde.

Você pode resolver o incidente.

Mas se não resolver a causa raiz...

O problema volta.

Mary Sioux é o RCA que nunca foi executado.

Ela é a consequência acumulada de decisões anteriores.

Ela é o ticket encerrado sem análise.

Ela é o erro recorrente que retorna meses depois para derrubar a produção inteira.


🏆 Veredito Bellacosa Mainframe

Yōjo Senki Gekijōban não é apenas um filme de anime.

É uma aula sobre:

  • Consequências

  • Liderança

  • Estratégia

  • Escalada de conflitos

  • Gestão de riscos

  • Natureza humana

Se a série é um incidente crítico em produção...

O filme é o War Room reunido às 3 da manhã enquanto o ambiente inteiro está pegando fogo e todos descobrem que o problema era muito maior do que imaginavam.

Nota Bellacosa Mainframe: ⭐⭐⭐⭐⭐ (10/10)

Nível de Recomendação para Profissionais de Mainframe: EXTREMAMENTE ALTO ☕💣🚀

Porque, assim como em TI, a maior batalha raramente é contra o problema visível.

É contra as consequências invisíveis das decisões tomadas muito tempo atrás.


terça-feira, 4 de junho de 2019

☕💥 A Jornada do Padawan COBOL – Parte 6 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o CALL em Cobol Parte VI

☕💥 A Jornada do Padawan COBOL – Parte 6

Desvendando o Universo dos CALLs no Mainframe

CICS LINK, XCTL, COMMAREA, Channels, Containers, APIs REST, MQ, Java e os Segredos dos Arquitetos da Nova República IBM Z

Ou como descobrir que um programa COBOL escrito em 1987 pode responder uma API REST em menos tempo do que muita startup consegue carregar um framework

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que CALL não é a única forma de chamar programas

Até agora aprendemos:

✅ CALL estático

✅ CALL dinâmico

✅ Binder

✅ RENT

✅ CEEDUMP

✅ LPA

✅ LE

Mas um dia o Padawan entra em um ambiente CICS.

Abre um programa.

E encontra isto:

EXEC CICS LINK
     PROGRAM('PGM0001')
     COMMAREA(WS-COMM)
END-EXEC

E pensa:

Ué...

Cadê o CALL?


O universo paralelo do CICS

Em Batch usamos:

CALL 'VALIDA'

No CICS temos:

LINK

XCTL

START

RETURN

LOAD

DELETE


LINK

É praticamente o CALL do CICS.

Exemplo

EXEC CICS LINK
     PROGRAM('CPFVAL')
     COMMAREA(WS-COMMAREA)
END-EXEC

Visualmente


CLIENTE01


↓

LINK


↓

CPFVAL


↓

RETORNA


↓

CLIENTE01



Programa chamador continua vivo.

Igual ao CALL.


Vantagens

Retorna controle

Compartilha contexto

Excelente modularização

Pode executar milhares de vezes


XCTL

Agora a coisa muda.


Exemplo

EXEC CICS XCTL
     PROGRAM('MENU0001')
END-EXEC

Visualmente


TELA01

↓

XCTL

↓

MENU0001



TELA01 morre




Não retorna.

Nunca.


É quase um:

exit();

Quando usar?

Troca definitiva.

Menu.

Workflow.

Navegação.


LINK versus XCTL

CaracterísticaLINKXCTL
RetornaSimNão
Consome stackSimNão
PerformanceBoaExcelente
WorkflowMédioIdeal

COMMAREA

A rainha do CICS.


Ela transporta dados.


Exemplo

01 WS-COMM.

05 WS-CPF PIC X(11).

05 WS-NOME PIC X(30).

05 WS-RC PIC 99.

LINK

EXEC CICS LINK
PROGRAM('CPFVAL')
COMMAREA(WS-COMM)
LENGTH(100)
END-EXEC

Subprograma

DFHCOMMAREA.

O limite

64 KB


Padawan feliz.

Arquiteto preocupado.


Channels e Containers

IBM resolveu.


Nasce o conceito:

CHANNEL

CONTAINER


Praticamente JSON.

Mas IBM.


Exemplo

EXEC CICS PUT CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
FROM(WS-CLIENTE)
END-EXEC

Ler

EXEC CICS GET CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
INTO(WS-CLIENTE)
END-EXEC

Vantagens

Gigabytes.

Múltiplos objetos.

Flexível.


MQ

Padawan evolui.

Conhece IBM MQ.


Exemplo

CALL 'MQPUT'

Visualmente



COBOL

↓

MQPUT


↓

QUEUE


↓

JAVA


↓

API




Assíncrono.

Bonito.

Elegante.

IBM aprova.


APIs REST

O grande sonho.


"Posso expor COBOL como API?"

Sim.


Muito.


zOS Connect

O mago moderno.


Ele converte

REST

em

COBOL


Visualmente



POST /cliente



↓

zOS Connect



↓

COBOL



↓

DB2



↓

JSON




Cliente pensa:

Microserviço.


Realidade:

COBOL 1989.


Exemplo

API

{
"id":123
}

COBOL

01 WS-ID PIC 9(9).

Java

Sim.

Java conversa.


JNI.

LE.

DLL.


Exemplo

CobolService.executar();

COBOL

CALL 'PROCESSA'

Python

Sim.

Também.


API REST.

MQ.

Kafka.


Tudo possível.


Metal C

Território avançado.


Muito usado.

IBM Z.

Baixa latência.


zIIP

Arquiteto sorri.

Financeiro também.


Pode descarregar CPU.


Exemplo

JSON parsing.

REST.

MQ.

DB2 DRDA.


SMF 110

O espião do CICS.


Captura:

Tempo

CPU

LINK

XCTL

DB2

MQ


APA

Application Performance Analyzer


Mostra:

Hotspots

CALLs

Loops

CPU


Strobe

Ferramenta lendária.


Veteranos adoram.


Exemplo real

Programa

1000 LINKs

Tempo

5 segundos

Após otimização

400 ms


Truques Bellacosa

Dica 1

LINK

Retorna.


Dica 2

XCTL

Não retorna.


Dica 3

Channels > COMMAREA

Projetos novos.


Dica 4

MQ desacopla.


Dica 5

REST não mata COBOL.

REST promove COBOL.


Easter Egg Mainframe

Muitos bancos possuem.

Programa.

APIGEN01

Dentro.

EXEC CICS LINK

PROGRAM('LEG1987')

END-EXEC

API moderna.

Swagger.

OAuth.

OpenAPI.

JWT.

Kubernetes.

No final...

Executa.

MOVE SALDO TO WS-SALDO

Escrito em 1987.

Funciona.

Processa bilhões.

Ninguém reclama.


Checklist Jedi da Integração

✅ Preferir LINK

✅ XCTL para troca definitiva

✅ Evitar COMMAREA grande

✅ Usar Channels

✅ Monitorar SMF110

✅ Medir CPU

✅ Utilizar MQ

✅ Explorar zOS Connect

✅ Aproveitar zIIP

✅ Testar latência

✅ Documentar APIs


A Filosofia Jedi do CALL – Parte 6

O Padawan iniciante acredita:

COBOL só conversa com COBOL.

O desenvolvedor intermediário pensa:

COBOL pode consumir APIs.

O Arquiteto IBM Z entende:

COBOL conversa com qualquer tecnologia capaz de trocar bytes, mensagens, estruturas, JSON, XML ou eventos.

E é exatamente por isso que alguns dos sistemas mais modernos do planeta possuem uma arquitetura semelhante a esta:

Mobile

↓

API Gateway

↓

REST

↓

zOS Connect

↓

CICS LINK

↓

COBOL

↓

DB2

↓

MQ

↓

Analytics

↓

IA

Enquanto o cliente enxerga apenas um botão escrito "Consultar Saldo", um pequeno exército de programas COBOL, escritos ao longo de quarenta anos, continua executando silenciosamente milhões de chamadas por segundo, provando mais uma vez que, no Mainframe, a Força nunca esteve na moda da tecnologia, mas na sua capacidade de durar décadas sem perder desempenho, segurança e confiabilidade.


Próxima aventura do Padawan COBOL – Parte 7

Assembler, BALR, BASSM, PC-Bit, SVC, LE Internals, SRBs, TCBs, Cross Memory Services, zIIP, HiperDispatch e os segredos obscuros dos Sysprogs Jedi do IBM Z.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...