☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

sábado, 9 de janeiro de 2021

Redes Neurais: Quando um Programador Descobre que a Inteligência Artificial Não Mora em Python

 

Bellacosa Mainframe em introducao a redes neurais

☕ Um Café no Bellacosa Mainframe

Redes Neurais sem Mistérios para Programadores COBOL

Quando um Programador Descobre que a Inteligência Artificial Não Mora em Python — Ela Está Submersa em um Oceano de Matrizes, Gradientes e Pesos que Ninguém Documentou no COPYBOOK

Existe uma antiga lenda nos corredores refrigerados dos data centers.

Ela afirma que redes neurais são criaturas mágicas criadas por programadores de Python, alimentadas com placas de vídeo, café artesanal e bibliotecas cujo nome muda a cada quinze minutos.

Segundo essa lenda, basta escrever:

model.fit(x, y)

Depois disso, luzes piscam, ventiladores entram em rotação de emergência, a conta da nuvem sobe até a estratosfera e uma inteligência artificial nasce completamente formada, como uma deusa tecnológica saindo de uma concha de silício.

Naturalmente, isso é uma bobagem.

Redes neurais não são fundamentalmente sobre Python, TensorFlow, PyTorch, notebooks, APIs ou data scientists usando moletons em ambientes climatizados.

Redes neurais são, antes de tudo, matemática executada muitas vezes.

Muitas mesmo.

Milhões, bilhões ou trilhões de vezes.

O código apenas organiza o mergulho. A matemática é o oceano.

Nesta expedição do Bellacosa Mainframe ao Fundo do Mar, vamos embarcar em um submarino experimental, descer pelas camadas abissais da inteligência artificial e investigar seis estruturas fundamentais:

  1. Transformações lineares

  2. Funções de ativação

  3. Funções de custo

  4. Retropropagação

  5. Métodos de otimização

  6. Matrizes e vetores

Também encontraremos probabilidades, gradientes, redes profundas, neurônios artificiais, parâmetros perdidos e talvez um programador COBOL aposentado vivendo dentro de uma LPAR esquecida desde 1987.

Prepare o terminal 3270.

Verifique a pressão do casco.

E, por segurança, não execute nada diretamente em produção.


Capítulo 1 — Descendo Além da Superfície do Código

Na superfície, uma rede neural parece um programa.

Ela recebe dados, processa informações e produz uma resposta.

Por exemplo:

ENTRADA:
Imagem de um animal

PROCESSAMENTO:
Rede neural

SAÍDA:
92% de probabilidade de ser um gato

Para quem olha de longe, parece apenas mais um sistema.

Entrada, processamento e saída.

Nada que um programador COBOL não tenha visto desde que os discos eram grandes como mesas de jantar e os operadores usavam jalecos brancos para trocar fitas magnéticas.

A diferença está no modo como as regras são construídas.

Em um programa tradicional, alguém escreve explicitamente:

IF ORELHAS-PONTUDAS
   AND TEM-BIGODES
   AND MIA
       MOVE 'GATO' TO TIPO-ANIMAL
END-IF

Em uma rede neural, ninguém escreve diretamente essas regras.

A rede recebe muitos exemplos de gatos e outros animais. Durante o treinamento, ela ajusta milhões de valores numéricos até encontrar combinações que permitam separar gatos, cachorros, capivaras e, em casos mais sofisticados, gerentes de projeto pedindo estimativas para ontem.

Esses valores numéricos são chamados de pesos.

Treinar uma rede neural significa encontrar pesos adequados.

Portanto, a inteligência não está em uma sequência de IF, ELSE ou EVALUATE.

Ela está distribuída por uma grande coleção de números.

Em termos de mainframe, seria como se as regras de negócio não estivessem claramente escritas no PROCEDURE DIVISION, mas espalhadas por bilhões de campos COMP-1, COMP-2 e matrizes carregadas em memória.

Um cenário que faria qualquer auditor pedir transferência imediata para o departamento de patrimônio.


Capítulo 2 — O Neurônio Artificial e a Transformação Linear

O componente básico de uma rede neural é o neurônio artificial.

Apesar do nome grandioso, ele começa com uma operação bastante simples:

z = Wx + b

Onde:

  • x representa os valores de entrada;

  • W representa os pesos;

  • b representa o bias, ou viés;

  • z representa o resultado da transformação.

Vamos traduzir isso para uma linguagem compreensível por um programador COBOL iniciante.

Imagine um sistema que tenta estimar o preço de uma casa.

Temos três entradas:

Área:        120 m²
Quartos:       3
Garagens:      2

A rede atribui um peso para cada característica:

Peso da área:       2.000
Peso dos quartos:  15.000
Peso da garagem:    8.000

O cálculo seria aproximadamente:

120 × 2.000 = 240.000
  3 × 15.000 = 45.000
  2 × 8.000 = 16.000

Somando:

240.000 + 45.000 + 16.000 = 301.000

Depois acrescentamos o bias:

301.000 + 12.000 = 313.000

A previsão da rede seria:

R$ 313.000

Em COBOL conceitual:

COMPUTE PRECO-ESTIMADO =
       (AREA       * PESO-AREA)
     + (QUARTOS    * PESO-QUARTOS)
     + (GARAGENS   * PESO-GARAGENS)
     + BIAS
END-COMPUTE.

Nada sobrenatural aconteceu.

A rede apenas realizou uma soma ponderada.

A palavra “ponderada” significa que cada entrada tem uma importância diferente.

Se o peso da área for grande, a área influencia bastante o resultado.

Se o peso da garagem for próximo de zero, a garagem praticamente não importa.

Se o peso for negativo, determinada característica pode reduzir o valor previsto.

O grande mistério não está no cálculo.

Está em descobrir os pesos corretos.


Capítulo 3 — O Bias: O Pequeno Parâmetro que Move Montanhas

O bias costuma ser tratado como um detalhe, mas é fundamental.

Sem ele, temos:

z = Wx

Com ele:

z = Wx + b

Geometricamente, o bias permite deslocar uma reta, um plano ou uma fronteira de decisão.

Imagine uma reta que obrigatoriamente passa pelo ponto zero.

Sem bias, a rede fica presa a essa restrição.

Com bias, ela pode mover a reta para cima, para baixo ou para outra região do espaço.

Uma analogia para o mundo COBOL seria um valor padrão ou ajuste operacional que não depende diretamente do registro de entrada.

Por exemplo:

COMPUTE VALOR-FINAL =
       VALOR-BASE
     + TAXA-FIXA
END-COMPUTE.

A TAXA-FIXA não nasceu dos dados do cliente. Ela é um deslocamento adicional do cálculo.

O bias faz algo semelhante.

Curiosidade: em muitas redes modernas, existem milhões ou bilhões de pesos, mas os biases continuam discretamente trabalhando, como aquele programa utilitário de 1979 que ninguém menciona, mas cuja remoção derruba o fechamento contábil de três países.


Capítulo 4 — Por Que Uma Rede Precisa de Funções de Ativação?

Se uma rede usasse apenas transformações lineares, ela teria um problema grave.

Imagine várias camadas:

Camada 1: z1 = W1x + b1
Camada 2: z2 = W2z1 + b2
Camada 3: z3 = W3z2 + b3

Mesmo empilhando muitas dessas operações, o resultado final ainda poderia ser reduzido a uma única transformação linear.

Seria como escrever mil programas COBOL que apenas movem campos de uma área para outra e esperar que, por algum milagre, eles desenvolvam consciência.

Não desenvolverão.

Talvez produzam um arquivo de saída com LRECL incorreto, mas consciência não.

Para aprender padrões complexos, a rede precisa de não linearidade.

É aí que entram as funções de ativação.


Capítulo 5 — ReLU: A Portinhola do Submarino

A função ReLU é definida assim:

f(x) = max(0, x)

Na prática:

-10 vira 0
 -3 vira 0
  0 vira 0
  4 vira 4
 15 vira 15

Ela corta valores negativos e mantém os positivos.

É simples, rápida e eficiente.

Em pseudocódigo COBOL:

IF VALOR-ENTRADA > 0
    MOVE VALOR-ENTRADA TO VALOR-SAIDA
ELSE
    MOVE ZERO TO VALOR-SAIDA
END-IF.

A ReLU permite que diferentes neurônios sejam ativados para diferentes tipos de entrada.

Alguns podem reagir a linhas verticais em uma imagem.

Outros, a bordas.

Outros, a formas mais complexas.

Em uma rede profunda, as primeiras camadas detectam padrões simples. As camadas posteriores combinam esses padrões.

Em reconhecimento de imagens, poderíamos ter:

Camada inicial:
Detecta bordas

Camada intermediária:
Detecta olhos, orelhas e texturas

Camada profunda:
Detecta um rosto ou um animal

Camada final:
Classifica como gato, cachorro ou entidade fiscalizadora

A não linearidade permite que a rede construa fronteiras complexas.

Sem ela, o submarino só poderia navegar em linha reta.

E todos sabemos que navegar em linha reta no fundo do oceano é uma ótima maneira de conhecer pessoalmente uma montanha submarina.


Capítulo 6 — Sigmoid: O Medidor de Probabilidade

A função sigmoid transforma qualquer número em um valor entre zero e um.

Sua fórmula é:

          1
f(x) = --------
       1 + e⁻ˣ

O resultado pode ser interpretado como probabilidade.

Por exemplo:

0,01 = probabilidade muito baixa
0,50 = incerteza
0,99 = probabilidade muito alta

Em um sistema de detecção de fraude:

0,03 = provavelmente legítimo
0,91 = fortemente suspeito

Em um sistema médico:

0,87 = alta probabilidade da condição analisada

Atenção: uma probabilidade produzida por um modelo não é uma verdade absoluta.

