☕ 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

terça-feira, 5 de outubro de 2010

🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe ☕🔥

 

Bellacosa Mainframe explica o JSON


🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe ☕🔥

“Enquanto muita gente ainda pensava em arquivos texto… o JSON já estava preparando o planeta para microserviços, APIs e integração global.”


🚀 Introdução — O Formato Que Conquistou o Mundo

Se existe algo que une JavaScript, Python, Java, Node.js, Kubernetes, APIs REST, Open Banking, cloud e até o z/OS… esse algo é o JSON.

Sim…

Aquele bloco aparentemente simples:

{
"cliente": "BELLACOSA",
"conta": 12345,
"saldo": 9999.99
}

Hoje parece trivial.

Mas o impacto do JSON na computação foi monstruoso.

Ele virou:

  • o idioma oficial das APIs,
  • a “cola” da internet moderna,
  • o padrão universal de troca de dados,
  • e uma das maiores revoluções silenciosas da computação corporativa.

E o mais curioso?

O JSON nasceu de forma extremamente simples… quase como um “truque elegante” dentro do JavaScript.


🧠 Quem Criou o JSON?

O JSON foi criado por:

👨 Douglas Crockford

Programador, arquiteto de software e evangelista JavaScript.


📅 Data de Criação

O JSON começou a ganhar forma por volta de:

📌 2001

E foi oficialmente popularizado entre:

📌 2002–2005


🌍 O Problema Que o JSON Resolveu

Antes do JSON, integração era quase sempre baseada em:

  • XML
  • CSV
  • Arquivos posicionais
  • Protocolos binários
  • EDI
  • Mensagens proprietárias

O problema?

Tudo era:

  • pesado,
  • verboso,
  • lento,
  • difícil de ler,
  • difícil de debugar.

Exemplo de XML:

<cliente>
<nome>BELLACOSA</nome>
<saldo>9999.99</saldo>
</cliente>

Agora compare com JSON:

{
"nome": "BELLACOSA",
"saldo": 9999.99
}

Menos ruído.
Mais legibilidade.
Mais velocidade.
Mais simplicidade.

E o mercado enlouqueceu.


⚡ O Grande Segredo do JSON

O JSON nasceu inspirado diretamente nos objetos JavaScript.

Na prática:

var cliente = {
nome: "BELLACOSA",
saldo: 9999.99
}

Douglas Crockford percebeu:

“E se isso virar um formato universal de troca de dados?”

E virou.


🔥 O JSON Explodiu Com as APIs REST

Quando APIs REST começaram a dominar o mercado…

o JSON virou praticamente obrigatório.

Porque:

  • era leve,
  • rápido,
  • fácil de parsear,
  • perfeito para internet,
  • amigável para humanos.

Resultado?

O XML começou a perder espaço rapidamente.


☕ O Mainframe Não Ficou de Fora

Aqui começa a parte interessante para o mundo COBOL.

Muita gente achava:

“Mainframe nunca vai falar JSON.”

Erro histórico.

Hoje o z/OS conversa JSON o tempo inteiro:

  • APIs REST
  • z/OS Connect
  • CICS Web Services
  • MQ
  • Kafka
  • Open Banking
  • Microsserviços
  • Cloud híbrida

O JSON virou peça fundamental da modernização mainframe.


🧠 COBOL + JSON = O Casamento Corporativo Moderno

A IBM percebeu rapidamente:

Se o mainframe quisesse continuar reinando…
precisaria falar JSON nativamente.

E então vieram recursos modernos como:

📌 JSON PARSE

e

📌 JSON GENERATE

no Enterprise COBOL.


🚀 Exemplo COBOL Moderno Com JSON

Gerando JSON

IDENTIFICATION DIVISION.
PROGRAM-ID. GERJSON.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 CLIENTE.
05 NOME PIC X(20) VALUE 'BELLACOSA'.
05 SALDO PIC 9(5)V99 VALUE 99999.99.

01 JSON-SAIDA PIC X(200).

PROCEDURE DIVISION.

JSON GENERATE JSON-SAIDA
FROM CLIENTE

DISPLAY JSON-SAIDA.

STOP RUN.

Saída:

{"NOME":"BELLACOSA","SALDO":99999.99}

🔥 Parsing JSON no COBOL

Recebendo API REST

JSON PARSE JSON-ENTRADA
INTO CLIENTE

Isso foi revolucionário no z/OS.

Porque eliminou:

  • parsers manuais,
  • tratamentos absurdos,
  • lógica artesanal,
  • conversões complexas.

🧠 O Que Tornou o JSON Tão Poderoso?

📌 1. Legibilidade Humana

Até operador consegue entender.


📌 2. Estrutura Hierárquica

Permite:

  • objetos,
  • listas,
  • arrays,
  • árvores complexas.

📌 3. Independência de Linguagem

Funciona em:

  • COBOL
  • Java
  • Python
  • Go
  • Node.js
  • Rust
  • RPG
  • PL/I

📌 4. Perfeito Para APIs

JSON praticamente virou:

“o TCP/IP da integração moderna.”


⚠️ Desvantagens do JSON

Nem tudo são flores.


❌ 1. Sem Tipagem Forte

JSON puro não define:

  • decimal fixo,
  • packed decimal,
  • COMP-3,
  • datas reais.

Isso gera problemas em integrações financeiras.


❌ 2. Overhead de Texto

JSON é texto.

Protocolos binários podem ser mais rápidos.


❌ 3. Segurança

Parsing inseguro pode causar:

  • injection,
  • payload malicioso,
  • consumo excessivo de memória.

❌ 4. Precisão Numérica

Problema clássico:

  • valores financeiros,
  • arredondamentos,
  • IEEE floating point.

O mainframe sofre muito menos disso graças ao decimal packed.


🔥 Curiosidades Históricas

☕ JSON NÃO É Linguagem

Apesar do nome:

JavaScript Object Notation

JSON NÃO é uma linguagem de programação.

É apenas um formato de dados.


☕ O JSON Virou Padrão Oficial

RFC oficial:

📌 RFC 8259


☕ XML Dominava Absolutamente

Antes do JSON:

  • SOAP,
  • WSDL,
  • XML Schema,
  • namespaces,
  • tags gigantescas.

Parecia um ritual mágico corporativo.

JSON chegou como uma motosserra.


💣 Easter Egg Histórico

Douglas Crockford chegou a remover referências perigosas do JavaScript porque:

📌 JSON podia executar código involuntariamente

No começo muita gente fazia:

eval(json)

Isso virou um pesadelo de segurança.

Daí nasceram parsers seguros.


🚀 JSON no Mundo Mainframe Moderno

Hoje o JSON está em todo lugar no z/OS:

TecnologiaUso
z/OS ConnectAPIs REST
CICSWeb Services
IMSIntegração moderna
MQMensageria
KafkaStreaming
Db2 RESTAPIs corporativas
Open BankingPayloads financeiros
Cloud híbridaMicrosserviços



🔥 O JSON Mudou o Papel do Programador COBOL

Antigamente:

  • COBOL manipulava arquivos,
  • VSAM,
  • copybooks,
  • EBCDIC.

Hoje o COBOL moderno:

  • consome APIs,
  • gera REST,
  • fala HTTP,
  • troca JSON,
  • integra cloud,
  • conversa com Kubernetes.

