Translate

quarta-feira, 18 de setembro de 2024

AIOps : Quando um Programador Embarca no Seaview e Descobre que o Verdadeiro Monstro do Oceano Não é um Polvo Gigante.

Bellacosa Mainframe apresenta o aiops

☕ Um Café no Bellacosa Mainframe

AIOps sem Mistérios para Programadores COBOL

Quando um Programador Embarca no Seaview e Descobre que o Verdadeiro Monstro do Oceano Não é um Polvo Gigante... É uma Anomalia de Performance Escondida Entre Milhões de Métricas

"Profundidade: 8.000 metros."

"Pressão externa: centenas de atmosferas."

"Silêncio absoluto."

No fundo do oceano não existe espaço para improvisação.

Não existe Ctrl+C.

Não existe reboot.

Não existe "vamos tentar novamente amanhã".

Uma pequena falha...

...e toda a missão termina.

Curiosamente, é exatamente assim que funciona um IBM Z.

Enquanto milhões de pessoas compram, transferem dinheiro, usam cartões, fazem PIX, reservam passagens e movimentam bolsas de valores, o mainframe continua trabalhando silenciosamente nas profundezas da infraestrutura mundial.

É justamente aí que nasce o universo do AIOps, do Performance Management e do Capacity Planning.

Prepare seu uniforme da Marinha Nelson Institute, embarque no USS Seaview, comandado pelo Almirante Harriman Nelson e pelo Capitão Lee Crane, porque hoje faremos uma viagem ao fundo do mar... das métricas do IBM Z.


Capítulo 1 — O Oceano Invisível do Mainframe

Todo iniciante imagina que um computador executa apenas programas.

Na realidade, um IBM Z executa milhares de atividades simultaneamente.

Enquanto seu programa COBOL faz um simples:

READ CLIENTES

o sistema inteiro está trabalhando.

Nos bastidores existem:

  • Dispatcher

  • PR/SM

  • WLM

  • zIIP

  • RMF

  • SMF

  • CICS

  • Db2

  • MQ

  • JES2

  • VSAM

  • RACF

  • DFSMS

  • Coupling Facility

  • IOS

  • Channel Subsystem

Todos gerando estatísticas.

Imagine centenas de sensores espalhados pelo casco do Seaview.

Cada sensor mede:

  • pressão

  • temperatura

  • velocidade

  • combustível

  • profundidade

  • oxigênio

  • consumo elétrico

Agora multiplique isso por dezenas de milhares.

É isso que o IBM Z mede continuamente.


Easter Egg nº 1

Na série Viagem ao Fundo do Mar, o Seaview parecia navegar calmamente.

Mas na sala de máquinas havia dezenas de oficiais monitorando centenas de instrumentos.

No IBM Z acontece exatamente o mesmo.

Você vê apenas uma tela 3270.

Por trás dela existe um oceano inteiro de telemetria.


Capítulo 2 — O erro que muita gente está cometendo

Com a chegada dos LLMs surgiu uma ideia perigosa.

"Agora basta perguntar para uma IA."

Será?

Imagine entrar no Seaview e perguntar:

— IA, estamos seguros?

Resposta:

— Sim.

Fim.

Mas...

E se existir uma microfissura no casco?

E se um sonar estiver apresentando ruído?

E se uma bomba hidráulica estiver começando a vibrar?

A IA respondeu.

Mas não analisou.

Essa é exatamente a diferença entre um chatbot e uma plataforma especializada como o IBM Z IntelliMagic Vision.


Informação não é conhecimento

Uma IA pode responder:

"A CPU está em 82%."

Ótimo.

Mas isso é bom?

Ruim?

Esperado?

Anormal?

Ela não sabe.

Porque falta contexto.

O especialista pergunta:

  • qual CPC?

  • qual LPAR?

  • qual horário?

  • qual workload?

  • qual Service Class?

  • qual política WLM?

  • houve IPL?

  • mudou o firmware?

  • houve novo package Db2?

  • apareceu nova aplicação Java?

  • aumentou MQ?

  • mudou o peso PR/SM?

É outro nível de investigação.


Capítulo 3 — O verdadeiro tesouro do oceano chama-se SMF

Poucos iniciantes conhecem o SMF.

Mas ele talvez seja o recurso mais valioso do z/OS.

SMF significa:

System Management Facility

Pense nele como o diário de bordo do Seaview.

Tudo é registrado.

Tudo.

Quem usou CPU.

Quem fez I/O.

Quem abriu datasets.

Quem executou CICS.

Quem acessou Db2.

Quem consumiu zIIP.

Quem gerou paging.

Quem alterou configuração.

Décadas de história ficam registradas.

Sem SMF...

não existe análise histórica.


Curiosidade

Muitas empresas possuem anos de dados SMF armazenados.

Algumas conseguem comparar o comportamento atual com períodos de cinco ou dez anos atrás.

É como comparar uma expedição submarina atual com os registros originais do Almirante Nelson.


Capítulo 4 — Uma imagem vale mais que mil RMFs

O artigo comenta algo extremamente importante.

Uma figura vale mais que mil palavras.

Observe mentalmente a topologia apresentada.

Diversos:

CPC

LPARs

Sysplex

Tudo conectado.

Em segundos o especialista entende:

Quem pertence a quem.

Quem compartilha recursos.

Quem faz parte do mesmo Sysplex.

Quem utiliza determinado processador.

Nenhum texto consegue transmitir isso tão rapidamente.


Easter Egg nº 2

No Seaview existia uma enorme mesa de navegação.

Ninguém decorava o oceano.

Eles olhavam o mapa.

O IntelliMagic faz exatamente isso.

Ele desenha o mapa do seu mainframe.


Capítulo 5 — O poder do Change Detection

Imagine esta situação.

Segunda-feira:

Tudo perfeito.

Terça-feira:

Usuários reclamando.

O que mudou?

Essa pergunta pode consumir dias de investigação.

Mas o IntelliMagic compara automaticamente períodos diferentes.

Ele verifica:

  • CPU

  • zIIP

  • Dispatch Time

  • Busy

  • Eligible Work

  • Utilização

  • Tendências

  • Desvios

Não apenas mostra valores.

Mostra mudanças.

E mais importante...

Mostra mudanças relevantes.


O segredo do desvio padrão

Imagine um sonar.

O ruído normal fica entre:

10 e 15 decibéis.

Hoje apareceu:

Nada mudou.

Agora imagine:

Tem algo enorme vindo na direção do submarino.

Foi isso que o desvio padrão detectou.

Mudanças realmente fora do comportamento esperado.

Não basta aumentar.

Precisa aumentar de forma estatisticamente significativa.


Capítulo 6 — Health Rating

Talvez a funcionalidade mais fascinante.

Imagine o painel do Seaview.

Luzes verdes.

Luzes amarelas.

Luzes vermelhas.

Você não precisa ler milhares de sensores.

Basta olhar o painel.

No IntelliMagic ocorre exatamente isso.

Cada sistema recebe indicadores como:

  • Dispatch Time

  • MVS Busy

  • LPAR Busy

  • zIIP

  • IOSQ

  • Pending

  • Connect

  • Interrupt

  • Page-ins

Em poucos segundos o especialista sabe onde investigar primeiro.


Dica Bellacosa

Nunca olhe apenas um indicador.

Performance é correlação.

CPU alta pode ser consequência.

Não a causa.


Capítulo 7 — Tendência vale mais que fotografia

Uma fotografia mostra um instante.

Um gráfico mostra uma história.

É por isso que Capacity Planning utiliza séries históricas.

Não interessa apenas saber:

Hoje = 70%.

Interessa descobrir:

Janeiro:

65%

Fevereiro:

67%

Março:

69%

Abril:

72%

Maio:

75%

Junho:

78%

Agora existe uma tendência.

Sem histórico...

não existe previsão.


Capítulo 8 — Capacity Planning

Aqui muitos iniciantes cometem outro erro.

Pensam:

Capacity Planning = CPU.

Não.

CPU é apenas uma peça.

O especialista observa:

CPU

Memória

I/O

Storage

Channels

Paging

Network

zIIP

MSU

Software

CICS

Db2

MQ

IMS

Batch

Online

WLM

Tudo ao mesmo tempo.

Porque gargalos raramente aparecem isolados.


Curiosidade

Em muitos ambientes o problema nunca foi CPU.

Foi um único volume DASD saturado.

Ou uma fila MQ crescendo.

Ou uma política WLM mal definida.

Ou uma consulta SQL sem índice.


Capítulo 9 — O verdadeiro papel do especialista

O artigo fala algo maravilhoso.

O maior problema não é coletar dados.

É interpretá-los.

Hoje qualquer ferramenta coleta milhões de métricas.

Mas poucas conseguem responder:

O que realmente importa?

Imagine o Seaview.

Existem dez mil instrumentos.