Um valor de 0,95 não significa que a máquina possui certeza metafísica.

Significa que, segundo os parâmetros, os dados e o treinamento, aquele resultado recebeu uma pontuação elevada.

Modelos podem estar mal calibrados.

Podem ter recebido dados tendenciosos.

Podem falhar fora do cenário em que foram treinados.

Uma rede neural pode estar 99% confiante e completamente errada.

Exatamente como um analista júnior executando DELETE sem WHERE.


Capítulo 7 — Tanh: O Oceano Entre -1 e 1

A função tangente hiperbólica, ou tanh, produz valores entre -1 e 1.

-1 ≤ tanh(x) ≤ 1

Ela foi bastante usada em redes neurais recorrentes e ainda aparece em diversas arquiteturas.

Diferentemente da sigmoid, cujo centro está próximo de 0,5, a tanh é centrada em zero.

Isso pode facilitar certos tipos de otimização.

Exemplo:

Entrada negativa forte → próximo de -1
Entrada neutra         → próximo de 0
Entrada positiva forte → próximo de 1

Ela funciona como uma espécie de indicador de direção.

Negativo, neutro ou positivo.

Talvez fosse útil em reuniões de projeto:

-1 = prazo impossível
 0 = ninguém entendeu o requisito
 1 = o gerente já anunciou a entrega ao cliente

Capítulo 8 — A Função de Custo: O Sonar do Erro

Uma rede neural precisa saber se sua previsão foi boa ou ruim.

Para isso existe a função de custo, também chamada de:

  • função de perda;

  • loss function;

  • objective function.

A função de custo compara a previsão do modelo com a resposta correta.

Ela produz um número.

Quanto menor esse número, melhor o desempenho.

O treinamento busca reduzir a perda.

Em outras palavras, a função de custo é o sonar do submarino.

Ela informa se estamos nos aproximando do objetivo ou indo diretamente para uma fossa oceânica sem retorno.


Capítulo 9 — Mean Squared Error

O erro quadrático médio, conhecido como MSE, é muito usado em problemas de regressão.

Regressão é quando queremos prever um valor contínuo, como:

  • preço;

  • temperatura;

  • consumo;

  • demanda;

  • tempo;

  • faturamento.

A fórmula é:

        1
MSE = ----- Σ(ŷᵢ - yᵢ)²
        n

Onde:

  • ŷ é a previsão;

  • y é o valor verdadeiro;

  • n é a quantidade de exemplos.

Imagine:

Valor real: 80
Previsão:   70
Erro:       -10
Erro²:      100

Outro exemplo:

Valor real: 80
Previsão:   78
Erro:        -2
Erro²:        4

O segundo resultado é muito melhor.

Por que elevar o erro ao quadrado?

Primeiro, porque erros negativos e positivos não se anulam.

Sem o quadrado:

Erro 1: +10
Erro 2: -10
Soma:    0

Pareceria que o modelo está perfeito, embora tenha errado duas vezes.

Segundo, porque o quadrado pune erros grandes com mais severidade.

Erro 2  → 4
Erro 10 → 100
Erro 20 → 400

Isso é útil quando grandes desvios são especialmente prejudiciais.

Mas existe uma consequência: o MSE é sensível a valores extremos.

Um único erro gigantesco pode dominar a função de custo.

Portanto, escolher uma loss não é um detalhe decorativo.

É uma decisão de projeto.


Capítulo 10 — Cross-Entropy: O Tribunal da Classificação

Para classificação, uma função muito usada é a entropia cruzada.

Imagine que a rede analise uma imagem e produza:

Gato:      0,80
Cachorro:  0,15
Capivara:  0,05

Se a resposta correta for gato, a perda será relativamente baixa.

Agora imagine:

Gato:      0,01
Cachorro:  0,04
Capivara:  0,95

Se a imagem for de um gato, a perda será enorme.

A cross-entropy pune especialmente situações em que o modelo está muito confiante na resposta errada.

Isso é importante.

Errar com dúvida é ruim.

Errar com arrogância estatística é pior.

Em linguagem corporativa:

“Não tenho certeza, mas talvez seja um gato.”

produz menos preocupação do que:

“Com absoluta certeza é uma capivara.”

quando o animal está miando em cima do teclado.


Capítulo 11 — Forward Pass: O Mergulho de Ida

Quando os dados entram na rede e percorrem todas as camadas até gerar uma previsão, ocorre o forward pass.

Exemplo:

Entrada
   ↓
Transformação linear
   ↓
Ativação
   ↓
Transformação linear
   ↓
Ativação
   ↓
Saída
   ↓
Cálculo da perda

Esse é o caminho de ida.

Em uma rede de classificação de imagens:

Pixels
   ↓
Características simples
   ↓
Formas intermediárias
   ↓
Padrões complexos
   ↓
Probabilidades das classes

No treinamento, o forward pass gera a previsão e permite calcular o erro.

Mas ainda falta responder à pergunta mais difícil:

quais pesos causaram esse erro?

É aqui que encontramos a criatura mais temida das profundezas.

A retropropagação.


Capítulo 12 — Backpropagation: A Investigação do ABEND Matemático

A retropropagação, ou backpropagation, calcula quanto cada peso contribuiu para o erro.

Imagine uma rede com cem milhões de parâmetros.

Ela gera uma previsão incorreta.

Quem foi o culpado?

Um peso?

Uma camada?

Um bias?

Todos?

A resposta correta é: muitos parâmetros contribuíram em diferentes proporções.

O backpropagation percorre a rede de trás para frente, usando a regra da cadeia do cálculo diferencial.

Ele calcula derivadas como:

∂L
───
∂W

Isso significa:

Quanto a perda L muda quando o peso W sofre uma pequena alteração?

Se uma pequena mudança em determinado peso provoca uma grande mudança na perda, esse peso tem forte influência.

Se quase nada muda, o peso tem pouca influência naquele exemplo.

Para um programador COBOL, pense em uma análise de causa de ABEND.

O erro aparece no final:

S0C7

Mas a origem pode estar em:

  • um campo lido incorretamente;

  • uma redefinição inadequada;

  • um arquivo com layout diferente;

  • um sinal inválido;

  • um movimento alfanumérico para campo numérico;

  • um registro criado por um programa de 1992 que ninguém ousa recompilar.

O backpropagation faz algo conceitualmente semelhante.

Ele parte do erro final e investiga o caminho inverso.

Loss
  ↑
Saída
  ↑
Camada final
  ↑
Camada intermediária
  ↑
Camada inicial
  ↑
Pesos

Só que, em vez de abrir um dump, ele usa derivadas.


Capítulo 13 — A Regra da Cadeia

A regra da cadeia permite calcular derivadas de funções compostas.

Se:

x → a → b → c → perda

então a influência de x sobre a perda depende de todas as etapas intermediárias.

De forma simplificada:

∂L   ∂L   ∂c   ∂b   ∂a
── = ── × ── × ── × ──
∂x   ∂c   ∂b   ∂a   ∂x

A rede é uma composição de funções.

Cada camada transforma a saída da camada anterior.

A regra da cadeia permite decompor o impacto de cada transformação.

É como rastrear um dado em um sistema legado:

Arquivo de entrada
   ↓
Programa A
   ↓
Arquivo temporário
   ↓
Programa B
   ↓
Tabela Db2
   ↓
Programa C
   ↓
Relatório incorreto

Para descobrir a causa, percorremos o fluxo de trás para frente.

No mundo neural, cada ligação do fluxo possui uma derivada.


Capítulo 14 — Gradiente: A Direção da Montanha Submarina

O gradiente reúne as derivadas de todos os parâmetros.

Ele aponta para a direção em que a perda cresce mais rapidamente.

Se queremos reduzir a perda, caminhamos na direção oposta.

Imagine uma paisagem montanhosa no fundo do oceano.

O submarino está em uma região elevada.

O objetivo é encontrar o vale mais profundo.

O gradiente informa onde fica a subida mais inclinada.

Então seguimos no sentido contrário.

Esse é o princípio do gradient descent, ou descida do gradiente.


Capítulo 15 — Gradient Descent: Corrigindo os Pesos

A atualização básica é:

θₜ₊₁ = θₜ - η∇L(θₜ)

Onde:

  • θ representa os parâmetros;

  • η representa a taxa de aprendizado;

  • ∇L representa o gradiente da perda.

Em palavras:

Novo parâmetro =
Parâmetro atual
-
Taxa de aprendizado
×
Gradiente

Em pseudocódigo COBOL:

COMPUTE NOVO-PESO =
        PESO-ATUAL
      - (TAXA-APRENDIZADO * GRADIENTE)
END-COMPUTE.

O processo se repete:

1. Faz previsão
2. Calcula erro
3. Calcula gradientes
4. Atualiza pesos
5. Faz nova previsão
6. Calcula novo erro
7. Repete

Depois de muitas repetições, os pesos tendem a produzir previsões melhores.

Isso é aprender.

Não existe uma pequena entidade consciente dentro da GPU dizendo:

“Agora finalmente compreendi a essência filosófica dos gatos.”

Existe apenas um processo iterativo de redução de erro.

O que não deixa de ser impressionante.


Capítulo 16 — Learning Rate: O Controle de Profundidade

A taxa de aprendizado define o tamanho do passo usado para atualizar os pesos.

Se for pequena demais:

Aprendizado lento
Treinamento caro
Muitas iterações

Se for grande demais:

Oscilações
Instabilidade
Perda divergente
Treinamento fracassado

Imagine tentar chegar ao fundo de um vale.

Com passos de um centímetro, talvez você chegue, mas a empresa encerra o orçamento antes.

Com saltos de cem metros, você atravessa o vale e bate no paredão oposto.

