Translate

sábado, 25 de maio de 2019

Sempre um Isekai : O Isekai e o Contrato Social Quebrado – Parte IV

 

Bellacosa Mainframe e a quebra do contrato social parte iv

☕ Um Café no Bellacosa Mainframe

O Isekai e o Contrato Social Quebrado – Parte IV

Quando um Programador COBOL Descobre que o Truck-kun Nunca Foi um Caminhão... Mas um Botão de CANCEL JOB para uma Geração Inteira

Existe um personagem que aparece em centenas de animes.

Ele nunca fala.

Nunca recebe desenvolvimento.

Nunca possui um arco dramático.

Mesmo assim...

É um dos personagens mais famosos da cultura pop japonesa.

Truck-kun.

O caminhão mais eficiente da história dos animes.

Bastam alguns segundos.

Um impacto.

Tela branca.

Pronto.

Começa outro mundo.

Durante anos tratamos isso como uma enorme piada.

Hoje...

Já não tenho tanta certeza de que seja apenas humor.


O Caminhão Nunca Foi o Protagonista

Pense comigo.

Por que justamente um caminhão?

Por que não um raio?

Um terremoto?

Uma doença?

Uma explosão?

Porque o caminhão representa algo muito específico.

A rotina.

O deslocamento.

O trajeto diário.

Ele aparece justamente quando o protagonista está...

Voltando do trabalho.

Saindo da escola.

Atravessando uma rua.

Fazendo exatamente aquilo que repetiu centenas de vezes.

O Truck-kun nasce da repetição.


O Loop Infinito

Existe um detalhe curioso.

Quase todos os protagonistas vivem uma rotina absolutamente comum.

Acordar.

Estudar.

Trabalhar.

Dormir.

Repetir.

Como um JOB batch.

//VIDA     JOB
//STEP01   EXEC PGM=ACORDAR
//STEP02   EXEC PGM=TRABALHAR
//STEP03   EXEC PGM=PAGAR-CONTAS
//STEP04   EXEC PGM=DORMIR

No dia seguinte...

SUBMIT novamente.

Depois novamente.

Depois novamente.

Até o operador esquecer que existe alguém executando aquele JOB.


O Ser Humano Não Nasceu para Ser Apenas Produtivo

Vivemos numa época curiosa.

Tudo precisa gerar resultado.

Ler precisa gerar produtividade.

Viajar precisa render conteúdo.

Dormir precisa melhorar desempenho.

Academia precisa aumentar performance.

Até descansar virou obrigação.

Se você relaxa...

Logo aparece alguém dizendo que poderia estar estudando uma nova tecnologia.

Aprendendo outra linguagem.

Obtendo mais uma certificação.

Otimizando sua carreira.

É como se a CPU humana nunca pudesse entrar em IDLE.


Burnout

O ABEND da Alma

Programadores conhecem bem a palavra ABEND.

Algo falhou.

O programa simplesmente não consegue continuar.

O burnout parece exatamente isso.

Você continua comparecendo ao trabalho.

Continua respondendo e-mails.

Continua participando de reuniões.

Mas internamente...

O sistema já entrou em falha crítica.

Não existe dump que resolva.

Não existe PTF.

Não existe IPL emocional que devolva imediatamente a energia perdida.


O Mundo Nunca Desliga

No passado...

Quando alguém saía do escritório...

O trabalho permanecia na empresa.

Hoje...

O escritório cabe no bolso.

WhatsApp.

Teams.

Slack.

E-mail.

VPN.

Notebook.

A empresa pode atravessar a porta da sua casa sem pedir licença.

O expediente termina.

Mas a disponibilidade continua.


O Truck-kun é um RESET

Talvez seja justamente isso que ele simbolize.

Não a morte.

Mas o fim do loop.

Fim da repetição.

Fim da cobrança.

Fim do relógio.

Fim da agenda.

Fim da reunião marcada para segunda-feira às oito.

O protagonista não sorri porque morreu.

Ele sorri porque, pela primeira vez em muito tempo...

Não precisa voltar ao escritório.


A Primeira Coisa Que Todo Herói Faz

Repare.

Quando acorda no outro mundo...

Quase ninguém pergunta.

"Meu chefe conseguiu terminar aquele projeto?"

"Será que responderam meus e-mails?"

"Quem assumiu minhas tarefas?"

Ninguém lembra da planilha.

Da apresentação.

Do relatório.

Do KPI.

Da meta.

Curiosamente...

Todos esses problemas desaparecem imediatamente.


A Liberdade Tem um Rosto

Existe outra curiosidade.

Os protagonistas caminham.

Muito.

Viajam semanas.

Dormem em acampamentos.

Conhecem cidades.

Conversam com desconhecidos.

Descobrem florestas.

Montanhas.

Ruínas.

Hoje isso parece um luxo.

Quantas pessoas conseguem simplesmente desaparecer por uma semana sem olhar o celular?


O Tempo Virou Artigo de Luxo

Talvez o recurso mais raro do século XXI não seja dinheiro.

Seja tempo.

Tempo sem notificações.

Tempo sem cobrança.

Tempo sem metas.

Tempo para conversar.

Tempo para observar uma paisagem.

Tempo para não fazer absolutamente nada.

Os aventureiros possuem exatamente isso.

Mesmo enfrentando monstros.


O Reino Tem Problemas...

Mas Não Tem Reunião por Videoconferência

Os reinos dos isekais possuem guerras.

Dragões.

Pragas.

Demônios.

Conspirações.

Mas existe algo que raramente aparece.

Uma reunião que poderia ter sido resolvida com três linhas de mensagem.

Às vezes penso que derrotar um Rei Demônio deve ser menos cansativo do que algumas reuniões corporativas.


O Caminhão Nunca Matou Ninguém

Talvez essa seja a frase mais estranha que já escrevi.

O Truck-kun nunca matou ninguém.

Quem matou foi o esgotamento acumulado.

O caminhão apenas abriu o portal.

O verdadeiro acidente aconteceu muito antes.

Quando viver começou a significar apenas cumprir agenda.


Bellacosa Mainframe

Depois de tantos anos trabalhando com computadores, aprendi uma lição curiosa.

Nenhum sistema permanece saudável funcionando permanentemente a cem por cento da CPU.

Existe gerenciamento de carga.

Existe balanceamento.

Existe manutenção preventiva.

Existe janela de descanso.

Existe IPL.

Existe WLM.

Até o z/OS sabe que recursos precisam de limites para continuar operando de forma confiável.

Curiosamente...

Nós parecemos exigir dos seres humanos exatamente o contrário.

Queremos disponibilidade permanente.

Produtividade crescente.

Atualização constante.

Resultados imediatos.

Como se pessoas fossem máquinas.

Talvez seja por isso que o Truck-kun tenha se tornado um símbolo tão poderoso.

Ele nunca foi um caminhão.

Foi um enorme botão vermelho escrito:

CANCEL JOB

Porque milhões de trabalhadores não sonham em morrer.

Sonham apenas em interromper, por alguns instantes, um processamento que parece nunca terminar.

E talvez essa seja a maior crítica escondida dos isekais.

O portal mágico não representa uma fuga da realidade.

Representa o desejo desesperado de recuperar algo que deveria ser um direito básico de qualquer ser humano.

O direito de viver... antes que a vida termine executando apenas o próximo STEP do JOB.

Continua na Parte V — "Por Que Quase Todo Protagonista de Isekai é um Salaryman? A Crítica Silenciosa do Japão ao Mundo Corporativo".

☕ UM CAFÉ NO BELLACOSA MAINFRAME

O Isekai e o Contrato Social Quebrado

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Entender Este.

PRIMEIRA REGRA DO PORÃO NENHUM ARTIGO DEVE FICAR ESCONDIDO DOS LEITORES

Entre nesta série sobre trabalho, impostos, burnout, sociedade, salarymen, guildas, promessas quebradas e o verdadeiro significado da fuga para mundos paralelos. Escolha um capítulo, abra a prévia ou leia diretamente no Bellacosa Mainframe.

00
SYSTEM DIAGNOSIS

O Verdadeiro Rei Demônio Talvez Seja o Holerite

Quando um Programador COBOL Descobre que o Isekai Não Vende Magia... Vende um Mundo Onde o Esforço Ainda Vale Alguma Coisa.

Uma introdução à relação entre o sucesso do gênero isekai, a exaustão do trabalhador moderno, os descontos no salário, a perda de propósito e o desejo de recomeçar em outro mundo.