Mas apenas um oficial experiente percebe que pequenas vibrações significam falha futura.

É exatamente isso que faz um especialista em performance.


Capítulo 10 — Explainability

Uma IA responde.

O especialista explica.

Existe enorme diferença.

Imagine um diretor perguntando:

"Por que precisamos comprar outro CPC?"

Você responde:

"Porque a IA sugeriu."

A reunião termina.

Agora imagine responder:

  • crescimento médio de 18% ao ano;

  • tendência confirmada em 36 meses;

  • workloads Batch crescendo;

  • consumo zIIP estabilizado;

  • pico de MSU chegando ao limite contratual;

  • risco para SLA da aplicação bancária;

  • previsão estatística de saturação em oito meses.

Agora existe evidência.


Easter Egg nº 3

No Seaview, o Almirante Nelson nunca dizia apenas:

"Vamos mergulhar."

Ele mostrava:

  • cartas náuticas;

  • sonar;

  • profundidade;

  • corrente marítima;

  • combustível;

  • pressão.

Isso é explainability.


Capítulo 11 — IA não substitui Analytics

Esse talvez seja o maior ensinamento do artigo.

A IA facilita perguntas.

O IntelliMagic produz respostas confiáveis.

Pense assim.

ChatGPT é como um excelente oficial de comunicações.

Ele conversa.

Resume.

Explica.

O IntelliMagic é o centro de controle do submarino.

Recebe milhares de sinais.

Correlaciona.

Detecta anomalias.

Calcula riscos.

Prevê problemas.

Ambos trabalham juntos.

Jamais um substitui o outro.


Passo a passo de uma investigação de performance

Imagine que um gerente liga dizendo:

"O sistema ficou lento."

Como um especialista procede?

Passo 1 — Confirmar o sintoma

Foi CPU?

I/O?

Rede?

Storage?

Aplicação?


Passo 2 — Comparar com a baseline

Como era ontem?

Semana passada?

Mesmo horário?


Passo 3 — Procurar mudanças

Novo deploy?

Novo package?

Nova política WLM?

Novo firmware?

Novo microcódigo?


Passo 4 — Correlacionar métricas

CPU alta.

Mas também houve:

  • aumento de I/O;

  • queda no cache;

  • crescimento do MQ;

  • aumento de locks Db2.

Agora aparece a verdadeira causa.


Passo 5 — Avaliar impacto

Quem sofreu?

Clientes?

PIX?

Internet Banking?

Cartão?

Folha?

Ou apenas um batch interno?


Passo 6 — Recomendar ações

Redistribuir workload.

Aumentar zIIP.

Reconfigurar WLM.

Otimizar SQL.

Criar índices.

Mover datasets.

Alterar prioridades.


O futuro

A próxima geração de ferramentas será híbrida.

Imagine conversar com a plataforma:

"Quais sistemas apresentaram crescimento anormal?"

A IA responde.

Mas por trás dela existe um motor especializado analisando:

  • milhares de métricas;

  • estatísticas;

  • tendências;

  • Health Insights;

  • correlações;

  • previsões.

É exatamente essa união que o artigo chama de:

AI + Analytics.


Curiosidades Bellacosa

✅ Um único IBM Z pode produzir milhões de registros SMF por dia.

✅ O WLM ajusta prioridades automaticamente centenas de vezes por segundo para manter os objetivos de serviço.

✅ O zIIP pode descarregar grande parte do processamento elegível de Db2, XML, Java, criptografia e workloads analíticos, reduzindo custos de software em muitos cenários.

✅ Um problema aparentemente "de CPU" pode, na verdade, ser consequência de filas de I/O, contenção em locks Db2, espera por MQ ou políticas WLM inadequadas.

✅ Ferramentas como o IBM Z IntelliMagic Vision incorporam décadas de conhecimento de especialistas em performance, automatizando análises que antes exigiam anos de experiência.


Conclusão — A Verdadeira Viagem ao Fundo do Mar

Ao final da missão, o USS Seaview emerge lentamente das profundezas. A tripulação sobreviveu não porque tinha o sonar mais bonito ou o rádio mais moderno, mas porque soube interpretar corretamente cada sinal vindo do oceano.

No IBM Z acontece exatamente o mesmo.

Os gráficos, mapas de Sysplex, indicadores de saúde, detecção automática de mudanças e análises históricas são os "sonares" do mundo corporativo. Eles transformam bilhões de amostras de desempenho em conhecimento acionável.

A IA generativa representa o novo oficial de comunicações: traduz perguntas complexas para linguagem natural, resume informações e acelera o acesso ao conhecimento. Já plataformas como o IBM Z IntelliMagic Vision são o cérebro analítico do navio, capazes de correlacionar milhares de métricas, detectar riscos antes que se tornem incidentes e justificar cada conclusão com evidências.

Para o programador COBOL iniciante, a maior lição é simples: escrever um bom programa não significa apenas fazer a lógica funcionar. Significa entender como esse programa consome CPU, acessa VSAM e Db2, utiliza CICS, aproveita zIIP, respeita as metas do WLM e influencia todo o ecossistema do mainframe.

No universo Bellacosa Mainframe, o código é apenas a ponta do iceberg.

A verdadeira aventura começa quando você aprende a enxergar o oceano invisível que existe sob cada EXEC CICS, cada SELECT no Db2, cada mensagem no MQ e cada READ em um dataset. É nesse oceano que vivem os maiores desafios da engenharia de performance — e também onde se encontram os maiores tesouros de conhecimento para quem deseja se tornar um verdadeiro Mestre Jedi do Mainframe.

segunda-feira, 9 de setembro de 2024

Se você Saiu do Mainframe Há muito, mas muito tempo? Sherlock Holmes, COBOL e o Mistério da Plataforma que se Recusou a Envelhecer

 

Bellacosa Mainframe reapresenta o mainframe para antigos mainframers retornantes

☕ Um Café no Bellacosa Mainframe

Se você Saiu do Mainframe Há muito, mas muito tempo? Sherlock Holmes, COBOL e o Mistério da Plataforma que se Recusou a Envelhecer

Imagine a seguinte cena.

Depois de quinze ou vinte anos afastado do universo mainframe, você decide voltar.

Talvez tenha trabalhado com COBOL, JCL, CICS, VSAM ou DB2 no início dos anos 2000. Talvez tenha deixado a área para atuar com gestão, sistemas distribuídos, suporte, negócios ou até mesmo em outra profissão. Durante esse período, você acompanhou o nascimento da computação em nuvem, dos smartphones, das redes sociais, dos microsserviços, dos containers e da inteligência artificial.

Então surge a dúvida:

“Será que ainda sei alguma coisa útil?”

Você imagina entrar novamente em um ambiente mainframe e encontrar uma tecnologia completamente diferente daquela que conheceu. Talvez espere descobrir que o COBOL desapareceu, que o terminal 3270 virou peça de museu e que todos os sistemas foram substituídos por aplicativos modernos executando em alguma nuvem misteriosa.

Mas, ao atravessar a porta do data center, algo curioso acontece.

O cenário parece novo e familiar ao mesmo tempo.

É como Sherlock Holmes retornando a Baker Street depois de muitos anos. A cidade ganhou novos prédios, os carros mudaram, as comunicações ficaram instantâneas e agora existem câmeras por toda parte. Entretanto, os mistérios continuam sendo resolvidos da mesma forma: observando detalhes, seguindo pistas, eliminando hipóteses e compreendendo o comportamento humano.

No mainframe moderno, acontece algo parecido.

As ferramentas mudaram.

As integrações mudaram.

Os processos de desenvolvimento mudaram.

Porém, a essência do trabalho continua surpreendentemente reconhecível.

O primeiro mistério: o mainframe ficou parado no tempo?

Não.

Esse é o primeiro caso que precisamos solucionar.

O mainframe não ficou congelado em uma sala escura, cercado por fitas magnéticas e operadores usando jalecos brancos. Ele evoluiu continuamente.

O que aconteceu foi algo mais interessante: a plataforma evoluiu preservando compatibilidade com grande parte do que já existia.

Essa é uma das principais diferenças entre o mundo mainframe e muitas tecnologias distribuídas.

Em certos ecossistemas, uma nova versão pode tornar aplicações antigas incompatíveis. Frameworks surgem, ganham popularidade e desaparecem em poucos anos. Bibliotecas são abandonadas, padrões são substituídos e projetos inteiros precisam ser reescritos.

No mainframe, a evolução costuma ser mais cuidadosa.

A plataforma é responsável por sistemas bancários, seguradoras, governos, empresas de transporte, indústrias, companhias aéreas e organizações que não podem simplesmente parar tudo por alguns meses para reconstruir aplicações críticas.

Portanto, o mainframe evolui como uma grande cidade histórica.

Novas avenidas são construídas.

Novos sistemas de transporte são criados.

