Translate

quinta-feira, 15 de maio de 2025

🔥 CICS Mainframe — As Últimas Grandes Releases (Linha do Tempo Mítica)

 


🔥 CICS Mainframe — As Últimas Grandes Releases (Linha do Tempo Mítica)


Nota: a IBM evolui o CICS através de releases principais (major), com novidades, foco em produtividade, segurança e modernização contínua. Este índice usa datas de general availability históricas e o que cada versão trouxe de mais bacana, junto com curiosidades e contexto técnico.


🧠 Como ler este índice Bellacosa

Cada item abaixo tem:

Versão e versão legível
Data de lançamento (GA / Generally Available)
Fim do ciclo de suporte (quando aplicável)
Principais novidades
Comentários Bellacosa



🔟 1) CICS Transaction Server for z/OS 5.1

📅 GA: ~3 out 2012
📌 Fim de Vida: já fora de serviço
Principais novidades: foco em eficiência operacional e service agility — foi grande passo para integração com padrões web e automação.
💬 Bellacosa comenta: primeira versão que rompeu claramente com legado puro, abrindo portas para aplicativos modernos.


2) CICS TS 5.2

📅 GA: 7 abr 2014
📌 Fim de Vida: fora de serviço
Novidades: melhorias em SOA, JSON e REST, suporte a mobilidade e service delivery.
💬 Coffeelore: a galera bancária vibrou — finalmente dava pra integrar com apps modernos sem sacrificar velocidade.


3) CICS TS 5.3

📅 GA: 5 out 2015
📌 Fim de Vida: 31 dez 2021
Novidades: DevOps no mainstream, métricas expandidas, simplicidade de gestão e segurança mais firme.
🐣 Easteregg: a versão que “pegou fogo” por incluir mais de 300 pedidos de clientes!


4) CICS TS 5.4

📅 GA: 16 mai 2017
📌 Fim de Vida: 31 dez 2023
Novidades: Mixed language app-serving, APIs assíncronas potentes, gestão dinâmica e MQ ampliado.
💬 Bellacosa talk: começou a se parecer com um app server corporativo moderno.


5) CICS TS 5.5

📅 GA: 2 out 2018
📌 Fim de Vida: 30 set 2025 (planejado para z/OS?)
Novidades: Suporte a Node.js, GraphQL API, melhor CICS Explorer e segurança.
🔎 Curiosidade: primeira versão com foco explícito em modern workloads (JavaScript e Node).


6) CICS TS 5.6

📅 GA: 12 jun 2020
📌 Fim de Vida: não listado (suporte atual até pelo menos 2025)
Novidades: Experiência do dev, melhorias de resiliência, segurança e gerenciamento.
💬 Bellacosa: aqui o “desenvolvedor CICS” começou a cantar alto — Maven, Spring Boot ligando nativo.


7) CICS TS 6.1

📅 GA: 5 abr 2022
📌 Fim de Vida: não anunciado
Novidades: Produtividade de dev, segurança e gestão modernizada.
📌 Bellacosa insight: versão guardiã — preparou base para zero trust e infra crítica.


8) CICS TS 6.2

📅 GA: 14 jun 2024
📌 Fim de Vida: 30 set 2025
Novidades:

  • Suporte Java 17

  • Node.js 18

  • Contêiner e produtividade

  • Segurança e conformidade reforçada

  • Threadsafe data reads

  • Policy extensões
    🎉 Easteregg: CAFC já tinha day-one support no mesmo dia em 2024!


9) CICS TS 6.3

📅 GA: 05 set 2025 (confirmado)
📌 Fim de Vida: prevista ~2027/2028, sujeito a IBM SAP policy
Novidades anunciadas:

  • OpenTelemetry distributed tracing

  • Observabilidade e configuração simplificada

  • AI agent ready

  • Java 21, Jakarta EE 10, MicroProfile 6

  • VS Code dev experience

  • Mais segurança Zero Trust

  • Políticas enriquecidas e TLS extendido
    🚀 Bellacosa Spoiler: esta versão é a carta na manga para times que querem CICS moderno de verdade.


🧾 Releases “Ancestrais” (meramente contexto)

Antes da série 5.* e 6.*, houve clássicos que ainda ecoam:

  • CICS TS V3.1 / V3.2 — base sólida de integração e performance nos anos 2000

  • CICS TS V2.x série — primeira expansão empresarial no início dos anos 2000

  • E claro, versões históricas de OS/390 que definiram o padrão corporativo.


🧠 Linha do tempo Bellacosa (Resumo de Open e End of Life)

VersãoGAEnd of Life / EOSDestaque
5.12012EoS passadoAgilidade operacional
5.22014EoS passadoSOA / JSON / mobile
5.320152021DevOps e métricas
5.420172023Mixed-language & async
5.520182025+Node.js & GraphQL
5.62020suporteDev + Resiliência
6.12022suporteProdutividade & segurança
6.220242025Modern app support
6.32025futuroObservability & AI readiness

(EOS = End of Service; marcas com * estarão no manual oficial IBM Lifecycle)


🎓 Bellacosa Insights & Eastereggs

CICS nunca morre: a cada release, CICS não “recomeça”, ele amplia — ampliando suporte a linguagens modernas, contêineres e infra corporativa.
🐣 Dev-centric shift: CICS TS 5.5+ foi a transição de “sistema OLTP puro” para plataforma de desenvolvimento moderna.
🧠 Continuous delivery: além dos grandes marcos, IBM injeta capacidades via APAR e continuous delivery entre versões.


🚀 Conclusão Bellacosa

CICS segue vivo e evoluindo com:

Modernização para nuvem e contêiner
🔐 Segurança Zero Trust
📊 Observabilidade distribuída (OpenTelemetry)
🛠️ Experiência de desenvolvimento integrada (VS Code)

🔥 Lição de casa: dominar CICS TS não é conhecer versões — mas saber o que cada release habilita em arquitetura, dev experience e operações.

quarta-feira, 14 de maio de 2025

☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

Bellacosa Mainframe e a ajuda do watsonx no mainframe


☕ O Holocron da Inteligência de Dados: Por que a IA Não Entende seu COPYBOOK e Como o watsonx.data Está Tentando Resolver Isso

"Muitos Padawans acreditam que Inteligência Artificial significa apenas conversar com um chatbot. Os Mestres sabem que a verdadeira batalha acontece muito antes: na compreensão dos dados."


Introdução – O Dia em que o Padawan Descobriu que a IA Não Sabia o que era um PIC X(10)

Imagine a seguinte cena.

Você é um programador COBOL júnior.

Recebe a missão de modernizar uma aplicação bancária construída há quase quarenta anos.

O gerente de inovação aparece sorrindo.

— Vamos colocar IA nisso.

Você pensa:

— Fácil. Basta enviar os dados para um modelo generativo.

Então encontra o seguinte layout:

01 CLIENTE-REG.
   05 CLI-NUMERO        PIC 9(09).
   05 CLI-NOME          PIC X(40).
   05 CLI-RENDA-LIQ     PIC S9(07)V99.
   05 CLI-SITUACAO      PIC X.

A IA observa aquilo.

E responde:

Não faço ideia do que seja CLI-RENDA-LIQ.

Nesse momento, o Padawan aprende uma das maiores lições da Engenharia de Dados moderna.

IA não entende tabelas.

IA entende contexto.

E é exatamente aqui que entra o conceito de Data Intelligence.


Durante muitos anos, empresas compraram ferramentas separadas

O mercado tradicional funcionava assim.

Equipe de Governança:

Possui uma ferramenta.

Equipe de Qualidade:

Possui outra.

Equipe de Catálogo:

Possui outra.

Equipe de Linhagem:

Mais uma.

Equipe de Compliance:

Outra plataforma.

Equipe de Segurança:

Mais uma solução.

Resultado?

Cinco contratos.

Cinco bancos de metadados.

Cinco interfaces.

Cinco APIs.

Cinco equipes discutindo.

Algo parecido com isto:

Governança
     │
Qualidade
     │
Lineage
     │
Catálogo
     │
Compliance
     │
IA

Parece organizado.

Mas na prática é um enorme spaghetti corporativo.


O que a IBM percebeu

A IBM começou a observar um padrão interessante.

As perguntas feitas pelas equipes eram sempre parecidas.

Governança pergunta

Quem é o dono?

Quem aprovou?

Quem pode acessar?


Qualidade pergunta

Posso confiar?

Está completo?

Possui erros?


Lineage pergunta

De onde veio?

Quem alterou?

Qual programa produz?


IA pergunta

O que significa?

Posso usar?

Existe restrição?

Na realidade, todas essas perguntas falam sobre a mesma coisa.