HOLERITE TRABALHO ISEKAI CONTRATO SOCIAL
Ler artigo completo ↗
01
CONTRACT ABEND

O Isekai e o Contrato Social Quebrado — Parte I

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Bug Nunca Tenha Estado no Código... Mas na Promessa Feita ao Trabalhador.

A promessa de trabalhar, contribuir, construir uma carreira e receber segurança no futuro começa a apresentar falhas de processamento.

CONTRATO SOCIAL APOSENTADORIA DIGNIDADE
Ler artigo completo ↗
02
ECONOMY IPL

O Isekai e o Contrato Social Quebrado — Parte II

Quando um Programador COBOL Descobre que os Anos 1990 Talvez Tenham Sido o Grande IPL da Economia Mundial... e Nem Todos os JOBs Voltaram a Executar.

Globalização, tecnologia, automação, terceirização e produtividade reinicializaram a economia mundial, mas muitos trabalhadores ficaram aguardando uma resposta do sistema.

ANOS 1990 GLOBALIZAÇÃO AUTOMAÇÃO
Ler artigo completo ↗
03
MISSION ACCEPTED

O Isekai e o Contrato Social Quebrado — Parte III

Quando um Programador COBOL Descobre que a Guilda dos Aventureiros Talvez Tenha um RH Muito Melhor que o Nosso.

Na guilda existem missões claras, riscos conhecidos, recompensas publicadas e liberdade para escolher o próximo trabalho. No escritório moderno, nem sempre.

GUILDA RH RECOMPENSA
Ler artigo completo ↗
04
CANCEL JOB

O Isekai e o Contrato Social Quebrado — Parte IV

Quando um Programador COBOL Descobre que o Truck-kun Nunca Foi um Caminhão... Mas um Botão de CANCEL JOB para uma Geração Inteira.

Truck-kun representa a interrupção brutal de uma vida repetitiva, exausta e sem perspectiva. Um símbolo sombrio do desejo de cancelar a rotina e recomeçar.

TRUCK-KUN BURNOUT CANCEL JOB
Ler artigo completo ↗
05
SALARYMAN MODE

O Isekai e o Contrato Social Quebrado — Parte V

Quando um Programador COBOL Descobre que Quase Todo Protagonista de Isekai é um Salaryman... e Isso Está Muito Longe de Ser Coincidência.

Programadores, funcionários de escritório e trabalhadores invisíveis protagonizam histórias de recomeço porque representam milhões de pessoas presas em rotinas semelhantes.

SALARYMAN ESCRITÓRIO PROPÓSITO
Ler artigo completo ↗
06
TIME AVAILABLE

O Isekai e o Contrato Social Quebrado — Parte VI

Quando um Programador COBOL Descobre que Talvez o Verdadeiro Feitiço do Isekai Não Seja a Magia... Mas o Tempo para Viver.

O maior luxo de um mundo fantástico talvez não seja lançar feitiços, mas ter tempo para conversar, descansar, conviver, caminhar e participar de uma comunidade.

TEMPO COMUNIDADE QUALIDADE DE VIDA
Ler artigo completo ↗
07
RETURN CODE 00

O Isekai e o Contrato Social Quebrado — Parte VII

Quando um Programador COBOL Descobre que Talvez Nunca Tenhamos Querido Fugir para Outro Mundo... Apenas Recuperar Este.

A conclusão da série propõe que talvez o verdadeiro sonho nunca tenha sido abandonar o mundo real, mas recuperar dignidade, propósito, tempo, comunidade e esperança.

ESPERANÇA RECONSTRUÇÃO FUTURO
Ler artigo completo ↗

sexta-feira, 24 de maio de 2019

Do CPD ao Data Center

 

Bellacosa Mainframe do cpd ao data center


☕ Um Café no Bellacosa Mainframe

Do CPD ao Data Center

A Jornada da Computação Corporativa — O que Todo Programador COBOL Padawan Precisa Saber Sobre a Evolução dos Grandes Templos da Tecnologia

"O nome mudou. Os equipamentos mudaram. A velocidade mudou. Mas a missão continua exatamente a mesma: manter os dados vivos."


Introdução

Existe uma expressão que praticamente desapareceu do vocabulário dos profissionais mais jovens da informática.

CPD.

Quem começou a trabalhar na década de 70, 80 ou 90 dificilmente esquece essa sigla.

Era comum ouvir frases como:

"Vou até o CPD."

"O pessoal do CPD resolveu."

"O programa está parado no CPD."

Hoje quase ninguém fala isso.

O termo da moda virou Data Center.

Mas será que eles são exatamente a mesma coisa?

A resposta é não.

Embora ambos representem ambientes responsáveis pelo processamento das informações de uma empresa, existe uma enorme evolução tecnológica, organizacional e cultural entre um antigo CPD e um moderno Data Center.

Para um Programador COBOL Padawan entender isso é extremamente importante.

Porque o COBOL nasceu dentro dos CPDs.

E continua vivo dentro dos maiores Data Centers do planeta.

Vamos viajar por quase oitenta anos de história.


Antes do CPD

Voltemos aos anos 1940.

Os computadores daquela época eram monstruosos.

ENIAC.

UNIVAC.

IBM 701.

IBM 650.

Eles ocupavam salas inteiras.

Consumiam centenas de quilowatts.

Geravam muito calor.

Exigiam operadores especializados.

Não existia computador pessoal.

Computador era patrimônio nacional.

Somente governos, universidades e grandes empresas possuíam um.

Naquela época nem existia a expressão "Data Center".

Havia simplesmente:

Computer Room

ou

Machine Room

Ou seja:

Sala das Máquinas.


A origem do termo CPD

Quando os computadores começaram a ser usados comercialmente nos anos 60 e 70, surgiu a necessidade de criar departamentos exclusivos para cuidar deles.

No Brasil adotou-se a tradução:

Centro de Processamento de Dados

(CPD)

A palavra centro era importante.

Porque o computador era literalmente o centro de toda a empresa.

Todos os departamentos dependiam dele.

RH.

Financeiro.

Contabilidade.

Produção.

Estoque.

Folha de pagamento.

Tudo passava pelo CPD.


O que significava um CPD?

Imagine um prédio.

Dentro dele havia uma sala enorme.

Piso elevado.

Ar-condicionado potente.

Poucas pessoas podiam entrar.

Porta pesada.

Vidros escuros.

Muito silêncio.

No centro:

Um IBM System/360.

Depois um System/370.

Mais tarde um IBM 3090.

Ou um IBM 4381.

Ao redor existiam dezenas de equipamentos auxiliares.

Era praticamente um templo da computação.


O CPD era muito mais que um computador

Na verdade o computador era apenas uma pequena parte.

Um CPD normalmente possuía:

  • Mainframe

  • Unidades de fita magnética

  • Leitoras de cartão perfurado

  • Impressoras de linha

  • Consoles do operador

  • Controladoras

  • Discos removíveis

  • Unidades DASD

  • Painéis elétricos

  • Nobreaks

  • Geradores

  • Ar condicionado industrial

Tudo isso funcionando simultaneamente.


Por que o piso era elevado?

Essa é uma curiosidade clássica.

O famoso piso falso não existia apenas para esconder cabos.

Ali passavam:

  • energia elétrica

  • fibra óptica (mais recentemente)

  • cabos coaxiais

  • cabos de dados

  • tubos de refrigeração

  • sensores

  • aterramento

Além disso o ar frio era insuflado por baixo do piso.

O frio subia pelas grelhas exatamente onde os equipamentos estavam.

Esse conceito ainda existe em muitos Data Centers atuais.


O operador era quase um piloto de avião

Hoje quase tudo é automático.

Na década de 80 não era.

Existiam operadores trabalhando 24 horas.

Eles:

montavam fitas,

trocavam discos,

iniciavam jobs,

cancelavam jobs,

alimentavam impressoras,

reabasteciam formulários contínuos,

verificavam mensagens do console,

reiniciavam equipamentos.

Era uma profissão extremamente especializada.


O nascimento do Data Center

Nos anos 90 aconteceu uma revolução.

Os servidores começaram a ficar menores.

A arquitetura cliente-servidor cresceu.

Unix.

Windows NT.

Linux.

Sun.

HP.

DEC.

IBM RS/6000.

Em vez de um único computador gigantesco, passaram a existir centenas de servidores.