Novas redes de comunicação são instaladas.

Mas os prédios centrais continuam funcionando.

O COBOL continua presente.

O CICS continua processando transações.

O DB2 continua armazenando dados críticos.

O MQ continua transportando mensagens.

O JCL continua controlando processamento batch.

O JES continua recebendo e executando jobs.

O SDSF continua permitindo que o profissional consulte filas, resultados e mensagens.

E o TSO/ISPF continua lá, com suas telas, comandos e painéis familiares.

Quem retorna depois de muitos anos pode até sentir uma estranha sensação de conforto ao abrir o ISPF e perceber que a opção 3.2 continua sendo utilizada para trabalhar com data sets.

É quase como reencontrar um antigo café que mudou as mesas, reformou a fachada e instalou Wi-Fi, mas continua servindo o mesmo bom espresso.

O segundo mistério: o COBOL mudou completamente?

Para um programador COBOL iniciante, essa pergunta é importante.

A resposta é: o COBOL mudou, mas não perdeu sua identidade.

Quem conhecia a linguagem há quinze ou vinte anos ainda reconhecerá sua estrutura principal.

Um programa COBOL moderno continua podendo apresentar divisões como:

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Ainda encontraremos comandos como:

MOVE
IF
EVALUATE
PERFORM
READ
WRITE
REWRITE
DELETE
CALL

Ainda teremos variáveis descritas por níveis:

01 WS-CLIENTE.
   05 WS-CODIGO        PIC 9(08).
   05 WS-NOME          PIC X(40).
   05 WS-SALDO         PIC S9(11)V99 COMP-3.

Ainda haverá programas que acessam DB2:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTES
    WHERE CODIGO = :WS-CODIGO
END-EXEC.

Ainda existirão programas CICS:

EXEC CICS
   READ FILE('CLIENTES')
        INTO(WS-REGISTRO)
        RIDFLD(WS-CODIGO)
        RESP(WS-RESP)
END-EXEC.

O programador que já conhecia COBOL não precisará reaprender a lógica fundamental da linguagem.

Porém, encontrará compiladores mais modernos, novos recursos, integração com JSON, XML, Unicode, APIs, ferramentas de análise, IDEs gráficas, testes automatizados e pipelines de desenvolvimento.

O COBOL não virou outra linguagem.

Ele ficou mais conectado ao mundo ao seu redor.

Uma analogia para o iniciante

Imagine um automóvel clássico que recebeu:

  • freios modernos;

  • injeção eletrônica;

  • sensores;

  • GPS;

  • computador de bordo;

  • novos sistemas de segurança.

O volante continua sendo um volante.

O motor continua transformando energia em movimento.

O motorista ainda precisa conhecer trânsito, direção, frenagem e manutenção.

Da mesma forma, o programador COBOL ainda precisa dominar:

  • estruturas de dados;

  • lógica condicional;

  • repetição;

  • arquivos;

  • bancos de dados;

  • tratamento de erros;

  • regras de negócio;

  • processamento transacional;

  • processamento batch.

As novas ferramentas ajudam, mas não substituem a compreensão.

O verdadeiro salto aconteceu ao redor do mainframe

Aqui encontramos a pista mais importante de toda a investigação.

Há quinze ou vinte anos, muitas aplicações mainframe eram acessadas diretamente por terminais 3270.

Um fluxo comum poderia ser representado assim:

Usuário
   ↓
Terminal 3270
   ↓
CICS
   ↓
Programa COBOL
   ↓
VSAM ou DB2

Esse modelo ainda existe.

Entretanto, hoje um mesmo programa pode participar de uma arquitetura muito mais ampla:

Aplicativo de celular
   ↓
API Gateway
   ↓
Microsserviço
   ↓
z/OS Connect
   ↓
CICS
   ↓
Programa COBOL
   ↓
DB2
   ↓
MQ
   ↓
Outro sistema corporativo

Observe o detalhe, meu caro Watson.

O aplicativo móvel pode ter sido escrito em Kotlin ou Swift.

A API pode utilizar Java, Node.js ou outra tecnologia.

A aplicação pode estar parcialmente executando em cloud ou em containers.

Mas a regra crítica de negócio pode continuar dentro de um programa COBOL que existe há décadas.

Isso não significa atraso.

Significa reutilização de um ativo confiável.

Se um programa calcula corretamente juros, impostos, limites, tarifas, seguros ou benefícios há vinte anos, talvez seja mais seguro integrá-lo a novas interfaces do que reescrever tudo apenas para seguir uma moda tecnológica.

O mainframe deixou de ser uma ilha

Antigamente, era comum imaginar o mainframe como uma grande fortaleza.

Tudo acontecia dentro dela.

Os usuários acessavam terminais.

Os sistemas trocavam arquivos.

Os jobs eram executados em horários definidos.

Grande parte da integração permanecia dentro dos limites da empresa.

Hoje, o mainframe faz parte de um ecossistema híbrido.

Ele pode conversar com:

  • aplicações web;

  • sistemas em cloud;

  • APIs REST;

  • ferramentas de analytics;

  • plataformas de inteligência artificial;

  • sistemas distribuídos;

  • aplicações móveis;

  • microsserviços;

  • ambientes Linux;

  • filas de mensagens;

  • plataformas de automação.

O mainframe não desapareceu.

Ele deixou de trabalhar sozinho.

CICS: do terminal 3270 para a API

Para o programador COBOL iniciante, é importante entender o papel do CICS.

CICS é um monitor de processamento transacional.

Ele permite que milhares de usuários e aplicações executem transações com rapidez, controle e segurança.

No passado, muitas transações CICS eram iniciadas diretamente por uma tela 3270.

O usuário digitava dados, pressionava Enter e o programa COBOL era executado.

Hoje, a mesma lógica pode ser acionada por uma API.

Por exemplo:

  1. Um cliente abre o aplicativo do banco.

  2. Solicita o saldo.

  3. O aplicativo envia uma requisição HTTPS.

  4. Uma API recebe essa solicitação.

  5. A API chama um serviço exposto pelo z/OS Connect.

  6. O serviço aciona uma transação ou programa no CICS.

  7. O programa COBOL consulta o DB2.

  8. O resultado é convertido para JSON.

  9. O aplicativo exibe o saldo ao usuário.

Para o cliente, tudo aconteceu em segundos.

Para o programa COBOL, talvez a operação continue sendo uma consulta conhecida há muitos anos.

A entrada mudou.

A saída mudou.

A regra central permaneceu.

DB2, VSAM e o valor dos dados

Todo bom detetive sabe que uma pista isolada não resolve um caso.

É preciso saber onde ela está armazenada e como se relaciona com outras informações.

No mainframe, grande parte das pistas está nos dados.

O DB2 continua sendo um dos pilares de inúmeros sistemas corporativos. Ele oferece recursos de banco de dados relacional, controle transacional, concorrência, integridade e recuperação.

O VSAM também continua presente, especialmente em aplicações que utilizam arquivos estruturados de alta performance.

Um programador COBOL iniciante deve compreender pelo menos quatro conceitos básicos:

1. KSDS

O Key Sequenced Data Set organiza registros por chave.

É semelhante à ideia de acessar um cadastro por um código identificador.

2. ESDS

O Entry Sequenced Data Set armazena registros na ordem em que foram incluídos.

3. RRDS

O Relative Record Data Set permite acessar registros por número relativo.

4. LDS

O Linear Data Set é utilizado como estrutura de armazenamento de baixo nível por alguns produtos.

Mesmo com bancos modernos, APIs e cloud, esses conceitos continuam importantes porque muitos sistemas críticos dependem deles.

MQ: o mensageiro silencioso

Imagine que Sherlock Holmes precisa enviar uma mensagem confidencial para o inspetor Lestrade.

Ele poderia entregar pessoalmente.

Mas também poderia utilizar um mensageiro confiável, garantindo que a mensagem chegasse ao destino mesmo que Lestrade não estivesse disponível naquele instante.

O MQ desempenha papel semelhante.

Uma aplicação envia uma mensagem para uma fila.

Outra aplicação consome essa mensagem quando estiver pronta.

Isso permite desacoplar sistemas.

Por exemplo:

Programa COBOL
   ↓
Fila MQ
   ↓
Sistema antifraude
   ↓
Fila de resposta
   ↓
Outro programa

O produtor da mensagem não precisa conhecer todos os detalhes do consumidor.

Ele precisa apenas respeitar o formato combinado.

Essa arquitetura ajuda a integrar mainframe, cloud, sistemas distribuídos e aplicações externas.

O batch não morreu

Existe uma espécie de lenda urbana na tecnologia: a ideia de que tudo precisa acontecer online e em tempo real.

Não é verdade.

Muitas tarefas continuam sendo mais eficientes em processamento batch.

