sexta-feira, 11 de janeiro de 2013

O PODER DE UMA PINTURA

 


O PODER DE UMA PINTURA
Crônica ao estilo Bellacosa Mainframe
Para o El Jefe Midnight Lunch


Existem casas que não são casas.
São repositórios de memória, versões ancestrais do nosso data lake afetivo.
E a casa dos seus bisavós Paco e Isabel — o Francisco e a eterna vó Bel — era exatamente isso:
um sistema vivo, cheio de charme, cheiro, sons e pequenos tesouros espalhados como easter eggs para qualquer criança curiosa.

Mas havia ali um elemento que ultrapassava o simples conceito de “decoração”.
Uma peça que fazia load direto na alma de todo bisneto que passava pelo corredor.

Uma pintura.
Um mural.

E não qualquer mural.




O Banco de Ônibus e o Laboratório do Pequeno Doutor

Antes de chegar ao mural, era preciso atravessar cenários icônicos do universo Bellacosa.

Na área, um velho banco de ônibus — presente do seu pai aos bisavós — havia sido promovido do transporte coletivo ao trono afetivo.

Era nele que as crianças sentavam para conversar, brincar, imaginar, disputar espaço…
Uma espécie de console central da infantaria da família.

Seguindo um corredor lateral, que saia do lado de uma mureta daquelas com piso cerâmico e coluninhas, ao lado um portão de ferro que guiava até o fundo do quintal onde ficava o quartinho externo, cheio de ferramentas, sucatas, parafusos e relíquias mecânicas.
Ali nascia o Pequeno Doutor Vagner, cientista-mirim, desmontador compulsivo, capaz de abrir um rádio com a mesma determinação de um engenheiro do CICS tentando entender um ABEND 0C7.

Havia ainda o canteiro da horta, guardado pelo lendário jaboti, um Highlander, sobrevivente de guerras, gerações e intempéries — provavelmente imortal, silencioso e sábio como as máquinas Z da IBM.

E, claro, a garagem na frente da casa coberta: o playground oficial de dias de chuva, onde as aventuras ganhavam eco, velocidade e imaginação.

Mas nada — absolutamente nada — se comparava ao que havia na varanda.




A PINTURA QUE ABRIA PORTAIS

Na parede, pintado por um amigo da família, havia um mural que poderia, tranquilamente, ter sido catalogado pela UNESCO como Patrimônio Imaterial da Infância Brasileira.

Um pôr do sol magnífico.
Quase dourado, quase mágico.
Aquela luz que não existe mais, que só os anos 70 sabiam produzir.

E nele, caminhando para a esquerda, um surfista.
Magro, forte, despreocupado.
Segurando uma prancha enorme.
Rumo ao infinito.

As crianças da família paravam diante daquela pintura como quem para diante de uma tela de login de um universo paralelo ou mesmo sentadas no banco de ônibus, olhavam para ela.

Ali, cada bisneto se imaginava o surfista:

  • correndo pela areia;

  • enfrentando ondas gigantes;

  • vivendo aventuras tropicais totalmente incompatíveis com a vida urbana da Mooca ou de Taubaté.

O mural era mais do que tinta.
Era um motor gráfico da imaginação.
Um gateway afetivo que alimentava sonhos, coragem e fantasia.

Era ali que o futuro adulto começava a ser desenhado — sem que ninguém percebesse.




Os Quitutes, os Vidrinhos e o Arroz com Ovo

E enquanto a arte nos transportava, a casa nos ancorava.

Tia Maria servia bolinhos de chuva tão divinos que mereciam IPL especial só pra carregar o cheiro.
Os vidrinhos vazios de remédio viravam frascos de laboratório dos pequenos cientistas.
E o arroz com ovo frito mole — aquele clássico absoluto — possuía algum tipo de opcode sagrado que registrava memória afetiva até o fim da vida.

Sem falar nos iogurtes caseiros, aqueles feitos com bacilos vivos, guardados em potes reciclados da geladeira, cuidadosamente produzidos como se fossem uma batch job culinária passada de geração a geração.

Era amor.
Simples.
Caseiro.
Imenso.
Do tipo que dura décadas, como as máquinas Z, como as histórias bem contadas, como os avós que moldam nosso código-fonte sem dizer uma palavra.


O Poder de uma Pintura

Hoje, olhando para trás, fica claro:

Aquele mural não era só um mural.
Era um servidor emocional.

Cada criança que parava ali fazia um login diferente:
um queria ser surfista, outro guerreiro, outro aventureiro.
Mas todos, absolutamente todos, saíam da varanda com o coração mais leve.

Porque o poder da arte é esse:
ela cria mundos dentro da gente.
E quando isso acontece na casa de avós amorosos, acompanhada de café, cheiro de chuva e iogurte caseiro…
o mundo inteiro fica melhor.

Aquela pintura não era apenas tinta na parede.
Era um lembrete silencioso de que a infância foi boa,
foi rica,
foi cheia de brilho,
de sonhos
e de amor.

E esse tipo de lembrança — ah, meu amigo —
é do tipo que nem o tempo, nem a vida, nem os tombos…
conseguem apagar.

segunda-feira, 7 de janeiro de 2013

⌨️🖥️ TSO no IBM Mainframe

 



⌨️🖥️ TSO no IBM Mainframe

O ponto de ignição do z/OS (ao estilo Bellacosa Mainframe)

“Se o z/OS é o motor do mainframe,
o TSO é a chave que gira e faz tudo ganhar vida.”

Quem está chegando agora ao mundo IBM Mainframe costuma ouvir três siglas logo no primeiro dia:
TSO, ISPF e JCL.
E quase sempre explicam o TSO assim:

“É tipo um terminal.”

Errado? Não.
Completo? Nem de longe.

Vamos colocar ordem na casa.


🧠 O que é TSO, de verdade?

TSO significa Time Sharing Option.

Em bom português mainframeiro:

TSO é o ambiente interativo que permite ao usuário conversar diretamente com o z/OS em tempo real.

Sem TSO:

  • Não tem login interativo

  • Não tem edição de datasets

  • Não tem teste rápido de programa

  • Não tem vida para desenvolvedor ou operador

É o primeiro contato humano com o sistema.


🕰️ Um pouco de história (porque tudo no mainframe tem história)

Lá atrás, nos primórdios do mainframe:

  • Tudo era batch

  • Cartão perfurado

  • Resultado só horas depois

A IBM percebeu que:

“Desenvolver assim é lento, caro e improdutivo.”

Nasce então o Time Sharing:

  • Vários usuários

  • Compartilhando CPU, memória e I/O

  • Cada um com a ilusão de exclusividade

👉 TSO foi revolucionário
Ele trouxe interatividade para um mundo 100% batch.


🧑‍💻 TSO é o “terminal” do mainframe?

Sim… mas com esteróides corporativos.

Comparação honesta:

AmbienteEquivalente
WindowsCommand Prompt / PowerShell
LinuxTerminal / Shell
MainframeTSO

Mas o TSO:

  • Controla segurança corporativa

  • Gerencia milhares de sessões

  • Impõe limites de recurso

  • Audita tudo

Nada de terminalzinho anárquico.


🔐 O que você faz com TSO no dia a dia

Com TSO, você pode:

✅ Logar no mainframe com User ID e senha
✅ Executar comandos em tempo real
✅ Criar, editar e apagar datasets
✅ Compilar e testar programas
✅ Submeter jobs batch
✅ Acompanhar execução
✅ Automatizar tarefas com REXX

Sem TSO:

Você estaria programando em 1970.


🗂️ TSO e o mundo real do desenvolvimento

TSO é o alicerce invisível de tudo que você faz:

  • ISPF roda em cima do TSO

  • SDSF depende do TSO

  • Edição de código depende do TSO

  • Debug interativo depende do TSO

👉 Quando alguém diz:

“Eu trabalho no ISPF”

Na prática:

Está trabalhando no TSO, só que com interface bonita.


🧱 TSO não é só conveniência — é controle

Em ambientes corporativos:

  • Milhares de usuários conectados

  • Cada um com limites de CPU

  • Prioridades diferentes

  • Auditoria rígida

O TSO:

  • Controla sessões

  • Limita consumo

  • Garante justiça no uso de recursos

  • Protege o sistema

Sem isso:

Um estagiário com loop errado derruba o banco.


🧪 Curiosidades que padawan precisa saber

🟡 TSO não é leve
Cada sessão consome recursos — por isso existe controle.

🟡 TSO mal usado custa MIPS
Loop infinito em REXX? CPU chora.

🟡 Batch pesado não é para TSO
TSO é para interação, não para processamento massivo.

