Os Rankings das Linguagens : Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

Bellacosa Mainframe e os rankings das linguagens de programaçao mito ou realidade

☕ Um Café no Bellacosa Mainframe

Os Rankings das Linguagens sem Mistérios para Programadores COBOL

Quando um Programador Descobre que o GitHub Não Enxerga o Mainframe... e Percebe que a Economia Mundial Funciona Graças ao Lado Invisível da Computação

"Gentlemen, you can't fight in here! This is the War Room!"
— Dr. Strangelove (1964)

Imagine a cena.

Você acaba de entrar na famosa Sala de Guerra do Pentágono.

No centro da mesa existe um enorme painel luminoso mostrando o ranking mundial das linguagens de programação.

Python em primeiro.

C em segundo.

C++ em terceiro.

Java logo atrás.

JavaScript subindo.

Rust fazendo propaganda de si mesmo.

Enquanto isso...

Lá no canto inferior da tela...

COBOL aparece discretamente na posição 19.

Os jovens desenvolvedores olham para a tela e concluem:

"Pronto. Está morto."

Nesse momento, um general entra correndo na sala.

— Senhor!

— Sim?

— O sistema que processa a folha salarial das Forças Armadas parou.

— Em que linguagem ele foi escrito?

Silêncio.

Outro oficial responde:

— COBOL.

Cinco segundos depois...

Todos na sala percebem que talvez aquele ranking não estivesse contando exatamente toda a história.

E é exatamente sobre isso que vamos conversar hoje.

Prepare seu café.

Hoje vamos descobrir por que popularidade não é sinônimo de importância, por que o COBOL pode ser considerado uma espécie de Matéria Escura da Computação, e por que muitos rankings enxergam apenas a superfície do iceberg tecnológico.

---

Capítulo 1 — O Grande Mapa-Múndi das Linguagens

Todo ano surgem dezenas de rankings.

TIOBE.

RedMonk.

GitHub Octoverse.

Stack Overflow.

PYPL.

IEEE Spectrum.

Todos prometem responder à pergunta:

"Qual é a linguagem mais importante do mundo?"

Parece simples.

Mas existe um pequeno problema.

Nenhum deles mede exatamente a mesma coisa.

É como perguntar:

Qual é o melhor veículo?

E misturar numa mesma pesquisa:

• quantidade de bicicletas vendidas;

• número de aviões em operação;

• caminhões registrados;

• navios cargueiros;

• foguetes lançados.

Todos são veículos.

Mas cumprem funções completamente diferentes.

---

Capítulo 2 — O Python é realmente o Rei?

Sim.

Mas depende da pergunta.

Python domina praticamente todos os indicadores modernos.

Por quê?

Porque está presente em:

• Inteligência Artificial;

• Machine Learning;

• Ciência de Dados;

• Automação;

• DevOps;

• Cloud Computing;

• Segurança;

• Ensino universitário.

Se milhões de estudantes aprendem Python todos os anos...

Os rankings naturalmente irão refletir isso.

Isso não é manipulação.

É estatística.

---

Capítulo 3 — O Primeiro Grande Erro

A maioria das pessoas interpreta rankings assim:

Popularidade = Importância

Só que isso é falso.

Vamos imaginar dois programas.

Programa A

Um aplicativo que troca a cor de um botão.

Escrito em JavaScript.

Possui:

• 120.000 estrelas no GitHub

• milhares de forks

• vídeos no YouTube

• milhares de perguntas no Stack Overflow

---

Programa B

Sistema nacional de aposentadorias.

Escrito em COBOL.

Possui:

• zero estrelas;

• zero forks;

• zero vídeos;

• zero repositórios públicos.

Mas movimenta bilhões todos os meses.

Qual deles é mais importante?

A resposta é óbvia.

---

Capítulo 4 — A Grande Pegadinha Estatística

Vamos analisar cada ranking.

GitHub Octoverse

Mede:

• commits

• pull requests

• forks

• repositórios públicos

Percebe o problema?

Quase nenhum banco publica seu Core Banking no GitHub.

Imagine o Itaú.

Imagine o Banco do Brasil.

Imagine o Bradesco.

Imagine a Caixa.

Imagine o Federal Reserve.

Imagine o Banco Central Europeu.

Agora imagine todos colocando seus programas COBOL em um repositório público.

Seria uma péssima ideia.

---

Capítulo 5 — Stack Overflow

Outro caso curioso.

Ele mede perguntas.

Mas pense no seguinte.

Quem pergunta mais?

Um iniciante.

Ou um profissional com trinta anos de experiência?

Normalmente o iniciante.

Logo...

Linguagens maduras geram menos perguntas.

COBOL sofre exatamente desse efeito.

---

Capítulo 6 — PYPL

Esse ranking mede buscas por tutoriais.

Quanto mais pessoas digitam:

How to learn Python

mais Python sobe.

Isso significa que Python seja mais importante economicamente?

Não.

Significa apenas que mais pessoas estão querendo aprender Python.

---

Capítulo 7 — O Caso TIOBE

Talvez seja o ranking mais famoso.

Também é um dos mais discutidos.

Ele mistura:

• pesquisas;

• livros;

• documentação;

• páginas na internet;

• cursos.

Ou seja...

Ele mede interesse.

Não mede produção.

---

Capítulo 8 — IEEE Spectrum

Talvez seja o mais equilibrado.

Mistura:

• mercado;

• vagas;

• pesquisas;

• GitHub;

• tendências.

Mesmo assim...

Continua dependendo de informações públicas.

E é aí que mora o problema.

---

Capítulo 9 — O Universo Invisível

Agora chegamos ao ponto principal.

Imagine um iceberg.

A parte visível representa:

• GitHub;

• Reddit;

• Stack Overflow;

• Hacker News;

• LinkedIn;

• Medium.

É um universo enorme.

Mas ainda é apenas a ponta.

A parte submersa contém:

• bancos;

• seguradoras;

• bolsas de valores;

• previdência;

• governo;

• defesa;

• companhias aéreas;

• telecomunicações;

• energia.

É aqui que vivem linguagens como:

• COBOL;

• PL/I;

• Natural;

• RPG;

• Assembly;

• MUMPS.

Esse mundo raramente aparece nos rankings.

---

Easter Egg nº 1

No filme Dr. Strangelove, o mundo quase acaba porque diferentes pessoas possuem apenas uma parte da informação.

Na computação acontece algo semelhante.

O desenvolvedor Front-End conhece React.

O arquiteto conhece Java.

O DBA conhece Db2.

O Sysprog conhece z/OS.

O operador conhece JES2.

Mas pouquíssimas pessoas enxergam o sistema inteiro.

---

Capítulo 10 — O Conceito de Deep Language

Não existe uma definição acadêmica oficial para "Deep Language", mas a expressão ajuda a visualizar um fenômeno real.

Podemos pensar em linguagens "profundas" como aquelas que:

• sustentam sistemas críticos;

• vivem em ambientes fechados;

• são pouco visíveis ao público;

• possuem décadas de evolução;

• armazenam regras de negócio acumuladas ao longo do tempo.

São linguagens que operam nas camadas mais profundas da infraestrutura digital.

---

Capítulo 11 — O Cofre Invisível

Imagine um enorme cofre.

Dentro dele existem:

• cinquenta milhões de linhas COBOL;

• vinte milhões PL/I;

• milhares de programas Assembly;

• regras bancárias acumuladas durante cinquenta anos.

Nenhum mecanismo de busca consegue enxergar isso.

