Translate

sábado, 22 de fevereiro de 2020

KISS Rules : Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

  

Bellacosa Mainframe apresenta o KISS rules

☕ Um Café no Bellacosa Mainframe

KISS Rules sem Mistérios

Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

"A maior demonstração de inteligência não é construir algo complicado. É construir algo tão simples que continue funcionando décadas depois."


Prólogo — O Código Secreto do Arquiteto

Depois de inúmeras batalhas contra o Agente Smith, Neo finalmente teve acesso ao núcleo da Matrix.

Esperava encontrar algoritmos impossíveis.

Equações gigantescas.

Milhares de níveis de abstração.

Mas encontrou algo completamente diferente.

O coração da Matrix era surpreendentemente simples.

Poucas regras.

Poucas interfaces.

Poucos componentes.

Neo olhou espantado para o Arquiteto.

— Isso é tudo?

O Arquiteto respondeu calmamente.

— A complexidade não está no código.

Está no mundo.

Nos usuários.

Nos negócios.

Nos requisitos.

Nos imprevistos.

Neo insistiu.

— Então por que não criar uma arquitetura extremamente sofisticada?

O Oráculo apareceu.

Serviu duas xícaras de café.

Depois colocou sobre a mesa dois relógios.

Um possuía centenas de engrenagens.

Outro tinha poucas peças.

Perguntou:

— Qual você acha que continuará funcionando daqui a cinquenta anos?

Neo sorriu.

Naquele instante compreendeu o verdadeiro significado do KISS.


O que significa KISS?

KISS significa:

Keep It Simple, Stupid

Em português:

"Mantenha tudo o mais simples possível."

Apesar do termo "Stupid" soar ofensivo em português, ele nasceu como uma forma bem-humorada de lembrar engenheiros de que a simplicidade costuma ser mais poderosa do que soluções excessivamente sofisticadas.

Hoje muitas empresas preferem versões como:

  • Keep It Simple

  • Keep It Short and Simple

  • Keep It Simple and Smart

Mas a essência permanece a mesma.


A origem do princípio

O princípio surgiu na década de 1960.

Foi popularizado pelo engenheiro Kelly Johnson, líder da famosa divisão Skunk Works, da Lockheed.

Johnson orientava sua equipe a desenvolver aviões militares extremamente eficientes, porém fáceis de manter em condições adversas.

Sua filosofia era simples:

Um mecânico em um campo de batalha deve conseguir reparar o avião com ferramentas comuns.

Se o projeto fosse complexo demais para ser mantido, ele já havia fracassado.

Décadas depois, esse princípio tornou-se um dos pilares da Engenharia de Software.


Matrix explica perfeitamente

Imagine duas versões da Matrix.

A primeira possui:

  • cinco componentes;

  • regras claras;

  • comunicação simples.

A segunda possui:

  • cinquenta frameworks;

  • cem microsserviços;

  • dezenas de filas;

  • múltiplas camadas;

  • configurações espalhadas.

Qual delas Neo conseguiria compreender primeiro?

Provavelmente a mais simples.


Simples não significa simplório

Esse é um dos maiores mal-entendidos.

KISS não significa fazer menos.

Significa fazer apenas o necessário.

Existe enorme diferença.


O COBOL nasceu seguindo KISS

Quando COBOL surgiu, seu objetivo era ser:

  • legível;

  • previsível;

  • próximo da linguagem humana.

Observe.

ADD VALOR
   TO SALDO.

Ou.

IF CLIENTE-ATIVO

Mesmo décadas depois.

Ainda conseguimos entender.

Essa clareza foi uma decisão arquitetural.


Como nasce a complexidade?

Ela raramente aparece de uma vez.

Primeiro surge um pequeno framework.

Depois outro.

Depois uma camada.

Depois uma abstração.

Depois uma exceção.

Anos depois.

Ninguém consegue explicar a arquitetura completa.


Matrix Reloaded

O Arquiteto mostra para Neo inúmeras versões anteriores da Matrix.

Cada uma tornou-se mais sofisticada.

Mas também mais difícil de controlar.

Quanto maior a complexidade.

Maior o número de efeitos colaterais.


O efeito psicológico

Existe um fenômeno curioso.

Profissionais iniciantes frequentemente acreditam que:

"Código complicado impressiona."

Profissionais experientes descobrem justamente o contrário.

Código simples impressiona muito mais.

Porque é difícil escrever algo realmente simples.


O Programador COBOL Padawan

Imagine duas soluções.

Primeira.

IF CLIENTE-ATIVO

Segunda.

IF CLIENTE-ATIVO
   AND WS-FLAG-01 = "S"
   OR WS-FLAG-02 = "N"
   AND WS-STATUS-XYZ NOT = ZERO
   ...

Qual será compreendida daqui a quinze anos?


O Agente Smith ama complexidade

Porque sistemas complicados escondem:

  • bugs;

  • inconsistências;

  • duplicações;

  • vulnerabilidades.

Quanto mais difícil entender.

Mais difícil corrigir.


Um exemplo inspirado na Matrix

Neo precisa abrir uma porta.

Versão simples.

Uma chave.

Versão complexa.

Quatro chaves.

Cinco senhas.

Três certificados.

Dois tokens.

Sete validações.

No final.

A porta continua sendo apenas uma porta.


O custo invisível

Complexidade gera:

  • treinamento maior;

  • documentação maior;

  • testes maiores;

  • manutenção maior;

  • risco maior.

Tudo cresce.


O impacto no Mainframe

Em ambientes IBM Z encontramos aplicações com quarenta anos de vida.

Sistemas assim sobrevivem porque muitos seguiram princípios como:

  • simplicidade;

  • modularização;

  • previsibilidade;

  • estabilidade.

Não porque eram sofisticados.


Curiosidade

Albert Einstein costuma receber a frase:

"Everything should be made as simple as possible, but not simpler."

Embora a autoria exata seja debatida, a ideia resume perfeitamente o KISS:

Simplifique.

Mas nunca elimine o essencial.


Quando KISS é ignorado?

Começam a surgir:

  • frameworks desnecessários;

  • padrões aplicados sem necessidade;

  • heranças enormes;

  • interfaces excessivas;

  • configurações infinitas.

Tudo para resolver problemas simples.


Um exemplo COBOL

Imagine um cálculo.

Versão simples.

COMPUTE TOTAL = PRECO * QUANTIDADE

Versão complicada.

Três programas.

Cinco CALLs.

Duas APIs.

Uma fila MQ.

Resultado idêntico.


Matrix e o Chaveiro

O Chaveiro representa uma lição interessante.

Ele cria chaves.

Não cem ferramentas.

Cada chave resolve exatamente um problema.

Essa é uma excelente representação do KISS.


Atenção!

KISS não significa evitar arquitetura.

Significa evitar arquitetura desnecessária.


A diferença

Arquitetura Elegante

Resolve o problema.


Arquitetura Complicada

Cria novos problemas.


O papel da simplicidade

Sistemas simples apresentam:

  • menos bugs;

  • menor custo;

  • maior previsibilidade;

  • onboarding mais rápido;

  • documentação menor.


Ferramentas ajudam

No universo IBM.

Ferramentas como:

  • IBM ADDI;

  • SonarQube;

  • COBOL Check;

  • Enterprise Analyzer;

ajudam a localizar:

  • duplicações;

  • complexidade ciclomática;

  • código morto;

  • módulos gigantes.