Conhecimento sobre os dados.


A pilha do watsonx.data intelligence

Podemos imaginar a arquitetura como um holocron dividido em cinco camadas.


Primeira camada

Hybrid Cloud Platform

É a fundação.

Conecta:

Db2

Oracle

SAP

Snowflake

MongoDB

Kafka

AWS

Azure

IBM Z

IMS

VSAM

CICS

É como um grande tradutor universal.


Segunda camada

Data Governance

O catálogo corporativo.

Aqui ficam armazenadas informações como:

Campo:

CPF

Classificação:

PII

Sensível:

Sim

LGPD:

Aplicável

Owner:

Área Financeira


Terceira camada

Data Quality

Pergunta simples.

Posso confiar?

Exemplo.

Esperado:

CPF válido

99,99%

Encontrado:

88%

Problema detectado.


Quarta camada

Data Lineage

Talvez a mais fascinante.

Permite responder:

De onde veio?

Imagine:

COBOL

VSAM

DFSORT

Db2

Kafka

Data Lake

LLM

Tudo rastreado.


Quinta camada

Data Product Hub

Talvez seja a ideia mais moderna.

Os dados deixam de ser arquivos.

Viram produtos.

Exemplo.

Produto:

Customer360

Contém:

Dados cadastrais

Histórico

Score

Endereços

Risco

Consumidores:

Fraude

CRM

Analytics

IA


Um exemplo para o Programador COBOL Jr.

Imagine este campo.

05 CLI-RENDA-LIQ PIC S9(07)V99.

Você sabe o que significa.

Mas a IA não.

Precisamos adicionar conhecimento.

Nome comercial:

Renda Líquida Mensal

Descrição:

Valor recebido após descontos.

Periodicidade:

Mensal

Sensibilidade:

Alta

Origem:

Programa COBCL001

Arquivo:

CLIENTES.KSDS

Consumidores:

CRM

Motor de crédito

Modelo IA

Agora sim.

A IA consegue responder.

Pergunta:

"Qual renda média dos clientes premium?"

Resposta:

Campo identificado.

Qualidade validada.

Autorização concedida.

Origem conhecida.

Consulta realizada.


E o Mainframe?

Aqui está a parte que mais interessa ao leitor Bellacosa Mainframe.

O IBM Z sempre teve metadados.

Só nunca os chamamos assim.

O catálogo Db2

É metadado.


Copybooks

São metadados.


RACF

É metadado.


JCL

É metadado.


DBD IMS

É metadado.


SMF

É metadado.


SYS1.PARMLIB

Também.

Durante décadas, o Mainframe guardou informações valiosíssimas.

O problema é que elas estavam dispersas.

E não eram consumidas por modelos de IA.


O novo ouro das empresas

Muitos acreditam que o ativo mais importante seja o modelo generativo.

Não é.

Modelos podem ser trocados.

GPT.

Granite.

Llama.

Mistral.

Claude.

O diferencial competitivo está em algo muito mais difícil.

Os metadados.

Porque representam conhecimento acumulado.

Décadas de regras de negócio.

Decisões.

Políticas.

Histórico.

Governança.

É aquilo que impede uma IA de produzir respostas brilhantes e completamente erradas.


Conselhos para o Padawan COBOL

Se você está iniciando sua jornada no IBM Z, comece a olhar seus programas de outra forma.

Não enxergue apenas instruções COBOL.

Enxergue conhecimento de negócio.

Documente copybooks.

Padronize nomes.

Descreva regras.

Mantenha linhagem.

Entenda quem consome seus dados.

Aprenda governança.

Estude LGPD.

Conheça APIs.

Explore Data Mesh.

Entenda catálogos modernos.

Porque o profissional mais valorizado da próxima década talvez não seja aquele que apenas programa COBOL.

Será aquele capaz de explicar para uma Inteligência Artificial o significado dos cinquenta anos de sabedoria escondidos dentro de um simples:

05 CLI-RENDA-LIQ PIC S9(07)V99.

E quando esse dia chegar, o velho programador COBOL descobrirá algo surpreendente.

Ele nunca foi apenas um codificador.

Ele sempre foi o guardião dos holocrons de dados da empresa.

Espero que este artigo ajude o Padawan COBOL a perceber que Data Intelligence é, em grande parte, a evolução natural da disciplina que o Mainframe pratica há décadas: conhecer profundamente a origem, o significado, a qualidade e a responsabilidade de cada byte armazenado no sistema corporativo.


terça-feira, 13 de maio de 2025

O Paciente Vibe Coding: IA, COBOL e o Dia em que Programar Virou Conversar com a Máquina

Bellacosa Mainframe e a vibe coding

☕ Um Café no Bellacosa Mainframe

O Paciente Vibe Coding: IA, COBOL e o Dia em que Programar Virou Conversar com a Máquina

Imagine a seguinte cena.

São duas da manhã.

O CPD está silencioso.

Algumas luzes piscam no rack.

O JES2 continua recebendo jobs como se nada tivesse acontecido.

O Db2 segue trabalhando.

O CICS atende transações.

E em algum lugar existe um programador COBOL iniciante olhando para uma tela e pensando:

— Eu preciso mesmo aprender tudo isso?

Antes que alguém responda, a porta da sala se abre.

Entra um médico de sistemas.

Não usa estetoscópio.

Usa um terminal 3270.

Olha para o paciente.

O paciente é um jovem sistema chamado:

VIBE CODING.

Sintomas:

  • cria programas apenas com descrições;

  • escreve código em segundos;

  • corrige erros automaticamente;

  • às vezes inventa coisas que não existem;

  • parece extremamente inteligente;

  • eventualmente faz besteiras monumentais com absoluta confiança.

Diagnóstico preliminar:

Síndrome Aguda de Inteligência Artificial Assistida por Linguagem Natural.

Prognóstico:

Pode transformar completamente a programação.

Também pode destruir seu ambiente se você acreditar em tudo que ele diz.

Como qualquer bom médico de sistemas diria:

O código não mente.
Mas quem gera código pode estar errado.

E é exatamente aqui que começa nossa investigação.


1. Afinal, o que é Vibe Coding?

Vibe Coding é uma maneira de construir software utilizando principalmente linguagem natural.

Em vez de começar escrevendo código linha por linha, você descreve o que deseja.

Por exemplo:

Crie uma aplicação que permita cadastrar clientes, consultar saldo, fazer transferências e gerar um histórico de movimentações.

A Inteligência Artificial interpreta essa descrição e começa a criar:

  • arquivos;

  • funções;

  • classes;

  • banco de dados;

  • APIs;

  • páginas;

  • testes;

  • documentação;

  • scripts de instalação.

Você não está necessariamente programando no sentido tradicional.

Você está orientando a construção do software.

Essa diferença parece pequena.

Não é.

Durante décadas o processo normalmente era:

IDEIA
 ↓
REQUISITO
 ↓
ANÁLISE
 ↓
DESENHO
 ↓
CÓDIGO
 ↓
COMPILAÇÃO
 ↓
ERRO
 ↓
CORREÇÃO
 ↓
TESTE
 ↓
PRODUÇÃO

Com ferramentas baseadas em Inteligência Artificial, parte disso pode acontecer em uma conversa:

IDEIA
 ↓
PROMPT
 ↓
IA
 ↓
CÓDIGO
 ↓
TESTE
 ↓
CORREÇÃO

Em sistemas mais sofisticados:

OBJETIVO
 ↓
AGENTE IA
 ↓
PLANEJAMENTO
 ↓
IMPLEMENTAÇÃO
 ↓
TESTES
 ↓
AVALIAÇÃO
 ↓
CORREÇÃO
 ↓
NOVA TENTATIVA

É uma mudança de paradigma.


2. Quem inventou esse negócio?

O termo Vibe Coding ganhou popularidade em 2025 associado a Andrej Karpathy, conhecido por seu trabalho em Inteligência Artificial e redes neurais.

A expressão possui uma certa dose de brincadeira.

A ideia seria mais ou menos:

Você explica a "vibe" do que quer construir e deixa a IA resolver os detalhes.

Não quer dizer que ninguém escrevia código com IA antes.

GitHub Copilot, ChatGPT e ferramentas semelhantes já estavam sendo utilizados.

A diferença foi dar um nome a uma nova atitude diante da programação.

Não é apenas:

“IA, complete essa função.”

É algo mais próximo de:

“IA, faça esse sistema funcionar.”

Existe uma enorme diferença entre as duas frases.

Na primeira, a IA é assistente.

Na segunda, ela começa a assumir uma parcela muito maior da engenharia.


3. O programador COBOL encontra o Vibe Coding

