☕ 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

quinta-feira, 14 de março de 2024

📜 O Retorno, Parte II — O Velho da Montanha e o Silêncio do Mundo

 


📜 O Retorno, Parte II — O Velho da Montanha e o Silêncio do Mundo
por El Jefe, Bellacosa Mainframe Edition

Dez anos se passaram desde o retorno.
O tempo fez o que sempre faz: apagou alguns rastros, aprofundou outros, deixou a alma com cicatrizes que só se sentem em dias de silêncio.

Cinquenta anos de idade — a curva do caminho onde o corpo desacelera, mas o pensamento ganha fôlego.
Hoje, olho pra trás e me vejo partindo em 2002, cheio de sonhos, cruzando o Atlântico com a cabeça leve e o coração aberto. O mundo parecia vasto, possível, ainda cheio de cores.
A Europa era o cenário, mas o enredo era meu.

Quando voltei, em 2014, o Brasil me pareceu um espelho embaçado.
Agora, dez anos depois, percebo que o mundo inteiro virou esse espelho — rachado, confuso, ruidoso.
Guerras, extremismos, ruínas políticas, falsos profetas de todas as ideologias.
Não existe mais aquele “lá fora” que um dia me encantou.
E o “aqui dentro” aprendeu a se defender ficando quieto.

A dorzinha ainda está aqui.
Não é grito, é suspiro.
Um incômodo discreto, desses que se sentam contigo no fim do dia e perguntam:
“Lembra de quem você era?”

Sim, lembro. E às vezes sinto falta.
Mas entre um voo e outro — Lisboa, Porto, Madrid, Paris — já aprendi que o retorno nunca mais será completo.
Hoje cruzo o oceano como turista, e talvez seja isso que me mantém são: saber que o passado continua lá, mas que não há mais casa possível no tempo.

Meu filho cresce em Portugal.
É estranho vê-lo seguir um caminho que parece o mesmo que um dia escolhi, mas com uma leveza que já não tenho.
Ele é o futuro, eu sou o arquivo — um dataset antigo, ainda funcional, mas lido apenas por quem entende a linguagem.

A política ficou pra trás.
As ilusões também.
Sobrou o professor, o consultor e o velho da montanha — meio ermitão, meio filósofo de estrada, vivendo longe da confusão, aprendendo a ouvir o som do vento e o ruído da própria respiração.

Descobri que a paz não é o oposto da guerra, é a arte de não participar dela.
E que o silêncio, esse companheiro fiel, é o mais honesto dos diálogos.

Hoje, se me perguntam se sou feliz, não sei responder.
Mas sei que sou inteiro — mesmo que em pedaços.
E isso, aos cinquenta, é uma forma de vitória.

☕️ Bellacosa Mainframe — porque algumas almas só rodam bem no modo batch, processando o tempo em silêncio.

quarta-feira, 13 de março de 2024

🌐 Os 12 Macacos, COBOL e a Grande Migração das Tribos Digitais ARCO I — CAPÍTULO III

 

Bellacosa Mainframe e os 12 macaos cobol e cenrusa na itnernet

☕ Um Café no Bellacosa Mainframe

🌐 Os 12 Macacos, COBOL e a Grande Migração das Tribos Digitais

ARCO I — CAPÍTULO III

Do eMule ao Discord — as tribos mudaram de endereço, não desapareceram

Mudamos o protocolo. Mudamos a interface. Mudamos o nome do botão. O usuário, entretanto, continuou sendo assustadoramente humano.



🕰️ 00:02 — COMMUNITY MIGRATION IN PROGRESS

No capítulo anterior, nosso programador COBOL finalmente encontrou uma pista.

Não era o paciente zero.

Não era o Exército dos 12 Macacos.

Não era sequer o culpado.

Era um mapa.

O terminal do Bellacosa Information Control Facility havia mostrado:

BBS
 |
USENET
 |
IRC
 |
ICQ
 |
FÓRUNS
 |
P2P
 |
BLOGS
 |
REDES SOCIAIS
 |
+-- FACEBOOK
+-- TWITTER
+-- REDDIT
+-- INSTAGRAM
+-- WHATSAPP
+-- TWITCH
+-- TELEGRAM
+-- DISCORD

Nosso COBOLzeiro olhou aquilo com preocupação.

— Isso é uma arquitetura?

NO.

— Uma árvore de dependências?

NO.

— Um diagrama de rede?

PARTIALLY.

— Então que diabos é isso?

O terminal respondeu:

MIGRATION HISTORY
OF DIGITAL TRIBES.

Bruce Willis tomou o último gole do café.

— Agora começa a parte complicada.

O COBOLzeiro apontou para o diagrama.

— Mais complicada que uma Internet sem RACF?

Bruce pensou alguns segundos.

— Muito.


🏕️ 1. Antes das redes sociais existiam tribos

Existe uma ideia equivocada de que as redes sociais inventaram comunidades digitais.

Não inventaram.

Muito antes de Facebook, Instagram, Reddit, Discord ou Telegram, pessoas já faziam algo profundamente humano:

encontravam outras pessoas estranhas iguais a elas.

E isso talvez seja uma das maiores contribuições da Internet.

Imagine morar numa cidade pequena em 1994 e possuir um interesse extremamente específico.

Mainframe.

Anime japonês.

Astronomia.

Ferromodelismo.

Ficção científica.

RPG.

Unix.

Radioamadorismo.

História militar.

Você poderia passar anos acreditando que era o único maluco interessado naquilo.

Então entrava na Internet.

Descobria:

YOU ARE NOT ALONE.

Havia cinquenta.

Quinhentos.

Cinco mil.

Talvez cinquenta mil.

A Internet não criou necessariamente a tribo.

Ela tornou possível que seus membros se encontrassem.


🖥️ 2. BBS: quando cada comunidade parecia um pequeno reino

Antes da Web dominar tudo, existiram as Bulletin Board Systems — BBS.

Para um jovem de 2026, explicar uma BBS exige quase arqueologia.

Imagine um computador atendendo chamadas via modem.

Usuários conectavam.

Encontravam:

  • mensagens;

  • arquivos;

  • áreas temáticas;

  • fóruns;

  • jogos;

  • administradores;

  • regras.

Parece familiar?

Claro.

A interface mudou.

A ideia permanece.

O responsável pela BBS era frequentemente chamado de sysop.

O COBOLzeiro imediatamente gosta da palavra.

System Operator.

Finalmente alguém responsável!

Ele pergunta:

— Então o sysop controlava tudo?

Tudo naquela BBS.

— Excelente. E quem controlava todas as BBS?

Ninguém.

O sorriso desaparece.


🧱 3. O primeiro choque: comunidade não é plataforma

Essa distinção acompanhará todo este capítulo.

Uma plataforma é infraestrutura.

Uma comunidade é um grupo social.

As duas coisas podem se sobrepor.

Mas não são iguais.

Imagine:

PLATAFORMA
    |
    +--- COMUNIDADE A
    +--- COMUNIDADE B
    +--- COMUNIDADE C
    +--- COMUNIDADE D

A plataforma fecha.

O que acontece?

Talvez:

COMUNIDADE A ---> NOVA PLATAFORMA
COMUNIDADE B ---> DESAPARECE
COMUNIDADE C ---> DUAS PLATAFORMAS
COMUNIDADE D ---> GRUPO PRIVADO

Derrubar a praça não necessariamente elimina as pessoas que se encontravam nela.

Elas podem simplesmente procurar outro bar.


📰 4. Usenet: o Reddit antes do Reddit?

Toda comparação histórica é perigosa.

Mas algumas são úteis.

A Usenet permitia discussões organizadas em newsgroups.

Assuntos diferentes.

Comunidades diferentes.

Conversas distribuídas.

Pessoas respondendo umas às outras.

Discussões técnicas.

Debates.

Brigas.

Especialistas.

Excêntricos.

Trolls.

Ou seja:

a humanidade já estava completamente instalada.

Quando alguém diz:

"As redes sociais fizeram as pessoas brigarem."

Um veterano da Usenet pode responder:

"Meu jovem..."

A Internet não precisou inventar conflito humano.

Apenas forneceu largura de banda.


💬 5. IRC: a praça que desaparecia quando você saía

Então chegamos ao Internet Relay Chat.

IRC.

Para muita gente, a palavra imediatamente traz outra:

mIRC.

Tecnicamente, não são a mesma coisa.

IRC é protocolo/ecossistema.

mIRC tornou-se um cliente extremamente popular no Windows.

Mas culturalmente os dois ficaram profundamente associados.

Você entrava em redes.

Escolhia canais.

/join #canal

E encontrava gente.

Muita gente.

Algumas normais.

Outras definitivamente não.


🧙 6. O operador do canal tinha poder

IRC possuía hierarquias.

Operators.

Moderadores.

Bots.

Regras.

Banimentos.

Identidades.

Apelidos.

Conflitos.

Se isso está começando a parecer familiar, ótimo.

Porque chegaremos ao Discord.

Mas primeiro precisamos observar uma coisa importante.

O IRC demonstrava que uma comunidade digital cria governança mesmo quando a infraestrutura geral não possui governo central.

Um canal podia estabelecer:

RULE 01 - NÃO FAÇA X
RULE 02 - NÃO FAÇA Y
RULE 03 - RESPEITE O OP

Alguém fazia X.

KICK

Voltava.

BAN

Então começava a discussão filosófica:

"CENSURA!"

Algumas coisas realmente nunca mudam.


🔐 7. Liberdade na Internet nunca significou ausência de regras

Este é um ponto essencial.

Mesmo comunidades antigas consideradas extremamente livres possuíam normas.

Às vezes escritas.

Às vezes culturais.

Às vezes impostas tecnicamente.

A diferença era quem possuía autoridade.

ESTADO
PLATAFORMA
ADMINISTRADOR
MODERADOR
OPERADOR
COMUNIDADE

São camadas diferentes.

Um operador de canal impedir alguém de falar naquele canal não equivale automaticamente ao Estado impedir aquela pessoa de falar em qualquer lugar.

Isso parece óbvio.

Na prática, discussões digitais misturam essas coisas continuamente.

Guardaremos essa bomba para o Capítulo IV.

