Translate

sábado, 29 de dezembro de 2012

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

 

Bellacosa Mainframe e uma visao do ano 2012 a vida na Italia

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

 

Bellacosa Mainframe e os personagens glutoes dos anime

🖥️🍜 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.”

domingo, 16 de dezembro de 2012

🖥️⚔️ Espadas japonesas: o mainframe de aço do Japão feudal



🖥️⚔️ Espadas japonesas: o mainframe de aço do Japão feudal

Bellacosa Mainframe Mode — El Jefe Midnight Lunch

Para o público mainframer, a espada japonesa não é arma: é sistema crítico monolítico, afinado ao extremo, sem interface gráfica, onde cada detalhe importa. A nihontō foi pensada para não falhar, porque quando falha… não há rollback.


🧠 Arquitetura básica (tipos por função)

Pense nelas como tiers de sistema:



🔹 Katana (60–73 cm)

O “IBM z/OS” das espadas. Equilíbrio perfeito entre corte, alcance e velocidade. Uso geral do samurai.




🔹 Wakizashi (30–60 cm)

Sistema auxiliar. Backup pessoal, combate em espaço fechado, ritual. Nunca fora do ar.



🔹 Tantō (até 30 cm)

Utilitário de precisão. Segurança pessoal, último recurso. Baixa latência.



🔹 Tachi (70–80 cm)

Versão antiga da katana, usada a cavalo. Otimizada para ataques descendentes.



🔹 Ōdachi / Nodachi (+90 cm)

Processamento pesado. Campo aberto. Difícil de manter, alto custo operacional.


📏 Classificação por tamanho (storage tiers)

  • Tantō: cache

  • Wakizashi: disco local

  • Katana: storage principal

  • Ōdachi: armazenamento externo — poderoso, mas complexo


🔥 Material e fabricação (hardware premium)

  • Tamahagane: aço obtido em forno tatara

  • Dobras múltiplas: remoção de impurezas = data cleansing

  • Têmpera diferencial (hamon): edge rápido + spine resiliente

📌 Insight Bellacosa: é um sistema hard real-time. Falha estrutural = morte.


🗺️ Principais centros de produção

  • Bizen (Okayama) — durabilidade e beleza

  • Yamashiro (Kyoto) — elegância, lâminas finas

  • Sōshū (Kamakura) — potência, lâminas agressivas

  • Mino (Gifu) — produção eficiente, padronização

🤫 Fofoquice: Mino era o “IBM da época” — escala e consistência.



🎨 Estilo e componentes (subsystems)

  • Hamon: assinatura visual do ferreiro

  • Tsuba: firewall

  • Tsuka: interface homem-máquina

  • Saya: encapsulamento seguro

🥚 Easter egg: dois ferreiros nunca produzem o mesmo hamon. É fingerprint criptográfico.


⚠️ Dicas para mainframers

  • Não confunda espada “bonita” com espada funcional

  • Katana não é para impacto lateral

  • Manutenção é ritual, não luxo

  • Original ≠ afiada demais (excesso é bug)


🧠 Filosofia oculta

A espada japonesa reflete a mentalidade que o mainframer conhece bem:

  • simplicidade extrema

  • disciplina

  • responsabilidade

  • respeito ao legado

🖥️ Comentário final Bellacosa
Assim como um mainframe, a espada japonesa é invisível até o momento crítico. Não impressiona pela aparência, mas pela confiabilidade absoluta. Não tolera improviso, não aceita atalhos.

MAINFRAME ONLINE. LÂMINA ALINHADA. SISTEMA PRONTO PARA PRODUÇÃO.

 

sábado, 15 de dezembro de 2012

🔥 JCL como Pipeline DevOps

 


🔥 JCL como Pipeline DevOps


Conhecimento básico sobre aplicações distribuídas para mainframers




☕ Midnight Lunch no CPD (agora com YAML na mesa)

Era madrugada. Café forte. JES2 organizando a fila com mais elegância do que muito orquestrador moderno.
Um arquiteto cloud visita o CPD e comenta:

“Hoje fazemos tudo com pipeline DevOps.”