O programador COBOL virou:

engenheiro de integração corporativa.


☕ Comparação Filosófica: JSON vs Copybook COBOL

Curiosamente…

JSON lembra MUITO a ideia dos copybooks.

Veja:

Copybook

01 CLIENTE.
05 NOME PIC X(20).
05 SALDO PIC 9(5)V99.

JSON

{
"NOME": "BELLACOSA",
"SALDO": 99999.99
}

Ambos descrevem estrutura de dados.

A diferença?

O JSON atravessa internet, nuvem e APIs.


🧠 O Verdadeiro Motivo do Sucesso do JSON

Não foi tecnologia.

Foi simplicidade.

O JSON venceu porque:

  • humanos entendem,
  • programadores gostam,
  • APIs adoram,
  • clouds dependem,
  • empresas inteiras padronizaram nele.

💣 Conclusão — O JSON Virou a “Nova Linguagem Universal”

O JSON não matou o COBOL.

Na verdade…

Ele ajudou o COBOL a sobreviver à era cloud.

Hoje o mainframe continua relevante porque aprendeu:

  • REST,
  • APIs,
  • microsserviços,
  • containers,
  • integração moderna,
  • e principalmente…
  • JSON.

E talvez essa seja a maior ironia da computação:

O formato que nasceu no JavaScript acabou ajudando o z/OS a continuar dominando o coração financeiro do planeta.


☕ Frase Final no Estilo Bellacosa Mainframe

“O COBOL continua processando bilhões… mas agora conversa com o mundo em JSON.” 🔥🚀

 

segunda-feira, 4 de outubro de 2010

SMP/E for z/OS Workshop : LIST & REPORT Commands

 

Bellacosa Mainframe apresenta SMP/E List and Report Commands

SMP/E for z/OS Workshop

ACCEPT Processing – LIST & REPORT Commands

Quando olhar o CSI é tão importante quanto instalar o código

Instalar SYSMOD qualquer um instala.
Agora… saber exatamente o que está instalado, onde, por quê e com qual dependência
👉 isso separa operador de System Programmer.

É aqui que entram os comandos LIST e REPORT.


LIST Command

Abrindo o CSI como quem abre o capô do sistema

O comando LIST é o bisturi do SMP/E.
Ele não interpreta, não deduz, não opina.
Ele mostra os fatos gravados no CSI.

📌 O LIST pode extrair informações de:

  • Global Zone

  • Target Zone

  • Distribution Zone

  • SMPPTS

  • SMPLOG

  • SMPSCDS

💡 Easter egg #1

Se você confia mais na memória do que no LIST,
o CSI vai te humilhar em algum momento.


Boundary: o detalhe que separa sucesso de confusão

Antes de usar LIST, você define o boundary:

  • Global Zone → acesso a SMPPTS

  • Zona com DDDEF do SMPLOG

  • Target Zone associada ao SMPSCDS

  • Ou tudo de uma vez com:

ALLZONES

⚠️ ALLZONES lista tudo que existe, não tudo que você quer ver.

💡 Easter egg #2

ALLZONES às 3 da manhã
é como dar SELECT * em produção.


O que dá pra listar no Global Zone

Com LIST você pode ver:

  • OPTIONS

  • UTILITIES

  • DDDEFs

  • FMIDSETs

  • ZONESETs

  • SYSMOD entries

  • MCS entries do SMPPTS

  • HOLDDATA (++HOLD)

HOLDDATA com lupa

Você pode filtrar por:

  • HOLDERROR

  • HOLDSYSTEM

  • HOLDUSER

E ainda combinar com SYSMOD específico.

📌 Se combinar filtros demais, o SMP/E só lista
entradas que satisfaçam todos.


Filtros avançados (onde mora o poder)

LIST aceita os mesmos refinamentos do APPLY/ACCEPT:

  • SOURCEID

  • EXSRCID

  • FORFMID

  • XZLMOD

  • XZLMODP

  • XREF

👉 Ideal para:

  • Debug de dependência

  • Auditoria

  • Pós-migração

  • Comparação entre ambientes

💡 Easter egg #3

SOURCEID bem usado
vale mais que planilha paralela.


LIST em Target e Distribution Zones

Além do básico, você pode listar:

  • TARGETZONE definition

  • DLIBZONE definition

  • DDDEFs

  • ELEMENT entries:

    • MOD

    • MAC

    • SRC

    • JAR

    • HFS

  • LMOD entries

SYSMOD entries com status

Você pode filtrar por:

  • ERROR

  • SUP (superseded)

  • NOSUP

  • RESTORE

  • NOAPPLY

  • NOACCEPT

  • BYPASS

  • DELETE

📌 SUP e NOSUP são mutuamente exclusivos.

💡 Easter egg #4

SYSMOD em ERROR não é bug
é aviso ignorado.


LIST LOG e BACKUP

  • LIST LOG → conteúdo do SMPLOG

    • Total ou por intervalo de data

  • LIST BACKUP → conteúdo do SMPSCDS

    • Tudo ou por SYSMOD específico

👉 LIST é o comando ideal para auditoria forense do SMP/E.


LIST vs DIALOG QUERY

LIST = dados brutos
QUERY = visão amigável

Quando a coisa aperta…
LIST sempre vence.


REPORT Command

Quando você precisa que o SMP/E pense por você

Se o LIST mostra,
o REPORT analisa.

Ele cruza zonas, dependências, FMIDs, SOURCEIDs e HOLDs
e ainda gera comandos prontos.

📌 REPORT é o SMP/E dizendo:

“relaxa, eu faço a correlação.”


REPORT CROSSZONE

Dependência entre produtos e zonas

Usado para responder:

“Instalei isso aqui… quebrou quem?”

Requisitos:

  • ZONESET obrigatório

  • Pode limitar por:

    • FMID

    • ZONE

O relatório mostra:

  • Dependências cruzadas

  • SYSMODs faltantes

  • Se já foram RECEIVED

  • Quem causou a dependência

👉 E ainda gera comandos SMP/E no SMPPUNCH

NOPUNCH

se você não quiser os comandos.

💡 Easter egg #5

SMPPUNCH esquecido
vira APPLY acidental.


REPORT ERRSYSMODS

Quando o passado volta pra cobrar

Identifica SYSMODs que:

  • Já foram instalados

  • Mas agora estão em ERROR HOLD

Pode analisar:

  • Global Zone

  • Target Zone

  • Distribution Zone

Filtros:

  • Data inicial / final

  • FMID

O relatório mostra:

  • SYSMOD afetado

  • Reason ID

  • Quem resolve

  • ++HOLD completo

💡 Easter egg #6

ERROR HOLD não some
só muda de lugar.


REPORT SOURCEID

Quem veio de onde?

Descobre:

  • Quais SOURCEIDs existem

  • Quais SYSMODs usam cada um

Com ou sem filtro por SYSMOD.

👉 Excelente para:

  • FIXCAT

  • Hardware novo

  • Coexistência

  • Migração de release


REPORT SYSMODS

Comparação entre zonas

Usado para:

  • Validar ambientes

  • Comparar releases

  • Checar desvio de serviço