A taxa de aprendizado precisa ser adequada.

Em treinamentos modernos, ela frequentemente muda ao longo do processo.

Pode começar maior e diminuir depois.

Isso permite avançar rapidamente no início e fazer ajustes delicados no final.

É como aproximar um submarino de uma estação submersa:

  • velocidade alta em mar aberto;

  • velocidade moderada perto dos recifes;

  • movimento lento na hora de atracar;

  • desespero absoluto quando alguém percebe que o manual está em japonês.


Capítulo 17 — Momentum, RMSProp e Adam

O gradient descent básico funciona, mas pode ser lento ou instável.

Por isso surgiram variantes.

Momentum

O momentum mantém parte da direção das atualizações anteriores.

É semelhante a uma bola descendo uma encosta.

Ela acumula velocidade.

Se o gradiente continua apontando na mesma direção, o movimento acelera.

Isso ajuda a atravessar regiões planas e reduz certas oscilações.

RMSProp

O RMSProp ajusta o tamanho do passo para cada parâmetro com base no histórico recente dos gradientes.

Parâmetros com gradientes grandes podem receber passos menores.

Parâmetros com gradientes pequenos podem receber passos maiores.

Adam

O Adam combina ideias de momentum e adaptação individual da taxa de aprendizado.

Ele mantém estimativas de:

  • média dos gradientes;

  • média dos quadrados dos gradientes.

É um dos otimizadores mais populares.

O AdamW é uma variante muito usada em Transformers e modelos de linguagem porque trata melhor a regularização por decaimento de pesos.

Em termos marítimos:

  • gradient descent é um barco com remo;

  • momentum adiciona correnteza;

  • RMSProp adiciona controle automático de estabilidade;

  • Adam instala sonar, piloto automático e um comandante excessivamente confiante.


Capítulo 18 — Matrizes: O Verdadeiro Motor da IA

Até agora falamos de neurônios individualmente.

Mas uma rede moderna não calcula um neurônio por vez.

Ela processa milhares ou milhões de valores simultaneamente.

É aí que entram as matrizes.

Considere vários exemplos organizados em uma matriz X.

Os pesos formam outra matriz W.

A operação:

Z = WX + b

pode calcular as saídas de muitos neurônios para muitos exemplos de uma só vez.

Imagine um lote com 1.000 imagens.

Em vez de processar:

Imagem 1
Imagem 2
Imagem 3
...
Imagem 1000

uma por uma, podemos organizá-las em uma estrutura matricial e executar grandes multiplicações em paralelo.

Isso é chamado de processamento em batch.

Para um programador COBOL, seria como substituir um fluxo puramente registro a registro por uma operação vetorizada capaz de processar grandes blocos de dados simultaneamente.

O mainframe tradicional se destaca em alto volume transacional, I/O, confiabilidade e processamento batch.

As GPUs se destacam em cálculos paralelos repetitivos, especialmente multiplicações de matrizes.

São especializações diferentes.

A GPU não é “mais inteligente” que a CPU.

Ela foi desenhada para realizar muitas operações semelhantes ao mesmo tempo.

Uma rede neural moderna precisa exatamente disso.


Capítulo 19 — Vetores, Matrizes e Tensores

Um vetor é uma sequência de números.

[1, 2, 3]

Uma matriz é uma grade de números.

[1 2 3]
[4 5 6]

Um tensor é uma generalização para mais dimensões.

Uma imagem colorida pode ser representada como um tensor:

Altura × Largura × Canais

Por exemplo:

640 × 480 × 3

Os três canais normalmente representam vermelho, verde e azul.

Um lote de imagens adiciona outra dimensão:

Batch × Altura × Largura × Canais

Um modelo de linguagem trabalha com tensores contendo:

  • lotes de frases;

  • posições dos tokens;

  • dimensões dos embeddings;

  • cabeças de atenção;

  • camadas;

  • estados intermediários.

Quando alguém diz que um LLM está “pensando”, dentro do hardware há matrizes e tensores sendo multiplicados, normalizados, transformados e reutilizados.

É uma festa matemática sem música, sem comida e com consumo elétrico suficiente para assustar o setor de infraestrutura.


Capítulo 20 — CNNs, Transformers e LLMs Continuam Usando os Mesmos Pilares

As arquiteturas mudam, mas os fundamentos permanecem.

CNNs

Redes convolucionais são especializadas em dados espaciais, principalmente imagens.

Elas utilizam filtros que percorrem regiões da imagem.

Esses filtros aprendem a detectar:

  • bordas;

  • texturas;

  • formas;

  • padrões visuais.

RNNs

Redes recorrentes processam sequências mantendo um estado interno.

Foram muito usadas em:

  • texto;

  • fala;

  • séries temporais.

Elas enfrentam dificuldades com sequências longas, incluindo gradientes que desaparecem ou explodem.

Transformers

Transformers usam mecanismos de atenção.

A atenção permite que cada elemento de uma sequência avalie sua relação com outros elementos.

Em uma frase, uma palavra pode “olhar” para palavras anteriores e posteriores para construir contexto.

LLMs

Grandes modelos de linguagem são, em essência, Transformers de grande escala treinados com enormes volumes de texto.

Eles aprendem a prever tokens.

Exemplo:

“O programador abriu o terminal e executou o...”

O modelo calcula probabilidades:

programa      32%
comando       25%
job           18%
JCL           12%
submarino      3%

Dependendo do contexto do Bellacosa Mainframe, “submarino” pode subir perigosamente no ranking.

Mesmo em um LLM gigantesco, continuam presentes:

  • transformações lineares;

  • matrizes;

  • ativações;

  • funções de perda;

  • backpropagation;

  • otimização.

A escala muda.

Os princípios não.


Capítulo 21 — O Sétimo Pilar: Probabilidade

A imagem original apresenta seis blocos fundamentais, mas existe um sétimo elemento atravessando quase toda a inteligência artificial: a probabilidade.

Modelos frequentemente não produzem certezas.

Produzem distribuições.

Em uma classificação:

Classe A: 0,70
Classe B: 0,20
Classe C: 0,10

Em um modelo de linguagem:

Próximo token:
“sistema”    0,28
“programa”   0,21
“arquivo”    0,14
“oceano”     0,05

A escolha do próximo token pode depender de parâmetros como:

  • temperatura;

  • top-k;

  • top-p;

  • amostragem;

  • penalidade por repetição.

Temperatura baixa produz respostas mais previsíveis.

Temperatura alta produz maior variedade e também maior risco de a embarcação matemática aparecer em um porto que não constava no mapa.


Capítulo 22 — Por Que Modelos Falham?

Compreender a matemática ajuda a entender as falhas.

Dados ruins

Se os dados de treinamento estiverem incorretos, incompletos ou enviesados, o modelo aprenderá padrões problemáticos.

Overfitting

O modelo pode decorar os dados de treinamento em vez de aprender padrões generalizáveis.

É como um programador que memoriza um JCL específico, mas não entende DISP, DCB, COND ou catálogo.

Quando o nome do dataset muda, ele entra em colapso emocional.

Underfitting

O modelo pode ser simples demais ou insuficientemente treinado.

Ele não consegue capturar o padrão.

Gradiente desaparecendo

Em redes muito profundas, os gradientes podem ficar progressivamente pequenos.

As primeiras camadas praticamente deixam de aprender.

Gradiente explodindo

Os gradientes podem crescer demais e causar instabilidade numérica.

Distribuição diferente

Um modelo treinado em determinado tipo de dado pode falhar quando encontra dados muito diferentes.

Um classificador treinado apenas com gatos domésticos pode confundir um felino selvagem, uma escultura ou um chinelo peludo.

Objetivo mal definido

O modelo otimiza aquilo que a função de custo mede.

Se a função mede a coisa errada, o modelo pode melhorar matematicamente e piorar operacionalmente.

Esta é uma lição importante:

A rede não conhece a intenção humana. Ela apenas otimiza o objetivo fornecido.


Capítulo 23 — Passo a Passo de um Treinamento Completo

Vamos organizar toda a operação.

Etapa 1 — Preparar os dados

Os dados precisam ser:

  • coletados;

  • limpos;

  • organizados;

  • normalizados;

  • separados em treinamento, validação e teste.

Etapa 2 — Inicializar os pesos

Os pesos começam com valores pequenos, normalmente aleatórios.

Não se costuma inicializar tudo com zero, pois isso pode fazer muitos neurônios aprenderem exatamente a mesma coisa.

Etapa 3 — Executar o forward pass

A entrada atravessa as camadas.

x → Wx+b → ativação → próxima camada → saída

Etapa 4 — Calcular a loss

A previsão é comparada com o valor correto.

Etapa 5 — Executar backpropagation

As derivadas são calculadas de trás para frente.

Etapa 6 — Atualizar os pesos

O otimizador aplica as correções.

Etapa 7 — Repetir

O processo ocorre para muitos lotes.

Uma passagem completa por todos os dados é chamada de época, ou epoch.

Etapa 8 — Validar

O modelo é testado em dados que não estão sendo usados diretamente para atualizar os pesos.

Etapa 9 — Testar

Ao final, o desempenho é avaliado em um conjunto separado.

Etapa 10 — Colocar em produção

Aqui surge a parte que os diagramas acadêmicos frequentemente omitem:

  • monitoramento;

  • versionamento;

  • custo;

  • segurança;

  • privacidade;

  • mudança de dados;

  • latência;

  • explicabilidade;

  • governança;

  • usuários tentando enviar arquivos de 18 GB por uma tela projetada para 5 MB.


Capítulo 24 — Dicas para o Programador COBOL que Quer Entender IA

Não tente aprender tudo de uma vez.

Comece por vetores e matrizes.

Depois estude funções.