O papel da IA

A IA frequentemente sugere soluções sofisticadas.

Cabe ao engenheiro perguntar:

"Existe uma maneira mais simples?"

Essa talvez seja uma das perguntas mais importantes da profissão.


Os riscos

Quando KISS é ignorado.

Surgem:

  • overengineering;

  • manutenção cara;

  • dependências excessivas;

  • curva de aprendizado enorme;

  • baixa produtividade.


Erros clássicos

  • Adotar tecnologia apenas porque está na moda.

  • Aplicar Design Patterns em todo lugar.

  • Criar abstrações prematuras.

  • Usar cinco frameworks quando um resolveria.

  • Confundir inteligência com complexidade.


Boas práticas

  • Resolver primeiro o problema.

  • Medir antes de otimizar.

  • Escrever código legível.

  • Modularizar.

  • Eliminar duplicações.

  • Revisar continuamente.

  • Questionar toda nova dependência.


Aplicabilidade

KISS aparece em:

  • COBOL.

  • CICS.

  • Db2.

  • Java.

  • Python.

  • APIs.

  • Cloud.

  • Kubernetes.

  • Microsserviços.

  • IA.

É um princípio universal.


KISS e os outros princípios

Curiosamente.

KISS conversa diretamente com vários conceitos já vistos nesta série.

Ele reduz:

  • Spaghetti Code, porque incentiva clareza.

  • Lasagna Code, porque evita camadas desnecessárias.

  • Golden Hammer, porque escolhe apenas as ferramentas necessárias.

  • Big Ball of Mud, porque favorece organização.

  • Boiling Frog, porque dificulta o crescimento invisível da complexidade.

  • Death March, porque soluções simples costumam ser entregues e testadas mais rapidamente.

Não é apenas um princípio isolado.

É uma filosofia que influencia praticamente todos os demais.


O ensinamento do Oráculo

O Oráculo entrega dois mapas para Neo.

O primeiro possui centenas de símbolos.

Setas.

Anotações.

Cores.

Camadas.

O segundo mostra apenas três caminhos.

Neo escolhe imediatamente o segundo.

Ela sorri.

— Por quê?

Neo responde.

— Porque consigo entender para onde estou indo.

Ela coloca a mão sobre seu ombro.

"Um sistema que ninguém compreende deixa de servir às pessoas e passa a exigir que as pessoas sirvam a ele."


Lições para um Programador COBOL Padawan

Durante sua carreira você encontrará colegas extremamente inteligentes.

Alguns escreverão soluções impressionantes.

Mas observe atentamente os profissionais realmente admirados após vinte ou trinta anos de experiência.

Quase sempre eles possuem outra característica.

Escrevem programas fáceis de ler.

Escolhem nomes claros.

Criam módulos pequenos.

Documentam decisões.

Eliminam o desnecessário.

Esses profissionais sabem que a manutenção representa a maior parte do ciclo de vida de um software.

Quem simplifica hoje está ajudando um colega — ou a si mesmo — daqui a dez anos.


Curiosidades