Entre elas:

  • fechamento contábil;

  • geração de extratos;

  • cálculo de folha de pagamento;

  • faturamento;

  • conciliação;

  • processamento de grandes volumes;

  • cálculo de impostos;

  • liquidação financeira;

  • atualização de cadastros;

  • geração de relatórios.

Um job JCL pode executar vários programas em sequência:

//FECHAMTO JOB ...
//STEP01   EXEC PGM=VALIDA
//ENTRADA  DD DSN=EMPRESA.ARQUIVO.ENTRADA,DISP=SHR
//SAIDA    DD DSN=EMPRESA.ARQUIVO.VALIDADO,
//            DISP=(NEW,CATLG,DELETE)
//STEP02   EXEC PGM=CALCULA
//STEP03   EXEC PGM=ATUALIZA

O princípio continua familiar.

Cada etapa realiza uma parte do trabalho.

O resultado de uma etapa pode alimentar a próxima.

O JES controla a execução.

As mensagens podem ser analisadas pelo SDSF.

O programador ainda precisa investigar códigos de retorno, abends, arquivos, condições e dependências.

Sherlock Holmes entra no SDSF

Suponha que um job terminou com erro.

O iniciante pode olhar para a tela e pensar:

“O programa quebrou.”

O analista experiente pensa diferente.

Ele pergunta:

  • Qual step falhou?

  • Qual foi o código de retorno?

  • Houve abend?

  • O arquivo existia?

  • O DISP estava correto?

  • O espaço foi suficiente?

  • O programa encontrou o registro esperado?

  • O SQLCODE indica erro de banco?

  • O problema aconteceu antes ou depois da alteração?

  • Qual mensagem apareceu primeiro?

Essa é a mentalidade investigativa.

Um erro observado no final nem sempre começou no final.

Talvez o STEP03 tenha falhado porque o STEP02 gerou um arquivo vazio.

Talvez o STEP02 tenha gerado um arquivo vazio porque o STEP01 utilizou uma data incorreta.

Talvez a data incorreta tenha sido enviada por um sistema externo.

O verdadeiro culpado pode estar muitos passos antes da mensagem final.

Elementar.

Git, DevOps e pipelines

Uma das maiores mudanças para quem retorna ao mainframe está no processo de desenvolvimento.

No modelo tradicional, o código COBOL podia permanecer em bibliotecas PDS ou PDSE, controlado por ferramentas corporativas de gerenciamento de mudanças.

Hoje, muitas empresas integram o mainframe com Git.

Isso permite trabalhar com conceitos como:

  • repositório;

  • branch;

  • commit;

  • merge;

  • pull request;

  • code review;

  • pipeline;

  • integração contínua;

  • entrega contínua.

Um fluxo moderno pode ser:

Desenvolvedor altera o COBOL
   ↓
Cria um commit
   ↓
Envia para o Git
   ↓
Pipeline inicia
   ↓
Código é compilado
   ↓
Testes são executados
   ↓
Qualidade é verificada
   ↓
Artefatos são preparados
   ↓
Implantação segue para o ambiente correto

O programa COBOL continua sendo COBOL.

O que mudou foi a estrada utilizada para levá-lo do desenvolvimento até a produção.

DevOps não é uma ferramenta

Essa distinção é importante.

DevOps não é apenas Jenkins.

Não é apenas Git.

Não é apenas pipeline.

DevOps é uma forma de organizar pessoas, processos e tecnologia para entregar software com maior frequência, segurança e rastreabilidade.

No contexto mainframe, isso pode envolver:

  • versionamento de código;

  • automação de builds;

  • testes automatizados;

  • análise de qualidade;

  • controle de mudanças;

  • infraestrutura como código;

  • observabilidade;

  • colaboração entre desenvolvimento e operação.

Para quem está retornando, não é necessário aprender tudo de uma vez.

O importante é compreender o fluxo.

Passo a passo para quem deseja voltar ao mainframe

Agora chegamos à parte prática da investigação.

Passo 1: recupere os fundamentos

Revise:

  • estrutura de programas COBOL;

  • PIC;

  • níveis de dados;

  • COMP e COMP-3;

  • tabelas;

  • REDEFINES;

  • PERFORM;

  • EVALUATE;

  • arquivos;

  • subprogramas;

  • tratamento de erros.

Não tente começar pelas ferramentas mais modernas sem recuperar a base.

Passo 2: revise JCL

Estude:

  • JOB;

  • EXEC;

  • DD;

  • DISP;

  • DSN;

  • SPACE;

  • DCB;

  • COND;

  • IF/THEN/ELSE;

  • PROC;

  • parâmetros simbólicos;

  • GDG;

  • utilitários.

O JCL continua sendo essencial para o processamento batch.

Passo 3: volte ao TSO/ISPF e SDSF

Relembre:

  • navegação no ISPF;

  • edição de membros;

  • manipulação de data sets;

  • submissão de jobs;

  • consulta de spool;

  • interpretação de mensagens;

  • análise de códigos de retorno.

Passo 4: escolha uma trilha de banco ou arquivo

Você pode aprofundar:

  • DB2 e SQL;

  • VSAM;

  • IMS DB.

Para muitos profissionais, DB2 é um excelente ponto de partida.

Passo 5: estude CICS

Compreenda:

  • transação;

  • programa;

  • COMMAREA;

  • canais e containers;

  • mapas BMS;

  • LINK;

  • XCTL;

  • START;

  • READ;

  • WRITE;

  • REWRITE;

  • DELETE;

  • códigos RESP.

Passo 6: aprenda integração moderna

Estude os conceitos de:

  • API REST;

  • JSON;

  • HTTP;

  • z/OS Connect;

  • MQ;

  • autenticação;

  • microsserviços.

Não é necessário virar especialista em desenvolvimento web.

É necessário entender como o COBOL participa do fluxo.

Passo 7: entre no mundo Git

Pratique:

git clone
git checkout -b
git add
git commit
git push
git pull

Entenda a lógica de branches e pull requests.

Passo 8: conheça pipelines

Aprenda o conceito antes da ferramenta.

Pergunte:

  • O que inicia o pipeline?

  • Como o código é compilado?

  • Onde os testes executam?

  • Como o artefato é promovido?

  • Quem aprova a mudança?

  • Como ocorre o rollback?

Passo 9: use inteligência artificial como assistente

A IA pode ajudar a:

  • explicar um trecho COBOL;

  • documentar código;

  • sugerir casos de teste;

  • analisar mensagens de erro;

  • criar exemplos;

  • comparar comandos;

  • explicar JCL;

  • revisar SQL.

Mas existe uma regra de ouro:

Nunca aceite uma resposta técnica sem validar contexto, sintaxe, impacto e segurança.

A IA é Watson.

Você continua sendo Sherlock Holmes.

A experiência ainda vale?

Vale muito.

Talvez mais do que antes.

Um profissional experiente sabe que alterar uma linha de código pode afetar:

  • outro programa;

  • outro job;

  • outro arquivo;

  • uma interface;

  • um relatório;

  • uma regra fiscal;

  • uma rotina contábil;

  • um processo noturno;

  • um sistema externo;

  • uma operação de negócio.

Essa percepção não nasce apenas em cursos.

Ela nasce de incidentes, projetos, viradas de produção, abends, reuniões, erros, acertos e noites acompanhando processamento.

O conhecimento técnico pode ser atualizado.

A maturidade sistêmica leva tempo para ser construída.

Curiosidade: por que o mainframe sobreviveu?

Porque ele resolve problemas difíceis.

Entre suas características estão:

  • alta disponibilidade;

  • segurança;

  • escalabilidade;

  • processamento transacional;

  • grande capacidade de entrada e saída;

  • gestão de cargas;

  • confiabilidade;

  • compatibilidade;

  • recuperação;

  • governança.

Empresas não mantêm mainframes por nostalgia.

Mantêm porque substituir sistemas críticos é caro, arriscado e complexo.

Além disso, a plataforma continua evoluindo.

Easter egg: o programa que ninguém queria tocar

Em quase toda grande empresa existe um programa lendário.

Ele possui milhares de linhas.

Foi escrito por alguém que se aposentou.

Tem comentários misteriosos.

Contém parágrafos chamados:

9000-ROTINA-ESPECIAL.

Ninguém sabe exatamente por que a rotina é especial.

Dentro dela há uma condição:

IF WS-CODIGO = 37
   MOVE 'S' TO WS-LIBERA
END-IF.

Todos perguntam:

“Por que 37?”

A documentação não explica.

O analista antigo diz:

“Não mexa nisso. Foi criado depois do incidente de 1998.”

Esse é o verdadeiro folclore mainframe.

Mas também revela um problema sério: conhecimento não documentado.

O profissional moderno deve preservar a confiabilidade do legado, mas também melhorar documentação, testes e rastreabilidade.

Dicas para o programador COBOL iniciante

Primeira dica: não tenha vergonha de perguntar.