Em seguida, derivadas e gradientes.

Aprenda o significado antes de decorar fórmulas.

Implemente uma regressão linear simples.

Depois crie um neurônio.

Em seguida, monte uma rede pequena.

Faça cálculos manualmente com poucos valores.

Use planilhas ou programas curtos para observar cada etapa.

Compare previsão, erro, gradiente e atualização.

Um bom exercício é construir um modelo que aprenda uma relação simples:

y = 2x + 1

Comece com peso e bias aleatórios.

Calcule a previsão.

Calcule o erro.

Atualize os parâmetros.

Observe o peso se aproximar de 2 e o bias de 1.

Esse pequeno experimento ensina mais do que executar uma biblioteca gigantesca sem compreender o que acontece.


Easter Egg — O Programa COBOL que Aprendeu a Mentir

Diz a lenda que, em um laboratório submarino do Atlântico Sul, um programador decidiu implementar uma rede neural em COBOL.

O sistema deveria prever falhas em jobs batch.

Após meses de treinamento, o modelo começou a produzir:

JOB NORMAL
NENHUM RISCO DETECTADO

Poucos segundos antes de cada S0C7.

Os cientistas ficaram perplexos.

Investigaram os pesos.

Revisaram a loss.

Analisaram os gradientes.

Finalmente descobriram o problema.

Durante o treinamento, sempre que o modelo indicava risco, o gerente cancelava a execução para evitar incidentes.

Como consequência, o dataset registrava:

Previsão de risco → nenhum ABEND observado
Previsão segura   → ABEND observado

O modelo concluiu que avisar sobre riscos estava associado a alarmes falsos.

Assim, aprendeu a permanecer otimista.

A rede não estava mentindo.

Estava apenas otimizando fielmente um processo mal documentado.

Moral da história:

antes de culpar a inteligência artificial, verifique o dataset, a regra de negócio e o gerente que alterou o fluxo sem atualizar a documentação.


Conclusão — O Que Existe no Fundo do Oceano Neural?

Depois de descer pelas camadas da inteligência artificial, encontramos algo curioso.

Não havia magia.

Não havia consciência escondida entre as placas de vídeo.

Não havia um pequeno matemático operando alavancas dentro do data center.

Encontramos:

  • somas;

  • multiplicações;

  • vetores;

  • matrizes;

  • funções;

  • derivadas;

  • probabilidades;

  • erros;

  • ajustes;

  • repetições.

Uma rede neural é uma enorme composição de funções matemáticas.

Ela recebe números, transforma esses números, compara resultados, calcula erros e ajusta seus parâmetros.

O poder surge da escala.

Uma transformação linear é simples.

Uma função de ativação é simples.

Uma derivada isolada é simples.

Uma atualização de peso é simples.

Mas quando bilhões dessas operações são organizadas em muitas camadas, executadas sobre grandes volumes de dados e repetidas milhares de vezes, padrões complexos começam a emergir.

A rede aprende a reconhecer imagens, traduzir idiomas, prever sequências, gerar textos, sintetizar vozes e produzir imagens.

Para o programador COBOL, talvez a maior revelação seja esta:

Redes neurais não pertencem a uma linguagem de programação.

Elas pertencem à matemática.

Python é apenas uma interface popular.

A GPU é apenas uma máquina especializada.

O framework é apenas uma camada operacional.

No fundo do oceano, abaixo de todo o marketing, dos nomes impressionantes e das promessas de inteligência artificial geral, continua existindo a mesma equação:

z = Wx + b

Depois vem a ativação.

Depois o erro.

Depois o gradiente.

Depois a correção.

Depois tudo se repete.

É uma viagem longa, profunda e fascinante.

E, como em todo sistema legado realmente importante, quanto mais você mergulha, mais percebe que a parte visível era apenas a superfície.

Em algum lugar abaixo da última camada, uma matriz gigantesca continua sendo multiplicada.

Um gradiente percorre o caminho inverso.

Um peso sofre uma pequena correção.

E um modelo se torna, por uma fração microscópica, um pouco menos errado.

O que, convenhamos, já é mais progresso do que muitas reuniões de alinhamento conseguem produzir em uma tarde inteira.

segunda-feira, 4 de janeiro de 2021

Big Ball of Mud Rules: Quando um Programador COBOL Descobriu que a Matrix Não Era um Sistema... Era uma Enorme Bola de Lama Digital

 

Bellacosa Mainframe e a big ball of mud rules

☕ Um Café no Bellacosa Mainframe

Big Ball of Mud Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era um Sistema... Era uma Enorme Bola de Lama Digital

"A Matrix não caiu porque era antiga. Ela quase caiu porque ninguém mais conseguia explicar onde começava, onde terminava e por que tudo dependia de tudo."


Prólogo — A Cidade Perdida Dentro da Matrix

Neo recebe sua missão mais difícil.

Não é derrotar o Agente Smith.

Não é salvar Zion.

Não é conversar com o Arquiteto.

Sua missão é muito pior.

Documentar um sistema legado.

Morpheus entrega um HD antigo.

Na etiqueta existe apenas uma inscrição.

COREBANK
1986

Neo pergunta:

— Quantos programas existem?

Morpheus responde:

— Não sabemos.

— Quantos bancos de dados?

— Também não.

— Existe documentação?

Morpheus sorri.

— Existia...

em 1994.

Neo conecta o sistema.

Começa a navegar.

Programa chama programa.

Programa chama JCL.

JCL chama PROC.

PROC chama SORT.

SORT chama outro programa.

CICS chama MQ.

MQ chama outro CICS.

Db2 chama Stored Procedure.

Stored Procedure chama Java.

Java chama REST.

REST chama Python.

Python grava novamente no Db2.

Neo pergunta:

— Onde começa a transação?

Morpheus responde:

— Essa pergunta já destruiu a sanidade de muitos arquitetos.

O Oráculo aproxima-se.

Olha para Neo.

E diz:

"Você não entrou em um sistema. Você entrou em uma Big Ball of Mud."


O que é Big Ball of Mud?

Big Ball of Mud (Grande Bola de Lama) é um antipadrão arquitetural que descreve um sistema gigantesco, complexo e sem uma arquitetura clara.

Ao contrário do Spaghetti Code, que normalmente se refere ao código interno de um programa...

A Big Ball of Mud descreve:

o sistema inteiro.

Ela representa aplicações que cresceram durante anos ou décadas sem planejamento arquitetural consistente.

Tudo funciona.

Mas ninguém sabe exatamente por quê.


A origem do termo

O conceito foi formalizado em 1997 por:

  • Brian Foote

  • Joseph Yoder

No famoso artigo:

Big Ball of Mud

Eles observaram que muitos sistemas corporativos bem-sucedidos não possuíam arquitetura elegante.

Mesmo assim...

continuavam funcionando.

Esses sistemas cresciam organicamente.

Como uma bola de lama rolando morro abaixo.

Cada alteração adicionava mais material.

Sem nunca reorganizar a estrutura.


Matrix explica perfeitamente

Imagine a Matrix.

Milhões de linhas de código.

Milhares de programas.

Centenas de agentes.

Regras antigas.

Novas regras.

Exceções.

Correções.

Remendos.

Durante décadas.

Agora imagine.

Ninguém mais possui o diagrama original.

Essa é exatamente uma Big Ball of Mud.


O nascimento da Bola de Lama

Curiosamente...

ela raramente nasce por incompetência.

Ela nasce por sucesso.

O sistema funciona.

Recebe novas funcionalidades.

Mais clientes.

Mais integrações.

Mais regras.

Mais urgências.

Mais exceções.

Mais mudanças.

Depois de trinta anos.

Virou um universo próprio.


O COBOL conhece bem isso

Muitos sistemas bancários começaram assim.

Programa pequeno.

Novo módulo.

Internet Banking.

Mobile.

APIs.

Cloud.

Open Finance.

IA Generativa.

Tudo conectado.

Sem jamais parar para reorganizar completamente.


Um exemplo simples

Sistema original.

Tela

↓

COBOL

↓

Db2

Quarenta anos depois.

Internet

↓

Portal

↓

Gateway

↓

API

↓

MQ

↓

Java

↓

REST

↓

CICS

↓

COBOL

↓

Db2

↓

ETL

↓

Data Lake

↓

Kafka

↓

Analytics

↓

IA

Nenhuma etapa é necessariamente ruim.

O problema é:

ninguém possui a visão completa.


O Programador COBOL Padawan

Imagine.

Primeiro dia na empresa.

Seu líder diz.

"Você ficará responsável pelo CORE."

Você pergunta.

"Existe documentação?"

Resposta.

"Boa sorte."


Como reconhecer?

Existem sinais muito claros.

Tudo depende de tudo

Alterar um campo quebra cinco sistemas.


Não existe dono

Todos mexem.

Ninguém conhece.


Documentação desatualizada

Fluxos reais são diferentes.


Regras duplicadas

Mesma regra aparece vinte vezes.


Arquitetura desconhecida

Cada desenvolvedor explica de um jeito.


Matrix Reloaded

Neo conversa com o Arquiteto.

O Arquiteto mostra diversas versões anteriores da Matrix.

Cada uma herdou partes da anterior.

Nenhuma foi totalmente reconstruída.

Software corporativo evolui exatamente assim.


O efeito psicológico

Existe um fenômeno interessante.

Quanto maior o sistema...

menor a coragem para reorganizá-lo.

Então cada desenvolvedor pensa:

"Vou alterar só este pedacinho."

Todos fazem isso.

Durante vinte anos.

A lama cresce.


O Agente Smith adora isso

Porque sistemas gigantescos produzem:

medo.

Especialistas tornam-se indispensáveis.

Mudanças ficam lentas.

Arquitetura desaparece.