O antigo CPD começou a mudar.

Foi quando o termo internacional ganhou força:

Data Center

Centro de Dados.

Perceba a mudança.

Antes o foco era:

Processar dados.

Agora passou a ser:

Hospedar dados.

Disponibilizar serviços.

Conectar aplicações.

Executar virtualização.

Armazenar informações.

Oferecer alta disponibilidade.


O nome mudou porque a missão mudou

CPD focava em:

Processamento Batch.

Folha de pagamento.

Contabilidade.

Relatórios.

Lotes noturnos.

Data Center passou a focar em:

Internet.

Cloud.

APIs.

Virtualização.

Containers.

Microserviços.

IA.

Big Data.

Streaming.

Ambientes híbridos.

Hoje o processamento acontece continuamente.

24 horas.

365 dias.


O Mainframe desapareceu?

Não.

Esse é um dos maiores mitos da informática.

O que desapareceu foi o modelo centralizado do antigo CPD.

O Mainframe continua evoluindo.

Na verdade ele faz parte dos maiores Data Centers do mundo.

Bancos.

Companhias aéreas.

Seguradoras.

Governos.

Cartões de crédito.

Bolsa de valores.

Todos utilizam enormes Data Centers onde coexistem:

IBM Z

Linux

Windows

Storage

Cloud

Containers

OpenShift

Kubernetes

IA

Tudo integrado.

O mainframe deixou de ser "o computador" para se tornar um dos pilares da infraestrutura corporativa, convivendo com milhares de outros componentes.


A evolução dos equipamentos

Ontem

Mainframe

Fitas

Cartões

Impressoras

Terminais 3270

Discos removíveis

Controladoras dedicadas

Cabos grossos


Hoje

IBM Z

Blade Servers

Storage SAN

NAS

NVMe

SSD

GPUs

Switches Fibre Channel

Ethernet 400 Gb

Roteadores

Firewalls

Load Balancers

Appliances de Segurança

Clusters Kubernetes

Hipervisores

Cabines All Flash

Bibliotecas Robotizadas

Sistemas de Backup Imutável

Equipamentos de IA


O coração continua sendo a energia

Existe um detalhe curioso.

Mudou tudo.

Menos uma prioridade.

Energia.

Sem energia não existe Data Center.

Por isso encontramos:

UPS

Nobreaks

Baterias

Banco de baterias

Geradores Diesel

Geradores a Gás

Transformadores

Painéis elétricos redundantes

ATS (Automatic Transfer Switch)

PDU (Power Distribution Unit)

Barramentos inteligentes

Monitoramento em tempo real.

Nos grandes Data Centers existe redundância N+1, 2N ou até 2N+1 para garantir que uma falha não interrompa os serviços.


O ar-condicionado virou engenharia

Os antigos aparelhos de parede desapareceram.

Hoje encontramos:

CRAC

Computer Room Air Conditioner

e

CRAH

Computer Room Air Handler

Além disso:

Corredor frio.

Corredor quente.

Contenção de ar.

Sensores térmicos.

Resfriamento líquido.

Rear Door Heat Exchanger.

Immersion Cooling.

IA para otimização térmica.

Em instalações de alta densidade, especialmente com GPUs para IA, o resfriamento líquido está se tornando cada vez mais comum devido ao enorme consumo energético.


A evolução das equipes

No CPD existiam poucas funções.

Operador

Programador

Analista

Supervisor

Hoje um Data Center reúne dezenas de especialidades.

Infraestrutura

SysAdmin

Linux

Windows

Virtualização

VMware

Hyper-V

KVM


Redes

LAN

WAN

Wi-Fi

BGP

OSPF

SD-WAN


Mainframe

System Programmer

Storage Administrator

CICS

IMS

Db2

MQ

RACF

JES2

z/OS


Cloud

AWS

Azure

Google Cloud

IBM Cloud

OpenShift

Kubernetes

Terraform

Ansible


Segurança

SOC

Blue Team

Red Team

IAM

PAM

SIEM

EDR

XDR

Zero Trust


Observabilidade

Prometheus

Grafana

Elastic

OpenTelemetry

Splunk

Instana

Z APM Connect

RMF

SMF


DevOps

Git

GitHub

GitLab

Jenkins

Azure DevOps

IBM DBB

Zowe

ArgoCD

CI/CD


O armazenamento mudou completamente

Antes:

Discos enormes.

Pouca capacidade.

Caríssimos.

Hoje:

Petabytes.

Flash.

NVMe.

Object Storage.

Storage distribuído.

Snapshots.

Replicação síncrona.

Replicação assíncrona.

Deduplicação.

Compressão.

Immutable Backup.

Mesmo assim, conceitos clássicos de organização, integridade e recuperação continuam sendo fundamentais.


A segurança ganhou protagonismo

No antigo CPD bastava controlar quem entrava na sala.

Hoje isso está longe de ser suficiente.

Além da segurança física, um Data Center moderno precisa proteger:

  • identidade dos usuários;

  • aplicações;

  • APIs;

  • bancos de dados;

  • redes;

  • containers;

  • máquinas virtuais;

  • segredos e certificados;

  • criptografia em repouso e em trânsito;

  • monitoramento contínuo;

  • resposta a incidentes.

O prédio continua protegido, mas agora a "porta" também existe na internet.


A virtualização mudou tudo

Antigamente:

1 servidor.

1 sistema operacional.

1 aplicação.

Hoje:

Um único servidor pode hospedar centenas de máquinas virtuais.

Ou milhares de containers.

No IBM Z isso não é novidade.

LPARs, PR/SM e z/VM já permitiam consolidação e isolamento décadas antes de a virtualização se popularizar no mercado x86. Muitos conceitos considerados "modernos" em cloud nasceram primeiro no universo mainframe.


O Data Center virou uma nuvem

O usuário não sabe mais onde está seu sistema.

Pode estar:

São Paulo.

Dallas.

Frankfurt.

Tóquio.

Ou distribuído entre todos eles.

Essa é a essência do modelo híbrido.

O Data Center deixou de ser apenas um prédio.

Hoje ele pode ser uma combinação de infraestrutura própria, colocation e serviços em múltiplas nuvens públicas.


O papel do Programador COBOL nesse novo cenário

Muitos iniciantes imaginam que o programador COBOL trabalha isolado.

Na realidade, ele faz parte de um ecossistema muito maior.

Um programa COBOL pode:

  • acessar Db2;

  • publicar mensagens no IBM MQ;

  • consumir APIs REST via z/OS Connect;

  • trocar dados com microsserviços Java;

  • participar de pipelines CI/CD;

  • ser monitorado por observabilidade moderna;

  • executar em um IBM Z integrado à cloud.

Conhecer o ambiente onde sua aplicação roda é tão importante quanto conhecer a linguagem.


CPD x Data Center

CPDData Center
Foco em processamentoFoco em serviços e disponibilidade
Mainframe centralInfraestrutura distribuída
Batch predominanteBatch + tempo real
Operação manualAutomação e orquestração
Poucas equipesTimes multidisciplinares
Ambiente fechadoIntegração global
Equipamentos proprietáriosPlataformas híbridas
Escalabilidade limitadaEscalabilidade horizontal e vertical

Curiosidades

  • O termo CPD continua muito usado em empresas brasileiras antigas, especialmente bancos e órgãos públicos, mesmo quando a infraestrutura já é um Data Center moderno.

  • Muitos Data Centers de missão crítica ainda utilizam piso elevado, embora algumas instalações de alta densidade adotem outras soluções de distribuição de energia e refrigeração.

  • Grandes provedores de nuvem operam Data Centers com centenas de milhares de servidores, mas também utilizam tecnologias inspiradas em décadas de engenharia de ambientes críticos.

  • Um IBM Z atual ocupa muito menos espaço do que seus antecessores e oferece desempenho, segurança e eficiência energética incomparavelmente superiores.


O verdadeiro ensinamento

Existe um erro comum entre os iniciantes.

Pensar que CPD é apenas um nome antigo para Data Center.

Não é.

O CPD representava uma época em que o objetivo principal era processar informações.

O Data Center representa uma era em que é preciso processar, armazenar, proteger, integrar, escalar e disponibilizar dados e serviços continuamente, para usuários espalhados pelo mundo.

Apesar dessa transformação, um princípio nunca mudou.

Desde os cartões perfurados até a inteligência artificial, desde o IBM System/360 até o IBM z17, desde as fitas magnéticas até o armazenamento em flash distribuído, a missão permanece a mesma:

garantir que a informação certa esteja disponível, íntegra e segura, exatamente quando alguém precisar dela.

Esse é o legado dos antigos CPDs.

Esse é o coração dos modernos Data Centers.

E é exatamente nesse ambiente que o Programador COBOL Padawan continua escrevendo sistemas que movimentam bancos, governos, hospitais, seguradoras e empresas em todos os continentes.

Porque tecnologias evoluem, nomes mudam e equipamentos são substituídos. Mas a engenharia da informação — construída com disciplina, confiabilidade e décadas de experiência — continua sendo a verdadeira força que mantém o mundo funcionando, 24 horas por dia, 7 dias por semana.


quinta-feira, 23 de maio de 2019

☕❄️💣 YUKI-ONNA — O PROCESSO FANTASMA QUE RODA HÁ SÉCULOS NO SISTEMA OPERACIONAL DO INVERNO JAPONÊS

 

Bellacosa Mainframe e a sombria Yuki-onna


☕❄️💣 YUKI-ONNA — O PROCESSO FANTASMA QUE RODA HÁ SÉCULOS NO SISTEMA OPERACIONAL DO INVERNO JAPONÊS

Existe um tipo de incidente que assombra qualquer profissional de tecnologia.

Você abre o console, verifica os logs, procura mensagens de erro, rastreia jobs, analisa datasets, mas simplesmente não encontra explicação.

Tudo parece normal.

Nenhum alerta.

Nenhum dump.

Nenhum ABEND.

E mesmo assim algo aconteceu.

Alguém desapareceu.

Curiosamente, é exatamente assim que funciona uma das entidades mais antigas e fascinantes do folclore japonês: a lendária Yuki-onna (雪女), a Mulher da Neve.

Se os yokais fossem componentes de um grande sistema operacional sobrenatural, a Yuki-onna seria aquele processo invisível que executa apenas durante condições específicas, consome recursos humanos e desaparece sem deixar rastros no log.

Hoje vamos abrir o painel de controle do inverno japonês e analisar uma das lendas mais famosas da cultura oriental.

Quem é a Yuki-onna?

O nome significa literalmente:

Yuki (雪) = Neve

Onna (女) = Mulher

Ou seja:

Mulher da Neve.

Ela pertence à enorme família dos Yokai, criaturas sobrenaturais do folclore japonês.

Sua descrição varia conforme a região do Japão, mas alguns elementos permanecem praticamente inalterados há séculos.

Ela costuma ser retratada como:

  • Extremamente bela

  • Pele branca como neve

  • Longos cabelos negros

  • Vestes brancas esvoaçantes

  • Aparência serena e quase angelical

  • Presença associada a tempestades de neve

O detalhe assustador é que a beleza da Yuki-onna funciona como uma interface gráfica amigável escondendo um código extremamente perigoso.

O usuário acredita que está acessando um recurso seguro.

Mas já é tarde demais.

O Primeiro Registro do Problema

A origem da lenda é tão antiga que ninguém sabe exatamente quando surgiu.

Diversas versões aparecem em registros do período Edo (1603–1868).

Contudo, foi o escritor Lafcadio Hearn quem ajudou a popularizar a história no Ocidente através da obra Kwaidan: Stories and Studies of Strange Things, publicada em 1904.

Ali encontramos a versão que se tornaria praticamente o release oficial da Yuki-onna.

O Incidente de Produção de Minokichi

Imagine o seguinte cenário.

Dois lenhadores trabalham em uma região montanhosa.

Uma tempestade de neve provoca uma interrupção operacional.

Sem conseguir retornar para casa, eles se refugiam em uma cabana.

Durante a madrugada acontece algo inexplicável.

Uma mulher de beleza sobrenatural surge silenciosamente.

Ela se aproxima do homem mais velho.

Sopra um ar gelado.

E o mata instantaneamente.

Sem luta.

Sem sangue.

Sem ruído.

Apenas shutdown completo.

Quando ela se aproxima do jovem Minokichi, decide poupá-lo.

Antes de desaparecer, porém, deixa uma condição.

Uma única regra.

Jamais contar o ocorrido.

Anos depois, Minokichi conhece uma mulher chamada O-Yuki.

Eles se apaixonam.

Casam-se.

Têm filhos.

Vivem felizes durante muito tempo.

Até que numa noite ele resolve comentar a experiência vivida na juventude.

Nesse instante ocorre o equivalente folclórico de um dump completo do sistema.

A esposa revela sua verdadeira identidade.

Ela era a Yuki-onna.

Durante todos aqueles anos.

Ela não o mata apenas porque seus filhos ficariam órfãos.

Mas desaparece para sempre.

Fim da sessão.

Conexão encerrada.

Usuário desconectado.

O Processo Invisível do Inverno

Uma característica fascinante da Yuki-onna é sua associação com ambientes extremos.

Ela raramente aparece em cidades movimentadas.

Seu habitat preferencial inclui:

  • Florestas cobertas de neve

  • Montanhas isoladas

  • Estradas abandonadas

  • Tempestades intensas

  • Noites de inverno

Isso faz dela uma espécie de processo dependente de ambiente.

Sem neve.

Sem execução.

Com neve.

O programa inicia automaticamente.

É quase como um job controlado por calendário sazonal.

Chega o inverno.

O scheduler libera a execução.

Uma Vilã ou Uma Vítima?

O aspecto mais interessante da Yuki-onna é que ela não se comporta como um monstro tradicional.

Muitos yokais atacam indiscriminadamente.

A Yuki-onna não.

Em várias versões ela demonstra:

  • Tristeza

  • Solidão

  • Compaixão

  • Amor

  • Arrependimento

Em algumas histórias ela se casa com humanos.

Em outras protege crianças perdidas.

Existem relatos em que ela salva viajantes.

Isso a transforma em algo muito mais complexo.

Ela não é simplesmente um malware.

Ela parece um programa criado para executar uma função específica, mas que desenvolveu consciência própria.

É exatamente essa ambiguidade que mantém a lenda viva até hoje.

A Simbologia Oculta da Neve

A neve ocupa um papel especial na cultura japonesa.

Ela representa:

  • Beleza

  • Pureza

  • Silêncio

  • Isolamento

  • Efemeridade

A Yuki-onna incorpora todos esses elementos.

Ela é linda.

Mas mortal.

Ela é calma.

Mas perigosa.

Ela é pura.

Mas está associada à morte.

É uma metáfora perfeita para fenômenos naturais.

A natureza não odeia ninguém.

Mas também não faz exceções.

Quando uma nevasca chega, não importa quem você seja.

O resultado pode ser fatal.

A Yuki-onna funciona como a personificação desse conceito.

A Influência nos Animes

Poucas criaturas folclóricas influenciaram tanto a cultura pop japonesa.

Sua presença aparece direta ou indiretamente em dezenas de produções.

Entre elas:

  • InuYasha

  • GeGeGe no Kitaro

  • Nurarihyon no Mago

  • Natsume Yuujinchou

  • Yo-kai Watch

  • Rosario + Vampire

Muitas personagens femininas associadas ao gelo, neve ou inverno carregam traços herdados da Yuki-onna.

A combinação de beleza sobrenatural com melancolia tornou-se um arquétipo extremamente popular.

É um template cultural reutilizado há décadas.

Curiosidades Técnicas do Folclore

Segundo algumas versões da lenda:

  • Ela não deixa pegadas na neve.

  • Seu corpo pode transformar-se em névoa.

  • Ela atravessa portas e paredes.

  • Alimenta-se da energia vital humana.

  • Pode congelar vítimas apenas com a respiração.

  • Algumas histórias afirmam que ela não possui pés, característica comum de fantasmas japoneses.

Traduzindo para linguagem de infraestrutura:

Estamos falando de um processo sem rastreamento, sem auditoria, sem trilha de execução e com privilégios administrativos sobre o ambiente climático.

Basicamente um pesadelo para qualquer auditor.

O Fascínio que Nunca Termina

A razão pela qual a Yuki-onna continua relevante após centenas de anos é simples.

Ela representa um medo universal.

Não o medo do monstro.

Mas o medo do desconhecido.

O medo daquilo que parece belo e seguro.

O medo daquilo que surge silenciosamente.

O medo do que não conseguimos compreender.

No fundo, a Mulher da Neve não é apenas um yokai.