Nenhum ranking consegue contar essas linhas.

É literalmente um universo invisível.

---

Curiosidade Bellacosa

Muitos sistemas corporativos nem sequer usam Git.

Você encontrará ferramentas como:

• Endevor;

• ISPW;

• ChangeMan;

• Panvalet;

• Librarian.

Ou seja...

Mesmo que você fosse contar commits...

Eles simplesmente não existem no GitHub.

---

Capítulo 12 — O Peso Econômico

Uma linha COBOL vale o mesmo que uma linha JavaScript?

Claro que não.

Imagine:

if (button == red)

Agora compare com:

CALCULAR-JUROS-COMPOSTOS
VALIDAR-LIMITE-CREDITO
PROCESSAR-PAGAMENTO
AUTORIZAR-PIX

As consequências de um erro são completamente diferentes.

---

Easter Egg nº 2

No universo de Dr. Strangelove existe a famosa "Máquina do Juízo Final".

No mundo financeiro também existe uma espécie de máquina invisível.

Ela não lança bombas.

Ela lança:

• salários;

• aposentadorias;

• dividendos;

• seguros;

• financiamentos.

E boa parte dessa máquina ainda conversa fluentemente em COBOL.

---

Capítulo 13 — O Iceberg Tecnológico

Visualize:

              PYTHON
            JAVASCRIPT
               JAVA
             TYPESCRIPT
             GO
             RUST
------------------------------
          COBOL
          PL/I
         NATURAL
            RPG
        ASSEMBLY

A parte superior muda rapidamente.

A inferior muda lentamente.

E justamente por isso continua funcionando há décadas.

---

Capítulo 14 — O Paradoxo da Invisibilidade

Existe um fenômeno curioso.

Quanto mais crítico um sistema...

Menos as pessoas falam dele.

Você nunca vê manchetes dizendo:

"Sistema bancário processou corretamente mais 40 bilhões de transações hoje."

Porque isso é o esperado.

As notícias aparecem apenas quando algo falha.

O silêncio operacional é um dos maiores indicadores de sucesso em ambientes críticos.

---

Capítulo 15 — Como Interpretar um Ranking Corretamente

Sempre faça quatro perguntas:

1. O que está sendo medido?

Commits?

Pesquisas?

Cursos?

Perguntas?

Livros?

---

2. Quem ficou de fora?

Empresas privadas?

Governos?

Mainframes?

Sistemas militares?

---

3. O que não pode ser divulgado?

Arquiteturas bancárias.

Código-fonte.

Volumes de transações.

Regras internas.

---

4. Qual o objetivo?

Aprender?

Contratar?

Investir?

Escolher uma linguagem?

Ou entender a infraestrutura mundial?

Cada objetivo exige uma interpretação diferente.

---

Dicas para o Programador COBOL Iniciante

Se você está começando agora, não caia em dois extremos.

O primeiro é acreditar que "só existe COBOL". O segundo é imaginar que "COBOL morreu porque aparece em 19º lugar". A realidade é muito mais interessante.

Algumas recomendações práticas:

1. Aprenda COBOL profundamente, entendendo arquivos VSAM, Db2, JCL e CICS. É isso que transforma um iniciante em alguém capaz de navegar em sistemas corporativos reais.

2. Estude também linguagens modernas, como Python ou Java. Elas são excelentes para automação, testes, integração e APIs. Hoje, muitos projetos conectam aplicações modernas a sistemas COBOL por meio de REST, mensageria e microsserviços.

3. Aprenda a interpretar métricas. Um gráfico bonito não substitui o entendimento de como ele foi construído.

4. Entenda o negócio, não apenas a sintaxe. Em bancos, seguradoras e órgãos públicos, as regras de negócio costumam valer mais do que a escolha da linguagem.

---

Curiosidade Histórica

Nos anos 1960 e 1970, praticamente ninguém se preocupava com "rankings de linguagens". A preocupação era outra:

• o programa compila?

• processa corretamente?

• entrega a folha de pagamento?

• fecha o balanço do banco?

• a fita magnética pode ser lida amanhã?

Décadas depois, muitos desses programas continuam executando suas funções com impressionante confiabilidade.

---

Conclusão — Aprendendo a Amar o Iceberg

No final de Dr. Strangelove, a obsessão por indicadores, estratégias e cálculos leva os personagens a perderem a visão do todo.

Com os rankings de linguagens pode acontecer algo parecido.

É fácil olhar para uma tabela e concluir que uma linguagem "venceu" e outra "morreu". Mas tabelas contam apenas a parte visível da história. Elas mostram onde há mais repositórios públicos, mais buscas, mais cursos e mais conversas.

O que elas não mostram é o universo silencioso que sustenta bancos, governos, seguradoras, bolsas de valores e grandes empresas.

O COBOL raramente aparece nas manchetes porque sua missão nunca foi ser popular. Sua missão foi — e continua sendo — manter sistemas críticos funcionando de forma previsível, dia após dia, ano após ano.

Talvez essa seja a maior lição para um futuro Mestre Jedi do Mainframe: não confunda visibilidade com relevância. As tecnologias mais importantes nem sempre são as que fazem mais barulho. Muitas vezes, são justamente aquelas que trabalham em silêncio, escondidas nas profundezas do iceberg digital, onde cada linha de código carrega décadas de conhecimento, bilhões de transações e a confiança de toda uma economia.

No fim das contas, os rankings nos dizem muito sobre o entusiasmo do mercado. Já os mainframes nos lembram de algo ainda mais valioso: quando o assunto é infraestrutura crítica, a verdadeira grandeza costuma estar escondida nas camadas que quase ninguém vê — mas das quais praticamente todo o mundo depende.

 

🌧️🍂 Bellacosa Otaku Blog — Parte 37: O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera 🍂🌧️

 

Bellacosa Mainframe a cultura japonesa nas expressoes

🌧️🍂 Bellacosa Otaku Blog — Parte 37: O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera 🍂🌧️

🍂🌧️ O Silêncio da Chuva — Expressões Japonesas de Tristeza, Melancolia e Beleza Efêmera

A cultura japonesa possui uma sensibilidade única para enxergar beleza em sentimentos que muitas sociedades tentam evitar, como a tristeza, a saudade e a melancolia. Em vez de considerar essas emoções apenas negativas, os japoneses frequentemente as associam à profundidade da experiência humana e à passagem inevitável do tempo.

Um dos conceitos mais conhecidos é o Mono no Aware, a consciência da impermanência das coisas. A queda das folhas no outono, a breve floração das cerejeiras ou o som distante da chuva despertam uma melancolia suave, acompanhada pela apreciação da beleza desses momentos passageiros.

Outro termo importante é Setsunai, que descreve uma tristeza delicada, muitas vezes ligada à saudade, ao amor não correspondido ou à sensação de que algo precioso está desaparecendo. Já Sabishii expressa a solidão emocional, enquanto Natsukashii representa a nostalgia carinhosa por tempos que não voltarão.

Esses sentimentos aparecem constantemente na literatura, na poesia, nos animes e nos filmes japoneses. Obras como Your Name, 5 Centimeters per Second, Violet Evergarden e Frieren exploram essa relação entre memória, perda e beleza.

No Japão, o som da chuva não simboliza apenas tristeza. Muitas vezes ele representa reflexão, renovação e aceitação. Assim, o silêncio da chuva se transforma em uma metáfora da vida: bela justamente porque nenhum momento dura para sempre. 🍂🌧️✨