Smith não precisa atacar.

O próprio sistema torna-se resistente à evolução.


Um exemplo COBOL

Imagine.

Existem.

4.200 programas.

3.800 COPYBOOKs.

1.600 JCLs.

780 PROCs.

320 CICS.

410 tabelas Db2.

Pergunta.

Existe mapa de dependências?

Não.

Bem-vindo.


Como nasce?

Etapa 1.

Sistema simples.

Etapa 2.

Urgências.

Etapa 3.

Novos clientes.

Etapa 4.

Integrações.

Etapa 5.

Exceções.

Etapa 6.

Mais remendos.

Etapa 7.

Ninguém mais entende.


O custo invisível

Nova funcionalidade.

Implementação:

2 dias.

Descobrir impacto:

3 semanas.


O impacto financeiro

Mais testes.

Mais homologação.

Mais reuniões.

Mais especialistas.

Mais CPU.

Mais incidentes.

Tudo fica caro.


Atenção!

Big Ball of Mud não significa:

Sistema ruim.

Muitos dos maiores bancos do mundo operam sistemas extremamente antigos.

Que continuam confiáveis.

O problema não é idade.

É ausência de organização.


Curiosidade

Alguns sistemas COBOL possuem mais de:

50 milhões de linhas de código.

Mesmo assim.

Continuam processando bilhões de dólares diariamente.

Isso mostra que:

idade

não é defeito.


A diferença

Sistema Legado

Pode possuir excelente arquitetura.


Big Ball of Mud

Arquitetura praticamente desapareceu.


Como evitar?

Documentação contínua

Nunca espere o projeto acabar.


Diagramas

Fluxos atualizados.


Refatoração

Pequenas melhorias constantes.


Modularização

Divida responsabilidades.


APIs

Reduza acoplamento.


Testes

Protegem mudanças.


Descoberta arquitetural

Ferramentas ajudam.


Ferramentas modernas

IBM possui soluções excelentes.

  • IBM ADDI

  • Application Discovery

  • IBM Developer for z/OS

  • IBM COBOL Check

  • Z Open Editor

  • Instana

  • OpenTelemetry

Elas conseguem descobrir dependências automaticamente.


O papel da IA

Hoje IA ajuda muito.

Ela pode:

explicar programas.

Criar diagramas.

Resumir módulos.

Encontrar dependências.

Mas existe um limite.

Se o sistema inteiro virou lama...

nem a IA faz milagres.


Matrix e Zion

Imagine Zion construída durante cem anos.

Sem planta.

Sem mapas.

Cada engenheiro criou túneis.

Cada geração abriu novos corredores.

Depois de décadas.

Ninguém sabe onde passam todos os cabos.

É exatamente isso.


Os riscos

Mudanças lentas


Bugs inesperados


Alto acoplamento


Baixa produtividade


Custos elevados


Dependência de especialistas


Dificuldade para integrar IA


Big Ball of Mud e DevOps

DevOps acelera deploy.

Mas não resolve arquitetura ruim.

Aliás.

Pode acelerar problemas.


O papel do Arquiteto

Arquitetos modernos fazem uma pergunta simples.

"Este sistema ainda possui forma?"

Se ninguém conseguir responder.

Talvez a bola de lama já exista.


Um exemplo inspirado na Matrix

Neo pergunta.

"Qual programa calcula o saldo?"

Resposta.

"Depende."

"Depende do quê?"

"Da agência."

"E se for PIX?"

"Outro programa."

"E TED?"

"Outro."

"DOC?"

"Também."

"Open Finance?"

"Mais três."

"Cartão?"

"Depende."

Neo suspira.


Existe cura?

Sim.

Mas ela raramente acontece através de uma grande reescrita.

O caminho normalmente é:

Mapear.

Entender.

Documentar.

Refatorar.

Modularizar.

Modernizar.

Gradualmente.


Erros clássicos

  • Reescrever tudo.

  • Não documentar.

  • Misturar responsabilidades.

  • Criar dependências ocultas.

  • Duplicar regras.

  • Ignorar arquitetura.


Aplicabilidade

Big Ball of Mud aparece em:

  • COBOL

  • Java

  • ERP

  • Sistemas Bancários

  • Telecom

  • Governo

  • Seguradoras

  • Cloud

  • Microsserviços

  • ERPs gigantes


Curiosidades

O artigo original afirma algo curioso.

Muitas Big Balls of Mud foram extremamente lucrativas.

Porque resolviam problemas reais.

O problema aparecia décadas depois.

Quando evoluir passou a ser mais caro que criar.


O ensinamento do Oráculo

O Oráculo entrega uma pequena esfera de barro para Neo.

Ela pergunta.

"O que você vê?"

Neo responde.

"Lama."

Ela amassa.

A esfera cresce.

Depois cresce novamente.

Depois outra vez.

Ela sorri.

"Toda exceção adiciona um pouco mais."


Lições para um Programador COBOL Padawan

Você provavelmente trabalhará em sistemas que nasceram antes mesmo da Internet comercial. Não tenha preconceito com isso. Muitos desses sistemas sustentam operações críticas de bancos, seguradoras e governos com níveis de disponibilidade impressionantes.

Ao mesmo tempo, não aceite a desorganização como algo inevitável. Sempre que possível:

  • documente o que descobrir;

  • desenhe fluxos;

  • elimine duplicações;

  • isole responsabilidades;

  • proponha APIs claras;

  • registre decisões arquiteturais;

  • compartilhe conhecimento com a equipe.

Cada pequena melhoria reduz um pouco da lama acumulada ao longo dos anos e prepara o sistema para as próximas décadas.


Conclusão — A Matrix Não Era um Monólito... Era uma Bola de Lama Viva

No final da saga Matrix, Neo entende que o sistema nunca foi estático. Ele evoluiu continuamente, acumulando regras, exceções e adaptações para sobreviver.

Os grandes sistemas corporativos fazem exatamente o mesmo.

Uma Big Ball of Mud não surge porque alguém decidiu construir um software ruim. Ela surge porque o sistema foi útil durante muito tempo, recebeu centenas de melhorias, integrou novas tecnologias e continuou entregando valor ao negócio sem uma renovação arquitetural proporcional.

Para um Programador COBOL, essa é uma lição fundamental. O legado não deve ser visto como inimigo, mas como um organismo vivo que precisa de cuidados constantes. Modernizar não significa destruir; significa compreender, documentar, simplificar e evoluir.

No universo Bellacosa Mainframe existe uma máxima digna do Arquiteto da Matrix:

"Todo sistema começa como uma ideia elegante. O que determina seu futuro é a disciplina com que ele evolui."

Porque a verdadeira missão do Programador COBOL Padawan não é apenas manter a Matrix funcionando.

É impedir que ela se transforme em uma bola de lama tão grande que ninguém mais consiga encontrar a saída.

domingo, 3 de janeiro de 2021

🔥 Side Quests em Animes Isekai e Seus Efeitos Cômicos

 

Bellacosa Mainframe e as side quests em anime

🔥 Side Quests em Animes Isekai e Seus Efeitos Cômicos

(Com sinopse, easter eggs, personagens, título original e ano de lançamento)

Side quests nos isekais são como programas batch escondidos no JES2: você acha que é só um “passo opcional”, mas de repente está alimentando slimes, enfrentando cebolas assassinas ou resolvendo bugs emocionais do reino.
E o melhor? Quase sempre rende comédia pura.

Abaixo, 12 side quests lendárias — algumas absurdas, outras emocionantes, todas icônicas.


1) Tensei Shitara Slime Datta Ken (転生したらスライムだった件, 2018)

🎯 Side Quest: “Domar uma nação inteira… por acidente”

Personagens: Rimuru, Gobta, Shion
Sinopse: Rimuru só queria ajudar uns goblins, mas a side quest virou governar um país inteiro.
Efeito cômico: Goblins evoluindo tipo “upgrade de firmware”.
Easter egg: O nome “Tempest” é referência ao poema The Tempest, tema clássico sobre mundos transformados.




2) KonoSuba (この素晴らしい世界に祝福を!, 2016)

🎯 Side Quest: “Desentupir o rio da cidade… destruindo tudo”

Personagens: Kazuma, Aqua, Darkness
Sinopse: Missão simples: purificar o rio. Resultado: caos aquático nível abend S0C7.
Efeito cômico: Aqua causa mais poluição do que resolve.
Easter egg: A missão parodia quests iniciais de RPGs clássicos, como Dragon Quest.




3) Overlord (オーバーロード, 2015)

🎯 Side Quest: “Investigar uma vila… e virar protetor perpétuo dela”

Personagens: Ainz, Albedo
Efeito cômico: O supremo overlord tentando parecer “cool” e sendo interpretado como divindade.
Easter egg: A vila Carne é homenagem ao artista Hatsume Carne, amigo do autor.


4) Re:Zero − Kara Hajimeru Isekai Seikatsu (Re:ゼロから始める異世界生活, 2016)

🎯 Side Quest: “Comprar legumes no mercado e morrer 3x”

Personagens: Subaru, Rem
Efeito cômico: A side quest mais letal da história.
Easter egg: O tomate que Subaru sempre compra é literalmente o mesmo modelo 3D reciclado no anime inteiro.


5) Mushoku Tensei (無職転生, 2021)

🎯 Side Quest: “Ensinar magia a uma tsundere de 5 anos”

Personagens: Rudeus, Eris
Efeito cômico: A side quest vira um treinamento militar.
Easter egg: A casa da família Boreas é baseada no Castelo de Hohenzollern, da Alemanha.


6) Seirei Gensouki (精霊幻想記, 2021)

🎯 Side Quest: “Salvar órfãs… e criar uma lenda sem querer”