🟡 Ambiente produtivo ≠ playground
TSO em produção é privilégio, não direito.


🥚 Easter-eggs do mundo TSO

  • O famoso comando TSO ISPF é quase um mantra

  • Muitos veteranos ainda digitam comandos sem olhar

  • Todo mundo já derrubou sessão com comando errado

  • Quem nunca travou TSO com REXX… mente


⚠️ Erros clássicos de padawan

❌ Usar TSO para rodar processamento pesado
❌ Editar dataset produtivo sem backup
❌ Testar código direto em produção
❌ Não entender que cada comando consome recurso

Dica Bellacosa:

“TSO é bisturi, não marreta.”


🚀 Por que TSO ainda é essencial em 2026?

Mesmo com:

  • DevOps

  • Git

  • APIs

  • Containers

  • Cloud híbrida

👉 O TSO continua sendo:

  • Porta de entrada

  • Ferramenta de diagnóstico

  • Ambiente de emergência

  • Base do desenvolvimento mainframe

Quando tudo falha…

É no TSO que você entra para salvar o dia.


☕ Palavra final do El Jefe

O mainframe não começa no COBOL.
Não começa no JCL.
Não começa no DB2.

Ele começa no TSO.

Se o z/OS é o motor,
se o hardware é o chassi,
👉 TSO é a ignição.

Sem ele, nada liga.
Com ele, o mainframe vive.

domingo, 6 de janeiro de 2013

SMP/E for z/OS Workshop – O que é e para que serve?

 


SMP/E for z/OS Workshop – O que é e para que serve

1. O que é SMP/E?

SMP/E significa System Modification Program/Extended.

  • É a ferramenta oficial da IBM para gerenciar correções, atualizações e modificações de software no IBM z/OS Mainframe.

  • Ele controla:

    • SYSMODs (System Modifications): PTFs, APARs, USERMODs

    • Aplicação e teste de patches sem quebrar o sistema

    • Gerenciamento de versões e dependências


Resumo rápido:
SMP/E é o controle de versão, patch e deployment para sistemas z/OS.

Sem SMP/E, atualizar o Mainframe era um pesadelo: você aplicava patch e… torcia para nada quebrar.


2. História e evolução

  • Criado nos anos 1980, quando o z/OS ainda era chamado MVS/XA.

  • Antes do SMP/E: sysprogs e operadores aplicavam correções manualmente, resultando em ABENDs e erros misteriosos.

  • SMP/E introduziu:

    • Controle de dependências entre SYSMODs

    • Capacidade de desfazer patches problemáticos (RESTORE)

    • Auditoria e rastreabilidade de modificações

Fofoquice histórica:

  • Nos primeiros dias, existia uma “tradição não oficial” de aplicar patches só às sextas-feiras, depois do expediente… mas ninguém documentava os passos. Isso virou lenda: “o patch de sexta-feira que ninguém lembra”. 😅


3. Casos de uso

  • Aplicar um PTF (Program Temporary Fix) sem derrubar aplicações críticas.

  • Testar correções em uma test library antes de ir para produção.

  • Restaurar versões anteriores se uma atualização causar problemas.

  • Gerenciar múltiplos ambientes: DEV, TEST, PROD, cada um com seu DLIB e SYSMODs.

Exemplo real de uso:

1. RECEIVE: trazer o PTF do IBM Service Repository 2. APPLY: aplicar o PTF na target library de teste 3. ACCEPT: promover a correção para produção 4. RESTORE: desfazer se algo der errado

4. Estrutura de SMP/E

  • DLIB (Distribution Library): onde ficam os SYSMODs recebidos

  • HOLD Library: para SYSMODs que precisam de aprovação ou teste

  • Target Library: onde o software efetivamente roda

Pensando como Bellacosa: a DLIB é o “armário secreto do sysprog”, HOLD é o “cofre do teste”, e a Target Library é “o palco principal do Mainframe”.


5. Easter-eggs e curiosidades

  • Alguns sysprogs antigos batizavam suas bibliotecas de SMP/E com nomes secretos, tipo “JEDI-DLIB”, “R2-D2-HOLD”.

  • Existe uma piada clássica no z/OS: “Se SMP/E aceitar, você está salvo; se não, bem-vindo ao ABEND-land”.

  • Comandos clássicos: RECEIVE, APPLY, ACCEPT, RESTORE → formam a linha da vida do SYSMOD.