Parâmetros:

  • INZONE

  • COMPAREDTO

Resultado:

  • O que existe em uma zona

  • E não existe na outra

  • Com comandos prontos para corrigir

💡 Easter egg #7

Ambiente “igual” sem REPORT
é fé, não evidência.


REPORT MISSINGFIX (FIXCAT)

Adeus PSP Bucket manual

Disponível a partir do SMP/E 3.6.

Identifica:

  • APARs faltantes

  • Por categoria FIXCAT

  • Para hardware, software e coexistência

Mostra:

  • FIXCAT

  • APAR

  • PTF corretivo

  • Dependências

  • Problemas de HOLD

📌 Dois blocos:
1️⃣ Missing fixes
2️⃣ Resolving SYSMODs em erro

💡 Easter egg #8

FIXCAT bem usado
economiza fim de semana inteiro.


Bellacosa Summary – em poucas linhas

LIST mostra o que existe
REPORT explica o impacto
SMPPUNCH sugere a correção
Você decide se confia


Checklist Bellacosa – LIST & REPORT

✔ LIST antes de APPLY
✔ REPORT antes de migrar
✔ FIXCAT sempre atualizado
✔ SOURCEID bem definido
✔ SMPPUNCH revisado
✔ LOG nunca ignorado


Conclusão

Quem domina LIST e REPORT:

  • Não instala no escuro

  • Não depende de planilha

  • Não descobre erro em produção

  • Não briga com auditor

💡 Easter egg final

O SMP/E sempre soube a verdade.
Você só precisava perguntar direito.

domingo, 3 de outubro de 2010

💽 Tracks, Cilindros e DASD no IBM Mainframe

Bellacosa Mainframe Storage e DASD 3390



💽 Tracks, Cilindros e DASD no IBM Mainframe

Arquitetura, não nostalgia

“O mainframe não mede storage em tracks e cilindros porque é antigo.
Ele faz isso porque sabe exatamente o que está fazendo.”


1️⃣ A origem da filosofia: quando hardware importava (e ainda importa)

Desde os primórdios do IBM System/360 (1964), o mainframe foi projetado com um princípio inegociável:

👉 Controle total do I/O

Naquela época:

  • Disco era caro

  • CPU era valiosa

  • I/O era o gargalo

💡 Conclusão da IBM:

“Se o gargalo é I/O, precisamos dominar o disco até o último detalhe físico.”

Assim nascem os conceitos de:

  • Track

  • Cilindro

  • Bloco

  • Extent

Nada disso é acaso. É engenharia.


2️⃣ O que é um TRACK (pista) – o átomo do DASD

📀 Track é:

  • Uma circunferência física no platter do disco

  • Unidade mínima de alocação real

  • Otimizada para leitura e escrita sequencial

Características importantes:

  • Contém um ou mais blocos

  • O tamanho em bytes não é fixo

  • Depende de:

    • Dataset (PS, PO, VSAM)

    • BLKSIZE

    • Tipo de acesso

📏 Referência clássica (3390):

  • ≈ 56 KB por track (didático, não absoluto)

🧪 Easter egg técnico:

Mesmo quando você pede espaço em MB,
o DFSMS converte tudo para tracks internamente 😎


3️⃣ O que é um CILINDRO – o segredo da performance

🛢️ Cilindro =
Conjunto de tracks alinhados verticalmente em todos os pratos do disco.

Por que isso é genial?

  • O braço do disco não precisa se mover

  • Menos seek

  • Mais throughput

  • Menos latência

📌 Em mainframe:

Performance não é pico, é constância.


IBM HD 3390

4️⃣ Modelos clássicos de DASD IBM (história viva)

📦 IBM 2311 / 2314

  • Anos 60 / 70

  • Discos removíveis

  • Origem dos conceitos de cilindro

📦 IBM 3330 – “Merlin”

  • Gigante físico

  • Primeiro “big storage”

📦 IBM 3380

  • Alta densidade

  • Base para sistemas bancários dos anos 80

📦 IBM 3390 (o eterno)

  • Padrão até hoje (logicamente)

  • Modelos:

    • 3390-3 (~2,8 GB)

    • 3390-9 (~8,4 GB)

  • Referência de cálculo de tracks/cilindros

📦 DS8000 (atual)

  • Storage virtualizado

  • Cache massivo

  • Flash

  • Mas… emula 3390
    😏

O mainframe moderniza sem quebrar o passado.


5️⃣ Evolução: do ferro ao virtual (sem perder o controle)

Hoje:

  • Não existe mais “disco girando” como antes

  • Temos:

    • Cache

    • Flash

    • Virtualização

    • Striping interno

Mas o z/OS continua falando em:

  • Track

  • Cilindro

  • Extent

💡 Por quê?

Porque:

  • SMF mede I/O em tracks

  • WLM calcula impacto por volume

  • SMS aloca espaço físico previsível

  • Batch depende disso


6️⃣ Alocação no dia a dia (JCL raiz)

Exemplo clássico:

//ARQ1 DD DSN=MEU.ARQUIVO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(CYL,(10,5),RLSE),
//         DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

📌 Tradução para o padawan:

  • 10 cilindros primários

  • 5 cilindros secundários

  • Espaço real

  • Custo previsível

  • Impacto conhecido


7️⃣ Performance: onde o mainframe humilha

Linux / Unix:

  • Você pede “10 GB”

  • O filesystem decide tudo

  • Fragmentação invisível

  • Latência variável

Mainframe:

  • Você define:

    • Onde

    • Quanto

    • Como cresce

  • O sistema sabe:

    • Quantos seeks

    • Quantos tracks

    • Quanto I/O será gerado

📊 Resultado:

  • SLA calculável

  • Batch que termina no horário

  • Sistema que envelhece bem


8️⃣ Uso prático: quem realmente se beneficia disso?

🏦 Bancos
✈️ Companhias aéreas
🏛️ Governos
💳 Clearing e pagamentos
📊 BI batch massivo

Onde:

  • Erro não é opção

  • Retry não existe

  • Previsibilidade é rei


9️⃣ Curiosidades e Easter Eggs de mainframer

🧠 Você sabia?

  • SPACE=(TRK,…) ainda é usado em sistemas críticos

  • VSAM define espaço em CI/CA, mas mapeia para tracks

  • SMF Type 42 mede EXCP por dataset

  • EAV permite volumes gigantes, mas o cálculo continua físico

  • O termo DASD é mais velho que “storage” 😄


🔚 Conclusão Bellacosa Mainframe ☕

Falar de tracks e cilindros não é nostalgia.
É respeito à física, engenharia de verdade e responsabilidade operacional.

“Mainframe não abstrai o problema.
Ele encara o problema de frente.”

E é por isso que, décadas depois,
ele ainda roda o mundo.




sexta-feira, 1 de outubro de 2010

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz

 

Bellacosa Mainframe apresenta o RACF 

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz 

Se você já perdeu acesso ao próprio TSO, já bloqueou produção com um PERMIT mal dado, ou já ouviu

“foi só uma alteração de RACF…”
então este texto é para você.

Aqui não tem introdução infantil.
Aqui é RACF raiz, técnico, sistêmico e perigoso — do jeito que veterano respeita.


🕰️ História & Origem — por que o RACF nasceu paranoico