Agora imagine alguém começando em COBOL.

Ele aprende:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

PROCEDURE DIVISION.

    DISPLAY 'HELLO WORLD'.

    STOP RUN.

Depois aprende:

WORKING-STORAGE SECTION.

01 WS-IDADE PIC 9(03).

PROCEDURE DIVISION.

    MOVE 25 TO WS-IDADE.

    IF WS-IDADE >= 18
        DISPLAY 'MAIOR DE IDADE'
    END-IF.

Depois aparecem:

  • arquivos sequenciais;

  • VSAM;

  • JCL;

  • Db2;

  • CICS;

  • IMS;

  • MQ;

  • RACF;

  • LE;

  • JES2;

  • datasets;

  • abends.

O jovem programador começa a suspeitar que escolheu a profissão errada.

Então aparece uma IA.

Ele pergunta:

Crie um programa COBOL que leia um arquivo de clientes e exiba apenas registros ativos.

A IA escreve algo.

O iniciante olha.

E pensa:

— Pronto. Acabou a profissão.

Não.

Calma.

Esse é o primeiro erro de diagnóstico.


4. IA gerar COBOL não significa IA entender seu mainframe

Essa distinção é fundamental.

Uma IA pode gerar:

READ ARQ-CLIENTES
    AT END
        SET EOF TO TRUE
    NOT AT END
        IF STATUS-CLIENTE = 'A'
            DISPLAY NOME-CLIENTE
        END-IF
END-READ

Isso é relativamente simples.

Agora diga:

Este programa participa do fechamento contábil de um banco, roda dentro de uma cadeia de 430 jobs, utiliza arquivos GDG, acessa Db2, envia mensagens MQ e precisa terminar antes das 05:40 porque às 06:00 começa a compensação.

Bem-vindo à medicina intensiva.

A IA pode conhecer:

  • COBOL;

  • JCL;

  • Db2;

  • MQ.

Mas talvez não conheça:

  • sua operação;

  • suas dependências;

  • seus datasets;

  • seus SLAs;

  • seus procedimentos;

  • suas convenções;

  • seus controles;

  • sua arquitetura histórica.

É aqui que o especialista humano continua essencial.


5. A grande ilusão: “a IA sabe programar”

É verdade.

E não é.

A IA é extraordinariamente boa em reconhecer padrões.

Se você disser:

Faça uma API REST de clientes em Java.

Ela provavelmente escreverá algo muito convincente.

Se disser:

Crie uma classe Python para acessar PostgreSQL.

Também.

Se disser:

Faça um JCL para executar um SORT.

Provavelmente também.

Mas existe uma diferença gigantesca entre:

gerar código plausível

e

garantir que esse código é correto no seu ambiente.

Esse é um dos pontos mais importantes deste artigo.

Uma IA pode produzir algo que:

  • compila;

  • executa;

  • parece bonito;

  • passa por testes simples;

e ainda assim está conceitualmente errado.


6. O sintoma mais perigoso: código convincente

Imagine um médico olhando um exame errado e dizendo com total segurança:

— Perfeito. O paciente está ótimo.

Esse é o equivalente técnico de uma IA produzindo código incorreto com aparência profissional.

Chamamos isso frequentemente de alucinação.

Por exemplo, a IA pode sugerir:

IBM.CICS.AUTO.REPAIR

como se fosse um parâmetro real.

Você procura.

Não existe.

Ou sugerir uma API.

Você abre a documentação.

Também não existe.

O modelo não está conscientemente mentindo.

Ele está produzindo uma sequência de palavras estatisticamente plausível.

Em desenvolvimento tradicional, o compilador geralmente avisa:

EI, ISSO NÃO EXISTE.

Mas alguns erros não aparecem na compilação.

Esse é o verdadeiro perigo.


7. Um programa pode funcionar e continuar errado

Considere:

COMPUTE WS-JUROS =
    WS-SALDO * 0.10

Perfeitamente válido.

Compila.

Executa.

Mas e se a taxa deveria ser:

0.01

O compilador não pode ajudar.

A IA também não pode saber, a menos que alguém informe.

Estamos falando de regra de negócio.

Esse é o coração de sistemas corporativos.

Programadores mainframe sabem disso muito bem.

Frequentemente o maior valor de um programa COBOL não está no código.

Está no conhecimento incorporado nele.

Pode existir uma regra escrita em 1989 que diz:

IF TIPO-CONTA = 17
   AND REGIAO = '03'
   AND DATA-MOVIMENTO < 19980101
       PERFORM ROTINA-ESPECIAL.

Por quê?

Ninguém sabe.

Apague.

Três dias depois metade da contabilidade explode.

E alguém aparece dizendo:

— Ah... isso existia por causa da fusão de 1997.

Esse tipo de conhecimento contextual ainda é um enorme desafio para sistemas de IA.


8. A história está se repetindo

Vamos voltar no tempo.

Na década de 1950, programação era extremamente próxima do hardware.

Imagine escrever instruções como:

LOAD
MOVE
ADD
JUMP
STORE

Então vieram linguagens de alto nível.

FORTRAN.

COBOL.

ALGOL.

Programadores Assembly reclamaram.

Provavelmente alguém disse:

Isso não é programação de verdade.

Décadas depois apareceu C.

Depois C++.

Depois Java.

Depois Python.

Depois frameworks.

Depois low-code.

Depois no-code.

Depois assistentes de IA.

Agora Vibe Coding.

Observe:

CÓDIGO DE MÁQUINA
        ↓
ASSEMBLY
        ↓
LINGUAGENS DE ALTO NÍVEL
        ↓
FRAMEWORKS
        ↓
LOW-CODE
        ↓
IA
        ↓
LINGUAGEM NATURAL

Cada camada abstrai alguma complexidade anterior.


9. COBOL já era uma forma ancestral de Vibe Coding?

Aqui temos uma bela curiosidade.

COBOL significa:

COmmon Business-Oriented Language.

Uma das filosofias da linguagem era facilitar a expressão de regras comerciais de forma relativamente próxima do inglês.

Compare Assembly:

L R1,VALUE1
A R1,VALUE2
ST R1,TOTAL

com COBOL:

ADD VALUE1 VALUE2
    GIVING TOTAL.

Agora compare com linguagem natural:

Some VALUE1 e VALUE2 e guarde em TOTAL.

A trajetória é evidente.

Talvez possamos brincar dizendo:

Assembly
 ↓
COBOL
 ↓
Prompt

Grace Hopper talvez olhasse para isso com bastante curiosidade.


10. Easter Egg: Grace Hopper entra na sala

Imagine Grace Hopper entrando no laboratório.

Um programador moderno mostra:

Crie um programa para calcular salários.

A IA gera COBOL.

Hopper observa.

Fica alguns segundos em silêncio.

Então provavelmente perguntaria:

— E quem valida o resultado?

Silêncio.

Esse talvez seja o principal conselho do Vibe Coding.

Nunca confunda geração com validação.


11. Prompt é o novo requisito?

Em parte.

Veja este prompt:

Faça um sistema bancário.

Resultado provável:

caos.

Agora:

Desenvolva uma aplicação bancária simples com cadastro de clientes, contas correntes, depósitos e transferências. Use autenticação, registre auditoria das operações, impeça saldo negativo e crie testes unitários para depósitos e transferências.

Muito melhor.

Agora evolua:

Nenhuma transferência pode ocorrer sem validação de saldo. Toda operação deve possuir timestamp, identificador de transação e trilha de auditoria. Operações superiores a R$ 10.000 devem ser registradas separadamente para análise.

Agora temos algo parecido com especificação.

O que aconteceu?

Você fez engenharia de requisitos.

Por isso existe uma ironia interessante.

A IA pode tornar o analista de sistemas ainda mais importante.


12. O melhor Vibe Coder talvez não seja o melhor digitador

Imagine dois profissionais.

Programador A:

digita 120 palavras por minuto.

Conhece a sintaxe inteira de Java.

Programador B:

entende profundamente:

  • arquitetura;

  • negócio;

  • segurança;

  • testes;

  • observabilidade;

  • infraestrutura.

Com IA gerando código, quem possui maior vantagem?

Provavelmente B.

Porque o gargalo muda.

Antes era:

Como escrever?

Agora começa a ser:

O que precisa ser feito?

E depois:

Como saber que está correto?


13. A nova profissão: programador como supervisor

Imagine uma oficina.

Antes:

HUMANO
 ↓
FAZ TUDO

Com IA:

HUMANO
 ↓
PLANEJA
 ↓
IA IMPLEMENTA
 ↓
HUMANO REVISA
 ↓
IA CORRIGE