Hoje estamos apenas seguindo as tribos.


🌸 8. ICQ: "Uh-oh!"

Então surgiu uma criatura inesquecível.

ICQ.

Para determinada geração, aquele som:

Uh-oh!

produz memória instantânea.

O ICQ trouxe uma experiência mais pessoal.

Você possuía um número.

Uma identidade.

Uma lista de contatos.

Mensagens.

Presença.

Online.

Offline.

Away.

As relações digitais começaram a ficar menos parecidas com entrar numa praça pública e mais parecidas com possuir uma rede pessoal persistente.

Isso é uma mudança importante.

No IRC:

ENTRO NO CANAL
      |
      v
ENCONTRO PESSOAS

No mensageiro:

TENHO PESSOAS
      |
      v
CONVERSO DIRETAMENTE

A topologia social estava mudando.


🧠 9. O número virou identidade

Algo curioso aconteceu com ICQ e serviços semelhantes.

Um identificador técnico podia ganhar valor emocional.

Era apenas um número.

Mas não era apenas um número.

Era:

IDENTIFIER
    +
HISTORY
    +
CONTACTS
    +
MEMORY
    =
DIGITAL IDENTITY

Esse é um fenômeno que acompanhará todas as redes seguintes.

Perfis deixam de ser apenas registros.

Eles acumulam história.

Mensagens.

Relacionamentos.

Fotos.

Reputação.

Memórias.

Um USER-ID começa a parecer uma extensão da pessoa.

E quando uma plataforma suspende aquela identidade, a experiência subjetiva pode ser muito maior que:

ACCOUNT STATUS = DISABLED

Para o usuário:

apagaram parte da minha vida digital.


🗂️ 10. Os fóruns: cada assunto ganhou sua cidade

Então vieram fóruns por toda parte.

Tecnologia.

Jogos.

Automóveis.

Música.

Cinema.

Política.

Anime.

Programação.

Linux.

Mainframe.

Qualquer coisa.

Um fórum era quase uma pequena cidade.

Existiam:

  • administradores;

  • moderadores;

  • veteranos;

  • novatos;

  • especialistas;

  • trolls;

  • regras;

  • reputação;

  • guerras antigas;

  • usuários banidos;

  • usuários que voltavam com outro nome.

Se você chegasse e perguntasse algo discutido 437 vezes, alguém respondia:

USE A BUSCA!

Era o equivalente digital de ser expulso da aldeia.


🧬 11. Fóruns criaram memória comunitária

Aqui temos uma diferença importante em relação ao chat.

Chat é fluxo.

Fórum é arquivo.

No IRC uma conversa podia desaparecer rapidamente da experiência comum.

No fórum:

POST
 |
 v
THREAD
 |
 v
INDEX
 |
 v
SEARCH
 |
 v
YEARS LATER

Um usuário poderia encontrar em 2008 uma discussão escrita em 2003.

A comunidade ganhou memória.

Isso é poderoso.

Também perigoso.

Porque agora uma frase antiga pode sobreviver ao contexto em que foi escrita.

Bem-vindo ao futuro das redes sociais.


🫏 12. eMule: a tribo começa a trocar mais que palavras

Chegamos novamente ao nosso burro favorito.

eMule.

P2P transformou a circulação de arquivos.

Até então nossa tribo principalmente:

TALKED

Agora ela também:

SHARED

E isso mudou a economia da Internet.

Música.

Vídeos.

Software.

Documentos.

Imagens.

Distribuições Linux.

Arquivos legítimos.

Arquivos pirateados.

Conteúdo ilegal.

Praticamente tudo podia aparecer em ecossistemas P2P.

E aqui o problema de governança explode.


🕸️ 13. Cadê o servidor?

Nosso COBOLzeiro pergunta novamente:

— Onde está o servidor?

Alguém responde:

— Qual?

— O servidor onde está o arquivo.

— Pode estar em vários usuários.

— Então derruba esses usuários.

— Outros podem ter cópias.

— Derruba as cópias.

— Podem existir outras.

— Quantas?

— Não sabemos.

O programador fica em silêncio.

Finalmente:

MOVE 'VOU EMBORA' TO WS-ESTADO-EMOCIONAL.

P2P demonstrou brutalmente uma característica fundamental da informação digital:

copiar é barato.

Muito barato.

E cada cópia pode virar uma nova origem.


📦 14. O arquivo tornou-se quase imortal

No mundo físico:

LIVRO ORIGINAL
     |
     v
DESTRUIR

Talvez o conteúdo desapareça se aquela for a única cópia.

No digital:

FILE
 |
 +--> COPY A
 |
 +--> COPY B
 |
 +--> COPY C
 |
 +--> COPY D
         |
         +--> COPY E
         +--> COPY F

Você remove FILE.

Ainda existem A, B, C, D, E e F.

É aqui que o conceito do Capítulo I retorna:

DELETE INTERNET

continua não funcionando.


🌐 15. E então a Web ficou social

No início da Web, muita gente ainda pensava em páginas.

Você visitava um site.

Depois outro.

Depois outro.

A grande transformação foi quando o site começou a ser menos:

DOCUMENT

e mais:

PLACE WHERE PEOPLE LIVE

Entramos na era das grandes redes sociais.

E a arquitetura social mudou novamente.


👤 16. Facebook: a Internet ganha nome e sobrenome

O Facebook ajudou a popularizar uma mudança cultural enorme:

identidade persistente e rede social explícita.

Amigos.

Fotos.

Família.

Trabalho.

Relacionamentos.

Escola.

Cidade.

Grupos.

Eventos.

A Internet que durante anos celebrara apelidos começou a exigir cada vez mais:

"Quem é você no mundo físico?"

Isso mudou comportamento.

Mas não eliminou as tribos.

Elas ganharam:

grupos.

O velho fórum reapareceu dentro de uma plataforma gigantesca.


🧱 17. A plataforma virou continente

Essa mudança é gigantesca.

Antes:

SITE A
SITE B
SITE C
FÓRUM D
CHAT E

Agora:

             FACEBOOK
          /      |       \
       GRUPO A GRUPO B GRUPO C
         |       |        |
      PESSOAS  PESSOAS  PESSOAS

A comunidade não precisava manter servidor.

Não precisava desenvolver software.

Não precisava administrar infraestrutura.

A plataforma fazia isso.

Em troca, a plataforma passou a possuir enorme poder sobre:

  • regras;

  • alcance;

  • identidade;

  • recomendação;

  • remoção;

  • monetização.

Centralizamos a praça.


📸 18. Instagram: quando a imagem virou dialeto

Instagram adicionou outra transformação.

A imagem passou a ocupar posição central.

Uma comunidade não precisava mais existir apenas em texto.

Estética tornou-se linguagem.

Hashtags funcionaram como mecanismo de descoberta.

Fotos criaram identidade.

Stories adicionaram efemeridade.

Vídeos ampliaram ainda mais a linguagem.

Uma subcultura podia ser identificada por:

  • estética;

  • roupas;

  • poses;

  • símbolos;

  • hashtags;

  • referências visuais.

Agora imagine moderar isso usando apenas:

IF TEXT CONTAINS BAD-WORD

Boa sorte.


🧠 19. O código deixou de ser apenas palavra

Nos capítulos anteriores falamos sobre vocabulário.

Agora o problema cresce.

Comunidades podem comunicar identidade através de:

TEXT
IMAGE
EMOJI
MEME
AUDIO
VIDEO
REFERENCE
IRONY
CONTEXT

Um símbolo pode significar uma coisa para 99% da população e outra para determinada subcultura.

É por isso que moderação contextual é tão difícil.

O computador pergunta:

— O que significa esta imagem?

A resposta correta frequentemente é:

— Depende de quem publicou, onde, quando, para quem e por quê.

O COBOLzeiro começa a sentir saudades de PIC X(80).


📱 20. WhatsApp: a tribo entra na sala fechada

Então chegamos à mensageria moderna.

WhatsApp mudou profundamente a dinâmica.

Grupos.

Família.

Amigos.

Empresas.

Escolas.

Condomínios.

Trabalho.

Política.

Comunidades.

Tudo dentro de ambientes de comunicação mais privados.

A praça pública transformou-se parcialmente em salas.

Isso muda a moderação.

No feed público:

PLATFORM CAN OBSERVE CONTENT

Em sistemas com criptografia de ponta a ponta e comunicação privada, a arquitetura é diferente.

A pergunta passa a ser:

Como proteger usuários sem transformar comunicação privada numa sala permanentemente vigiada?

Não existe resposta trivial.


🕵️ 21. Privacidade e segurança entram em colisão

Temos dois valores legítimos:

PRIVACY

e:

SAFETY

Se aumentarmos vigilância indiscriminadamente em nome da segurança, podemos destruir privacidade.

Se tratarmos privacidade como argumento absoluto contra qualquer mecanismo de investigação legal, podemos dificultar a proteção contra crimes reais.

Esse equilíbrio é uma das discussões centrais da sociedade digital.

E fica ainda mais sensível quando crianças e adolescentes entram na equação.

Capítulo IV.

Calma.

Estamos chegando.


📰 22. Twitter/X: a praça pública toma anfetamina

Twitter, hoje X, trouxe outra dinâmica.

Curtíssimo ciclo de publicação.

Comentários.

Reposts.

Hashtags.

Trending topics.

Jornalistas.

Políticos.

Empresas.

Celebridades.

Especialistas.

Anônimos.

Bots.

Tudo no mesmo lugar.

Imagine a praça central de uma cidade.

Agora dê um megafone para todo mundo.

Depois instale um contador dizendo quantas pessoas ouviram cada grito.

Depois crie um sistema capaz de aumentar o alcance de alguns gritos.

Finalmente permita que todos respondam simultaneamente.

Pronto.


🔥 23. Context collapse

Nas comunidades antigas, contexto era frequentemente local.

Uma piada dentro de um fórum era entendida pelos membros.

Nas grandes redes:

COMMUNITY A
    |
    | SCREENSHOT
    v
COMMUNITY B
    |
    | REPOST
    v
PUBLIC INTERNET

Uma frase criada para cinquenta pessoas pode aparecer diante de cinco milhões.