O mainframer olha para o JCL rodando há 20 anos e responde em silêncio:
👉 “Engraçado… eu faço isso desde antes de chamar assim.”

Este artigo é sobre isso:
JCL como pipeline DevOps, explicado para quem já domina batch, job, step, CC e restart — e quer entender aplicações distribuídas sem abandonar a alma mainframe.


🧠 Pipeline DevOps, em português mainframe

No mundo moderno, um pipeline DevOps:

  • Compila

  • Testa

  • Executa

  • Publica

  • Reprocessa em caso de falha

  • Controla recursos

  • Gera logs

No mundo mainframe, isso sempre foi:

//JOBNAME JOB ... //STEP01 EXEC ... //STEP02 EXEC ... //STEP03 EXEC ...

📌 Pipeline DevOps = Job bem escrito.


🕰️ Um pouco de história (spoiler: nada é novo)

Antes de:

  • Jenkins

  • GitLab CI

  • GitHub Actions

  • Argo

  • Airflow

Já existia:

  • JES

  • JCL

  • PROCs

  • COND

  • RESTART

  • SMF

💡 Curiosidade Bellacosa:
O JCL nasceu automatizando fluxo de trabalho. Exatamente o que DevOps promete até hoje.


🧩 Mapeamento direto: JCL ↔ DevOps

DevOps PipelineJCL
StageSTEP
Pipeline fileJOB
AgentInitiator
RetryRESTART
ConditionalCOND
Resource limitTIME / REGION
LogsSYSOUT / SMF
SchedulingJES

👉 A diferença é sintaxe, não conceito.


⚙️ JOB Statement: o manifesto DevOps original

Hoje você descreve tudo em YAML.
No mainframe, isso sempre existiu:

//PIPEJOB JOB 'BELLACOSA', /* CLASS=A, MSGCLASS=X, TIME=0, REGION=0M, PRTY=15 */

Isso define:

  • Prioridade

  • Limite (ou não) de CPU

  • Memória

  • Classe de execução

  • Comportamento operacional

💡 Easter Egg:
PRTY=15 é o “run ASAP” do DevOps raiz 😎


🔀 Steps como stages de pipeline

Cada STEP é um stage isolado, previsível e rastreável:

//BUILD EXEC PGM=IGYCRCTL //TEST EXEC PGM=TESTRUN //DEPLOY EXEC PGM=LOADMOD

📌 Isso é:

  • Build

  • Test

  • Deploy

Só que sem marketing.


❌ COND: o if/else que evita desperdício

DevOps fala em:

“Não execute se o estágio anterior falhar.”

JCL já resolvia:

COND=(4,GT)

Tradução:

“Se algo deu ruim, nem continua.”

👉 Economia de CPU, custo e paciência.


🔄 RESTART: o sonho de todo pipeline moderno

Quantos pipelines cloud ainda fazem restart de verdade?

No mainframe:

//JOB JOB ...,RESTART=STEP03
  • Nada de reprocessar tudo

  • Nada de gambiarra

  • Nada de “vamos rodar de novo desde o começo”

💡 Curiosidade:
RESTART idempotente é disciplina de projeto. O mainframe sempre exigiu isso.


🌐 JCL e aplicações distribuídas

Hoje, um pipeline DevOps pode:

  • Chamar APIs

  • Publicar eventos

  • Rodar batch

  • Integrar sistemas

No mundo híbrido:

  • JCL dispara batch

  • Batch chama MQ

  • MQ aciona microserviço

  • Microserviço chama CICS

  • CICS grava no DB2

  • SMF registra tudo

👉 JCL vira o maestro do ambiente distribuído.


📊 Observabilidade: antes era obrigação

Hoje falam:

  • Observability

  • Tracing

  • Metrics

No JCL:

  • SYSOUT

  • SMF

  • RMF

  • JES logs

📌 Se não tem log, não roda.
📌 Se não mede, não entra em produção.

Mainframe ensinou isso cedo.


🪜 Passo a passo mental para o mainframer virar “DevOps”

  1. Veja jobs como pipelines

  2. Veja steps como stages

  3. Veja JES como scheduler

  4. Veja SMF como observabilidade

  5. Veja RESTART como retry inteligente

  6. Ignore o hype, foque nos princípios