O profissional muda de artesão puro para algo parecido com:

  • arquiteto;

  • supervisor;

  • revisor;

  • engenheiro;

  • operador.

Isso não significa que programação desaparece.

Significa que escrever código manualmente deixa de ocupar 100% do processo.


14. O programador júnior de velocidade absurda

Uma analogia muito útil é pensar na IA como um programador júnior com características bizarras.

Ele:

  • leu milhões de programas;

  • digita instantaneamente;

  • conhece centenas de linguagens;

  • nunca fica cansado;

  • trabalha 24 horas;

  • gera documentação;

  • escreve testes.

Mas possui um pequeno problema.

Às vezes inventa coisas.

E frequentemente não conhece seu ambiente.

Portanto você precisa dizer:

Não altere essa interface.

Não adicione dependências.

Preserve compatibilidade.

Use COBOL Enterprise 6.x.

O arquivo possui RECFM=FB.

LRECL=120.

Não altere o layout.

Quanto mais contexto correto você oferece, melhor.


15. Contexto é combustível

Dizer:

Corrija meu programa.

é pouco.

Dizer:

Este programa COBOL Enterprise 6.3 roda em z/OS, lê um VSAM KSDS pelo campo chave CLIENT-ID e recebe dados de CICS através de COMMAREA. O erro ocorre quando CLIENT-ID não existe.

é muito melhor.

A IA agora possui:

  • linguagem;

  • plataforma;

  • acesso;

  • estrutura;

  • condição do erro.

Resultado tende a melhorar drasticamente.


16. Vibe Coding e ferramentas modernas

O fenômeno cresceu porque surgiram ferramentas capazes de juntar diferentes capacidades.

Em vez de apenas gerar um trecho de código, ambientes modernos conseguem:

  1. ler o projeto;

  2. entender arquivos;

  3. alterar código;

  4. executar comandos;

  5. testar;

  6. examinar erros;

  7. corrigir;

  8. repetir.

Ferramentas conhecidas passaram a oferecer diferentes versões desse modelo.

Cursor.

Replit.

Lovable.

GitHub Copilot.

Windsurf.

Ambientes com agentes de programação.

O detalhe importante não é a marca.

É a arquitetura.

A IA deixou de ser apenas:

Pergunta → Resposta

e passou a ser:

OBJETIVO
 ↓
AÇÃO
 ↓
RESULTADO
 ↓
ANÁLISE
 ↓
NOVA AÇÃO

17. Isso nos leva aos agentes

Agora entramos em território ainda mais interessante.

Vibe Coding pode evoluir naturalmente para Agentic Coding.

Um agente pode receber:

Corrija o bug no módulo de cadastro.

Então:

  1. lê o código;

  2. encontra a função;

  3. procura logs;

  4. identifica possível causa;

  5. altera código;

  6. cria teste;

  7. executa;

  8. falha;

  9. modifica novamente;

  10. executa;

  11. passa.

Isso é muito mais poderoso que simples geração textual.

É um loop fechado.


18. O loop é fundamental

Considere dois sistemas.

Sistema A:

IA
 ↓
GERA CÓDIGO
 ↓
FIM

Sistema B:

IA
 ↓
GERA
 ↓
TESTA
 ↓
AVALIA
 ↓
CORRIGE
 ↓
TESTA

Sistema B possui uma vantagem gigantesca.

Ele recebe feedback.

Programadores humanos trabalham assim há décadas.

escreve
 ↓
compila
 ↓
erro
 ↓
corrige
 ↓
executa
 ↓
erro
 ↓
corrige

Agentes estão aprendendo exatamente esse ciclo.


19. Só que existe um novo problema

Um agente pode continuar tentando indefinidamente.

Imagine:

tentativa 1
tentativa 2
tentativa 3
tentativa 4
...
tentativa 329

Cada tentativa custa:

  • tokens;

  • CPU;

  • tempo;

  • dinheiro;

  • chamadas de API.

Portanto bons sistemas agentic precisam de limites.

Chamamos isso de guardrails.


20. Guardrails: cercas ao redor do robô

Nunca devemos simplesmente dizer:

Faça o que for necessário.

Principalmente em produção.

Melhor:

Você pode:
- ler código;
- criar testes;
- modificar ambiente DEV.

Você não pode:
- acessar produção;
- alterar RACF;
- deletar datasets;
- executar deploy sem aprovação.

Isso é governança.

No mainframe essa filosofia é familiar.

RACF já existe exatamente porque:

Nem todo usuário deve poder fazer tudo.

Agentes precisam da mesma disciplina.


21. Human-in-the-loop

Outro conceito essencial.

Significa manter seres humanos nos pontos críticos.

Por exemplo:

IA cria alteração
 ↓
IA executa testes
 ↓
IA gera relatório
 ↓
HUMANO APROVA
 ↓
DEPLOY

Isso é muito mais seguro que:

IA teve uma ideia
 ↓
PRODUÇÃO

Qualquer veterano mainframe provavelmente sentiu um arrepio lendo a segunda opção.

Com razão.


22. Vibe Coding não elimina DevOps

Pelo contrário.

Quanto mais rápido produzimos código, mais importantes tornam-se:

  • Git;

  • versionamento;

  • pipeline;

  • testes;

  • code review;

  • segurança;

  • observabilidade.

Imagine gerar 50 alterações em uma hora.

Sem governança, você simplesmente produz bugs mais rápido.

Portanto:

IA + DevOps

faz sentido.

Mas:

IA - DevOps

é receita para desastre.


23. O famoso “funciona na minha máquina”

Com IA ganha uma nova versão:

“Funcionou no ambiente da IA.”

Excelente.

Agora teste:

  • DEV;

  • QA;

  • homologação;

  • integração;

  • produção.

Porque software empresarial possui dependências invisíveis.


24. Exemplo COBOL completo

Imagine um pedido:

Crie um programa COBOL para calcular desconto de clientes VIP.

A IA produz:

IF CLIENTE-VIP = 'S'
    COMPUTE VALOR-FINAL =
        VALOR-COMPRA * 0.90
ELSE
    MOVE VALOR-COMPRA TO VALOR-FINAL
END-IF.

Parece perfeito.

Até o analista perguntar:

— Clientes VIP acima de 60 anos têm desconto adicional?

Silêncio.

E clientes corporativos?

Silêncio.

E compras internacionais?

Silêncio.

E arredondamento monetário?

Silêncio.

É por isso que conhecimento de negócio continua valendo ouro.


25. Easter Egg: o paciente “IF”

Nosso médico olha para o código:

IF CLIENTE-VIP = 'S'

e pergunta:

— Por que?

O programador responde:

— Porque a documentação mandou.

— Quem escreveu?

— Não sei.

— Quando?

— 1996.

— Ainda vale?

— Acho que sim.

O médico sorri.

Esse é o momento em que o caso deixa de ser programação e vira arqueologia corporativa.

Bem-vindo ao mainframe.


26. Vibe Coding pode ajudar iniciantes?

Muito.

Desde que seja utilizado corretamente.

Um iniciante pode perguntar:

Explique este trecho COBOL linha a linha.

Pode pedir:

Mostre como funciona OCCURS.

Depois:

Crie um exemplo usando OCCURS DEPENDING ON.

Depois:

Agora mostre o mesmo conceito utilizando uma tabela de clientes.

Isso cria um tutor personalizado.

É extraordinário.

Mas existe uma regra.

Não apenas copie.

Pergunte:

Por quê?


27. Método Bellacosa para aprender com IA

Experimente este fluxo.

Passo 1 — peça um exemplo simples

Crie um programa COBOL que some dois valores.

Passo 2 — peça explicação

Explique linha por linha.

Passo 3 — altere o problema

Agora leia os valores de um arquivo.

Passo 4 — introduza erro

O que acontece se o arquivo não existir?

Passo 5 — peça produção

Como esse programa seria diferente em ambiente bancário?

Passo 6 — peça testes

Crie casos de teste.

Passo 7 — questione a própria IA

Quais riscos existem no código que você criou?

Isso ensina muito mais do que simplesmente copiar código.


28. Nunca use IA apenas como copiadora

Use-a como:

  • professor;

  • debugger;

  • revisor;

  • colega;

  • explicador;

  • gerador de exemplos.

Uma pergunta poderosa:

Explique esse programa como se eu fosse um programador COBOL iniciante.

Outra:

Agora explique como um sysprog analisaria esse problema.

Outra:

Agora liste possíveis falhas em produção.

Perceba a evolução.

Você está explorando diferentes perspectivas.


29. Segurança merece atenção

Imagine pedir:

Crie uma API de transferência bancária.

