🌾 ⑤ – Laid-Back Camp (Yuru Camp△)

 

🌾 ⑤ – Laid-Back Camp (Yuru Camp△)

Ano: 2018
Estúdio: C-Station
Gênero: Slice of Life, Comédia, Aventura

🏕️ Sinopse

Rin Shima é uma garota tranquila que ama acampar sozinha aos pés do Monte Fuji. Certo dia, ela conhece Nadeshiko, uma garota enérgica e curiosa que transforma completamente suas jornadas. Juntas, elas descobrem o simples prazer do vento frio na manhã, do ramen instantâneo sob o céu estrelado e da amizade que se acende ao calor da fogueira.

🌿 Curiosidades

• O anime causou um aumento real no turismo e na venda de equipamentos de camping no Japão.

• Muitas locações são fiéis a pontos reais do Monte Fuji e do Lago Motosu.

• O “△” no título simboliza uma tenda — um charme minimalista de design japonês.

💡 Dica Bellacosa

Assista Laid-Back Camp em um dia frio, com uma manta e uma xícara de chá verde. O segredo da série não está no enredo, mas no silêncio entre os diálogos — aquele respiro que o Japão chama de “ma”, o espaço entre as coisas.

🎭 Filosofia Slow Life

Esse anime é um lembrete de que não é preciso correr para viver bem. Às vezes, basta acampar com uma boa companhia e deixar o tempo fluir como o vapor do chá no vento da montanha.

 

Bellacosa Mainframe e o SQL no Mainframe muito alem do select

---

☕ Um Café no Bellacosa Mainframe

☕ SQL NO MAINFRAME: MUITO ALÉM DO SELECT

Como Dominar os Fundamentos de SQL no DB2 13 for z/OS

Quando alguém abre o SPUFI, Data Studio, DBeaver ou qualquer ferramenta SQL pela primeira vez, normalmente executa algo simples:

SELECT *
FROM CLIENTES;

A consulta retorna dados.

O usuário sorri.

Acredita que aprendeu SQL.

Mas na realidade acabou de dar apenas o primeiro passo de uma longa jornada.

No universo Mainframe, SQL é a língua falada entre:

• COBOL

• CICS

• IMS

• Java

• Web Services

• APIs REST

• z/OS Connect

• Analytics

• Inteligência Artificial

Todo sistema corporativo moderno passa por SQL em algum momento.

E o DB2 13 elevou ainda mais essa importância.

---

A HISTÓRIA QUE TODO PROFISSIONAL DE MAINFRAME DEVERIA CONHECER

Antes do SQL, bancos relacionais eram apenas uma teoria.

Em 1970, Edgar F. Codd publicou um artigo revolucionário na IBM:

A Relational Model of Data for Large Shared Data Banks

Esse trabalho mudou a computação.

A ideia era simples:

Ao invés de navegar registros fisicamente, os usuários deveriam dizer:

"Quero estes dados."

E o banco decidiria:

"Eu descubro a melhor forma de encontrá-los."

Nascia o conceito de SQL.

Décadas depois, essa filosofia continua viva dentro do DB2 13.

---

O QUE É SQL?

SQL significa:

Structured Query Language

Ou:

Linguagem Estruturada de Consulta

Ela permite:

• Consultar dados

• Inserir dados

• Alterar dados

• Excluir dados

• Criar estruturas

• Gerenciar segurança

Praticamente tudo que fazemos no DB2 passa por SQL.

---

OS QUATRO GRANDES GRUPOS DE COMANDOS SQL

DQL – Data Query Language

Consulta de dados.

Exemplo:

SELECT *
FROM FUNCIONARIOS;

---

DML – Data Manipulation Language

Manipulação de registros.

INSERT INTO FUNCIONARIOS
VALUES
(100,'CARLOS');

UPDATE FUNCIONARIOS
SET SALARIO = 5000
WHERE MATRICULA = 100;

DELETE
FROM FUNCIONARIOS
WHERE MATRICULA = 100;

---

DDL – Data Definition Language

Definição das estruturas.

CREATE TABLE CLIENTES
(
 ID INTEGER,
 NOME VARCHAR(50)
);

---

DCL – Data Control Language

Controle de segurança.

GRANT SELECT
ON CLIENTES
TO USER01;

---

A TABELA É O CORAÇÃO DO DB2

Imagine um arquivo VSAM KSDS.

Agora imagine esse conceito evoluído.

Uma tabela é composta por:

• Linhas

• Colunas

• Relacionamentos

• Índices

• Constraints

Exemplo:

ID	NOME	CIDADE
1	ANA	SÃO PAULO
2	JOÃO	SANTOS
3	MARIA	RIO

Essa simplicidade aparente esconde uma enorme complexidade de armazenamento.

---

SUA PRIMEIRA CONSULTA DE VERDADE

O erro mais comum é usar:

SELECT *
FROM CLIENTES;

Em produção isso costuma ser um desastre.

O profissional experiente utiliza:

SELECT
    ID,
    NOME,
    CIDADE
FROM CLIENTES;

Por quê?

Porque reduz:

• I/O

• CPU

• Network Traffic

• Uso de buffer pools

No DB2 13 isso continua sendo uma das melhores práticas.

---

APRENDENDO A FILTRAR DADOS

O poder real surge com o WHERE.

SELECT
    NOME
FROM CLIENTES
WHERE CIDADE = 'SANTOS';

Sem WHERE:

SCAN TOTAL

Com WHERE:

BUSCA DIRECIONADA

Diferença gigantesca.

Principalmente em tabelas com bilhões de linhas.

---

OPERADORES MAIS UTILIZADOS

Igualdade

WHERE ID = 100

Diferente

WHERE ID <> 100

Maior

WHERE SALARIO > 10000

Menor

WHERE SALARIO < 5000

Intervalo

WHERE SALARIO
BETWEEN 5000 AND 10000

Lista

WHERE CIDADE
IN ('SANTOS','CAMPINAS')

---

LIKE: A ARMA SECRETA DOS ANALISTAS

SELECT *
FROM CLIENTES
WHERE NOME LIKE 'MAR%';

Retorna:

• MARIA

• MARCOS

• MARCELO

Mas atenção.

LIKE mal utilizado pode destruir a performance.

Exemplo ruim:

LIKE '%MAR%'

O otimizador normalmente perde a possibilidade de usar índices eficientemente.

---

ORDER BY

Organizando resultados.

SELECT
NOME,
SALARIO
FROM FUNCIONARIOS
ORDER BY SALARIO DESC;

Maior salário primeiro.

Muito simples.

Muito poderoso.

Muito custoso quando mal utilizado.

---

DISTINCT

Eliminando duplicidades.

SELECT DISTINCT
CIDADE
FROM CLIENTES;

Resultado:

SANTOS
CAMPINAS
RIO

Sem repetições.

---

CONTANDO REGISTROS

Todo DBA utiliza:

SELECT COUNT(*)
FROM CLIENTES;

Mas poucos iniciantes sabem que em tabelas gigantes isso pode gerar leituras enormes.

Por isso estatísticas e catálogos do DB2 também são utilizados para estimativas.

---

FUNÇÕES DE AGREGAÇÃO

Soma

SELECT SUM(VALOR)
FROM VENDAS;

---

Média

SELECT AVG(SALARIO)
FROM FUNCIONARIOS;

---

Máximo

SELECT MAX(SALARIO)
FROM FUNCIONARIOS;

---

Mínimo

SELECT MIN(SALARIO)
FROM FUNCIONARIOS;

---

GROUP BY: ONDE O SQL COMEÇA A FICAR INTERESSANTE

Exemplo:

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE;

Resultado:

Cidade	Quantidade
Santos	1200
São Paulo	5800
Campinas	900

Aqui começamos a transformar dados em informação.

---

HAVING

Filtrando grupos.

SELECT
CIDADE,
COUNT(*)
FROM CLIENTES
GROUP BY CIDADE
HAVING COUNT(*) > 1000;

Somente cidades relevantes aparecem.

---

JOINS: O SUPERPODER DO SQL

Aqui nasce o verdadeiro banco relacional.

Tabela CLIENTES:

ID	NOME
1	ANA

Tabela PEDIDOS:

PEDIDO	ID_CLIENTE
100	1

Consulta:

SELECT
C.NOME,
P.PEDIDO
FROM CLIENTES C
INNER JOIN PEDIDOS P
ON C.ID = P.ID_CLIENTE;

Resultado:

ANA 100

Magia?

Não.

Modelo relacional.

---

INNER JOIN

Retorna apenas correspondências.

INNER JOIN

É o JOIN mais utilizado do mundo.

---

LEFT JOIN

Mantém todos os registros da esquerda.

LEFT JOIN

Mesmo sem correspondência.

Muito usado em auditorias.

---

SUBSELECTS

Uma consulta dentro da outra.

SELECT *
FROM FUNCIONARIOS
WHERE SALARIO >
(
SELECT AVG(SALARIO)
FROM FUNCIONARIOS
);

Funcionários acima da média.

Excelente exemplo de lógica relacional.

---

SQL E COBOL: UMA DUPLA IMBATÍVEL

Em Mainframe o SQL raramente vive sozinho.

Exemplo Embedded SQL:

EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTES
WHERE ID = :WS-ID
END-EXEC.

Esse padrão movimenta bancos, seguradoras, governos e bolsas de valores há décadas.

---

O PAPEL DO BIND

Iniciantes aprendem SQL.

Profissionais Mainframe aprendem:

• Pré-compilação

• DBRM

• PACKAGE

• PLAN

• BIND

Sem isso o SQL não chega à produção.

---

O OTIMIZADOR: O CÉREBRO DO DB2

O usuário escreve:

SELECT *
FROM CLIENTES
WHERE ID = 100;

O DB2 pergunta:

• Uso índice?

• Faço scan?

• Quantas páginas?

• Quanto CPU?

Esse processo é chamado:

Access Path Selection

É aqui que a mágica acontece.

---

EXPLAIN: O RAIO-X DA CONSULTA

Nunca confie apenas porque uma consulta funciona.

Verifique o plano.

EXPLAIN PLAN FOR
SELECT *
FROM CLIENTES;

O DB2 mostrará:

• Índices usados

• Custo estimado

• Estratégias de acesso

DBAs vivem nessa análise.

---

O QUE MUDA NO DB2 13?

O DB2 13 trouxe avanços importantes:

Melhor exploração de estatísticas

O otimizador toma decisões mais inteligentes.

Melhor uso de CPU

Redução de consumo em workloads intensos.

Aprimoramentos em SQL Analytics

Funções analíticas mais eficientes.

Melhor integração híbrida

Conectividade moderna com APIs e aplicações distribuídas.

Evolução contínua do Machine Learning para otimização

Capacidade crescente de melhorar decisões de acesso com base em padrões observados.

---

ERROS CLÁSSICOS DOS INICIANTES

SELECT *

Evite.

---

Falta de índice

Performance despenca.

---

WHERE inadequado

Full table scan.

---

JOIN sem critério

Explosão de registros.

---

UPDATE sem WHERE

O terror dos DBAs.

UPDATE CLIENTES
SET STATUS='A';

Toda tabela alterada.

Acidente clássico.

---

O CAMINHO PARA VIRAR ESPECIALISTA

Etapa 1

Dominar SELECT.

---

Etapa 2

Dominar filtros.

---

Etapa 3

Dominar JOINs.

---

Etapa 4

Entender índices.

---

Etapa 5

Aprender EXPLAIN.

---

Etapa 6

Estudar catálogo DB2.

---

Etapa 7

Entender RUNSTATS.

---

Etapa 8

Compreender Access Paths.

---

Etapa 9

SQL embarcado em COBOL.

---

Etapa 10

Otimização avançada.

---

CONCLUSÃO: SQL É A NOVA LINGUAGEM UNIVERSAL DO MAINFRAME

Muitos profissionais acreditam que dominar COBOL é suficiente para trabalhar em Mainframe.

Não é.

O mercado moderno exige uma combinação poderosa:

• COBOL

• JCL

• CICS

• RACF

• DB2

• SQL

E dentro desse conjunto, SQL ocupa uma posição privilegiada.

Toda aplicação corporativa depende dele.

Toda API consulta dados através dele.

Toda IA corporativa precisa dele.

Todo analista precisa entendê-lo.

O segredo não é decorar comandos.

O segredo é compreender o que acontece por trás deles.