Mainframe é um ecossistema enorme. Ninguém domina tudo.

Segunda dica: aprenda a ler antes de querer escrever.

Grande parte do trabalho será compreender programas existentes.

Terceira dica: siga os dados.

Quando estiver investigando um problema, acompanhe:

  • entrada;

  • transformação;

  • armazenamento;

  • saída.

Quarta dica: leia as mensagens completas.

Não olhe apenas para a última linha do erro.

Quinta dica: entenda o negócio.

Um programa não existe por causa da tecnologia. Ele existe para cumprir uma regra.

Sexta dica: evite alterações desnecessárias.

Em sistemas críticos, elegância não vale mais do que previsibilidade.

Sétima dica: teste cenários extremos.

Considere:

  • zeros;

  • valores negativos;

  • campos vazios;

  • datas inválidas;

  • duplicidade;

  • arquivo inexistente;

  • registro não encontrado;

  • SQLCODE inesperado;

  • indisponibilidade de serviço.

Oitava dica: documente o motivo.

O código mostra o que foi feito.

O comentário deve explicar por que foi feito.

O retorno não é um recomeço do zero

Quem saiu do mainframe há quinze anos não retorna como iniciante absoluto.

Retorna como alguém que já conhece parte do mapa.

Será necessário atualizar ferramentas, processos e integrações.

Mas a capacidade de analisar sistemas, compreender regras e trabalhar com responsabilidade continua presente.

Talvez você precise aprender Git.

Talvez precise entender APIs.

Talvez precise utilizar VS Code.

Talvez precise estudar pipelines.

Mas ainda reconhecerá o cheiro de um job em produção, o silêncio desconfortável de um código de retorno inesperado e a satisfação de encontrar a causa de um erro escondida em uma variável inicializada incorretamente.

Conclusão: o último mistério de Baker Street

Sherlock Holmes colocaria todas as pistas sobre a mesa:

  • o COBOL continua vivo;

  • o CICS continua processando transações;

  • o DB2 continua armazenando dados críticos;

  • o batch continua movimentando empresas;

  • o JCL continua organizando execuções;

  • o mainframe agora conversa com APIs, cloud e aplicações móveis;

  • Git e DevOps modernizaram o processo;

  • a inteligência artificial acelerou o aprendizado;

  • a experiência continua sendo um ativo valioso.

Então ele concluiria:

“O mainframe não permaneceu no passado. Ele trouxe o passado consigo, incorporou o presente e continua se preparando para o futuro.”

Para o programador COBOL iniciante, essa é uma excelente notícia.

Você está entrando em um ambiente que valoriza fundamentos.

Para o profissional que deseja retornar, a notícia é ainda melhor.

Você não perdeu tudo o que sabia.

Seu conhecimento apenas precisa ser recompilado com novas opções, testado em um novo pipeline e integrado a um ecossistema mais moderno.

No Bellacosa Mainframe, diríamos que a carreira não sofreu um ABEND definitivo.

Ela apenas ficou aguardando um novo EXEC.

E quando esse momento chegar, talvez você descubra que a plataforma mudou bastante ao redor de você, mas ainda reconhece perfeitamente os caminhos internos do sistema.

Afinal, meu caro Watson, tecnologias podem mudar de interface.

Mas bons profissionais continuam seguindo pistas, protegendo dados, compreendendo negócios e mantendo o mundo funcionando enquanto todos dormem.

Um Café no Bellacosa Mainframe — onde cada SYSOUT conta uma história, cada ABEND esconde um mistério e todo programa COBOL antigo pode guardar uma pista sobre o futuro.

 

domingo, 8 de setembro de 2024

🌸 Linguagem da rua japonesa — o “slang” do cotidiano

 

Bellacosa Mainframe e a linguagem slgan do cotidiano japones

🌸 Linguagem da rua japonesa — o “slang” do cotidiano

Enquanto o japonês formal é cheio de camadas de respeito (keigo, sonkeigo, kenjougo…), o japonês informal é puro improviso e emoção.
Essas palavras que você escuta em animes, dramas, ou no karaokê depois do saquê, nascem nas ruas de Shibuya, nas salas de aula, e até nos fóruns online tipo 2channel.
São expressões flexíveis, vivas e mutantes — um reflexo da cultura japonesa urbana e digital.


💥 1. Maji (マジ)

Significado: “Sério”, “de verdade”, “realmente”.
Origem: vem de majime (真面目), que significa “sério, honesto, aplicado”. Com o tempo, os jovens encurtaram pra “maji” — mais leve e expressivo.

Uso:

  • 「マジで?」 (Maji de?) → “Sério mesmo?”

  • 「マジかよ!」 (Maji kayo!) → “Tá brincando!?”

  • 「マジで疲れた。」 (Maji de tsukareta.) → “Tô cansado pra caramba.”

🧠 Curiosidade Bellacosa: é o equivalente japonês do nosso “sério mesmo?” ou “na moral?”. Hoje é quase universal entre jovens e aparece em quase todo anime escolar.


😩 2. Darui (だるい)

Significado: “Preguiça”, “moleza”, “sem energia”.
Origem: deriva de “darui” (怠い ou だるい) — uma palavra antiga que descrevia o corpo cansado ou sem ânimo.

Uso:

  • 「今日だるいなぁ。」 (Kyō darui naa.) → “Tô mole hoje.”

  • 「授業だるい。」 (Jugyō darui.) → “A aula tá chata/pesada.”

🧘 Bellacosa Note: É a palavra do adolescente de segunda-feira. É o “aff” japonês, o “que preguiça” dos tempos modernos.


⚡ 3. Yabai (ヤバい)

Significado: originalmente “perigoso”, mas hoje pode ser “incrível”, “tenso”, “lascou”, “da hora”, dependendo do contexto.
Origem: vem do dialeto de criminosos no Japão do século XX — yabai descrevia uma situação arriscada (tipo “a polícia tá vindo”).
Com o tempo, virou um gíria universal que expressa tanto perigo quanto admiração.

Uso:

  • 「このラーメンやばい!」 (Kono rāmen yabai!) → “Esse ramen tá incrível!”

  • 「テストやばい…」 (Tesuto yabai…) → “Tô ferrado na prova…”

🔥 Bellacosa Insight: É o “mano do céu!” japonês. Pode ser bom ou ruim — depende do tom e do contexto. É o camaleão das gírias nipônicas.


🤝 4. Sorena (それな)

Significado: “Verdade!”, “Exatamente isso!”, “Concordo total.”
Origem: junção de sore (isso) + na (partícula de concordância ou ênfase). Literalmente “isso aí, né”.

Uso:

  • 「あの先生うるさいよね。」→「それな!」 (Aquele professor é chato, né?Pois é!)

Bellacosa Reflexão: é o “totalmente”, “é isso aí”, o “fala tudo” japonês — usado em bate-papo entre amigos pra demonstrar sintonia.


🫡 5. Otsu (おつ)

Significado: abreviação de otsukaresama (お疲れ様) — algo como “bom trabalho”, “valeu pelo esforço”.
Origem: vem da etiqueta do trabalho japonês. É dito ao final de um expediente, ou ao terminar uma tarefa.

Uso:

  • 「おつかれ!」 (Otsukare!) → “Valeu, bom trabalho!”

  • 「おつ!」 (Otsu!) → “Falou!”, “Tamo junto!”

💼 Bellacosa Contexto: no mundo corporativo japonês, é quase um ritual: você diz “otsukaresama deshita” ao sair, mesmo que o colega ainda vá ficar.
No digital (LINE, Discord, games), virou o “flw”, “vlw”, “gg” japonês.


🎌 Epílogo Bellacosa Mainframe

Essas cinco palavras — maji, darui, yabai, sorena, otsu — são o código-fonte da alma jovem japonesa.
Misturam respeito e rebeldia, tradição e modernidade, como o COBOL e o JSON da língua falada.
O Japão pode ser milenar e hierárquico, mas na esquina de Akihabara, no Discord gamer, ou no barzinho de Shinjuku, o japonês vivo respira, ri e cria novas versões de si mesmo — sempre com um toque de yabai energia.


sábado, 7 de setembro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON PARSE - Parte II

 

Bellacosa Mainframe e o json no cobol parte II

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 2 – JSON PARSE

Quando o Padawan Aprende a Transformar Texto em Estruturas COBOL

Por Bellacosa Mainframe


"JSON é apenas texto. O verdadeiro poder está em fazer COBOL compreender esse texto como se fosse uma estrutura nativa do IBM Z."

Mestre Bellacosa Sysprog Jedi


Introdução

Na Parte 1, o Padawan descobriu algo surpreendente.

COBOL moderno fala JSON.

Aprendemos:

  • JSON GENERATE

  • UTF-8

  • CCSID

  • Enterprise COBOL 6.x

  • APIs REST

  • JSON em memória

  • Segurança básica