A IA talvez produza algo funcional.

Mas segurança exige:

  • autenticação;

  • autorização;

  • validação;

  • criptografia;

  • proteção contra replay;

  • logs;

  • auditoria;

  • rate limiting;

  • tratamento de erros.

E mais.

Código funcional não significa código seguro.

Essa distinção será cada vez mais importante.


30. Observabilidade também

Se sua IA cria um sistema, pergunte:

Como saberei se ele está funcionando?

Você precisa de:

LOGS

MÉTRICAS

TRACES

ALERTAS

No mundo mainframe já utilizamos ferramentas equivalentes há décadas:

  • SMF;

  • RMF;

  • logs;

  • JES;

  • CICS statistics;

  • Db2 accounting;

  • monitors.

Nada disso perde importância com IA.

Na realidade, ganha importância.

Porque sistemas serão modificados mais rapidamente.


31. O futuro pode ser estranho

Talvez daqui alguns anos alguém abra uma IDE e diga:

Temos lentidão no fechamento mensal.

O agente responde:

Analisei SMF, WLM, logs do Db2 e histórico dos últimos seis meses. O tempo médio do job aumentou 23% depois da alteração do índice X. Criei uma mudança de teste em homologação e a execução caiu de 18 para 11 minutos. Deseja revisar?

Isso não é ficção absurda.

É a direção natural da integração entre IA, observabilidade e automação.


32. Então programadores vão desaparecer?

Provavelmente não.

Mas certas tarefas podem diminuir drasticamente.

Especialmente trabalho repetitivo.

Por exemplo:

  • criar CRUD;

  • gerar boilerplate;

  • escrever getters;

  • converter formatos;

  • escrever testes simples;

  • gerar documentação inicial.

Outras tarefas aumentam em importância:

  • arquitetura;

  • regras de negócio;

  • segurança;

  • decisão;

  • integração;

  • diagnóstico;

  • governança.


33. Quem deve ficar preocupado?

Talvez não quem sabe programar.

Talvez quem apenas digita código sem entender por quê.

Isso vale para qualquer tecnologia.

COBOL.

Java.

Python.

JavaScript.

A IA é muito boa em tarefas mecânicas.

Quanto mais seu trabalho depende exclusivamente de tarefas mecânicas, maior a pressão de automação.


34. Quem ganha vantagem?

Profissionais com conhecimento profundo.

Imagine um especialista que entende:

COBOL
+
CICS
+
DB2
+
NEGÓCIO BANCÁRIO
+
DEVOPS
+
IA

Esse profissional não perde valor.

Ele pode multiplicar sua produtividade.

Porque agora possui um exército de assistentes digitais.


35. O verdadeiro Superpoder

Não é escrever prompt bonito.

É saber dizer:

Isso está errado.

Imagine a IA produzindo 500 linhas.

O iniciante pensa:

— Impressionante.

O especialista olha por 30 segundos:

— Essa transação não pode atualizar essas duas tabelas nessa ordem.

Esse conhecimento vale muito.


36. Dica de ouro: peça evidências

Quando a IA recomendar alguma coisa, pergunte:

Por que?

Depois:

Qual documentação suporta isso?

Depois:

Quais alternativas existem?

Depois:

Quais riscos?

Esse pequeno hábito muda completamente a qualidade do trabalho.


37. Dica ainda melhor: peça autocrítica

Depois da IA gerar código:

Revise criticamente o código anterior.

Depois:

Procure vulnerabilidades.

Depois:

Procure race conditions.

Depois:

Procure problemas de performance.

Depois:

Procure problemas de manutenção.

Você transforma a IA em revisora da própria IA.

Não garante perfeição.

Mas aumenta muito a qualidade.


38. A regra das três perguntas

Antes de confiar em código gerado, pergunte:

1. Compila?

2. Funciona?

3. Faz o que deveria fazer?

Essas perguntas parecem iguais.

Não são.

Um programa pode:

COMPILAR = SIM

EXECUTAR = SIM

ESTAR CORRETO = NÃO

Essa distinção é absolutamente fundamental.


39. O paciente melhora

Nosso paciente Vibe Coding está agora sentado na maca.

O médico consulta os exames.

Sintaxe:

Excelente.

Produtividade:

Altíssima.

Velocidade:

Absurda.

Conhecimento contextual:

Variável.

Segurança:

Precisa supervisão.

Confiabilidade:

Depende de validação.

Diagnóstico final:

Ferramenta extremamente poderosa com risco severo de uso irresponsável.

Tratamento recomendado:

IA
+
ENGENHARIA
+
TESTES
+
GOVERNANÇA
+
HUMANO

40. A receita do doutor do mainframe

Para utilizar Vibe Coding sem criar um monstro:

  1. Entenda o problema antes de gerar código.

  2. Dê contexto suficiente.

  3. Estabeleça restrições.

  4. Gere pequenas alterações.

  5. Revise.

  6. Compile.

  7. Teste.

  8. Observe.

  9. Versione.

  10. Nunca entregue produção diretamente à IA sem controle.

Parece conservador?

Sim.

Também funciona.


41. Curiosidade final: o programador não desaparece, ele sobe de nível

Em cada revolução tecnológica ouvimos:

Essa profissão vai acabar.

Compiladores acabariam com programadores Assembly.

COBOL acabaria com programadores.

CASE tools acabariam com programadores.

Fourth Generation Languages acabariam com programadores.

Low-code acabaria com programadores.

Outsourcing acabaria com programadores.

Cloud acabaria com infraestrutura.

Agora IA acabará com programação.

A história costuma ser mais complicada.

Tecnologias raramente simplesmente apagam profissões.

Elas mudam o que é considerado trabalho valioso.


42. Easter Egg final: produção às 03:17

São 03:17.

O telefone toca.

Produção.

— O job AB1234 terminou com S0C7.

O jovem programador abre a IA.

Explique S0C7.

A IA responde:

Data Exception. Provavelmente operação numérica sobre campo contendo dados inválidos.

Excelente.

O jovem pergunta:

Corrija o programa.

A IA altera 47 linhas.

O veterano olha.

— Não.

O jovem:

— Por quê?

— Porque o erro está no arquivo de entrada.

Silêncio.

O veterano abre o dump.

Encontra:

VALOR = '12A45'

Ele aponta para a tela.

— A IA conhece COBOL.

— E você?

— Eu conheço o sistema.

Essa é talvez a melhor definição do futuro.

A máquina terá conhecimento gigantesco.

O humano continuará responsável por contexto, julgamento e consequência.


Conclusão

Vibe Coding não é simplesmente uma moda.

Também não é uma tecnologia mágica que elimina a necessidade de programadores.

É mais uma etapa na longa história da abstração da computação.

Máquina.

Assembly.

COBOL.

Linguagens modernas.

Frameworks.

Low-code.

IA.

Linguagem natural.

Estamos lentamente removendo a necessidade de dizer ao computador exatamente como fazer cada pequena coisa.

E migrando para uma época em que dizemos principalmente o que queremos.

Isso muda o papel do desenvolvedor.

O programador do futuro talvez escreva menos código.

Mas precisará compreender mais sistemas.

Precisará dominar:

  • arquitetura;

  • negócio;

  • segurança;

  • dados;

  • integração;

  • observabilidade;

  • governança;

  • testes.

Principalmente precisará desenvolver algo que nenhum autocomplete substitui facilmente:

juízo técnico.

Para quem está começando em COBOL, portanto, não veja a Inteligência Artificial como motivo para abandonar os fundamentos.

Faça o contrário.

Use-a para aprender mais rápido.

Pergunte.

Teste.

Quebre.

Investigue.

Compare.

Peça explicações.

Leia código antigo.

Observe dumps.

Entenda JCL.

Conheça Db2.

Descubra por que aquele programa de 1987 ainda está funcionando.

Porque talvez o profissional mais poderoso da próxima década não seja aquele que escreve dez mil linhas de código.

Talvez seja aquele capaz de olhar dez mil linhas escritas por uma IA e dizer:

“Aqui.”

“É exatamente aqui que vai dar problema.”

E nesse instante o programador COBOL iniciante compreenderá uma verdade antiga do mainframe:

tecnologia muda.

Ferramentas mudam.

Linguagens mudam.

Mas alguém sempre precisa entender o paciente.

sexta-feira, 2 de maio de 2025

Kotonoha Katsura em destaque homenagem de um otaku

Bellacosa Mainframe homenageia Kotonoha Katsura

Kotonoha Katsura em destaque homenagem de um otaku