Isso é context collapse.

O contexto colapsa.

A audiência original desaparece.

A frase permanece.

É como pegar uma mensagem de CICS escrita para um operador experiente e colocar num outdoor no centro da cidade.

Provavelmente alguém entenderá errado.


🟠 24. Reddit: milhares de pequenas aldeias dentro da metrópole

Reddit recupera algo muito antigo da cultura online:

comunidades temáticas relativamente autônomas.

Subreddits.

Cada um pode possuir:

  • regras;

  • moderadores;

  • cultura;

  • vocabulário;

  • memes;

  • tolerâncias diferentes.

Parece familiar?

Usenet.

Fóruns.

BBS.

A interface mudou.

A ideia voltou.

Isso é uma constante fascinante da história digital:

nós reinventamos a aldeia.

Depois centralizamos.

Depois descobrimos que queremos aldeias novamente.


🎮 25. Twitch: agora a tribo está ao vivo

Twitch adiciona uma variável particularmente cruel para moderação:

TIME = NOW

Vídeo ao vivo.

Chat ao vivo.

Milhares de pessoas.

Reação instantânea.

No fórum, um moderador pode encontrar uma mensagem horas depois.

Numa transmissão ao vivo:

EVENT
 |
 v
REACTION
 |
 v
CLIP
 |
 v
REPOST

Tudo pode acontecer em segundos.

A latência da governança tornou-se parte do problema.


✈️ 26. Telegram: quando canal e grupo ganham escala

Telegram combina diferentes modelos.

Mensagens.

Grupos.

Canais.

Comunidades.

Bots.

Distribuição.

Ambientes públicos e privados.

Isso cria possibilidades legítimas extraordinárias.

Educação.

Notícias.

Projetos.

Comunidades.

Organização.

Também cria desafios de moderação e investigação quando recursos são utilizados de forma abusiva ou criminosa.

A ferramenta não determina automaticamente a intenção.

Um martelo pode construir uma casa.

A arquitetura, porém, determina o que é fácil fazer em escala.

Essa diferença importa.


🎧 27. E finalmente: Discord

Nosso COBOLzeiro finalmente chega ao nome que estava esperando.

Discord.

Ele abre.

Observa.

Servidores.

Canais.

Texto.

Voz.

Vídeo.

Bots.

Roles.

Permissões.

Moderadores.

Comunidades.

Convites.

Mensagens privadas.

Ele fica parado.

Então fala:

— Eu conheço isso.

Bruce Willis olha desconfiado.

— Conhece?

— Isso é IRC depois de fazer um MBA.

Não é tecnicamente uma definição adequada.

Mas culturalmente...

não está tão longe.


🏰 28. Discord é menos uma praça e mais um prédio

Uma boa metáfora é pensar no Discord como um edifício.

A plataforma é a cidade.

Um servidor é um prédio.

Dentro:

SERVIDOR
 |
 +-- #GERAL
 |
 +-- #TECNOLOGIA
 |
 +-- #MEMES
 |
 +-- #OFF-TOPIC
 |
 +-- VOZ
 |
 +-- STAFF
 |
 +-- BOTS

Algumas salas são públicas aos membros.

Outras restritas.

Alguns usuários possuem funções especiais.

Administradores controlam permissões.

É uma arquitetura social sofisticada.

E isso cria um desafio enorme:

Discord não é uma única comunidade.

Existem incontáveis comunidades dentro dele.


🔑 29. ROLE é quase RACF — quase

Nosso programador imediatamente gosta das roles.

Finalmente!

Permissões!

Ele começa:

USER
 |
 +-- ROLE
       |
       +-- READ
       +-- WRITE
       +-- MODERATE
       +-- ADMIN

— RACF!

Bruce Willis interrompe:

— Calma.

Roles lembram conceitos de controle de acesso.

Mas não existe equivalência simples entre administração de um servidor social e segurança corporativa de mainframe.

Ainda assim, a analogia ajuda.

A pergunta fundamental continua:

quem pode fazer o quê, em qual recurso?

Isso é autorização.

Desde o mainframe até Discord, alguém eventualmente precisa responder essa pergunta.


👮 30. O moderador virou operador de uma pequena sociedade

Aqui começa o problema.

Administrar um servidor não é apenas configurar canais.

Quando a comunidade cresce, surgem:

  • conflitos;

  • spam;

  • assédio;

  • golpes;

  • contas falsas;

  • comportamento abusivo;

  • denúncias;

  • conteúdo inadequado;

  • usuários menores de idade;

  • possíveis crimes.

O adolescente que criou um servidor para conversar sobre videogame pode descobrir subitamente que administra uma comunidade com vinte mil pessoas.

Sem curso.

Sem departamento jurídico.

Sem SOC.

Sem treinamento.

Sem café suficiente.

Ele virou uma espécie de:

SYSOP
MODERATOR
SECURITY
HELP DESK
HR
POLICE?
JUDGE?
THERAPIST?

Não.

Ele não é todas essas coisas.

Mas usuários frequentemente esperam que seja.


🚨 31. Aqui começa o verdadeiro problema do Discord

E chegamos à razão pela qual esta série nasceu.

Quando algo grave acontece numa comunidade digital, surgem perguntas:

Quem sabia?

Quem deveria saber?

Quem poderia impedir?

O moderador tinha responsabilidade?

A plataforma tinha responsabilidade?

O usuário cometeu crime?

Era apenas conteúdo ofensivo?

Havia criança ou adolescente envolvido?

A mensagem era pública ou privada?

Existe dever de preservação?

Existe obrigação de denúncia?

Qual legislação se aplica?

Agora estamos muito além de:

/kick usuario

Entramos em direito.


👶 32. E então uma criança entra no servidor

O terminal muda de cor.

Até agora nosso COBOLzeiro estava relativamente confortável.

Brigas.

Memes.

Bots.

Permissões.

Moderadores.

Tudo administrável.

Então aparece:

USER TYPE:
MINOR

Silêncio.

Bruce Willis larga a caneca.

Nosso programador pergunta:

— Isso muda alguma coisa?

O terminal responde:

YES.

— Quanto?

A LOT.

É aqui que termina nossa arqueologia.

Porque quando crianças e adolescentes entram em ambientes digitais, a discussão sobre liberdade, privacidade e moderação ganha outra dimensão.

No Brasil existe uma sigla que mudará completamente nosso próximo capítulo:

ECA.


⚖️ 33. A plataforma não substitui a lei

Um erro comum é imaginar:

"Se a plataforma permite, então é legal."

Não.

Termos de serviço não substituem legislação.

Outro erro:

"Se a plataforma proíbe, então é crime."

Também não.

Podemos representar assim:

              CONDUTA
                 |
        +--------+--------+
        |                 |
   LEGISLAÇÃO         PLATAFORMA
        |                 |
   LEGAL/ILEGAL      PERMITIDO/PROIBIDO

Esses eixos podem produzir combinações diferentes.

Algo pode ser:

LEGAL + PROIBIDO PELA PLATAFORMA

Ou:

ILEGAL + OBVIAMENTE PROIBIDO

A moderação trabalha com regras privadas.

O sistema jurídico trabalha com leis e garantias.

Misturar os dois produz confusão.


🧠 34. A subcultura sobrevive à plataforma

Agora podemos responder à pergunta principal deste capítulo.

Por que comportamentos parecem reaparecer em plataformas diferentes?

Porque comunidades carregam cultura.

Quando migram, levam:

MEMBERS
LANGUAGE
MEMES
HISTORY
NORMS
CONFLICTS
KNOWLEDGE
CONTACTS

Talvez mudem de nome.

Talvez mudem de símbolo.

Talvez adotem novas ferramentas.

Mas existe continuidade.

Uma comunidade de fórum pode migrar para Facebook.

Depois WhatsApp.

Depois Telegram.

Depois Discord.

A infraestrutura mudou quatro vezes.

A rede social humana permaneceu parcialmente conectada.


🧬 35. Migração também produz mutação

Mas cuidado.

Não estamos dizendo que tudo permanece igual.

A plataforma modifica a comunidade.

IRC favorece determinado comportamento.

Fórum favorece outro.

Instagram privilegia visualidade.

Twitter/X favorece comunicação curta e pública.

WhatsApp favorece redes relacionais privadas.

Twitch adiciona transmissão ao vivo.

Discord organiza comunidades persistentes em servidores e canais.

A cultura entra na plataforma.

A arquitetura modifica a cultura.

Depois a cultura modifica o uso da plataforma.

Temos novamente:

HUMANS
   |
   v
PLATFORM
   |
   v
BEHAVIOR
   |
   v
CULTURE
   |
   +------> PLATFORM ADAPTATION
               |
               v
             HUMANS

Outro feedback loop.

Os 12 Macacos continuam sorrindo.


🏃 36. Banir pode provocar migração

Agora chegamos a um fenômeno importante.

Uma comunidade viola regras.

A plataforma intervém.

Contas são suspensas.

Grupo removido.

Servidor encerrado.

Problema resolvido?

Às vezes parcialmente.

Mas pode ocorrer:

COMMUNITY
    |
    v
BAN
    |
    v
MIGRATION
   / \
  /   \
A     B

Isso não significa que banir seja inútil.

Pode reduzir alcance.

Pode aumentar fricção.

Pode proteger usuários.

Pode impedir recrutamento dentro daquele ambiente.

Pode desorganizar redes.

Mas remoção de infraestrutura não garante automaticamente eliminação da comunidade.

Essa distinção é essencial.


🪳 37. Resiliência distribuída

Aqui nosso mainframeiro reconhece algo.

Resiliência.

Só que aplicada a comunidades.

Em sistemas críticos queremos:

NO SINGLE POINT OF FAILURE

Na Internet, comunidades também podem desenvolver isso involuntariamente.

Possuem:

DISCORD
+
TELEGRAM
+
WHATSAPP
+
REDDIT
+
WEBSITE
+
BACKUP CONTACTS

Uma plataforma cai.

Outra mantém conexões.

A arquitetura que torna movimentos legítimos resistentes à censura também pode tornar comunidades problemáticas resistentes à moderação.

A tecnologia não pergunta:

"Sua causa é moralmente boa?"

Ela executa protocolos.


🗡️ 38. A mesma ferramenta, resultados opostos

Criptografia protege:

  • jornalistas;

  • empresas;

  • cidadãos;

  • vítimas;

  • pesquisadores;

  • ativistas;

  • famílias.

Também pode ser utilizada por criminosos.

Anonimato pode proteger dissidentes.

Também pode proteger abusadores.

Comunidades privadas podem permitir apoio psicológico.

Também podem esconder comportamentos prejudiciais.

Compartilhamento distribuído pode manter conhecimento disponível.

Também pode distribuir material ilegal.

Essa dualidade acompanha praticamente toda tecnologia de comunicação.

É o velho problema:

TOOL != INTENT

Mas:

ARCHITECTURE AFFECTS CAPABILITY

As duas afirmações podem ser verdadeiras simultaneamente.


🐒 39. O Exército dos 12 Macacos muda de servidor

03:59.

O terminal começa a emitir alertas.

COMMUNITY DETECTED.

LOCATION: IRC

Depois:

CONNECTION LOST.

Nosso programador comemora.

— Acabou!

O terminal responde:

NEGATIVE.

COMMUNITY DETECTED.

LOCATION: FORUM

— Derruba!

CONNECTION LOST.

— Agora acabou.

NEGATIVE.

LOCATION: FACEBOOK GROUP.

— Outra vez?

LOCATION CHANGED:
WHATSAPP

Depois:

TELEGRAM

Depois:

DISCORD

O COBOLzeiro bate na mesa.

— Eles ficam migrando!

Bruce Willis responde:

— Finalmente você entendeu.


☕ 40. O sysprog encontra o verdadeiro dataset

Nosso programador tenta outra abordagem.

LIST COMMUNITY MEMBERS

O sistema mostra usuários.

Ele percebe algo.

Os nomes mudaram.

Os nicknames mudaram.

As plataformas mudaram.

Mas algumas relações permaneceram.

Então pergunta:

WHERE IS COMMUNITY STORED?

O terminal responde:

INVALID QUESTION.

— Como assim?

Ele tenta:

LOCATE COMMUNITY DATASET

Resposta:

DATASET NOT FOUND.

Irritado:

WHERE DOES THE COMMUNITY EXIST?

Finalmente:

IN RELATIONSHIPS
BETWEEN PEOPLE.

Silêncio.

Essa é a resposta.


🕸️ 41. A comunidade é o grafo

Pense como um grafo.

       ALICE
      /     \
     /       \
  BOB ------ CAROL
   |           |
   |           |
 DAVID ------ EVA

Facebook pode desaparecer.

As conexões podem continuar.

Discord pode fechar um servidor.

Alice talvez ainda tenha Bob no Telegram.

Bob conhece Carol no WhatsApp.

Carol possui contato de Eva.

Eva cria outro servidor.

O grafo social sobrevive parcialmente à infraestrutura.

Esse é o verdadeiro mecanismo de migração.

Não estamos migrando apenas dados.

Estamos migrando relações.


🤯 42. O pesadelo do COBOLzeiro

Agora nosso veterano finalmente percebe por que estava fazendo a pergunta errada.

Ele procurava:

COMMUNITY.MASTER.FILE

Não existe.

Procurava:

COMMUNITY.ADMIN.USER

Pode haver vários.

Procurava:

CENTRAL.CONTROL

Não necessariamente existe.

A comunidade está distribuída entre:

  • memória;

  • contatos;

  • confiança;

  • reputação;

  • linguagem;

  • plataformas;

  • identidades.

Ele olha para Bruce Willis.

— Isso é o pior banco de dados que já vi.

Bruce responde:

— Espere até conhecer seres humanos.


🚨 43. O terminal detecta uma nova variável

De repente:

WARNING
WARNING
WARNING

Tela vermelha.

COMMUNITY ANALYSIS UPDATED.

ADULT USERS............... DETECTED
MINOR USERS............... DETECTED

JURISDICTION.............. BRAZIL

LEGAL FRAMEWORK SEARCH....

CONSTITUIÇÃO.............. FOUND
MARCO CIVIL............... FOUND
PENAL LAW................. FOUND
ECA....................... FOUND

RISK LEVEL................ INCREASED

Nosso programador pergunta:

— O que mudou?

Resposta:

AGE CHANGES THE MODEL.

👶 44. A idade não é apenas mais um campo

Em sistemas comerciais podemos ter:

05 CUSTOMER-AGE PIC 9(03).

Parece apenas dado.

Mas juridicamente idade pode alterar profundamente relações, proteções e responsabilidades.

Quando crianças e adolescentes entram numa comunidade digital, precisamos considerar proteção especial.

Não basta dizer:

"Mas todo mundo entrou voluntariamente."

Não basta dizer:

"Estava num grupo privado."

Não basta dizer:

"Era apenas uma brincadeira."

Dependendo da conduta, essas frases podem ser juridicamente irrelevantes.

E também precisamos evitar o extremo oposto:

"Havia um menor no servidor, portanto qualquer conversa estranha era crime."

Também não.

Direito exige distinguir condutas.

Contexto importa.

Fatos importam.

Tipificação importa.


⚖️ 45. O próximo capítulo não terá botão fácil

Até agora brincamos com:

KICK
BAN
DELETE
BLOCK

No próximo capítulo precisaremos separar cuidadosamente:

CENSURA
      !=
MODERAÇÃO

MODERAÇÃO
      !=
INVESTIGAÇÃO

VIOLAÇÃO DE TERMOS
      !=
CRIME

CONTEÚDO OFENSIVO
      !=
AUTOMATICAMENTE ILEGAL

LIBERDADE DE EXPRESSÃO
      !=
IMUNIDADE JURÍDICA

E existe ainda:

CRIANÇA / ADOLESCENTE
      =
PROTEÇÃO JURÍDICA ESPECIAL

Agora o jogo muda.


🐒 46. Easter egg: USER TYPE = MINOR

O terminal imprime:

BELLACOSA INFORMATION CONTROL FACILITY
---------------------------------------

COMMUNITY MIGRATION TRACE COMPLETE.

BBS.................... ARCHIVED
USENET................. ARCHIVED
IRC.................... MIGRATED
ICQ.................... MIGRATED
FORUMS................. MIGRATED
P2P.................... DISTRIBUTED
FACEBOOK............... ACTIVE
INSTAGRAM.............. ACTIVE
WHATSAPP............... ACTIVE
REDDIT................. ACTIVE
X/TWITTER.............. ACTIVE
TWITCH................. ACTIVE
TELEGRAM............... ACTIVE
DISCORD................ ACTIVE

CONCLUSION:

PLATFORMS CHANGE.
HUMAN NETWORKS SURVIVE.

---------------------------------------

NEW EVENT:

USER TYPE.............. MINOR
LOCATION............... BRAZIL

LOADING...

ECA
CONSTITUTION
CRIMINAL LAW
PLATFORM RULES

WARNING:

DO NOT CONFUSE
"ALLOWED BY PLATFORM"
WITH
"ALLOWED BY LAW".

DO NOT CONFUSE
"PROHIBITED BY PLATFORM"
WITH
"CRIME".

---------------------------------------

Nosso COBOLzeiro olha para a tela.

— Posso dar BAN?

Bruce Willis responde:

— Talvez.

— Posso chamar a polícia?

— Depende do que aconteceu.

— É censura?

— Depende de quem fez o quê.

— É crime?

— Depende da conduta.

O programador fecha os olhos.

— Finalmente chegamos ao pior sistema legado de todos.

— Qual?

Bruce aponta para uma estante.

— Direito.

O COBOLzeiro observa os códigos, leis, decisões, regulamentos e jurisprudência.

Sorri.

— Isso eu entendo.

Bruce fica surpreso.

— Entende?

— Claro.

— Como?

Ele pega o café.

— Milhões de linhas acumuladas durante décadas, compatibilidade histórica, patches, exceções, interpretações, dependências, documentação espalhada e ninguém ousa reescrever tudo do zero.

Bruce Willis fica em silêncio.

— Meu Deus.

— O quê?

— Você acabou de comparar o sistema jurídico com COBOL.

— E estou errado?

Longo silêncio.

ANSWER NOT FOUND.

🖥️ FINAL DO CAPÍTULO III

O Bellacosa Mainframe executa a última rotina:

BELLACOSA MAINFRAME
INFORMATION CONTROL FACILITY
---------------------------------------

ARC I STATUS

CHAPTER I
INFORMATION OUTBREAK......... COMPLETE

CHAPTER II
DISCOVERY PATH............... COMPLETE

CHAPTER III
DIGITAL TRIBES............... COMPLETE

PATIENT ZERO................. NOT FOUND

COMMUNITY MASTER FILE........ NOT FOUND

CENTRAL INTERNET OWNER....... NOT FOUND

HUMAN NETWORK................ ACTIVE

---------------------------------------

IMPORTANT DISCOVERY:

A COMMUNITY IS NOT
THE SERVER WHERE IT LIVES.

THE COMMUNITY IS
THE RELATIONSHIP BETWEEN
THE PEOPLE INSIDE IT.

---------------------------------------

NEW INCIDENT:

JURISDICTION................. BRAZIL
MINORS....................... PRESENT
CONTENT...................... UNDER REVIEW
PLATFORM..................... DISCORD

LOADING LEGAL MODULE...

ECA.......................... READY
CONSTITUTION................. READY
PLATFORM RULES............... READY

WARNING:

NEXT CHAPTER REQUIRES
DISTINCTION BETWEEN

FREEDOM
MODERATION
CENSORSHIP
AND CRIME.

---------------------------------------

CONTINUE? Y/N

===> Y

Enter.

A tela apaga.

Durante alguns segundos não acontece nada.

Então surge apenas uma frase:

FREE SPEECH DOES NOT MEAN
PERFORM ANYTHING UNTIL END-OF-INTERNET.

Nosso COBOLzeiro ri.

Bruce Willis não.

Porque no próximo capítulo não estaremos mais procurando simplesmente onde a tribo foi parar.

Teremos de descobrir o que pode acontecer dentro dela, quem pode intervir e onde termina uma regra comunitária e começa a lei brasileira.