📚 Guia de estudo (com cérebro mainframe)

🔹 Estude:

  • CI/CD

  • Pipelines

  • Event-driven

  • Observabilidade

🔹 Faça paralelos:

  • JCL ↔ YAML

  • JES ↔ Orquestrador

  • COND ↔ if/else

  • RESTART ↔ rerun from failure

🔹 Exercício clássico:

“Esse pipeline sobreviveria a um batch noturno de verdade?”


🏁 Conclusão – El Jefe fecha o pipeline

DevOps não inventou:

  • Orquestração

  • Automação

  • Governança

  • Resiliência

Ele renomeou.

O JCL já fazia tudo isso:

  • Sem buzzword

  • Sem framework da moda

  • Sem quebrar a cada release

Por isso, quando alguém diz:

“Pipeline moderno é coisa nova”

O mainframer responde, calmamente, com o café na mão:

“Novo é o nome.
O conceito… eu já rodei em produção.” ☕🔥

 

sexta-feira, 14 de dezembro de 2012

🔥 CICS Transaction Server for z/OS 5.1 — A Virada do Jogo no CICS

 

Bellacosa Mainframe apresenta o cics 5.1

🔥 CICS Transaction Server for z/OS 5.1 — A Virada do Jogo no CICS



☕ Midnight Lunch no início da década de 2010

Estamos em 2012. O mundo corporativo não quer mais apenas green screens; quer interfaces modernas, serviços, agilidade, eficiência operacional e integração com tudo — do mobile ao cloud. O CICS TS 5.1 é a primeira versão da família 5.x a entregar esse salto totalmente alinhado com tecnologia moderna, sem destruir o legado que move o mundo há décadas.


📅 Datas importantes

📌 Data de Lançamento (GA): 3 de outubro de 2012 (estimado com base em anúncio de apoio de produtos relacionados)
📌 Fim de Vida/Suporte: Já fora de serviço há anos; versões posteriores (5.3, 5.4 e 5.5) tomaram o lugar de 5.1 no ciclo oficial.


CICS 5.1


🆕 O que há de novo e o que isso realmente quer dizer

O CICS TS 5.1 não foi apenas mais uma atualização. Foi um piso firme para o CICS moderno — uma plataforma transacional pronta para o mundo conectado:


💡 1) Eficiência operacional e Service Agility

CICS 5.1 foi projetado para satisfazer centenas de requisitos de clientes, focando em agilidade de serviço e eficiência operacional; é o ponto onde o CICS passa de monolito transacional para um servidor de serviços.


🔒 2) Gerenciamento baseado em policies

Regras de monitoramento e acionamento automático para:

  • uso excessivo de CPU

  • leitura/gravação de dados

  • thresholds de armazenamento

  • loops de programa
    Tudo definido por políticas inteligentes que substituem e ampliam o antigo “system event”.

💬 Bellacosa diz:

“É como colocar cintos de segurança eletrônicos no monitor transacional — automágico e automático.”


🌐 3) Web e integração nativa

Liberty Profile — o contêiner leve da IBM — começou a aparecer em 5.1, permitindo rodar:

  • Servlets e JSPs

  • HTTP nativo

  • Interfaces modernas via JCICS APIs

Isso foi o primeiro movimento real para desbloquear o CICS para aplicações web corporativas, bem antes de JSON/REST dominarem.


📊 4) Maior visibilidade & métricas

Novas capacidades para:

  • estatísticas de dispatcher e TCB

  • métricas detalhadas de workload

  • campos de performance detalhados

Esses dados permitiram operações e ajustes finos de produção como nunca antes.


🔗 5) Capacidade de Cloud/Serviço

Ainda que não “cloud-native” no sentido moderno, essa versão introduz caminhos para serviço de ciclo de vida e application platforms, permitindo cenários de deployment mais ágeis e seguros.


🧪 Mudanças e melhorias reais

Operações sem downtime
Algumas mudanças permitem ajustar parâmetros críticos (como SSL Certs) sem reiniciar a região, aumentando disponibilidade.