Quando você entende como o DB2 13 interpreta uma consulta, escolhe índices, calcula custos, acessa páginas e otimiza recursos, deixa de ser apenas alguém que escreve SQL.

Você passa a pensar como o próprio banco de dados.

E, no universo Bellacosa Mainframe, é exatamente aí que começa a verdadeira jornada: não em aprender comandos, mas em aprender a conversar com um dos sistemas mais sofisticados já construídos pela engenharia da computação.

☕🚀 Bem-vindo ao mundo do DB2 13. O primeiro SELECT é simples. O desafio real é transformar consultas em performance, conhecimento e valor para o negócio.

 

🌒 O Eros que dorme no sofá

Por Vagner Bellacosa Mainframe

No início, tudo é incêndio.
Palavras são faíscas, toques viram explosões e o simples olhar acende o corpo inteiro.
É o tempo da dopamina, da conquista, do “te quero agora e não importa onde”.
O mundo se comprime num quarto, e o amor parece ser o próprio milagre da existência.

Mas, aos poucos, o fogo vira brasa.
A rotina entra de mansinho, como quem não quer nada, e começa a organizar o caos.
A cama perde o improviso, o espelho perde o susto, e aquele mistério que fazia o coração tropeçar… adormece.
O Eros, outrora selvagem, se deita no sofá — cansado, domesticado, quase confortável.

Muitos chamam isso de amor maduro.
Outros, de tédio.
Na verdade, é apenas o corpo obedecendo à biologia e o cérebro trocando o vício da paixão pela morfina da estabilidade.
A dopamina dá lugar à oxitocina, e a necessidade de possuir vira medo de perder.
O sexo, que antes era ritual, transforma-se em rotina.
E o toque, antes febril, vira apenas prova de que ainda existe algo — mesmo que pequeno — entre dois mundos que já se afastam.

E é aí que o erro acontece.
Não porque alguém mudou, mas porque o que era conquista virou costume.
A mulher, antes curiosa e livre, agora se protege na previsibilidade.
O homem, que buscava intensidade, se perde no eco do que já foi.
Ambos trocam a vertigem pela certeza, esquecendo que o desejo nasce do abismo — não do conforto.

O fetiche, o risco, o segredo — tudo aquilo que fazia pulsar — é trancado num cofre de culpas.
E o casal que um dia queimava lençóis agora divide o cobertor como quem divide o silêncio.
O amor, paradoxalmente, continua.
Mas o desejo, esse fugitivo, vai dormir em outra casa.

Não há vilões nessa história.
Há apenas a natureza humana tentando conciliar o impossível:
querer segurança sem perder a chama da descoberta.

E talvez o segredo não seja reviver o que foi,
mas continuar curioso — mesmo depois de anos, mesmo com rugas, mesmo com lembranças.
Porque o desejo não morre de velhice,
morre de previsibilidade.

E o Eros, se adormece no sofá,
é só porque esquecemos de chamá-lo para dançar.

Paging no IBM Z — Quando a memória começa a “respirar fundo”

 

Bellacosa Mainframe comenta sobre paginação de memoria no ibm z 

☕ Um Café no Bellacosa Mainframe

Paging no IBM Z — Quando a memória começa a “respirar fundo”

Se a tela anterior mostrava o cérebro relaxado do sistema…
esta aqui mostra a respiração dele.

PAGING RATE IN: 28/SEC
IN DELAY: 0.6 %

Pode parecer algo obscuro, mas na prática isso responde a uma pergunta crucial:

👉 A memória do sistema está sobrando… ou está começando a faltar?

Vamos traduzir isso para o português humano ☕

---

TSO SDSF Simulator

🧠 Primeiro: o que é Paging?

Mesmo um mainframe gigantesco não mantém tudo na memória ao mesmo tempo.

Quando a RAM começa a ficar cheia, o sistema faz algo muito inteligente:

➡️ Move partes pouco usadas da memória para o disco
➡️ Libera espaço para o que está sendo usado agora

Isso se chama:

📦 PAGING (ou paginação)

💡 Analogia Bellacosa™:

Imagine sua mesa de trabalho.

• Papéis importantes → ficam na mesa (RAM)

• Papéis menos usados → vão para a gaveta (disco)

• Quando precisa → você pega da gaveta de volta

O IBM Z faz isso bilhões de vezes por dia.

---

⚡ PAGING RATE IN — “Quantos papéis estão voltando da gaveta”

👉 28/SEC = 28 páginas por segundo voltando do disco para a RAM

Isso indica atividade de paginação para dentro da memória.

Quanto maior esse número:

• Mais o sistema está buscando dados no disco

• Mais lentidão pode ocorrer

• Pode indicar pressão de memória

Mas aqui vem a surpresa…

👉 28 por segundo é praticamente nada para um mainframe

Um z/OS sob estresse pode chegar a milhares por segundo.

💬 Fofoquinha técnica:

Existem ambientes bancários onde o paging é tão bem ajustado que passa dias em zero.

---

⏳ IN DELAY — “Usuários esperando por memória”

👉 0.6%

Esse indicador mostra quanto tempo tarefas ficaram aguardando páginas chegarem do disco.

Em outras palavras:

➡️ Quanto o sistema está “segurando a fila” por falta de memória imediata.

Como interpretar?

• 0% → perfeito

• < 1% → excelente

• 1–5% → atenção

• 10% → problema sério

👉 0.6% = sistema saudável e tranquilo

---

🏥 Diagnóstico geral desta tela

💚 O sistema está:

✔️ Fazendo pouca paginação
✔️ Quase ninguém esperando
✔️ Memória bem dimensionada
✔️ Performance intacta

Em termos humanos:

👉 Ele está respirando calmamente, não ofegante.

---

🧓 História curiosa

Nos anos 70 e 80, tuning de paging era uma arte quase mística.

Operadores ajustavam:

• Tamanhos de page dataset

• Algoritmos de working set

• Prioridades de jobs

• Balanceamento manual

Hoje, o z/OS faz isso com uma sofisticação absurda.

---

🤫 Easter Egg Mainframe

Existe um ditado famoso entre sysprogs:

“Paging is normal. Thrashing is panic.”

Thrashing é quando o sistema passa mais tempo movendo páginas do que executando trabalho.