O princípio KISS influenciou diretamente diversas metodologias modernas:

  • Agile, ao priorizar entregas simples e incrementais.

  • Extreme Programming (XP), com foco na solução mais simples que funciona.

  • YAGNI (You Aren't Gonna Need It), evitando funcionalidades imaginárias.

  • Lean Software Development, reduzindo desperdícios.

  • Unix Philosophy, que recomenda ferramentas pequenas fazendo uma única tarefa muito bem.

Embora tenham surgido em épocas diferentes, todas compartilham a mesma ideia: simplicidade gera sustentabilidade.


Conclusão — O Código Verde da Matrix Era Simples

Quando Neo finalmente enxergou o código verde da Matrix, ele percebeu que por trás de toda aquela realidade existiam padrões claros e elegantes.

Os sistemas mais duradouros seguem exatamente esse caminho.

O princípio KISS nos ensina que complexidade deve existir apenas quando ela é realmente necessária. Cada camada, cada framework, cada abstração e cada linha de código precisam justificar sua existência.

Para um Programador COBOL que trabalha com IBM Z, essa lição é ainda mais valiosa. Sistemas bancários, seguradoras e governos dependem de aplicações que continuarão sendo mantidas por décadas. Quanto mais simples, legíveis e previsíveis forem essas aplicações, maior será sua capacidade de evoluir sem perder confiabilidade.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na parede da sala do Arquiteto:

"A verdadeira genialidade não está em criar uma Matrix impossível de compreender. Está em construir uma tão simples que qualquer Padawan consiga mantê-la funcionando mesmo cinquenta anos depois."

Porque, no fim, o software que atravessa gerações não é aquele que impressiona pela complexidade.

É aquele que continua resolvendo problemas quando todas as tecnologias da moda já ficaram para trás.

quinta-feira, 20 de fevereiro de 2020

A Psicologia por Trás do Programador COBOL

 

Bellacosa Mainframe e a psicologia por trás do programador Cobol

☕ Um Café no Bellacosa Mainframe

A Psicologia por Trás do Programador COBOL

Como as Grandes Teorias do Comportamento Explicam a Vida no IBM Z — Um Guia para o Programador COBOL Padawan Inspirado em Star Trek e no Dr. Spock

"A lógica é o começo da sabedoria, não o fim." — Dr. Spock

Existe uma curiosidade fascinante sobre o desenvolvimento de software.

Quando um programa COBOL apresenta um ABEND S0C7 pela terceira vez consecutiva, duas pessoas podem reagir de maneiras completamente diferentes.

Um iniciante pensa:

"Eu nunca vou aprender isso."

Um veterano pensa:

"Interessante... existe um padrão escondido."

O erro é exatamente o mesmo.

A diferença está no cérebro.

Mais especificamente, na forma como aprendemos, criamos hábitos, tomamos decisões, reagimos ao estresse e interpretamos o sucesso e o fracasso.

Curiosamente, quase tudo isso já havia sido estudado muito antes da existência do COBOL.

Muito antes do IBM System/360.

Muito antes da linguagem C.

Muito antes do Agile.

A psicologia comportamental, cognitiva e social explica boa parte do que acontece diariamente dentro de um projeto mainframe.

Hoje vamos visitar a ponte da USS Enterprise.

Nosso guia será o oficial de ciências mais famoso da ficção.

Dr. Spock.

Porque poucos personagens representam tão bem o equilíbrio entre lógica, emoção, aprendizado e disciplina quanto um vulcano.

Prepare seu tricorder.

Vamos explorar a mente do programador.


Capítulo 1 — O cérebro do programador COBOL

Quando um padawan chega ao IBM Z ele acredita que seu maior desafio será aprender:

  • COBOL

  • JCL

  • CICS

  • Db2

  • VSAM

  • IMS

  • RACF

Na verdade não.

Seu maior desafio será aprender...

...como funciona seu próprio cérebro.

Porque programar é uma atividade profundamente psicológica.

Todos os dias você precisa:

  • resolver problemas

  • aprender coisas novas

  • lembrar detalhes

  • controlar ansiedade

  • trabalhar em equipe

  • lidar com críticas

  • aceitar erros

  • persistir

Tudo isso é comportamento humano.


Capítulo 2 — Ivan Pavlov e os condicionamentos

Todo mundo conhece o cachorro de Pavlov.

O experimento era simples.

Campainha.

Comida.

Salivação.

Depois de repetir diversas vezes...

Somente a campainha já fazia o cachorro salivar.

Chamamos isso de:

Condicionamento clássico.


E no mainframe?

Você também foi condicionado.

Exemplos:

Abrir SDSF →

Ansiedade.

Receber e-mail do gerente →

Tensão.

Ver "ABEND" →

Frio na barriga.

Ou...

Ver JOB RC=0000 →

Satisfação.

Seu cérebro aprende associações constantemente.


Dica Bellacosa

Não associe erro à vergonha.

Associe erro ao aprendizado.

Veteranos fazem exatamente isso.


Capítulo 3 — Skinner e o condicionamento operante

B. F. Skinner mostrou que comportamentos recompensados tendem a aumentar.

Exemplo:

Você resolve um problema difícil.

Recebe elogios.

Seu cérebro libera dopamina.

Na próxima vez...

Você terá maior motivação.


No desenvolvimento COBOL

Quando um mentor diz:

"Excelente análise."

Você ganha confiança.

Quando ele apenas critica...

Seu aprendizado diminui.

Por isso grandes líderes ensinam.

Não apenas corrigem.


Easter Egg Star Trek

Capitão Kirk motiva.

Spock orienta.

McCoy apoia emocionalmente.

Uma boa equipe técnica possui exatamente esses três perfis.


Capítulo 4 — Albert Bandura e a aprendizagem observacional

Bandura revolucionou a psicologia.

Ele mostrou que aprendemos observando.

Nem sempre precisamos experimentar.

Podemos aprender vendo alguém fazer.


O veterano na tela 3270

Você observa um analista experiente.

Ele:

  • navega rapidamente

  • usa atalhos

  • identifica erros em segundos

  • conhece comandos escondidos

Você aprende apenas olhando.

Por isso pair programming funciona.

Shadowing funciona.

Mentoria funciona.


Curiosidade

Grande parte do conhecimento do mainframe nunca foi documentada.

Foi transmitida oralmente.

Como os mestres Jedi.


Capítulo 5 — Jean Piaget

Piaget estudou como construímos conhecimento.

Aprender não significa decorar.

Aprender significa reorganizar modelos mentais.


Exemplo

No início:

"JCL executa programa."

Depois:

"JCL conversa com JES."

Mais tarde:

"JES conversa com WLM."

Depois:

"SMS influencia datasets."

Depois:

"Tudo faz parte do sistema operacional."

Seu cérebro cria mapas mentais cada vez maiores.


Capítulo 6 — Lev Vygotsky

Talvez a teoria mais importante para um padawan.

Vygotsky criou a famosa:

Zona de Desenvolvimento Proximal.

Ou simplesmente:

ZDP.

Ela representa aquilo que você ainda não consegue fazer sozinho...

...mas consegue fazer com ajuda.


Exemplo

Você não sabe montar um BIND PACKAGE.

Com um mentor...

Consegue.

Depois de algumas semanas...

Faz sozinho.

É assim que ocorre o crescimento profissional.


Dica

Nunca estude completamente sozinho.

Mentores aceleram décadas de aprendizado.


Capítulo 7 — Carol Dweck e o Growth Mindset

Carol Dweck descobriu duas formas principais de pensar.

Mentalidade fixa

"Sou ruim em COBOL."

Fim.


Mentalidade de crescimento

"Ainda não domino COBOL."

Existe enorme diferença.

A palavra "ainda" muda tudo.


No IBM Z

Veteranos erram diariamente.

A diferença?

Eles sabem que aprenderão com o erro.


Spock diria

"A ausência de conhecimento atual não implica incapacidade futura."


Capítulo 8 — Daniel Kahneman

Prêmio Nobel.

Criador da teoria dos dois sistemas.

Sistema 1:

Rápido.

Automático.

Instintivo.

Sistema 2:

Lento.

Analítico.

Lógico.


Durante um ABEND

Sistema 1:

"Foi o Db2."

Sistema 2:

"Vamos verificar SQLCODE."

Ou:

"Vamos analisar SYSUDUMP."

Ou:

"Verifique o offset."

Grandes analistas usam o Sistema 2.


Capítulo 9 — Heurísticas

Nosso cérebro cria atalhos.

Eles economizam energia.

Mas produzem erros.


Viés da confirmação

"Tenho certeza que o erro está no COBOL."

Horas depois...

Era o JCL.


Ancoragem

"O último problema era VSAM."

Logo:

Todo problema agora parece VSAM.


Disponibilidade

Você lembra do último ABEND.

Então acredita que ele é o mais comum.

Mesmo não sendo.


Capítulo 10 — Maslow

A famosa pirâmide.

No mundo corporativo ela aparece diariamente.

Primeiro:

Segurança.

Depois:

Pertencimento.

Depois:

Reconhecimento.

Depois:

Autorrealização.


Um padawan inseguro

Tem medo de perguntar.

Tem medo de errar.

Tem medo de produzir.

Sem segurança psicológica...

Não existe inovação.


Capítulo 11 — Herzberg

Herzberg descobriu algo curioso.

Salário evita insatisfação.

Mas não gera paixão.

O que realmente motiva?

  • autonomia

  • crescimento

  • reconhecimento

  • propósito


Mainframe

Quem entende que processa milhões de salários, hospitais e bancos...

Encontra propósito.


Capítulo 12 — Csikszentmihalyi e o Flow

Flow.

O estado de concentração absoluta.

Você esquece o relógio.

Horas passam.

Você nem percebe.


Quando acontece?

Desafio equilibrado.

Nem fácil.

Nem impossível.

É exatamente onde um bom líder posiciona seus padawans.


Capítulo 13 — Charles Duhigg e os hábitos

Todo hábito possui:

  • gatilho

  • rotina

  • recompensa


Exemplo

Chegar ao trabalho.

Abrir SDSF.

Verificar jobs.

Sensação de controle.

Em poucos meses...

Isso vira automático.


Dica

Crie hábitos saudáveis:

  • revisar código

  • comentar programas

  • ler manuais

  • testar antes do deploy


Capítulo 14 — Inteligência Emocional (Daniel Goleman)

Conhecimento técnico explica parte do sucesso.

Relacionamento explica o restante.

Grandes profissionais:

  • ouvem

  • perguntam

  • ajudam

  • compartilham

Nunca humilham iniciantes.


Curiosidade

Muitas empresas perderam especialistas...

Não por aposentadoria.

Mas porque ninguém quis aprender com pessoas difíceis.

Conhecimento sem empatia morre.


Capítulo 15 — Reforço Positivo na Revisão de Código

Imagine duas revisões.

Revisor A

"Está tudo errado."

Fim.


Revisor B

"Gostei da organização. Agora podemos melhorar estes três pontos."

Mesmo resultado técnico.

Impacto psicológico completamente diferente.


Capítulo 16 — O efeito Dunning-Kruger

Iniciantes frequentemente acreditam que sabem muito.

Depois descobrem quanto ainda falta aprender.

A confiança cai.

Mais tarde...

O conhecimento cresce.

A confiança volta.

Agora baseada em experiência.

Todo especialista já passou por essa curva.


Capítulo 17 — O poder da curiosidade

A curiosidade é um dos maiores motores do aprendizado.

Perguntas como:

  • Por que existe o SQLCA?

  • Por que o JCL usa DDNAME?

  • Por que o COBOL continua evoluindo?

  • Como o JES agenda milhares de jobs?

  • Como o WLM decide prioridades?

Cada resposta amplia seu mapa mental.

Os melhores profissionais raramente se contentam com "funciona". Eles perguntam "por que funciona?".


Easter Egg — A Ponte da USS Enterprise como um Projeto Mainframe

Imagine um grande sistema bancário.

  • Capitão Kirk é o gerente de projeto: toma decisões sob pressão e assume riscos calculados.

  • Dr. Spock é o arquiteto ou analista sênior: baseia-se em evidências, métricas e lógica.

  • Dr. McCoy representa RH, UX e liderança humana: lembra que sistemas existem para atender pessoas.

  • Scotty é o sysprog: mantém a infraestrutura IBM Z funcionando, faz milagres com CPU, memória e I/O.

  • Uhura é o middleware: garante que CICS, MQ, APIs e sistemas conversem.

  • Sulu é o operador: conduz a operação diária com precisão.

  • Chekov é o padawan curioso: aprende rápido, faz perguntas e cresce a cada missão.

Nenhum deles vence sozinho. A Enterprise funciona porque cada especialidade respeita as demais.


As Grandes Lições para um Padawan COBOL

Depois de conhecer essas teorias, fica claro que evoluir no mainframe depende de muito mais do que decorar comandos.

Os maiores aprendizados são:

  • Erros são dados para aprendizado, não motivos para vergonha.

  • Observe especialistas: modelagem é uma das formas mais rápidas de aprender.

  • Desenvolva uma mentalidade de crescimento e aceite o "ainda não".

  • Questione seus próprios vieses antes de concluir a causa de um problema.

  • Crie hábitos consistentes de estudo, testes e documentação.

  • Valorize mentores e também torne-se mentor quando adquirir experiência.

  • Cultive inteligência emocional: conhecimento compartilhado vale mais do que conhecimento guardado.

  • Busque o estado de flow, equilibrando desafio e capacidade.

  • Nunca pare de fazer perguntas.


Conclusão — O Verdadeiro Vulcano do IBM Z

No universo de Star Trek, muitos acreditam que Spock representa apenas a lógica. Mas essa é uma visão incompleta.

Spock estudou suas emoções para não ser dominado por elas. Ele sabia que lógica sem empatia se torna fria, enquanto emoção sem disciplina leva a decisões impulsivas. Sua força estava no equilíbrio.

O mesmo vale para um excelente profissional de mainframe.

Dominar COBOL, JCL, CICS, Db2, IMS, RACF ou z/OS é essencial, mas insuficiente. Os melhores especialistas também entendem como aprendem, como colaboram, como reagem à pressão, como recebem críticas e como transformam erros em experiência.

Em um datacenter, milhões de linhas de código mantêm bancos, hospitais, governos e empresas funcionando. Mas por trás de cada linha existe um ser humano tomando decisões. É aí que a psicologia encontra a engenharia.

Ao longo da carreira, você perceberá que os maiores desafios raramente serão técnicos. Eles envolverão comunicação, disciplina, curiosidade, paciência, liderança e aprendizado contínuo.

Como diria o Dr. Spock:

"Computadores são excelentes ferramentas para seguir instruções. Pessoas são extraordinárias porque conseguem aprender, adaptar-se e evoluir."

Essa talvez seja a tecnologia mais poderosa de todas.


quarta-feira, 19 de fevereiro de 2020

Jenkins - O Que Todo Programador COBOL Padawan Precisa Saber Sobre CI/CD, DevOps, Pipelines, Git, Automação, IBM Z

 

Bellacosa Mainframe apresenta o jenkins

☕ Um Café no Bellacosa Mainframe

Jenkins Muito Além do Botão "Build"

O Que Todo Programador COBOL Padawan Precisa Saber Sobre CI/CD, DevOps, Pipelines, Git, Automação, IBM Z e Como o Jenkins se Tornou o Maestro da Engenharia de Software Moderna

"Compilar um programa é uma tarefa. Automatizar uma empresa inteira é engenharia."


Introdução

Se você começou recentemente sua jornada no universo IBM Mainframe, provavelmente já ouviu alguém dizer algo parecido com:

"Faz um build no Jenkins."

Parece algo simples.

Você altera um programa COBOL.

Faz um git push.

Alguns minutos depois alguém informa:

"O pipeline ficou verde."

Ou então...

"O Jenkins quebrou."

Para quem está começando, tudo isso parece mágica.

Existe um servidor.

Existe um robô.

Existe um botão chamado Build Now.

E, aparentemente, tudo acontece sozinho.

Mas o Jenkins está muito longe de ser apenas um servidor que compila programas.

Na realidade, ele é um dos pilares que sustentam praticamente toda a engenharia moderna de software.

Se o Git organiza o código-fonte, o Jenkins organiza todo o trabalho realizado sobre esse código.

Neste artigo vamos muito além dos conceitos básicos. Vamos entender como o Jenkins nasceu, por que ele revolucionou a indústria, como funciona sua arquitetura, por que ele continua relevante mesmo na era do Kubernetes, GitHub Actions e Inteligência Artificial, e como tudo isso conversa perfeitamente com o universo IBM Z, COBOL, CICS, DB2 e z/OS.

Pegue seu café.

Hoje vamos conversar sobre um dos softwares mais importantes da história da Engenharia de Software.


Antes do Jenkins: a era da integração manual

Imagine um banco em 1998.

A equipe possui:

  • 80 programadores COBOL

  • 20 analistas

  • dezenas de aplicações

  • centenas de programas

Cada desenvolvedor trabalha em sua própria máquina.

Ao final da semana...

Todos entregam seus programas.

Alguém precisa reunir tudo.

Compilar.

Executar testes.

Gerar executáveis.

Mover bibliotecas.

Executar JCLs.

Atualizar CICS.

Publicar em produção.

Tudo manualmente.

Agora imagine o caos.

João alterou o Programa A.

Maria alterou o Programa B.

Carlos modificou um COPY utilizado por ambos.

Quando tudo é compilado junto...

Nada funciona.

Esse problema ficou conhecido como Integration Hell.

Quanto maior a equipe...

Maior o problema.

Era necessário encontrar uma solução.


O nascimento da Integração Contínua

Foi aí que surgiu uma ideia simples.

Ao invés de integrar o código apenas no final do projeto...

Por que não integrar continuamente?

Sempre que alguém fizer uma alteração:

  • compilar automaticamente;

  • executar testes;

  • verificar qualidade;

  • avisar imediatamente se algo deu errado.

Assim nasceu a Continuous Integration (CI).

A integração contínua não é uma ferramenta.

É uma filosofia.

O Jenkins tornou essa filosofia prática.


O que realmente é o Jenkins?

Muita gente responde:

"É uma ferramenta de Build."

Na verdade, isso é apenas uma pequena parte.

O Jenkins é um servidor de automação.

Ele automatiza praticamente qualquer tarefa repetitiva.

Pode:

  • compilar programas

  • executar testes

  • gerar documentação

  • criar containers Docker

  • executar scripts Shell

  • chamar APIs

  • publicar microsserviços

  • disparar Ansible

  • executar Terraform

  • chamar Zowe CLI

  • enviar notificações

  • atualizar ambientes Mainframe

Ou seja...

O Jenkins não entende apenas de software.

Ele entende de processos.


Pense no Jenkins como um maestro

Imagine uma orquestra.

Cada músico conhece apenas seu instrumento.

O maestro coordena todos.

O Jenkins faz exatamente isso.

Ele não precisa saber programar Java.

Nem COBOL.

Nem Python.

Ele apenas coordena.

Git

↓

Compilar

↓

Testar

↓

Analisar qualidade

↓

Criar artefatos

↓

Publicar

↓

Implantar

↓

Monitorar

Cada ferramenta executa sua especialidade.

O Jenkins organiza a sequência.


O Pipeline: a esteira de produção do software

Uma fábrica produz automóveis.

O software moderno produz versões.

Imagine uma linha de montagem.

Chassi

↓

Motor

↓

Pintura

↓

Inspeção

↓

Entrega

Agora substitua por desenvolvimento.

Código

↓

Build

↓

Testes

↓

Qualidade

↓

Deploy

↓

Monitoramento

Esse fluxo recebe o nome de Pipeline.

Pipeline significa literalmente:

tubulação.

Cada etapa entrega seu resultado para a próxima.

Se uma etapa falhar...

Nada continua.


O primeiro passo: Git

Tudo começa no Git.

O desenvolvedor altera um programa COBOL.

CLIENTE.CBL

Executa:

git add .

git commit

git push

Nesse instante acontece algo extremamente importante.

O Git envia um evento.

Esse evento dispara um Webhook.


WebHooks: quem avisa quem?

Um erro comum é imaginar que o Jenkins fica perguntando ao Git:

Mudou?

Mudou?

Mudou?

Isso existia.

Chamava-se Poll SCM.

Hoje o modelo mais moderno é o WebHook.

O GitHub avisa imediatamente:

Recebi um commit.

Pode iniciar o Pipeline.

É mais rápido.

Mais eficiente.

Mais escalável.


Build: muito além de compilar

No universo Java, Build normalmente significa:

.java

↓

.class

↓

.jar

No universo COBOL isso muda bastante.

Um Build pode incluir:

  • compilação COBOL

  • Link-Edit

  • geração do Load Module

  • pré-compilação DB2

  • BIND

  • geração de mapas CICS

  • cópia para bibliotecas

  • atualização de catálogos

Observe que "Build" não é apenas traduzir código.

É transformar código-fonte em algo executável.


Testes: por que eles são indispensáveis?

Imagine um caixa eletrônico.

Você altera apenas uma linha.

Sem testes.

Na segunda-feira...

Nenhum saque funciona.

Por isso o Pipeline executa testes automaticamente.

Existem vários níveis.

  • Unit Test

  • Integration Test

  • Component Test

  • Smoke Test

  • Regression Test

  • Performance Test

  • Security Test

  • Acceptance Test

No universo IBM Z encontramos ferramentas como:

  • IBM ZUnit

  • COBOL Check


SonarQube: o inspetor de qualidade

Compilar não significa qualidade.

Um programa pode compilar perfeitamente e ainda assim possuir:

  • código duplicado

  • vulnerabilidades

  • baixa cobertura de testes

  • alta complexidade

  • más práticas

Ferramentas como SonarQube analisam tudo isso.

Se a qualidade estiver abaixo do padrão...

O Jenkins interrompe o Pipeline.


Continuous Delivery e Continuous Deployment

Esses conceitos costumam gerar confusão.

Continuous Delivery

Tudo acontece automaticamente.

Mas existe aprovação humana antes da produção.

Build

↓

Testes

↓

Deploy QA

↓

Aprovação

↓

Produção

É o modelo predominante em bancos.

Continuous Deployment

Não existe aprovação manual.

Passou em todos os testes?

Vai automaticamente para produção.

Empresas como Netflix, Spotify e Amazon utilizam amplamente essa estratégia para muitos de seus serviços.


Jenkinsfile: Pipeline como Código

Antigamente configurávamos tudo pela interface gráfica.

Hoje utilizamos Pipeline as Code.

Arquivo:

Jenkinsfile

Exemplo simplificado:

pipeline {

    agent any

    stages {

        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }

        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }

        stage('Deploy') {
            steps {
                sh './deploy.sh'
            }
        }

    }

}