Kotonoha Katsura é uma das personagens mais marcantes e trágicas do anime School Days (2007). Estudante do ensino médio, ela é apresentada como uma jovem extremamente gentil, educada, tímida e reservada. Sua beleza e comportamento delicado fazem dela a representação do arquétipo da "garota ideal" dos romances escolares japoneses.

Apesar da aparência frágil, Kotonoha possui uma grande capacidade de amar e confiar nas pessoas. Quando inicia seu relacionamento com Makoto Itou, entrega-se emocionalmente de forma sincera, abrindo espaço para que ele conheça sua vida pessoal, sua família e seus sentimentos mais profundos. Essa confiança absoluta é justamente o que torna sua trajetória tão dolorosa para muitos espectadores.

Ao longo da história, Kotonoha enfrenta rejeição, isolamento, humilhações e sucessivas decepções amorosas. Sua jornada mostra como a vulnerabilidade emocional pode ser explorada por pessoas egoístas e irresponsáveis. Diferente de outras personagens da série, ela raramente age por interesse próprio, o que faz com que muitos fãs a enxerguem como a principal vítima dos acontecimentos.

Mais do que uma personagem de romance, Kotonoha tornou-se um símbolo da confiança traída e do sofrimento emocional. Quase vinte anos após o lançamento de School Days, ela continua sendo lembrada como uma das figuras mais impactantes, debatidas e emocionantes da história dos animes. 🌸💔📼


🌳 O Universo Overflow

A série School Days pertence a uma linhagem de Visual Novels iniciada com:

1. Summer Radish Vacation!!

(2000)

Primeira aparição de alguns personagens que mais tarde seriam parentes de figuras importantes de School Days.


2. Shuffle! People?

(Não confundir com o anime Shuffle!)

Obra menor do universo Overflow.


3. Cross Days

(2010)

A mais famosa derivada de School Days.

Aqui Kotonoha aparece novamente.


4. Island Days

(2014)

Uma espécie de spin-off em ambiente de sobrevivência numa ilha.

Kotonoha também pode aparecer dependendo da rota.


5. Shiny Days

(2012)

Remake expandido de Summer Days.

Inclui várias personagens ligadas à árvore genealógica de School Days.


🎮 Cross Days

Esta é provavelmente a obra mais importante para quem gosta de Kotonoha.

Título Original

クロスデイズ

(Cross Days)

Lançamento

2010

Protagonista

Yuuki Ashikaga

Não é Makoto.


O que acontece?

A história ocorre paralelamente aos eventos de School Days.

Você observa vários acontecimentos sob outra perspectiva.

Kotonoha possui participação significativa dependendo da rota escolhida.


Curiosidade

Muitos fãs consideram algumas rotas de Cross Days mais satisfatórias para Kotonoha do que os eventos vistos no anime.


🌸 Shiny Days

Título Original

Shiny Days

Lançamento

2012

Remake de Summer Days.


Relação com Kotonoha

Ela aparece porque faz parte da gigantesca árvore genealógica do universo Overflow.

E aqui chegamos à parte mais curiosa.


☕💣 O UNIVERSO OVERFLOW É UMA CONFUSÃO GENEALÓGICA GIGANTESCA

Operador...

Prepare-se.

O universo School Days possui uma das árvores familiares mais bizarras dos animes e Visual Novels.

Existem:

  • primos

  • meios-irmãos

  • parentes distantes

  • relações cruzadas

Em alguns casos os próprios criadores brincavam com isso.

Muitos fãs chamam a árvore genealógica de:

"o JCL mais impossível já escrito"


📺 Kotonoha no Anime

No anime tradicional:

School Days (2007)

é sua única participação principal.

Ela não recebeu:

  • spin-off próprio;

  • série própria;

  • continuação focada nela.


😢 Por que ela nunca ganhou um spin-off?

Porque School Days foi concebido como uma tragédia.

A função narrativa de Kotonoha era representar:

  • amor idealizado;

  • confiança;

  • vulnerabilidade emocional.

O impacto da obra depende justamente da destruição dessa inocência.

Criar uma continuação poderia enfraquecer a mensagem original.


📚 Existe material extra?

Sim.

Há:

  • Drama CDs

  • Artbooks

  • Mangás

  • Visual Novels

Neles é possível ver lados diferentes da personagem.

Alguns apresentam situações mais leves e felizes do que o anime.


🌸 Um detalhe que muitos fãs não sabem

Na Visual Novel original existem rotas em que Kotonoha tem finais felizes.

Isso surpreende quem conhece apenas o anime.

Muita gente acredita que a tragédia é inevitável.

Não é.

Dependendo das escolhas do jogador:

  • Kotonoha pode ser feliz;

  • pode namorar Makoto;

  • pode evitar boa parte do sofrimento.

O anime escolheu deliberadamente uma das linhas mais sombrias possíveis.


☕💔 Veredito Bellacosa Mainframe

Talvez a razão pela qual tantos fãs continuam lembrando de Kotonoha quase vinte anos depois seja simples.

Ela não foi escrita para ser a garota mais engraçada.

Nem a mais poderosa.

Nem a mais carismática.

Ela foi escrita para ser a personagem que faz o espectador pensar:

"Ela merecia algo melhor."

E personagens assim são raros.

Por isso, mesmo existindo outras obras do universo Overflow, para muitos fãs a imagem definitiva de Kotonoha continua sendo aquela garota tímida que abriu seu coração, mostrou seu mundo, apresentou sua família e acabou se tornando uma das personagens mais trágicas da história dos romances em anime. ☕🌸💔📼


Bellacosa Mainframe e a doce kotonoha Katsura

🌸 Easteregg

O nome Kotonoha Katsura (桂 言葉) é extremamente simbólico e provavelmente foi escolhido de forma intencional pelos criadores de School Days.


🌸 Kotonoha (言葉)

O nome Kotonoha é escrito com os kanjis:

言葉

Que significam literalmente:

  • 言 (koto) = palavra, fala, dizer

  • 葉 (ha) = folha

Mas em japonês moderno:

言葉 (kotoba/kotonoha) significa:

"palavras"

"linguagem"

"expressão verbal"

A leitura "Kotonoha" é mais poética e literária.


☕ Interpretação Bellacosa Mainframe

Isso é quase uma ironia cruel.

Kotonoha significa:

"Palavras"

Mas durante boa parte do anime ela é justamente a personagem que:

  • tem dificuldade para se expressar;

  • guarda sentimentos;

  • não consegue comunicar sua dor;

  • permanece em silêncio quando deveria ser ouvida.

É como se o sistema tivesse um dataset chamado:

KOTONOHA = PALAVRAS

Mas ninguém executasse:

READ KOTONOHA

🌳 Katsura (桂)

O sobrenome:

Lê-se:

Katsura

Refere-se à árvore Katsura (Cercidiphyllum japonicum).

No simbolismo japonês ela é associada a:

  • elegância

  • beleza discreta

  • delicadeza

  • refinamento

Em algumas tradições também aparece ligada à Lua e à imortalidade.


🌸 O Significado Completo

Juntando os dois:

桂 言葉

Pode ser interpretado poeticamente como:

"Palavras delicadas"

ou

"Palavras elegantes"

ou ainda

"Folhas da árvore Katsura"

dependendo do contexto literário.


📖 Uma Curiosidade Interessante

Muitos personagens de School Days possuem nomes ligados a:

  • estações ferroviárias;

  • linhas de trem;

  • regiões de Tóquio.

Os criadores da Overflow tinham o hábito de usar referências geográficas reais para batizar personagens.

Por isso vários nomes da série possuem significados ocultos ou ligações com locais do Japão.


☕💔 A Triste Ironia de Kotonoha

Analisando a obra inteira, o nome dela se torna quase profético.

Ela é:

  • a personagem que mais ama;

  • a personagem que mais confia;

  • a personagem que mais sofre;

e ao mesmo tempo:

  • a que menos consegue ser ouvida.

Por isso muitos fãs enxergam um simbolismo involuntário ou proposital:

Kotonoha significa "palavras", mas sua tragédia nasce justamente porque suas palavras nunca foram realmente escutadas.

Talvez seja por isso que, quase vinte anos depois de School Days, o nome Kotonoha Katsura continue despertando tanta empatia entre os fãs. Ela não é lembrada apenas como uma personagem, mas como a voz de alguém que tentou amar, confiar e se comunicar... e que acabou sendo ignorada quando mais precisava ser ouvida. 🌸💔📼☕

quinta-feira, 1 de maio de 2025

☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Bellacosa Mainframe introducao a modernizacao do cics mainframe seculo xxi


☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Durante décadas, muita gente repetiu a mesma profecia:

"O Mainframe vai acabar."

Enquanto isso, silenciosamente, o CICS continuou processando bilhões de transações por dia.