E dessa vez existe algo muito mais sério que um usuário banido.

Existe uma sigla piscando no terminal:

ECA

CONTINUA...


🐒 Próximo capítulo

ARCO I — CAPÍTULO IV

⚖️ ECA, liberdade e crime — quando FREE SPEECH encontra o RETURN-CODE da lei brasileira

Constituição, Estatuto da Criança e do Adolescente, Marco Civil, plataformas, Discord, moderação, responsabilidade, liberdade de expressão e o estranho dia em que nosso COBOLzeiro descobriu que BAN USER, ordem judicial e crime são três comandos completamente diferentes — embora na tela do usuário todos possam parecer simplesmente “ACESSO NEGADO”.

domingo, 10 de março de 2024

🎌✨ Geek vs Otaku — Entenda as diferenças com estilo Bellacosa!

Bellacosa Mainframe a diferença entre Geek versus Otaku

 🎌✨ Geek vs Otaku — Entenda as diferenças com estilo Bellacosa!

Ei, Padawan! Já percebeu que muita gente usa “geek” e “otaku” como se fossem a mesma coisa? Pois é, mas apesar de viverem no mesmo universo nerd, esses dois mundos têm regras próprias, culturas diferentes e origens cheias de curiosidades. Então prepara o café (ou o ramen 🍜) e vem comigo nessa viagem!

🧠 O que é ser Geek:
Ser geek é viver conectado com tecnologia, cultura pop, quadrinhos, filmes, games e gadgets. O geek é aquele que ama saber como as coisas funcionam — o tipo que desmonta o computador pra “dar uma olhadinha” e depois vira o herói da TI da família.
👉 Geek é o cientista, o gamer, o dev, o fã da Marvel e o entusiasta de ficção científica.

🎌 O que é ser Otaku:
O otaku vem da cultura japonesa e é o fã apaixonado por animes, mangás, doramas e cultura nipônica. A palavra “otaku” originalmente, no Japão, era usada pra se referir a pessoas muito reclusas e obcecadas por um tema — mas o Ocidente ressignificou tudo e transformou em orgulho cultural.
👉 Otaku é o que chora em Your Name, debate Naruto vs Luffy e sabe cantar todas as aberturas de Bleach.

📜 Origens rápidas:

  • “Geek” vem do alemão geck, que significava “esquisito” — e evoluiu pra “pessoa obcecada por tecnologia e cultura pop”.

  • “Otaku” vem do japonês お宅 (otaku), que significa literalmente “sua casa”, usado pra falar com formalidade — e virou gíria pra quem vive mergulhado em seus hobbies.

💡 Curiosidades do multiverso geek/otaku:

  • No Japão, chamar alguém de “otaku” ainda pode soar meio negativo. Já no Ocidente, é título de respeito.

  • Muitos geeks também são otakus — o crossover é real!

  • O Japão tem eventos gigantes como o Comiket, e o mundo geek tem a Comic-Con.

⚙️ Dica Bellacosa:
Quer o melhor dos dois mundos? Seja um Tech-Otaku, aquele que programa de dia e maratona Attack on Titan à noite. 😉

🌌 Resumo Jedi:

  • Geek = tecnologia, cultura pop e conhecimento.

  • Otaku = animes, mangás e cultura japonesa.
    Ambos vivem de paixões, curiosidade e um toque de loucura criativa — e isso é o que faz cada um de nós único nesse vasto universo nerd.

#BellacosaMainframe #GeekVsOtaku #PadawanCulture #NerdPower #OtakuLife

quinta-feira, 7 de março de 2024

Mr. Spock Entra no CPD — O Dia em que o Programador COBOL Disse “É Só um SELECT” e Descobriu uma Civilização Inteira Dentro do Db2

 

Bellacosa Mainframe por dentro do Db2

☕ Um Café no Bellacosa Mainframe

Mr. Spock Entra no CPD — O Dia em que o Programador COBOL Disse “É Só um SELECT” e Descobriu uma Civilização Inteira Dentro do Db2

Ou: por que Buffer Pool, IRLM, DDF, Catalog, Directory, Logs, RUNSTATS, Package, RACF, WLM e Parallel Sysplex fazem parte da mesma missão — e por que dizer que Db2 é “apenas um banco de dados” seria, segundo Spock, altamente ilógico

O turno da noite estava tranquilo.

Tranquilo demais.

E todo profissional de mainframe com alguma estrada sabe que essa frase normalmente é seguida por algum desastre.

O monitor do CICS estava verde. O JES2 aparentemente não tinha nada contra a humanidade naquele momento. O RACF não estava distribuindo ICH408I como panfleto em estação de metrô e nenhum operador havia entrado correndo no CPD gritando:

— A PRODUÇÃO PAROU!

Era quase suspeito.

O jovem programador COBOL, ainda naquela fase da carreira em que acreditamos que um programa que compilou também necessariamente funciona, olhou para sua rotina e anunciou:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTE
    WHERE CONTA = :WS-CONTA
END-EXEC.

Ele sorriu.

— Pronto. É só um SELECT.

Uma sobrancelha levantou-se no outro lado da sala.

Mr. Spock havia entrado no CPD.

Ninguém soube explicar como um oficial científico da Frota Estelar havia conseguido autorização RACF, crachá temporário e acesso à área restrita do datacenter. Mas considerando que o pessoal de infraestrutura já havia liberado consultores externos com justificativas muito piores, ninguém perguntou.

Spock examinou o código.

Depois examinou o programador.

— Sua afirmação contém uma simplificação estatisticamente perigosa.

— Como assim?

— Você acredita ter executado um SELECT. Na realidade, iniciou uma sequência de eventos envolvendo processamento SQL, gerenciamento de memória, otimização, concorrência, storage, catálogo, controle transacional, autorização e possivelmente comunicação distribuída.

O programador ficou olhando para ele.

— Mas voltou um saldo.

— Exatamente. E esta é a parte fascinante.

Assim começa nossa viagem pela arquitetura do Db2 for z/OS.



1. Primeiro diagnóstico de Spock: Db2 não é uma caixa preta

Para muita gente que começa no COBOL, Db2 parece funcionar assim:

COBOL
  ↓
SQL
  ↓
Db2
  ↓
dados

É confortável.

Também está incompleto.

Uma representação mais próxima da realidade seria algo como:

Programa COBOL
      ↓
CICS / Batch / DDF
      ↓
Thread Db2
      ↓
Package
      ↓
Access Path
      ↓
DBM1
      ↓
Buffer Pools
      ↓
Table Space / Index Space
      ↓
DFSMS / Storage

Enquanto isso, paralelamente:

IRLM → locking
Logs → recovery
RACF → segurança
WLM → prioridade
Catalog → metadados
DDF → acesso distribuído

Spock provavelmente resumiria:

“A simplicidade percebida pelo programador é consequência da complexidade absorvida pela infraestrutura.”

E isso é um dos maiores triunfos do mainframe.



2. O que é um Db2 Subsystem?

Vamos começar pela porta da nave.

No z/OS, frequentemente trabalhamos com um Db2 subsystem.

Ele representa uma instância operacional do Db2 dentro daquele ambiente.

Uma empresa poderia ter algo como:

DB2D → desenvolvimento
DB2T → testes
DB2H → homologação
DB2P → produção

Os nomes variam conforme a instalação.

Não existe mandamento dizendo que produção precisa se chamar DB2P.

Aliás, se existe algo que mainframe ensina rapidamente é:

cada empresa tem suas tradições.

Algumas parecem normas técnicas.

Outras parecem decisões tomadas em 1989 por alguém chamado Geraldo, que se aposentou em 2003 e nunca documentou nada.

Curiosidade do CPD

É muito comum o iniciante dizer:

— Estou conectado no Db2.

O veterano pergunta:

— Qual?

E aí começa a aula.

Um mesmo ambiente pode possuir múltiplos subsystems.

Por isso entender onde seu programa está executando é tão importante quanto entender o que ele executa.



3. DBM1 — a sala de máquinas

No coração da arquitetura encontramos o DBM1, o Database Services Address Space.

É onde ocorre uma quantidade enorme do trabalho relacionado ao banco.

Dentro dessa paisagem aparecem conceitos como:

  • Buffer Pools;

  • EDM Pool;

  • estruturas de processamento;

  • threads;

  • acesso a dados;

  • gerenciamento interno;

  • execução de SQL.

Pense no DBM1 como a engenharia da Enterprise.

Você pode estar sentado confortavelmente na ponte dizendo:

— Warp 5.

Mas alguém lá embaixo precisa fazer o motor funcionar.

No COBOL seria:

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

Do ponto de vista do desenvolvedor:

SELECT → resultado

Do ponto de vista da infraestrutura:

solicitação
→ contexto de execução
→ access path
→ memória
→ índice
→ páginas
→ locking
→ eventualmente I/O
→ retorno

“É só um SELECT” começa a parecer uma frase corajosa.


4. Buffer Pool — o truque que evita transformar cada consulta em uma excursão ao storage

Se existe um conceito que todo programador Db2 deveria entender cedo, é Buffer Pool.

Imagine que você tenha uma tabela com 100 milhões de registros.

O programa procura:

SELECT NOME
FROM CLIENTE
WHERE ID_CLIENTE = 928173;

Fisicamente, os dados estão persistidos em storage.

Se toda consulta tivesse que buscar diretamente no disco, teríamos:

programa
   ↓
Db2
   ↓
storage
   ↓
I/O
   ↓
Db2
   ↓
programa

Constantemente.

A performance seria digna de uma carroça klingon.

O Buffer Pool existe justamente para manter páginas de dados e índices em memória.

              MEMÓRIA

        ┌───────────────────┐
        │    BUFFER POOL    │
        │                   │
        │ páginas de dados  │
        │ páginas de índice │
        └─────────┬─────────┘
                  │
          página ausente?
                  │
              SIM ↓
               STORAGE

Se a página já está em memória, evitamos determinado I/O físico.

Essa diferença pode ser gigantesca.


5. O programador pensa em linha; o Db2 frequentemente pensa em página

Aqui está uma mudança de mentalidade poderosa.

