Translate

Mostrar mensagens com a etiqueta dev mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta dev mainframe. Mostrar todas as mensagens

domingo, 19 de abril de 2026

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

 

Bellacosa Mainframe fala sobre Ronins e Terceirização

💀 RONIN DO MAINFRAME: O CÓDIGO SEM SENHOR NO MUNDO CORPORATIVO

Existe um tipo de profissional que não pertence a lugar nenhum… mas é essencial em todos os lugares.
No Japão feudal, ele era chamado de ronin.
No mundo corporativo — especialmente no universo mainframe — ele atende por outro nome: o terceirizado de projeto.

E a semelhança vai muito além da estética.


⚔️ O QUE É UM RONIN, AFINAL?

A palavra ronin (浪人) significa literalmente “homem à deriva”.

No Japão feudal:

  • Era um samurai sem mestre (daimyō)
  • Perdia seu senhor por morte, desonra ou queda política
  • Ficava sem propósito fixo, sem renda e sem proteção

Mas não se engane…
Um ronin não era um fracasso.

Ele era, muitas vezes:

  • Extremamente habilidoso
  • Independente
  • Perigoso
  • E… livre demais para um sistema que exigia lealdade absoluta

💻 O RONIN DO MAINFRAME

Agora transporta isso para o nosso mundo…

O profissional que:

  • Entra em projetos críticos
  • Resolve o que ninguém resolve
  • Domina COBOL, JCL, CICS, DB2 como poucos
  • E… quando tudo estabiliza, é dispensado

Esse é o ronin corporativo.

Sem squad fixo.
Sem “casa”.
Sem pertencimento.

Mas com algo que poucos têm:
👉 capacidade de sobrevivência em qualquer ambiente hostil de TI


🔥 ANALOGIA DIRETA (SEM FILTRO)

Japão FeudalMainframe Corporativo
DaimyōCliente / Empresa
SamuraiFuncionário CLT
RoninTerceirizado
KatanaConhecimento técnico
Código de honra (Bushidō)Boas práticas, governança
SobrevivênciaAlocação em projetos

E aqui vem o ponto mais forte…

👉 O ronin não escolhe estabilidade.
👉 Ele escolhe movimento.


🧠 FILOSOFIA RONIN (QUE TODO DEV DEVERIA ENTENDER)

O ronin vive sob três regras não escritas:

1. 🧭 Você é sua própria reputação

Sem empresa para te “defender”, só existe:

  • Seu nome
  • Sua entrega
  • Seu histórico

No mainframe isso pesa ainda mais…
porque todo mundo se conhece.


2. ⚡ Aprender não é opcional

O ronin não tem zona de conforto.

Hoje é:

  • Batch noturno quebrando

Amanhã:

  • Problema em CICS com transação travando

Depois:

  • SQL de 1978 que ninguém entende

Se você não evolui… você desaparece.


3. 🏹 Desapego é sobrevivência

Terminou o projeto?

Você vai embora.

Sem despedida dramática.
Sem “vamos manter contato” que nunca acontece.

👉 Só o próximo desafio.


🏯 ORIGEM HISTÓRICA (CURIOSIDADE RAIZ)

Os ronin ficaram especialmente famosos após eventos como:

  • A era Tokugawa (1603–1868), quando guerras diminuíram
  • Muitos samurais ficaram sem função
  • Alguns viraram mercenários
  • Outros… professores, escritores ou até criminosos

O caso mais icônico:
👉 Os 47 Ronin

Um grupo que vingou seu mestre mesmo após anos — um dos maiores símbolos de lealdade da cultura japonesa.


🧩 EASTER EGGS QUE POUCA GENTE PERCEBE

  • 🔍 Muitos personagens de anime são “ronins modernos” (sem mestre, sem vínculo)
  • 💡 No mundo corporativo, o ronin é frequentemente o cara que “salva o legado”
  • ⚠️ Empresas dependem deles… mas raramente os valorizam corretamente
  • 🧠 O conhecimento deles é tácito, não documentado — um risco gigante

⚠️ O LADO SOMBRIO DO RONIN CORPORATIVO

Nem tudo é poesia.