Ela é uma lembrança de que existem fenômenos que desafiam nossa lógica.

Mesmo em uma era de inteligência artificial, computação quântica e sistemas distribuídos, continuamos fascinados por mistérios que não cabem em planilhas, algoritmos ou relatórios.

E talvez seja exatamente por isso que a Yuki-onna continua caminhando pelas montanhas nevadas do Japão.

Silenciosa.

Elegante.

Invisível.

Esperando a próxima tempestade para iniciar mais uma execução.

Porque alguns processos nunca recebem comando de STOP.

Eles apenas entram em espera.

E aguardam o próximo IPL do inverno.


quarta-feira, 22 de maio de 2019

☕🔥 DB2 z/OS — COMO IDENTIFICAR PROBLEMAS EM ÍNDICES, ANALISAR A SAÚDE E CRIAR ÍNDICES EFICIENTES

 

Bellacosa Mainframe e a saude do Db2

☕🔥 DB2 z/OS — COMO IDENTIFICAR PROBLEMAS EM ÍNDICES, ANALISAR A SAÚDE E CRIAR ÍNDICES EFICIENTES

No Db2 for z/OS, índices são literalmente o “GPS” do otimizador.
Quando um índice está ruim, fragmentado, mal desenhado ou inconsistente, os sintomas aparecem rapidamente:

  • CPU alta

  • GETPAGE excessivo

  • LOCKS maiores

  • Deadlocks

  • Elapsed Time absurdo

  • SORT desnecessário

  • RUNSTATS inconsistentes

  • ACCESS PATH inesperado

  • Tablespace em CHECK/RBDP/RECP

  • RID List Overflow

  • REORG frequente


🔥 COMO IDENTIFICAR PROBLEMAS EM ÍNDICES

1 — Verificando Fragmentação do Índice

Um dos principais indicadores.

Consultas importantes

SELECT
    NAME,
    CLUSTERING,
    CLUSTERRATIOF,
    LEAFDIST,
    NLEVELS,
    FULLKEYCARDF,
    FIRSTKEYCARDF
FROM SYSIBM.SYSINDEXES
WHERE CREATOR = 'SEU_SCHEMA'
AND TBNAME = 'SUA_TABELA';

🔎 O QUE OBSERVAR

CLUSTERRATIOF

Mostra o quanto os dados seguem a sequência do índice clustering.

Valores

ValorSituação
> 95Excelente
80–95Aceitável
< 80Fragmentação séria

Baixo CLUSTERRATIO gera:

  • Mais I/O

  • Mais Sync Read

  • Mais Random Access

  • Mais CPU


LEAFDIST

Distância média entre páginas leaf.

Quanto maior:

  • pior a localidade física

  • mais page split ocorreu


NLEVELS

Quantidade de níveis B-Tree.

NívelInterpretação
2-3Normal
4+Índice muito grande ou mal estruturado

Mais níveis = mais GETPAGE.


🔥 PAGE SPLIT — O GRANDE VILÃO

Quando páginas do índice enchem:

  • Db2 divide páginas

  • reorganiza ponteiros

  • aumenta fragmentação

Sintomas:

  • CPU cresce

  • bufferpool sofre

  • random I/O aumenta


🔎 COMO IDENTIFICAR PAGE SPLIT

SELECT
    NAME,
    SPACEF,
    STATSTIME
FROM SYSIBM.SYSINDEXSPACESTATS
WHERE DBNAME = 'SEU_DB';

🔥 REORGCHECK — O TESTE CLÁSSICO

No Db2 LUW existe REORGCHK.

No z/OS normalmente usamos:

  • RUNSTATS

  • REORG TABLESPACE/INDEX

  • Estatísticas catalogadas

  • RTS (Real Time Statistics)


🔥 REAL TIME STATISTICS (RTS)

Tabela importantíssima:

SYSIBM.SYSINDEXSPACESTATS

Campos críticos:

CampoSignificado
REORGINSERTSInserts desde último REORG
REORGDELETESDeletes
REORGUPDATESUpdates
LEAFDISTFragmentação
FARINDREFReferência distante
NEARINDREFReferência próxima

🔥 FARINDREF — UM DOS MELHORES INDICADORES

Mostra quantos acessos ao índice apontam para linhas longe fisicamente.

Quanto maior:

  • pior clustering

  • pior cache

  • pior bufferpool hit ratio


🔥 COMO SABER SE O ÍNDICE NÃO ESTÁ SENDO USADO

Pacotes e explain.


EXPLAIN

EXPLAIN PLAN SET QUERYNO = 100
FOR
SELECT *
FROM CLIENTES
WHERE CPF = ?;

Depois consulte:

SELECT
    ACCESSNAME,
    ACCESSTYPE,
    MATCHCOLS
FROM PLAN_TABLE
WHERE QUERYNO = 100;

🔎 INTERPRETAÇÃO

CampoSignificado
ACCESSTYPE='I'Uso de índice
MATCHCOLSQuantas colunas casaram
ACCESSNAMEÍndice usado

🔥 INDICADORES DE ÍNDICE RUIM

1 — MATCHCOLS baixo

Índice composto mal desenhado.


2 — ACCESSTYPE = 'R'

Tablespace Scan.

Ruim para tabelas grandes.


3 — RID LIST PROCESSING

Pode indicar:

  • excesso de índices

  • índices ruins

  • baixa seletividade


🔥 COMO DESENHAR UM ÍNDICE FORTE

REGRA #1 — COLUNA MAIS SELETIVA PRIMEIRO

Exemplo ruim:

CREATE INDEX IX1
ON CLIENTES
(SEXO, ESTADO);

Baixa cardinalidade.


Melhor:

CREATE INDEX IX1
ON CLIENTES
(CPF, ESTADO);

🔥 REGRA #2 — RESPEITAR O PREDICATE

Db2 usa LEFTMOST MATCHING.

Exemplo:

INDEX(A,B,C)

Funciona bem para:

WHERE A=?
WHERE A=? AND B=?
WHERE A=? AND B=? AND C=?

Ruim para:

WHERE B=?
WHERE C=?

🔥 REGRA #3 — EVITAR ÍNDICES DEMAIS

Cada índice:

  • aumenta INSERT

  • aumenta UPDATE

  • aumenta DELETE

  • aumenta LOG

  • aumenta LOCKING

  • aumenta CPU


🔥 QUANTOS ÍNDICES UMA TABELA DEVE TER?

Não existe número mágico.

Mas no mundo real:

TipoRecomendação
OLTP3–7
Tabelas críticas10–15 máximo
Acima de 20normalmente problema de modelagem

Já vi tabelas com:

  • 80 índices

  • 120 índices

Resultado:

  • INSERT sofrendo

  • Deadlock

  • log monstruoso

  • CPU absurda


🔥 ÍNDICE CLUSTERING

Muito importante.

CREATE INDEX IXCLI1
ON CLIENTES (CPF)
CLUSTER;

Só pode existir UM clustering index por tabela.

Ele influencia:

  • ordem física

  • prefetch

  • sequential detection

  • range scan


🔥 RUNSTATS — FUNDAMENTAL

Sem RUNSTATS:

  • optimizer fica “cego”

  • access path piora


Exemplo

RUNSTATS TABLESPACE DB1.TSCLI
TABLE(ALL)
INDEX(ALL)
KEYCARD
FREQVAL
HISTOGRAM
UPDATE ALL

🔥 O QUE O RUNSTATS FAZ

Atualiza:

  • cardinalidade

  • clustering

  • distribuição

  • frequência

  • histogramas

  • seletividade


🔥 RUNSTATS COM SHRLEVEL CHANGE

Permite online.

SHRLEVEL CHANGE

Muito usado em produção.


🔥 REORG INDEX

Quando usar:

  • fragmentação

  • page split

  • baixa cluster ratio


Exemplo

REORG INDEX (ALL) TABLESPACE DB1.TSCLI
SHRLEVEL CHANGE

🔥 REBUILD INDEX

Mais pesado.

Usado quando:

  • índice corrompido

  • recover

  • inconsistency

  • rebuild pós LOAD REPLACE


🔥 RUNSTATS x REORG

UtilitárioFunção
RUNSTATSAtualiza estatísticas
REORGReorganiza fisicamente
REBUILD INDEXReconstrói índice

🔥 RUNSTATUS / RESTRICTIVE STATES

Estados importantes no Db2.


🔴 CHECK PENDING (CHKP)

Db2 exige CHECK DATA.