6. Resumo Bellacosa

  • O que: Gerenciador de patches e correções para z/OS

  • Para que serve: Aplicar, testar, aceitar e restaurar modificações de software

  • Onde atua: DLIB, HOLD, Target Library

  • História: Criado nos anos 80 para controlar modificações de forma segura

  • Dicas fofoqueiras: Sexta-feira era o dia favorito para patches misteriosos

  • Easter-eggs: Bibliotecas secretas com nomes nerds, piadas internas de sysprog

sábado, 29 de dezembro de 2012

Itália 2012: quando o sistema entrou em degraded mode

 


Itália 2012: quando o sistema entrou em degraded mode

2012 foi o ano em que a Itália começou a piscar no painel. Nada explodiu de vez, mas o operador atento sabia: o sistema estava em degraded mode. A crise de 2008, que parecia um incident distante no início, seguia rodando como job fantasma, consumindo recursos, corroendo margens, destruindo planos silenciosamente.

Para quem vivia ali, não era estatística. Era cotidiano.

A Itália pós-crise: beleza com rachaduras

A Itália de 2012 continuava linda. A arquitetura intacta, o café impecável, o pôr do sol cinematográfico. Mas por trás da estética, a máquina rangia. O custo de vida subia como process runaway, enquanto os salários encolhiam sem aviso prévio. Contratos mais frágeis, menos estabilidade, mais improviso.

O país parecia viver de herança cultural enquanto vendia o futuro a prazo.

Para um imigrante, isso pesa dobrado. Sem rede de proteção real, qualquer oscilação vira ameaça existencial.

O grande giro que virou plano de contingência

Havia um plano. Sempre há. Um grande giro pelo sul da Itália — Napoles e Puglia — seguido de uma travessia simbólica para a Grécia indo até Atenas. Um fechamento de ciclo, quase ritualístico. Um graceful shutdown antes da próxima fase da vida.

Mas planos, como sistemas, dependem de orçamento, previsibilidade e energia emocional. E em 2012, tudo isso começou a faltar.

O giro virou planilha. A viagem virou simulação. O sonho entrou em standby.

A tristeza técnica de ver um projeto ruir

Não foi uma tristeza dramática. Foi pior: uma tristeza técnica. Aquela sensação de ver um projeto bem desenhado ser desmontado não por erro conceitual, mas por falta de recursos. Não falhou porque era ruim. Falhou porque o ambiente mudou.

Quem trabalha com sistemas entende: há falhas que não se corrigem com talento.

A Itália de 2012 ensinou isso com elegância cruel.

Inglaterra como next possible node

Foi nesse contexto que a Inglaterra entrou no radar. Não como paixão, mas como viabilidade. Mercado maior, idioma global, promessa de salários menos comprimidos. Londres aparecia como um novo nó possível no cluster europeu.

Vieram os estudos: custo de vida, aluguel, transporte, impostos, visto, empregabilidade. Tudo frio, calculado, quase clínico. Quando o sonho quebra, a sobrevivência assume o comando.

Mas até ali já se percebia: a Europa inteira estava mais cara e menos generosa.

Salários caindo, vida encarecendo

Em 2012, ficou claro que algo estrutural havia mudado. A equação clássica europeia — custo alto compensado por estabilidade e salário — começou a falhar. Os salários estagnaram ou caíram. O custo de vida seguiu subindo. A promessa implícita do projeto europeu começou a se desgastar.

A crise de 2008 não era mais evento. Era estado permanente.

E estados permanentes redefinem destinos.

O retorno ao Brasil entra no roadmap

Foi assim que o Brasil voltou ao roadmap. Não como derrota, mas como alternativa lógica. Um sistema conhecido, com falhas crônicas, mas onde ainda havia espaço para reconfiguração. Onde o custo de vida, apesar de tudo, parecia mais proporcional às possibilidades reais.

Retornar deixou de ser tabu. Virou cenário plausível.

O operador começa a aceitar que talvez seja hora de encerrar a sessão.

Epílogo: quando sonhos viram logs

2012 não foi o fim imediato. Foi o ano da aceitação. O ano em que se entende que a crise de 2008 não destruiu apenas bancos — destruiu trajetórias pessoais. Lentamente, educadamente, sem pedir desculpas.