O programador escreve:

WHERE CONTA = 12345

Ele pensa:

“Quero essa linha.”

O Db2 precisa lidar com estruturas de armazenamento organizadas em pages.

Então conceitualmente:

linha solicitada
      ↓
página onde ela está
      ↓
Buffer Pool
      ↓
storage se necessário

Isso explica por que performance de banco não pode ser estudada pensando apenas no SQL textual.

Existem questões envolvendo:

  • número de páginas;

  • organização dos dados;

  • índices;

  • clustering;

  • seletividade;

  • Buffer Pool;

  • I/O;

  • estatísticas.

Spock talvez acrescentasse:

— Confundir linha lógica com armazenamento físico seria ilógico.

O DBA responderia:

— Finalmente alguém me entende.


6. Table Space — onde a tabela mora

Uma tabela Db2 precisa viver em uma estrutura apropriada de armazenamento.

Entra o Table Space.

Podemos visualizar:

DATABASE
   │
   ├── TABLE SPACE
   │      │
   │      └── TABLE
   │
   └── INDEX SPACE
          │
          └── INDEX

Aqui vale uma distinção importante.

Table Space e Index Space não são exatamente a mesma coisa.

A tabela reside no Table Space.

O índice possui sua própria estrutura associada.

Essa diferença aparece bastante quando começamos a estudar:

  • utilities;

  • administração;

  • recovery;

  • reorganização;

  • performance.


7. Índice — o tricorder do Db2

Imagine um arquivo com 20 milhões de clientes.

Você quer:

SELECT *
FROM CLIENTE
WHERE CPF = '12345678900';

Sem um caminho adequado, o Db2 pode precisar examinar uma grande quantidade de dados.

Com um índice apropriado:

CPF procurado
    ↓
ÍNDICE
    ↓
localização das páginas
    ↓
dados

Parece maravilhoso.

E é.

Mas existe uma regra que iniciantes aprendem um pouco depois:

índice não é almoço grátis.

Cada índice pode representar:

  • armazenamento;

  • manutenção;

  • custo em INSERT;

  • custo em UPDATE;

  • custo em DELETE;

  • necessidade de reorganização;

  • estatísticas;

  • complexidade adicional.

Criar índice para absolutamente tudo seria como equipar cada tripulante da Enterprise com quinze tricorders.

Em algum momento alguém precisa carregar aquilo.


8. O Optimizer — Spock trabalhando dentro do Db2

Talvez nenhum componente mereça mais o título de “Mr. Spock interno” do que o optimizer.

Você escreve:

SELECT C.NOME,
       P.VALOR
FROM CLIENTE C
JOIN PAGAMENTO P
  ON P.ID_CLIENTE = C.ID_CLIENTE
WHERE C.UF = 'SP';

Você disse o que deseja.

Mas existe mais de uma maneira de conseguir aquilo.

O Db2 pode precisar decidir:

  • qual tabela acessar primeiro;

  • qual índice usar;

  • se deve usar índice;

  • método de join;

  • ordem das tabelas;

  • custo estimado;

  • paralelismo;

  • quantidade provável de linhas.

Esse conjunto de decisões produz o chamado access path.

Simplificando:

SQL
 ↓
Optimizer
 ↓
estatísticas
 ↓
custos estimados
 ↓
Access Path
 ↓
execução

É por isso que dois SQLs que entregam exatamente o mesmo resultado podem ter performances completamente diferentes.


9. RUNSTATS — não mande Spock calcular com sensores quebrados

O optimizer precisa tomar decisões.

Mas baseado em quê?

Em informações sobre os objetos e os dados.

Entram aí as statistics.

Imagine esta distribuição:

CLIENTE

SP = 5.000.000
RJ = 2.000.000
MG = 1.500.000
AC =    30.000
RR =    20.000

Agora compare:

WHERE UF = 'SP'

com:

WHERE UF = 'RR'

A seletividade pode ser radicalmente diferente.

O optimizer precisa ter noção disso.

Ferramentas como RUNSTATS ajudam a coletar estatísticas utilizadas nas decisões de otimização.

Metáfora Bellacosa

Imagine Spock calculando a rota até Vulcano.

Mas você fornece um mapa feito antes da construção das últimas cinquenta colônias.

Ele continua sendo brilhante.

Só está usando informação ruim.

Em banco de dados:

optimizer bom + estatística ruim = possibilidade de access path ruim.

Por isso performance não é apenas:

— “Reescreve esse SELECT.”

Às vezes o SQL estava perfeitamente aceitável.

O ambiente é que mudou.


10. EDM Pool — aquilo que não queremos reconstruir a toda hora

Outro componente importante é o EDM Pool — Environmental Descriptor Manager Pool.

Ele mantém estruturas importantes usadas pelo Db2, incluindo informações relacionadas a packages e estruturas de execução.

O conceito pedagógico é simples:

aquilo que custa processamento para construir pode ser vantajoso manter disponível em memória.

Não confunda EDM Pool com Buffer Pool.

O Buffer Pool trabalha fortemente com páginas de dados e índices.

O EDM Pool está associado a outras estruturas internas necessárias à execução.

Mas ambos ilustram uma obsessão saudável de sistemas de alta performance:

evitar trabalho desnecessário.


11. IRLM — ninguém toca nesse registro sem conversar com o segurança

Chegamos ao IRLM — Internal Resource Lock Manager.

O problema que ele ajuda a resolver é clássico.

Imagine:

Programa A

UPDATE CONTA
SET SALDO = 500
WHERE CONTA = 100;

Programa B

simultaneamente:

UPDATE CONTA
SET SALDO = 800
WHERE CONTA = 100;

Quem ganha?

Quem espera?

Quem pode ler?

Em qual momento?

Que isolamento estamos usando?

Sem controle de concorrência, banco de dados financeiro viraria bingo.

O IRLM participa do gerenciamento de locks.

Podemos pensar:

Programa A ─────┐
                ├── IRLM ── recurso
Programa B ─────┘

Locks existem para preservar consistência em ambientes concorrentes.

E ambiente mainframe costuma ser sinônimo de concorrência em escala bastante séria.


12. Deadlock — quando dois oficiais se recusam a sair da porta

Considere:

Programa A tem recurso X
Programa B tem recurso Y

Agora:

A precisa de Y
B precisa de X

Resultado:

A ───── espera por Y
↑                 │
│                 ↓
X espera por ───── B

Temos um deadlock.

Os dois ficariam esperando eternamente se o sistema não identificasse a situação.

O Db2 precisa detectar o problema e selecionar uma unidade de trabalho para ser interrompida.

Dica para COBOL iniciante

Quando ocorrer erro associado a deadlock ou timeout, não trate imediatamente como:

“Db2 caiu.”

Não.

Na maioria das vezes Db2 está vivíssimo.

Talvez vivo até demais.

Está protegendo a consistência contra seus programas.


13. LOCK não é LATCH

Esse é um pequeno easter egg técnico para quando você estiver conversando com alguém mais experiente.

Lock e latch não são sinônimos.

Locks estão fortemente associados ao controle lógico/transacional de concorrência.

Latches são mecanismos internos de serialização mais leves usados para proteger determinadas estruturas internas.

Portanto quando alguém disser:

— Temos contenção.

Pergunte:

— Que tipo?

Você ganhará pelo menos +3 pontos de experiência mainframe.

Talvez até um café.


14. Logs — a caixa-preta da Enterprise

Agora entramos em uma das áreas mais importantes do Db2.

Imagine:

UPDATE CONTA
SET SALDO = SALDO - 100
WHERE NUM_CONTA = 123;

Uma alteração aconteceu.

O sistema precisa ter capacidade de preservar consistência e recuperar-se de falhas.

Por isso existe toda uma arquitetura de logging.

Em uma visão simplificada:

alteração
   ↓
Log Buffer
   ↓
Active Logs
   ↓
Archive Logs

Os logs guardam informações fundamentais para:

  • recovery;

  • rollback;

  • restart;

  • consistência transacional.

Sem logs, um banco corporativo seria praticamente um caderno escrito a lápis durante um terremoto.


15. COMMIT — quatro letras e uma enorme responsabilidade

No COBOL:

EXEC SQL
   UPDATE CONTA
      SET SALDO = :WS-NOVO-SALDO
    WHERE NUM_CONTA = :WS-CONTA
END-EXEC.

EXEC SQL
   COMMIT
END-EXEC.

COMMIT não significa simplesmente:

“terminei.”

Ele marca uma fronteira transacional importante.

Imagine:

UPDATE
INSERT
DELETE
UPDATE
   ↓
COMMIT

A unidade de trabalho foi confirmada.

O gerenciamento correto de commit é particularmente importante em batch.

Por quê?

Imagine processar cinco milhões de registros e só dar COMMIT no final.

Isso pode aumentar:

  • volume de locks;

  • duração de locks;

  • quantidade de trabalho a desfazer;

  • impacto de rollback;

  • pressão operacional.

Por outro lado, dar COMMIT a cada registro também pode ser inadequado.

A frequência de commit deve ser desenhada conscientemente.

Não existe “número mágico universal”.


16. ACID — as quatro leis de Vulcano das transações

O Db2 trabalha sob princípios transacionais tradicionalmente descritos pela sigla ACID.

Atomicity

Ou a unidade de trabalho ocorre adequadamente ou precisamos impedir resultado parcial inconsistente.

Consistency

O banco deve passar de um estado válido para outro.

Isolation

Transações concorrentes precisam coexistir de forma controlada.

Durability

Depois de confirmado, o resultado deve sobreviver conforme as garantias do sistema.

Considere uma transferência:

Conta Kirk  -100
Conta Spock +100

O universo proibido seria:

Conta Kirk  -100

💥 falha

Conta Spock +0

O dinheiro sumiu em algum buraco de minhoca.

O banco central provavelmente não aceitaria “anomalia espaço-temporal” como justificativa.


17. Active Log, Archive Log e a arte de voltar no tempo sem DeLorean

Os Active Logs participam diretamente das operações correntes de logging do Db2.

Com o avanço do processamento, parte dessas informações pode ser arquivada em Archive Logs.

Conceitualmente:

atividade recente
       ↓