Esse arquivo também fica versionado no Git.

O Pipeline passa a fazer parte do projeto.


Parametrização: um Pipeline para vários cenários

Imagine quatro ambientes:

  • DEV

  • QA

  • HML

  • PRD

Você poderia criar quatro pipelines.

Ou criar apenas um.

Na execução o Jenkins pergunta:

Qual ambiente?

DEV

QA

HML

PRD

Isso é parametrização.

Também podemos solicitar:

  • número da versão

  • branch

  • Change Request

  • arquivo de entrada

  • descrição da implantação

Um único Pipeline atende dezenas de cenários.


Cron: automação baseada em tempo

Nem todo Build depende de commits.

Às vezes queremos executar tarefas periodicamente.

Por exemplo:

  • backup diário

  • limpeza semanal

  • geração de relatórios

  • sincronização de ambientes

O Jenkins utiliza a sintaxe CRON.

Exemplo:

0 2 * * *

Executa diariamente às duas da manhã.

Outro detalhe interessante é o uso da letra H, exclusiva do Jenkins.

Ela distribui automaticamente os horários dos Jobs, evitando que centenas de pipelines iniciem exatamente no mesmo minuto.


Controller e Agents

As versões antigas utilizavam os termos Master e Slave.

Hoje a nomenclatura oficial é:

  • Controller

  • Agent