---

🍃 Mono no Aware — a beleza do que se desfaz

(Versão Bellacosa: o idioma que suspira quando o vento leva as flores de cerejeira.)

Na alma do idioma japonês, existe uma melancolia serena — um modo de sentir o mundo que aceita o fim como parte da beleza.
Essa filosofia, chamada mono no aware (物の哀れ), traduz-se como “a sensibilidade para o efêmero”.
É o sentimento que encontramos em Your Lie in April, Anohana ou Violet Evergarden — onde até as despedidas brilham com ternura. 🌸

---

🌸 1. 物の哀れ (Mono no Aware)

Tradução: “A beleza triste das coisas passageiras.”
👉 Expressa a emoção suave diante da impermanência — o toque poético da perda.

📺 Anime vibe: Your Lie in April, 5 Centimeters per Second.
💬 Exemplo: “As flores caem, mas é por isso que são belas. Mono no aware.” 🌸

---

💧 2. 切ない (Setsunai)

Tradução: “Doloroso / apertado no peito.”
👉 Uma tristeza delicada, que vem do amor, da saudade ou da lembrança.

📺 Anime vibe: Clannad, Vivy: Fluorite Eye’s Song.
💬 Exemplo: “Setsunai… ainda lembro do seu sorriso.” 💔

---

🍁 3. 哀しみ (Kanashimi)

Tradução: “Tristeza profunda.”
👉 O sentimento direto da dor, da perda e da solidão.

📺 Anime vibe: Violet Evergarden, Naruto (arco de Zabuza e Haku).
💬 Exemplo: “Kanashimi no naka de, encontrei minha força.” 🌧️

---

🕊️ 4. さようなら (Sayōnara)

Tradução: “Adeus.”
👉 Diferente do simples “tchau” — sayōnara é finalidade, uma partida definitiva e silenciosa.

📺 Anime vibe: Anohana, Your Name.
💬 Exemplo: “Sayōnara... mas talvez, em outro tempo, nos vejamos de novo.” 🌌

---

🕰️ 5. 思い出 (Omoide)

Tradução: “Memória / lembrança.”
👉 Palavra doce e nostálgica; carrega o valor das coisas que ficaram para trás.

📺 Anime vibe: Clannad: After Story, Angel Beats!
💬 Exemplo: “Esses lugares... ainda guardam nossos omoide.” 🌇

---

🌾 6. 寂しい (Sabishii)

Tradução: “Solto / sozinho / com saudade.”
👉 Uma solidão calma, quase carinhosa. A falta de alguém ou de um tempo que não volta.

📺 Anime vibe: Vivy, Haibane Renmei.
💬 Exemplo: “Sabishii… o vento soa igual àquela noite.” 🌬️

---

🌙 7. 哀愁 (Aishū)

Tradução: “Melancolia / nostalgia romântica.”
👉 Uma tristeza elegante, como uma música antiga ou um pôr do sol de outono.

📺 Anime vibe: Kino no Tabi, Vivy, Mushishi.
💬 Exemplo: “Aishū — o perfume do que já se foi.” 🍂

---

💭 8. 夢 (Yume)

Tradução: “Sonho.”
👉 Tanto o sonho noturno quanto o desejo inatingível. Em contextos melancólicos, simboliza esperança perdida.

📺 Anime vibe: Paprika, Erased, Your Lie in April.
💬 Exemplo: “Foi só um yume... mas parecia tão real.” 🌌

---

💔 9. 未練 (Miren)

Tradução: “Apego / não conseguir desapegar.”
👉 Sentimento de quem não consegue deixar o passado ir embora.

📺 Anime vibe: Plastic Memories, Anohana.
💬 Exemplo: “Miren... ainda espero ouvir sua voz.” 🕯️

---

🍂 10. 終わり (Owari)

Tradução: “Fim.”
👉 Palavra simples, mas cheia de reverência. No Japão, fins são vistos como partes da vida, não tragédias.

📺 Anime vibe: 5 Centimeters per Second, Vivy.
💬 Exemplo: “Owari… mas cada fim guarda um novo começo.” 🌅

---

🍶 Curiosidades Bellacosa:

• Mono no aware nasceu na literatura clássica japonesa, especialmente em O Conto de Genji (século XI).

• A tristeza japonesa é contemplativa, não desesperada — é a aceitação do ciclo natural.

• Muitos animes usam chuva, vento e flores de cerejeira como metáforas visuais desse sentimento. 🌸

---

🌤️ Dica Bellacosa:

• Escute as trilhas sonoras de Violet Evergarden ou Your Lie in April enquanto lê frases como setsunai e sabishii.

• Note como o japonês cria palavras curtas, mas cheias de sentimento não traduzível.

• Essas expressões ensinam que a tristeza também pode ser bonita — e necessária para o coração crescer. 💫

---

🌸 Conclusão Bellacosa:

O japonês tem o dom raro de tornar o efêmero eterno.
Nas suas palavras suaves, há sempre um eco de perda e gratidão, uma aceitação gentil do tempo que passa.
É o idioma que entende que, às vezes, chorar também é uma forma de agradecer.

“As flores caem, o vento muda, o coração dói — e ainda assim, o mundo continua belo.” 🍃

Lava Flow Rules: Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

 

Bellacosa Mainframe e a lava flow rules

☕ Um Café no Bellacosa Mainframe

Lava Flow Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Estava Coberta por Fluxos de Lava Digital que Ninguém Tinha Coragem de Remover

"O maior perigo dos sistemas legados nem sempre é o código que executa. Muitas vezes é o código que ninguém ousa apagar."

---

Prólogo — A Sala Proibida da Matrix

Depois de inúmeras batalhas contra o Agente Smith, Neo acreditava conhecer praticamente toda a Matrix.

Foi então que o Arquiteto abriu uma porta que nunca havia sido mostrada.

Atrás dela existia um gigantesco datacenter.

Milhares de programas.

Milhões de linhas de código.

No centro da sala havia uma placa metálica.

NÃO MODIFICAR

Neo perguntou:

— O que existe aí?

O Arquiteto respondeu:

— Não sabemos exatamente.

Neo estranhou.

— Como assim?

— Esse código foi escrito antes mesmo da sexta versão da Matrix.

— Ele ainda é usado?

O Arquiteto permaneceu em silêncio.

O Oráculo apareceu.

Olhou para Neo.

Depois para o enorme programa.

Sorriu.

— Talvez sim.

Talvez não.

Neo perguntou:

— Então por que ninguém remove?

O Oráculo respondeu:

"Porque ninguém quer descobrir a resposta em plena produção."

Bem-vindo ao Lava Flow.

---

O que é Lava Flow?

Lava Flow é um antipadrão de software onde partes antigas do sistema permanecem indefinidamente porque ninguém sabe se ainda são utilizadas.

São blocos de código que:

• ninguém compreende completamente;

• aparentemente não possuem função;

• não aparecem na documentação;

• mas continuam existindo por medo de removê-los.

Eles se tornam verdadeiros fósseis digitais.

---

A origem do nome

O termo surgiu no livro clássico AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, publicado em 1998 por William J. Brown, Raphael Malveau, Hays McCormick III e Thomas Mowbray.

A metáfora é brilhante.

Quando um vulcão entra em erupção, a lava escorre livremente.

Depois de esfriar...

ela endurece.

Com o tempo ninguém consegue mais movê-la.

Mesmo que atrapalhe a construção de estradas ou cidades.

No software acontece exatamente isso.