Agora chegamos ao momento em que o programa COBOL deixa de apenas produzir JSON.

Ele começa a entender JSON.

E isso acontece através de uma instrução quase mágica.

JSON PARSE


O que é JSON PARSE?

JSON PARSE é o tradutor universal.

Ele recebe.

Texto.

Transforma.

Em estruturas COBOL.


Visualmente.

JSON


↓

JSON PARSE


↓

WORKING STORAGE


↓

Programa COBOL

Exemplo.

Recebemos.

{
"id":100,

"nome":"Bellacosa",

"idade":52
}

COBOL deseja.

01 CLIENTE.

05 ID.

PIC 9(5).


05 NOME.

PIC X(30).


05 IDADE.

PIC 999.

JSON PARSE faz isso.

Automaticamente.


Quando surgiu?

IBM introduziu.

JSON PARSE

Enterprise COBOL

Version 6.


Mais utilizado hoje.

6.3

6.4

6.5


Mudou completamente.

Integrações.


Primeiro programa JSON PARSE

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

Passo 2

Buffer JSON

01 WS-JSON.

PIC X(500).

Passo 3

Popular

MOVE

'{"id":100,

"nome":"Bellacosa",

"idade":52}'


TO WS-JSON

Passo 4

Parse

JSON PARSE

WS-JSON

INTO WS-CLIENTE

Passo 5

Display

DISPLAY WS-ID.


DISPLAY WS-NOME.


DISPLAY WS-IDADE.

Resultado.

100


Bellacosa


52

Pronto.

JSON virou COBOL.


O que acontece internamente?

Compilador cria.

Parser interno.


Percorre.

Caractere.

Por caractere.


Reconhece.

Chaves.

Aspas.

Números.

Vetores.


Mapeia.

Campos.


Visualmente.

{


"id"



100



}


↓

COBOL


ID=100

Como funciona na memória?

JSON continua sendo texto.


Exemplo.

Buffer


500 bytes

Parser lê.


Move dados.


Para.

Working Storage.


Resultado.

WS-ID


100



WS-NOME


Bellacosa

Sem ponteiros.

Sem árvore.

Sem DOM.


Muito eficiente.


Objetos Aninhados

JSON suporta.

Estruturas.

Dentro.

De estruturas.


Exemplo.

{

"cliente":{

"id":1,

"nome":"Bellacosa"

}

}

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.

Muito elegante.


Arrays

Chegamos.

Ao lado divertido.


JSON.

{

"telefones":[

"1111",

"2222"

]

}

COBOL.

05 TELEFONES.

10 TEL OCCURS 10.


15 NUMERO.


PIC X(20).

Parser.

Preenche.


COUNT IN

Muito útil.


Exemplo.

JSON PARSE

WS-JSON


INTO WS-DADOS


COUNT IN WS-CONTADOR

Retorna.

Quantidade.

Itens.


Excelente.

Para.

Arrays.


ON EXCEPTION

Fundamental.

Nunca esquecer.


Exemplo.

JSON PARSE

WS-JSON


INTO WS-CLI


ON EXCEPTION


DISPLAY 'ERRO'

Padawan.

Sempre use.


Exemplo inválido

JSON.