Active Logs
       ↓
arquivamento
       ↓
Archive Logs

Essa arquitetura é um dos pilares das capacidades de recovery.

E aqui entra outro personagem importante.


18. IMAGE COPY — a fotografia antes da tempestade

Uma Image Copy funciona como uma cópia utilizada em estratégias de recuperação dos objetos Db2.

Imagine:

00:00
IMAGE COPY
   │
   │ logs
   │ logs
   │ logs
   │
13:42
falha

Dependendo da estratégia e do cenário, combinamos:

IMAGE COPY
+
LOGS
+
procedimento de recovery

para reconstruir o estado necessário.

Isso é muito mais sofisticado do que aquela frase genérica:

“Restauramos o backup.”

Em ambientes grandes, recovery é ciência.


19. Catalog — o cartório galáctico

Imagine que você cria:

CREATE TABLE PLANETA
(
   ID_PLANETA INTEGER,
   NOME       VARCHAR(80),
   QUADRANTE  CHAR(1)
);

Db2 precisa saber:

  • que a tabela existe;

  • quais colunas existem;

  • seus tipos;

  • seus índices;

  • seus relacionamentos;

  • tablespace;

  • authorities;

  • estatísticas;

  • dependências.

Essas informações vivem no universo do Db2 Catalog.

A metáfora é simples:

Os dados são cidadãos.
O Catalog é o cartório.

Quer saber sobre determinado objeto?

Frequentemente você consulta tabelas do catálogo.


20. Directory — o compartimento em que Spock recomenda não mexer sem motivo

Além do Catalog existe o Db2 Directory.

São estruturas internas essenciais ao próprio funcionamento do Db2.

Uma distinção simplificada:

CATALOG
→ metadados administrativos acessíveis

DIRECTORY
→ estruturas internas do próprio Db2

Não trate os dois termos como sinônimos.

É uma daquelas diferenças que parece acadêmica no começo.

Depois você começa a estudar internals e percebe por que existia.


21. DDF — o momento em que o mainframe abre as portas da nave

Db2 for z/OS não serve apenas a COBOL rodando dentro do próprio mainframe.

Aplicações externas podem acessar Db2 utilizando DDF — Distributed Data Facility.

Por exemplo:

Java
Python
.NET
Linux
Windows
Cloud
   │
   ↓
DRDA
   ↓
TCP/IP
   ↓
DDF
   ↓
Db2 for z/OS

Isso destrói outro mito antigo:

“Mainframe é uma ilha.”

Há décadas não é.

O mainframe moderno pode conversar com praticamente o ecossistema corporativo inteiro.


22. DRDA — o diplomata entre mundos relacionais

DRDA — Distributed Relational Database Architecture fornece mecanismos padronizados para acesso distribuído a bancos relacionais.

Você pode imaginar:

Aplicação externa
      ↓
Driver
      ↓
DRDA
      ↓
TCP/IP
      ↓
DDF
      ↓
Db2

Ou seja, aquele programa Java no Kubernetes pode estar consultando informações que no final vivem no Db2 for z/OS.

O desenvolvedor Java talvez nem saiba.

E em muitos casos nem precisa saber.

Mas o arquiteto deveria.


23. COBOL + CICS + Db2 — o triângulo clássico

Agora voltamos à nossa velha sala de produção.

Um caminho clássico:

usuário
   ↓
CICS
   ↓
Programa COBOL
   ↓
SQL
   ↓
Db2

No programa:

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

Parece natural.

Mas como o SQL foi parar dentro daquele programa executável?

Aí vem uma parte fundamental que muitos cursos passam rápido demais.


24. PRECOMPILE — COBOL e SQL precisam conversar

COBOL puro não interpreta nativamente aquele EXEC SQL.

Existe uma etapa de preparação.

De forma tradicional e simplificada:

Fonte COBOL + SQL
        ↓
   PRECOMPILER
      ┌─┴─────────────┐
      ↓               ↓
COBOL modificado     DBRM
      ↓               ↓
Compiler             BIND
      ↓               ↓
Object              Package
      ↓
Link
      ↓
Load Module

O precompiler identifica instruções SQL e prepara os elementos necessários para o processamento posterior.

Esse fluxo explica por que desenvolvimento COBOL + Db2 envolve muito mais que:

compilar
executar

25. DBRM e PACKAGE — o que Spock realmente queria encontrar

O DBRM guarda informações extraídas das instruções SQL durante a preparação.

Posteriormente ocorre o BIND.

O BIND gera estruturas como packages utilizadas pela execução.

Simplificando:

SQL
 ↓
DBRM
 ↓
BIND
 ↓
PACKAGE
 ↓
Access Path

O package é extremamente importante.

Porque o programa COBOL pode continuar exatamente igual enquanto o comportamento do SQL muda por razões relacionadas a:

  • rebind;

  • novas estatísticas;

  • novos índices;

  • alteração do ambiente;

  • manutenção;

  • mudança de release;

  • access path diferente.

Essa é uma das primeiras grandes revelações para quem trabalha com performance.

Código-fonte igual não significa necessariamente comportamento operacional idêntico.


26. BIND — o casamento arranjado entre SQL e Db2

O BIND é uma etapa fundamental da vida do SQL estático.

É quando informações do DBRM são utilizadas para produzir um package.

E ali são tomadas decisões importantíssimas.

Se você aprende apenas a programar:

EXEC SQL ...

mas não aprende:

  • package;

  • bind;

  • rebind;

  • access path;

você aprendeu a dirigir, mas nunca abriu o capô.

Serve.

Até o carro começar a fazer barulho.


27. O verdadeiro caminho de um SELECT

Nosso jovem programador agora olha novamente para:

SELECT SALDO
FROM CONTA
WHERE NUM_CONTA = :WS-CONTA;

Mas depois da aula de Spock ele já enxerga outra coisa:

COBOL
  ↓
CICS
  ↓
Thread Db2
  ↓
Package
  ↓
Access Path
  ↓
Index?
  ↓
Buffer Pool
  ↓
Página disponível?
   ├── SIM → usa memória
   └── NÃO → solicita I/O
                  ↓
                Storage
                  ↓
              Buffer Pool
                  ↓
                 Db2
                  ↓
                COBOL

Aquela linha de SQL agora parece uma missão espacial inteira.

E é exatamente essa mudança de percepção que diferencia alguém que apenas escreve SQL de alguém que começa a compreender o Db2.


28. DFSMS — quando descobrimos que storage também faz parte do banco

Db2 não administra storage em um vácuo.

No z/OS existe integração com o universo do DFSMS — Data Facility Storage Management Subsystem.

Entram conceitos como:

  • datasets;

  • volumes;

  • storage classes;

  • management classes;

  • data classes;

  • políticas SMS;

  • VSAM.

Esse ponto é profundamente “mainframe”.

Em plataformas mais simples, desenvolvedor e banco às vezes parecem universos separados do storage.

No z/OS, você começa a perceber que:

banco
+
storage
+
sistema operacional
+
segurança
+
workload management

formam uma arquitetura integrada.


29. E então aparece VSAM escondido atrás da cortina

Essa curiosidade normalmente surpreende o iniciante.

Db2 for z/OS utiliza infraestrutura de armazenamento associada ao ecossistema VSAM para seus datasets.

Então podemos desenhar:

Db2 object
   ↓
Table Space
   ↓
datasets
   ↓
VSAM / DFSMS
   ↓
storage

Mas atenção:

Isso NÃO significa que Db2 seja simplesmente “um VSAM com SQL”.

Db2 acrescenta um universo inteiro:

  • modelo relacional;

  • SQL;

  • optimizer;

  • locking;

  • logging;

  • recovery;

  • catálogo;

  • integridade;

  • transações.

VSAM e Db2 possuem propósitos e abstrações diferentes.


30. RACF — nem Spock acessa folha de pagamento sem autorização

Agora imagine:

SELECT *
FROM FOLHA_PAGAMENTO;

Tecnicamente válido.

Mas deveria qualquer programa poder executá-lo?

Claro que não.

Entram mecanismos de segurança do ambiente, incluindo integração com RACF e os mecanismos de autorização do próprio Db2.

A regra fundamental:

SQL válido
≠
SQL autorizado

E ainda bem.

Imagine um estagiário descobrindo:

SELECT *
FROM SALARIOS_DIRETORIA;

e dizendo:

— Funcionou no desenvolvimento.

Produção:

ICH408I

O RACF entra em cena como o segurança vulcano:

— Seu entusiasmo não constitui autorização.


31. WLM — todos são iguais, mas alguns workloads precisam responder em 100 milissegundos

Outro componente importante do ecossistema é o WLM — Workload Manager.

O z/OS pode administrar workloads conforme objetivos definidos.

Imagine simultaneamente:

Transação PIX
Consulta de saldo
Batch de faturamento
Relatório gerencial
Backup
Compilação
Job de teste

Todos querem CPU.

Todos acham que são importantes.

Alguns realmente são.

WLM ajuda o sistema a priorizar recursos conforme políticas de serviço.

Pense nele como o oficial de operações da ponte:

“Essa transação é crítica.”
“Esse relatório pode esperar.”
“Esse batch precisa terminar antes das 06:00.”

É uma das grandes razões pelas quais mainframes conseguem misturar workloads muito distintos de forma eficiente.


32. MQ, CICS, TCP/IP e companhia — Db2 nunca esteve sozinho

Observe uma arquitetura corporativa típica:

Mobile
  ↓
API
  ↓
z/OS Connect
  ↓
CICS
  ↓
COBOL
  ↓
Db2

Ao lado:

COBOL
  ↓
MQ
  ↓
sistema externo

Com:

RACF → segurança
WLM  → prioridades
DFSMS → storage
TCP/IP → comunicação
JES → batch

O segredo do mainframe nunca foi um único produto.

É a integração.

Isso vale para Db2 também.


33. Parallel Sysplex — quando uma Enterprise deixa de ser suficiente

Agora entramos em território mais avançado.

Em ambientes de altíssima disponibilidade, Db2 pode operar em configuração de Data Sharing, dentro do universo do Parallel Sysplex.