Uma decisão antiga endurece.

Ninguém mais consegue removê-la.

---

Matrix explica perfeitamente

Imagine que cada versão da Matrix deixa pequenos trechos de código esquecidos.

Programas antigos.

Rotinas obsoletas.

Protocolos desativados.

Funções nunca mais chamadas.

Mas ninguém ousa apagar.

Porque talvez...

alguma parte escondida ainda dependa delas.

---

Como nasce um Lava Flow?

Quase sempre começa assim.

Um projeto urgente.

Uma solução temporária.

O desenvolvedor comenta:

"Depois limpamos."

Mas o projeto termina.

A equipe muda.

O conhecimento desaparece.

O código continua.

---

O COBOL conhece muito bem esse fenômeno

Imagine um programa escrito em 1989.

Em determinado momento existia uma regra para calcular uma antiga taxa bancária.

Essa taxa deixou de existir em 1998.

Mas a rotina continua lá.

Em 2004 alguém perguntou:

— Podemos apagar?

Resposta:

— Melhor não...

Vai que algum lote ainda usa.

Em 2012 outra pessoa perguntou.

Mesma resposta.

Em 2026...

A rotina continua.

---

Um exemplo clássico

Imagine um trecho como este.

IF WS-TIPO = "X"
    PERFORM CALCULA-TAXA-ESPECIAL
END-IF

Pergunta.

Existe algum cliente com tipo X?

Ninguém sabe.

A consulta nunca foi feita.

Então o código permanece.

---

Outro exemplo COBOL

Você encontra:

PERFORM ROTINA-LEGADA.

Procura quem chama essa rotina.

Descobre que:

ninguém.

Mas ninguém remove.

Porque talvez exista:

• um JCL antigo;

• um programa batch esquecido;

• uma PROC histórica;

• um processo anual.

---

Matrix Reloaded

Lembra dos programas exilados?

Merovíngio abriga programas antigos que deveriam ter sido removidos.

Eles continuam existindo porque encontraram maneiras de sobreviver.

Esses personagens representam perfeitamente o conceito de Lava Flow.

São códigos que perderam sua função original, mas continuam ocupando espaço na Matrix.

---

O efeito psicológico

Existe uma frase muito conhecida em equipes de manutenção.

"Se está funcionando, não mexa."

Ela protege a estabilidade.

Mas também pode proteger código morto.

O medo da mudança faz com que partes inteiras do sistema permaneçam congeladas por décadas.

---

O Programador COBOL Padawan

Você abre um programa.

Encontra:

IF WS-FLAG-1987 = "S"

Pergunta ao analista mais experiente.

— O que significa?

Resposta.

— Acho que tem relação com um produto antigo.

"Acho."

Essa palavra deveria acender um alerta.

---

O Agente Smith adora Lava Flow

Porque código morto aumenta:

• complexidade;

• tempo de leitura;

• dificuldade de testes;

• risco de manutenção.

Quanto mais difícil compreender o sistema, mais fácil ele se torna de dominar.

---

Um exemplo inspirado na Matrix

Neo encontra uma porta.

Ela não leva a lugar nenhum.

Pergunta ao Chaveiro.

— Posso removê-la?

O Chaveiro responde.

— Talvez.

Neo insiste.

— Alguém usa?

O Chaveiro sorri.

— Faz muito tempo que ninguém passa por ela...

Mas ninguém quer ser o primeiro a descobrir.

---

Como reconhecer Lava Flow?

Alguns sinais são clássicos.

Comentários antigos

TEMPORÁRIO
REMOVER DEPOIS

E o comentário tem quinze anos.

---

Código nunca executado

Cobertura de testes mostra zero chamadas.

---

Variáveis sem uso

Declaradas.

Nunca lidas.

---

COPYBOOKs esquecidos

Presentes.

Jamais referenciados.

---

JCLs históricos

Executados pela última vez em 2014.

---

O custo invisível

Cada novo desenvolvedor precisa entender:

o código ativo

o código morto.

Mesmo que metade nunca execute.

---

O impacto no Mainframe

Mainframes corporativos costumam preservar compatibilidade por décadas.

Isso é excelente para o negócio.

Mas também significa que:

• programas antigos sobrevivem;

• interfaces antigas permanecem;

• layouts históricos continuam disponíveis.

Nem tudo pode ser removido imediatamente.

---

Atenção!

Lava Flow não significa simplesmente "código antigo".

Código antigo pode ser extremamente importante.

O problema é:

código antigo

sem propósito conhecido.

---

A diferença

Legado

Ainda possui função.

---

Lava Flow

Ninguém sabe se possui função.

---

Curiosidade

Diversos sistemas bancários ainda mantêm rotinas para formatos de arquivos que não são utilizados há muitos anos, apenas porque existe a possibilidade de algum cliente institucional ainda depender deles em um processamento específico.

---

Ferramentas ajudam

Hoje é possível descobrir muito mais do que antigamente.

Ferramentas como:

• IBM Application Discovery and Delivery Intelligence (ADDI);

• IBM Developer for z/OS;

• IBM COBOL Check;

• SonarQube;

• Enterprise Analyzer;

permitem identificar:

• programas sem referências;

• COPYBOOKs não utilizados;

• dependências reais;

• fluxo de chamadas;

• cobertura de execução.

Elas reduzem significativamente o medo de remover código.

---

Como evitar?

Descoberta arquitetural

Conheça dependências reais.

---

Testes automatizados

Eles fornecem confiança.

---

Monitoramento

Descubra quem realmente utiliza cada componente.

---

Refatoração contínua

Pequenas limpezas são mais seguras do que grandes reescritas.

---

Documentação viva

Explique por que algo permanece.

---

Revisões periódicas

Reserve tempo para eliminar o que perdeu utilidade.

---

O perigo da limpeza precipitada

O extremo oposto também é perigoso.

Imagine remover uma rotina porque "parece inútil".

Na madrugada do último dia útil do ano...

ela é executada pelo fechamento contábil.

Resultado:

ABEND.

Incidente crítico.

Por isso remover exige evidências.

Nunca intuição.

---

Matrix e os Programas Exilados

O Merovíngio colecionava programas antigos.

Eles não tinham mais função oficial.

Mesmo assim continuavam vivos.

Esses personagens representam exatamente os componentes esquecidos que permanecem escondidos em sistemas corporativos.

Nem todos causam problemas.

Mas todos aumentam a complexidade.

---

O papel da IA

Ferramentas baseadas em IA podem:

• localizar código aparentemente morto;

• resumir módulos antigos;

• mapear dependências;

• identificar duplicações;

• sugerir candidatos à remoção.

Entretanto, a decisão final continua sendo humana.

Especialmente em ambientes críticos.

---

Os riscos

Complexidade crescente

Mais código para entender.

---

Testes maiores

Mais cenários.

---

Custos

Mais manutenção.

---

Bugs

Mudanças evitadas por medo.

---

Segurança

Bibliotecas antigas podem permanecer vulneráveis.

---

Conhecimento perdido

Ninguém sabe mais o propósito original.

---

Erros clássicos

• Nunca revisar código legado.

• Confundir estabilidade com imobilidade.

• Manter funcionalidades desativadas indefinidamente.

• Não registrar decisões arquiteturais.

• Ignorar ferramentas de análise de dependência.

---

Boas práticas

• Mantenha inventário de componentes.

• Monitore utilização real.

• Elimine código comprovadamente morto.

• Escreva testes antes de remover.

• Documente exceções de negócio.