{


"id":100


"nome":"Bellacosa"

Aspa.

Faltando.


Parser.

Falha.


ON EXCEPTION.

Executado.


JSON Malicioso

Poucos falam.

Mas existe.


Payload.

Gigante.


Exemplo.

50 MB.


Consome.

CPU.


Memória.


Tempo.


DoS.


Negação.

Serviço.


Boa prática

Validar.

Tamanho.


Exemplo.

IF WS-LEN > 100000

DISPLAY 'ERRO'

Muito recomendado.


Nomes diferentes

JSON.

Pode vir.

{

"customer_name":"Bellacosa"

}

COBOL.

05 WS-NOME.

Problema.


Precisamos.

Mapear.


Enterprise COBOL possui.

NAME OF.

SUPPRESS.


Falaremos.

Parte 3.


UTF8

Grande inimigo.


JSON.

UTF8.


COBOL.

EBCDIC.


José.

Pode quebrar.


Ç.

Ã.

É.


Atenção.

Sempre.


JSON NULL

JSON.

{


"nome":null
}

COBOL.

Não possui.

Null textual.


Precisamos.

Tratar.


Muito importante.


Performance

Excelente.


JSON PARSE.

É compilado.


Muito rápido.


Melhor.

Que parser.

Manual.


Evite.

UNSTRING


INSPECT


STRING

Desnecessário.


JSON PARSE.

Resolve.


Curiosidades

Muitos bancos.

Recebem.

Milhões.

JSON.

Por dia.


Aplicativos.

PIX.

Cartão.

Open Finance.


Tudo passa.

Por.

JSON.


E em muitos casos.

Existe.

COBOL.

No fim.

Da cadeia.


Debug

Exemplo.

DISPLAY WS-JSON

Muito útil.


Ou.

IBM Debug Tool.


Fault Analyzer.


Dump.


Quando usar?

Excelente.

REST

MQ

Kafka

zOS Connect

Mobile

Open Banking

PIX

Cloud


Quando evitar?

Arquivos internos.


VSAM.


Relatórios.


Batch tradicional.


Bellacosa Best Practices

Sempre

Use ON EXCEPTION


Sempre

Validar tamanho


Sempre

Testar UTF8


Sempre

Documentar JSON


Sempre

Versionar APIs


O Conselho do Mestre Bellacosa

JSON PARSE é provavelmente uma das maiores evoluções já incorporadas ao Enterprise COBOL.

Ele permite que um programa escrito há vinte ou trinta anos compreenda payloads produzidos por smartphones, microsserviços, plataformas OpenShift e aplicações espalhadas pela Internet.

O jovem Padawan deve perceber uma verdade importante.

JSON continua sendo apenas texto.

Mas JSON PARSE transforma esse texto em algo que COBOL entende profundamente.

Estruturas.

Campos.

Vetores.

Níveis.

OCCURS.

Variáveis.

E talvez essa seja a maior beleza do IBM Z moderno.

Ele não exige que o desenvolvedor abandone décadas de conhecimento.

Ele apenas oferece novas ferramentas.

E diz:

Continue programando em COBOL.

Continue usando seus níveis 01, 05 e 10.

Continue confiando em sua experiência.

Eu apenas ensinarei ao seu programa a compreender uma nova linguagem falada por toda a galáxia digital.


Continua na Parte 3

JSON GENERATE – Quando o Padawan Aprende a Construir APIs REST com COBOL, Criar Payloads Elegantes, Controlar Campos, Suprimir Dados e Falar com Microsserviços do Futuro.


domingo, 1 de setembro de 2024

Num futuro bem distante... o Cobol continuará na ativa


Bellacosa Mainframe e uma perspectiva sobre o futuro do COBOL

☕ Um Café no Bellacosa Mainframe

COBOL no Futuro

Quando um Programador Descobre que o Último Ser Humano a Escrever COBOL Talvez Ainda Nem Tenha Nascido

Existe uma lenda que circula pela informática desde os anos 1980.

Ela aparece de tempos em tempos, sempre com uma roupa diferente.

Em 1985 diziam:

"COBOL morreu."

Em 1995:

"Agora é definitivo."

Em 2005:

"A web acabou com ele."

Em 2015:

"Cloud enterrou o mainframe."

Em 2025:

"A IA vai substituir todos os programadores COBOL."

Enquanto isso...

...o compilador recebeu novas versões.

O z/OS ganhou novos recursos.

O Db2 evoluiu.

O CICS aprendeu REST.

O MQ continuou transportando bilhões de mensagens.

E o COBOL...

...continuou trabalhando sem fazer propaganda. 



Imagine um arqueólogo daqui a 200 anos.

Ele encontra uma cápsula do tempo contendo um notebook.

Liga o equipamento.

Dentro existe um projeto Git.

Abre o README.


Primeira linha:

Enterprise COBOL 6.7

Ele pergunta:

— "Isso ainda funciona?"

A Inteligência Artificial responde:

— "Claro."

— "Mas esse software tem quase três séculos."

— "Sim."

— "Quem mantém isso?"

A IA faz silêncio durante alguns nanossegundos.

Depois responde:

— "Os bancos."


Existe algo curioso sobre tecnologia.

Nós adoramos imaginar o futuro.

Carros voadores.

Computadores quânticos.

Robôs domésticos.

Colonização de Marte.

Mas quase ninguém imagina quem vai calcular a folha de pagamento da primeira colônia marciana.

Spoiler.

Provavelmente algum programa COBOL.


Imagine uma agência bancária em Marte.

Cliente entra.

— Gostaria de financiar um módulo habitacional na Cratera Gale.

O atendente responde:

— Um instante...

A tela mostra:

CICS Transaction Started

EXEC SQL
SELECT LIMIT
FROM CLIENTE_MARTE
END-EXEC

O planeta mudou.

A gravidade mudou.

A distância até a Terra mudou.

Mas o COMMIT continua funcionando.


A verdade é que COBOL possui uma qualidade extremamente rara na informática.

Ele não tenta impressionar ninguém.

Nunca tentou.

Java queria revolucionar.

JavaScript queria dominar.

Python queria simplificar.

Rust queria proteger memória.

Go queria ser minimalista.

COBOL apenas perguntou:

— O salário caiu na conta?


Enquanto linguagens brigam por benchmarks...

COBOL mede sucesso em décadas.


Talvez seja justamente esse o segredo.

Toda tecnologia nova promete velocidade.

Toda tecnologia antiga entrega estabilidade.

O mundo precisa das duas.

Mas só uma delas costuma pagar aposentadorias.


Hoje falamos sobre Inteligência Artificial.

Modelos generativos.

Agentes autônomos.

LLMs.

Copilots.

A pergunta moderna não é mais:

"Como escrever COBOL?"

Agora é:

"Como fazer uma IA entender cinquenta milhões de linhas escritas desde 1972?"

De repente...

O conhecimento do programador COBOL deixou de ser apenas programação.

Virou arqueologia digital.

Virou engenharia reversa.

Virou tradução entre gerações.

Virou patrimônio tecnológico.


Imagine uma IA especializada em manutenção.

Ela abre um programa de 18.000 linhas.

Depois de alguns segundos declara:

— Detectei um IF desnecessário.

O programador sorri.

— Não mexa.

— Por quê?

— Porque aquele IF resolve um bug descoberto em 1989 durante o Plano Verão.

— Mas ele nunca será executado.

— Eu sei.

— Então por que existe?

— Porque um cliente jurou que aconteceu.

A IA fica em silêncio.

Anota:

Conhecimento ancestral detectado.


Aliás...

Existe uma teoria divertida.

Quanto mais antiga a aplicação...

...menos pessoas querem modificá-la.

E quanto menos modificada...

...mais tempo ela continua funcionando.

Talvez o maior segredo da alta disponibilidade seja simplesmente deixar o programa em paz.


Outro paradoxo interessante.

Em 2035 provavelmente teremos computadores capazes de executar trilhões de instruções por segundo.

Mesmo assim...

alguém continuará escrevendo:

MOVE ZEROES TO SALDO.

Porque algumas coisas não precisam mudar.

Precisam apenas continuar corretas.


Há quem imagine que o futuro pertence apenas à Inteligência Artificial.

Discordo.

O futuro pertence à parceria.

A IA encontrará o programa.

Explicará o fluxo.

Gerará testes.

Criará documentação.

Sugerirá melhorias.

Mas alguém continuará fazendo a pergunta que realmente importa:

"Se eu alterar esta linha...

...quanto dinheiro deixa de chegar ao cliente?"

Essa pergunta continua sendo humana.


E talvez seja essa a maior transformação da carreira COBOL.

O programador deixará de ser apenas um codificador.

Será um historiador dos sistemas.

Um engenheiro de confiabilidade.

Um tradutor entre regras de negócio de cinquenta anos atrás e APIs que ainda nem existem.

Será menos digitador.

Mais estrategista.


Existe uma ironia maravilhosa nisso tudo.

Durante décadas disseram que COBOL era velho demais.

Agora descobrimos que justamente a experiência acumulada virou seu maior diferencial.

A IA aprende com dados.

O programador COBOL aprende com consequências.

São competências diferentes.

E extremamente complementares.


Talvez daqui a cinquenta anos alguém pergunte:

— Ainda existe COBOL?

A resposta provavelmente será a mesma de hoje.

Existe.

Só que agora ele conversa naturalmente com APIs, microsserviços, eventos, nuvem híbrida, IA generativa, agentes autônomos, computação quântica, criptografia pós-quântica e tudo o que ainda será inventado.

Porque linguagens não sobrevivem por serem modernas.

Sobrevivem porque resolvem problemas importantes.


No fim das contas, talvez COBOL nunca tenha sido uma linguagem de programação.

Talvez sempre tenha sido uma máquina do tempo.

Cada programa guarda decisões tomadas por pessoas que talvez nem estejam mais entre nós.

Cada COPYBOOK conta um pedaço da história de uma empresa.

Cada arquivo VSAM é um museu vivo.

Cada JCL é uma carta enviada do passado para o futuro.

E cada novo programador que abre um código legado descobre que não está apenas lendo instruções para um computador.

Está conversando com gerações inteiras de engenheiros que construíram, linha por linha, a infraestrutura invisível que movimenta o mundo.

E talvez esse seja o maior plot twist da computação moderna.

Enquanto todos olham para a próxima tecnologia revolucionária...

o COBOL continua, silenciosamente, preparando o futuro — exatamente da mesma forma que fez nos últimos sessenta e cinco anos.

Sem fazer barulho.

Sem precisar provar nada.

Apenas executando o próximo JOB.


Bellacosa Mainframe é uma visão do COBOL

COBOL FOREVER



  

sábado, 31 de agosto de 2024

Padawans Aprendam COBOL

Bellacosa Mainframe e o misterio do codigo que nunca morre


☕ Um Café no Bellacosa Mainframe

O Mistério do Código que Nunca Morreu

Por que um Programador Iniciante Deve Aprender COBOL?

Revista Bellacosa Mainframe — Edição Especial — Inspirada nas Grandes Revistas de Mistério dos Anos 1950


Prólogo: O Caso do Cadáver que Continuava Trabalhando

Londres.

Nova York.

São Paulo.

Tóquio.

Frankfurt.

Em todos esses lugares existe um crime aparentemente impossível.

Há décadas, especialistas anunciam que COBOL morreu.

Mesmo assim...

milhões de pagamentos são realizados.

Bilhões de dólares são movimentados.

Cartões de crédito continuam autorizando compras.

Aposentadorias continuam sendo pagas.

Voos continuam sendo vendidos.

Seguros continuam sendo emitidos.

Então surge a pergunta que todo detetive faz diante de um cadáver que insiste em respirar:

Quem está realmente morto? O COBOL... ou as previsões?

Pegue sua lupa.

Acenda o cachimbo.

A investigação começa agora.


Caso nº 1 — O Cofre dos Bilhões

Nos anos 1950, toda revista policial possuía um banco misterioso.

No nosso caso, o banco existe de verdade.

Imagine que você entra em uma instituição financeira.

Você vê:

  • aplicativo moderno

  • internet banking

  • biometria

  • reconhecimento facial

  • IA

  • chatbot

Tudo parece extremamente moderno.

Mas quando você aperta o botão Transferir...

...a ordem viaja por dezenas de sistemas...

...até encontrar um programa COBOL criado anos ou até décadas atrás.

Esse programa decide:

  • existe saldo?

  • há limite?

  • qual tarifa cobrar?

  • qual imposto aplicar?

  • qual conta debitar?

É ali que mora o dinheiro.

Não na interface.

Não no aplicativo.

Mas na lógica construída ao longo de muitos anos.

O iniciante normalmente imagina que aprender COBOL significa estudar tecnologia antiga.

Na realidade, significa compreender como funciona o coração financeiro do planeta.


Caso nº 2 — O Código que Já Sobreviveu a Cinco Gerações

Imagine um investigador encontrando um relógio.

O fabricante fechou.

Os donos morreram.

As ferramentas desapareceram.

Mesmo assim...

o relógio continua funcionando perfeitamente.

Esse é o COBOL.

Ele atravessou:

  • cartões perfurados

  • fitas magnéticas

  • discos DASD

  • terminais 3270

  • PCs

  • Internet

  • Cloud

  • IA Generativa

Pouquíssimas linguagens podem contar essa história.

Java?

Ainda é jovem.

Python?

Mais jovem ainda.

Rust?

Recém-nascido.

COBOL já viu praticamente todas as revoluções da informática.

Quem aprende COBOL também aprende a evolução da computação corporativa.


Caso nº 3 — A Linguagem que Foi Feita para Ser Lida

Todo detetive precisa ler relatórios.

COBOL foi criado exatamente com essa filosofia.

Compare.

Linguagens tradicionais:

x=x+y*z

COBOL:

COMPUTE TOTAL = VALOR + IMPOSTO * TAXA

Ou ainda:

IF CLIENTE-INADIMPLENTE

    PERFORM BLOQUEAR-CONTA

END-IF

Mesmo alguém que nunca programou consegue entender a intenção.

Isso reduz erros.

E reduz erros porque COBOL foi desenvolvido para negócios, não para matemáticos.


Caso nº 4 — O Enigma da Estabilidade

Imagine um elevador.

Você entra nele todos os dias.

Durante quarenta anos.

Ele nunca para.

Nunca cai.

Nunca apresenta defeito.

É exatamente isso que empresas esperam de seus sistemas.

Enquanto muitos softwares modernos são atualizados diariamente...

...um programa COBOL pode executar milhões de vezes exatamente da mesma forma.

Essa previsibilidade vale ouro.

Empresas preferem estabilidade do que novidades.


Caso nº 5 — A Biblioteca Perdida

Todo investigador sabe:

o verdadeiro tesouro nunca é o ouro.

É a informação.

Dentro das empresas existem milhões de linhas COBOL.

Ali está registrado:

  • regras fiscais

  • legislação

  • cálculos bancários

  • contratos

  • seguros

  • previdência

  • financiamentos

Em muitos casos...

ninguém mais sabe exatamente por que determinada regra existe.

O programa virou documentação viva.

Aprender COBOL é aprender a interpretar esse patrimônio.

É quase uma arqueologia tecnológica.


Caso nº 6 — A Falsa Cena do Crime

Durante anos ouvimos:

"COBOL acabou."

Mas os fatos contam outra história.

O mercado continua procurando profissionais porque:

  • sistemas continuam crescendo;

  • novas integrações surgem diariamente;

  • APIs REST conversam com programas COBOL;

  • IA ajuda a compreender código legado;

  • DevOps chegou ao IBM Z;

  • Git chegou ao Mainframe;

  • VS Code conversa com z/OS.

Ou seja...

o ambiente mudou completamente.

Hoje o desenvolvedor utiliza:

  • Git

  • Jenkins

  • VS Code

  • Zowe

  • OpenShift

  • APIs REST

  • IA

Tudo isso ao lado do COBOL.

O "legado" tornou-se parte do ecossistema moderno.


Caso nº 7 — O Salário Invisível

Existe um detalhe curioso.

Todo mundo aprende linguagens populares.

Poucos aprendem COBOL.

Resultado?

Oferta menor de profissionais.

Demanda constante.

Não existe fórmula mágica para salários elevados.

Mas especialização sempre aumenta o valor profissional.

Enquanto milhares disputam vagas em tecnologias da moda...

o especialista em Mainframe frequentemente encontra menos concorrência.


Caso nº 8 — A Universidade da Engenharia de Software

COBOL ensina disciplina.

Antes de escrever código você aprende:

  • análise

  • documentação

  • regras de negócio

  • organização

  • modularização

  • nomenclatura

  • testes

  • tratamento de erros

Essa formação faz diferença.

Quem domina COBOL costuma entender melhor sistemas corporativos enormes.

Depois aprender Java, Python ou C# torna-se muito mais simples.


Caso nº 9 — O Detetive e a Inteligência Artificial

Aqui está uma das maiores reviravoltas da investigação.

Durante muito tempo diziam:

"A IA vai substituir COBOL."

O que realmente aconteceu?

A IA passou a ajudar programadores COBOL.

Hoje ela consegue:

✔ explicar programas antigos;

✔ localizar bugs;

✔ gerar documentação;

✔ sugerir melhorias;

✔ converter estruturas;

✔ explicar COPYBOOKs;

✔ resumir regras de negócio.

O investigador ganhou um parceiro.

Não perdeu o emprego.


Caso nº 10 — O Verdadeiro Segredo

Depois de investigar centenas de pistas...

chegamos à maior descoberta.

O COBOL nunca foi apenas uma linguagem.

Ele é uma enorme biblioteca de conhecimento empresarial.

Quando um iniciante aprende COBOL, ele não aprende apenas comandos como:

MOVE

READ

WRITE

IF

PERFORM

Ele aprende:

como bancos funcionam.

Como seguros calculam riscos.

Como cartões autorizam compras.

Como governos pagam benefícios.

Como empresas controlam bilhões de registros.

Aprender COBOL é estudar processos de negócio em escala mundial.


Dossiê Bellacosa — Dez Motivos Para Aprender COBOL

🕵️ Resolve problemas reais.

🕵️ Está presente nas maiores empresas do mundo.

🕵️ Ensina lógica extremamente organizada.

🕵️ Desenvolve disciplina de engenharia de software.

🕵️ Trabalha junto com IA, APIs e Cloud.

🕵️ Abre portas para IBM Z e Mainframe.

🕵️ Dá acesso a sistemas críticos.

🕵️ Permite compreender décadas de evolução tecnológica.

🕵️ Continua sendo procurado pelo mercado.

🕵️ Forma profissionais capazes de entender tecnologia e negócios ao mesmo tempo.


Arquivo Confidencial

Ao final desta investigação, resta apenas uma pergunta.

Por que tantas pessoas acreditam que COBOL morreu?

Talvez porque nunca tenham entrado na sala onde o verdadeiro trabalho acontece.

Longe das luzes da interface gráfica, atrás de paredes de concreto dos grandes CPDs, existem computadores IBM Z processando milhões de transações por segundo. Em cada transação há uma decisão tomada por regras escritas em COBOL, muitas delas executadas continuamente há décadas, com precisão admirável.

O mistério, portanto, nunca foi "por que aprender COBOL?"

O verdadeiro mistério é outro:

Como uma linguagem criada em 1959 continua tão relevante em 2026, atravessando gerações, sobrevivendo a modismos tecnológicos e trabalhando silenciosamente onde o mundo não pode parar?

Talvez seja justamente isso que transforma o COBOL no maior "caso não resolvido" da história da computação — um código que muitos declararam morto, mas que continua vivo, invisível e indispensável, resolvendo milhões de problemas enquanto todos olham para outra direção. E, para o iniciante que decide seguir essas pistas, aprender COBOL pode ser menos uma viagem ao passado e mais a descoberta dos alicerces que ainda sustentam uma parte significativa da economia digital.


Aproveite, comente, compartilhe, convide e marque aquele padawan que programa em Python e não

 conhece COBOL

🔻 O Século da Mentira: quando o mundo inteiro começou a falar a língua do tirano




 🔻 O Século da Mentira: quando o mundo inteiro começou a falar a língua do tirano

Por Bellacosa Mainframe | Encerramento da Série “Anatomia de um Regime Fantasma”


Há uma ironia amarga no nosso tempo:
O século XXI prometeu transparência — e nos entregou reflexos distorcidos.
A verdade, tão abundante quanto o Wi-Fi, tornou-se descartável.
Vivemos na era em que todos dizem algo, e ninguém realmente sabe.

O autoritarismo russo não criou essa era.
Apenas a antecipou.
O resto do mundo — democrático, ocidental, progressista — acabou por imitá-lo, com filtros e hashtags.


🌐 O Sistema da Mentira Global
A mentira moderna não precisa de censura.
Ela precisa de distração.

É o século do scroll infinito, da indignação programada, da timeline que decide o que você acredita.
Enquanto os velhos regimes controlavam a informação pela ausência, os novos fazem o oposto: te afogam nela.
A desordem é a nova forma de controle.

O Kremlin entendeu isso cedo — e o planeta aprendeu rápido demais.


🧠 O Colapso da Verdade
Antigamente, a verdade era uma busca.
Hoje, é um incômodo.
As pessoas não querem saber, querem pertencer.
E o pertencimento moderno é algorítmico: quem questiona, é excluído.

As democracias, cansadas e cheias de ruído, começaram a adotar a gramática do medo.
Chamam vigilância de segurança.
Chamam manipulação de engajamento.
Chamam conformismo de “consenso social”.

A mentira já não tem dono — é multinacional.


📡 O Mundo Conectado, Desconectado de Si Mesmo
Enquanto a Ucrânia sangra no frio, a informação viaja mais rápido que qualquer socorro.
Mas a compaixão não acompanha a velocidade.
Estamos sobrecarregados de tragédias, incapazes de sentir todas elas.

O império russo mostrou o roteiro; o resto do planeta seguiu a encenação.
Hoje, a verdade é só mais um formato de conteúdo — sujeita a edição, monetização e esquecimento.


🩸 O Novo Autoritarismo: Limpo, Digital e Elegante


Não há mais campos de prisioneiros, há termos de serviço.
Não há mais propaganda, há tendências patrocinadas.
Não há mais censura, há recomendações personalizadas.

A ditadura contemporânea não grita — ela sussurra.
E o silêncio vem disfarçado de escolha.

O século da mentira é sofisticado demais para botas e bandeiras.
Ele usa logotipos, feeds e discursos sobre empatia.


💬 Para o Padawan que tenta enxergar entre os ruídos:
A verdade ainda existe — mas agora exige esforço.
Exige solidão, dúvida, e coragem de desconfiar até do que confirma nossas crenças.

“No fim, o inimigo da verdade não é a mentira,
é a indiferença.”


🕯️ Vivemos no século em que a mentira se tornou infraestrutura.
E cada vez que aceitamos o absurdo como rotina,
ela cresce, polida, funcional, elegante —
até o dia em que não reste mais ninguém para lembrar que era uma mentira.

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