☕ 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

quarta-feira, 11 de julho de 2018

O Caso da Porta Invisível : Quando um Programador COBOL Descobre que Seu Sistema de 40 Anos Está Conversando com Aplicativos de Celular

 

Bellacosa Mainframe e o caso da porta invisivel 

☕ Um Café no Bellacosa Mainframe

O Caso da Porta Invisível

Quando um Programador COBOL Descobre que Seu Sistema de 40 Anos Está Conversando com Aplicativos de Celular

"Naquela madrugada chuvosa, enquanto a luz verde do terminal 3270 iluminava fracamente a sala do CPD, uma pergunta ecoava entre os corredores silenciosos do datacenter: como um programa COBOL escrito quando a Internet sequer existia consegue responder, em poucos milissegundos, à consulta de saldo feita por um smartphone do outro lado do planeta?"

Peguei minha xícara de café, observei as luzes do IBM Z piscando como estrelas artificiais e sorri. O mistério estava apenas começando.

Hoje investigaremos uma das maiores mágicas da computação moderna.

Ou melhor...

Uma das maiores ilusões.

Porque nada ali é magia.

É engenharia.

E ela atende pelo nome de CICS Web Services.


Capítulo 1 — O Fantasma que Nunca Saiu do Mainframe

Existe um boato que circula pela Internet há quase vinte anos.

Dizem que o COBOL morreu.

Curiosamente...

Toda vez que alguém consulta o saldo bancário, compra uma passagem aérea, paga um boleto, faz um PIX, reserva um hotel ou utiliza um cartão de crédito...

Lá está ele.

Respirando.

Processando.

Calculando.

Respondendo.

A verdade é que o COBOL nunca precisou aparecer.

Ele apenas trabalha.

Enquanto linguagens modernas brigam por popularidade, frameworks entram e saem de moda e novas arquiteturas surgem a cada ano, milhões de linhas de COBOL continuam executando regras de negócio escritas décadas atrás.

O problema nunca foi o COBOL.

O problema sempre foi a porta de entrada.


Capítulo 2 — O Antigo Castelo

Imagine um enorme castelo medieval.

Dentro dele vivem milhares de escribas.

Eles conhecem absolutamente todas as regras do reino.

Quem pode receber dinheiro.

Quem pode sacar.

Quem está inadimplente.

Quem pode fazer um empréstimo.

Quem possui limite.

Esses escribas representam os programas COBOL.

Durante muitos anos, quem desejava conversar com eles precisava entrar pela porta principal.

Essa porta chamava-se:

Terminal 3270.

Mais tarde surgiram outras entradas.

MQ.

APPC.

Sockets.

CTG.

LU6.2.

Cada uma exigia uma chave diferente.

Era como um castelo cheio de entradas secretas.

Até que alguém teve uma ideia genial.

"E se fizermos uma porta universal?"

Nasciam os Web Services.


Capítulo 3 — A Porta Invisível

A beleza dos CICS Web Services está justamente no fato de que eles quase não alteram o castelo.

Eles não reescrevem o COBOL.

Não mudam o Db2.

Não substituem o VSAM.

Eles apenas constroem uma nova entrada.

Uma entrada que fala a língua do mundo moderno.

Enquanto o aplicativo do banco acredita estar conversando com uma API sofisticada...

Na realidade existe um programa COBOL executando:

EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTAS
WHERE NUMERO = :WS-CONTA
END-EXEC.

Nada mudou.

Mudou apenas quem bate à porta.


Capítulo 4 — O Tradutor Universal

Imagine dois diplomatas.

Um fala apenas português.

Outro apenas japonês.

Sem intérprete, ambos passam horas sorrindo sem entender absolutamente nada.

O CICS Web Service funciona exatamente como esse intérprete.

Ele recebe:

JSON

↓

XML

↓

HTTP

↓

REST

↓

SOAP

E traduz tudo para algo que o programa COBOL compreende.

Da mesma forma, quando o COBOL responde usando uma COMMAREA ou um CHANNEL, o CICS converte a resposta novamente para JSON ou XML.

É como se houvesse um tradutor simultâneo trabalhando o tempo inteiro.


Capítulo 5 — O Caminho Percorrido por uma Consulta de Saldo

Vamos acompanhar uma simples consulta de saldo.

Você abre o aplicativo.

Digita sua senha.

Pressiona "Consultar Saldo".

A partir desse instante começa uma viagem fascinante.

Celular

↓

Internet

↓

HTTPS

↓

Firewall

↓

API Gateway

↓

Load Balancer

↓

Servidor HTTP

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Resposta

↓

Celular

Tudo isso costuma acontecer em menos de um segundo.

Na maioria das vezes, em poucos milissegundos.

O usuário nunca imagina que seu smartphone acabou de conversar com um computador cuja arquitetura tem raízes na década de 1960.


Capítulo 6 — REST e SOAP: Dois Detetives, Dois Métodos

Se este fosse um romance policial, REST e SOAP seriam investigadores completamente diferentes.

Inspetor REST

Chega de camisa dobrada.

Pouca burocracia.

Fala pouco.

Resolve rápido.

Transporta informações em JSON.

Adorado por desenvolvedores Web.

Exemplo:

GET /api/clientes/12345

Resposta:

{
 "saldo":2450.75
}

Simples.

Elegante.

Rápido.


Detetive SOAP

Sempre de terno.

Gravata impecável.

Maleta cheia de documentos.

Tudo precisa estar assinado.

Validado.

Carimbado.

Registrado.

Utiliza XML.

Possui contratos (WSDL).

É extremamente rigoroso.

Por isso continua muito presente em bancos, seguradoras, governos e grandes empresas.


Curiosidade Bellacosa nº 1

SOAP costuma ser criticado por ser "pesado".

Entretanto, em ambientes financeiros, sua estrutura rígida é justamente uma vantagem.

A previsibilidade reduz erros de integração.


Capítulo 7 — Os Personagens Secretos do CICS

Quando alguém fala apenas "CICS Web Services", parece algo simples.

Mas existe uma verdadeira equipe trabalhando nos bastidores.

Entre eles:

PIPELINE

Imagine uma esteira industrial.

Cada estação faz uma tarefa.

Validação.

Conversão.

Segurança.

Encaminhamento.

Resposta.

Tudo organizado.


URIMAP

É o GPS.

Quando chega uma URL:

/api/saldo

Ele sabe exatamente qual programa deve ser chamado.


WEBSERVICE

É a ficha técnica.

Define como funciona o serviço.

Quais dados entram.

Quais dados saem.


TCPIPSERVICE

É quem abre a porta da rede.

Sem ele...

Ninguém entra.


WSBIND

Aqui mora um dos maiores segredos.

Ele conhece o idioma dos dois lados.

XML.

JSON.

COMMAREA.

CHANNEL.

CONTAINERS.

Ele sabe exatamente como converter cada campo.


Easter Egg nº 1 🥚

Os nomes DFHLS2WS e DFHWS2LS parecem códigos secretos encontrados em um filme de espionagem.

Na verdade, escondem uma lógica elegante:

LS → Language Structure

WS → Web Service

Logo:

Language Structure → Web Service

e

Web Service → Language Structure

Depois que você percebe isso, nunca mais esquece.


Capítulo 8 — DFHLS2WS: O Alquimista

Imagine entregar um copybook COBOL.

01 CLIENTE.

   05 NOME.

   05 SALDO.

Poucos instantes depois aparecem:

  • WSDL

  • WSBIND

Quase como um passe de mágica.

Na realidade é o utilitário DFHLS2WS trabalhando.

Ele pega uma estrutura COBOL e cria toda a descrição necessária para transformá-la em Web Service.


Capítulo 9 — DFHWS2LS: O Caminho Inverso

Agora imagine que outra equipe desenvolveu um Web Service.

Você recebe apenas o WSDL.

Como escrever o copybook?

Simples.

O DFHWS2LS faz isso automaticamente.

É como um tradutor que trabalha nos dois sentidos.


Curiosidade Bellacosa nº 2

Esses utilitários economizam centenas de horas de desenvolvimento manual.

Antes deles, muitos mapeamentos XML eram escritos praticamente "na mão".

Hoje isso é automatizado.


Capítulo 10 — COMMAREA ou CHANNEL?

Aqui está uma dúvida clássica de entrevistas.

COMMAREA foi durante décadas a forma padrão de troca de dados.

Ela funciona.

Muito bem.

Mas possui um limite famoso.

32 KB.

Quando as integrações começaram a crescer, surgiu uma necessidade.

Mais espaço.

Mais flexibilidade.

Nasciam:

CHANNEL

+

CONTAINERS

Cada Container funciona como uma pequena caixa.

Você pode possuir dezenas delas.

Cada uma armazenando informações diferentes.

Muito mais elegante.


Capítulo 11 — Segurança: O Porteiro Nunca Dorme

Outro mito bastante comum.

"Se o CICS virou Web Service, qualquer pessoa consegue acessá-lo."

Errado.

Na verdade, normalmente o caminho possui diversas camadas.

HTTPS

↓

TLS

↓

Firewall

↓

API Gateway

↓

RACF

↓

SAF

↓

CICS

↓

Programa

Ou seja...

Mesmo que alguém encontre a URL correta...

Ainda terá de atravessar diversos mecanismos de autenticação e autorização.