O RACF (Resource Access Control Facility) surge nos anos 70, quando a IBM percebeu que:

  • Controle por good behavior não escala

  • Segurança precisava ser centralizada

  • Auditoria não podia ser opcional

RACF foi desenhado para:

  • Negar por padrão

  • Controlar quem, o quê, quando e como

  • Integrar com o núcleo do z/OS

Verdade inconveniente:

RACF não confia nem no SYSADM. E está certo.


🔐 Por onde começar com Segurança (visão de veterano)

Segurança não começa no comando. Começa no modelo mental.

Princípios reais:

  • Least Privilege

  • Segregation of Duties

  • Accountability

  • Auditabilidade

🔥 Easter egg:
Ambiente “funcionando” ≠ ambiente “seguro”.


🏗️ A Estrutura de Grupos — o esqueleto invisível

Grupos RACF não são “organizacionais”.
São domínios de autoridade.

  • Grupos pais controlam filhos

  • OWNER ≠ SUPGROUP

  • Hierarquia mal desenhada vira bomba relógio

📌 Exemplo técnico:

ADDGROUP FINANCE SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP FINANCE.PAYROLL SUPGROUP(FINANCE)

Comentário ácido:

Grupo mal definido é privilégio eterno.


⌨️ Os Comandos RACF — bisturis, não martelos

  • ADDUSER / DELUSER

  • ADDGROUP / DELGROUP

  • CONNECT / REMOVE

  • PERMIT

  • ALTUSER / ALTGROUP

  • SETROPTS

🔥 Regra de Produção:

Se você não sabe desfazer, não execute.


🗑️ Definindo & Excluindo Grupos RACF

Criar grupo é fácil.
Excluir é trauma.

Antes de um DELGROUP:

  • Usuários conectados?

  • Perfis com OWNER?

  • DATASET PROFILE ownership?

  • Surpresas em ACL herdada?

Fofoquice técnica:
DELGROUP em produção é evento histórico.


👤 Definindo Usuários — mais que um ID

Um usuário RACF é:

  • Identidade

  • Responsabilidade

  • Risco

Campos críticos:

  • SPECIAL / OPERATIONS / AUDITOR

  • PASSWORD interval

  • REVOKE / RESUME

  • OMVS / DFP / CICS

📌 Exemplo:

ADDUSER JOSE NAME('JOSE SILVA') DFLTGRP(FINANCE) PASSDATE(30)

🔥 Easter egg:
Usuário genérico é pecado capital.


🔗 Conectando Usuários a Grupos

CONNECT é onde a segurança realmente acontece.

  • AUTHORITY (USE, READ, CONNECT, JOIN)

  • GROUP-SPECIAL

  • OWNER implícito

Verdade nua:

CONNECT errado é privilégio que ninguém vê.


🗂️ Perfis de Conjunto de Dados (DATASET PROFILES)

O coração do RACF clássico.

  • HLQ como fronteira de poder

  • DISCRETIONARY ≠ MANDATORY

  • UACC mal definido = vazamento

📌 Exemplo:

ADDSD 'FINANCE.PAYROLL.**' OWNER(FINANCE) UACC(NONE)
PERMIT 'FINANCE.PAYROLL.**' ID(PAYUSR) ACCESS(READ)

🔥 Curiosidade:
UACC(READ) já causou mais incidente que bug de COBOL.


🌐 Perfis Gerais de Recursos (CLASS Profiles)

Aqui o RACF vira onipresente:

  • CICS

  • IMS

  • MQ

  • SDSF

  • OPERCMDS

  • FACILITY

El Jefe warning:

Quem ignora classe FACILITY não entende z/OS moderno.


🧨 Recursos Especiais do RACF

  • SPECIAL

  • OPERATIONS

  • AUDITOR

  • TRUSTED

  • WARNING vs FAIL

🔥 Comentário venenoso:
SPECIAL demais é insegurança institucionalizada.


⚙️ O Comando SETROPTS — o painel nuclear

SETROPTS controla:

  • Ativação de classes

  • Auditoria

  • Regras globais

  • Password rules

📌 Exemplo:

SETROPTS CLASSACT(DATASET) RACLIST(DATASET) REFRESH

☕🔥 Regra sagrada:

SETROPTS sem planejamento vira outage invisível.


🔄 RACF Remote Sharing Facility (RRSF)

RACF em modo distribuído:

  • Compartilhamento de identidades

  • Replicação de perfis

  • Confiança entre sistemas

🔥 Curiosidade:
RRSF mal configurado espalha erro em escala industrial.


🔗 RACF e Sysplex — segurança em cluster

No Sysplex:

  • Database compartilhado

  • Consistência obrigatória

  • Propagação imediata

Verdade dura:

No Sysplex, erro local vira problema global.


🧪 Programas Utilitários RACF

Ferramentas para quem não vive no ISPF:

  • IRRDBU00

  • IRRUT200

  • IRRICE

  • unloads para auditoria

  • Análise offline

🔥 Easter egg veterano:
Auditor sério não confia só em LISTUSER.


🧠 Mentalidade de Segurança Mainframe (nível veterano)

✔️ Segurança é processo, não produto
✔️ Tudo que não está definido será explorado
✔️ RACF não protege sistema — protege negócio
✔️ Auditor não é inimigo
✔️ Log é prova histórica


🥚 Easter Eggs & Fofoquices RACF

  • Todo ambiente tem um ID “histórico”

  • Sempre existe um dataset que “ninguém sabe de quem é”

  • Segurança forte incomoda — e é esse o objetivo

  • Incidente sério sempre começa com:

    “Mas esse acesso sempre existiu…”


☕🔥 Conclusão — Manifesto El Jefe RACF

RACF não é:

  • Cadastro

  • Burocracia

  • Entrave

RACF é:

  • Arquitetura de confiança

  • Controle de risco

  • Linha final de defesa do z/OS

☕🔥 Se você domina RACF,
você não protege arquivos —
protege a empresa inteira.

terça-feira, 7 de setembro de 2010

Gazeta Esportiva: John Belushi, COBOL e o Jornal que Transformava Segunda-feira em War Room

 

Bellacosa Mainframe e o jornal gazeta esportiva

☕ Um Café no Bellacosa Mainframe

Gazeta Esportiva: John Belushi, COBOL e o Jornal que Transformava Segunda-feira em War Room

⚽ Futebol, rádio, bancas, tabelas, resultados, São Silvestre, Corinthians, Palmeiras, Santos, São Paulo e a extraordinária época em que descobrir o placar de um jogo podia exigir comprar um jornal — enquanto John Belushi berrava que o juiz era ladrão

Se o Notícias Populares era a interface brasileira para descobrir quem havia matado quem, onde apareceu o lobisomem e se o Bebê-Diabo havia sido visto novamente no telhado de alguma residência paulistana...

existia outra máquina de papel rodando em produção.

Só que essa processava uma matéria-prima ainda mais perigosa.

FUTEBOL.

Seu nome:

A GAZETA ESPORTIVA

E antes que algum jovem desenvolvedor COBOL pergunte:

— Bellacosa, mas era apenas um jornal de esportes?

HAHAHAHAHAHAHAHA.

Meu caro...