Suporte ampliado à JVM/Liberty
JVM servers 64-bit e primeiros passos com servlet containers dentro do CICS.

IDs de recursos modernos e CEMT novos
Novos comandos e opções para administrar mais dinamicamente recursos — por exemplo PERFORM SSL REBUILD.

Suporte técnico a linguagens e runtimes modernos
Compatibilidade com compilers e runtimes mais atuais, deixando atrás compiladores obsoletos e antigos modelos de programação.


🎯 Evolução e contexto histórico

O 5.1 foi o start oficial da família 5.x, que após essa base primordial evoluiu para:

  • 5.2 — incrementou SOA e REST/JSON

  • 5.3 — bateu o número de requisitos pedidos por clientes

  • 5.4 — trouxe suporte ainda maior à linguagem moderna

  • 5.5 — Node.js, GraphQL e mais integração
    👉 5.1, portanto, é a fundação de toda essa modernização.


💬 Eastereggs & Curiosidades Bellacosa

🍺 100+ requisitos reais de clientes implementados:
Não é exagero — a IBM contabilizou mais de cem pedidos de clientes nessa versão, focados em eficiência e flexibilidade.

🍺 Computação antes de “cloud” ser moda:
Embora o termo “cloud” fosse quase hipster em 2012, o CICS 5.1 já construía as fundações de serviço transacional distribuído — um ancestral direto de cloud-ready mainframe.

🍺 Operações sem reinício:
Mudanças importantes em parâmetros durante operações — bem antes de muita tecnologia moderna conseguir isso de forma fluida.


🧠 Exemplo real de produção

Imagine um core bancário em 2012:

📌 Antes — ambientes puramente green screens e Web via WebSphere Gateway.

📌 Com CICS 5.1 —

  • Aplicações COBOL/PL1 continuam rodando

  • Serviços HTTP nativos dispensam middleware externo

  • Políticas automatizam thresholds de performance

  • Métricas detalhadas reduzem MTTR

💬 Bellacosa comenta:

“Essa foi a primeira vez que muitos clientes disseram:
‘Não precisamos levantar WebSphere só pra falar com CICS’.”


💡 Dicas para quem ainda vive 5.1 hoje

✅ Explore policies antes de brincar com thresholds manualmente
✅ Use CICS Explorer para visualizar métricas operacionais
✅ Aproveite Liberty/JVM onde possível — mesmo em versões antigas
💬 Bellacosa:

“CICS 5.1 não é velho. É clássico moderno.”


📌 Conclusão — Bellacosa Mainframe

O CICS Transaction Server for z/OS 5.1 foi muito mais que um release:
🔹 Foi a fundação da era de serviço e integração moderna do CICS
🔹 It paved the way for modern Web, policies, metrics, and JVM support
🔹 Foi um divisor de águas para operações e agilidade corporativa

🔥 5.1 é o “Zero Hora” do CICS moderno.
Sem ele, nada do que veio depois faria tanto sentido.

segunda-feira, 10 de dezembro de 2012

Sankarea: Quando um Backup Humano Volta Corrompido

 

Bellacosa Mainframe e a zombie de sankarea

☕ Um Café no Bellacosa Mainframe

Sankarea: Quando um Backup Humano Volta Corrompido

O Romance Zumbi que Ensina Mais Sobre Resiliência, Recuperação de Desastres e Continuidade de Serviço do que Muitos Cursos de TI


Ficha Técnica

ItemInformação
Título Originalさんかれあ (Sankarea)
Título InternacionalSankarea: Undying Love
AutorMitsuru Hattori
MangáPublicado entre 2009 e 2014
RevistaBessatsu Shōnen Magazine (Kodansha)
Anime2012
EstúdioStudio DEEN
DiretorMamoru Hatakeyama
Episódios12 episódios + 3 OVAs
GêneroRomance, Comédia, Sobrenatural, Horror, Drama, Ecchi, Slice of Life
Classificação Indicativa16 anos (violência moderada, temas psicológicos e sensualidade)

Sinopse