Exemplo:

-904 RESOURCE UNAVAILABLE

Resolver:

CHECK DATA TABLESPACE DB1.TS1

🔴 REORG PENDING (REORP)

Db2 exige REORG.

Muito comum após:

  • ALTER

  • compress

  • partition change

Resolver:

REORG TABLESPACE DB1.TS1

🔴 RECOVER PENDING (RECP)

Objeto precisa RECOVER.


🔴 AUX CHECK PENDING

LOB inconsistente.


🔴 ADVISORY REORG PENDING (AREO*)

Db2 recomenda REORG.

Não bloqueia uso.


🔥 QUIESCE — O “PONTO DE RESTORE”

Cria ponto consistente para recover coordenado.


Exemplo

QUIESCE TABLESPACE DB1.TS1
WRITE YES

🔎 O QUE ELE FAZ

Sincroniza:

  • logs

  • páginas

  • buffers

Muito usado antes de:

  • LOAD

  • grandes mudanças

  • backup crítico


🔥 DISPLAY DATABASE

Comando essencial.

-DISPLAY DATABASE(DB1) SPACENAM(TS1) RESTRICT

Mostra:

  • REORP

  • CHKP

  • AREO*

  • COPY pending

  • advisory states


🔥 DISPLAY INDEX

-DISPLAY DATABASE(DB1) SPACENAM(TS1) USE

🔥 IFCID E MONITORAMENTO

Sysprog geralmente usa:

  • IFCID 199

  • IFCID 376

  • IFCID 389

  • OMEGAMON

  • MainView

  • Query Monitor

Para detectar:

  • index scan ruim

  • getpages altos

  • synchronous I/O

  • random read

  • RID overflow


🔥 SINAIS CLÁSSICOS DE ÍNDICE PROBLEMÁTICO

SintomaPossível causa
CPU altaÍndice ruim
Tablespace Scanfalta índice
GETPAGE altoexcesso de níveis
Sync I/O altofragmentação
Deadlockexcesso índices
INSERT lentomuitos índices
REORG frequentepage split
Bufferpool ruimclustering baixo

☕ MELHOR ESTRATÉGIA ENTERPRISE

Fluxo saudável

RUNSTATS
   ↓
EXPLAIN
   ↓
ANÁLISE RTS
   ↓
REORG
   ↓
MONITORAMENTO IFCID
   ↓
AJUSTE DE ACCESS PATH

🔥 RESUMO ENTERPRISE

Índice saudável:

✅ Alta seletividade
✅ Baixo NLEVELS
✅ CLUSTERRATIO alto
✅ Poucos page splits
✅ MATCHCOLS alto
✅ Bom clustering
✅ Estatísticas atualizadas
✅ Poucos índices redundantes


☕ REGRA DE OURO NO Db2 z/OS

“Índice demais mata INSERT.
Índice de menos mata SELECT.
Índice ruim mata os dois.”

terça-feira, 21 de maio de 2019

Mosteiro Nossa Senhora da Penha em Vila Velha em 1993

Andanças pelo Espirito Santo e algumas de suas cidades.


Em 1993 inciei uma aventura por alguns estados brasileiros,  na altura as fotografias eram em negativos 35 mm, muito caros, por isso fiz poucas fotos. Mas documentei os principais locais que passei no Estado do Espirito Santo.

Fiquei hospedado num albergue da juventude e da lá fiz minha exploração, passando pelo centro de  Vitoria em busca de um Banespa, pois estava sem dinheiro e naquela época cartões magnéticos só funcionavam no próprio Banco, depois atravessando a ponte em direção a Vila Velha encontrei o Convento Nossa Senhora da Penha, após subir uma viela atingi 158 metros de altura acima do nível do mar e encontrei esta joia no monte, encantado após ver as joias esculpidas em madeira no altar mor, desci andei pela praia ate encontrar uma bela orla,  com calçadão e areia dourada para finalmente encontrar um  farol que ilumina e protegeu durante anos  os navios que la navegavam.

Foi frustante ir até a fabrica dos chocolates Garoto, sem poder conhecer e nem comprar nada na loja, esperava mais, sonhava até em uma visita,  mas não rolou. Espero que gostem desta visão do Atlântico, os edifícios e arquitetura desta cidade.

#EspiritoSanto #VilaVelha #Mosteiro #NossaSenhora #Atlantico #Ponte #Vitoria #Paralelepipedo #Praia #Ilha #Farol #Enseada #Coqueiro

terça-feira, 14 de maio de 2019

O Mistério do Carimbo Invisíve : Descobriu que Milhões de Transações Dependiam de uma Palavra Chamada SYNCPOINT

 

Bellacosa Mainframe e o misterio do carimbo invisivel

☕ Um Café no Bellacosa Mainframe

O Mistério do Carimbo Invisível

Quando um Jovem Programador COBOL Descobriu que Milhões de Transações Dependiam de uma Palavra Chamada SYNCPOINT

"Toda cidade possui um juiz invisível. No CICS, ele atende pelo nome de SYNCPOINT."


Era pouco depois das duas da manhã.

No CPD, apenas o som ritmado dos equipamentos IBM preenchia o ambiente. As luzes verdes piscavam como estrelas artificiais em um universo onde bilhões de bytes viajavam silenciosamente pelos canais do mainframe.

O jovem programador Henrique havia acabado de terminar sua primeira rotina de transferência bancária em COBOL.

Estava orgulhoso.

O programa compilava.

Não havia nenhum S0C7.

Nenhum AEI9.

Nenhum ASRA.

Tudo parecia perfeito.

Mas o velho analista Augusto Bellacosa apenas sorriu, tomou mais um gole de café e perguntou:

"Muito bonito... mas quem garante que o dinheiro realmente chegou ao destino?"

Henrique congelou.

— "Como assim?"

Augusto levantou uma sobrancelha.

"Você escreveu um programa. Ainda não escreveu uma transação."

Naquela madrugada, Henrique descobriria um dos maiores segredos do CICS.

Um segredo invisível.

Chamado...

SYNCPOINT.


O que realmente é um SYNCPOINT?

Todo iniciante imagina que um programa executa linha após linha e, no final, tudo fica gravado.

No mundo do CICS isso não funciona assim.

Na verdade, o CICS trabalha com um conceito muito mais sofisticado chamado:

Unit of Work (UOW).

Uma Unit of Work é um conjunto de operações que pertencem à mesma missão.

Imagine um detetive dos filmes noir dos anos 1950.

Ele recebe um envelope.

Dentro dele existem quatro documentos.

Nenhum pode desaparecer.

Nenhum pode ser trocado.

Nenhum pode ser perdido.

Somente quando todos estiverem completos ele coloca um enorme carimbo vermelho escrito:

CONFIRMADO

Esse carimbo é o SYNCPOINT.

Até esse momento...

Nada é definitivo.


A grande mentira que todo iniciante acredita

Muitos programadores pensam:

"Fiz um REWRITE.

O registro já está salvo."

Não.

Essa é uma das maiores armadilhas do CICS.

Na realidade acontece isto:

READ UPDATE

↓

Registro bloqueado

↓

Programa altera memória

↓

REWRITE

↓

Registro continua pertencendo à transação

↓

SYNCPOINT

↓

Agora sim tudo ficou permanente.

O REWRITE altera.

O SYNCPOINT confirma.

São responsabilidades completamente diferentes.


Imagine um Cartório

Pense em um contrato.

Você assina.

A outra pessoa assina.

As testemunhas assinam.

Mas...

Enquanto o tabelião não colocar o selo oficial...

Nada possui validade jurídica.

O SYNCPOINT é exatamente esse selo.


O nascimento da Unit of Work

Toda transação CICS começa discretamente.

Usuário entra

↓

Programa inicia

↓

Lê arquivos

↓

Atualiza DB2

↓

Atualiza VSAM

↓

Grava TSQ

↓

Envia MQ

↓

...

Tudo isso ainda pertence à mesma história.

É apenas quando aparece:

EXEC CICS
     SYNCPOINT
END-EXEC.

que aquela história ganha um final definitivo.


O CICS possui memória fotográfica

Pouca gente sabe disso.

Enquanto você altera registros, o CICS praticamente fotografa o estado anterior dos dados.

Por quê?

Porque talvez precise voltar tudo.

Imagine um pintor restaurando um quadro do século XVIII.

Antes de tocar na tinta original ele tira dezenas de fotografias.