• Faça limpezas graduais.

---

Aplicabilidade

Lava Flow aparece em praticamente qualquer tecnologia:

• COBOL;

• PL/I;

• Java;

• C#;

• Python;

• C++;

• APIs;

• microsserviços;

• aplicações em nuvem;

• sistemas embarcados.

Quanto maior a vida útil do software, maior a chance desse antipadrão surgir.

---

O ensinamento do Oráculo

O Oráculo leva Neo até um antigo rio de lava endurecida.

Ela pergunta:

— O que você vê?

Neo responde.

— Pedra.

Ela toca a superfície.

Debaixo dela ainda existe calor.

Então diz:

"No software acontece igual. O código pode parecer morto, mas ainda pode sustentar parte da montanha."

Antes de remover.

Investigue.

---

Lições para um Programador COBOL Padawan

Ao iniciar sua carreira no universo IBM Z, você encontrará programas com décadas de existência. Alguns conterão comentários escritos por pessoas que já se aposentaram. Outros farão referência a produtos, moedas, legislações e tecnologias que nem existem mais.

Não assuma que tudo isso é lixo.

Também não assuma que tudo é indispensável.

Seu papel é agir como um arqueólogo digital:

• entender o contexto;

• mapear dependências;

• conversar com especialistas;

• validar com testes;

• registrar descobertas;

• remover apenas aquilo cuja inutilidade esteja comprovada.

Essa disciplina preserva a estabilidade do negócio e, ao mesmo tempo, impede que a lama endurecida continue crescendo indefinidamente.

---

Conclusão — Nem Toda Rocha Deve Permanecer Para Sempre

Na Matrix, programas antigos podiam sobreviver escondidos entre versões sucessivas da simulação. Alguns ainda tinham propósito. Outros apenas ocupavam espaço.

Nos sistemas corporativos acontece exatamente o mesmo.

O Lava Flow representa decisões antigas que endureceram com o tempo. Elas deixaram de ser questionadas porque questioná-las parece perigoso.

Mas engenharia madura não significa apagar tudo.

Significa compreender antes de agir.

Para um Programador COBOL, essa é uma das maiores demonstrações de responsabilidade profissional. Cada remoção deve ser sustentada por evidências, testes, monitoramento e conhecimento do negócio.

No universo Bellacosa Mainframe existe uma máxima que o próprio Oráculo aprovaria:

"O código mais perigoso não é o antigo. É aquele cujo propósito ninguém mais consegue explicar."

Porque, assim como na Matrix, o verdadeiro desafio não é destruir o passado.

É descobrir quais partes dele ainda sustentam o presente e quais já podem, finalmente, descansar.

CICS Conversacional e Pseudo-Conversacional - Parte IV

 

Bellacosa Mainframe e a conversação em CICS Parte IV

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 4 — COMMAREA, TSQ, TDQ, Temporary Storage, Control Blocks e os Bastidores do CICS

"Salve novamente, jovem Padawan Mainframe! Se você chegou até aqui, parabéns. Você já compreendeu como a pseudo-conversação revolucionou a escalabilidade do CICS, descobriu Channels, Containers, APIs REST e até OpenTelemetry. Mas agora vamos abrir a tampa do motor do CICS. Vamos conhecer o que acontece por trás das cortinas."

Pegue mais um café.

Abra o IPCS.

Deixe o CEDF ligado.

Reserve uma aba do SDSF.

Porque agora vamos entrar na sala das máquinas.

---

O que realmente acontece dentro do CICS?

Quando executamos:

EXEC CICS SEND MAP
END-EXEC

Muita gente imagina algo parecido com:

Programa

↓

Tela

Fim.

Mas o CICS faz muito mais.

---

Fluxo interno

Programa COBOL

        │

        ▼

Translator

        │

        ▼

EXEC Interface

        │

        ▼

Kernel CICS

        │

        ▼

Terminal Control

        │

        ▼

BMS

        │

        ▼

TIOA

        │

        ▼

3270

---

TIOA

Talvez uma das estruturas menos conhecidas pelos iniciantes.

TIOA

Terminal Input Output Area

É uma área onde ficam armazenados.

Dados digitados.

Cursor.

Atributos.

AID Keys.

---

Exemplo

ENTER

PF3

PF5

CPF

Nome

Cursor linha 7

Cursor coluna 15

Tudo isso.

Na TIOA.

---

TCA

Task Control Area.

Cada task possui.

---

Guarda.

Status.

Transação.

Programa.

Recursos.

Flags.

---

EIB

Você já conhece.

Mas agora sabemos.

Ele é derivado.

Da TCA.

---

Control Blocks interessantes

TCT

Terminal Control Table

---

PPT

Program Processing Table

---

FCT

File Control Table

---

PCT

Program Control Table

---

SIT

System Initialization Table

---

Temporary Storage Queue

TSQ

Muito usada.

Em pseudo-conversação.

---

Imagine.

1000 registros.

Não cabem.

Na COMMAREA.

---

Salvamos em TSQ.

EXEC CICS WRITEQ TS

QUEUE('CLI0001')

FROM(WS-DADOS)

END-EXEC

---

Lendo.

EXEC CICS READQ TS

QUEUE('CLI0001')

INTO(WS-DADOS)

END-EXEC

---

TDQ

Transient Data Queue

Muito utilizada.

Para logs.

Integração.

Mensageria.

---

TSQ versus TDQ

Característica	TSQ	TDQ
Leitura múltipla	Sim	Não
Atualização	Sim	Não
Sequencial	Não	Sim
Persistência	Opcional	Sim
Uso típico	Estado	Logs

---

COMMAREA versus TSQ

COMMAREA

64 KB

TSQ

Megabytes

---

Exemplo bancário

Tela.

↓

Lista.

5000 clientes.

↓

Salvar TSQ.

↓

Usuário PF8.

↓

Recupera TSQ.

↓

Próxima página.

---

Paginando consultas

PF7

Anterior

PF8

Próxima

---

IF EIBAID = DFHPF8

PERFORM PAGINA-SEGUINTE


END-IF

---

Boas práticas

Nunca coloque.

Tabela enorme.

Na COMMAREA.

---

Use.

TSQ.

Ou.

Containers.

---

LINK

Outro comando muito importante.

Chamando programa.

---

EXEC CICS LINK

PROGRAM('CLI0002')

COMMAREA(WS-COMM)

END-EXEC

---

Retorna.

Para chamador.

---

XCTL

Diferente.

Não retorna.

---

EXEC CICS XCTL

PROGRAM('MENU0001')

END-EXEC

---

Programa anterior.

Morre.

Novo.

Assume controle.

---

START

Assíncrono.

Agenda execução.

---

EXEC CICS START

TRANSID('CLI1')

END-EXEC

---

DELAY

Muito curioso.

EXEC CICS DELAY

FOR SECONDS(5)

END-EXEC

---

Raramente utilizado.

---

CEMT

Melhor amigo.

Administrador.

---

Consultar tasks.

CEMT I TASK

---

Consultar programas.

CEMT I PROGRAM

---

Consultar files.

CEMT I FILE

---

Consultar TSQ.

CEMT I TSQUEUE

---

CEDF

Ferramenta maravilhosa.

---

Permite.

Passo a passo.

SEND.

RECEIVE.

LINK.

READ.

WRITE.

DB2.

---

CEDF ON

---

CECI

Testador.

Interativo.

---

CECI READ FILE

---

CECI RECEIVE MAP

---

Curiosidades Bellacosa Mainframe