A Itália continuava linda.
A Grécia ainda chamava no horizonte.
A Inglaterra piscava como opção racional.
O Brasil reaparecia como retorno possível.

Mas algo essencial havia mudado:
o sonho europeu deixara de ser infinito.

E todo operador veterano sabe:
quando um sistema começa a consumir mais do que entrega,
não é questão de paixão —
é questão de viabilidade.

2012 foi o ano em que o projeto começou a ruir.
Não com estrondo.
Mas com silêncio, planilhas e decisões adiadas.

E às vezes,
é assim que os grandes ciclos terminam.

domingo, 23 de dezembro de 2012

🖥️🍜 O personagem glutão no anime: o processo que consome tudo e nunca dá overflow

 


🖥️🍜 O personagem glutão no anime: o processo que consome tudo e nunca dá overflow


Bellacosa Mainframe Mode — antropologia otaku em batch

Se você assiste anime e nunca viu um personagem que come mais que o resto do elenco somado, algo está errado no sistema. O glutão não é acidente narrativo — ele é arquitetura cultural.

🧠 A razão estrutural (não é só comédia)

No Japão, comer muito e com prazer está ligado a vitalidade, energia vital (ki) e pureza de espírito. O personagem glutão geralmente:

  • é honesto

  • é direto

  • não esconde intenções

  • vive no presente

Ou seja: não tem processos ocultos rodando em background.

Para o Bellacosa mainframe, ele é o job que consome CPU demais, mas mantém o sistema vivo.

🍚 Função narrativa (o porquê de sempre existir)

  1. Alívio cômico — quebra tensão

  2. Indicador de poder — quem come muito, aguenta muito

  3. Contraponto moral — simples num mundo complexo

  4. Símbolo de humanidade — comer é o gesto mais básico

📌 Insight: personagens frios, calculistas e vilões quase nunca comem em cena. Comer é vulnerabilidade.

🥚 Easter eggs culturais

  • Em mangás antigos, o glutão era inspirado em monges errantes

  • Em shōnen, comer = recarregar barra de energia

  • Muitos autores usam o glutão como avatar do leitor

🤫 Fofoquice: vários mangakás admitem que criaram esses personagens porque esqueciam de comer enquanto desenhavam.

🎌 Exemplos clássicos (dump de memória)

  • Goku (Dragon Ball) — come como quem faz overclock no corpo

  • Luffy (One Piece) — carne = combustível ideológico

  • Naruto (Naruto) — ramen como trauma e conforto

  • Inosuke (Demon Slayer) — selvagem, instintivo

  • Charmy (Black Clover) — comida como magia

  • Akira Mado (Tokyo Ghoul) — inversão trágica do ato de comer

  • Gluttony (Fullmetal Alchemist) — versão corrompida do arquétipo

🧩 Filosofia oculta

O glutão representa um mundo onde tudo é escasso, controlado e burocrático. Ele diz, sem discurso:

“Enquanto eu puder comer, ainda estou vivo.”

🖥️ Comentário final Bellacosa
Em anime, o personagem guloso é o heartbeat do sistema. Ele parece desperdício, mas sem ele o mundo ficaria frio, calculista e vazio. Todo universo precisa de alguém que lembre o básico:
viver também é consumir, sentir e compartilhar.

MAINFRAME ESTÁVEL. TIGELA VAZIA. PRÓXIMA PORÇÃO EM LOAD. 🍜

terça-feira, 18 de dezembro de 2012

🔥 Como Criar uma Tela CICS BMS – Guia Definitivo Passo a Passo

 


🔥 Como Criar uma Tela CICS BMS – Guia Definitivo Passo a Passo



☕ Introdução — Antes do HTML, existia o BMS

Antes de React, Angular e CSS, o mainframe já fazia interface rica — só que com disciplina, regra e respeito ao terminal.

No mundo CICS, tela não é arte.
Tela é contrato, estado, performance e sobrevivência em produção.

Vamos do zero absoluto até a tela rodando, sem pular etapas.


🧱 Conceitos Fundamentais (Sem isso, tudo quebra)

📌 O que é BMS?

BMS (Basic Mapping Support) é a linguagem declarativa usada para definir telas CICS.

Ela descreve:

  • Campos

  • Posições

  • Atributos

  • Proteção

  • Entrada e saída de dados

📌 BMS não tem lógica.
Ele só descreve como a tela se comporta.


🧠 MAP vs MAPSET — A confusão clássica