Felizmente, esta tela está MUITO longe disso.

---

🕵️ Fofoquice corporativa

Algumas instituições configuram alertas automáticos quando:

👉 IN DELAY ultrapassa 2%
👉 Paging rate dispara subitamente

Porque isso pode indicar:

• Pico inesperado de transações

• Job descontrolado

• Vazamento de memória

• Ataque ou loop

• Batch gigante rodando fora da janela

---

🧃 Explicação ultra simples

Se o IBM Z fosse um restaurante:

• Cozinha (RAM) → área principal

• Despensa (disco) → armazenamento

• Garçom trazendo ingredientes → paging IN

• Clientes esperando prato → IN DELAY

👉 Aqui os pratos estão saindo rápido.
Ninguém está reclamando.

---

🚀 Por que isso é impressionante?

Porque estamos falando de sistemas que:

• Processam milhões de transações por segundo

• Mantêm bancos inteiros online

• Não podem travar

• Não podem “ficar lentos”

• Não podem perder dados

E tudo isso com números que parecem… tranquilos.

---

☕ Conclusão

Esta tela é um dos sinais vitais mais importantes do z/OS.

Ela responde silenciosamente:

👉 “Estamos confortáveis ou começando a sufocar?”

Neste caso:

💚 Sistema confortável
💚 Memória adequada
💚 Performance estável
💚 Nenhum drama no horizonte

O tipo de tela que faz um sysprog sorrir discretamente.

💋 O que é o Delivery Health (Deriheru)

 

💋 O que é o Delivery Health (Deriheru)

🔹 1. Origem do nome

Nos anos 1980, com o aumento dos controles sobre os soaplands, muitos empresários buscaram uma alternativa legal.
A ideia era simples:

“Se o cliente não vem ao prazer, o prazer vai até o cliente.”

Para contornar a lei, registraram os negócios como “massagem domiciliar de saúde” — daí o nome Delivery Health.
O “health” é um eufemismo para “prazer físico”.

---

🔹 2. Como funciona

• O cliente escolhe uma atendente por site, catálogo ou aplicativo.

• Faz uma reserva e indica um local (geralmente hotel).

• A profissional vai até o local e oferece massagens e outros serviços sensuais.

• Sexo completo é oficialmente proibido — mas na prática, muitos “extras” são negociados pessoalmente.

O pagamento inclui:

• Taxa da agência (geralmente 60–120 minutos).

• Transporte da atendente.

• Eventuais “opções extras” (roupas, fetiches, tipo de atendimento etc.).

---

🔹 3. Legalidade

O deriheru opera dentro da lei, pois:

• Não possui local fixo de atendimento (evita registro como prostíbulo).

• Oferece “massagem relaxante” e não “sexo explícito”.

⚠️ Porém:

• Qualquer ato sexual explícito não pode ser contratado oficialmente — se houver, é considerado “acordo pessoal”.

• Exploração, tráfico, coerção ou atendimento de menores são crimes severos.

A polícia local fiscaliza as agências, exigindo registro e comprovação de idade das funcionárias.

---

🔹 4. Tipos de Deriheru

O mercado é enorme e dividido por nichos:

Tipo	Descrição
Standard Deriheru	Atendentes comuns, catálogo online, preços médios.
High-Class Deriheru	Mulheres modelo, empresárias ou ex-hostesses; clientes VIP.
JK Deriheru (ilegal)	Fantasia de “colegial” — amplamente perseguido pela polícia.
Mature Deriheru	Mulheres mais velhas, público masculino 40+.
Cosplay Deriheru	Atendentes fantasiadas (enfermeira, policial, anime, etc.).
SM Deriheru	Fetiches e dominação, mas dentro de limites de segurança.

---

🔹 5. Cultura e curiosidades

• 💻 O deriheru é uma indústria digitalizada — com sites que exibem fotos, perfis, avaliações e rankings.

• 🌸 Muitas atendentes se apresentam com nomes artísticos e estilos de comunicação “fofos” (kawaii).

• 💬 Algumas agências permitem conversas prévias por LINE (mensageiro japonês), o que cria laços emocionais.

• 🏮 Há áreas específicas em Tóquio conhecidas por isso — como Ikebukuro e Gotanda.

• 📸 Alguns mangás e dramas japoneses retratam esse universo, como Shinjuku Swan (sobre recrutadores de fūzoku).

---

🔹 6. Por que é tão popular?

• Mais discreto que soapland.

• Mais prático — o cliente não precisa se deslocar para um bairro de prazer.

• Mais acessível financeiramente.

• Permite variedade e anonimato.

Mas também há críticas sociais:

• Muitos veem o deriheru como um símbolo da solidão moderna japonesa — prazer rápido, sem vínculo emocional.

• Algumas mulheres usam o trabalho como fonte paralela de renda, especialmente universitárias.

---

🎭 Conclusão

O Deriheru é a versão moderna do Yoshiwara portátil:
um serviço que adapta o prazer japonês à vida urbana e digital, equilibrando legalidade, sigilo e fantasia.

É uma parte essencial da cultura fūzoku — discreta, codificada e incrivelmente organizada.

JSON no COBOL Mainframe : O Guia Definitivo para um Programador Padawan Entender Como o IBM Z Conversa com o Mundo Moderno

 

Bellacosa Mainframe e o json no cobol

☕ Um Café no Bellacosa Mainframe

JSON no COBOL Mainframe

O Guia Definitivo para um Programador Padawan Entender Como o IBM Z Conversa com o Mundo Moderno

"O COBOL nunca teve dificuldade em processar dados. O desafio sempre foi aprender novos idiomas. JSON é apenas mais um idioma."

---

Introdução

Durante décadas, o mundo Mainframe conversou utilizando formatos extremamente bem definidos.

Arquivos VSAM.

Registros fixos.

Copybooks.

Layouts COBOL.

MQ.

CICS COMMAREA.

IMS.

Tudo extremamente organizado.

Enquanto isso, o restante do mercado passou a utilizar um formato muito mais simples para troca de informações:

JSON (JavaScript Object Notation).

Hoje praticamente toda API REST utiliza JSON.

Aplicativos móveis.

Sites.

Microsserviços.

Open Banking.

Pix.

Cloud.

Inteligência Artificial.

ChatGPT.

IBM watsonx.