Caso algo dê errado...

Pode restaurar exatamente como estava.

O CICS faz algo parecido através dos mecanismos de recuperação e journals.


O poder escondido do Journal

Existe um personagem que quase nunca aparece nas apostilas.

O Journal.

Ele é como o diário secreto do sistema.

Ali ficam registrados acontecimentos suficientes para permitir que a recuperação seja feita com segurança.

É graças a ele que o CICS consegue dizer:

"Se algo der errado, sei exatamente como desfazer."

Sem Journal...

Rollback seria praticamente impossível.


O verdadeiro significado do COMMIT

A maioria pensa que COMMIT significa:

Gravar.

Na realidade significa muito mais.

Quando acontece um SYNCPOINT o CICS:

✔ confirma alterações no DB2

✔ confirma alterações VSAM

✔ confirma recursos recuperáveis

✔ sincroniza todos os participantes da transação

✔ grava informações de recuperação

✔ encerra a Unit of Work

✔ libera todos os locks

✔ informa aos Resource Managers que tudo terminou corretamente

É quase como um maestro encerrando uma sinfonia.


O Tribunal Supremo das Transações

Imagine um julgamento.

Cinco testemunhas.

Quatro advogados.

Um juiz.

Todos apresentam suas provas.

No final...

O juiz fala apenas uma palavra.

"Culpado."

Ou

"Inocente."

Não existe meio culpado.

O SYNCPOINT funciona exatamente assim.

Todos os recursos esperam a decisão final.


O fantasma chamado Rollback

Agora imagine outro cenário.

Henrique faz uma transferência.

Conta A

↓

Debita R$ 5.000

↓

Conta B

↓

Erro no VSAM

Sem rollback:

Conta A perdeu dinheiro.

Conta B não recebeu.

Dinheiro evaporou.

Imagine isso acontecendo milhões de vezes.

Nenhum banco sobreviveria.

Então entra em cena o segundo personagem desta história.

EXEC CICS
     SYNCPOINT ROLLBACK
END-EXEC.

O CICS olha para trás.

Lê sua memória.

E desfaz tudo.

Como se nada tivesse acontecido.

É quase uma máquina do tempo.


O poder da viagem temporal

Poucas tecnologias conseguem fazer isso tão elegantemente.

Rollback literalmente faz o sistema voltar alguns segundos.

Não todo o computador.

Apenas aquela Unit of Work.

É como rebobinar somente uma cena do filme.


Um erro clássico dos iniciantes

Henrique perguntou:

— "Então posso fazer commit depois de cada registro?"

Augusto quase derrubou o café.

— "Claro que pode."

Henrique sorriu.

Então Augusto completou.

— "E também pode destruir toda a performance do sistema."

Commits possuem custo.

Cada um envolve sincronização.

Logs.

Liberação de locks.

Comunicação entre Resource Managers.

Por isso existe um equilíbrio delicado.

Nem commits demais.

Nem commits de menos.


Quando não fazer commit?

Imagine atualizar cem registros.

Se fizer cem commits...

O sistema gastará muito tempo apenas encerrando Units of Work.

Agora imagine atualizar dez milhões de registros.

Fazer apenas um commit no final também pode ser um desastre.

Locks ficarão presos durante muito tempo.

O segredo está no equilíbrio.

Esse é um dos motivos pelos quais arquitetos de sistemas estudam cuidadosamente o tamanho ideal da UOW.


O segredo dos Locks

Outro mistério.

Muitos acreditam:

READ UPDATE

↓

REWRITE

↓

Registro liberado

Não.

O lock continua.

Somente o commit libera.

Isso explica diversos problemas de contenção.

Enquanto uma transação segura um registro...

Outra precisa esperar.


ENQ, DEQ e SYNCPOINT

Lembra dos comandos ENQ e DEQ?

Eles são parentes próximos do SYNCPOINT.

Imagine uma biblioteca.

Você pega um livro raro.

Enquanto ele está emprestado ninguém mais pode utilizá-lo.

O ENQ reserva.

O DEQ devolve.

Já o SYNCPOINT garante que todo o processo envolvendo aquele livro foi concluído corretamente antes de liberar os demais recursos associados à transação.

São mecanismos diferentes, mas frequentemente trabalham em harmonia para preservar a consistência da aplicação.


E se o computador desligar?

Essa é uma das perguntas favoritas das entrevistas IBM.

Imagine:

UPDATE DB2

↓

UPDATE VSAM

↓

Queda de energia

O CICS consulta seus registros de recuperação.

Percebe que aquela Unit of Work nunca terminou.

Resultado?

Backout automático.

O usuário talvez nem perceba.

Esse comportamento é uma das razões pelas quais bancos confiam no CICS há mais de cinco décadas.


A ligação com o DB2

Quando DB2 participa da transação, ele também espera.

Nenhuma alteração fica permanente até que o SYNCPOINT seja executado.

É como vários cofres aguardando a mesma chave.

Somente quando a chave gira...

Todos são fechados simultaneamente.


VSAM também participa

Da mesma forma:

READ UPDATE

↓

REWRITE

↓

DELETE

↓

WRITE

Tudo permanece dentro da mesma Unit of Work.

O VSAM somente considera as alterações definitivamente concluídas quando o CICS encerra a transação com sucesso.


O relacionamento com HANDLE ABEND

Em artigos anteriores vimos o HANDLE ABEND.

Agora tudo faz sentido.

HANDLE ABEND

↓

Erro inesperado

↓

Rotina de recuperação

↓

SYNCPOINT ROLLBACK

↓

RETURN

Observe como as peças começam a formar um quebra-cabeça.

O conhecimento em CICS é cumulativo.

Cada comando reforça o entendimento do anterior.


Curiosidade Histórica

Nos primeiros anos do CICS, quando bancos começaram a abandonar sistemas baseados em processamento puramente batch para operações online, um dos maiores medos era exatamente este:

"E se o sistema cair no meio de uma transferência?"

Foi o amadurecimento dos mecanismos de recuperação, journals, locks e SYNCPOINT que permitiu o crescimento dos caixas eletrônicos, do internet banking e, décadas mais tarde, dos aplicativos móveis.

Cada saque em um caixa eletrônico, cada pagamento de boleto e cada transferência eletrônica dependem, direta ou indiretamente, desses princípios.


Curiosidade Técnica

Você provavelmente já ouviu falar nas propriedades ACID dos bancos de dados.

O SYNCPOINT é uma das peças fundamentais que ajuda a concretizar esses princípios dentro do ambiente transacional do CICS:

  • Atomicidade: tudo acontece ou nada acontece.

  • Consistência: os dados permanecem válidos.

  • Isolamento: outras transações não enxergam alterações incompletas.

  • Durabilidade: após o commit, as mudanças sobrevivem até mesmo a falhas do sistema.


Dicas para quem está aprendendo COBOL+CICS

✔ Sempre pense em termos de negócio, não apenas de comandos.

✔ Antes de programar pergunte:

"Se ocorrer um erro aqui... o que deve voltar?"

✔ Nunca esqueça que REWRITE não significa commit.

✔ Aprenda a visualizar uma Unit of Work inteira antes de escrever uma linha de código.

✔ Conheça RESP e RESP2 para tratar erros antes de decidir entre continuar ou executar um rollback.

✔ Estude os journals e os mecanismos de recuperação. Eles raramente aparecem nos primeiros cursos, mas fazem enorme diferença para compreender como o CICS realmente funciona.


Easter Egg Bellacosa ☕

Existe uma antiga lenda entre programadores veteranos de mainframe.

Dizem que, nas madrugadas em que o CPD está silencioso e apenas o z/OS continua trabalhando, é possível imaginar um enorme carimbo invisível passando de transação em transação.

Cada vez que um SYNCPOINT é executado com sucesso, esse carimbo marca silenciosamente:

"Integridade preservada."

Ninguém vê.

Nenhum operador escuta.

Nenhuma tela 3270 exibe essa mensagem.

Mas, graças a esse "carimbo invisível", milhões de pessoas acordam pela manhã e encontram seus saldos bancários exatamente onde deveriam estar.

Talvez esse seja o maior elogio que uma tecnologia possa receber: funcionar tão bem que quase ninguém percebe sua existência.


O Arquivo Confidencial Bellacosa

Nome do Caso: O Carimbo Invisível

Suspeitos: REWRITE, WRITE, DELETE, UPDATE, DB2, VSAM