Imagine um jovem cujo maior sonho não é encontrar a garota perfeita.

Seu sonho é encontrar uma garota zumbi.

Parece absurdo.

Mas Sankarea utiliza essa premissa para contar uma das histórias mais sensíveis já produzidas sobre perda, liberdade, abuso psicológico e aceitação.

Chihiro Furuya sempre foi fascinado por mortos-vivos.

Após a morte de seu gato Babu, ele tenta fabricar uma poção capaz de ressuscitá-lo.

Enquanto realiza seus experimentos conhece Rea Sanka, filha de uma família milionária que vive aprisionada pelo controle obsessivo de seu pai.

Após ingerir acidentalmente a poção experimental, Rea sofre um acidente fatal.

Ela deveria morrer.

Mas não morre.

Ela desperta como um zumbi.

É neste momento que o anime realmente começa.


Resumo da História

Ao contrário dos animes tradicionais de zumbis, aqui não existe um apocalipse.

Não existem hordas.

Não existe sobrevivência.

Existe apenas uma garota tentando continuar vivendo enquanto seu corpo lentamente entra em decomposição.

Cada episódio apresenta um dilema:

  • esconder sua condição

  • controlar a deterioração física

  • manter sua humanidade

  • descobrir até onde ainda é possível amar alguém que tecnicamente morreu.


O Grande Diferencial

Sankarea não fala sobre zumbis.

Fala sobre pessoas.

O zumbi é apenas uma metáfora.

A verdadeira doença apresentada na série é emocional.

Todos os personagens estão presos.

Alguns pela família.

Outros pelo passado.

Outros pelas próprias obsessões.


Os Personagens

Rea Sanka

A protagonista.

Bonita.

Educada.

Inteligente.

Mas completamente aprisionada por um pai controlador.

Após tornar-se zumbi, ironicamente passa a experimentar sua primeira sensação verdadeira de liberdade.

Sua morte representa seu nascimento.


Chihiro Furuya

Obcecado por filmes B de terror.

Inicialmente parece apenas um nerd estranho.

Mas rapidamente percebemos que sua obsessão pelos mortos-vivos é consequência de enxergar beleza onde todos veem defeitos.

Ele ama Rea mesmo quando ela deixa de ser humana.


Dan'ichirou Sanka

Um dos personagens mais perturbadores da série.

Seu comportamento obsessivo em relação à filha ultrapassa a proteção paternal e se transforma em um retrato do controle absoluto, da manipulação emocional e da perda de autonomia. A obra sugere um ambiente familiar profundamente disfuncional, sem recorrer a explicações simplistas.


Ranko Saouji

A amiga de infância.

Representa a vida normal.

É praticamente o contraponto da fantasia.


O Studio DEEN

O Studio DEEN é um dos estúdios mais antigos da indústria.

Produziu obras como:

  • Fate/stay night (2006)

  • Higurashi

  • Rurouni Kenshin

  • Konosuba (temporadas iniciais)

  • Log Horizon (3ª temporada)

Apesar de frequentemente receber críticas por limitações orçamentárias em alguns projetos, em Sankarea entregou um resultado visual consistente.

O uso de iluminação azulada, noites silenciosas, jardins e flores cria uma atmosfera melancólica que reforça a identidade da obra.


Uma Direção Muito Inteligente

A série evita exageros.

Não existe sangue por toda parte.

Não existem sustos baratos.

O horror nasce da contemplação.

Rea continua bonita.

Continua sorrindo.

Mas lentamente deixa de pertencer ao mundo dos vivos.

Essa dualidade produz um desconforto constante.


Temáticas

Sankarea aborda muito mais do que romance.

Entre seus principais temas estão:

  • abuso psicológico

  • superproteção familiar

  • perda da identidade

  • liberdade

  • aceitação da morte

  • depressão

  • isolamento

  • amadurecimento

  • obsessão

  • amor incondicional

  • humanidade


Aventuras

Embora seja um anime tranquilo, os protagonistas enfrentam desafios contínuos:

  • esconder que Rea morreu

  • impedir que seu corpo entre em colapso

  • encontrar formas de retardar a decomposição

  • enfrentar a família Sanka

  • descobrir os limites da condição zumbi

  • preservar relacionamentos enquanto convivem com um segredo impossível.