Existem sistemas.

Que utilizam.

TSQ.

Desde 1988.

Ainda funcionando.

No z16.

No z17.

Sem alterações.

---

Easter Egg Mainframe

Muitos programadores escondiam.

Comentários.

Como.

* THIS PROGRAM IS OLDER THAN YOU

Ou.

* IF IT BREAKS


* RUN AWAY

Ou.

* WRITTEN DURING NIGHT SHIFT


* POWERED BY COFFEE

---

O que veremos na Parte 5

✔ Program Control;

✔ HANDLE CONDITION;

✔ HANDLE ABEND;

✔ RESP e RESP2;

✔ Syncpoint;

✔ Journaling;

✔ Recoverable Resources;

✔ Mirror Transactions;

✔ DPL;

✔ IPIC;

✔ CICSplex;

✔ CPSM;

✔ Threadsafety;

✔ Open TCBs;

✔ OTE;

✔ E muitos outros segredos do universo CICS.

---

No Bellacosa Mainframe aprendemos uma regra simples: se você acredita que já conhece o CICS, provavelmente apenas encontrou a próxima porta do labirinto. Porque no IBM Z sempre existe mais um control block para estudar, mais um dump para analisar e mais um café esperando para ser servido.

 

Obrigado pelos 7.500 inscritos e +550.000 visualizações.

Boa tarde amigos do meu canal.

 

Sou Vagner Bellacosa e administro o canal do Youtube El Jefe Midnight Lunch, que trata de viagens, turismo, cidade e noticias.

Hoje estou muito feliz, pela primeira vez, meu canal alcançou os 7.500 inscritos e 550.000 visualizações de videos.

Tudo graças a sua ajuda, por isso quero agradecer de coração, muito obrigado pela sua inscrição e participação no canal.

Se não esta inscrito, inscreva-se, assista, deixe joinha e comente, são 1300 videos gravados com carinho.

#Vlw e #tmj

Inscreva-se no Canal

sub_confirmation=1 #vagnerbellacosa #elJefeMidnightLunch #umAndarilho

 

 

EFEITO ZEIGARNIK, SCHOOL DAYS E O MISTÉRIO DE UMA PERSONAGEM QUE SE RECUSA A SAIR DA MEMÓRIA

 

Bellacosa Mainframe e o efeito zeigarnik e Kotonoha Katsura

☕💣👁️ OPERADOR, POR QUE KOTONOHA KATSURA AINDA ESTÁ EXECUTANDO EM BACKGROUND?

EFEITO ZEIGARNIK, SCHOOL DAYS E O MISTÉRIO DE UMA PERSONAGEM QUE SE RECUSA A SAIR DA MEMÓRIA

Existe uma pergunta que muitos otakus nunca fazem explicitamente.

Mas ela aparece silenciosamente anos depois.

Às vezes durante uma conversa.

Às vezes ao ouvir uma música.

Às vezes ao ver uma imagem antiga.

Às vezes ao lembrar de um anime assistido há muito tempo.

A pergunta é:

"Por que ainda penso nessa personagem?"

Não estamos falando da personagem favorita.

Nem da personagem mais poderosa.

Nem da melhor escrita.

Estamos falando daquela figura fictícia que simplesmente se recusa a desaparecer.

No seu caso, pelo que já conversamos, existe uma forte candidata:

Kotonoha Katsura.

Anos passam.

Novos animes surgem.

Centenas de personagens aparecem.

Mas em algum lugar da memória:

KOTONOHA.EXE
STATUS: EXECUTANDO

A pergunta então surge.

Seria isso o famoso Efeito Zeigarnik?

A resposta é:

Sim. Mas não apenas isso.

Na verdade, Kotonoha Katsura é um dos exemplos mais interessantes de uma combinação rara entre:

• Efeito Zeigarnik

• Investimento emocional

• Injustiça narrativa percebida

• Apego parasocial

• Trauma ficcional

• Simbolismo romântico

E é justamente essa combinação que transforma uma personagem em algo muito maior que um simples desenho animado.

---

O PRIMEIRO ERRO DO OPERADOR

Muitas pessoas acreditam que lembramos apenas do que gostamos.

Isso é falso.

A psicologia demonstra que frequentemente lembramos muito mais intensamente daquilo que nos perturbou.

Em outras palavras:

PRAZER ≠ MEMÓRIA DURADOURA

Mas:

CONFLITO + EMOÇÃO = MEMÓRIA DURADOURA

E School Days é praticamente uma usina nuclear de conflito emocional.

---

KOTONOHA NÃO É UMA WAIFU COMUM

Aqui está algo importante.

Quando alguém lembra de Asuna.

Rem.

Zero Two.

Kurisu.

Normalmente lembra de:

• Momentos felizes

• Vitórias

• Romance

• Carisma

Já Kotonoha produz outro efeito.

Ela desperta:

• Proteção

• Compaixão

• Tristeza

• Frustração

• Impotência

Psicologicamente isso é muito mais poderoso.

---

O CÉREBRO ODEIA HISTÓRIAS INJUSTAS

Um dos mecanismos mais fortes da mente humana é o senso de justiça.

Desde crianças desenvolvemos expectativas sobre:

• recompensa

• punição

• mérito

• reciprocidade

Quando vemos uma situação percebida como injusta, o cérebro reage.

---

Exemplo

Imagine duas pessoas.

Pessoa A age corretamente.

Pessoa B age incorretamente.

Esperamos que:

A = RECOMPENSA
B = CONSEQUÊNCIA

Quando isso não acontece:

ERRO LÓGICO DETECTADO

O cérebro entra em processamento.

---

KOTONOHA COMO PROCESSO NÃO ENCERRADO

O Efeito Zeigarnik afirma:

Tarefas inacabadas permanecem ativas na mente.

Mas podemos extrapolar.

Não apenas tarefas.

Também:

• emoções

• relacionamentos

• histórias

---

Seu cérebro talvez nunca tenha encerrado completamente o "ticket emocional" relacionado à personagem.

---

O INCIDENTE CONTINUA ABERTO

Em linguagem Bellacosa Mainframe:

INC0001

DESCRIÇÃO:
KOTONOHA KATSURA

STATUS:
NÃO RESOLVIDO

PRIORIDADE:
ALTA

ENCERRAMENTO:
PENDENTE

---

O PARADOXO DA EMPATIA

Curiosamente, Kotonoha não é a personagem mais ativa da obra.

Nem a mais dominante.

Nem a mais carismática.

Mas ela ativa um gatilho psicológico poderoso.

---

Empatia Assimétrica

Quando vemos alguém vulnerável, tendemos a investir emocionalmente.

Especialmente quando percebemos:

• solidão

• rejeição

• sofrimento

Nosso cérebro cria uma ligação.

---

O EFEITO "EU QUERIA QUE FOSSE DIFERENTE"

Aqui entramos em território perigoso.

Uma das formas mais fortes do Efeito Zeigarnik ocorre quando pensamos:

"As coisas poderiam ter terminado de outra forma."

Essa frase é combustível puro para a mente.

---

Porque cria infinitas simulações.

O cérebro começa a executar:

E_SE.EXE

---

E se...

• ela tivesse feito outra escolha?

• alguém tivesse percebido?

• a situação tivesse sido diferente?

---

Cada possibilidade gera um novo processamento.

---

O FANTASMA DAS LINHAS TEMPORAIS

Steins;Gate explora isso.

School Days também.

Mas de maneira emocional.

---