O Controller coordena.

Os Agents trabalham.

Imagine um restaurante.

O gerente organiza os pedidos.

Os cozinheiros preparam os pratos.

O gerente não cozinha.

Da mesma forma, o Controller distribui tarefas para diversos Agents.


Por que vários Agents?

Suponha três Builds de 30 minutos.

Sem Agents:

Build A

↓

Build B

↓

Build C

Tempo total:

90 minutos.

Com três Agents:

Todos executam simultaneamente.

Tempo aproximado:

30 minutos.

Essa é a base da escalabilidade.


Labels: enviando o trabalho para a máquina certa

Nem todos os servidores possuem as mesmas ferramentas.

Podemos ter:

  • Linux

  • Windows

  • Docker

  • Kubernetes

  • IBM Z

  • Java

  • .NET

  • COBOL

Os Labels funcionam como etiquetas.

linux

docker

java

ibmz

cobol

Quando o Pipeline precisa compilar COBOL:

agent {
    label 'ibmz'
}

O Jenkins envia automaticamente o trabalho ao Agent correto.


Credenciais: segurança em primeiro lugar

Jamais coloque senhas dentro do Jenkinsfile.

O Jenkins possui um cofre chamado Credentials Store.

Nele podemos armazenar:

  • usuários

  • senhas

  • tokens GitHub

  • chaves SSH

  • certificados

  • chaves privadas

O Pipeline acessa essas informações de forma segura, sem expô-las no código.


Workspaces

Cada execução recebe um diretório exclusivo.

Nele ficam:

  • código baixado do Git

  • arquivos temporários

  • artefatos

  • logs

  • resultados de testes

Ao final da execução o Workspace pode ser limpo automaticamente.

Isso evita conflitos entre Builds.


Plugins: o verdadeiro poder do Jenkins

O Jenkins possui milhares de plugins.

Entre os mais conhecidos estão:

  • Git

  • GitHub

  • Docker

  • Kubernetes

  • SonarQube

  • Slack

  • Teams

  • Ansible

  • Terraform

  • Artifactory

  • Nexus

  • Blue Ocean

  • Pipeline Utility Steps