E aqui está a grande ironia tecnológica da nossa época:

As empresas que tentaram substituir completamente seus sistemas CICS descobriram que recriar 40 anos de regras de negócio é muito mais difícil do que parece.

Foi então que surgiu uma pergunta mais inteligente:

E se, em vez de substituir, nós modernizarmos?

É exatamente isso que o CICS moderno faz.


O PRIMEIRO ERRO: CONFUNDIR MODERNIZAÇÃO COM REESCRITA

Quando alguém fala em modernização, muitos imaginam:

COBOL -> Java
Mainframe -> Cloud
3270 -> Browser

Mas o CICS moderno propõe algo diferente:

COBOL + Java
Mainframe + Cloud
3270 + REST
VSAM + APIs

A IBM chama isso de:

Hybrid Cloud

Ou seja:

O sistema continua executando onde sempre funcionou, mas agora conversa com aplicações modernas.


PASSO 1 – ENTENDER O QUE VOCÊ POSSUI

Antes de modernizar qualquer aplicação CICS, faça um inventário.

Identifique:

  • Transações

  • Programas COBOL

  • Arquivos VSAM

  • DB2

  • COMMAREAs

  • Web Services existentes

  • Dependências

Perguntas importantes:

  • O sistema ainda usa 3270?

  • Existem APIs?

  • Existe documentação?

  • Existe código-fonte?

Acredite:

Nem sempre existe.

E sim...

Existem sistemas produtivos em que o fonte original desapareceu há décadas.


PASSO 2 – SEPARAR APRESENTAÇÃO E NEGÓCIO

A arquitetura clássica ensinada pela IBM possui:

Presentation Layer
Business Logic Layer
Data Services Layer

Exemplo clássico:

PAYPGM
    |
    v
PAYBUS
    |
    v
VSAM

O PAYPGM fala com o usuário.

O PAYBUS contém as regras de negócio.

Quando isso já existe, a modernização fica muito mais simples.


PASSO 3 – TRANSFORMAR O NEGÓCIO EM SERVIÇO

O erro mais comum é tentar modernizar a tela.

A tela não tem valor.

O valor está na regra de negócio.

Por isso o melhor caminho normalmente é:

Browser
    |
REST API
    |
PAYBUS
    |
VSAM

Observe:

O COBOL continua vivo.

Apenas ganhou uma nova interface.


PASSO 4 – APOSENTAR A COMMAREA

A COMMAREA foi uma revolução.

Mas ela possui um limite:

32767 bytes

Isso era enorme em 1975.

Hoje não é.

A solução moderna:

Channels
Containers

Antes:

EXEC CICS LINK
     COMMAREA(...)
END-EXEC

Depois:

EXEC CICS LINK
     CHANNEL('PAYROLL')
END-EXEC

Benefícios:

  • Sem limite prático

  • Dados organizados

  • Menos copybooks gigantes

  • Melhor integração


PASSO 5 – INTRODUZIR JAVA SEM TRAUMA

Aqui surge a pergunta que assombra muitos programadores COBOL:

"Precisamos reescrever tudo em Java?"

Não.

E provavelmente você não deveria.

O CICS permite executar Java dentro do próprio ambiente.

Arquitetura:

CICS
   |
JVM Server
   |
Liberty
   |
Java

Agora o cenário fica interessante:

COBOL
   |
LINK
   |
Java

e também:

Java
   |
LINK
   |
COBOL

Os dois mundos coexistem.


PASSO 6 – DESCOBRIR O PODER DO LINK TO LIBERTY

Este é um dos recursos mais elegantes do CICS moderno.

Um programa COBOL pode chamar um método Java.

Exemplo:

@CICSProgram("CUSTGET")

Agora o COBOL pode executar:

EXEC CICS LINK
     PROGRAM('CUSTGET')
END-EXEC

Sem HTTP.

Sem REST.

Sem MQ.

Sem gambiarra.

Tudo dentro do próprio CICS.


PASSO 7 – ADOTAR APIs REST

Uma das formas mais comuns de modernização é expor programas COBOL como APIs REST.

Arquitetura:

Mobile App
     |
REST
     |
Java
     |
PAYBUS
     |
VSAM

O usuário nem imagina que existe COBOL por trás.

E isso é perfeitamente aceitável.

Aliás...

É exatamente o objetivo.


PASSO 8 – IMPLEMENTAR EVENT PROCESSING

Aqui está um superpoder pouco conhecido.

Imagine um sistema de apostas.

Toda vez que alguém aposta mais de R$ 50.000:

Evento

Mas você perdeu o fonte.

Como alterar o programa?

Você não altera.

O CICS observa eventos.

Exemplo:

EXEC CICS LINK

Ao detectar o comando:

Evento gerado

Sem modificar uma linha de COBOL.

Isso é Event Processing.


PASSO 9 – PROGRAMAÇÃO ASSÍNCRONA

Outro recurso poderoso.

Tradicional:

Programa A
espera B
espera C
espera D

Moderno:

Programa A

+---- B
|
+---- C
|
+---- D

Tudo executando simultaneamente.

Novas APIs:

RUN TRANSID
FETCH CHILD
FETCH ANY
FREE CHILD

Menos espera.

Mais throughput.

Mais escalabilidade.


PASSO 10 – ENTRAR NO MUNDO DEVOPS

Aqui muitos profissionais acreditam que existe:

DevOps Linux
DevOps Mainframe

Mas a IBM foi direta:

Existe apenas:

DevOps

Ferramentas modernas:

Git
VS Code
Zowe
Jenkins
DBB
Ansible
UrbanCode

O fluxo torna-se:

Git
 |
Build
 |
Test
 |
Deploy
 |
CICS

ERROS MAIS COMUNS

Erro 1

Tentar reescrever tudo.

Resultado:

Projeto de 5 anos.

Orçamento explode.

Sistema antigo continua rodando.


Erro 2

Modernizar a interface e esquecer a regra de negócio.

A regra é o patrimônio.

A tela é apenas um detalhe.


Erro 3

Ignorar testes.

Use:

ZUnit
JUnit
Mockito
Galasa

Erro 4

Não envolver o System Programmer.

Lembre-se:

Arquivos.

Recovery.

Resources.

Bundles.

JVM Servers.

Tudo isso depende dele.


SOLUÇÃO DE PROBLEMAS

EIBCALEN = 0

Primeira entrada da transação.


Programa novo não atualiza

Execute:

NEWCOPY

ou

REFRESH PROGRAM

COMMAREA truncada

Provavelmente ultrapassou:

32K

Migre para Containers.


LINK retornando erro

Verifique:

RESP
RESP2

Sempre.


CURIOSIDADE

Pouca gente sabe, mas o CICS nasceu em uma época em que muitos computadores ainda trabalhavam com cartões perfurados.

Hoje ele executa:

  • APIs REST

  • Java

  • JSON

  • Liberty

  • Cloud

  • DevOps

Sem abandonar sua essência transacional.

Isso talvez explique sua longevidade.


EASTER EGG MAINFRAME

Existe uma frase que quase todo profissional experiente de CICS aprende depois de alguns anos:

"O problema nunca está no CICS."

Primeiro você culpa:

  • CICS

  • VSAM

  • RACF

  • DB2

  • MQ

Depois de algumas horas investigando...

Descobre que esqueceu de fazer:

EXEC CICS RETURN
END-EXEC

ou

EXEC CICS HANDLE CONDITION
END-EXEC

ou simplesmente compilou o programa errado.

Acontece mais do que deveria.


CONCLUSÃO

☕💣🚀 PADAWAN, O MAIOR SEGREDO DA MODERNIZAÇÃO NÃO É TROCAR COBOL POR JAVA.

É entender que o verdadeiro valor está nas regras de negócio acumuladas durante décadas.

O CICS moderno permite adicionar:

  • REST

  • Java

  • Liberty

  • Eventos

  • APIs

  • DevOps

  • Cloud

sem destruir aquilo que já funciona.

E essa talvez seja a definição mais elegante de modernização:

Evoluir sem perder a confiança conquistada por milhões de transações executadas corretamente ao longo de décadas.

quarta-feira, 30 de abril de 2025

🖥️ A História do z/OS e dos Sistemas Operacionais do Mainframe IBM Z

 




🖥️ A História do z/OS e dos Sistemas Operacionais do Mainframe IBM Z



“Antes da IA, da nuvem e até do PC existir, já havia o OS/360 rodando o mundo.”
Bellacosa Mainframe Blog


🕰️ Linha do Tempo dos Sistemas Operacionais Mainframe IBM