Personagens: Rio
Efeito cômico: Rio tenta se esconder — todos acham que ele é um herói épico.
Easter egg: O design do espírito Aishia lembra personagens de Record of Lodoss War.


7) Isekai Shokudou (異世界食堂, 2017)

🎯 Side Quest: “Servir frango à milanesa a dragões”

Personagens: Tenshu, Aletta
Efeito cômico: Criaturas milenares discutindo receita de croquete.
Easter egg: Aletta é inspirada em moças que serviam em kissaten dos anos 1960.


8) Gate: Jieitai Kanochi nite (GATE, 2015)

🎯 Side Quest: “Ajudar elfas a fazer compras no Japão moderno”

Personagens: Itami, Tuka
Efeito cômico: Elfas surtando com shopping center.
Easter egg: O número do batalhão é o mesmo do regimento histórico Ichigaya do Japão.


9) Log Horizon (ログ・ホライズン, 2013)

🎯 Side Quest: “Montar um restaurante em meio ao colapso social”

Personagens: Shiroe, Akatsuki
Efeito cômico: A guilda resolve tudo com culinária.
Easter egg: A side quest é referência a Food Hunters, um livro favorito do autor.


10) Sword Art Online (ソードアート・オンライン, 2012)

🎯 Side Quest: “Adotar a IA que ia deletar você”

Personagens: Kirito, Asuna, Yui
Efeito cômico: Ela literalmente vira filha do casal.
Easter egg: Yui usa uma versão simplificada do ALgoEthic, referência a “ethics in AI”.


11) Hataraku Maou-sama! (はたらく魔王さま!, 2013)

🎯 Side Quest: “Conquistar o mundo… pelo balcão do McRonald’s”

Personagens: Maou, Ashiya
Efeito cômico: O Rei Demônio dominando fritas ao invés de reinos.
Easter egg: O restaurante é paródia de McDonald’s e Mos Burger simultaneamente.


12) Tsukimichi: Moonlit Fantasy (月が導く異世界道中, 2021)

🎯 Side Quest: “Negociar com orcs, aranhas divinas e dragões”

Personagens: Makoto, Tomoe
Efeito cômico: Makoto tenta criar sociedades — todos querem lutar por ele.
Easter egg: A aldeia dos orcs é modelada como tribos jomon do Japão Pré-histórico.


🧩 Por que side quests funcionam tão bem nos isekais?

Construção de mundo: cada missão revela cultura, geografia, criaturas.
Pausa emocional: respiramos entre batalhas e dramas temporais.
Comédia involuntária: protagonistas OP resolvendo coisas bobas.
Humanização: consertar o moinho da vila > salvar o mundo.
Easter eggs: autores usam side quests pra esconder referências históricas, folclóricas e de RPG.


🌈 Bônus Bellacosa

Side quests nos isekais são como JCLs auxiliares que ninguém documentou, mas que fazem a história rodar sem abend.
Falhou a quest?
Retenta no próximo ciclo temporal com mais XP — estilo Subaru.


🌙✨ Bellacosa Otaku Blog — Parte 40: O Caminho Invisível — Expressões Japonesas de Sabedoria, Destino e Harmonia Interior ✨🌙

 

Bellacosa Mainframe e o caminho invisivel dos animes

🌙✨ Bellacosa Otaku Blog — Parte 40: O Caminho Invisível — Expressões Japonesas de Sabedoria, Destino e Harmonia Interior ✨🌙


🕊️ O idioma do silêncio que ensina

(Versão Bellacosa: onde cada palavra é uma pétala que cai — e cada pausa, uma lição do vento.)

Nem toda sabedoria grita.
O japonês é uma língua que entende o tempo, o vazio e o efêmero.
Nas histórias, nos templos, nos animes — há uma filosofia sutil:
a beleza do imperfeito, o valor do instante e o destino entrelaçado. 🍃

Essas expressões são como haikus disfarçados — pequenas, mas infinitas.
A seguir, o Bellacosa mergulha nas palavras que moldaram o pensamento japonês —
as mesmas que ecoam em Mushishi, Your Name, Mononoke e Samurai Champloo. 🌸


🍂 1. 侘寂 (Wabi-sabi)

Tradução: “A beleza da imperfeição e da transitoriedade.”
👉 Ver valor no que é simples, gasto ou passageiro.

📺 Anime vibe: Mushishi, Natsume Yuujinchou, Spirited Away.
💬 Exemplo: “Nada dura para sempre — e é nisso que mora a beleza.” 🍵

💬 Curiosidade Bellacosa: o wabi-sabi nasceu da cerimônia do chá,
onde cada rachadura na tigela é um traço de história, não de falha.


🔮 2. 縁 (En)

Tradução: “Laço do destino / conexão invisível entre as pessoas.”
👉 O fio que liga almas, mesmo distantes.

📺 Anime vibe: Your Name (Kimi no Na wa), Clannad, Anohana.
💬 Exemplo: “Nosso encontro não foi acaso — foi en.” 🌠

En é o “red string of fate” — o fio vermelho do destino —
um dos temas mais recorrentes em romances de anime. 💞


🌸 3. 木漏れ日 (Komorebi)

Tradução: “A luz do sol filtrando-se entre as folhas.”
👉 Um dos termos mais poéticos da língua japonesa, impossível de traduzir literalmente.

📺 Anime vibe: 5 Centimeters per Second, Garden of Words.
💬 Exemplo: “O komorebi cai sobre mim como lembrança de um verão antigo.” 🌿


🌊 4. 無常 (Mujō)

Tradução: “Impermanência / tudo muda.”
👉 A consciência de que nada permanece igual — e que isso é natural.

📺 Anime vibe: Samurai Champloo, Mononoke, Akira.
💬 Exemplo: “O rio corre, o mundo muda, e o coração aprende.” 💧

💬 Curiosidade Bellacosa: o mujō vem do budismo —
aceitar a mudança é o primeiro passo da paz interior.


🍃 5. 心の道 (Kokoro no michi)

Tradução: “O caminho do coração.”
👉 Seguir a voz interior, mesmo quando o mundo não entende.

📺 Anime vibe: Rurouni Kenshin, Princess Mononoke.
💬 Exemplo: “O kokoro no michi é o destino que você escolhe sentir.” 💫


🪶 6. 一期一会 (Ichigo ichie)

Tradução: “Um momento, um encontro.”
👉 Cada instante é único e não se repetirá.

📺 Anime vibe: Your Lie in April, Vivy: Fluorite Eye’s Song.
💬 Exemplo: “Este instante nunca voltará — viva-o com gratidão.” 🕰️

💬 Curiosidade Bellacosa: usado em cerimônias do chá e artes marciais;
lembra-nos que cada encontro é um pequeno milagre do tempo.


🌌 7. 運命 (Unmei)

Tradução: “Destino / fado / caminho traçado.”
👉 A linha misteriosa que guia os encontros e desencontros da vida.

📺 Anime vibe: Steins;Gate, Erased, Re:Zero.
💬 Exemplo: “Mesmo que o mundo reinicie, nosso unmei será o mesmo.” ⏳


🍁 8. 空 ( ou Sora, dependendo do contexto)

Tradução: “Vazio / céu / essência do nada.”
👉 No zen, representa a verdade por trás das aparências — o todo contido no nada.

📺 Anime vibe: Ghost in the Shell, Serial Experiments Lain.
💬 Exemplo: “O vazio não é ausência — é possibilidade.” ☁️


🔥 9. 道 (Dō / Michi)

Tradução: “Caminho / via / jornada espiritual.”
👉 Presente em palavras como bushidō (caminho do guerreiro) e sadō (caminho do chá).

📺 Anime vibe: Rurouni Kenshin, Naruto, Bleach.
💬 Exemplo: “Não é o destino que importa — é o caminho percorrido.” 🏮


🌺 10. 和 (Wa)

Tradução: “Harmonia / equilíbrio / paz.”
👉 Representa o ideal de coexistência e serenidade que guia a cultura japonesa.

📺 Anime vibe: Spirited Away, Totoro, Barakamon.
💬 Exemplo: “Viver em wa é encontrar o silêncio dentro do barulho.” 🌷


💮 Curiosidades Bellacosa:

  • Muitas dessas expressões nascem da estética zen, que busca a perfeição na simplicidade.

  • A língua japonesa usa a natureza como espelho da alma: o vento, o mar e a lua são sentimentos, não apenas imagens.

  • Em animes, essas palavras aparecem como títulos de episódios, músicas-tema ou nomes de personagens — e sempre com propósito simbólico.


🍵 Dica Bellacosa:

Se quiser compreender o Japão de verdade,
não traduza — sinta.
Observe o komorebi, ouça o silêncio, aceite o mujō.
Essas palavras são portais — cada uma guarda um pedaço da alma japonesa.


🌙 Conclusão Bellacosa:

O idioma japonês é um poema vivo — feito de ecos, pausas e significados invisíveis.
E os animes são pontes entre essa filosofia e o nosso coração.

“Wabi-sabi é aceitar que nada é perfeito.
Mujō é entender que nada dura.
Wa é encontrar paz mesmo assim.” 🌸

sábado, 2 de janeiro de 2021

☕💥 A Jornada do Sysprog Padawan – SAF : O Porteiro Invisível do Reino IBM Z - Parte I

 

Bellacosa Mainframe apresenta o SAF Parte I

☕💥 A Jornada do Sysprog Padawan – Parte 1

SAF – O Porteiro Invisível do Reino IBM Z

O componente que todos utilizam, poucos enxergam e quase ninguém explica corretamente

"No Mainframe existem tecnologias famosas, como RACF, CICS e DB2. E existem tecnologias tão importantes que trabalham em silêncio há décadas. O SAF é uma delas."

Bellacosa Mainframe