Todos utilizam JSON.

E é justamente por isso que um programador COBOL moderno precisa dominar este formato.

A boa notícia?

Desde o Enterprise COBOL V6, a IBM adicionou suporte nativo através dos comandos:

• JSON PARSE

• JSON GENERATE

Sem bibliotecas externas.

Sem escrever um parser manual.

Sem sofrimento.

---

O que é JSON?

JSON é simplesmente uma forma de representar dados usando pares:

nome : valor

Exemplo:

{
   "cliente": "João",
   "idade": 35,
   "saldo": 1250.75,
   "ativo": true
}

Perceba que ele lembra um registro COBOL.

No COBOL escreveríamos:

01 CLIENTE.
   05 NOME        PIC X(30).
   05 IDADE       PIC 9(3).
   05 SALDO       PIC 9(7)V99.
   05 ATIVO       PIC X.

A diferença é apenas o formato.

---

JSON x Copybook

Um copybook descreve campos.

JSON descreve informações.

Copybook:

05 NOME PIC X(30).

JSON

"nome":"Maria"

A IBM simplesmente faz o mapeamento entre ambos.

---

Estrutura básica

Um objeto:

{
   "nome":"Maria",
   "idade":28
}

Um vetor

{
   "telefones":[
      "1111",
      "2222"
   ]
}

Objeto dentro de objeto

{
   "cliente":{
      "nome":"Carlos",
      "cidade":"São Paulo"
   }
}

Tudo isso pode ser representado em COBOL.

---

Como declarar no COBOL

01 WS-CLIENTE.

   05 WS-NOME          PIC X(30).
   05 WS-IDADE         PIC 999.
   05 WS-SALDO         PIC 9(7)V99.
   05 WS-ATIVO         PIC X.

Agora um campo contendo o JSON.

01 WS-JSON.

   05 WS-DADOS PIC X(5000).

Este será o buffer utilizado para leitura ou gravação.

---

Lendo JSON

Imagine receber:

{
   "nome":"Luke",
   "idade":22,
   "saldo":1500.50,
   "ativo":"S"
}

Basta executar:

JSON PARSE WS-DADOS
     INTO WS-CLIENTE
END-JSON

Pronto.

A IBM faz todo o trabalho.

Após isso:

WS-NOME = LUKE

WS-IDADE = 22

WS-SALDO = 1500.50

WS-ATIVO = S

Sem IF.

Sem UNSTRING.

Sem parser.

---

Programa exemplo de leitura

IDENTIFICATION DIVISION.
PROGRAM-ID. JSONREAD.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-JSON.
   05 WS-DADOS PIC X(500).

01 WS-CLIENTE.
   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.
   05 WS-SALDO PIC 9(7)V99.
   05 WS-ATIVO PIC X.

PROCEDURE DIVISION.

MOVE
'{"nome":"Luke","idade":22,"saldo":1500.50,"ativo":"S"}'
TO WS-DADOS

JSON PARSE WS-DADOS
    INTO WS-CLIENTE
END-JSON

DISPLAY WS-NOME
DISPLAY WS-IDADE
DISPLAY WS-SALDO
DISPLAY WS-ATIVO

STOP RUN.

---

Como funciona internamente

O parser da IBM:

1. lê caractere por caractere

2. identifica as chaves

3. procura o campo correspondente

4. converte texto para número

5. grava nas variáveis COBOL

Tudo automaticamente.

---

Gravando JSON

O caminho inverso também existe.

Suponha:

MOVE "ANA" TO WS-NOME

MOVE 30 TO WS-IDADE

MOVE 999.99 TO WS-SALDO

MOVE "S" TO WS-ATIVO

Agora:

JSON GENERATE WS-DADOS
    FROM WS-CLIENTE
END-JSON

Resultado:

{
   "nome":"ANA",
   "idade":30,
   "saldo":999.99,
   "ativo":"S"
}

---

Programa exemplo de geração

IDENTIFICATION DIVISION.
PROGRAM-ID. JSONWRITE.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-DADOS PIC X(1000).

01 WS-CLIENTE.

   05 WS-NOME PIC X(30).
   05 WS-IDADE PIC 999.
   05 WS-SALDO PIC 9(7)V99.
   05 WS-ATIVO PIC X.

PROCEDURE DIVISION.

MOVE "ANA" TO WS-NOME

MOVE 30 TO WS-IDADE

MOVE 1500.75 TO WS-SALDO

MOVE "S" TO WS-ATIVO

JSON GENERATE WS-DADOS
    FROM WS-CLIENTE
END-JSON

DISPLAY WS-DADOS

STOP RUN.

---

Gravando em arquivo

Após gerar o JSON basta gravá-lo normalmente.

WRITE REGISTRO-SAIDA

ou

STRING

WS-DADOS

DELIMITED BY SIZE

INTO REGISTRO

END-STRING

WRITE REGISTRO

Pode ser salvo em:

• Sequential File

• VSAM ESDS

• UNIX USS

• MQ

• FTP

• API REST

• Kafka

• IBM MQ

• z/OS Connect

---

Tratando erros

Nunca assuma que o JSON está correto.

Utilize:

JSON PARSE
...
ON EXCEPTION

DISPLAY "JSON INVALIDO"

NOT ON EXCEPTION

DISPLAY "SUCESSO"

END-JSON

Isso evita que dados inválidos sejam processados.

---

Exemplo completo

JSON PARSE WS-DADOS

INTO WS-CLIENTE

ON EXCEPTION

MOVE "ERRO" TO WS-STATUS

NOT ON EXCEPTION

MOVE "OK" TO WS-STATUS

END-JSON

---

Arrays

JSON

{
 "produtos":[
   "Mouse",
   "Teclado",
   "Monitor"
 ]
}

COBOL

05 PRODUTO OCCURS 10 TIMES.

   10 NOME PIC X(30).

A IBM faz o relacionamento automaticamente quando os nomes e a estrutura são compatíveis.

---

Objetos aninhados

JSON

{
 "cliente":{
   "nome":"Carlos",
   "cidade":"Campinas"
 }
}

COBOL

01 CLIENTE.

   05 DADOS.

      10 NOME PIC X(30).

      10 CIDADE PIC X(20).

---

Valores opcionais

Nem sempre todos os campos existirão.