Easter Egg nº 2 🥚

Observe os filmes noir dos anos 1950.

Quase sempre existe um porteiro discreto.

Poucos prestam atenção nele.

Mas absolutamente ninguém entra sem passar por ele.

No IBM Z esse porteiro atende por vários nomes:

RACF.

SAF.

TLS.

API Gateway.

Todos silenciosos.

Todos eficientes.


Capítulo 12 — O Grande Equívoco da Modernização

Muitas pessoas acreditam que modernizar significa apagar tudo.

Nada poderia estar mais distante da realidade.

Imagine um prédio histórico.

Você troca:

  • elevadores

  • iluminação

  • rede elétrica

  • ar-condicionado

Mas preserva sua estrutura.

É exatamente isso que acontece no CICS.

O COBOL permanece.

As regras continuam.

O que muda é a forma de acesso.


Capítulo 13 — O Aplicativo Nunca Saberá

Quando um aplicativo Android faz uma chamada REST:

GET /saldo

Ele imagina estar conversando com uma API escrita em Java.

Talvez Node.js.

Quem sabe Python.

Na verdade...

Existe uma enorme possibilidade de existir um programa COBOL executando no final da cadeia.

Essa é uma das maiores demonstrações da longevidade da engenharia de software.


Capítulo 14 — O Verdadeiro Valor Está nas Regras de Negócio

Código pode ser reescrito.

Interfaces podem ser substituídas.

Protocolos evoluem.

Mas regras de negócio acumuladas durante quarenta anos representam um patrimônio imenso.

Ali estão milhares de decisões tomadas por especialistas do mercado financeiro, seguros, saúde, governo e logística.

Os CICS Web Services preservam esse conhecimento.

Eles não reinventam a lógica.

Eles a tornam acessível ao mundo moderno.


Dicas para o Programador COBOL Iniciante

✔ Aprenda primeiro o fluxo tradicional do CICS antes de estudar Web Services.

✔ Domine COMMAREA e depois CHANNEL/CONTAINER.

✔ Entenda HTTP, HTTPS e métodos REST.

✔ Saiba a diferença entre JSON e XML.

✔ Estude o papel de WSDL e WSBIND.

✔ Pratique a leitura de copybooks e compreenda como eles representam contratos de dados.

✔ Familiarize-se com utilitários como DFHLS2WS e DFHWS2LS.

✔ Conheça conceitos de segurança como TLS, RACF, autenticação e autorização.

✔ Entenda que a performance de uma API raramente depende apenas do protocolo; consultas Db2, acesso a VSAM e regras de negócio geralmente têm impacto muito maior.

✔ Nunca pense no COBOL como uma tecnologia isolada. Hoje ele faz parte de arquiteturas distribuídas, APIs, microsserviços e soluções em nuvem.


Curiosidades que Impressionam em Entrevistas

  • Muitos aplicativos bancários utilizam APIs REST que terminam em programas COBOL executando em CICS.

  • O mesmo programa COBOL pode atender simultaneamente terminais 3270, filas MQ e Web Services.

  • SOAP continua sendo amplamente utilizado em integrações corporativas críticas devido aos seus contratos formais e padrões de segurança.

  • O uso de APIs permitiu que aplicações escritas há décadas participassem de iniciativas como Open Banking, Open Finance e ecossistemas digitais sem a necessidade de reescrita completa.

  • Em muitos ambientes, um único IBM Z processa milhares de requisições simultâneas com tempos de resposta medidos em milissegundos.


O Arquivo Confidencial Bellacosa 📁

Os velhos investigadores das revistas pulp dos anos 1950 costumavam encerrar seus casos dizendo que "o verdadeiro culpado nunca era quem parecia ser".

Neste caso, o culpado também não é.

Durante anos, disseram que o COBOL era o obstáculo para a inovação. No entanto, a investigação revela outro cenário: o COBOL nunca impediu a transformação digital. O verdadeiro desafio sempre foi criar uma ponte segura entre um patrimônio tecnológico consolidado e as novas formas de consumo de serviços.

Essa ponte recebeu muitos nomes ao longo da história, mas no universo do CICS ela se materializa nos Web Services. Eles permitem que um programa escrito há décadas continue executando exatamente a mesma lógica de negócio, enquanto atende aplicativos móveis, portais Web, plataformas em nuvem e arquiteturas baseadas em APIs.

Da próxima vez que você consultar o saldo pelo celular, comprar uma passagem aérea ou realizar uma transferência bancária, lembre-se deste caso. Em algum lugar, atrás de uma API elegante, de um JSON aparentemente simples e de uma interface moderna, talvez exista um veterano programa COBOL respondendo com a precisão de sempre.

E, se você escutar atentamente o suave zumbido do datacenter em uma madrugada silenciosa, talvez perceba que o maior mistério nunca foi descobrir como o mainframe conversa com o mundo moderno.

O verdadeiro mistério é que ele faz isso tão bem que quase ninguém percebe que ele continua lá, trabalhando incansavelmente, como um detetive das sombras que resolve milhões de casos por dia sem jamais assinar o próprio nome.

terça-feira, 10 de julho de 2018

☕🔥 ANIMES PSICOLÓGICOS — QUANDO O VERDADEIRO MONSTRO NÃO ESTÁ NA TELA… MAS DENTRO DA MENTE

 

Bellacosa Mainframe analisa os animes psicologicos

☕🔥 ANIMES PSICOLÓGICOS — QUANDO O VERDADEIRO MONSTRO NÃO ESTÁ NA TELA… MAS DENTRO DA MENTE

Existe um momento inevitável na vida de quem assiste anime.

Você começa com:

  • luta

  • aventura

  • poderes

  • fantasia

  • comédia

E então, um dia…

aparece um anime que não quer apenas te entreter.

👉 Ele quer te desmontar emocionalmente.

É aí que muita gente descobre o universo dos:

🔥 animes psicológicos.

E diferente do terror tradicional…

o medo aqui não vem do “monstro”.

Vem de:

  • trauma

  • paranoia

  • identidade

  • culpa

  • isolamento

  • obsessão

  • depressão

  • manipulação

  • existência humana


☕ O QUE DEFINE UM ANIME PSICOLÓGICO?

Muita gente pensa que anime psicológico é apenas:

  • triste

  • sombrio

  • violento

Mas isso é superficial.

Anime psicológico verdadeiro mexe com:

🧠 percepção
🧠 realidade
🧠 consciência
🧠 moralidade
🧠 sanidade

Ele força o espectador a pensar:

“E se o problema for a própria mente humana?”


☕🔥 PERFECT BLUE — O COLAPSO DA IDENTIDADE NA ERA DA INTERNET

Vamos começar com uma obra-prima absoluta.

Perfect Blue (1997)

Satoshi Kon criou algo assustadoramente profético.


☕ Sobre o que é?

Uma idol japonesa abandona a carreira musical para virar atriz.

E lentamente:

  • realidade

  • fama

  • perseguição

  • obsessão

  • identidade

começam a se misturar.


☕ O assustador?

🔥 Esse anime antecipou:

  • cultura influencer

  • stalking digital

  • cancelamento

  • obsessão parasocial

  • perda de identidade online

DECADAS antes das redes sociais explodirem.


☕ Bellacosa Mainframe Analysis™

Perfect Blue é como um sistema sem integridade referencial.

Os dados da realidade começam a corromper.

A mente entra em “loop”.

E o espectador também.


☕🔥 SERIAL EXPERIMENTS LAIN — O ANIME QUE PREVIU A INTERNET MODERNA

Talvez um dos animes mais incompreendidos da história.


☕ Lain não é assistido.

Lain é experienciado.


☕ A trama

Uma garota introvertida mergulha numa rede digital chamada:

The Wired

E começa a perder a fronteira entre:

  • virtual

  • físico

  • consciência

  • existência


☕ O que torna isso assustador?

Porque hoje nós realmente vivemos isso.


☕ Redes sociais fizeram exatamente isso

Misturaram:

  • persona digital

  • identidade real

  • validação online

  • existência virtual


☕ Lain previu:

🔥 internet psicológica.


☕🔥 MONSTER — O MAIOR VILÃO NÃO TEM PODERES

Agora chegamos numa obra brutal.

Monster


☕ O anime faz uma pergunta terrível:

“O mal nasce… ou é criado?”


☕ Johan Liebert talvez seja um dos personagens mais assustadores da ficção

Porque ele:

  • não tem magia

  • não tem poderes

  • não tem transformação

Ele apenas entende profundamente a mente humana.


☕ O terror aqui é filosófico

Monster mostra como:

  • trauma

  • manipulação

  • abandono

  • ideologia

podem destruir pessoas.


☕ Bellacosa Mainframe Analysis™

Johan é como um exploit psicológico.

Ele encontra vulnerabilidades emocionais humanas…

e executa ataques silenciosos.


☕🔥 NEON GENESIS EVANGELION — DEPRESSÃO DISFARÇADA DE MECHA

Muita gente começou Evangelion esperando:

🤖 robôs gigantes.

E terminou recebendo:

🧠 colapso existencial.


☕ Evangelion não é sobre EVA

É sobre:

  • solidão

  • abandono

  • medo de rejeição

  • depressão

  • incapacidade de conexão humana


☕ Shinji é um personagem genial justamente porque é humano

Ele não quer “salvar o mundo”.