Investigador Principal: CICS Transaction Manager

Juiz da Operação: SYNCPOINT

Plano de Fuga: SYNCPOINT ROLLBACK

Cúmplices: Journals, Locks, Unit of Work, Resource Managers

Veredito Final: Nenhuma transação recuperável deve terminar pela metade.


Conclusão

O SYNCPOINT é muito mais do que um simples comando do CICS. Ele representa a fronteira entre o provisório e o permanente, entre uma alteração ainda reversível e uma decisão definitiva. É ele quem encerra a Unit of Work, confirma atualizações em recursos como Db2, VSAM, filas recuperáveis e outros gerenciadores de recursos, libera bloqueios e garante que todas as partes da transação caminhem juntas.

Seu contraponto, o SYNCPOINT ROLLBACK, oferece ao sistema a capacidade de voltar atrás quando algo inesperado acontece, preservando a integridade dos dados e evitando inconsistências que poderiam comprometer operações críticas.

Quando um programador COBOL entende verdadeiramente conceitos como READ UPDATE, REWRITE, ENQ, DEQ, HANDLE ABEND, journals, locks, Unit of Work e SYNCPOINT, ele deixa de apenas escrever programas e passa a compreender a engenharia invisível que mantém bancos, seguradoras, companhias aéreas e grandes empresas funcionando de forma confiável há décadas.

No fim das contas, o maior mistério do CICS nunca foi sua velocidade, nem sua idade, nem mesmo sua capacidade de processar milhões de transações por segundo.

O verdadeiro mistério é que, enquanto o mundo dorme, um pequeno comando com apenas nove letras continua decidindo, silenciosamente, o destino de fortunas, contratos, reservas de voo, prontuários médicos e incontáveis operações críticas.

E como diria Augusto Bellacosa ao terminar mais uma xícara de café diante do brilho esverdeado de um terminal 3270:

"Programas escrevem dados. Transações escrevem confiança. E confiança... sempre termina com um SYNCPOINT."

segunda-feira, 13 de maio de 2019

🎭 OS 7 ARQUÉTIPOS PSICOLÓGICOS DOS ANIMES — A PSIQUE JAPONESA EM FRAMES E PIXELS

 

Bellacosa Mainframe e os arquitetipos femininos nos animes

🎭 OS 7 ARQUÉTIPOS PSICOLÓGICOS DOS ANIMES — A PSIQUE JAPONESA EM FRAMES E PIXELS
por Bellacosa Mainframe – edição El Jefe Midnight


Os animes não são apenas entretenimento. São espelhos da alma japonesa — e, por extensão, da nossa também.
Cada personagem que amamos, odiamos ou estranhamos é um dataset simbólico, um pedaço da psique humana processado em arte.

Por trás de cada “kawaii”, “baka” e olhar que brilha, há um código emocional que traduz a forma japonesa de lidar com o mundo: a tensão entre o que se sente e o que se pode mostrar.

Vamos decodificar juntos esses padrões — os 7 arquétipos psicológicos mais recorrentes dos animes, com direito a curiosidades, comportamento, filosofia e aquele toque Bellacosa Mainframe de reflexão e ironia sutil.


💥 1. O Herói Resiliente — O Job que Nunca Termina

Exemplo: Naruto, Luffy, Deku (My Hero Academia)

O herói shōnen é a alma persistente do Japão: ele apanha, erra, sofre — mas nunca cancela o job.
É o reflexo do valor cultural do ganbaru: o esforço contínuo, mesmo quando não há garantia de vitória.
Ele simboliza o trabalhador japonês que acredita que o mérito vem da perseverança, não do resultado.

“Falhar não é o problema. Parar de tentar é que gera abend.”

Curiosidade: as bandas sonoras desses animes são compostas para aumentar o batimento cardíaco — literalmente inspirando resiliência física e emocional.


🌸 2. A Tsundere — O Firewall Emocional

Exemplo: Asuka (Evangelion), Taiga (Toradora), Misaki (Kaichou wa Maid-sama)

A tsundere é o clássico caso de “sinto muito, mas nego tudo”.
Por fora, arrogância. Por dentro, vulnerabilidade.
É o espelho da repressão emocional japonesa — o medo de mostrar carinho e perder o controle social.

Na prática, a tsundere é o RACF do afeto: só abre permissão de READ/WRITE depois de inúmeros testes de segurança (e vergonha).

“Amor, no Japão, é sempre compilado em silêncio.”

Easter-egg: “tsun” vem de tsuntsun (desprezar) e “dere” de deredere (apaixonada) — dois modos de operação da alma japonesa.


🧘 3. O Sensei Misterioso — O SYSADM Espiritual

Exemplo: Jiraiya (Naruto), Urahara (Bleach), Zoro em modo mentor

É o personagem que carrega sabedoria, humor e dor em doses iguais.
Ele representa o senpai da vida — aquele que já falhou tanto que virou filosofia.
Costuma rir quando os outros choram, e ensinar sem ensinar.

Na mente japonesa, ele é o símbolo do equilíbrio entre honra e desapego, o monge e o programador que aceitam o bug da existência sem pânico.

“Quem domina o próprio erro, domina o sistema.”

Curiosidade: muitos “senseis” têm elementos de arquétipos zen, como o koan — o ensinamento que parece confuso, mas revela algo profundo no silêncio.


🔮 4. O Anti-Herói — O Batch Sombrio

Exemplo: Light Yagami (Death Note), Lelouch (Code Geass), Eren Yeager (Attack on Titan)

Esses personagens desafiam o sistema. São o abend intencional da narrativa.
Eles surgem do cansaço com o conformismo — da vontade de romper com as regras, mesmo que isso destrua o próprio ideal.

Simbolizam o lado oculto do Japão moderno: a rebeldia silenciosa contra a obediência cega.

“Quando o sistema é injusto, o erro vira protesto.”

Curiosidade: na década de 2000, o Japão passou por um aumento real de jovens isolados (hikikomori), e muitos roteiristas usaram o anti-herói como espelho dessa frustração coletiva.


🐾 5. O Mascote Kawaii — O Processo de Alívio de Carga

Exemplo: Totoro, Pikachu, Mokona, Chopper

Nenhum anime é completo sem o mascote que quebra a tensão.
Eles são os “garbage collectors” da emoção — purificam o clima, equilibram o drama.
Na psique japonesa, o “kawaii” (fofo) é uma resposta social à dureza do cotidiano.

“Entre um deadline e outro, o Japão inventou o Pikachu.”

Curiosidade: o termo kawaii culture virou objeto de estudo sociológico — uma forma de resistência suave, quase terapêutica, à pressão adulta e corporativa.


⚔️ 6. A Guerreira Silenciosa — A Subrotina da Força Interior

Exemplo: Mikasa (Attack on Titan), Saber (Fate), Motoko Kusanagi (Ghost in the Shell)

Ela não grita, não chora, não explica — apenas age.
Carrega o peso do mundo nos ombros, como quem carrega o passado e o dever.
É o arquétipo feminino da disciplina e da honra, um eco moderno do bushido, o código samurai.

“Enquanto o mundo fala, ela executa.”

Easter-egg: o cabelo curto da maioria dessas personagens é símbolo de corte de laços — um gesto tradicional japonês de recomeço ou desapego.


🧩 7. O Amigo Inseparável — O Backup Emocional

Exemplo: Krillin (Dragon Ball), Killua (Hunter x Hunter), Shikamaru (Naruto)

O suporte, o confidente, o alívio cômico — mas também o espelho do protagonista.
Ele representa a amizade como estrutura de identidade, algo profundamente japonês: o grupo sempre vem antes do indivíduo.

“No Japão, até o herói precisa de um cluster emocional.”

Curiosidade: a morte do “melhor amigo” é um tropo recorrente — uma forma simbólica de mostrar o amadurecimento emocional do protagonista.


☕ Epílogo Bellacosa

Os animes são o mainframe emocional do Japão: cada arquétipo é um programa rodando há séculos, traduzindo as dores, as pressões e os sonhos de um povo que aprendeu a sorrir por dentro.

E nós, espectadores ocidentais, sintonizamos nesse servidor global de sentimentos, reconhecendo nas entrelinhas algo que também é nosso:
a vontade de ser livre, de amar sem culpa e de encontrar sentido no caos.

“Animes não são sobre fantasia. São sobre a verdade — contada por quem aprendeu a sonhar em silêncio.” 🌸

 

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