Dizer que a Gazeta Esportiva era “um jornal de esportes” é como dizer que um IBM Z é “um computador grande”.

Tecnicamente correto.

Culturalmente criminoso.

Durante décadas, a Gazeta Esportiva foi banco de dados, arquivo histórico, placar, agenda, tabela de classificação, serviço estatístico, catálogo de jogadores, calendário esportivo e combustível para discussões capazes de destruir amizades antes mesmo da invenção das redes sociais.

Se Quentin Tarantino foi nosso guia para o Notícias Populares, aqui precisamos de alguém diferente.

Precisamos de um homem capaz de olhar para uma derrota por 1 a 0 e reagir como se o Império Romano tivesse acabado.

Precisamos de:

JOHN BELUSHI.

Camisa parcialmente aberta.

Gravata torta.

Café na mão.

Gazeta Esportiva debaixo do braço.

Ele invade a redação:

QUEM ESCALOU ESSE TIME?!

Bem-vindo.

O batch de domingo acabou.

Segunda-feira começou.

E o SYSOUT tem 64 páginas.


CAPÍTULO I — ANTES DO GOOGLE EXISTIA PAPEL

Precisamos novamente transportar o jovem programador para uma época estranha.

Uma época em que você não podia perguntar:

“Quem ganhou o jogo ontem?”

para um retângulo luminoso no bolso.

Não havia Google.

Não havia OneFootball.

Não havia SofaScore.

Não havia ESPN no celular.

Não havia notificações push.

Não havia grupo do WhatsApp.

Não havia X.

Não havia geolocalização do jogador.

Não havia mapa de calor.

Não havia xG.

Não havia VAR.

Aliás...

talvez devêssemos ter parado no “não havia VAR” e apreciado alguns segundos de silêncio.

Você queria informação esportiva?

Havia rádio.

Televisão.

E havia:

JORNAL.

Na manhã seguinte, o torcedor caminhava até a banca.

E lá estava ela.

A Gazeta Esportiva.

O equivalente esportivo de executar:

DISPLAY MATCH-RESULTS
DISPLAY LEAGUE-TABLE
DISPLAY PLAYER-RATINGS
DISPLAY NEXT-ROUND
DISPLAY COMPLETE-DISASTER

Só que impresso.


CAPÍTULO II — TUDO COMEÇOU COM UM QUARTO DE PÁGINA

A origem da Gazeta Esportiva é quase uma aula de escalabilidade.

Em 1918, já sob a administração de Cásper Líbero, o jornal A Gazeta criou uma pequena seção dedicada aos esportes.

Tamanho?

Aproximadamente:

UM QUARTO DE PÁGINA.

Isso mesmo.

O monstro começou como feature pequena.

A popularidade cresceu.

E em 24 de dezembro de 1928, aquela seção evoluiu para um suplemento esportivo, então chamado A Gazeta — Edição Esportiva.

O COBOLzeiro reconhece imediatamente.

V1.0
COLUNA ESPORTIVA

V2.0
SUPLEMENTO

V3.0
JORNAL INDEPENDENTE

V4.0
PORTAL WEB

Nunca subestime aquele programinha de 400 linhas que alguém chama de:

“solução temporária”.


CAPÍTULO III — CÁSPER LÍBERO, O ARQUITETO

Para compreender a Gazeta Esportiva precisamos conhecer Cásper Líbero.

Ele adquiriu A Gazeta em 1918 e iniciou uma série de transformações editoriais. Esporte tornou-se uma das áreas nas quais investiu intensamente.

Mas sua importância vai muito além de simplesmente publicar resultados.

Cásper percebeu algo fundamental:

ESPORTE É CONTEÚDO E EVENTO.

Essa combinação é poderosíssima.

Você não apenas cobre uma competição.

Você pode ajudar a criá-la.

A marca Gazeta ficou ligada a eventos esportivos que atravessariam gerações.

O caso mais extraordinário?

CORRIDA INTERNACIONAL DE SÃO SILVESTRE.

Criada em 1925.

Também surgiu a tradicional Prova Ciclística Nove de Julho, criada em 1933.

Isso significa que o ecossistema não era:

EVENTO
  |
  v
JORNAL COBRE

Era muito mais interessante:

JORNAL
  |
  +----> PROMOVE EVENTO
  |
  +----> COBRE EVENTO
  |
  +----> CRIA AUDIÊNCIA
  |
  +----> FORTALECE MARCA
  |
  +----> AUMENTA INTERESSE

Hoje chamaríamos isso de:

ecossistema de conteúdo.

Em 1925 chamavam de:

trabalhar.


CAPÍTULO IV — A TRAGÉDIA DE CÁSPER

Cásper Líbero não chegou a ver a Gazeta Esportiva transformar-se no grande diário independente que se tornaria.

Ele morreu em 27 de agosto de 1943, em um acidente aéreo na Baía de Guanabara.

Mas deixou algo extraordinário.

Um testamento determinando a criação de uma fundação.

Como não teve filhos, seu patrimônio foi destinado à instituição que preservaria seu projeto de comunicação.

Nasceu a:

FUNDAÇÃO CÁSPER LÍBERO.

Instituída em 1944, ela permanece responsável por um ecossistema que inclui Gazeta Esportiva, TV Gazeta, Rádio Gazeta, Faculdade Cásper Líbero e outras atividades.

Isso diferencia profundamente a história empresarial da Gazeta.

Não estamos falando simplesmente de:

PROPRIETÁRIO
   |
HERDEIROS
   |
VENDA

Existe uma estrutura institucional criada a partir da vontade testamentária de seu fundador.

É quase um:

PERFORM LEGADO
    UNTIL FOREVER
END-PERFORM.

CAPÍTULO V — 10 DE OUTUBRO DE 1947: GO LIVE

Chegamos ao grande deployment.

10 de outubro de 1947.

A Gazeta Esportiva deixa definitivamente sua condição de suplemento e torna-se um jornal diário independente dedicado ao esporte.

O projeto havia sido pensado antes.

A Copa de 1938 parecia uma oportunidade.

Depois veio a Segunda Guerra Mundial.

Houve nova tentativa em 1943.

Então Cásper morreu.

Finalmente:

1947.

GO LIVE.

A primeira edição diária apresentava o jornal como moderno, dinâmico e comprometido com independência e ética jornalística.

E nasceu uma expressão que se tornaria praticamente identidade:

“O MAIS COMPLETO.”

Isso era marketing.

Mas havia uma ambição real por trás.

Não se pretendia falar apenas de futebol.

A proposta era cobrir:

futebol,

atletismo,

basquete,

automobilismo,

ciclismo,

boxe,

natação,

tênis

e muitas outras modalidades.

Era uma espécie de:

SPORTS.*

CAPÍTULO VI — MAS VAMOS PARAR DE FINGIR: FUTEBOL ERA O MONSTRO

Sim.

Havia outras modalidades.

Mas estamos no Brasil.

Portanto chega John Belushi chutando a porta:

E O CORINTHIANS?!

HAHAHAHAHAHA.

Futebol era inevitavelmente o grande motor de atenção.

Corinthians.

Palmeiras.

São Paulo.

Santos.

Portuguesa.

Clubes do interior.

Seleção Brasileira.

Campeonatos estaduais.