Ele só quer:

ser aceito.


☕ O anime desmonta emocionalmente o espectador

Especialmente nos episódios finais.


☕🔥 MADE IN ABYSS — O ANIME QUE ENGANOU TODO MUNDO

Visual fofo.

Personagens pequenos.

Estilo inocente.

E então…

🔥 sofrimento absoluto.


☕ Made in Abyss é cruel

Porque transforma curiosidade em punição.


☕ O Abyss funciona quase como:

  • trauma progressivo

  • descida psicológica

  • perda da inocência


☕ Quanto mais fundo…

mais a humanidade se desfaz.


☕ Bellacosa Mainframe Analysis™

O Abyss parece um stack overflow emocional.

Quanto mais você desce…

mais impossível fica retornar intacto.


☕🔥 PARANOIA AGENT — O CAOS SOCIAL EM FORMA DE ANIME

Outro Satoshi Kon.

Outro ataque psicológico.


☕ Aqui o medo é coletivo

Um garoto misterioso começa a atacar pessoas.

Mas lentamente percebemos:

👉 o verdadeiro tema é escapismo.


☕ O anime fala sobre:

  • pressão social

  • ansiedade urbana

  • colapso emocional coletivo

  • fuga psicológica


☕ Parece exagero…

até você olhar o mundo moderno.


☕🔥 DEATH NOTE — O ANIME QUE FEZ TODO MUNDO QUESTIONAR MORALIDADE

Death Note é brilhante porque:

🔥 faz o espectador concordar com um sociopata.


☕ Light Yagami começa parecendo herói.

E lentamente:

  • ego

  • poder

  • controle

  • narcisismo

corrompem completamente sua humanidade.


☕ O anime faz você perceber algo desconfortável

“Talvez qualquer pessoa possa virar um monstro se acreditar que está certa.”


☕🔥 ERGO PROXY — IDENTIDADE, EXISTÊNCIA E O MEDO DE SER HUMANO

Ergo Proxy parece confuso inicialmente.

Mas o núcleo é filosófico.


☕ O anime pergunta:

  • O que é consciência?

  • O que é humanidade?

  • O que define identidade?


☕ Parece cyberpunk.

Mas é quase existencialismo animado.


☕🔥 PAPRIKA — O SONHO COMO HACK DA MENTE

Outro clássico absurdo de Satoshi Kon.


☕ Paprika mistura:

  • sonhos

  • subconsciente

  • realidade

  • memória

até tudo virar caos.


☕ Christopher Nolan claramente bebeu daqui para criar:

🔥 Inception.


☕ Paprika mostra algo assustador

Se sonhos forem invadidos…

a própria realidade mental deixa de existir.


☕🔥 PSYCHO-PASS — QUANDO O SISTEMA DECIDE QUEM VOCÊ É

Esse anime é praticamente:

🔥 RACF + IA + distopia psicológica.


☕ O Sistema Sibyl mede:

  • estabilidade mental

  • risco criminal

  • potencial violento


☕ Parece ficção…

Mas hoje temos:

  • IA preditiva

  • scoring social

  • vigilância algorítmica

  • análise comportamental


☕ Psycho-Pass é assustador porque está ficando possível.


☕🔥 ELFEN LIED — TRAUMA TRANSFORMADO EM VIOLÊNCIA

Muita gente lembra apenas do gore.

Mas Elf Lied é sobre:

  • abuso

  • rejeição

  • isolamento

  • desumanização


☕ O anime pergunta:

“O que acontece quando alguém nunca recebe amor?”


☕🔥 TEXHNOLYZE — O COLAPSO TOTAL DA ESPERANÇA

Talvez um dos animes mais pesados emocionalmente já feitos.


☕ Atmosfera sufocante.

Silêncio constante.

Humanidade decadente.


☕ Não é entretenimento leve.

É quase:

🔥 depressão cyberpunk filosófica.


☕🔥 O QUE TODOS ESSES ANIMES TÊM EM COMUM?

Eles usam:

  • ficção

  • fantasia

  • cyberpunk

  • terror

  • suspense

para falar sobre:

🧠 sofrimento humano.


☕ O verdadeiro terror não é o monstro

É:

  • a solidão

  • a mente

  • o vazio

  • o trauma

  • o medo da existência


☕🔥 POR QUE ESSES ANIMES MARCAM TANTO?

Porque eles não terminam quando o episódio acaba.

Eles ficam:

  • na memória

  • na consciência

  • nas reflexões

  • nas crises existenciais


☕ Alguns literalmente mudam a forma como você vê o mundo

Especialmente:

  • Lain

  • Evangelion

  • Monster

  • Perfect Blue


☕🔥 O MAINFRAME DA MENTE HUMANA

Ao estilo Bellacosa Mainframe:

A mente humana é como um sistema operacional gigantesco.

Ela possui:

  • memória

  • processos

  • corrupção

  • loops

  • falhas

  • proteção

  • logs emocionais

  • traumas persistentes


☕ Alguns animes mostram exatamente isso

👉 o que acontece quando esse sistema começa a falhar.


☕🔥 CONCLUSÃO — O ANIME PSICOLÓGICO NÃO QUER TE ASSUSTAR

Ele quer algo muito mais profundo:

fazer você encarar partes desconfortáveis da própria existência.

E talvez seja por isso que essas obras continuam tão poderosas.

Porque monstros externos podem morrer.

Mas:

🔥 os monstros da mente humana continuam existindo em silêncio.


segunda-feira, 9 de julho de 2018

🔴 A Linha Vermelha Invisível do Destino

 

Bellacosa Mainframe e a linha vermelha do destino

🔴 A Linha Vermelha Invisível do Destino

Quando o amor compila mesmo sem a gente rodar o JOB

Existem mitos que parecem escritos em pergaminho.
Outros parecem vir de sonhos.
E há um terceiro tipo — os que soam como se um programador antigo tivesse deixado um comentário oculto no código-fonte do universo.

No Japão, esse comentário se chama:

赤い糸 — Akai Ito
“A linha vermelha invisível do destino.”


 

É a crença de que duas pessoas destinadas a se encontrar estão ligadas para sempre, por um fio vermelho amarrado ao mindinho.
Ele pode esticar, enrolar, atrasar a execução… mas não quebra jamais.

Hoje vamos destrinchar esse mito com bisturi de historiador, elegância de poeta e precisão cirúrgica de operador de JES2.

Senta.
Que lá vem história — e destino.


📜 Capítulo 1 — Origem: quando deuses eram tecelões e pessoas eram fios

A lenda nasceu na China antiga, migrou para o Japão e se consolidou nos períodos Heian e Edo.

Segundo o folclore, existe um deus chamado Yue Lao, o guardião dos relacionamentos, que passa as noites ligando pessoas por fios invisíveis.
Ele não pergunta, não pede permissão, não negocia SLA. Ele simplesmente conecta.

Essa visão ecoa a filosofia japonesa de 縁 (en) — os laços que definem encontros significativos.

En não é destino cego.
É mais profundo: é a ideia de que existem vínculos que antecedem o momento do encontro.

Como se alguém tivesse atualizado seu catálogo de endereços antes mesmo de você nascer.


❤️ Capítulo 2 — Por que o fio é vermelho?

Porque o vermelho é a cor japonesa da:

  • vida

  • proteção

  • energia vital

  • celebração

E simboliza algo ainda mais profundo: o sangue que conecta gerações, o legado que viaja através do tempo.

É o highlight universal do destino — o chamado “campo vermelho do dataset” que ninguém apaga no masterfile da existência.


🧘‍♂️ Capítulo 3 — A filosofia: destino não é prisão, é encontro

Diferente do fatalismo ocidental, a linha vermelha não significa que existe um único grande amor predestinado.

Significa que existem conexões essenciais, encontros que constroem quem você é:

  • o amigo que muda sua vida

  • a paixão que vira cicatriz ou poesia

  • o mestre que te direciona

  • o amor que te encontra no caos

  • ou alguém que aparece na hora exata, como um comando EXEC que salva o JOB da falha

A linha vermelha é o reconhecimento de que o universo, às vezes, organiza coincidências com precisão suspeita demais para ser acaso.


📺 Capítulo 4 — Cultura pop: os fios vermelhos aparecem em tudo

Se você gosta de animes, já viu o mito disfarçado:

  • Your Name — o cordão vermelho que atravessa o tempo

  • Inuyasha — laços que duram eras

  • Noragami — vínculos entre vivos e espíritos

  • Ano Hana — um destino atrasado, mas inevitável

  • Fruits Basket — conexões kármicas tocando o invisível

O fio vermelho virou um framework narrativo japonês:
onde há amor, há fio; onde há destino, há vermelho.


🧩 Capítulo 5 — O easter-egg do mindinho

Por que o fio está preso ao dedo mínimo?

Porque no Japão medieval, o mindinho era o dedo das promessas profundas.

Daí nasceu o yubikiri (ゆびきり):

“Promessa de mindinho. Se eu quebrar, corto o dedo.”

Pode parecer extremo, mas o Japão sempre soube misturar poesia com intensidade.

O mindinho é o dedo do compromisso.
Logo, o destino se amarra exatamente ali.


Capítulo 6 — Um pouco de história humana também

Na época feudal japonesa, muitos casamentos eram arranjados.
O mito do fio vermelho era uma espécie de conforto emocional:

“Mesmo se eu não te escolher, o destino nos escolheu.”

Ele funcionava como amortecedor espiritual numa sociedade rígida — um lembrete de que o coração encontra caminhos que nem sempre estão no mapa oficial.


🧶 Capítulo 7 — A versão Bellacosa: o mainframe do destino

Imagine que cada pessoa é um JOB rodando com prioridade variável.

Imagine que o universo é o sistema operacional definitivo.

E a linha vermelha?

É a reference link entre duas entidades que precisam se encontrar para que o script da vida compile sem erro.

Ela não apressa nada.
Não força nada.
Não é um IF/THEN; é um evento assíncrono.

Quando a vida achar que é hora, ela puxa o fio.
E o encontro acontece — com uma naturalidade tão precisa que parece obra de um programador genial.


🌌 Conclusão — A poesia final: o fio que nunca dorme

A linha vermelha diz que:

  • há encontros que vêm de outras vidas

  • há pessoas que te encontram mesmo quando você se perde

  • há amores que retornam como edição revisada de si mesmos

  • há conexões que resistem ao tempo, à ausência e à distância

E acima de tudo:

Existe alguém caminhando neste exato momento com o outro lado do seu fio.
Mesmo que vocês ainda não tenham se tocado.
Mesmo que demore.
Mesmo que a linha esteja frouxa, embaraçada ou silenciosa.

O fio é o que lembra ao universo que duas vidas estão programadas para colidir.

Uma hora…
um puxa o outro.

O Mainframe Nunca Foi o Mistério.

Bellacosa Mainframe explora nosso blogspot


CASE BM-1988 • INVESTIGATION OPEN

O Mainframe Nunca Foi o Mistério.

O verdadeiro mistério sempre foi por que tão poucas pessoas conhecem quem mantém o mundo funcionando.

Todos os dias bilhões de transações passam silenciosamente pelos computadores IBM Z. Cartões de crédito, PIX, companhias aéreas, hospitais, seguradoras, bolsas de valores, governos e grandes empresas continuam confiando em tecnologias que atravessaram décadas sem perder sua confiabilidade. Enquanto muitos falam apenas das novidades, este blog investiga a história, explica os bastidores, conecta passado e futuro e transforma conhecimento complexo em algo que qualquer profissional curioso consegue compreender.

> INITIALIZING KNOWLEDGE DATABASE...
> SEARCHING 3.000+ ARTIGOS...
> IBM MAINFRAME DETECTED
> COBOL • CICS • Db2 • VSAM • JCL • IMS • MQ • REXX
> STATUS: READY

👤 Sobre o Autor

Conheça a trajetória de Vagner Renato Bellacosa, IBM Champion, profissional de Mainframe desde 1988, educador, escritor e apaixonado pela história da computação.

Abrir Dossiê

📨 Contato

Sugestões, dúvidas, projetos, consultorias, treinamentos, eventos ou simplesmente um café para conversar sobre tecnologia.

Entrar em Contato

🔒 Privacidade

Entenda como o blog trata dados, cookies, segurança, publicidade, Google AdSense e transparência com os visitantes.

Ler Política

🍪 Cookies

Veja como funcionam cookies, estatísticas, anúncios e tecnologias que ajudam o blog a oferecer uma melhor experiência.

Saiba Mais


☕ Bem-vindo ao Bellacosa Mainframe

Este não é apenas um blog sobre computadores. É uma biblioteca viva sobre IBM Mainframe, COBOL, CICS, Db2, z/OS, história da informática, modernização de aplicações, inteligência artificial, engenharia de software, cultura geek, ficção científica, anime e tecnologia corporativa. Cada artigo procura responder uma pergunta diferente. Cada postagem preserva um conhecimento que poderia desaparecer. Cada visita ajuda a manter viva uma parte importante da história da computação. Se você gosta de descobrir como os sistemas realmente funcionam, acabou de encontrar o seu laboratório de investigação.

Explorar o Blog →

domingo, 8 de julho de 2018

☕💣 OPERADOR, ANTES DE EXISTIR O COBOL EXISTIA A LÓGICA! — O SEGREDO QUE TRANSFORMA APRENDIZES EM MESTRES DO MAINFRAME

 

Bellacosa Mainframe e a logica de programação estruturada para mainframe

☕💣 OPERADOR, ANTES DE EXISTIR O COBOL EXISTIA A LÓGICA! — O SEGREDO QUE TRANSFORMA APRENDIZES EM MESTRES DO MAINFRAME

Por que tantos profissionais aprendem COBOL, mas poucos se tornam realmente programadores?

Existe uma crença muito comum entre iniciantes no universo Mainframe:

"Se eu decorar comandos COBOL, vou aprender a programar."

Mas a realidade é outra.

Um programador COBOL experiente sabe que a linguagem é apenas uma ferramenta.

O verdadeiro diferencial está na lógica.

Quando observamos um sistema bancário executando milhões de transações por dia, um processamento batch consolidando contas correntes ou um programa CICS consultando dados em tempo real, o que realmente está funcionando por trás das telas verdes não é COBOL.

É a lógica.

O COBOL apenas traduz essa lógica para o computador.

Por isso, antes de estudar comandos avançados, VSAM, DB2, MQ ou CICS, é fundamental compreender os pilares da programação.

E curiosamente esses mesmos pilares já existiam muito antes dos computadores modernos.


O que é um algoritmo no mundo Mainframe?

A definição clássica diz que algoritmo é uma sequência finita de passos para resolver um problema.

No Mainframe podemos enxergar um algoritmo como um JOB.

Observe:

Exemplo cotidiano

Preparar café.

  1. Colocar água.

  2. Adicionar pó.

  3. Aquecer.

  4. Coar.

  5. Servir.

Existe uma sequência.

Se invertermos os passos, o resultado não será o esperado.


Exemplo Mainframe

Processar folha de pagamento.

  1. Ler arquivo de funcionários.

  2. Ler tabela salarial.

  3. Calcular salário.

  4. Calcular impostos.

  5. Gerar relatório.

  6. Atualizar arquivo mestre.

Perceba:

Um programa COBOL nada mais é que uma sequência organizada de passos.

Isso é um algoritmo.


O algoritmo invisível que existe em todo JOB

Quando um operador submete um JCL:

//JOB001 JOB ...
//STEP01 EXEC PGM=LEFUNC
//STEP02 EXEC PGM=CALCSAL
//STEP03 EXEC PGM=RELATOR

O JCL é um algoritmo.

Ele determina:

  • O que executar.

  • Em qual ordem.

  • Quais dados utilizar.

  • Qual resultado produzir.

Sem lógica não existe processamento.


O conceito mais importante de toda programação

Todo programa responde a três perguntas:

O que entra?

Input.

O que acontece?

Processamento.

O que sai?

Output.


Exemplo COBOL

Imagine um programa que calcula a média de um aluno.

Entrada:

01 WS-NOTA1 PIC 9(3)V99.
01 WS-NOTA2 PIC 9(3)V99.

Processamento:

COMPUTE WS-MEDIA =
        (WS-NOTA1 + WS-NOTA2) / 2.

Saída:

DISPLAY "MEDIA = " WS-MEDIA.

Observe:

Entrada → Processamento → Saída

Esse modelo está presente em praticamente todos os sistemas Mainframe.


Tipos de dados: os tijolos da programação COBOL

Todo programa trabalha com dados.

No COBOL eles são definidos na DATA DIVISION.


Dados numéricos

Exemplos:

01 WS-IDADE PIC 999.
01 WS-SALARIO PIC 9(7)V99.

Utilizados para:

  • cálculos;

  • somatórios;

  • médias;

  • juros;

  • impostos.


Dados alfanuméricos

Exemplos:

01 WS-NOME PIC X(40).
01 WS-CPF  PIC X(11).

Utilizados para:

  • nomes;

  • documentos;

  • códigos;

  • mensagens.


Dados lógicos no COBOL

COBOL não possui BOOLEAN clássico como linguagens modernas.

Normalmente utilizamos:

88 CLIENTE-ATIVO VALUE 'S'.
88 CLIENTE-INATIVO VALUE 'N'.

Ou:

01 WS-STATUS PIC X.

   88 APROVADO VALUE 'A'.
   88 REPROVADO VALUE 'R'.

Esse recurso é extremamente utilizado em sistemas bancários.


Variáveis: os registradores da aplicação

Uma variável representa uma área de memória.

Exemplo:

01 WS-SALDO PIC S9(9)V99 COMP-3.

Durante a execução:

MOVE 1000 TO WS-SALDO.

Depois:

ADD 500 TO WS-SALDO.

Valor atual:

1500

A variável mudou.

Por isso ela recebe esse nome.


Constantes em COBOL

Valores fixos normalmente são definidos com VALUE.

01 WS-TAXA-JUROS PIC 9V999
   VALUE 0.125.

Ou:

01 WS-PI PIC 9V99999
   VALUE 3.14159.

O conceito é simples:

Uma constante não deve mudar.


MOVE: o comando mais utilizado do COBOL

Na apostila existe o conceito de atribuição.

No COBOL isso ocorre principalmente através do comando MOVE.

Exemplo:

MOVE 100 TO WS-SALDO.

Significa:

"Coloque o valor 100 dentro da variável."

Outro exemplo:

MOVE WS-NOME TO WS-NOME-CLIENTE.

Equivale à atribuição de uma variável para outra.


Entrada e saída de dados no Mainframe

Em linguagens acadêmicas encontramos:

Leia
Escreva

No COBOL encontramos:

READ
WRITE
DISPLAY
ACCEPT


Entrada de dados

Terminal:

ACCEPT WS-NOME.

Arquivo:

READ ARQ-CLIENTES

Saída de dados

Tela:

DISPLAY WS-NOME.

Arquivo:

WRITE REG-SAIDA.

Relatório:

WRITE LINHA-RELATORIO.

Operadores matemáticos no COBOL

O COBOL utiliza verbos muito próximos da linguagem humana.


Soma

ADD A TO B.

Subtração

SUBTRACT A FROM B.

Multiplicação

MULTIPLY A BY B.

Divisão

DIVIDE A INTO B.

Fórmulas complexas

COMPUTE WS-MEDIA =
       (WS-NOTA1 + WS-NOTA2) / 2.

O COMPUTE é um dos comandos mais poderosos da linguagem.


Operadores relacionais

São utilizados para comparar valores.


Igual

IF WS-IDADE = 18

Maior

IF WS-SALDO > 1000

Menor

IF WS-SALDO < 0

Diferente

IF WS-STATUS NOT = 'A'

O poder do IF

Todo sistema bancário depende de decisões.

A decisão é implementada através do IF.


Exemplo

IF WS-SALDO > 0
    DISPLAY "CONTA POSITIVA"
END-IF.

Exemplo bancário

IF WS-LIMITE > WS-VALOR-SAQUE
    PERFORM EFETUA-SAQUE
ELSE
    PERFORM NEGA-SAQUE
END-IF.

Observe:

O programa está tomando decisões.

Isso é lógica.


EVALUATE: o SWITCH/CASE do COBOL

Em outras linguagens existe SWITCH.

No COBOL moderno utilizamos:

EVALUATE WS-STATUS
   WHEN 'A'
      DISPLAY 'ATIVO'
   WHEN 'I'
      DISPLAY 'INATIVO'
   WHEN OTHER
      DISPLAY 'INVALIDO'
END-EVALUATE.

Muito comum em sistemas corporativos.


Estruturas de repetição no COBOL

Um dos conceitos mais importantes da programação.

Imagine um arquivo com 50 milhões de registros.

Como processar tudo?

Com laços de repetição.


PERFORM UNTIL

PERFORM UNTIL EOF = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO EOF
   END-READ

END-PERFORM.

Esse é provavelmente um dos padrões mais encontrados no Mainframe.


O algoritmo clássico de processamento batch

Observe a lógica utilizada em milhares de programas COBOL:

ABRIR ARQUIVOS

LER PRIMEIRO REGISTRO

ENQUANTO NÃO FOR FIM DO ARQUIVO

   PROCESSAR

   LER PRÓXIMO REGISTRO

FIM-ENQUANTO

FECHAR ARQUIVOS

Transformado para COBOL:

OPEN INPUT ARQ-CLIENTES

PERFORM UNTIL EOF = 'S'

   READ ARQ-CLIENTES
      AT END
         MOVE 'S' TO EOF
      NOT AT END
         PERFORM PROCESSA-REGISTRO
   END-READ

END-PERFORM

CLOSE ARQ-CLIENTES.

Esse padrão existe há décadas.

E continua executando boa parte da economia mundial.


A lógica por trás de CICS

Muitos acreditam que CICS é algo completamente diferente.

Mas a lógica é a mesma.

Entrada:

EXEC CICS RECEIVE

Processamento:

IF
EVALUATE
COMPUTE

Saída:

EXEC CICS SEND

Novamente:

Entrada → Processamento → Saída.


O segredo dos grandes programadores COBOL

Os melhores profissionais não decoram comandos.

Eles aprendem a pensar.

Quando recebem uma demanda, primeiro desenham a lógica.

Depois escrevem o código.

Por isso um profissional experiente consegue aprender:

  • COBOL

  • PL/I

  • Natural

  • Java

  • Python

  • C#

Porque a lógica permanece.

A linguagem muda.

O raciocínio não.


Conclusão

Todo sistema Mainframe que processa cartões, PIX, contas correntes, seguros, previdência, telecomunicações ou governo possui a mesma fundação:

Algoritmos.

Variáveis.

Decisões.

Repetições.

Processamento de dados.

O COBOL não é apenas uma linguagem.

Ele é a materialização de uma lógica extremamente bem estruturada, criada para representar regras de negócio de forma clara e confiável.

Quem domina apenas comandos escreve programas.

Quem domina lógica constrói sistemas que sobrevivem décadas.

E talvez esse seja o maior segredo do Mainframe:

Os computadores mudaram.

As telas mudaram.

As linguagens mudaram.

Mas a lógica continua exatamente a mesma desde os primeiros dias da computação.



sábado, 7 de julho de 2018

Blog Analytics : Parte V – Construindo o Bellacosa Blog Doctor Desenvolvendo um Scanner Automático de HTML, SEO e Qualidade para Blogger

 

Bellacosa Mainframe e o blog analytics parte v

☕ Um Café no Bellacosa Mainframe

Blog Analytics : Parte V – Construindo o Bellacosa Blog Doctor

Desenvolvendo um Scanner Automático de HTML, SEO e Qualidade para Blogger

Quando o Feed Atom Deixa de Ser Apenas um Arquivo XML e se Transforma no SYSUDUMP de um Acervo Digital

☕ Um Café no Bellacosa Mainframe

Nas quatro primeiras partes desta série percorremos um caminho que começou com uma suspeita aparentemente pequena e terminou em uma descoberta muito maior.

Primeiro percebemos que o Blogger podia armazenar HTML invisível.

Depois identificamos os resíduos deixados por inteligência artificial, Microsoft Word, Google Docs e outros editores.

Em seguida aprendemos que limpar milhares de posts sem planejamento poderia causar mais problemas do que benefícios.

Por fim, construímos um checklist de auditoria para blogs antigos, tratando um acervo editorial como um sistema crítico que precisa de manutenção preventiva.

Agora chegamos ao ponto em que a teoria precisa virar ferramenta.

Não basta saber que existem resíduos.

Não basta abrir manualmente cada artigo.

Não basta analisar visualmente milhares de páginas.

Precisamos de um scanner.

Um programa capaz de receber o Feed Atom de um blog, percorrer milhares de publicações, interpretar o HTML, aplicar regras de qualidade, calcular indicadores, classificar riscos e produzir um relatório compreensível.

Em outras palavras:

Precisamos construir o Bellacosa Blog Doctor.


O Que é o Bellacosa Blog Doctor?

O Bellacosa Blog Doctor é uma ferramenta de auditoria técnica para Blogger.

Seu objetivo não é editar automaticamente todos os artigos.

Seu objetivo é muito mais importante:

diagnosticar antes de corrigir.

Em ambientes IBM Mainframe, ninguém altera um sistema crítico sem antes reunir evidências.

Primeiro olhamos:

  • logs;

  • dumps;

  • traces;

  • métricas;

  • códigos de retorno;

  • históricos de execução;

  • impactos;

  • dependências.

Somente depois decidimos o que fazer.

O Blog Doctor segue exatamente essa filosofia.

Ele não deve agir como um aspirador de pó cego que remove tudo que parece estranho.

Ele deve funcionar como um laboratório forense digital.

Receber dados.

Analisar.

Classificar.

Explicar.

Priorizar.

Gerar um laudo.


A Filosofia Mainframe Aplicada ao Blogger

Um mainframe não é confiável apenas porque possui hardware robusto.

Ele é confiável porque toda sua operação é baseada em controle, observabilidade e diagnóstico.

Quando um job falha, existem pistas:

  • RC;

  • ABEND;

  • SYSOUT;

  • JESMSGLG;

  • JESYSMSG;

  • CEEDUMP;

  • SYSUDUMP;

  • mensagens do subsistema;

  • registros SMF.

O Blog Doctor deve produzir o equivalente editorial dessas evidências.

Por exemplo:

POST: ABEND sem Mistérios para Programadores COBOL

STATUS GERAL..............ATENÇÃO

HTML......................82
SEO TÉCNICO...............91
ACESSIBILIDADE............76
QUALIDADE EDITORIAL.......94

OCORRÊNCIAS:
- 3 imagens sem ALT
- 1 tabela dentro de parágrafo
- 2 links HTTP
- 4 atributos data-message-id
- heading H3 sem H2 anterior

PRIORIDADE.................MÉDIA
AÇÃO RECOMENDADA...........REVISÃO MANUAL

Esse relatório funciona como um pequeno dump do artigo.

Não diz apenas que existe um problema.

Mostra:

  • onde;

  • qual;

  • quantas vezes;

  • qual gravidade;

  • qual ação recomendada.


A Arquitetura da Ferramenta

Antes de escrever código, precisamos desenhar a arquitetura.

Uma ferramenta de auditoria bem organizada pode ser dividida em cinco camadas.

CAMADA 1 – AQUISIÇÃO
Feed Atom ou Blogger API

CAMADA 2 – NORMALIZAÇÃO
Conversão dos posts para objetos internos

CAMADA 3 – ANÁLISE
HTML, SEO, acessibilidade, conteúdo e metadados