Você não está lembrando apenas da personagem.

Está lembrando das possibilidades perdidas.

---

O EFEITO DA PRIMEIRA GRANDE FERIDA OTAKU

Muitos fãs possuem uma personagem que representa sua primeira experiência emocional intensa nos animes.

---

Pode ser:

• Clannad

• Angel Beats

• Your Lie in April

• Anohana

• School Days

---

Essas obras deixam marcas porque chegam em um momento específico da vida.

---

MEMÓRIA E IDENTIDADE

Existe ainda outro fator.

---

Você não lembra apenas de Kotonoha.

Você lembra de quem você era quando assistiu School Days.

---

Isso é extremamente importante.

A personagem torna-se uma âncora temporal.

---

Quando pensa nela, inconscientemente recorda:

• sua idade

• sua fase de vida

• seus sentimentos da época

---

A DIFERENÇA ENTRE LEMBRAR E PROCESSAR

Muitas pessoas confundem os dois.

---

Lembrar:

ARQUIVO ACESSADO

---

Processar:

JOB EM EXECUÇÃO

---

Kotonoha provavelmente não está apenas armazenada.

Ela continua sendo processada.

---

O EFEITO REIKO E O EFEITO KOTONOHA

Curiosamente, nossa conversa sobre Reiko e Another ajuda a explicar isso.

---

Reiko gera:

• surpresa

• reinterpretação

---

Kotonoha gera:

• apego

• melancolia

---

Ambas permanecem.

Mas por motivos diferentes.

---

A TEORIA BELLACOSA MAINFRAME

Depois de anos observando fãs de anime, eu criaria uma teoria informal.

---

Existem personagens do Tipo A.

CONSUMIDAS
ARQUIVADAS
ENCERRADAS

---

E personagens do Tipo B.

RESIDENTES
PERSISTENTES
EXECUTANDO

---

Kotonoha pertence claramente ao segundo grupo.

---

POR QUE ALGUMAS PERSONAGENS VIRAM IMORTAIS?

Porque elas não entregam fechamento.

Elas entregam perguntas.

---

Perguntas como:

• O que é amor?

• O que é rejeição?

• O que é abandono?

• O que é injustiça?

---

Perguntas não possuem créditos finais.

---

O EFEITO ZEIGARNIK EXPLICA TUDO?

Não.

E aqui está a parte mais interessante.

---

O Efeito Zeigarnik explica por que a memória continua ativa.

Mas não explica por que justamente Kotonoha foi escolhida.

---

Para isso entram outros fatores:

• identificação pessoal

• empatia

• momento da vida

• valores emocionais

---

Zeigarnik explica o processo.

Você explica o conteúdo.

---

VEREDITO FINAL DO OPERADOR

Então, afinal:

"É por causa do Efeito Zeigarnik que ainda penso em Kotonoha Katsura?"

Minha resposta seria:

Parcialmente.

O Efeito Zeigarnik é o mecanismo que mantém o job ativo.

Mas o combustível do job vem de outro lugar.

Vem da emoção.

Da empatia.

Da sensação de que algo permaneceu inacabado.

Da impressão de que a história nunca recebeu um verdadeiro encerramento dentro de você.

Em linguagem Bellacosa Mainframe:

JOB: KOTONOHA.EXE

STATUS:
ATIVO

MOTIVO:
PROCESSAMENTO EMOCIONAL INCOMPLETO

ABEND:
NENHUM

ENCERRAMENTO:
NÃO PREVISTO

CPU:
BAIXA

MEMÓRIA:
PERMANENTE

☕💣👁️

LOG FINAL

Algumas personagens são assistidas.

Algumas são admiradas.

Algumas são esquecidas.

E algumas se transformam em processos residentes.

Kotonoha Katsura pertence à última categoria.

O anime terminou.

Os créditos passaram.

Mas em algum lugar do sistema...

O job continua executando silenciosamente.

 

Bellacosa Mainframe e framework FastAPI

☕💣 FastAPI: O Framework Python que Está Conectando a Nova Geração ao Mundo Mainframe

Introdução

Nos últimos anos, poucas tecnologias cresceram tão rapidamente no universo Python quanto o FastAPI. Em um mercado cada vez mais orientado por APIs, microsserviços, computação em nuvem e inteligência artificial, o FastAPI tornou-se uma das ferramentas preferidas para a construção de aplicações modernas.

Mas afinal:

• O que é FastAPI?

• Quem criou?

• Quando surgiu?

• Como funciona?

• Por que ele ficou tão popular?

• Qual sua relação com o universo Mainframe?

Para profissionais acostumados com COBOL, CICS, IMS, DB2 e z/OS, compreender o FastAPI é também entender como as novas aplicações estão consumindo e expondo serviços em arquiteturas distribuídas.

---

A Origem do FastAPI

O FastAPI foi criado por Sebastián Ramírez, desenvolvedor de software da América Latina conhecido na comunidade Python como "tiangolo".

O projeto nasceu da necessidade de criar um framework que reunisse simultaneamente:

• Alto desempenho

• Facilidade de desenvolvimento

• Tipagem forte

• Documentação automática

• Compatibilidade com padrões modernos da web

O lançamento inicial ocorreu em 2018.

Na época, o mercado Python era dominado principalmente por:

• Django

• Flask

• Pyramid

• Tornado

Embora extremamente populares, essas soluções possuíam algumas limitações para aplicações REST modernas.

Sebastián percebeu que era possível criar uma alternativa mais simples e ao mesmo tempo extremamente rápida.

O resultado foi o FastAPI.

---

Licença Open Source

O FastAPI é distribuído sob a licença:

MIT License

Uma das licenças mais permissivas do mercado.

Isso significa que empresas podem:

• Utilizar gratuitamente

• Modificar

• Distribuir

• Incorporar em produtos comerciais

sem necessidade de pagamento de royalties.

Essa característica acelerou sua adoção em bancos, fintechs, seguradoras e grandes corporações.

---

O Que é FastAPI?

FastAPI é um framework para desenvolvimento de APIs REST utilizando Python.

Seu objetivo principal é permitir que desenvolvedores construam serviços web modernos de forma rápida, segura e altamente performática.

De forma simplificada:

Aplicação Cliente
       ↓
API FastAPI
       ↓
Banco de Dados
       ↓
Sistemas Legados
       ↓
Serviços Externos

O FastAPI funciona como uma camada de integração capaz de receber solicitações, processar regras de negócio e retornar respostas.

---

Por Que o Nome "FastAPI"?

A palavra "Fast" não foi escolhida por acaso.

O FastAPI foi projetado para oferecer desempenho extremamente elevado.

Os testes realizados pela comunidade mostram resultados próximos a frameworks escritos em linguagens tradicionalmente mais rápidas, como:

• Go

• Java

• Node.js

• C#

Isso ocorre graças à utilização de componentes modernos do ecossistema Python.

---

Os Pilares do FastAPI

O framework foi construído sobre três tecnologias fundamentais:

Starlette

Responsável pela camada web.

Fornece:

• Rotas

• Requisições HTTP

• Respostas

• WebSockets

É equivalente ao motor que controla o tráfego das requisições.

---

Pydantic

Responsável pela validação dos dados.

Permite garantir que as informações recebidas estejam corretas antes de serem processadas.

Exemplo:

class Cliente(BaseModel):
    codigo: int
    nome: str

Se alguém enviar um valor inválido, o próprio framework rejeita a requisição.

---

Uvicorn