Nacionais.

Mundiais.

Transferências.

Escalações.

Crises.

Cartolas.

Técnicos.

Juízes.

E aquela instituição brasileira que existe desde antes de a humanidade dominar o fogo:

A CORNETA.


CAPÍTULO VII — A BANCA ERA O SOFASCORE

Voltemos à banca.

Segunda-feira de manhã.

São Paulo.

Um trabalhador chega.

Vê a Gazeta.

A manchete anuncia a rodada.

Ele não precisa comprar imediatamente.

Olha.

Outro sujeito para.

Mais um.

— Você viu o jogo?

— Vi.

— Aquilo não foi pênalti.

Pronto.

THREAD CRIADA.

Outro responde:

— Foi pênalti sim.

ENGAGEMENT +100%.

Chega um palmeirense.

CONFLITO DETECTADO.

Chega um corintiano.

CPU 97%.

Chega um santista lembrando do Pelé.

HISTORICAL QUERY STARTED.

Chega o dono da banca:

— Vocês vão comprar o jornal ou vão ficar discutindo aí?

A rede social brasileira já funcionava perfeitamente.

Sem Internet.


CAPÍTULO VIII — A SEGUNDA-FEIRA ERA O WAR ROOM

O domingo terminava.

Mas o futebol não.

Na segunda-feira começava:

A AUTÓPSIA.

Quem jogou bem?

Quem jogou mal?

O juiz errou?

O técnico enlouqueceu?

O atacante perdeu gol?

Quem foi expulso?

Como ficou a classificação?

Quem joga na próxima rodada?

Era praticamente uma reunião pós-incidente.

INCIDENT:
DERROTA POR 3 X 0

SEVERITY:
SEV-1

ROOT CAUSE:
EM INVESTIGAÇÃO

POSSIBLE CAUSES:
- técnico
- goleiro
- zagueiro
- gramado
- juiz
- diretoria
- Mercúrio retrógrado

John Belushi sobe na mesa:

— NÃO FOI DERROTA!

Todos olham.

— FOI SABOTAGEM!


CAPÍTULO IX — A GAZETA ERA BANCO DE DADOS

Aqui entra o COBOL.

Para gerações inteiras, jornal esportivo era também:

DATASET.

Resultados.

Classificações.

Artilharia.

Escalações.

Calendários.

Estatísticas.

Histórico.

Você queria saber como estava o campeonato?

Não executava API.

Consultava tabela.

01 CAMPEONATO.
   05 TIME.
   05 PONTOS.
   05 JOGOS.
   05 VITORIAS.
   05 EMPATES.
   05 DERROTAS.
   05 GOLS-PRO.
   05 GOLS-CONTRA.

A tabela classificatória era praticamente um arquivo sequencial que todo brasileiro sabia interpretar.

Curiosamente, milhões de pessoas que jamais ouviram falar em banco relacional entendiam perfeitamente:

ordenação, agregação, chave, ranking e atualização incremental.


CAPÍTULO X — 1958: BRASIL CAMPEÃO

Então acontece 1958.

Brasil campeão mundial.

Pelé.

Garrincha.

Didi.

Nilton Santos.

Bellini.

Suécia.

O futebol brasileiro explode simbolicamente.

Segundo registros históricos, a Gazeta alcançou cerca de 400 mil exemplares nas grandes tiragens associadas à Copa de 1958.

Imagine imprimir centenas de milhares de jornais.

Não é pageview.

Não é request HTTP.

Cada cópia exige:

papel,

tinta,

máquina,

energia,

operários,

caminhão,

distribuição,

banca.

É infraestrutura física.


CAPÍTULO XI — 1970: O MAINFRAME ENTRA EM OVERLOAD

E então chegamos ao México.

Pelé.

Jairzinho.

Tostão.

Rivelino.

Carlos Alberto Torres.

Brasil tricampeão.

A Seleção que virou mitologia.

Em 23 de junho de 1970, a Gazeta Esportiva registrou seu recorde histórico:

534.530 EXEMPLARES.

Em um único dia.

MEIO MILHÃO.

John Belushi olha para a rotativa.

— MAIS PAPEL!

— Não cabe!

— MAIS TINTA!

— Estamos no limite!

— ENTÃO OVERCLOCKA A ROTATIVA!

Isso é escala.


CAPÍTULO XII — A COR DO JORNAL ERA A PAIXÃO

A experiência do jornal esportivo não era apenas informacional.

Era ritual.

Comprar.

Dobrar.

Carregar debaixo do braço.

Ler no ônibus.

Ler no bar.

Ler no trabalho escondido.

Deixar sobre a mesa.

Recortar.

Guardar.

Um resultado esportivo deixava de ser efêmero porque adquiria suporte físico.

A vitória do seu time existia em papel.

A derrota também.

Infelizmente.

E aquela página podia sobreviver décadas.


CAPÍTULO XIII — “ME DÁ A GAZETA”

Essa frase fazia sentido por si só.

O jornaleiro sabia.

A marca havia conquistado aquilo que toda empresa deseja:

atalho mental.

Gazeta = esporte.

Assim como determinados produtos tornam-se quase sinônimos de categoria, a Gazeta ocupava um lugar particular no imaginário esportivo paulista.

E isso era especialmente poderoso numa cidade onde futebol não era passatempo.

Era:

IDENTITY MANAGEMENT SYSTEM.

CAPÍTULO XIV — E O INTERIOR?

Aqui há outro ponto importante.

A Gazeta não se limitava ao eixo dos quatro grandes clubes paulistas.

A imprensa esportiva impressa possuía espaço para acompanhar campeonatos, clubes e modalidades que hoje podem desaparecer rapidamente da homepage porque não geram cliques suficientes.

Guarani.

Ponte Preta.

XV de Piracicaba.

Ferroviária.

Botafogo de Ribeirão Preto.

Comercial.

Noroeste.

Portuguesa Santista.

São Bento.

Juventus.

América.

E tantos outros.

O papel tinha limite físico.

Mas o jornal esportivo precisava construir uma visão relativamente ampla do ecossistema.

Isso ajudou a preservar uma quantidade monumental de memória esportiva.


CAPÍTULO XV — E A SÃO SILVESTRE?

Aqui o legado sai da página e invade a rua.

A Corrida Internacional de São Silvestre permanece uma das marcas esportivas mais reconhecíveis associadas ao legado de Cásper Líbero.

Criada em 1925, atravessou décadas e continua sendo realizada.

Pense nisso.

Um veículo de comunicação ajudou a criar um evento.

O evento virou tradição.

A tradição sobreviveu ao jornal impresso.

Isso é branding com RETENTION PERIOD = CENTURY.


CAPÍTULO XVI — O TROFÉU INVISÍVEL DA MEMÓRIA

A Gazeta também esteve ligada à criação e distribuição de premiações esportivas, entre elas a tradicional Taça dos Invictos, associada a equipes que mantinham longas sequências sem derrota.

Isso revela outra função da imprensa esportiva:

ela não apenas relata o esporte.

Ela ajuda a construir:

mitologia.

Recordes precisam ser lembrados.

Sequências precisam ser comparadas.

Heróis precisam de narrativas.

Rivalidades precisam de arquivo.