Exemplo

{
   "nome":"Pedro"
}

Sem idade.

Sem saldo.

Os campos COBOL permanecerão com seus valores iniciais (SPACES, ZEROS ou VALUE), por isso é importante inicializar a estrutura antes do JSON PARSE, geralmente com:

INITIALIZE WS-CLIENTE

---

Campos numéricos

Muito cuidado.

JSON

"idade":"ABC"

Jamais poderá alimentar

PIC 999

O parser gerará exceção.

---

Decimais

JSON

123.45

COBOL

PIC 9(5)V99

O ponto decimal é interpretado automaticamente conforme as regras do compilador e da representação numérica.

---

Booleanos

JSON

true
false

COBOL não possui um tipo booleano tradicional.

Uma prática comum é utilizar:

05 ATIVO PIC X.
   88 CLIENTE-ATIVO VALUE "S".
   88 CLIENTE-INATIVO VALUE "N".

Ou mapear para indicadores específicos conforme o padrão da aplicação.

---

Controle de tamanho

Um erro comum dos iniciantes.

Criar

PIC X(100)

para um JSON de

500 caracteres.

Resultado?

Truncamento.

Sempre dimensione com folga ou utilize áreas compatíveis com o tamanho esperado.

---

Performance

O parser da IBM é extremamente eficiente.

Mesmo assim:

• Evite gerar JSON gigantescos.

• Não faça PARSE repetidamente da mesma informação.

• Reutilize áreas de trabalho.

• Inicialize apenas quando necessário.

• Evite cópias desnecessárias do buffer.

---

Armadilhas

Nomes diferentes

JSON

customerName

COBOL

CLIENTE-NOME

Não haverá correspondência automática sem mecanismos de mapeamento.

---

Campos obrigatórios

Nem sempre existirão.

Sempre valide.

---

Tipos incompatíveis

Número enviado como texto.

Texto enviado como número.

Boolean enviado como string.

São causas clássicas de erro.

---

Caracteres especiais

JSON utiliza UTF-8 com frequência.

Aplicações tradicionais em z/OS podem utilizar EBCDIC.

Em integrações, pode ser necessário converter a codificação antes do JSON PARSE ou após o JSON GENERATE.

---

Riscos

Os maiores riscos não estão no JSON.

Estão nos dados.

Por exemplo:

• JSON malformado.

• Dados incompletos.

• Campos inesperados.

• Tamanho excessivo.

• Conteúdo malicioso.

• Falhas de conversão de caracteres.

• Exposição de informações sensíveis em logs.

Valide sempre a entrada e registre apenas o necessário.

---

Vantagens

Utilizar JSON no Mainframe oferece inúmeras vantagens:

• integração simples com APIs REST;

• comunicação natural com aplicações Java, .NET, Python e Node.js;

• suporte a microsserviços;

• facilidade de integração com nuvem;

• menor necessidade de conversões proprietárias;

• manutenção mais simples;

• suporte nativo do Enterprise COBOL;

• excelente desempenho quando comparado a parsers desenvolvidos manualmente.

---

Onde ele é utilizado?

Hoje praticamente em todos os projetos modernos.

• Open Banking

• PIX

• Internet Banking

• Aplicativos Mobile

• APIs REST

• IBM z/OS Connect

• IBM API Connect

• IBM MQ

• Kafka

• Cloud

• Inteligência Artificial

• IBM watsonx

• Integrações híbridas entre IBM Z e plataformas distribuídas

---

Boas práticas

Um Padawan COBOL deve criar alguns hábitos desde o primeiro dia:

• Inicialize as estruturas antes do processamento (INITIALIZE).

• Utilize ON EXCEPTION e trate todos os erros.

• Dimensione corretamente o buffer JSON.

• Valide obrigatoriedade e formato dos campos.

• Documente o layout esperado.

• Mantenha os nomes consistentes entre JSON e estrutura COBOL sempre que possível.

• Evite expor informações confidenciais em arquivos de log.

• Teste com JSONs válidos, inválidos, incompletos e com dados extremos.

---

Conclusão

Durante muito tempo existiu o mito de que o Mainframe "não falava JSON". Isso deixou de ser verdade há anos. O Enterprise COBOL trouxe comandos nativos que simplificam enormemente a leitura e a geração desse formato, permitindo que aplicações escritas há décadas conversem com APIs modernas, serviços em nuvem, aplicações móveis e plataformas de Inteligência Artificial.

Para um Programador Padawan, aprender JSON significa abrir uma porta para o futuro sem abandonar os fundamentos que fazem do COBOL uma das linguagens mais confiáveis do mundo. Quem domina registros, copybooks e validação de dados aprenderá JSON rapidamente. A diferença está apenas na forma de representar a informação.

O verdadeiro desafio não é escrever JSON PARSE ou JSON GENERATE. É compreender a estrutura dos dados, validar corretamente o conteúdo recebido, tratar exceções, garantir compatibilidade de tipos e proteger informações sensíveis. Esses princípios sempre fizeram parte do desenvolvimento em Mainframe e continuam válidos na era das APIs.

No fim das contas, JSON não substitui o COBOL. Ele amplia sua capacidade de comunicação. E um IBM Z que conversa com o mundo moderno continua fazendo aquilo que sempre fez melhor: processar dados com segurança, desempenho e confiabilidade.

A Ditadura da Beleza Digital nas Redes Sociais

 

Bellacosa Mainframe e a ditadura da beleza digital

☕ Um Café no Bellacosa Mainframe

A Ditadura da Beleza Digital

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Algoritmos, Psicologia, Sociologia e Como a Economia da Atenção Está Reescrevendo os Padrões de Beleza do Século XXI

"O algoritmo não olha para o espelho. Ele olha para as métricas. E, ao fazer isso, acaba amplificando aquilo que nós mesmos escolhemos enxergar."

---

Introdução

Existe uma pergunta aparentemente simples, mas profundamente desconfortável.

Por que quase não existem pessoas "comuns" nas redes sociais?

Abra o Instagram.

Role alguns minutos.

Você verá:

• corpos extremamente definidos;

• rostos praticamente sem imperfeições;

• dentes impecáveis;

• peles sem marcas;

• viagens paradisíacas;

• roupas de luxo;

• casas cinematográficas;