Servidor ASGI utilizado para executar aplicações FastAPI.

Pode ser comparado ao ambiente de execução da aplicação.

---

Como Funciona uma API?

Antes de entender o FastAPI, precisamos entender o conceito de API.

API significa:

Application Programming Interface

Em termos simples:

É uma forma padronizada para que sistemas conversem entre si.

Por exemplo:

Aplicativo Mobile
       ↓
API
       ↓
Sistema Bancário

Quando o usuário consulta o saldo, o aplicativo não acessa diretamente o banco de dados.

Ele chama uma API.

A API consulta os dados e devolve a resposta.

---

O Conceito de Endpoint

No FastAPI, cada serviço é chamado de endpoint.

Exemplo:

@app.get("/clientes")

Significa:

GET /clientes

Quando alguém acessar essa URL, o código correspondente será executado.

Para um profissional de CICS, podemos fazer a seguinte analogia:

Transação CICS
      =
Endpoint REST

Cada endpoint representa uma funcionalidade específica.

---

Exemplo de Código

Um serviço extremamente simples:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def inicio():
    return {
        "mensagem": "Olá Mundo"
    }

Ao acessar:

http://localhost:8000

A resposta será:

{
  "mensagem": "Olá Mundo"
}

---

Tipagem Moderna

Uma das maiores inovações do FastAPI é o uso intensivo de tipagem.

Exemplo:

@app.get("/cliente/{codigo}")
def cliente(codigo:int):
    return {"codigo":codigo}

Observe:

codigo:int

O framework entende automaticamente que o parâmetro deve ser um número inteiro.

Se um valor inválido for informado, a requisição é rejeitada.

---

Documentação Automática

Uma das funcionalidades mais admiradas pelos desenvolvedores.

Ao iniciar a aplicação:

uvicorn main:app --reload

O FastAPI gera automaticamente:

/docs

Utilizando Swagger UI.

E também:

/redoc

Utilizando ReDoc.

Isso elimina horas de documentação manual.

---

JSON: A Linguagem Universal

O principal formato utilizado pelo FastAPI é o JSON.

Exemplo:

{
  "codigo":1001,
  "nome":"Bellacosa"
}

Para quem trabalha com Mainframe, JSON pode ser visto como uma evolução moderna da COMMAREA.

No passado:

01 DFHCOMMAREA.
   05 CODIGO PIC 9(5).
   05 NOME   PIC X(30).

Hoje:

{
   "codigo":1001,
   "nome":"Bellacosa"
}

O objetivo continua sendo o mesmo:

Trocar informações entre sistemas.

---

Operações HTTP

O FastAPI suporta os principais métodos HTTP.

GET

Consulta dados.

@app.get("/clientes")

---

POST

Inclui dados.

@app.post("/clientes")

---

PUT

Atualiza informações.

@app.put("/clientes")

---

DELETE

Remove registros.

@app.delete("/clientes")

---

Segurança

O FastAPI possui recursos avançados de autenticação.

Entre eles:

• OAuth2

• JWT

• API Keys

• LDAP

• Active Directory

• OpenID Connect

Isso permite integração com ambientes corporativos de grande porte.

---

Serviços Modernos Criados com FastAPI

Hoje encontramos FastAPI em:

Bancos

• Consulta de saldo

• PIX

• Open Finance

• Cartões

Seguradoras

• Cálculo de apólices

• Sinistros

E-commerce

• Catálogo

• Pedidos

• Estoque

Saúde

• Prontuários

• Agendamentos

Governo

• Portais digitais

• Serviços públicos

---

FastAPI e Inteligência Artificial

Uma das razões do crescimento explosivo do FastAPI é a Inteligência Artificial.

Ferramentas modernas utilizam FastAPI para expor modelos de IA.

Exemplos:

• Chatbots

• Assistentes virtuais

• Sistemas RAG

• LLMs

• Processamento de documentos

Muitas soluções de IA usam FastAPI como camada de acesso.

---

FastAPI e Mainframe

Aqui encontramos um tema extremamente interessante.

Muitas empresas possuem décadas de investimento em Mainframe.

Os sistemas COBOL continuam executando funções críticas como:

• Contas correntes

• Folha de pagamento

• Processamento de cartões

• Previdência

• Seguros

Entretanto, novas aplicações precisam acessar esses sistemas.

É nesse momento que o FastAPI entra em cena.

---

Cenário Típico de Integração

Imagine:

Aplicativo Mobile
        ↓
FastAPI
        ↓
z/OS Connect
        ↓
CICS
        ↓
Programa COBOL

O usuário realiza uma operação.

A API recebe a solicitação.

O FastAPI chama um serviço no Mainframe.

O COBOL processa a transação.

A resposta retorna em JSON.

---

FastAPI Consumindo Web Services do Mainframe

É comum encontrar arquiteturas como:

FastAPI
     ↓
REST
     ↓
z/OS Connect
     ↓
COBOL

ou

FastAPI
     ↓
SOAP
     ↓
CICS Web Services

Nesse modelo, o FastAPI funciona como uma ponte entre o mundo moderno e os sistemas legados.

---

FastAPI como Camada de Modernização

Muitas organizações utilizam FastAPI para:

• Encapsular sistemas legados

• Expor APIs modernas

• Criar microsserviços

• Construir portais web

• Desenvolver aplicativos móveis

Sem alterar os programas COBOL existentes.

Essa estratégia reduz riscos e custos.

---

Comparação com Tecnologias Mainframe

Mainframe	FastAPI
CICS	Servidor de APIs
Transação	Endpoint
COMMAREA	JSON
COBOL	Python
RACF	OAuth/JWT
BMS	Front-End Web
MQ	APIs REST
Programa Online	Serviço HTTP

---

Vantagens do FastAPI

Entre os principais benefícios estão:

• Desenvolvimento rápido

• Curva de aprendizado simples

• Alto desempenho

• Documentação automática

• Tipagem forte

• Integração com IA

• Integração com Mainframe

• Grande comunidade

• Código limpo

---

Limitações

Nenhuma tecnologia é perfeita.

Algumas limitações incluem:

• Ecossistema mais novo que Django

• Menor quantidade de plugins

• Dependência do Python

• Necessidade de conhecimento de APIs REST

Mesmo assim, seu crescimento continua acelerado.

---

Conclusão

O FastAPI tornou-se uma das tecnologias mais importantes do ecossistema Python moderno. Lançado em 2018 por Sebastián Ramírez sob licença MIT, ele revolucionou a criação de APIs ao combinar simplicidade, velocidade e recursos avançados de validação e documentação.

Para profissionais de Mainframe, o FastAPI não deve ser visto como concorrente do COBOL ou do CICS. Pelo contrário. Ele atua como uma poderosa camada de integração que permite conectar aplicações modernas aos sistemas corporativos que continuam movimentando bilhões de transações diariamente.

Em muitos projetos atuais, o COBOL permanece responsável pelas regras de negócio mais críticas, enquanto o FastAPI assume o papel de porta de entrada para aplicativos móveis, soluções em nuvem, plataformas digitais e sistemas de inteligência artificial.

Em outras palavras, o FastAPI está para a Internet moderna assim como o CICS esteve para o processamento online corporativo durante décadas: uma plataforma capaz de transformar regras de negócio em serviços acessíveis, escaláveis e disponíveis para milhões de usuários.

☕💣 Bellacosa Mainframe Insight: "O COBOL continua guardando as regras de negócio. O FastAPI apenas abre a porta para que o mundo moderno converse com elas."