ConceitoO que é
MAPSETConjunto de mapas (arquivo fonte BMS)
MAPUma tela individual dentro do MAPSET

📌 Analogia Bellacosa:

  • MAPSET = arquivo HTML

  • MAP = página individual

  • FIELD = input / label



🧭 Passo a Passo — Criando uma Tela CICS BMS


1️⃣ Criar o Fonte BMS (MAPSET)

Exemplo básico:

MAPSET01 DFHMSD TYPE=MAP,MODE=INOUT,LANG=COBOL,TERM=3270

Parâmetros importantes:

  • TYPE=MAP → indica que é um MAPSET

  • MODE=INOUT → entrada e saída

  • LANG=COBOL → gera copybook COBOL

  • TERM=3270 → terminal padrão

📌 Erro comum: esquecer LANG=COBOL → não gera copybook.


2️⃣ Definir um MAP (Tela)

MAP01 DFHMDI SIZE=(24,80),LINE=1,COLUMN=1

O que isso faz:

  • Cria uma tela de 24x80

  • Posiciona no canto superior

📌 Um MAPSET pode ter vários MAPs.


3️⃣ Definir Campos (DFHMDF)

Exemplo:

CAMPO1 DFHMDF POS=(5,10), LENGTH=10, ATTRB=(UNPROT,IC), INITIAL='Digite:'

Parâmetros essenciais:

ParâmetroFunção
POSLinha e coluna
LENGTHTamanho
ATTRBAtributos
INITIALTexto inicial

🎛️ Atributos Importantes (Onde mora o poder)

AtributoFunção
PROTCampo protegido
UNPROTCampo editável
ICCursor inicial
MDTCampo alterado
BRTBrilho
ASKIPPula o campo

📌 Erro clássico: esquecer MDT → CICS acha que o campo não mudou.


4️⃣ Finalizar o MAPSET

DFHMSD TYPE=FINAL END

📌 Sem isso, não compila.



⚙️ Workflow de Compilação (Onde muitos erram)

1️⃣ Fonte BMS
2️⃣ Assembler
3️⃣ Gera MAPSET (LOAD)
4️⃣ Gera COPYBOOK
5️⃣ COPYBOOK entra no programa COBOL
6️⃣ Programa SEND/RECEIVE MAP

📌 BMS não é compilado como COBOL.


🧪 Usando o MAP no Programa COBOL

Enviar a tela:

EXEC CICS SEND MAP('MAP01') MAPSET('MAPSET01') ERASE END-EXEC

Receber dados:

EXEC CICS RECEIVE MAP('MAP01') MAPSET('MAPSET01') END-EXEC

📌 O COPYBOOK gerado contém:

  • campos de entrada

  • campos de saída

  • indicadores MDT


🚀 Otimização — Dicas Bellacosa de Produção

✅ Boas práticas

  • Campos pequenos → menos tráfego

  • Use PROT para labels

  • Use UNPROT só onde necessário

  • Evite mapas gigantes

  • Reutilize MAPSETs

❌ Erros comuns

  • Um MAP por MAPSET sem necessidade

  • Tela cheia de campos UNPROT

  • Esquecer MDT

  • Misturar lógica com tela

  • Hardcode de posição no COBOL


🧠 Hierarquia Mental do BMS (Grave isso)

MAPSET ├── MAP │ ├── FIELD │ ├── FIELD │ └── FIELD

📌 Se você entende isso, não se perde mais.


🧯 Erros Clássicos em Produção

ProblemaCausa
Tela não apareceMAPSET não instalado
Campos vaziosMDT ausente
Cursor erradoIC mal posicionado
Dump AEIMMAP inexistente
Dados não chegamRECEIVE errado

🎓 Guia de Estudo Rápido

  1. Entenda MAPSET vs MAP

  2. Crie tela simples

  3. Compile e gere copybook

  4. Faça SEND

  5. Faça RECEIVE

  6. Trate MDT

  7. Otimize


💬 Comentário El Jefe Midnight Lunch

“Quem domina BMS, domina o ritmo do CICS.”


🏁 Conclusão Bellacosa

Tela CICS não é UI.
É contrato, estado e performance.

🔥 Quem respeita o BMS:

  • evita ABEND

  • entrega rápido

  • sobrevive em produção

segunda-feira, 17 de dezembro de 2012