O jornal funciona como memória externa do torcedor.


CAPÍTULO XVII — O TORCEDOR ERA O ALGORITMO DE RECOMENDAÇÃO

Hoje:

IF USER = CORINTHIANS
   RECOMMEND CORINTHIANS-CONTENT
END-IF

Na banca?

O torcedor olhava a primeira página.

Se o clube estivesse em destaque:

CLICK = BUY

Se o rival tivesse perdido vergonhosamente:

CLICK = BUY
SHARE = BUY-AND-SHOW-FRIENDS

HAHAHAHA.

Esse segundo caso provavelmente possuía CTR extraordinário.


CAPÍTULO XVIII — O HUMOR DO FUTEBOL

Aqui John Belushi assume definitivamente a redação.

Porque futebol brasileiro nunca foi apenas análise.

É absurdo.

Um sujeito passa a semana inteira dizendo:

— Futebol é só entretenimento.

Domingo, 17h43:

EU NÃO ACREDITO NESSE DESGRAÇADO!

Cinco minutos depois:

— Nunca mais assisto futebol.

Quarta-feira:

— Que horas é o jogo?

Essa é uma máquina de estados fantástica:

STATE 01 = ESPERANÇA
STATE 02 = ANSIEDADE
STATE 03 = EUFORIA
STATE 04 = ÓDIO
STATE 05 = DEPRESSÃO
STATE 06 = NUNCA-MAIS
STATE 07 = PRÓXIMA-RODADA

GO TO STATE-01.

Loop infinito.


CAPÍTULO XIX — RÁDIO, TV, JORNAL: UM ECOSSISTEMA

Outra diferença fundamental da Gazeta está no ecossistema construído pela Fundação.

Jornal.

Rádio.

Televisão.

Faculdade.

Agência.

Eventos.

Hoje falaríamos em:

OMNICHANNEL.

A Fundação Cásper Líbero mantém até hoje esse complexo de comunicação no edifício da Avenida Paulista, incluindo TV Gazeta, Rádio Gazeta, Faculdade Cásper Líbero e Gazeta Esportiva digital.

A Gazeta não era apenas uma publicação isolada.

Era parte de uma arquitetura.


CAPÍTULO XX — ENTÃO CHEGA A INTERNET

E novamente nosso velho conhecido aparece.

TCP/IP.

Em 1997, segundo a própria Fundação, a Gazeta Esportiva começou sua entrada na Internet, inicialmente reproduzindo conteúdo do impresso. Outra retrospectiva oficial situa o lançamento do portal independente em 1998. As duas datas refletem etapas diferentes da migração digital.

Isso é interessante porque mostra a transição acontecendo em tempo real.

Primeiro:

PAPER → HTML

Depois:

DIGITAL-FIRST

E finalmente:

REAL-TIME

CAPÍTULO XXI — O INIMIGO DO JORNAL ESPORTIVO CHAMAVA-SE LATÊNCIA

Pense no problema.

Um jogo termina às 22h.

O jornal precisa:

fechar texto,

editar,

diagramar,

imprimir,

distribuir.

A Internet diz:

— Gol.

Agora.

Cartão vermelho.

Agora.

Fim do jogo.

Agora.

Classificação atualizada.

Agora.

Para informação esportiva, a diferença entre:

amanhã

e

agora

é brutal.

O produto possuía um problema arquitetural que nenhuma manchete conseguiria eliminar:

LATENCY = HOURS

contra:

LATENCY = SECONDS

CAPÍTULO XXII — 2001: ABEND

No início do século XXI, a situação financeira do jornal havia se tornado crítica.

Em outubro de 2001, a Fundação anunciou a decisão de encerrar a edição impressa e transferir seu conteúdo para a Internet. A Folha registrou naquele momento uma tiragem média inferior a 14 mil exemplares.

Compare.

1970:

534.530

2001:

menos de 14.000 em média

Isso não é queda.

Isso é:

IEC030I B37

O dataset ficou sem espaço para continuar fingindo que estava tudo bem.


CAPÍTULO XXIII — A ÚLTIMA CAPA

Em 19 de novembro de 2001, circulou a edição número:

27.162

A última edição impressa diária.

A manchete?

“O Futuro é Hoje!”

Poucas manchetes poderiam ser mais apropriadas.

No dia seguinte, a operação esportiva passava definitivamente para o ambiente digital.

O jornal morreu?

O suporte morreu.

A marca continuou.

E isso é muito diferente.


CAPÍTULO XXIV — MODERNIZAÇÃO SEM REWRITE

Agora o programador COBOL começa a sorrir.

Porque reconheceu tudo.

BUSINESS LOGIC:
COBRIR ESPORTES

OLD INTERFACE:
PAPEL

NEW INTERFACE:
WEB

Não foi necessário executar:

DELETE FROM BRAND;

Executou-se:

ALTER ACCESS METHOD.

Essa é uma aula maravilhosa de modernização.

A função continua.

A tecnologia muda.


CAPÍTULO XXV — O QUE MORREU?

Morreu o ritual diário específico.

O jornal debaixo do braço.

A banca como endpoint.

A tabela impressa.

O resultado congelado no papel.

A fotografia que você recortava.

A edição guardada porque seu clube foi campeão.

O sujeito lendo por cima do seu ombro no ônibus.

O jornal aberto sobre a mesa do boteco.

E talvez uma das experiências mais deliciosamente analógicas:

virar a página procurando seu time.


CAPÍTULO XXVI — O QUE NÃO MUDOU ABSOLUTAMENTE NADA?

Agora prepare-se.

1958:

— O juiz roubou.

2026:

— O juiz roubou.

1970:

— O técnico escalou errado.

2026:

— O técnico escalou errado.

1985:

— Esse presidente está destruindo o clube.

2026:

— Esse presidente está destruindo o clube.

1994:

— Esse jogador não vale tudo isso.

2026:

— Esse jogador não vale tudo isso.

O suporte tecnológico evoluiu.

O torcedor recebeu:

Internet,

smartphone,

streaming,

4K,

VAR,

GPS,

estatística avançada,

inteligência artificial,

tracking,

big data.

E usa tudo isso para concluir:

“O JUIZ É CEGO.”

Magnífico.


CAPÍTULO XXVII — A GAZETA ERA O REDDIT DO BOTECO

O jornal sozinho não era a comunidade.

Ele era o gatilho da comunidade.

A pessoa lia.

Comentava.

Discutia.

Levava ao trabalho.

Mostrava ao colega.

Discordava.

Guardava.

Recortava.

A informação saía do papel e entrava na conversa.

Hoje chamamos isso de:

engagement.

Na época chamava:

— Você viu a Gazeta?


CAPÍTULO XXVIII — JOHN BELUSHI DESCOBRE O VAR

Nosso guia finalmente chega ao futebol moderno.

Belushi observa uma sala com 37 monitores.

Linhas.

Replay.

Zoom.

Câmeras.

Computadores.

Comunicação eletrônica.

Ele pergunta:

— Tudo isso serve para decidir se foi pênalti?

— Sim.

— E funciona?

Silêncio.

Belushi pega uma Gazeta Esportiva de 1970.

— Na minha época bastava xingar o juiz!

O COBOLzeiro responde:

— Tecnicamente ainda basta.