Ser um ronin no mainframe também significa:

  • Falta de estabilidade
  • Pouco reconhecimento institucional
  • Desgaste constante
  • Necessidade de provar valor repetidamente

👉 É uma vida de guerra contínua.


🚀 O GRANDE PARADOXO

As empresas dizem querer:

  • Estabilidade
  • Padronização
  • Governança

Mas quando o sistema cai…

👉 Elas chamam o ronin.


☕ CONCLUSÃO ESTILO BELLACOSA

O ronin do mainframe não é só um profissional.

Ele é:

  • O cara que entra no caos
  • Entende código legado sem documentação
  • Resolve em silêncio
  • E desaparece antes dos aplausos

Enquanto muitos buscam conforto…

👉 O ronin busca relevância.

E no fundo, no fundo…

Todo ambiente crítico de mainframe sabe:

“Sem os ronins… muita coisa simplesmente pararia.”

 

segunda-feira, 30 de março de 2026

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

 

Bellacosa Mainframe e o servidor web dentro Mainframe

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳

IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

Se você ainda acha que mainframe é “tela verde + batch”…
👉 você está anos atrás.

Existe um componente rodando silenciosamente no z/OS que transforma:

COBOL legado → API moderna → web → mobile → cloud

Esse cara é o IBM HTTP Server (IHS).
E hoje você vai entender como ele funciona de verdade — no estilo Bellacosa 👊🔥


🌐 O QUE É O IBM HTTP SERVER?

O IHS (IBM HTTP Server) é o web server oficial da IBM.

👉 Baseado no Apache, mas com:

  • integração com z/OS
  • segurança enterprise (RACF)
  • performance absurda

💡 Tradução direta:

“É o Apache… só que preparado pra rodar num banco de bilhões.”


🧠 COMO ELE FUNCIONA (VISÃO REAL)

Quando alguém acessa:

https://empresa.com/api/clientes

Acontece isso:

Cliente (browser/app)

IBM HTTP Server (z/OS)

Backend (CICS / COBOL / DB2)

Resposta HTTP

🔥 Insight importante

O IHS NÃO executa COBOL diretamente.

Ele:

  • recebe requisição
  • encaminha para outro componente (ex: CICS, WAS)
  • devolve resposta

🏗️ ARQUITETURA TÍPICA

Internet

IHS (porta 80/443)

WebSphere / z/OS Connect

COBOL / CICS / DB2

⚙️ INSTALAÇÃO (nível z/OS raiz)

🔹 Requisitos básicos

  • z/OS instalado
  • TCP/IP ativo
  • USS (UNIX System Services)
  • Dataset do produto (SMP/E)

🔥 Onde ele vive?

👉 No USS (Unix do z/OS)

Exemplo de path:

/usr/lpp/ihs

💡 Insight

Se não conhece USS… já começou errado no mundo moderno do mainframe.


📦 INSTALAÇÃO via SMP/E

Resumo do processo:

  1. RECEIVE
  2. APPLY
  3. ACCEPT

👉 padrão IBM para software


⚙️ CONFIGURAÇÃO

Arquivo principal:

httpd.conf

🔹 Exemplo simples

Listen 8080

ServerName localhost

DocumentRoot "/u/ihs/htdocs"

<Directory "/u/ihs/htdocs">
AllowOverride None
Require all granted
</Directory>

💡 Tradução

  • porta → onde escuta
  • document root → onde estão arquivos
  • directory → permissões

🚀 EXECUÇÃO NO z/OS

Você pode iniciar via:

🔹 USS (direto)

apachectl start

🔹 Ou via JCL (mainframe raiz 👇)