Essa arquitetura modular explica sua enorme popularidade.


Jenkins e Containers

Hoje muitos Builds acontecem dentro de containers Docker.

Cada execução recebe um ambiente completamente limpo.

Terminou?

O container é destruído.

Isso elimina problemas do tipo:

"Na minha máquina funciona."


Jenkins e Kubernetes

A evolução natural foi integrar o Jenkins ao Kubernetes.

Quando um Build começa:

  • um Pod é criado;

  • o Pipeline executa;

  • o Pod é removido.

O ambiente sempre inicia do zero.

É altamente escalável.


Jenkins no IBM Mainframe

Aqui começa a parte que mais interessa ao Programador COBOL Padawan.

Muitas pessoas acreditam que Jenkins serve apenas para aplicações Java.

Nada poderia estar mais distante da realidade.

Hoje o Jenkins integra perfeitamente o universo IBM Z.

Um Pipeline moderno pode executar:

Git Push

↓

Webhook

↓

Jenkins

↓

Zowe CLI

↓

Upload do Programa COBOL

↓

Compilação

↓

Link-Edit

↓

DB2 BIND

↓

Execução do ZUnit

↓

Análise SonarQube

↓

Deploy para CICS

↓

Smoke Test

↓

Atualização do Endevor

↓

Notificação

Perceba.

O Jenkins não substitui o Mainframe.

Ele conversa com o Mainframe.


DevOps não elimina o Mainframe

Existe um mito de que DevOps pertence apenas ao mundo Linux.

Na realidade, DevOps é uma cultura.

Ela pode ser aplicada em qualquer plataforma.

Inclusive no IBM Z.

Hoje encontramos pipelines automatizando:

  • COBOL

  • PL/I

  • Assembler

  • JCL

  • DB2

  • IMS

  • CICS

  • MQ

  • z/OS Connect

Tudo integrado ao GitHub, GitLab e Azure DevOps.


Inteligência Artificial e Jenkins

Estamos entrando em uma nova fase.

Os modelos de IA auxiliam na geração de código, revisão automática, documentação e testes.

Mas alguém ainda precisa orquestrar todo o processo.

É aí que o Jenkins continua relevante.

Imagine um Pipeline moderno:

Commit

↓

IA revisa Pull Request

↓

Build

↓

Testes

↓

SonarQube

↓

Análise de Segurança

↓

Deploy

↓

Observabilidade

↓

Feedback para IA

A automação não desaparece.

Ela apenas incorpora novas ferramentas.


Conclusão

Quando começamos a estudar Jenkins, é comum enxergá-lo apenas como uma tela com um botão chamado Build Now.

Depois descobrimos os Pipelines.

Mais tarde aprendemos sobre WebHooks, Agents, Labels, Credenciais, Containers, Kubernetes e DevOps.

Finalmente percebemos algo muito maior.

O Jenkins não é apenas uma ferramenta.

Ele é uma plataforma de orquestração da engenharia de software.

Para um Programador COBOL Padawan, compreender esse ecossistema significa deixar de pensar apenas na compilação de programas e começar a enxergar o ciclo completo de vida das aplicações.

O futuro do IBM Mainframe não está em competir com as tecnologias modernas, mas em integrá-las. Git, Jenkins, Zowe CLI, Ansible, APIs REST, testes automatizados, observabilidade e Inteligência Artificial já fazem parte da realidade dos ambientes corporativos que executam aplicações críticas sobre IBM Z.

Dominar Jenkins é compreender que escrever código é apenas o começo. A verdadeira engenharia acontece quando conseguimos transformar esse código em software confiável, testado, rastreável, seguro e entregue continuamente aos usuários. E é justamente nesse ponto que o Jenkins deixa de ser um simples servidor de Build para se tornar o maestro que coordena toda a sinfonia da entrega contínua, conectando o legado robusto do Mainframe às práticas mais modernas da Engenharia de Software.

terça-feira, 18 de fevereiro de 2020

☕🔥🔄💣 HIGURASHI NO NAKU KORO NI GOU — O DIA EM QUE O AMBIENTE HOMOLOGADO VOLTOU A DAR ABEND E NINGUÉM ENTENDEU O PORQUÊ

 

Bellacosa Mainframe exibe higurashi no naku koro ni gou

☕🔥🔄💣 HIGURASHI NO NAKU KORO NI GOU — O DIA EM QUE O AMBIENTE HOMOLOGADO VOLTOU A DAR ABEND E NINGUÉM ENTENDEU O PORQUÊ

"O sistema estava estável. O incidente havia sido encerrado. O relatório final foi arquivado. Então alguém apertou RESET."


Dados Técnicos

Título Original: ひぐらしのなく頃に業 (Higurashi no Naku Koro ni Gou)

Título Internacional: Higurashi: When They Cry – Gou

Autor Original: Ryukishi07

Obra Base: Franquia Higurashi no Naku Koro ni

Estúdio: Passione

Direção: Keiichiro Kawaguchi

Roteiro Supervisionado por: Ryukishi07

Exibição Original: Outubro de 2020 a Março de 2021

Quantidade de Episódios: 24


Gênero

  • Terror Psicológico

  • Mistério

  • Horror

  • Suspense

  • Thriller

  • Drama

  • Sobrenatural

  • Ficção Temporal


Classificação Indicativa

18 anos

Contém:

  • Violência extrema

  • Automutilação

  • Assassinatos gráficos

  • Trauma psicológico

  • Tortura

  • Conteúdo perturbador

É provavelmente a entrada mais brutal da franquia até então.


O Maior Engano da História de Higurashi

Quando Gou foi anunciado, praticamente todo mundo acreditou que fosse:

REMAKE = TRUE

Inclusive muitos veículos de mídia.

Inclusive muitos fãs antigos.

Inclusive espectadores novos.

Mas Ryukishi07 preparava uma armadilha narrativa monumental.

Após alguns episódios descobrimos a verdade:

REMAKE = FALSE

SEQUÊNCIA = TRUE

Gou não reinicia a franquia.

Ele continua a história.

E essa revelação mudou completamente a percepção da obra.


Sinopse

Keiichi Maebara chega novamente a Hinamizawa.

As mesmas amigas.

A mesma vila.

O mesmo festival.

Os mesmos eventos aparentemente familiares.

Tudo parece seguir exatamente o roteiro de 2006.

Mas pequenos detalhes começam a divergir.

Algumas escolhas mudam.

Alguns personagens agem de forma diferente.

Algumas tragédias ocorrem em momentos inesperados.

E rapidamente fica claro:

algo está corrompendo a linha temporal novamente.


Resumo da História

Ao estilo Bellacosa Mainframe:

Imagine que um sistema passou anos sofrendo falhas.

Após centenas de correções, finalmente estabilizou.

Os operadores comemoraram.

Os relatórios foram encerrados.

Então um novo incidente surge.

Mas desta vez o erro não vem do código antigo.

O erro vem de uma modificação feita depois da correção.

PRODUÇÃO = ESTÁVEL

PATCH NOVO INSTALADO

ABEND RETORNOU

É exatamente isso que Gou representa.


O Que Tem de Diferente?

Tudo.

E essa é a genialidade.

Inicialmente parece nostalgia.

Mas logo vira desconforto.

O espectador veterano percebe que conhece os eventos.

Mas os eventos não obedecem mais às regras conhecidas.

A sensação é semelhante a executar um programa antigo e descobrir que alguém alterou linhas críticas do código sem documentar nada.