As Mensagens Ocultas

A morte nem sempre é o fim.

Rea apenas começa a viver depois de morrer.


Liberdade pode nascer da tragédia.

Quando perde tudo, ela finalmente pode decidir quem deseja ser.


Amar é aceitar mudanças.

Chihiro ama alguém que nunca mais será igual.


Toda pessoa possui uma decomposição invisível.

Enquanto Rea perde partes do corpo, outras pessoas perdem autoestima, esperança ou identidade.

O anime sugere que todos carregamos algum tipo de deterioração interna.


Bellacosa Mainframe

O Restore Funcionou...

Mas Algo Está Errado.

Imagine um ambiente IBM Z.

O datacenter sofreu um desastre.

O time executa o Disaster Recovery.

Os backups funcionam.

O sistema volta ao ar.

As aplicações respondem.

O banco de dados está íntegro.

Mas pequenos erros começam a surgir.

Campos inconsistentes.

Jobs intermitentes.

Processamentos lentos.

Nada está totalmente quebrado.

Mas também nada voltou exatamente ao normal.

Rea é esse sistema.

Ela continua operacional.

Porém exige manutenção constante.

Monitoramento permanente.

Correções diárias.

Ela representa um ambiente recuperado que jamais retornará ao estado original.

Já Chihiro assume o papel do engenheiro de sustentação.

Ele não tenta recriar o passado.

Aceita a nova realidade.

No universo IBM Z isso lembra uma equipe de SRE ou Operações: o objetivo não é buscar perfeição, mas manter um serviço crítico disponível, resiliente e útil mesmo após uma grande falha.


Impacto Cultural

Sankarea nunca alcançou a popularidade de grandes sucessos como Highschool of the Dead, Tokyo Ghoul ou The Walking Dead. Ainda assim, conquistou um público fiel por oferecer uma combinação incomum de romance, drama e horror leve. Em vez de transformar os zumbis em ameaça coletiva, a obra usa essa condição para discutir liberdade, identidade e aceitação.

Também ajudou a consolidar uma tendência de histórias em que criaturas sobrenaturais são retratadas com profundidade emocional, influenciando a recepção de romances com fantasmas, vampiros e outros seres fantásticos nos anos seguintes.


Houve Censura?

O anime não sofreu uma censura ampla como aconteceu com algumas produções violentas da mesma época. Entretanto, certas cenas com violência, ferimentos e enquadramentos sensuais foram suavizadas em transmissões televisivas e variaram conforme a emissora e a região de exibição. As versões para mídia física preservaram melhor a intenção original da direção.

No mangá, alguns elementos ligados ao estado físico de Rea e ao tom mais sombrio da narrativa recebem um desenvolvimento mais detalhado, o que faz muitos fãs considerarem a obra impressa uma experiência mais completa.


Vale a Pena Assistir?

Se você espera ação frenética e batalhas contra hordas de mortos-vivos, provavelmente encontrará uma obra diferente do imaginado.

Mas, se aprecia narrativas que exploram personagens, simbolismos e dilemas humanos, Sankarea oferece uma experiência singular. O sobrenatural funciona como metáfora para questões muito reais: o desejo de liberdade, o peso das relações familiares, o medo da perda e a capacidade de continuar vivendo mesmo depois de acontecimentos que mudam uma pessoa para sempre.


Veredicto Bellacosa Mainframe

Nota Técnica: ★★★★★ (9,0/10)

Arquitetura da História: 9,5/10
Construção dos Personagens: 9,4/10
Atmosfera e Direção: 9,3/10
Originalidade: 9,6/10
Profundidade Psicológica: 9,2/10
Valor para Reassistir: 8,8/10

"Em um datacenter, um backup restaurado nunca é exatamente igual ao sistema que falhou. Em Sankarea, uma vida restaurada também não. É justamente nessa imperfeição que a obra encontra sua maior beleza: resiliência não significa voltar ao estado anterior, mas aprender a seguir em frente, mesmo transformado."

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