😈🔥 Manual não oficial de sobrevivência do mainframer em times cloud

 


😈🔥 Manual não oficial de sobrevivência do mainframer em times cloud


Conhecimento básico sobre aplicações distribuídas para quem já viu produção cair em silêncio


☕ 08:59 — Daily começa, o risco também

Você entra no call.
Alguém diz:

“Hoje vamos subir direto em produção, é só um ajuste pequeno.”

Você, mainframer, já sente o cheiro de abend conceitual.

Este manual não é sobre tecnologia.
É sobre sobrevivência cultural e técnica em times cloud, sem perder sanidade — nem reputação.


1️⃣ Contexto histórico: por que você é estranho ali 🧬

O time cloud veio de:

  • Startups

  • Ambientes stateless

  • Deploy diário

  • “Se cair, a gente resolve”

Você veio de:

  • SLA

  • Batch noturno

  • Controle transacional

  • Auditoria

  • Multas

📌 Tradução Bellacosa:
Eles foram treinados para velocidade.
Você foi treinado para não errar.


2️⃣ Regra de ouro #1: nunca diga “no mainframe…” 🛑

Diga:

  • ❌ “No mainframe isso é melhor”

  • ✅ “Em ambientes críticos, isso costuma falhar por causa de…”

🔥 Comentário ácido:
Argumento técnico convence. Nostalgia não.


3️⃣ Falha parcial: o novo inimigo invisível 👻

No mainframe:

  • Caiu → caiu tudo → alguém resolve

No cloud:

  • Um serviço cai

  • Outro fica lento

  • Um terceiro responde errado

  • O sistema parece funcionar

😈 Easter egg traumático:
O erro mais caro é o que não quebra imediatamente.


4️⃣ Observabilidade: sem SMF, sem paz 📊

Se o time não sabe:

  • Qual serviço respondeu

  • Em quanto tempo

  • Com qual dependência

👉 Então não existe produção, só esperança.

📌 Frase para reuniões:
“Sem observabilidade, não é sistema — é aposta.”


5️⃣ Event-driven: MQ não perdoa 📨

Quando alguém diz:

“É só publicar o evento”

Pergunte:

  • É idempotente?

  • Tem reprocessamento?

  • E se duplicar?

  • E se perder?

🔥 Comentário Bellacosa:
Evento não é desculpa para perder controle.


6️⃣ Retry mal feito mata silenciosamente 🔁

Retry:

  • Sem backoff

  • Sem limite

  • Sem idempotência

= batch distribuído rodando para sempre

😈 Easter egg:
Retry é GO TO disfarçado.


7️⃣ Deploy contínuo ≠ deploy irresponsável 🚀

Explique:

  • Feature flag

  • Canary

  • Rollback real

  • Monitoramento pós-deploy

📌 Regra prática:
Quem não sabe voltar, não deveria ir.


8️⃣ Passo a passo de sobrevivência diária 🧭

1️⃣ Escute antes de julgar
2️⃣ Traduza buzzword para risco
3️⃣ Faça perguntas incômodas
4️⃣ Documente decisões
5️⃣ Peça métricas
6️⃣ Exija plano de rollback
7️⃣ Proteja produção como território sagrado


9️⃣ Curiosidades que só o mainframer percebe 👀

  • “Alta disponibilidade” virou feature

  • Logs são decorativos

  • Produção é confundida com staging

  • Ninguém pensa em auditoria

😈 Comentário realista:
Cloud ensinou muitos a programar.
Mainframe ensinou poucos a operar.


🔟 Guia de estudo para não virar o chato do time 📚

Conceitos

  • CAP Theorem

  • Resiliência

  • SRE

  • Observabilidade

  • Arquitetura híbrida

Ferramentas

  • APM (Instana, Dynatrace)

  • Message brokers

  • Feature flags

  • Chaos Engineering (com juízo)

📌 Dica final:
Estude o suficiente para liderar sem impor.


🎯 Aplicações práticas desse manual

  • Modernização de core

  • Integração mainframe-cloud

  • Arquitetura corporativa

  • Times de plataforma

  • Ambientes regulados


🖤 Epílogo — 23:58, produção ainda de pé

Você não está ali para atrasar o time.
Está ali para evitar que ele se autodestrua.

El Jefe Midnight Lunch assina:
“Quando o cloud falha, chamam o mainframer. Quando funciona, ninguém percebe.”