EraSistemaAno de LançamentoAmbienteDestaques e Mudanças
🧮 1964OS/3601964IBM System/360O marco zero. Primeiro SO da IBM com compatibilidade entre modelos. Introduziu JCL, batch, e multitarefa.
🧰 1972MVT / SVS1972System/370Introduziu memória virtual (SVS: Single Virtual Storage). Evolução da arquitetura 360.
🧱 1974MVS (Multiple Virtual Storage)1974System/370Suporte a múltiplas áreas de memória virtual; nascia o conceito moderno de “job address space”.
🔐 1988MVS/XA (Extended Architecture)1983–1988370-XASuporte a endereçamento de 31 bits, canais de I/O mais rápidos, e novos dispositivos.
⚙️ 1990MVS/ESA (Enterprise Systems Architecture)1990System/390Suporte a multiprocessamento, novos modos de dispatching e SRM aprimorado.
💾 1995OS/3901995System/390Consolidação do MVS, JES2/JES3, TSO/E, ISPF, RACF e DFSMS em um único produto.
🧠 2001z/OS 1.02001IBM zSeries (z900)Rebranding do OS/390. Suporte nativo a 64 bits, Sysplex aprimorado, e TCP/IP integrado.
2007z/OS 1.8 – 1.132007–2011z9 / z10Inovações em UNIX System Services, RRS, segurança, e WLM dinâmico. z/OS 1.10 marcou 64 bits real.
☁️ 2012z/OS 2.12012zEC12 (z12)Base para modernização: zFS nativo, integração com z/VM e Linux, RACF estendido, 64-bit datasets.
🌐 2015z/OS 2.2 – 2.32015–2017z13 / z14Introdução do z/OSMF (z/OS Management Facility), APIs REST, automação e melhor UX.
🤖 2021z/OS 2.52021z15 / z16Suporte a AI Ops, integração com Ansible, containers, OpenShift no Z, e criptografia pervasiva.
🧬 2023–2025z/OS 3.1 e 3.2 (em evolução)2023–2025z16 / z17Primeira versão da nova geração “AI Native z/OS”. Observabilidade, IA em operações, OpenTelemetry e automação cognitiva.

🧭 Resumo Técnico das Grandes Mudanças

VersãoMudança Técnica ChaveImpacto
MVS → OS/390Consolidação de subsistemas (RACF, TSO, JES, DFSMS) em um único pacote.Simplificação da gestão e licenciamento.
OS/390 → z/OS 1.0Suporte nativo a 64 bits e TCP/IP.Entrada definitiva do mainframe na era da Internet.
z/OS 1.9 – 1.13Modernização do UNIX System Services e DFSMSdfp.Reforço da interoperabilidade e performance.
z/OS 2.xIntrodução de APIs REST, z/OSMF e segurança criptográfica pervasiva.Começo da integração com DevOps e automação.
z/OS 3.xIA nativa, automação cognitiva e observabilidade integrada.O mainframe como AI + Operations Platform.

🔍 Curiosidades Bellacosa

  • O OS/360 é citado até hoje em livros de engenharia de software — foi o projeto que inspirou o clássico “The Mythical Man-Month” de Fred Brooks, que liderou a equipe da IBM.

  • O JCL (Job Control Language) nasceu no OS/360 e sobrevive até hoje, com as mesmas palavras-chave básicas!

  • O z/OSMF (Management Facility) trouxe interface gráfica ao mainframe — uma revolução silenciosa em 2015.

  • O z/OS 3.1 inclui suporte nativo a observabilidade (via OpenTelemetry), o que permite monitorar o mainframe como se fosse uma app cloud-native.

  • Apesar de décadas, o z/OS mantém retrocompatibilidade funcional — programas compilados há 40 anos ainda rodam.


🧠 Dica Técnica

Cada nova versão do z/OS não é apenas mais performance — é um passo de integração com o ecossistema híbrido.

  • ✅ Use z/OSMF para gerenciar sem precisar de ISPF.

  • 🔒 Explore o z/OS Encryption Readiness Technology (zERT) para visibilidade de tráfego criptografado.

  • 🧩 Se estiver com z/OS 3.1+, integre com AI Operations e observabilidade via OMEGAMON + OpenTelemetry.

  • 🚀 E claro: mantenha seu Sysplex ajustado — ele é o coração do paralelismo z/OS.


📜 História em Números

GeraçãoBitsArquiteturaMarca de Hardware
OS/36024System/3601964
MVS/ESA31System/3901990
z/OS64zSeries (IBM Z)2001 – atual

🏁 Conclusão

O z/OS é a espinha dorsal da computação corporativa há mais de meio século.
De cartões perfurados a IA em tempo real, ele não apenas evoluiu — sobreviveu e liderou cada revolução tecnológica.

“Se a nuvem é o futuro, o mainframe é o alicerce onde a nuvem confia.”
Vagner Bellacosa – Um Café no Bellacosa Mainframe

 

terça-feira, 29 de abril de 2025

🧭 Tabela de Compatibilidade z/OS x Hardware IBM Z

 



🧭 Tabela de Compatibilidade z/OS x Hardware IBM Z

🧱 Mainframe (Hardware)📅 Ano de Lançamento⚙️ Arquitetura / Processador💿 Versão z/OS Compatível (mínima / recomendada)🧠 Observações / Curiosidades Bellacosa
z900 (zSeries 900)2000z/Architecture (64 bits) – Geração 1z/OS 1.1 a 1.8Primeiro mainframe 64 bits real; marco inicial do z/OS moderno.
z990 (zSeries 990 – “T-Rex”)2003Geração 2z/OS 1.4 a 1.10Introduziu suporte massivo a Sysplex e WLM avançado.
z9 EC / BC2005Geração 3z/OS 1.7 a 1.11Suporte aprimorado a criptografia, novas instruções de CPU e zAAP/zIIP.
z10 EC / BC2008Geração 4z/OS 1.9 a 1.13Introduziu processadores quad-core e otimizações de energia.
zEnterprise 196 / 114 (z196/z114)2010Geração 5z/OS 1.11 a 2.1Introduziu zEnterprise BladeCenter Extension (zBX). Início da integração heterogênea.
zEnterprise EC12 / BC12 (zEC12/zBC12)2012 / 2013Geração 6z/OS 1.13 a 2.2Introduziu criptografia AES e melhorias em zAAP/zIIP.
IBM z13 / z13s2015Geração 7 – 22nmz/OS 2.1 a 2.3Primeiro suporte oficial a Java 8, Cloud APIs e grandes melhorias em JES2.
IBM z14 / z14 ZR12017 / 2018Geração 8 – 14nmz/OS 2.2 a 2.5Introduziu Pervasive Encryption e o conceito de “Data Privacy by Default”.
IBM z15 (T01 / T02)2019 / 2020Geração 9 – 14nmz/OS 2.3 a 2.5Suporte a Data Privacy Passports e compressão de memória (zEDC).
IBM z162022Geração 10 – Telum 7nmz/OS 2.5 e z/OS 3.1Primeiro com AI On-Chip e inferência em tempo real via Telum.
IBM z172024Geração 11 – Telum 5nmz/OS 3.1 (nativo)Introduz Quantum Safe Encryption, IA expandida e otimizações de workload híbrido.

🔍 Padrões gerais de compatibilidade

  • O z/OS é sempre compatível com duas gerações anteriores de hardware (backward compatibility).

  • Já o hardware IBM Z suporta versões do z/OS até duas gerações anteriores (forward compatibility).

    Exemplo: o z16 suporta oficialmente z/OS 2.5 e 3.1, mas não roda 2.3 ou anteriores.

  • Cada geração de hardware introduz novas instruções de máquina, firmware PR/SM, e créditos de CPU específicos — por isso versões antigas de z/OS não reconhecem o processador.


Curiosidades Bellacosa

  • O z/OS 1.1 nasceu junto com o z900 — ambos foram marcos da transição para 64 bits.

  • O z/OS 2.1 (2013) foi o primeiro a exigir hardware com suporte nativo a HiperDispatch.

  • O z/OS 2.5 (2021) marcou o início da integração com IA e observabilidade moderna.

  • O z/OS 3.1 (2023) é o primeiro a suportar IA Ops e automação via Watsonx, exigindo no mínimo z16.

  • O z17 (2024) é o primeiro com suporte total a criptografia quântica e IA expandida em hardware — o casamento perfeito com o z/OS 3.1.


💡 Dica Bellacosa para seus alunos

Sempre verifique a “base mínima de suporte” (Hardware Base Level) antes de instalar um z/OS.
É comum em ambientes de teste ou em Hercules/Emulação que o z/OS falhe por instruções não suportadas no nível da CPU simulada.

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...