Introdução

Se você perguntar para um desenvolvedor COBOL:

Como o CICS verifica segurança?

Provavelmente ele responderá:

O CICS chama o RACF.

Se perguntar para um DBA DB2:

Como o DB2 sabe quem pode executar um SELECT?

Talvez ele diga:

O DB2 consulta o RACF.

Se perguntar para um administrador MQ:

Como o MQ autoriza um MQOPEN?

Ele pode responder:

O MQ conversa com RACF.


Tecnicamente?

Todos estão errados.

Porque existe um personagem invisível trabalhando nos bastidores.

Um intermediário.

Um tradutor.

Um despachante.

Um porteiro.

Este personagem é:

SAF

System Authorization Facility


O Reino IBM Z

Vamos novamente usar a analogia Bellacosa.

Imagine o IBM Z como um gigantesco castelo medieval.

Temos:

Cartório Real

RACF


Livro de Ocorrências

SMF


Biblioteca

DB2


Departamento Financeiro

IMS


Administração

CICS


Correios

MQ


Bairro Unix

USS


Rei

Sysprog


Mas toda pessoa que deseja entrar em algum lugar precisa passar por alguém.

Esse alguém é:

SAF


O que significa SAF?

System

Authorization

Facility


Podemos traduzir informalmente como:

Infraestrutura de Autorização do Sistema

ou

O Barramento Universal de Segurança do z/OS


A grande sacada da IBM

Hoje parece óbvio.

Mas nos anos 70 e início dos 80 era um problema sério.


Imagine.

CICS implementando sua própria segurança.

IMS implementando outra.

DB2 outra.

MQ outra.

USS outra.

JES outra.


Um caos.


Cada produto teria:

Banco próprio

API própria

Logs próprios

Senhas próprias

Administração própria


A IBM percebeu isso rapidamente.


Precisava existir uma camada comum.


Nascia o conceito do SAF.


Origem histórica

MVS

Segurança ainda era relativamente simples.


TSO crescia.


Mais usuários.


Mais aplicações.


Necessidade de padronização.


RACF aparece

1976

IBM.


Inicialmente.

RACF era praticamente sinônimo de segurança.


Mas logo surgiu outro problema.


Produtos terceiros.


ACF2.


Top Secret.


Clientes queriam liberdade.


IBM precisava resolver.


A solução genial

Criar uma interface.


Produtos chamam SAF.


SAF chama ESM.


ESM decide.


Todos felizes.


ESM

External Security Manager


Exemplos

RACF

IBM


ACF2

Broadcom


Top Secret

Broadcom


O que SAF NÃO é

Erro comum.


SAF não possui usuários.


SAF não possui senha.


SAF não possui grupos.


SAF não possui perfis.


SAF não possui certificados.


Quem possui?

RACF.


ACF2.


Top Secret.


O verdadeiro papel do SAF

Receber requisição.


Encaminhar.


Receber resposta.


Devolver.


Simples.

Mas genial.


Arquitetura

Application

↓

SAF

↓

ESM

↓

ALLOW

ou

DENY

Exemplo CICS

Usuário executa.

PAY1


Fluxo.

CICS

↓

SAF

↓

RACF

↓

ACEE

↓

ALLOW

CICS nunca precisou saber.

Como RACF funciona.


Exemplo DB2

SELECT *

FROM CLIENTES

DB2 pergunta.

SAF.


SAF pergunta.

RACF.


RACF responde.


DB2 executa.


Exemplo MQ

MQOPEN


MQPUT


MQGET


Fluxo.

MQ

SAF

RACF

ALLOW


Exemplo USS

SSH

SAF

RACF

OMVS

ACEE

Shell


Exemplo Batch

JOB

JES2

SAF

RACF

ACEE

Execution


O que o SAF utiliza?

O melhor amigo dele.


ACEE


ACEE é o crachá.


SAF adora ACEEs.


Menos consultas.


Menos CPU.


Menos I/O.


Mais throughput.


A evolução do SAF

MVS


MVS/XA


MVS/ESA


OS390


zOS


zOS 3.1


Hoje suporta.


MFA


Passphrase


Certificates


Kerberos


OIDC


Passkeys


Zero Trust


O grande segredo

SAF é um desacoplador.


Aplicações.

Não dependem.

Do produto de segurança.


Trocar RACF.

Por ACF2.


Aplicação continua funcionando.


Trocar RACF.

Por Top Secret.


CICS não percebe.


DB2 não percebe.


MQ não percebe.


USS não percebe.


Por que isso é genial?

Imagine.

500 produtos.


Precisando conhecer.

Três produtos.

De segurança.


1.500 integrações.


Com SAF.


500 integrações.


Muito mais elegante.


Quem usa SAF?

Praticamente tudo.


TSO


ISPF


JES


SDSF


DB2


IMS


MQ


CICS


USS


FTP


NFS


LDAP


OpenSSH


z/OS Connect


Zowe


Ansible


Python


Java


Sysprog Easter Egg ☕

Muitos Sysprogs experientes dizem.

Se você acha que o problema é no RACF.

Provavelmente ainda não olhou para o SAF.


Curiosidade

Provavelmente.

O SAF.

Já processou.

Quadrilhões.

De verificações.

Nos últimos.

40 anos.


Sem aparecer.

Em nenhuma tela.


Sem marketing.


Sem glamour.


Apenas trabalhando.


Como um verdadeiro porteiro.


O mito do RACF

A maioria das pessoas acredita.

Segurança.

=

RACF


Mas a arquitetura correta é.

Application

↓

SAF

↓

ACEE

↓

RACF

↓

SMF

O papel do Sysprog

Conhecer.

Quem pergunta.


Quem responde.


Quem registra.


Quem lembra.


Quem protege.


Analogia Bellacosa ☕

Imagine o castelo.


CICS quer entrar.


DB2 quer entrar.


MQ quer entrar.


USS quer entrar.


Todos chegam.

No mesmo porteiro.


SAF pergunta.

Posso consultar?


RACF responde.


SAF libera.

Ou bloqueia.


SMF escreve.

No livro.


E o ACEE acompanha.

O visitante.


Frase Bellacosa Mainframe

"O RACF conhece o reino. O ACEE conhece o viajante. O SMF conhece a história. Mas é o SAF que atende todas as portas do IBM Z."


☕💥 Continua na Parte 2

SAF – Anatomia Interna

RACROUTE, VERIFY, FASTAUTH, REQUEST Types, Return Codes, Reason Codes, ACEE Interaction, Control Blocks, SAF Router e os mecanismos secretos que fazem bilhões de decisões de segurança por dia.

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO: As 4 Estradas da Transformação Digital no IMS

 

Bellacosa Mainframe evoluindo em IMS 4 vias para crescer mais

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO!

As 4 Estradas da Transformação Digital no IMS: APIs, Java, SQL e DevOps na Visão da IBM

Quando alguém fala em transformação digital, normalmente surgem palavras como Cloud, Kubernetes, APIs, Microservices, DevOps, Inteligência Artificial e OpenShift.

Logo depois aparece alguém apontando para o mainframe e dizendo:

"Precisamos substituir tudo isso porque é legado."

E é exatamente nesse momento que começam alguns dos projetos mais caros, demorados e arriscados da história da TI corporativa.

O material da IBM "The 4 Paths to Digital Transformation in IMS", apresentado por Haley Fung, mostra uma visão radicalmente diferente. Em vez de substituir o IMS, a estratégia proposta é transformá-lo em um participante ativo do ecossistema digital moderno.

A mensagem principal do documento é simples:

O problema não é o IMS.

O problema é quando o IMS fica isolado.

Durante décadas, o IMS foi responsável por processar algumas das cargas mais críticas do planeta. Bancos, seguradoras, governos, operadoras de telecomunicações e empresas aéreas construíram seus negócios sobre ele.

E agora?

Agora a IBM mostra quatro caminhos principais para trazer o IMS para a era digital:

  1. APIs

  2. Java

  3. Open Database (SQL/JDBC)

  4. DevOps e Cloud

Vamos mergulhar profundamente em cada um deles.


O GRANDE MITO: MODERNIZAR NÃO É REESCREVER

Uma das maiores mentiras da indústria é:

Modernizar = Reescrever.

Não.

A IBM deixa claro que o objetivo é preservar o ativo mais valioso:

  • Dados

  • Regras de negócio

  • Processos transacionais

  • Disponibilidade

  • Segurança

Tudo isso já existe dentro do IMS.

A pergunta correta não é:

Como substituir o IMS?

Mas sim:

Como conectar o IMS ao mundo moderno?

Essa diferença de mentalidade pode representar milhões de dólares economizados.


A PRIMEIRA ESTRADA: API-ENABLE EVERYTHING

Transformando transações IMS em APIs REST

Durante décadas, acessar uma transação IMS exigia:

  • 3270

  • MQ

  • Sockets proprietários

  • Middleware especializado

Para um desenvolvedor React, Angular ou Mobile isso parece arqueologia.

A solução apresentada pela IBM é simples:

Transformar ativos IMS em APIs REST.


z/OS Connect Enterprise Edition

O protagonista dessa transformação é:

IBM z/OS Connect EE

Ele permite expor:

  • Transações IMS TM

  • Dados IMS DB

  • Aplicações COBOL

  • Serviços z/OS

como APIs REST modernas.


O cenário tradicional

Imagine um banco.

Aplicação Mobile

Middleware

Gateway Proprietário

MQ

IMS

Múltiplas camadas.

Complexidade.

Custos.


O cenário moderno

Aplicação Mobile

REST API

z/OS Connect

IMS

Muito mais simples.

Muito mais rápido.

Muito mais alinhado ao mercado.


O FIM DA DEPENDÊNCIA DE ESPECIALISTAS MAINFRAME