• casais aparentemente perfeitos.

É coincidência?

É manipulação?

É culpa da Inteligência Artificial?

Ou sempre fomos atraídos por determinados padrões de beleza, e agora os algoritmos apenas potencializaram esse comportamento?

A resposta talvez seja uma mistura de tudo isso.

Estamos vivendo uma transformação inédita na história da humanidade.

Pela primeira vez, bilhões de pessoas disputam atenção em um ambiente onde visibilidade pode ser convertida diretamente em dinheiro.

E, nessa nova economia, a aparência deixou de ser apenas uma característica física.

Ela tornou-se um ativo econômico.

---

O Algoritmo Não Ama a Beleza

Existe uma ideia muito difundida de que o Instagram, TikTok ou outras plataformas "preferem pessoas bonitas".

Tecnicamente isso não é correto.

O algoritmo não possui gosto estético.

Ele não acorda pensando:

"Hoje vou mostrar pessoas loiras."

Ele faz algo muito mais simples.

Aprende.

E aprende observando bilhões de interações humanas.

Se milhões de usuários:

• param mais tempo diante de determinado rosto;

• curtem mais determinado tipo de corpo;

• compartilham determinadas imagens;

• comentam determinados vídeos;

o algoritmo interpreta isso como um sinal estatístico.

Não existe julgamento moral.

Existe otimização matemática.

O objetivo é simples:

maximizar atenção.

---

A Atenção Vale Mais do Que Ouro

Na Economia da Atenção, o recurso mais escasso deixou de ser informação.

É atenção.

Cada segundo que permanecemos olhando para uma tela pode gerar receita publicitária.

Isso cria um incentivo poderoso.

Mostrar aquilo que mais prende nossos olhos.

Independentemente do motivo.

Admiração.

Desejo.

Curiosidade.

Inveja.

Indignação.

Tudo isso aumenta engajamento.

---

A Engenharia da Aparência

Ao longo dos últimos anos surgiu uma verdadeira indústria dedicada à otimização da aparência.

Ela reúne:

• fotografia profissional;

• iluminação;

• maquiagem;

• harmonização facial;

• cirurgia plástica;

• personal trainer;

• nutricionistas;

• filtros;

• edição por IA;

• retoques digitais.

O resultado é uma realidade visual extremamente distante da vida cotidiana.

Mesmo pessoas consideradas muito bonitas frequentemente publicam versões cuidadosamente produzidas de si mesmas.

Comparar-se com essas imagens é como comparar um ambiente de produção perfeitamente monitorado com um laboratório cheio de testes.

---

O Efeito Halo

Em 1920, Edward Thorndike descreveu um fenômeno psicológico conhecido como Halo Effect.

Quando percebemos alguém como atraente, tendemos a atribuir automaticamente outras características positivas.

Inteligente.

Competente.

Honesta.

Gentil.

Bem-sucedida.

Mesmo sem qualquer evidência.

Esse viés continua sendo observado em inúmeras pesquisas.

E ajuda a explicar por que rostos considerados atraentes frequentemente recebem mais atenção, confiança e oportunidades.

---

Beauty Premium

Economistas utilizam a expressão Beauty Premium.

Ela descreve a vantagem econômica frequentemente associada à atratividade percebida.

Pesquisas encontraram associações entre aparência física e:

• salários mais altos;

• maiores chances de contratação;

• promoções;

• melhores avaliações;

• maior influência em determinados mercados.

Isso não significa que beleza determine competência.

Significa que seres humanos frequentemente misturam aparência e julgamento.

O algoritmo apenas amplifica esse comportamento.

---

Existe Uma Ditadura da Beleza?

A palavra "ditadura" provoca impacto.

Ela transmite a sensação de imposição.

Sob certo aspecto, essa metáfora faz sentido.

Milhões de pessoas são expostas diariamente aos mesmos padrões visuais.

Mas existe um paradoxo importante.

Ninguém obriga alguém a clicar.

Ninguém obriga alguém a compartilhar.

Ninguém obriga alguém a seguir influenciadores.

O algoritmo aprende justamente aquilo que nós escolhemos consumir.

Nesse sentido, talvez vivamos menos uma ditadura tecnológica e mais uma retroalimentação entre comportamento humano, interesses econômicos e sistemas algorítmicos.

---

Leon Festinger e a Comparação Social

Leon Festinger demonstrou que seres humanos constroem parte de sua identidade comparando-se com outras pessoas.

Esse mecanismo fazia sentido em pequenas comunidades.

Hoje, porém, nossa comparação tornou-se global.

Antes comparávamos nossa casa com a do vizinho.

Hoje com mansões em Beverly Hills.

Antes comparávamos nosso corpo com colegas da escola.

Hoje com modelos, atletas, atores e influenciadores cuidadosamente editados.

A régua tornou-se praticamente inalcançável.

---

Privação Relativa

A sociologia chama esse fenômeno de Privação Relativa.

Não nos sentimos pobres apenas pelo que temos.

Sentimo-nos pobres pelo que vemos.

Uma pessoa pode viver melhor que seus pais e, ainda assim, sentir fracasso ao comparar sua vida com o feed de celebridades.

Nunca tivemos tantos recursos.

Mas talvez nunca tenhamos sentido tanta insuficiência.

---

Pierre Bourdieu e o Capital Estético

Pierre Bourdieu mostrou que riqueza não se resume ao dinheiro.

Existe capital:

• econômico;

• cultural;

• social;

• simbólico.

Na sociedade digital, muitos pesquisadores acrescentam outro elemento.

O capital estético.

Uma aparência valorizada pode abrir portas para:

• contratos;

• publicidade;

• seguidores;

• convites;

• influência;

• renda.

O corpo passa a funcionar como um investimento.

---

O Corpo Como Produto

Na lógica das plataformas, a imagem tornou-se uma vitrine.

Isso transforma o próprio corpo em uma espécie de produto.

Não basta viver.

É preciso parecer viver bem.

Não basta viajar.

É preciso registrar.

Não basta treinar.

É preciso publicar.

Não basta comer.

É preciso fotografar.

O cotidiano converte-se em marketing pessoal.

---

Guy Debord Estava Certo?

Em 1967, Guy Debord publicou A Sociedade do Espetáculo.