CAPÍTULO XXIX — O ARQUIVO É UMA MÁQUINA DO TEMPO

Existe algo que frequentemente esquecemos quando falamos sobre jornais antigos.

Eles são bancos de memória.

Uma edição da Gazeta Esportiva não guarda apenas resultados.

Guarda:

ortografia,

publicidade,

preços,

nomes,

clubes desaparecidos,

estádios modificados,

patrocinadores,

uniformes,

jogadores esquecidos,

modalidades,

expectativas,

frustrações.

Você abre uma edição de 1958 e não está simplesmente lendo sobre futebol.

Está executando:

RESTORE BRASIL
FROM BACKUP
DATE '1958';

Isso é patrimônio histórico.


CAPÍTULO XXX — O GRANDE EASTER EGG: O ESPORTE SEMPRE FOI DATA-DRIVEN

Hoje adoramos falar:

data analytics no futebol.

Mas esporte sempre foi uma gigantesca fábrica de dados.

Gols.

Pontos.

Vitórias.

Derrotas.

Tempo.

Distância.

Recordes.

Classificação.

Artilharia.

Aproveitamento.

Média.

O jornal esportivo era uma camada de apresentação desse banco de dados.

Hoje temos dashboards.

Antes tínhamos tabelas.

Hoje temos APIs.

Antes tínhamos repórteres telefonando.

Hoje temos feeds em tempo real.

Antes tínhamos fechamento.

A arquitetura mudou.

O domínio continua assustadoramente parecido.


CAPÍTULO XXXI — NOTÍCIAS POPULARES X GAZETA ESPORTIVA

Agora coloque os dois jornais lado a lado numa banca imaginária.

À esquerda:

NOTÍCIAS POPULARES

NASCEU O DIABO!

À direita:

GAZETA ESPORTIVA

CORINTHIANS PERDE CLÁSSICO!

Um corintiano olha para ambos.

Compra o Notícias Populares.

Porque naquele momento:

o Bebê-Diabo parece uma notícia menos traumática.

HAHAHAHAHAHA.

Mas há uma conexão séria.

Os dois compreendiam a força da banca.

Da manchete.

Da identidade do público.

Da leitura compartilhada.

Da informação como ritual.

E principalmente:

da emoção.


CAPÍTULO XXXII — A BANCA COMO HOMEPAGE DA CIDADE

Imagine novamente São Paulo.

Década de 1970.

Ônibus.

Fumaça.

Buzinas.

Padaria.

Café.

Cigarro.

Banca.

Jornais pendurados.

Você passa.

Em alguns segundos recebe:

política,

economia,

crime,

esporte,

celebridade,

emprego,

classificados.

A banca era:

PORTAL.

Só que fisicamente instalado na calçada.

Cada jornal era um aplicativo.

Cada manchete era uma notificação.

Cada capa disputava atenção.

Cada comprador era conversão.

E a Gazeta tinha uma vantagem extraordinária:

o torcedor já chegava emocionalmente autenticado.


CAPÍTULO XXXIII — O LEGADO

O legado da Gazeta Esportiva é maior que seu período impresso.

Ele inclui a contribuição histórica para o jornalismo esportivo brasileiro, sua ligação com eventos como São Silvestre e Nove de Julho, o arquivo acumulado durante décadas e a continuidade da marca no ambiente digital.

Mas existe um legado menos tangível.

Ela pertence a uma época em que a relação com informação possuía:

peso.

Literalmente.

Você carregava informação.

Dobrava informação.

Emprestava informação.

Guardava informação.

Jogava informação fora.

A notícia tinha cheiro de tinta.


EPÍLOGO — BELUSHI, O COBOLZEIRO E A ÚLTIMA SEGUNDA-FEIRA

São Paulo.

Segunda-feira.

Sete horas da manhã.

Um bar perto de uma estação.

Café.

Pão na chapa.

Um homem entra carregando a Gazeta Esportiva.

Abre sobre o balcão.

Outro olha.

— Quanto foi?

— Dois a zero.

— Quem fez?

Ele aponta para a página.

Chega outro.

— Esse time não tem meio-campo.

Outro responde:

— Você não entende nada de futebol.

Pronto.

A rede entrou em produção.

Não existe Wi-Fi.

Não existe smartphone.

Não existe login.

Não existe perfil.

Não existe algoritmo.

Mas existe:

USER-A
USER-B
USER-C
CONTENT
ENGAGEMENT
COMMUNITY

John Belushi entra.

Olha o jornal.

Olha o placar.

Derruba o café.

DOIS A ZERO?!

O bar inteiro olha.

Belushi sobe numa cadeira.

— Acabou! Este clube morreu! Nunca mais assisto futebol! Nunca mais compro jornal! Nunca mais discuto escalação!

Silêncio.

O balconista pergunta:

— Quarta tem jogo, não tem?

Belushi desce lentamente.

Pega a Gazeta.

Folheia.

— Oito e meia.

Senta.

Pede outro café.

E talvez essa seja a melhor definição possível da Gazeta Esportiva.

Ela não vendia apenas resultados.

Vendia o próximo capítulo.

A derrota de domingo não encerrava nada.

Produzia a segunda-feira.

A segunda-feira produzia discussão.

A discussão produzia expectativa.

A expectativa produzia quarta-feira.

Quarta produzia outro jogo.

Outro resultado.

Outra manchete.

Outra Gazeta.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TORCEDOR-BRASILEIRO.

       PROCEDURE DIVISION.

       JOGA.
           PERFORM ESPERAR-JOGO.
           PERFORM ASSISTIR-JOGO.
           PERFORM RECLAMAR-DO-JUIZ.
           PERFORM DISCUTIR-ESCALACAO.
           PERFORM LER-GAZETA.
           PERFORM PROMETER-NUNCA-MAIS.

           GO TO JOGA.

Um programador junior observa horrorizado:

— Bellacosa! Isso é um GO TO infinito!

Exatamente.

Está em produção há mais de cem anos.

Não mexa.

Ninguém sabe todas as dependências.

A Gazeta Esportiva impressa executou sua última edição em 2001.

Mas o programa continua.

A banca virou portal.

A tabela virou widget.

O rádio virou streaming.

A fotografia virou vídeo.

A coluna virou feed.

O fechamento virou atualização contínua.

O leitor virou usuário.

O assinante virou audiência.

A discussão do bar virou comentário.

O arquivo virou database.

O jornal virou URL.

Mas domingo à tarde, quando a bola bate na mão de alguém dentro da área...

todo o avanço tecnológico da humanidade é descartado.

Milhões de brasileiros executam simultaneamente:

IF PENALTI-CONTRA-MEU-TIME
    DISPLAY 'FOI SEM QUERER'
ELSE
    DISPLAY 'PENALTI CLARISSIMO'
END-IF.

Esse código jamais passou por revisão.

Jamais passará.

John Belushi pega o jornal.

O COBOLzeiro pega o café.

A rotativa começa a girar.

CLAC. CLAC. CLAC. CLAC.

534.530 exemplares.

Uma cidade acordando.

Uma banca abrindo.

Um torcedor procurando a manchete.

E um programa centenário chamado:

PAIXÃO PELO ESPORTE

continua executando.

RC=0000.

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