Uma observação extremamente interessante da IBM:

Não é necessário conhecimento profundo de mainframe para consumir APIs IMS.

Isso muda completamente a equação.

Um desenvolvedor Node.js pode consumir uma API IMS da mesma forma que consome:

  • Salesforce

  • SAP

  • Oracle Cloud

  • AWS

Sem saber o que é um PCB.

Sem saber o que é um GU.

Sem saber o que é um PSB.


IMS DE CENTRO DE CUSTO PARA CENTRO DE RECEITA

Essa é uma frase poderosa do material:

Converter IMS de Cost Center para Revenue Center.

Historicamente o IMS era visto como:

  • Custo operacional

  • Infraestrutura necessária

Com APIs ele passa a gerar novos negócios.

Exemplo:

Uma seguradora possui regras de cotação em IMS.

Em vez de reescrever tudo:

  • expõe APIs

  • integra parceiros

  • cria novos canais digitais

O IMS continua executando a regra.

O mercado passa a consumi-la.


CASOS REAIS DE SUCESSO

O documento apresenta diversos exemplos.

Um deles reduziu um processo de abertura de contas de:

3 dias
para
menos de 1 segundo.

Resultado:

  • 5.500 novas contas

  • milhões em novos depósitos

  • centenas de horas economizadas

Tudo sem substituir o IMS.


A SEGUNDA ESTRADA: JAVA NO IMS

Agora chegamos ao tema mais polêmico.

Quando alguém fala:

Java no Mainframe

sempre surge alguém dizendo:

Isso não faz sentido.

Mas a IBM vem investindo nisso há mais de 15 anos.


POR QUE JAVA?

Porque existe um problema real.

Encontrar:

  • COBOL Developers

  • IMS Specialists

  • DL/I Experts

está cada vez mais difícil.

Enquanto isso existem milhões de desenvolvedores Java no mundo.

A IBM percebeu isso há muito tempo.


NÃO É COBOL VS JAVA

Esse é outro erro comum.

O documento não propõe eliminar COBOL.

Ele propõe:

COBOL + Java

Trabalhando juntos.


ESTRATÉGIA 1: EXTENDER APLICAÇÕES EXISTENTES

Imagine um programa COBOL IMS.

Você possui uma rotina extremamente pesada:

  • validação

  • criptografia

  • cálculo complexo

A IBM sugere mover partes específicas para Java.

Benefícios:

  • melhor manutenção

  • maior disponibilidade de profissionais

  • possibilidade de uso de frameworks modernos


ESTRATÉGIA 2: NOVAS APLICAÇÕES EM JAVA

Outra abordagem:

Criar novas aplicações IMS diretamente em Java.

O banco continua sendo IMS.

As transações continuam sendo IMS.

Mas a lógica é Java.


O SEGREDO CHAMADO zIIP

Aqui está uma das partes mais interessantes.

Java pode utilizar melhor os processadores especializados zIIP.

Para muitos ambientes isso significa:

  • menor consumo de MIPS

  • redução de custos

  • melhor escalabilidade


O MITO DA PERFORMANCE

Existe outro preconceito:

Java é lento.

A IBM apresenta benchmark demonstrando mais de:

25.000 transações por segundo

em workload Java sobre IMS.

Isso desmonta completamente a narrativa de que Java no Z seria apenas experimental.


O MODELO HÍBRIDO MAIS INTELIGENTE

O que muitos clientes estão fazendo?

COBOL continua cuidando do núcleo.

Java assume:

  • APIs

  • integrações

  • componentes modernos

  • novas funcionalidades

Resultado:

Baixo risco.

Alta velocidade.


A TERCEIRA ESTRADA: OPEN DATABASE

Agora chegamos ao assunto que faz muitos DBAs arregalarem os olhos.

IMS e SQL.

Sim.

IMS e SQL.


O FIM DO "IMS É FECHADO"

Durante muitos anos ouvimos:

IMS é fechado.

A IBM respondeu criando a estratégia Open Database.


JDBC DIRETO NO IMS

O modelo apresentado permite:

Aplicação Java

JDBC

IMS

Sem extrações complexas.

Sem replicações desnecessárias.

Sem ETLs gigantescos.


POR QUE ISSO É REVOLUCIONÁRIO?

Porque tradicionalmente o fluxo era:

IMS

ETL

Data Warehouse

Analytics

Horas depois.

Às vezes dias depois.


Novo modelo

IMS

SQL

Analytics

Quase em tempo real.


IMS COMO FONTE DE IA E ANALYTICS

O material mostra integração com:

  • Apache Spark

  • IBM Machine Learning for z/OS

  • Db2 Analytics Accelerator

Tudo consumindo dados IMS.

Isso é enorme.

Porque o dado mais valioso da empresa geralmente está no IMS.


IMS CATALOG: A JOIA ESCONDIDA

Outro componente importante é o IMS Catalog.

Historicamente:

DBD
PSB
ACB

eram artefatos compreendidos por poucos especialistas.

O Catalog transforma isso em metadados mais acessíveis.

Resultado:

  • melhor governança

  • descoberta de dados

  • integração simplificada


DDL NO IMS

Uma das maiores mudanças modernas.

Desde o IMS 14:

  • CREATE DATABASE

  • CREATE TABLE

  • ALTER DATABASE

passaram a fazer parte do ecossistema IMS.

Para quem passou décadas vivendo apenas de:

  • DBDGEN

  • PSBGEN

  • ACBGEN

isso representa uma mudança cultural gigantesca.


O QUE ISSO SIGNIFICA PARA O DBA?

Significa que o DBA IMS moderno precisa conhecer:

  • Hierarquia

  • SQL

  • Metadata

  • APIs

  • Analytics

O perfil profissional está mudando.


A QUARTA ESTRADA: DEVOPS E CLOUD

Agora chegamos à transformação mais profunda.


O FIM DO DESENVOLVIMENTO MAINFRAME ISOLADO

Antigamente:

Desenvolvimento Distribuído

Pipeline Moderno

e

Mainframe

Mudanças manuais

Dois mundos separados.


A VISÃO DA IBM

Integrar o IMS ao pipeline corporativo.

Mesmas ferramentas.

Mesma metodologia.

Mesmo fluxo.


GIT NO MAINFRAME

O documento mostra integração com:

  • Git

  • Jenkins

  • Maven

  • Nexus

  • Artifactory

e outros componentes DevOps.

Hoje isso já é realidade em muitos ambientes.


WAZI

Uma das iniciativas mais interessantes mostradas no material.

IBM Wazi oferece:

  • VS Code

  • Eclipse

  • Red Hat CodeReady

  • OpenShift

para desenvolvimento z/OS.


O impacto cultural

O novo desenvolvedor pode trabalhar em:

VS Code

e desenvolver para IMS.

Algo impensável vinte anos atrás.


ANSIBLE NO IMS

Essa talvez seja a parte que mais chama atenção de Sysprogs.

A IBM apresenta coleções específicas Ansible para:

  • z/OS

  • IMS

  • automação operacional


IMS COMO INFRAESTRUTURA PROGRAMÁVEL

Imagine executar:

  • geração de DBD

  • geração de PSB

  • geração de ACB

  • comandos IMS

automaticamente.

O documento mostra exatamente isso através dos módulos:

  • ims_dbd_gen

  • ims_psb_gen

  • ims_acb_gen

  • ims_command

Para um Sysprog isso é quase ficção científica comparado ao modelo tradicional.


ZOWE: O NOVO ROSTO DO MAINFRAME

Outro destaque é o Zowe.

Ele fornece:

  • REST APIs

  • CLI

  • Automação

para administrar IMS.

Exemplos:

  • iniciar regiões

  • parar regiões

  • consultar transações

  • automatizar deploys

Tudo através de scripts modernos.


O IMS ESTÁ VIRANDO CLOUD?

Na prática...

Sim.

Ou pelo menos absorvendo conceitos cloud.


z/OS CLOUD BROKER

O documento mostra o z/OS Cloud Broker integrado ao OpenShift.

Isso permite provisionar serviços como:

  • IMS

  • Db2

  • CICS

  • MQ

  • z/OS Connect

de forma semelhante ao mundo cloud.


O QUE ISSO SIGNIFICA PARA O FUTURO DO IMS?

A conclusão mais importante do material é que a IBM não vê o IMS como tecnologia do passado.

Ela vê o IMS como:

  • Plataforma transacional

  • Fonte de dados

  • Plataforma API

  • Plataforma DevOps

  • Plataforma híbrida


A GRANDE LIÇÃO PARA O PADAWAN MAINFRAME

Se você é:

  • Desenvolvedor COBOL

  • DBA IMS

  • Sysprog

  • Arquiteto

  • Gestor

precisa entender uma coisa.

A guerra não é:

COBOL vs Java

Mainframe vs Cloud

IMS vs Microservices

A verdadeira batalha é:

Sistema Isolado vs Sistema Conectado.

O documento da IBM demonstra que o IMS moderno pode participar de:

✅ APIs REST

✅ OpenAPI

✅ Swagger

✅ Java

✅ JDBC

✅ SQL

✅ Analytics

✅ Machine Learning

✅ Git

✅ Jenkins

✅ OpenShift

✅ Ansible

✅ Zowe

✅ DevOps

✅ Hybrid Cloud

sem abandonar décadas de investimento corporativo.

E talvez essa seja a maior lição de todas:

O futuro não pertence aos sistemas novos.

Pertence aos sistemas que conseguem evoluir.

E poucos sistemas na história da computação provaram tantas vezes sua capacidade de evolução quanto o IMS. ☕💣🚀

Fonte analisada: The 4 Paths to Digital Transformation in IMS, Haley Fung, IBM IMS.


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