CAMADA 4 – CLASSIFICAÇÃO
Score, gravidade, prioridade e recomendações

CAMADA 5 – RELATÓRIOS
Dashboard, CSV, JSON, tabelas e laudos

Essa separação é fundamental.

Sem ela, o programa rapidamente se transforma em um bloco gigantesco de JavaScript difícil de manter.

No universo mainframe, seria como colocar leitura de arquivo, regra de negócio, banco de dados, impressão e tratamento de erro dentro de uma única SECTION COBOL.

Pode até funcionar.

Mas ninguém gostaria de manter.


Camada 1 – Aquisição dos Dados

O primeiro módulo precisa localizar e carregar os artigos.

Existem duas fontes principais.

Feed Atom

O Feed Atom é excelente para análise porque fornece o conteúdo publicado em formato estruturado.

Ele pode conter:

  • título;

  • data de publicação;

  • data de atualização;

  • categorias;

  • links;

  • HTML completo do artigo.

Exemplo simplificado:

<entry>
  <title>ABEND sem Mistérios</title>
  <published>2026-07-25T20:00:00-03:00</published>
  <category term="COBOL"/>
  <category term="Mainframe"/>
  <content type="html">
    <![CDATA[
      <h2>Introdução</h2>
      <p>Conteúdo...</p>
    ]]>
  </content>
</entry>

O Feed Atom funciona quase como uma unload de banco de dados.

Ele não representa apenas aquilo que aparece visualmente.

Ele revela aquilo que foi armazenado.


Blogger API

A Blogger API fornece dados em JSON.

Isso facilita o processamento porque JavaScript trabalha naturalmente com objetos JSON.

Exemplo:

{
  "title": "ABEND sem Mistérios",
  "published": "2026-07-25T20:00:00-03:00",
  "labels": ["COBOL", "Mainframe"],
  "content": "<h2>Introdução</h2><p>Conteúdo...</p>"
}

Em um projeto mais maduro, o Blog Doctor pode oferecer as duas opções:

  • leitura direta do Feed Atom;

  • leitura da Blogger API.


O Problema da Paginação

Blogs pequenos podem ser lidos em uma única requisição.

Blogs com milhares de posts não.

Tentar carregar quatro mil artigos de uma vez pode gerar:

  • timeout;

  • resposta truncada;

  • consumo elevado de memória;

  • travamento do navegador;

  • falhas de rede;

  • bloqueio temporário.

A solução é processar em lotes.

async function carregarPosts() {
  const lote = 100;
  let inicio = 1;
  const posts = [];

  while (true) {
    const dados = await carregarLote(inicio, lote);

    if (!dados.length) {
      break;
    }

    posts.push(...dados);
    inicio += dados.length;

    if (dados.length < lote) {
      break;
    }
  }

  return posts;
}

Essa lógica lembra um programa batch lendo um arquivo em blocos.

Não importa se existem cem ou dez mil registros.

O processo continua até encontrar o fim.


Camada 2 – Normalização

Os dados recebidos do Feed Atom não devem ser usados diretamente em todas as funções.

Primeiro precisam ser normalizados.

Isso significa converter cada post para um formato interno consistente.

{
  titulo: "ABEND sem Mistérios",
  url: "https://...",
  publicadoEm: Date,
  atualizadoEm: Date,
  html: "<h2>...</h2>",
  texto: "ABEND sem Mistérios...",
  palavras: 1842,
  caracteres: 10920,
  marcadores: ["COBOL", "Mainframe"],
  imagens: [],
  links: [],
  headings: []
}

Esse objeto se transforma no registro mestre da auditoria.

Em COBOL, seria como montar um layout padronizado na WORKING-STORAGE antes de aplicar as regras de negócio.


Convertendo HTML em Texto

Um dos primeiros algoritmos necessários é remover o HTML para obter apenas o conteúdo textual.

function htmlParaTexto(html) {
  const documento = new DOMParser()
    .parseFromString(html, "text/html");

  documento
    .querySelectorAll("script, style, noscript")
    .forEach(elemento => elemento.remove());

  return (documento.body.textContent || "")
    .replace(/\s+/g, " ")
    .trim();
}

Essa função permite calcular:

  • palavras;

  • caracteres;

  • densidade textual;

  • repetições;

  • legibilidade;

  • termos mais usados.


Contando Palavras

A contagem não deve usar apenas:

texto.split(" ")

Esse método falha com:

  • múltiplos espaços;

  • quebras de linha;

  • pontuação;

  • hífens;

  • apóstrofos.

Uma abordagem melhor é usar expressão regular Unicode.