O Retorno de Hinamizawa

Visualmente, Gou moderniza completamente a franquia.

O Studio Passione entrega:

  • animação mais fluida

  • cenários detalhados

  • direção mais cinematográfica

  • iluminação moderna

  • cenas de horror muito mais impactantes

A pequena vila nunca pareceu tão bonita.

Nem tão assustadora.


Principais Personagens

Keiichi Maebara

Retorna como principal ponto de vista.

Mas agora existe uma sensação constante de que algo está fora do lugar.


Rena Ryugu

Continua sendo uma das figuras mais imprevisíveis da franquia.

Em Gou ganha novas interpretações.


Mion Sonozaki

Recebe momentos extremamente importantes para os fãs antigos.


Shion Sonozaki

Continua sendo uma peça fundamental dos mistérios.


Satoko Houjou

A personagem que redefine completamente a série.

Sem exagero.

Sem spoilers.

Gou transforma Satoko de forma tão radical que altera toda a percepção da franquia clássica.


Rika Furude

Após finalmente escapar do inferno...

descobre que talvez o inferno não tenha terminado.


A Verdadeira Protagonista

Uma das maiores surpresas da obra.

Durante anos acreditávamos que a história de Higurashi era sobre Rika.

Gou questiona essa ideia.

A série começa a deslocar o foco para outra personagem.

E essa mudança é responsável por algumas das discussões mais intensas da comunidade.


Temáticas Profundas

Obsessão

O tema dominante de Gou.

Mais do que medo.

Mais do que destino.

Mais do que sobrevivência.

A obsessão torna-se o motor da tragédia.


Dependência Emocional

A série explora relações que ultrapassam os limites da amizade saudável.


Mudança

Nem todos conseguem aceitar que as pessoas cresçam.

Nem todos conseguem aceitar despedidas.


Livre Arbítrio

Até onde alguém pode ir para impedir o futuro?


Egoísmo Disfarçado de Amor

Talvez o tema mais perturbador da série.


As Aventuras

Diferentemente de Kai, onde a missão era salvar Hinamizawa...

Gou transforma a narrativa em uma investigação sobre quem está sabotando a nova realidade.

Cada arco funciona como:

INCIDENTE NOVO

ANALISAR LOGS

ISOLAR VARIÁVEIS

LOCALIZAR RESPONSÁVEL

O espectador torna-se novamente um analista de problemas.


As Mensagens Ocultas

Amar Não É Possuir

Uma das mensagens centrais.

Muitas tragédias surgem quando afeto transforma-se em controle.


O Passado Não Pode Ser Prisão

A série questiona a dificuldade humana de seguir em frente.


Crescer Significa Aceitar Mudanças

Nem todos os relacionamentos permanecem iguais para sempre.


A Felicidade Individual Importa

Um dos debates mais importantes da obra.

Até onde alguém deve sacrificar sua felicidade pelos outros?


O Impacto Cultural

Gou explodiu a internet.

Os fóruns ficaram em estado de guerra.

As teorias multiplicaram-se.

A comunidade passou meses tentando descobrir o que realmente estava acontecendo.

A obra revitalizou completamente a franquia.

Uma nova geração descobriu Higurashi.

Veteranos voltaram a discutir a série.

Poucos retornos foram tão bem-sucedidos.


Houve Censura?

Sim.

E muita.

A violência gráfica de Gou é significativamente superior à da série de 2006.

Diversas transmissões utilizaram:

  • escurecimento de cenas

  • redução de detalhes

  • filtros visuais

  • cortes internacionais

Alguns episódios ficaram famosos justamente pelas diferenças entre as versões televisiva e Blu-ray.


A Grande Jogada de Ryukishi07

O autor executou uma manobra brilhante.

Ele usou a nostalgia como isca.

Fez os fãs acreditarem que estavam retornando a uma história conhecida.

E então revelou que estavam entrando em um novo pesadelo.

É uma das maiores pegadinhas narrativas da história dos animes.


Veredito Bellacosa Mainframe

Se Higurashi foi o incidente.

Se Kai foi a correção.

Se Rei foi a auditoria final.

Então Gou é o chamado inesperado às três da manhã.

ALERTA CRÍTICO

SISTEMA ESTÁVEL APRESENTOU FALHA

CAUSA DESCONHECIDA

SEVERIDADE = MÁXIMA

E o mais assustador?

O erro não veio do sistema.

Veio de alguém que não conseguia aceitar que o sistema tivesse sido corrigido.

☕🔥🔄💣 Nota Bellacosa Mainframe: 10/10 chamados críticos abertos após o encerramento do incidente.

Status do Ambiente:

HINAMIZAWA.EXE

LOOP DETECTADO NOVAMENTE

ORIGEM DO PROBLEMA:
NÃO IDENTIFICADA

INVESTIGAÇÃO EM ANDAMENTO

E quando você acredita que finalmente entendeu Higurashi...

Gou mostra que o verdadeiro dump ainda nem começou. 🌾🩸🔥🔄💣


segunda-feira, 17 de fevereiro de 2020

🔥💣 REXX + CICS: O “CENTRO DE COMANDO SECRETO” DO z/OS — 30 LABORATÓRIOS PRÁTICOS QUE TRANSFORMAM UM ANALISTA DE PRODUÇÃO EM UM MESTRE DA AUTOMAÇÃO MAINFRAME 💣🔥

 

Bellacosa Mainframe laboratorio pratico REXX e CICS

🔥💣 REXX + CICS: O “CENTRO DE COMANDO SECRETO” DO z/OS — 30 LABORATÓRIOS PRÁTICOS QUE TRANSFORMAM UM ANALISTA DE PRODUÇÃO EM UM MESTRE DA AUTOMAÇÃO MAINFRAME 💣🔥

☕ Introdução

Existe um momento na carreira de todo Analista de Produção Senior em Mainframe em que ele percebe uma verdade brutal:

“Quem domina automação no CICS deixa de apagar incêndio… e começa a controlar o incêndio antes dele nascer.”

E é exatamente aqui que entra o velho — porém absurdamente poderoso — REXX.

Enquanto muita gente ainda usa REXX apenas para pequenos scripts no TSO, os veteranos sabem:

🔥 REXX consegue:

  • conversar com CICS
  • operar consoles
  • controlar filas
  • monitorar transações
  • automatizar recovery
  • analisar dumps
  • integrar SDSF
  • conversar com DB2
  • chamar APIs
  • acionar comandos MVS
  • gerar alertas inteligentes

Tudo isso com poucas linhas.

Este laboratório foi pensado para:

  • Analistas de Produção Senior
  • Operadores avançados
  • Especialistas z/OS
  • Equipes de automação
  • Times de observabilidade mainframe

🚀 Estrutura do Laboratório

Cada caso possui:

✅ Objetivo
✅ Cenário real
✅ Passo a passo
✅ Código exemplo
✅ Dicas de produção
✅ Curiosidades Bellacosa Mainframe
✅ Solução operacional


🔥 LAB 01 — Consultando Status de Região CICS

🎯 Objetivo

Automatizar consulta de status da região CICS.


☕ Cenário Real

O operador precisa verificar:

  • se a região está ativa
  • número de tasks
  • uso de CPU
  • mensagens de erro

🚀 Passo a Passo

1. Criar EXEC REXX

ADDRESS SDSF

"ISFEXEC ST"