//IHSSTART JOB ...
//STEP1 EXEC PGM=BPXBATCH
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDPARM DD *
SH /usr/lpp/ihs/bin/apachectl start
/*

🔥 Tradução Bellacosa

JCL chama UNIX… que sobe o servidor web 😳


🧪 TESTES (o momento da verdade)

Após subir:

🔹 Teste básico

curl http://localhost:8080

🔹 Ou browser:

http://hostname:8080

🧩 INTEGRAÇÃO COM COBOL

🔥 Cenário real

Você tem:

  • programa COBOL em CICS

Quer expor como API:

👉 Caminho:

IHS → z/OS Connect → CICS → COBOL

💡 Resultado

  • COBOL vira REST API
  • JSON entra / sai
  • mundo moderno conversa com legado

🔐 SEGURANÇA

🔹 Recursos:

  • SSL/TLS
  • certificados digitais
  • integração com RACF

🧨 Easter Egg

Você pode proteger endpoint HTTP com regras RACF.

👉 Sim, segurança de banco direto na web.


⚡ PERFORMANCE

🔥 Diferenciais no z/OS:

  • alta disponibilidade
  • integração com sistema
  • throughput absurdo

💡 Insight

O gargalo raramente é o IHS…
geralmente é o backend (COBOL/DB2)


🧨 CURIOSIDADES (nível Bellacosa)

🧠 1. Apache dentro do mainframe

Sim, mas adaptado e otimizado.


🔥 2. COBOL pode responder HTTP

Com ajuda de outros componentes.


💀 3. Web pode rodar sem sair da máquina

Com HiperSockets (memória ↔ memória).


🤯 4. Você pode ter API moderna…

rodando código de 30 anos.


⚠️ PROBLEMAS COMUNS

  • porta já em uso
  • erro de permissão USS
  • SSL mal configurado
  • backend não responde

🧠 DICAS DE OURO

💡 Dica 1

Sempre valide:

netstat -a | grep 8080

💡 Dica 2

Logs são sua vida:

logs/error_log
logs/access_log

💡 Dica 3

Entenda o fluxo completo

IHS raramente é o problema — ele só repassa.


🎯 RESUMO FINAL

✔ IHS = web server do z/OS

✔ Baseado em Apache

✔ Roda no USS

✔ Integra com COBOL via outros serviços

✔ Permite API, web e cloud


💥 FRASE FINAL

“O IBM HTTP Server é o tradutor…
que faz o mundo moderno entender o que o COBOL sempre soube fazer.”

 

quarta-feira, 24 de dezembro de 2025

💥 Seu CICS Não Sobe — Ele RENASCE: O Guia Definitivo de Startup e Shutdown Para Quem Vive de COBOL

 

Bellacosa Mainframe conheça o start e shutdown do CICS

💥 Seu CICS Não Sobe — Ele RENASCE: O Guia Definitivo de Startup e Shutdown Para Quem Vive de COBOL

Se você é um dev COBOL sênior, já sabe:
CICS não é só um runtime — é um organismo vivo dentro do z/OS.

E como todo organismo, ele tem dois momentos críticos:

👉 Como nasce (startup)
👉 Como morre (shutdown)

Dominar isso não é opcional. É o que separa quem “roda programa” de quem segura produção.


🧬 🕰️ UM POUCO DE HISTÓRIA (E UM EASTER EGG)

O IBM CICS nasceu lá nos anos 60/70 para resolver um problema simples:

Como processar milhares de transações simultâneas com consistência?

A resposta foi revolucionária:

  • Controle transacional (commit/rollback)
  • Gerenciamento de recursos
  • Isolamento de unidades de trabalho

💥 Easter egg:

O conceito de ACID que você vê em bancos modernos…
já era realidade no CICS décadas antes.


🚀 ⚙️ STARTUP — O NASCIMENTO DO CICS

🧠 O que realmente acontece quando você roda:

S CICSPRD1

Não é só “subir um sistema”.

👉 É isso aqui:

  1. JES inicia a task
  2. DFHSIP assume o controle
  3. SIT (System Initialization Table) é carregada
  4. Overrides são aplicados
  5. CICS consulta o catálogo
  6. Decide como iniciar
  7. Inicializa domínios
  8. Libera controle

🔥 O MOMENTO MAIS IMPORTANTE

DFHSI1517 Control is being given to CICS

👉 Tradução:

“Agora sim — pode mandar transação COBOL que eu aguento.”


🧠 TIPOS DE START (O PASSADO DEFINE O FUTURO)

TipoQuando acontece
INITIALPrimeira vez
COLDReset
WARMNormal
EMERGENCYApós falha

💥 Insight de produção

O tipo de startup não depende do comando…
depende de como o CICS morreu antes.


📦 🔍 GLOBAL CATALOG — A MEMÓRIA DO CICS

Aqui está o segredo:

O CICS sempre pergunta:

“O que aconteceu antes?”

E a resposta vem de:

  • Recovery Manager Control Record
  • Autostart Override Record

👉 Isso define:

  • Se houve crash
  • Se há transações pendentes
  • Se precisa recovery

💥 Easter egg técnico

START=AUTO não é “automático” —
é decisão baseada em histórico persistente


🔄 🚨 EMERGENCY START — VOLTANDO DOS MORTOS

Quando o CICS cai mal:

  • CANCEL
  • Queda de energia
  • Abend

👉 Ele entra em modo cirúrgico:

  1. Lê DFHLOG
  2. Identifica transações incompletas
  3. Executa rollback
  4. Restaura consistência

💣 Realidade

Emergency Start não é erro
é o sistema tentando salvar sua pele


🛑 ⚙️ SHUTDOWN — COMO O CICS MORRE

Agora vem a parte mais negligenciada — e mais perigosa.


🟢 NORMAL SHUTDOWN — MORRER COM DIGNIDADE

CEMT P SHUT

🧠 O que acontece:

Stage 1 (Quiesce)

  • Para novas transações
  • Deixa as atuais terminarem
  • Executa PLT

Stage 2 (Finalização)

  • Fecha arquivos
  • Flush de buffers
  • Fecha VTAM
  • Resolve unidades de trabalho
  • Marca “warm start possível”

🏁 Final:

DFHKE1799 TERMINATION OF CICS IS COMPLETE

💥 Resultado

👉 Próximo start:

WARM

👉 Rápido, limpo, sem dor


🟡 IMMEDIATE SHUTDOWN — FREIO DE EMERGÊNCIA

F CICSPRD1,CEMT P SHUT IMM

⚠️ O que muda:

  • Tasks podem ser interrompidas
  • Arquivos nem sempre fechados corretamente
  • Estado não totalmente salvo

💣 Consequência:

👉 Próximo start pode ser:

EMERGENCY

💥 Easter egg real de console

Se você já viu:

THREAD ENDED WITHOUT BEING UNDUBBED

👉 Parabéns: você já viveu um shutdown “meio traumático” 😅


🔴 UNCONTROLLED — O CAOS

Quando acontece:

  • Crash
  • Falha de hardware
  • Kill job

👉 Resultado:

❌ Nenhum controle
❌ Nenhuma garantia
❌ Recovery obrigatório


🔗 🔥 A REGRA MAIS IMPORTANTE

Como você desligaComo você sofre depois
NormalTranquilo
ImmediateTalvez
CrashCom certeza

🧠 💥 VISÃO DE UM DEV COBOL SÊNIOR

Se você trabalha com:

  • VSAM
  • DB2
  • MQ
  • Transações críticas

👉 Isso impacta diretamente:

✔ Commit consistency
✔ Locking
✔ Recovery
✔ Performance


💥 Exemplo real

Você faz:

EXEC CICS WRITE FILE(...)
EXEC CICS SYNCPOINT

👉 Se o CICS cai antes do syncpoint:

  • Emergency Start vai decidir
  • Rollback pode ocorrer
  • Dados podem voltar

🔧 🧪 CHECKLIST DE PRODUÇÃO (OURO)

Antes de desligar:

✔ Verificar tasks:

CEMT I TASK

✔ Verificar filas / integrações

✔ Garantir que não há batch crítico

✔ Executar:

CEMT P SHUT

😏 CONCLUSÃO PROVOCATIVA

CICS não é sobre rodar programas
é sobre garantir que nada se perca mesmo quando tudo dá errado


🚀 O QUE VOCÊ LEVA DISSO

✔ Entende o ciclo completo
✔ Sabe ler mensagens DFH
✔ Sabe escolher tipo de shutdown
✔ Entende impacto real em dados


💥 FRASE FINAL (GUARDA ESSA)

Quem domina STARTUP aprende a subir sistema
Quem domina SHUTDOWN aprende a salvar produção