function contarPalavras(texto) {
  const palavras = texto.match(
    /[\p{L}\p{N}][\p{L}\p{N}'’-]*/gu
  );

  return palavras ? palavras.length : 0;
}

O uso de \p{L} ajuda a reconhecer letras acentuadas e outros alfabetos.

Isso é importante em um blog que mistura português, inglês, japonês romanizado, termos técnicos e nomes próprios.


Camada 3 – O Motor de Análise

Aqui está o verdadeiro coração do Bellacosa Blog Doctor.

Cada módulo analisa um aspecto diferente.

MÓDULO HTML
MÓDULO SEO
MÓDULO ACESSIBILIDADE
MÓDULO EDITORIAL
MÓDULO LINKS
MÓDULO IMAGENS
MÓDULO RESÍDUOS
MÓDULO PERFORMANCE

Cada módulo deve produzir ocorrências independentes.

Exemplo:

{
  codigo: "HTML-TABLE-IN-P",
  categoria: "HTML",
  gravidade: "media",
  mensagem: "Tabela encontrada dentro de parágrafo",
  quantidade: 1
}

Scanner de HTML

O scanner de HTML deve procurar estruturas inválidas ou suspeitas.

Tabela dentro de parágrafo

const tabelaEmParagrafo =
  /<p\b[^>]*>\s*<table\b/i.test(html);

Tabela dentro de heading

const tabelaEmHeading =
  /<h[1-6]\b[^>]*>\s*<table\b/i.test(html);

Headings vazios

const headingsVazios = [
  ...documento.querySelectorAll("h1,h2,h3,h4,h5,h6")
].filter(elemento => !elemento.textContent.trim());

Mais de um H1

const quantidadeH1 =
  documento.querySelectorAll("h1").length;

Essas regras parecem simples, mas quando aplicadas a milhares de posts revelam padrões históricos inteiros.


Scanner de Resíduos de IA

Os resíduos deixados por interfaces modernas podem ser identificados por padrões conhecidos.

const residuosIA = [
  /data-message-id\s*=/i,
  /data-message-author-role\s*=/i,
  /data-message-model-slug\s*=/i
];

O algoritmo pode contar cada ocorrência.

function contarPadrao(html, regex) {
  const global = new RegExp(regex.source, regex.flags + "g");
  return (html.match(global) || []).length;
}

Resultado:

data-message-id...............12
data-message-author-role.......4
data-message-model-slug........4

Isso permite identificar não apenas se existe resíduo, mas sua intensidade.


Scanner de Microsoft Word

O Word possui uma assinatura bastante reconhecível.

const possuiWord =
  /\bclass=["'][^"']*\bMso/i.test(html) ||
  /<o:p\b/i.test(html) ||
  /mso-[a-z-]+\s*:/i.test(html);

Também é possível detectar comentários condicionais:

<!--[if gte mso 9]>

Esses resíduos normalmente não quebram a página.

Mas aumentam o tamanho do HTML e tornam a manutenção mais difícil.


Scanner de Google Docs

O Google Docs costuma deixar estruturas mais limpas que o Word, porém pode inserir grande quantidade de spans e estilos inline.

Uma regra simples pode medir densidade de spans.

const spans =
  documento.querySelectorAll("span").length;

const palavras =
  contarPalavras(texto);

const densidadeSpan =
  palavras > 0 ? spans / palavras : 0;

Exemplo:

Palavras..............1.000
Spans...................480
Densidade..............0,48

Uma densidade muito alta pode indicar excesso de formatação.


Análise de Headings

A hierarquia de títulos é essencial para organização semântica.

Um scanner deve verificar:

  • H1 duplicado;

  • H2 ausente;

  • H3 sem H2 anterior;

  • saltos de H2 para H4;

  • headings vazios;

  • headings excessivamente longos.

Algoritmo simplificado:

function analisarHierarquiaHeadings(documento) {
  const headings = [
    ...documento.querySelectorAll("h1,h2,h3,h4,h5,h6")
  ];

  const problemas = [];
  let nivelAnterior = 0;

  headings.forEach(heading => {
    const nivel = Number(heading.tagName.substring(1));

    if (nivelAnterior && nivel > nivelAnterior + 1) {
      problemas.push({
        tipo: "salto-heading",
        de: nivelAnterior,
        para: nivel,
        texto: heading.textContent.trim()
      });
    }

    nivelAnterior = nivel;
  });

  return problemas;
}

Isso funciona como um verificador de estrutura de programa.

É quase um compiler warning editorial.


Scanner de Imagens

Cada imagem deve ser analisada.

const imagens = [
  ...documento.querySelectorAll("img")
];

Para cada uma:

{
  src: imagem.src,
  alt: imagem.getAttribute("alt"),
  title: imagem.getAttribute("title"),
  width: imagem.getAttribute("width"),
  height: imagem.getAttribute("height")
}

Problemas possíveis:

  • ausência de ALT;

  • ALT vazio;

  • URL HTTP;

  • imagem sem dimensões;

  • imagem externa;

  • possível arquivo pesado;

  • imagem duplicada;

  • nome de arquivo genérico.

Exemplo de diagnóstico:

IMG-ALT-MISSING
Gravidade: média
Ocorrências: 3

Scanner de Links

Links quebrados são uma das maiores dívidas técnicas de blogs antigos.

O scanner local pode verificar inicialmente:

  • HTTP;

  • links vazios;

  • href="#";

  • JavaScript no href;

  • links internos;

  • links externos;

  • links duplicados.

const linksHTTP = links.filter(link =>
  /^http:\/\//i.test(link.getAttribute("href") || "")
);

Verificar se uma URL externa realmente responde exige chamadas de rede e pode sofrer limitações de CORS.

Por isso, o Blog Doctor pode classificar a análise em dois níveis:

Nível local

  • estrutura do link;

  • protocolo;

  • domínio;

  • duplicação;

  • consistência.

Nível remoto

  • código HTTP;

  • redirect;

  • página removida;

  • timeout.


Scanner de Conteúdo

O conteúdo também pode ser avaliado.

Indicadores possíveis:

  • quantidade de palavras;

  • tamanho do título;

  • presença de introdução;

  • presença de conclusão;

  • repetição excessiva;

  • parágrafos muito longos;

  • densidade de palavras-chave;

  • excesso de caixa alta;

  • excesso de negrito;

  • excesso de emojis.

Exemplo:

const tituloCurto = titulo.length < 20;
const tituloLongo = titulo.length > 70;
const conteudoCurto = palavras < 300;

Essas regras não devem ser tratadas como leis universais.

Um post curto pode ser perfeitamente válido.

O scanner apenas sinaliza.

A decisão continua sendo humana.


O Índice Técnico de SEO

O Blog Doctor pode calcular uma pontuação de zero a cem.

Exemplo inicial:

Título.........................10
Conteúdo.......................15
Headings.......................10
Imagens........................10
Links internos.................10
Marcadores.....................10
HTML limpo.....................15
Acessibilidade.................10
Estrutura......................10

O algoritmo pode começar com 100 pontos e aplicar penalidades.

function calcularSEO(post) {
  let score = 100;

  if (post.titulo.length < 20) {
    score -= 7;
  }

  if (post.palavras < 300) {
    score -= 15;
  }

  if (post.imagensSemAlt > 0) {
    score -= Math.min(12, post.imagensSemAlt * 3);
  }

  if (post.semLinksInternos) {
    score -= 8;
  }

  if (post.residuoIA) {
    score -= 6;
  }

  return Math.max(0, score);
}

Esse índice não mede posição no Google.

Ele mede qualidade técnica estimada.

É semelhante a uma métrica de saúde.

Um servidor pode estar funcionando e ainda apresentar alertas.

Um artigo pode estar indexado e ainda possuir problemas técnicos.


Gravidade e Prioridade

Nem todo problema merece a mesma atenção.

O Blog Doctor deve separar gravidade de prioridade.

Gravidade

Refere-se ao impacto técnico.

BAIXA
MÉDIA
ALTA
CRÍTICA

Prioridade

Refere-se à ordem de correção.

Um problema tecnicamente médio pode ter prioridade alta se aparecer em centenas de posts.

Exemplo:

Problema........Imagem sem ALT
Gravidade.......Média
Ocorrências.....1.240
Prioridade......Alta

Outro exemplo:

Problema........Resíduo data-message-id
Gravidade.......Baixa
Ocorrências.....3
Prioridade......Baixa

Essa distinção evita pânico.


A Matriz de Risco

Podemos criar uma matriz simples.

                 POUCOS POSTS   MUITOS POSTS

BAIXO IMPACTO       BAIXA          MÉDIA
MÉDIO IMPACTO       MÉDIA          ALTA
ALTO IMPACTO        ALTA           CRÍTICA

Em JavaScript:

function calcularPrioridade(gravidade, ocorrencias) {
  const peso = {
    baixa: 1,
    media: 2,
    alta: 3,
    critica: 4
  };

  const volume =
    ocorrencias > 500 ? 3 :
    ocorrencias > 50 ? 2 : 1;

  const resultado = peso[gravidade] + volume;

  if (resultado >= 6) return "crítica";
  if (resultado >= 5) return "alta";
  if (resultado >= 3) return "média";
  return "baixa";
}

Geração de Relatórios

Uma ferramenta sem relatório é apenas um conjunto de funções.

O Blog Doctor precisa transformar dados técnicos em informação útil.

Ele pode produzir quatro tipos de saída.

Dashboard

Indicadores visuais:

Posts analisados.............4.018
HTML saudável................3.912
Posts com alerta................89
Posts críticos..................17
SEO técnico médio..............92
Imagens sem ALT................243
Links HTTP......................81
Resíduos de IA..................14

Relatório por artigo

TÍTULO: Data Division sem Mistérios

URL: https://...

PALAVRAS..................1.846
IMAGENS.......................4
LINKS INTERNOS................3
MARCADORES....................8

SEO TÉCNICO..................94

ALERTAS:
- 1 imagem sem ALT
- 1 link HTTP

CSV

O CSV permite abrir os resultados no Excel ou LibreOffice.

Colunas possíveis:

Título
URL
Data
Palavras
Caracteres
Marcadores
Imagens
Imagens sem ALT
Links internos
Resíduos IA
Resíduos Word
SEO Score
Prioridade

JSON

O JSON é ideal para integração futura.

{
  "blog": "Bellacosa Mainframe",
  "dataAuditoria": "2026-07-26",
  "posts": [
    {
      "titulo": "ABEND sem Mistérios",
      "score": 92,
      "prioridade": "media",
      "ocorrencias": []
    }
  ]
}

A Tela de Progresso

Em um blog com milhares de posts, o usuário precisa saber que o sistema continua funcionando.

Carregando lote 12...

Posts recebidos........1.200
Posts analisados.......1.175
Palavras processadas...1.832.411

[██████████░░░░░░░░░░] 29%

Essa barra não é apenas estética.

Ela reduz a ansiedade e ajuda a identificar travamentos.

Em sistemas batch, o equivalente seria acompanhar o job no SDSF.


Cache e IndexedDB

Reanalisar quatro mil posts em toda visita é desperdício.

O navegador pode guardar os resultados localmente usando IndexedDB.

Arquitetura:

Primeira execução
Feed → análise → IndexedDB

Próxima execução
IndexedDB → dashboard

Atualização
Buscar apenas posts recentes

Isso transforma o painel em uma aplicação muito mais rápida.


Processamento Incremental

Em vez de reler o blog inteiro, podemos guardar a data da última análise.

{
  ultimaAtualizacao: "2026-07-26T23:10:00-03:00"
}

Na próxima execução, o sistema procura apenas artigos publicados ou atualizados depois dessa data.

É o equivalente editorial de um processamento incremental.

Muito semelhante a um batch que lê apenas os registros alterados.


Web Workers

Analisar milhões de palavras pode travar a interface.

Uma solução futura é usar Web Workers.

O Worker executa o processamento em uma thread separada.

const worker = new Worker("blog-doctor-worker.js");

worker.postMessage(posts);

worker.onmessage = evento => {
  atualizarDashboard(evento.data);
};

Assim, a interface continua respondendo enquanto a análise ocorre.


A Implementação Mínima

Uma primeira versão funcional do Blog Doctor precisa apenas de cinco componentes.

1. Leitor do Feed
2. Normalizador
3. Scanner de HTML
4. Calculador de Score
5. Gerador de tabela

Fluxo:

async function executarAuditoria() {
  const entradas = await carregarTodosOsPosts();

  const posts = entradas.map(normalizarPost);

  const auditados = posts.map(post => {
    const ocorrencias = analisarPost(post);
    const score = calcularScore(post, ocorrencias);

    return {
      ...post,
      ocorrencias,
      score
    };
  });

  gerarRelatorio(auditados);
}

Essa função representa o coração do sistema.


Estrutura de uma Ocorrência

Todas as regras devem produzir o mesmo formato.

{
  codigo: "IMG-ALT-MISSING",
  categoria: "Acessibilidade",
  gravidade: "media",
  quantidade: 2,
  mensagem: "Duas imagens não possuem texto alternativo",
  recomendacao: "Adicionar ALT descritivo"
}

Essa padronização torna possível:

  • ordenar;

  • filtrar;

  • exportar;

  • calcular score;

  • gerar relatórios;

  • criar gráficos.


Criando um Catálogo de Regras

As regras podem ficar em uma lista.

const regras = [
  {
    codigo: "HTML-AI-RESIDUE",
    categoria: "HTML",
    gravidade: "baixa",
    testar(post) {
      return /data-message-id/i.test(post.html);
    },
    mensagem: "Resíduo de interface de IA encontrado"
  },
  {
    codigo: "IMG-ALT-MISSING",
    categoria: "Acessibilidade",
    gravidade: "media",
    testar(post) {
      return post.imagensSemAlt > 0;
    },
    mensagem: "Imagem sem ALT"
  }
];

Depois, o motor executa todas.

function executarRegras(post) {
  return regras
    .filter(regra => regra.testar(post))
    .map(regra => ({
      codigo: regra.codigo,
      categoria: regra.categoria,
      gravidade: regra.gravidade,
      mensagem: regra.mensagem
    }));
}

Essa arquitetura facilita adicionar novas verificações sem alterar o restante do programa.


O Equivalente ao Return Code

No mainframe, um job pode terminar com:

RC=0000
RC=0004
RC=0008
RC=0012
RC=0016

O Blog Doctor pode adotar uma lógica semelhante.

BDC0000 – Post saudável
BDC0004 – Alerta leve
BDC0008 – Revisão recomendada
BDC0012 – Problema grave
BDC0016 – Conteúdo crítico

Exemplo:

BDC0008
Imagem sem ALT e heading inconsistente

Isso adiciona identidade à ferramenta e facilita a leitura dos relatórios.


Mensagens no Estilo Mainframe

A ferramenta pode gerar mensagens padronizadas.

BBDHTML001W TABLE FOUND INSIDE PARAGRAPH
BBDSEO004W INTERNAL LINK NOT FOUND
BBDACC002E IMAGE WITHOUT ALT ATTRIBUTE
BBDIA001I AI INTERFACE METADATA DETECTED
BBDDOC003W MICROSOFT WORD RESIDUE FOUND

Legenda:

I – Information
W – Warning
E – Error
S – Severe

Além de divertido, isso cria consistência.


O Dashboard Final

Imagine a tela principal.

┌─────────────────────────────────────────┐
│ BELLA COSA BLOG DOCTOR                  │
│ BLOG HEALTH MONITOR                     │
├─────────────────────────────────────────┤
│ Posts.........................4.018     │
│ Score médio.....................94      │
│ Alertas.........................126     │
│ Críticos.........................12     │
├─────────────────────────────────────────┤
│ HTML   ████████████████ 96              │
│ SEO    ███████████████  92              │
│ A11Y   ██████████████   88              │
│ LINKS  ███████████████  91              │
└─────────────────────────────────────────┘

Abas:

  • visão geral;

  • HTML;

  • SEO;

  • acessibilidade;

  • imagens;

  • links;

  • resíduos;

  • posts;

  • exportação.


O Que Não Deve Ser Automatizado

Uma ferramenta madura também precisa saber seus limites.

O Blog Doctor não deve:

  • reescrever automaticamente milhares de posts;

  • remover tags sem confirmação;

  • alterar URLs;

  • trocar títulos;

  • apagar marcadores;

  • corrigir links externos de forma cega;

  • publicar alterações sem backup.

Ele deve diagnosticar.

A correção pode ser manual ou assistida.

Mas sempre controlada.


Auditoria Não é Limpeza

Essa distinção é fundamental.

AUDITORIA
Descobre e classifica

LIMPEZA
Altera o conteúdo

Misturar as duas etapas é perigoso.

No mainframe, primeiro analisamos o dump.

Depois corrigimos o programa.

Não alteramos a memória do dump esperando que o sistema volte a funcionar.


O Bellacosa Blog Doctor como Projeto Real

O projeto pode evoluir em versões.

Versão 0.1

  • leitura de 100 posts;

  • contagem de palavras;

  • posts por ano.

Versão 0.5

  • paginação completa;

  • imagens;

  • links;

  • headings.

Versão 1.0

  • scanner HTML;

  • scanner SEO;

  • dashboard;

  • CSV.

Versão 2.0

  • IndexedDB;

  • processamento incremental;

  • mapa de calor;

  • evolução dos marcadores.

Versão 3.0

  • Web Workers;

  • auditoria remota de links;

  • relatórios JSON;

  • comparação entre auditorias.

Versão 4.0

  • sugestões de correção;

  • diff de HTML;

  • histórico de qualidade;

  • integração com Search Console.


Comparando Auditorias

Uma das funções mais poderosas será comparar dois momentos.

AUDITORIA 1 – JULHO/2026
Score geral.................88
HTML inválido...............49
Imagens sem ALT............312

AUDITORIA 2 – OUTUBRO/2026
Score geral.................94
HTML inválido...............11
Imagens sem ALT.............87

Isso permite medir evolução real.

Não apenas sensação.


O Histórico de Saúde

Cada auditoria pode ser salva.

{
  data: "2026-07-26",
  posts: 4018,
  score: 92,
  problemas: {
    html: 49,
    imagens: 312,
    links: 87
  }
}

Depois criamos um gráfico.

Julho...........88
Agosto..........90
Setembro........92
Outubro.........94

Esse é o verdadeiro conceito de evolução técnica.


O RMF Editorial

No z/OS, o RMF ajuda a observar recursos do sistema.

O Bellacosa Blog Doctor pode ser visto como um RMF editorial.

Em vez de medir:

  • CPU;

  • memória;

  • I/O;

  • canais;

  • dispositivos.

Ele mede:

  • HTML;

  • palavras;

  • imagens;

  • links;

  • headings;

  • marcadores;

  • qualidade;

  • acessibilidade.

O objetivo é o mesmo.

Transformar um sistema invisível em algo observável.


Um Scanner para Décadas de História

Um blog antigo não é apenas um conjunto de páginas.

É um sistema que atravessou:

  • mudanças de layout;

  • troca de editores;

  • novas tecnologias;

  • alterações de SEO;

  • migrações;

  • modismos;

  • ferramentas;

  • plataformas;

  • estilos de escrita.

O Blog Doctor permite enxergar essas camadas.

Um artigo de 2012 pode ter HTML completamente diferente de um artigo de 2026.

E isso não é necessariamente ruim.

É história.

O scanner não serve apenas para encontrar defeitos.

Ele também ajuda a compreender a evolução do acervo.


Conclusão

Construir o Bellacosa Blog Doctor significa aplicar ao universo editorial os mesmos princípios que tornaram o IBM Mainframe uma das plataformas mais confiáveis da história da computação.

Observabilidade.

Padronização.

Diagnóstico.

Controle.

Mensuração.

Rastreabilidade.

A ferramenta começa lendo um simples Feed Atom.

Depois converte cada post em uma estrutura organizada.

Em seguida executa algoritmos de análise.

Detecta resíduos.

Avalia HTML.

Examina imagens.

Verifica headings.

Conta palavras.

Classifica problemas.

Calcula scores.

Gera relatórios.

E transforma milhares de páginas dispersas em um sistema mensurável.

Essa talvez seja a maior evolução de toda a série.

No início queríamos apenas descobrir algumas tags invisíveis.

Agora estamos projetando uma plataforma de auditoria capaz de examinar décadas de produção digital.

O Feed Atom deixou de ser apenas um arquivo XML.

Virou dump.

Virou log.

Virou histórico.

Virou matéria-prima para inteligência editorial.

E o Bellacosa Blog Doctor deixa de ser apenas uma ideia curiosa.

Ele se transforma em uma ferramenta de engenharia.

Uma ferramenta que não promete milagres.

Não apaga tudo automaticamente.

Não substitui o julgamento humano.

Mas faz aquilo que as melhores ferramentas de diagnóstico sempre fizeram:

mostra a verdade antes que alguém toque em produção.

Porque, seja em um Data Center IBM ou em um blog com milhares de artigos, a regra continua sendo a mesma:

Primeiro diagnostique. Depois corrija. E nunca altere aquilo que você ainda não compreendeu.

🔎 CSI BLOGSPOT · ARQUIVO DE EVIDÊNCIAS

Blog Analytics: A Investigação Completa

Seis capítulos sobre auditoria de HTML, resíduos invisíveis, limpeza segura, checklist técnico e construção do Bellacosa Blog Doctor.

6 relatórios2018HTML · SEO · Blogger
CASE FILE 01

Blog Analytics — Parte I

Como descobrir evidências invisíveis no HTML de um blog antigo.

HTMLAuditoriaBlogspot
CASE FILE 02

Blog Analytics — Parte II

Os resíduos invisíveis deixados por editores, Word, IA e cópias antigas.

ResíduosWord HTMLIA
CASE FILE 03

Blog Analytics — Parte III

Como limpar milhares de posts sem destruir o acervo editorial.

LimpezaBackupQualidade
CASE FILE 04

Blog Analytics — Parte IV

Checklist de auditoria para blogs antigos e acervos com anos de história.

ChecklistSEO TécnicoAuditoria
CASE FILE 05

Blog Analytics — Parte V

Construindo o Bellacosa Blog Doctor e seu scanner automático.

Blog DoctorScannerJavaScript
CASE FILE 06

Blog Analytics — Parte VI

Criando o motor de regras, scores, prioridades e códigos de retorno.

Motor de RegrasScoreMainframe

Índice textual da série Blog Analytics

Esta série investiga a saúde técnica de blogs antigos no Blogger, cobrindo auditoria de HTML, resíduos de editores, SEO técnico, acessibilidade, limpeza segura, diagnóstico automatizado e motores de regras.

  1. Blog Analytics Parte I — Como descobrir evidências invisíveis
  2. Blog Analytics Parte II — Os resíduos invisíveis do HTML
  3. Blog Analytics Parte III — Como limpar com segurança
  4. Blog Analytics Parte IV — Checklist de auditoria
  5. Blog Analytics Parte V — Construindo o Bellacosa Blog Doctor
  6. Blog Analytics Parte VI — Criando o motor de regras
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...