DO IX = 1 TO JNAME.0

IF POS("CICS", JNAME.IX) > 0 THEN
SAY JNAME.IX STATUS.IX

END

🔥 Resultado Esperado

CICSA ACTIVE
CICSB ACTIVE

💡 Dica Senior

Nunca dependa apenas de:

  • ping
  • VTAM
  • TCP/IP

Uma região pode responder rede e estar:

  • hung
  • loopando
  • sem dispatcher

☕ Curiosidade

Grandes bancos possuem robôs REXX monitorando CICS desde os anos 90.

Muita automação “moderna” apenas reinventou isso.


🔥 LAB 02 — Derrubando Transações Presas

🎯 Objetivo

Cancelar transações em loop.


🚀 Comando CICS

CEMT SET TASK(12345) PURGE

🚀 Automação REXX

ADDRESS TSO

TASK = 12345

CMD = "F CICSPROD,CEMT SET TASK("TASK") PURGE"

"CONSOLE "CMD

💡 Dica Senior

Sempre validar:

  • tempo de execução
  • CPU
  • enqueue
  • wait type

antes de purgar.


🔥 LAB 03 — Monitorando Número de Tasks

ADDRESS SDSF

"ISFEXEC ST"

TOTAL = 0

DO I = 1 TO JNAME.0

IF POS("CICS",JNAME.I) > 0 THEN
TOTAL = TOTAL + 1

END

SAY "REGIOES CICS:",TOTAL

🔥 LAB 04 — Detectando Região Travada

🎯 Estratégia

Comparar:

  • CPU baixa
  • tasks altas
  • ausência de logs

🚀 Exemplo

IF CPU < 1 & TASKS > 500 THEN
SAY "POSSIVEL HANG"

🔥 LAB 05 — Automatizando CEMT INQ TASK

ADDRESS TSO

"CONSOLE F CICSPROD,CEMT INQ TASK"

🔥 LAB 06 — Restart Automático de Região CICS

🚨 Cenário

Região caiu inesperadamente.


🚀 Fluxo

  1. Detecta DOWN
  2. Verifica horário permitido
  3. Sobe região
  4. Valida startup
  5. Gera alerta

🚀 Exemplo

"START CICSPRD"

🔥 LAB 07 — Verificando SOS (Short On Storage)

IF POS("SOS",MSG) > 0 THEN
SAY "ALERTA CRITICO"

🔥 LAB 08 — Ler JESMSGLG Automaticamente

ADDRESS SDSF
"ISFEXEC ST"

SAY "LENDO JESMSGLG..."

🔥 LAB 09 — Detectar Abend AEI9

IF POS("AEI9",LINHA) > 0 THEN
SAY "TRANSACAO INVALIDA"

🔥 LAB 10 — Automação de CEDF

🎯 Objetivo

Automatizar tracing de transações.


"CONSOLE F CICSPROD,CEDF TRANS(PGMA)"

🔥 LAB 11 — Monitor de Deadlocks

IF POS("DEADLOCK",MSG) > 0 THEN
SAY "DB2 DEADLOCK DETECTADO"

🔥 LAB 12 — Captura Automática de Dumps

"CONSOLE DUMP COMM=(CICSABEND)"

🔥 LAB 13 — Monitorando VSAM Locks

IF POS("ENQUEUE",MSG) > 0 THEN
SAY "LOCK VSAM"

🔥 LAB 14 — Robô de Health Check CICS

Checklist

✅ Tasks
✅ Storage
✅ CPU
✅ MQ
✅ DB2
✅ VTAM


🔥 LAB 15 — Integração REXX + SDSF + CICS

ADDRESS SDSF
"ISFEXEC DA"

🔥 LAB 16 — Restart Inteligente Pós-Abend

Estratégia

Nunca restartar:

  • em loop
  • acima de X falhas
  • fora da janela

🔥 LAB 17 — Monitorando Transações Long Running

IF TEMPO > 300 THEN
SAY "TRANSACAO SUSPEITA"

🔥 LAB 18 — Gerando Alertas Operacionais

SAY "ENVIANDO ALERTA PARA NOC"

🔥 LAB 19 — Detectando Storage Violation

IF POS("ASRA",MSG) > 0 THEN
SAY "POSSIVEL STORAGE VIOLATION"

🔥 LAB 20 — Operando CICS Pelo Console MVS

"CONSOLE F CICSPROD,CEMT INQ SYS"

🔥 LAB 21 — Monitorando MQ no CICS

IF POS("MQ",MSG) > 0 THEN
SAY "MQ ISSUE"

🔥 LAB 22 — Auditoria de Comandos Operacionais

QUEUE USERID DATE TIME CMD

🔥 LAB 23 — Detectando Loops de CPU

IF CPU > 90 THEN
SAY "LOOP CPU"

🔥 LAB 24 — Shutdown Controlado

"CONSOLE F CICSPROD,CEMT P SHUT"

🔥 LAB 25 — Coleta Automática de Estatísticas

SAY "GERANDO RELATORIO"

🔥 LAB 26 — Integração com DB2

ADDRESS DSNREXX

🔥 LAB 27 — Automação de Recovery

Fluxo

  1. Detecta erro
  2. Coleta dump
  3. Reinicia recurso
  4. Valida aplicação

🔥 LAB 28 — Detectando Flood de Tasks

IF TASKS > 5000 THEN
SAY "FLOOD DETECTADO"

🔥 LAB 29 — Operação Multi-CICS

DO FOREVER

Monitorando dezenas de regiões simultaneamente.


🔥 LAB 30 — Central de Automação Mainframe

🎯 Objetivo Final

Construir:

  • console inteligente
  • monitor operacional
  • auto recovery
  • observabilidade
  • automação enterprise

Tudo em REXX.


🚀 Arquitetura Recomendada

REXX
├── SDSF
├── CONSOLE
├── CICS
├── DB2
├── MQ
├── JES2
├── VTAM
└── SYSLOG

☕ Dicas de Ouro de Produção Senior

🔥 Nunca automatize sem rollback

Toda automação precisa:

  • validação
  • fallback
  • retry
  • logging
  • auditoria

🔥 REXX pode derrubar um banco inteiro

Um EXEC mal feito:

  • purga task errada
  • derruba região
  • gera storm de comandos

Produção não perdoa.


🔥 Monitore antes de agir

Senior não automatiza “ação”.

Senior automatiza:

  • decisão
  • contexto
  • diagnóstico

💣 Curiosidades Bellacosa Mainframe

☕ O REXX virou “DevOps” antes do DevOps existir

Muito antes de:

  • Ansible
  • Terraform
  • Kubernetes
  • Jenkins

o mainframe já fazia:

  • automação
  • self-healing
  • orchestration
  • monitoramento inteligente

com:

  • REXX
  • NetView
  • OPS/MVS
  • System Automation

🚀 Missão Final do Curso

Ao terminar estes 30 laboratórios você será capaz de:

✅ Automatizar CICS
✅ Criar robôs operacionais
✅ Detectar incidentes automaticamente
✅ Fazer self-healing
✅ Integrar múltiplos subsistemas
✅ Construir observabilidade real no z/OS
✅ Reduzir MTTR
✅ Operar ambientes enterprise críticos


🔥 Frase Final Bellacosa Mainframe

“No mundo distribuído o operador reage ao problema.

No Mainframe automatizado o problema já foi resolvido antes do telefone tocar.” 🚀☕

 

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