Imagine:

            Aplicações
                │
      ┌─────────┼─────────┐
      ↓         ↓         ↓
    DB2A      DB2B      DB2C
      │         │         │
      └─────────┼─────────┘
                ↓
      dados compartilhados

Vários membros Db2 podem trabalhar cooperativamente.

Isso proporciona benefícios associados a:

  • disponibilidade;

  • escalabilidade;

  • flexibilidade operacional;

  • continuidade.

Mas surge um problema lógico.

Se DB2A e DB2B acessam os mesmos dados:

Como garantir coerência?

Excelente pergunta, jovem cadete.


34. Coupling Facility e Group Buffer Pool

No Data Sharing entram estruturas disponibilizadas através da Coupling Facility.

Entre elas aparecem mecanismos relacionados a Group Buffer Pools e coordenação entre membros.

Simplificando:

DB2A                     DB2B
 │                         │
Buffer Pool            Buffer Pool
 │                         │
 └──────────┐   ┌──────────┘
            ↓   ↓
      Coupling Facility
            │
      Group Buffer Pool

Se vários membros acessam os mesmos dados, precisamos impedir que cada um viva numa realidade alternativa.

Afinal, nem Star Trek resolve consistência eventual com universo paralelo em folha de pagamento.


35. O programa funciona, mas está lento. E agora?

Este é um dos momentos mais importantes da carreira.

Iniciante:

“O SQL está lento.”

Profissional experiente:

“Vamos descobrir por quê.”

Possibilidades:

SQL ruim
estatísticas inadequadas
índice ausente
índice inadequado
access path diferente
muito I/O
Buffer Pool pressionado
contenção
locks
volume de dados cresceu
commit inadequado
CPU
storage
DDF
rede
WLM

Percebe a diferença?

Performance não é adivinhação.

É investigação.

Mr. Spock aprovaria.


36. Checklist Bellacosa para o COBOL iniciante

Quando um SQL apresentar problema, pergunte nesta ordem aproximada:

  1. O SQL está logicamente correto?

  2. Quantas linhas deveriam retornar?

  3. Quantas realmente retornam?

  4. Existe índice apropriado?

  5. Qual access path está sendo usado?

  6. As estatísticas estão atualizadas?

  7. Houve REBIND recentemente?

  8. O volume de dados mudou?

  9. Existe contenção?

  10. Existe timeout ou deadlock?

  11. O programa está dando commits adequadamente?

  12. O problema acontece sempre ou apenas em horários específicos?

  13. É batch, CICS ou acesso distribuído?

  14. Existe pressão de CPU ou I/O?

  15. Houve mudança no ambiente?

Já percebeu que:

“Está lento porque Db2 está lento”

é praticamente uma não-explicação.


37. O easter egg do SQLCODE

Todo programador COBOL conhece algum momento assim:

IF SQLCODE NOT = 0
    DISPLAY 'ERRO DB2'
END-IF

Spock vê isso.

Fica silencioso durante oito segundos.

Depois diz:

— Fascinante. Você descartou todas as informações diagnósticas e preservou apenas o fato de que algo ocorreu.

Não seja esse programador.

SQLCODE é começo de diagnóstico.

Não fim.

Considere também as informações disponibilizadas por SQLCA e mecanismos apropriados de diagnóstico.

A mensagem:

ERRO DB2

é quase equivalente a chamar a manutenção dizendo:

“A máquina não está normal.”

Boa sorte.


38. Segundo easter egg: SELECT *

Spock observa:

SELECT *
FROM CLIENTE;

— Por que você deseja todas as colunas?

— Porque é mais fácil.

— Essa justificativa não parece relacionada à necessidade funcional.

Silêncio.

SELECT * pode ser conveniente em testes.

Em aplicação profissional, pense nas colunas realmente necessárias.

Isso melhora:

  • clareza;

  • manutenção;

  • previsibilidade;

  • potencialmente movimentação de dados;

  • dependências.

Escreva o que precisa.

Não o que seus dedos acharam mais curto.


39. Terceiro easter egg: COMMIT dentro do loop sem pensar

Outro clássico:

PERFORM UNTIL EOF
   ...
   EXEC SQL
      UPDATE ...
   END-EXEC

   EXEC SQL
      COMMIT
   END-EXEC
END-PERFORM

Talvez seja correto.

Talvez seja horrível.

Depende.

A pergunta certa não é:

“Posso dar COMMIT aqui?”

É:

“Qual unidade de trabalho faz sentido para esse processo?”

Em batch, estratégia de commit precisa considerar:

  • restart;

  • volume;

  • locking;

  • recuperação;

  • consistência;

  • desempenho.


40. A diferença entre saber SQL e saber Db2

Este talvez seja o ponto mais importante do artigo.

Conhecer:

SELECT
INSERT
UPDATE
DELETE
JOIN
GROUP BY

é conhecer SQL.

Essencial.

Mas conhecer Db2 for z/OS envolve também:

Subsystem
DBM1
MSTR
IRLM
DDF
Buffer Pool
EDM Pool
Table Space
Index Space
Catalog
Directory
Package
DBRM
BIND
Access Path
RUNSTATS
Logs
Recovery
Image Copy
DFSMS
RACF
WLM
Data Sharing
Parallel Sysplex

É outro nível de entendimento.

E você não precisa aprender tudo no primeiro mês.

Apenas precisa saber que essas camadas existem.


41. Um caminho de estudo em sete missões

Se eu estivesse orientando um programador COBOL iniciante, faria assim.

Missão 1 — SQL

Aprenda bem:

SELECT
INSERT
UPDATE
DELETE
JOIN
CURSOR
NULL
SQLCODE

Missão 2 — COBOL + Db2

Entenda:

host variables
SQLCA
cursor
commit
rollback

Missão 3 — preparação

Estude:

Precompile
DBRM
Bind
Package
Plan

Missão 4 — armazenamento

Estude:

Table Space
Index
Page
Buffer Pool

Missão 5 — optimizer

Estude:

Access Path
RUNSTATS
EXPLAIN
seletividade
cardinalidade

Missão 6 — concorrência

Estude:

Lock
Timeout
Deadlock
Isolation
Commit

Missão 7 — arquitetura z/OS

Finalmente:

IRLM
DDF
DFSMS
RACF
WLM
Logs
Recovery
Data Sharing

Quando terminar isso, volte à Missão 1.

Você descobrirá que seu antigo SELECT mudou completamente.


42. A grande revelação

Nosso programador volta finalmente ao código:

EXEC SQL
   SELECT NOME,
          SALDO
     INTO :WS-NOME,
          :WS-SALDO
     FROM CLIENTE
    WHERE CONTA = :WS-CONTA
END-EXEC.

Antes ele via:

“Busca o saldo.”

Agora enxerga:

Aplicação
 ↓
contexto Db2
 ↓
Package
 ↓
Access Path
 ↓
Optimizer
 ↓
Statistics
 ↓
Index
 ↓
Buffer Pool
 ↓
Page
 ↓
possível I/O
 ↓
Storage
 ↓
controle transacional
 ↓
segurança
 ↓
resultado

Ele olha para Spock.

— Então nunca foi “só um SELECT”.

Spock responde:

— Correto.

— E tudo isso acontece para devolver duas colunas?

— Correto.

— Isso é completamente insano.

Spock levanta novamente a sobrancelha.

— Eu escolheria a palavra “engenharia”.


Epílogo — Vida longa ao Db2

Existe uma tendência natural de ensinar mainframe de fora para dentro.

Primeiro mostramos:

IDENTIFICATION DIVISION.

Depois:

EXEC SQL.

Depois CICS.

Depois JCL.

Está correto.

O problema é quando o aprendizado para ali.

Um profissional começa realmente a amadurecer quando pergunta:

O que existe atrás dessa instrução?

Db2 é um ótimo exemplo.

Por trás do humilde:

SELECT SALDO

existe uma arquitetura desenhada para funcionar em ambientes nos quais:

  • milhões de transações podem acontecer;

  • múltiplas aplicações disputam recursos;

  • dados precisam permanecer consistentes;

  • falhas precisam ser recuperáveis;

  • workloads críticos têm prioridade;

  • segurança precisa ser auditável;

  • sistemas externos precisam acessar dados;

  • operações precisam continuar durante enormes cargas.

É por isso que Db2 for z/OS não deve ser estudado apenas como linguagem SQL.

Ele deve ser entendido como parte de uma arquitetura transacional completa.

Buffer Pool ensina que memória é estratégia.

IRLM ensina que concorrência precisa de disciplina.

RUNSTATS ensina que inteligência depende de boas informações.

Logs ensinam que sobreviver ao desastre é tão importante quanto evitar o desastre.

RACF ensina que capacidade técnica não significa autorização.

WLM ensina que nem todo trabalho possui a mesma urgência.

DDF ensina que mainframe não é uma ilha.

Parallel Sysplex ensina que alta disponibilidade é uma arquitetura, não uma frase de marketing.

E o humble COBOL programador aprende finalmente uma verdade que acompanha muita gente durante décadas de carreira:

quanto mais você entende o que existe abaixo do seu programa, melhores ficam as decisões que você toma acima dele.

Spock deixou o CPD pouco antes das três da manhã.

Na saída, encontrou o operador.

— O senhor está indo embora?

— Acredito que meu trabalho aqui terminou.

— E o garoto?

Spock olhou através do vidro para o programador, que naquele momento pesquisava access path, Buffer Pool e RUNSTATS enquanto sua caneca de café esfriava ao lado do terminal.

— Ele cometeu um erro comum.

— Qual?

— Pensou que estava aprendendo apenas COBOL.

Spock fez uma pequena pausa.

— Agora começou a aprender sistemas.

O elevador fechou.

No monitor apareceu:

DSN SYSTEM(...)

Depois:

READY

E em algum lugar profundamente dentro do z/OS, um Buffer Pool continuou recebendo páginas, o IRLM continuou arbitrando recursos, os logs continuaram registrando transações e o velho Db2 fez aquilo que vem fazendo há décadas:

carregar boa parte do mundo corporativo nas costas sem exigir que o usuário saiba quantas maravilhas estavam acontecendo atrás de um simples SELECT.

🖖 Vida longa, prosperidade e um access path decente.

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