Sua principal tese era que a representação passaria a substituir a experiência.

Décadas depois, essa previsão parece assustadoramente atual.

Vivemos para experimentar?

Ou experimentamos para publicar?

O espetáculo deixou de acontecer apenas na televisão.

Agora cabe no bolso.

---

Byung-Chul Han e a Sociedade do Desempenho

O filósofo Byung-Chul Han afirma que deixamos de viver sob uma sociedade disciplinar para viver em uma sociedade do desempenho.

Não somos apenas consumidores.

Somos empreendedores de nós mesmos.

Cada perfil funciona como uma pequena empresa.

Cada fotografia representa marketing.

Cada postagem torna-se publicidade pessoal.

A beleza converte-se em investimento.

---

Zygmunt Bauman

Bauman descreveu uma modernidade líquida.

Tudo muda rapidamente.

Tendências duram semanas.

Padrões estéticos também.

O resultado é insegurança permanente.

Nunca parece suficiente.

Sempre existe uma nova referência.

---

Existe Um Padrão Racial?

Este é um dos temas mais delicados.

Diversos estudos mostram que, historicamente, publicidade, cinema e moda privilegiaram determinados padrões eurocêntricos.

Ao mesmo tempo, as redes ampliaram a visibilidade de influenciadores negros, asiáticos, indígenas, latinos e de inúmeras outras identidades antes pouco representadas.

As duas afirmações podem ser verdadeiras ao mesmo tempo.

Ainda existem assimetrias de representação.

Mas também existe maior diversidade do que em décadas anteriores.

O cenário é dinâmico e varia conforme país, plataforma e nicho.

---

O Lookism

Existe inclusive um termo para discriminação baseada na aparência.

Lookism.

Assim como preconceitos relacionados a gênero, raça ou idade, pesquisadores discutem até que ponto a aparência influencia oportunidades sociais.

Em entrevistas de emprego.

Na escola.

Na política.

Nas redes sociais.

A aparência pode funcionar como vantagem inicial, embora não explique sozinha resultados de longo prazo.

---

A Inteligência Artificial Também Aprende Preconceitos?

Infelizmente, sim.

Modelos de IA são treinados com grandes volumes de dados produzidos por seres humanos.

Se esses dados refletem desigualdades históricas, a IA pode reproduzir parte desses vieses.

Por isso surgiram áreas como:

• AI Fairness;

• Responsible AI;

• Explainable AI;

• Algorithmic Accountability.

O objetivo é tornar sistemas mais transparentes e reduzir discriminações injustificadas.

---

O Grande Paradoxo

As mesmas redes sociais que ampliam padrões estéticos também criaram movimentos como:

• Body Positivity;

• Body Neutrality;

• Moda Inclusiva;

• Diversidade Étnica;

• Inclusão de Pessoas com Deficiência;

• Valorização do Envelhecimento.

Nunca houve tanta pressão estética.

Mas também nunca existiu tanto espaço para contestá-la.

O algoritmo distribui ambos.

Quem decide qual ganhará força somos nós, coletivamente.

---

A Psicologia da Inveja Silenciosa

Poucas emoções são tão mal compreendidas quanto a inveja.

Ela raramente aparece como ódio explícito.

Normalmente surge como sensação de inadequação.

"Por que minha pele não é assim?"

"Por que meu corpo não parece aquele?"

"Por que minha vida não é tão interessante?"

Essas perguntas corroem lentamente a autoestima.

Não porque sejam verdadeiras.

Mas porque a comparação é injusta.

Estamos comparando nossa realidade cotidiana com conteúdos cuidadosamente produzidos.

---

O Custo Invisível

A pressão estética possui consequências reais.

Ansiedade.

Depressão.

Transtornos alimentares.

Uso indiscriminado de procedimentos estéticos.

Endividamento.

Baixa autoestima.

Dependência de validação digital.

Especialistas em saúde mental alertam que esses problemas são multifatoriais — família, cultura, personalidade e contexto também influenciam —, mas a exposição contínua a padrões idealizados pode contribuir para agravá-los em parte da população.

---

O Que Podemos Fazer?

Não existe solução simples.

Mas existem caminhos.

Como indivíduos:

• seguir perfis diversos;

• compreender como funcionam os algoritmos;

• limitar comparações;

• reduzir tempo de exposição;

• desenvolver pensamento crítico.

Como plataformas:

• investir em transparência;

• pesquisar vieses algorítmicos;

• ampliar diversidade de recomendações.

Como educadores:

• ensinar alfabetização midiática;

• discutir autoestima digital;

• mostrar que popularidade não equivale a valor humano.

Como sociedade:

• reconhecer diferentes formas de beleza;

• valorizar competência acima da aparência;

• estimular ambientes digitais mais inclusivos.

---

O Que Todo Programador Mainframe Pode Ensinar

Quem trabalha com IBM Z sabe que um sistema crítico não pode ser avaliado apenas pela interface.

O que realmente importa está nos bastidores.

Arquitetura.

Confiabilidade.

Segurança.

Governança.

Desempenho.

Talvez devêssemos olhar para as pessoas da mesma forma.

A interface gráfica nunca contou toda a história.

---

Conclusão

Talvez a pergunta mais importante não seja:

"O algoritmo favorece pessoas bonitas?"

Talvez seja:

"O que nós ensinamos ao algoritmo a valorizar?"

Os algoritmos não nasceram admirando determinados rostos, corpos ou estilos de vida.

Eles aprenderam observando bilhões de pequenas decisões humanas.

Cada curtida.

Cada compartilhamento.

Cada segundo de atenção.

Cada clique.

No fim, a chamada "ditadura da beleza" não é apenas tecnológica. Ela é também cultural, econômica e psicológica. As plataformas aceleram tendências, os mercados lucram com elas e nós, muitas vezes sem perceber, ajudamos a reforçá-las.

Mas há uma boa notícia.

Se fomos capazes de ensinar máquinas a amplificar certos padrões, também somos capazes de ensinar uma nova geração de algoritmos — e principalmente uma nova geração de pessoas — a valorizar diversidade, autenticidade e competência.

Porque nenhuma Inteligência Artificial decide, sozinha, o que significa ser belo.

Essa decisão continua sendo humana.

E talvez essa seja a responsabilidade mais importante da sociedade digital do século XXI.