✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e as meninas kawaii-animais em anime
🐾✨ Meninas Kawaii-Animais: o zoológico mais fofo (e caótico) dos animes
☕ Um Café no Bellacosa Mainframe
🐾 Meninas Kawaii-Animais: Quando a Fantasia Ganha Orelhas, Caudas e Muito Carisma
Se existe um elemento capaz de identificar um anime à primeira vista, são as famosas kemonomimi: personagens humanas com orelhas, caudas ou outros traços inspirados em animais. Muito mais do que um simples detalhe visual, elas representam um dos arquétipos mais tradicionais da cultura pop japonesa, combinando fantasia, humor, simbolismo e um toque de fofura que conquistou gerações de fãs.
Para um programador COBOL padawan, imagine que cada tipo de personagem é como uma classe de objetos em um grande sistema. As nekomimi (garotas-gato) costumam ser independentes, curiosas e brincalhonas. As kitsunemimi (raposas) carregam inteligência e mistério. As ōkamimimi (lobas) transmitem força, proteção e liderança, enquanto coelhas, cães, ursos e outras variações acrescentam novas personalidades ao universo dos animes.
Esse recurso narrativo possui raízes em antigas lendas japonesas sobre espíritos animais, como kitsune e tanuki, que inspiraram inúmeras obras ao longo das décadas. Com o tempo, evoluiu para um elemento marcante da estética moe, aparecendo em mangás, animes, jogos, cafés temáticos, cosplay e até VTubers.
O grande charme das kemonomimi está justamente no equilíbrio entre o humano e o instintivo. Um simples movimento das orelhas ou da cauda pode revelar emoções que palavras não conseguem expressar. No fim, essas personagens mostram que, às vezes, um pequeno detalhe visual é suficiente para tornar um mundo de fantasia muito mais vivo, divertido e inesquecível.
Sabe aquela personagem que tem orelhas de gato, rabinho e mia quando fica feliz? Pois é.
Você acabou de entrar no mundo das meninas-animais (kemonomimi-kei) — um dos tropos mais antigos, fofos e estranhamente coerentes da cultura moe.
🧬 Origem: quando orelhas se tornaram tendência
A ideia de misturar traços humanos e animais não nasceu no Japão — os mitos gregos já faziam isso (centauros, harpias e cia).
Mas o Japão disse:
“Ok, e se em vez de criaturas épicas... fossem garotas fofas com orelhinhas?”
Boom 💥
Nascia o império das kemonomimi (獣耳) — literalmente “orelhas de fera”.
Tudo começou discretamente em mangás dos anos 70–80 (Urusei Yatsura, Cat’s Eye, Ranma ½), e se espalhou como moda no doujin, nos cafés temáticos, e claro, nos animes moe dos anos 2000.
🐱 Tipos de meninas-animais (e seus nomes japoneses)
Abaixo, o guia definitivo de kemonomimi — o que elas são, de onde vêm, e o que simbolizam:
Tipo
Nome Japonês
Personalidade Típica
Exemplos
🐱 Gato
Nekomimi (猫耳)
Travessa, charmosa, preguiçosa. Adora carinho mas só quando quer.
Doce, tímida e nervosa — símbolo de pureza e fertilidade.
Haruhi Suzumiya (Bunny Girl), Rize (Is the Order a Rabbit?)
🦊 Raposa
Kitsunemimi (狐耳)
Misteriosa, esperta, espirituosa. Pode ser sensual ou sábia.
Senko-san, Tamamo no Mae (Fate/Extra)
🐺 Lobo
Ōkamimimi (狼耳)
Selvagem, protetora, alfa vibes. Fiel mas orgulhosa.
Holo (Spice and Wolf), Yatsuharu Sohma (Fruits Basket)
🐻 Urso
Kumamimi (熊耳)
Fofa, sonolenta, gosta de abraços (e mel).
Kuma Kuma Kuma Bear
🐭 Rato
Nezumimi (鼠耳)
Pequena, ágil, tímida — muitas vezes mascote.
Hamtaro versão humana, Neko Musume (GeGeGe no Kitarō)
🐍 Cobra
Hebimimi (蛇耳)
Fria, misteriosa, muitas vezes sedutora.
Miia (Monster Musume)
🐸 Sapo
Kaerumimi (蛙耳)
Excêntrica, otimista, estranha e única.
Tsuyu Asui (My Hero Academia)
🧠 Curiosidades de bastidor
“Kemonomimi” virou categoria fixa em doujinshi, cosplay, e IA art tags.
Em cafés maid de Akihabara, garçonetes usam orelhas de gato ou coelho para “ajudar o cliente a relaxar”.
O visual se popularizou tanto que inspirou até VTubers (metade do top 50 do YouTube Japão tem orelhinhas).
A diferença entre nekomimi e kemonomimi é simples: todo nekomimi é kemonomimi, mas nem todo kemonomimi é nekomimi 🐾
🎭 Por que o Japão ama tanto isso?
Três palavras: fofura + instinto + escapismo.
Os kemonomimi unem:
a pureza emocional (animal)
a sensibilidade humana (drama, romance, humor)
Essa fusão cria personagens que brincam com o limite entre o racional e o instintivo.
É o lado selvagem do moe — literal e metafórico.
💬 Comentários do El Jefe (modo sabedoria do café noturno ☕)
“Kemonomimi é o equivalente otaku da astrologia — todo mundo tem um arquétipo animal que o define.”
Gatos são tsunderes, coelhas são kuuderes, raposas são onee-sans e lobas… bem, são material de fanart perigoso.
E no fim, o verdadeiro encanto está em como esses personagens mostram humanidade através da animalidade.
Porque às vezes, pra entender o coração humano, é preciso colocar um par de orelhas e dizer nyan~.
🧩 Dica bônus pra identificar em animes:
Orelhas? Veja se mexem quando a personagem sente emoção.
Rabo? Repare se tem função de “ponte emocional” (balança = alegria, parado = tensão).
Som? Mia, late, grunhe = ponto extra no nível de moe.
Bellacosa Mainframe e o ms copilot para devs cobol
☕ Um Café no Bellacosa Mainframe
Stargate Copilot — O dia em que o programador COBOL atravessou o portal da IA corporativa
Ou: você entrou achando que Microsoft Copilot era um sujeito que resumiria sua reunião no Teams e descobriu do outro lado do portal agentes, Graph, Fabric, APIs, identidade, governança, Power Automate e um velho programa COBOL esperando tranquilamente no CICS
Imagine a cena.
Você é um jovem programador COBOL.
Ainda está naquele estágio saudável da carreira em que olha para:
IDENTIFICATION DIVISION.
PROGRAM-ID. XPTO001.
e sente uma mistura de respeito, curiosidade e uma pequena vontade de perguntar:
— Mas por que diabos isso começa com um parágrafo dizendo o nome do programa se eu já sei o nome do programa?
Calma.
Você ainda verá coisas muito mais estranhas.
Um belo dia alguém da arquitetura chega com uma imagem gigantesca chamada:
MICROSOFT COPILOT ECOSYSTEM
Na imagem aparecem Power Platform, Power BI, Copilot Studio, Entra ID, Purview, Defender, Dynamics, OneDrive, SharePoint, Teams, Microsoft Fabric, OneLake, Azure AI, GitHub Copilot, Azure DevOps, Bing, Edge, Logic Apps, Functions, SQL e uma quantidade de logotipos suficiente para fazer um programador COBOL procurar discretamente a tecla PF3.
Não aperte PF3 ainda.
Porque existe uma maneira curiosamente simples de entender tudo isso.
E, ironicamente, quem conhece mainframe talvez tenha mais facilidade do que muita gente imagina.
Pegue um café.
Ative o chevron.
Hoje vamos atravessar o Stargate da IA corporativa.
🌌 1. O primeiro erro: achar que Copilot é “o ChatGPT da Microsoft”
Foi assim que muita gente conheceu a coisa.
Abriu o Word:
“Copilot, melhore este texto.”
Abriu o Outlook:
“Resuma esta conversa.”
Entrou no Teams:
“O que aconteceu na reunião enquanto eu estava fingindo que prestava atenção?”
Abriu o PowerPoint:
“Crie uma apresentação.”
Muito útil.
Mas isso corresponde apenas à primeira camada.
Podemos representar assim:
USUÁRIO
|
v
COPILOT
|
v
RESPOSTA
Você pergunta.
Ele responde.
Fim.
É o equivalente cognitivo de um programa batch extremamente simples:
INPUT
|
PROCESS
|
OUTPUT
Para uma primeira experiência é ótimo.
Mas a Microsoft está construindo algo muito maior ao redor dessa ideia.
O ponto central é:
Copilot não deve ser entendido apenas como um produto. Ele está se transformando numa interface para um ecossistema empresarial de IA.
E isso muda completamente a arquitetura.
🌀 2. Chevron 1 locked: produtividade
No primeiro planeta encontramos o Microsoft 365 Copilot.
Word.
Excel.
PowerPoint.
Outlook.
Teams.
SharePoint.
OneDrive.
É o planeta mais confortável porque o humano continua no comando.
Ele pergunta:
“Resuma os emails de hoje.”
O sistema procura contexto.
Um modelo gera uma resposta.
E o humano decide o que fazer.
A lógica ainda é:
HUMANO
|
v
PERGUNTA
|
v
IA
|
v
RESPOSTA
|
v
HUMANO EXECUTA
Isso é produtividade assistida.
Pode economizar cinco minutos.
Pode economizar meia hora.
Pode economizar algumas horas por semana.
Excelente.
Mas ainda não transformamos o processo.
Mudamos apenas a produtividade de uma etapa.
É a diferença entre colocar um compilador COBOL mais rápido e redesenhar toda a cadeia de processamento.
🧠 3. O Microsoft Graph: o MALP enviado antes da equipe
Quem assistia a Stargate SG-1 lembra do MALP.
Antes de mandar O’Neill, Carter, Daniel Jackson e Teal’c atravessarem alegremente um buraco de minhoca para um planeta onde poderia haver Goa’uld esperando do outro lado, enviava-se uma pequena máquina.
Ela verificava o terreno.
Atmosfera.
Ambiente.
Imagens.
Possíveis problemas.
O Microsoft Graph cumpre uma função vagamente comparável dentro da história do Copilot: ajuda a fornecer contexto organizacional.
Quando você pergunta:
“O que ficou decidido sobre o Projeto X?”
a resposta pode depender de:
emails;
documentos;
reuniões;
calendários;
arquivos;
conversas;
conteúdo no SharePoint;
informações disponíveis ao usuário.
O Microsoft 365 Copilot usa grounding e o Microsoft Graph para enriquecer a solicitação com contexto relevante. E há uma regra fundamental: o acesso continua limitado às permissões do usuário autenticado.
Isso merece atenção.
Copilot não significa:
SELECT *
FROM EMPRESA;
Significa algo mais parecido com:
SELECT INFORMACAO
FROM ORGANIZACAO
WHERE USUARIO_TEM_PERMISSAO = TRUE;
Pelo menos conceitualmente.
E o jovem COBOL pode reconhecer imediatamente a importância disso.
Porque uma coisa é saber responder.
Outra completamente diferente é saber a que dados você pode ter acesso para responder.
🔎 4. Grounding: evitando mandar a IA explorar Abydos com um mapa de Marte
Um modelo de linguagem possui conhecimento geral.
Mas a sua empresa possui conhecimento específico.
Imagine perguntar:
“Qual foi a decisão sobre o projeto Phoenix?”
Para um modelo genérico isso significa aproximadamente nada.
Phoenix pode ser:
projeto de software;
cliente;
sistema interno;
codinome;
tabela;
incidente;
nome do gato do diretor.
O grounding adiciona contexto.
Conceitualmente:
PROMPT ORIGINAL
"Qual foi a decisão sobre Phoenix?"
|
v
RECUPERAÇÃO DE CONTEXTO
|
+--> email
+--> Teams
+--> documento
+--> reunião
|
v
PROMPT ENRIQUECIDO
|
v
LLM
|
v
RESPOSTA CONTEXTUAL
É uma diferença enorme.
Sem grounding:
IA sabe coisas.
Com grounding:
IA sabe coisas e consegue relacionar sua pergunta ao contexto autorizado da organização.
Esse é um dos pilares da IA corporativa.
📚 5. A grande biblioteca onde ninguém sabe onde guardou nada
Toda empresa grande possui uma versão da mesma tragédia.
Existe um documento importante.
Em algum lugar.
Talvez no SharePoint.
Talvez no OneDrive.
Talvez num email.
Talvez numa pasta chamada:
FINAL
dentro de:
FINAL_V2
dentro de:
FINAL_V2_AGORA_VAI
dentro de:
FINAL_V2_AGORA_VAI_CORRIGIDO_JOSE_3
A IA empresarial tenta transformar esse caos documental em conhecimento pesquisável.
Daí entram recursos de pesquisa semântica, Graph, índices e sistemas de recuperação.
Pesquisa tradicional pergunta:
“Onde aparece exatamente a palavra XPTO?”
Pesquisa semântica tenta chegar mais perto de:
“Que documentos estão falando aproximadamente sobre aquilo que o usuário quer saber?”
Para um programador COBOL isso é uma mudança semelhante a sair de:
SEARCH STRING
para:
SEARCH MEANING
Não é mágica.
É recuperação de informação + representação semântica + contexto + ranking + segurança.
Mas para o usuário parece mágica.
☠️ 6. A armadilha: Copilot também encontra sua bagunça mais depressa
Agora entra uma das melhores pegadinhas dessa arquitetura.
Considere:
CONTRATO_CONFIDENCIAL.PDF
Por algum erro histórico, José possui acesso.
José jamais descobriu isso.
O documento está enterrado em um SharePoint de 2017.
Logo:
falha existe
+
ninguém percebe
=
aparente tranquilidade
Então chega uma IA capaz de pesquisar profundamente os dados aos quais José já possui acesso.
José pergunta:
“Quais contratos mencionam aquisição da Empresa Y?”
E aparece justamente aquilo.
O Copilot não necessariamente criou o problema.
O problema já existia.
A IA simplesmente colocou um holofote em cima dele.
Por isso uma frase merece entrar na parede do datacenter:
IA transforma dívida de governança em dívida operacional visível.
Purview, políticas de dados, classificação de informação e revisão de permissões deixam de ser acessórios.
Viraram pré-requisitos.
A própria arquitetura Microsoft reforça que o Copilot respeita o escopo de acesso do usuário e que serviços como Purview e controles do SharePoint fazem parte da estratégia de segurança e governança.
🔐 7. Entra ID: “Jaffa, kree!” mas com autenticação multifator
Agora chegamos à identidade.
Em sistemas empresariais você jamais deveria começar perguntando:
“O que esta aplicação consegue fazer?”
Primeiro pergunte:
“Quem é você?”
Depois:
“O que você tem autorização para fazer?”
Entra ID ocupa parte importante dessa função no ecossistema Microsoft.
Tradicionalmente pensávamos em identidades como:
HUMANOS
APLICAÇÕES
SERVICE ACCOUNTS
WORKLOADS
Mas agentes de IA criaram uma nova criatura.
AGENT
Se um agente puder:
consultar dados;
chamar uma API;
alterar CRM;
criar um pedido;
acionar outro agente;
executar um workflow;
então precisamos responder:
Quem é ele?
Quem criou?
Quem é responsável?
O que pode acessar?
Em nome de quem trabalha?
Quando sua autorização termina?
Como auditamos tudo?
A Microsoft já possui Microsoft Entra Agent ID para autenticação, autorização, governança e auditoria de identidades de agentes.
Aqui começa algo fascinante:
EMPRESA DE 2030?
40.000 humanos
3.000 aplicações
1.000 service accounts
70.000 agentes
Não sei se os números serão exatamente esses.
Mas a direção arquitetural é essa:
agentes tornam-se uma nova população digital corporativa.
A documentação atual do Copilot Studio descreve agentes autônomos capazes de reagir a eventos, decidir e executar tarefas dentro de permissões, limites e guardrails definidos.
Portanto passamos de:
Prompt-driven AI
para:
Event-driven AI
Programador COBOL veterano neste momento começa a sorrir.
Porque evento disparando processamento?
Isso não parece inteiramente extraterrestre.
⚙️ 9. Power Automate: o braço mecânico do robô
Imagine uma inteligência fabulosa que diz:
“Descobri que precisamos bloquear o cartão.”
Excelente.
Agora bloqueie.
Silêncio.
O modelo sabe o que deveria acontecer, mas não necessariamente possui uma operação capaz de fazer aquilo.
É aí que entram ferramentas, flows, conectores, APIs e automações.
No Copilot Studio, agent flows podem ser usados como ferramentas que agentes chamam durante execução para recuperar informações ou realizar ações. Esses fluxos podem ser disparados manualmente, por eventos, agentes ou agenda.
Exemplo:
AGENT
|
| "preciso verificar crédito"
v
FLOW
|
+--> GET CUSTOMER
+--> CHECK CREDIT
+--> GET DEBT
+--> UPDATE CRM
+--> SEND NOTIFICATION
Agora o agente ganhou mãos.
🧮 10. A lição mais importante para o COBOLero: não deixe o LLM fazer o trabalho do programa
Esta vale ouro.
Imagine:
“Calcule os juros desta operação financeira de R$ 72 milhões conforme regra contratual XYZ.”
Você pode pedir ao modelo para improvisar.
Ou pode ser um adulto responsável.
A arquitetura correta tende a separar:
LLM
|
| interpreta intenção
|
v
FUNÇÃO DETERMINÍSTICA
|
| calcula
|
v
RESULTADO
Algo como:
AGENT:
"Precisamos calcular juros."
|
v
CALCULAR-JUROS
|
v
COBOL / JAVA / FUNCTION / API
|
v
VALOR EXATO
Isso é particularmente bonito porque agent flows são apresentados pela Microsoft como determinísticos: regras definidas, caminho previsível, entradas iguais produzindo o mesmo comportamento esperado.
Então guarde:
LLM interpreta. Programa calcula.
Claro que existem exceções.
Mas como regra mental para iniciante, é excelente.
Você não substitui determinismo por probabilidade só porque probabilidade virou moda.
🧱 11. Aqui o jovem programador percebe que COBOL não morreu outra vez
Agora chegamos ao portal favorito do Bellacosa Mainframe.
Um gerente entra no Teams e pergunta:
“Por que a operação do cliente ABC foi recusada?”
Vamos montar um cenário possível.
MICROSOFT TEAMS
|
v
COPILOT
|
v
AGENT
|
+--> CRM
|
+--> SharePoint
|
+--> Fabric
|
v
POWER AUTOMATE / API
|
v
API MANAGEMENT
|
v
z/OS CONNECT
|
v
CICS
|
v
COBOL
|
v
Db2
Observe cuidadosamente.
O mainframe não desapareceu.
O COBOL não desapareceu.
O CICS não desapareceu.
O Db2 não desapareceu.
Eles mudaram de posição na experiência.
O usuário talvez nunca veja uma tela 3270.
Mas lá embaixo:
EXEC CICS LINK
continua trabalhando tranquilamente.
Essa é a grande lição para quem está começando em COBOL:
Modernização não significa necessariamente substituição. Muitas vezes significa exposição, integração e composição.
O velho programa pode virar uma capacidade empresarial acessível através de API.
🏛️ 12. System of Engagement versus System of Record
Essa distinção ajuda demais.
Imagine:
Teams
Copilot
Web
Mobile
como systems of engagement.
São os lugares nos quais humanos interagem.
E:
CICS
IMS
Db2
Core banking
ERP
como systems of record.
São lugares onde a transação séria acontece.
Então:
EXPERIENCE
|
v
INTELLIGENCE
|
v
ORCHESTRATION
|
v
INTEGRATION
|
v
SYSTEM OF RECORD
Essa arquitetura não elimina legado.
Ela transforma legado em serviço consumível.
🧵 13. Microsoft Fabric: o planeta dos dados
Agora entra Fabric.
A organização possui dados espalhados:
CRM
ERP
financeiro
produção
telemetria
logs
vendas
clientes
estoque
Durante décadas construímos algo parecido:
DADOS
|
v
ETL
|
v
DATA WAREHOUSE
|
v
BI
|
v
DASHBOARD
|
v
HUMANO
Apareceu uma bolinha vermelha.
O analista observa.
Liga para alguém.
Abre ticket.
Manda email.
Esperamos.
Com agentes, podemos começar a pensar:
DADOS
|
v
FABRIC
|
v
MODELO SEMÂNTICO
|
v
INSIGHT
|
v
AGENTE
|
v
INVESTIGA
|
v
PROPÕE AÇÃO
|
v
APROVAÇÃO
|
v
EXECUTA
O dashboard deixa de ser necessariamente o último ponto do processo.
Vira um sensor.
🚨 14. Power BI vê fumaça; agente chama os bombeiros
Exemplo simples.
Um dashboard detecta:
VENDAS -35%
REGIÃO SUL
PRODUTO XPTO
No modelo tradicional:
alerta
|
v
gerente vê amanhã
|
v
manda email
|
v
analista investiga
Modelo agentic possível:
ALERTA
|
v
AGENT
|
+--> consulta estoque
+--> consulta preço
+--> consulta incidentes
+--> consulta campanhas
|
v
"causa provável:
erro de preço após atualização"
|
v
cria incidente
|
v
notifica responsável
Se a política permitir:
solicita correção
Se a política não permitir:
AGUARDA HUMANO
A diferença é brutal.
🧯 15. Nunca confunda inteligência com autoridade
Aqui está uma regra fundamental.
PODE PENSAR
!=
PODE LER
PODE LER
!=
PODE ALTERAR
PODE ALTERAR
!=
PODE APROVAR
PODE APROVAR
!=
PODE EXECUTAR QUALQUER COISA
Um agente pode concluir:
“A melhor ação seria estornar R$ 2 milhões.”
Isso não significa que deveria poder executar:
ESTORNAR 2000000
sozinho.
Arquitetura madura:
AGENTE RACIOCINA
|
v
POLÍTICA
|
v
VALIDAÇÃO DETERMINÍSTICA
|
v
APROVAÇÃO HUMANA
|
v
TRANSAÇÃO
|
v
AUDITORIA
O objetivo não é construir um Goa’uld financeiro com acesso irrestrito ao core banking.
👮 16. Purview, Defender e segurança: porque os Replicators também automatizavam muito bem
Há algo que todo fã de Stargate deveria respeitar.
Automação sem controle pode escalar uma pequena bobagem até ela começar a comer a galáxia.
Os Replicators eram, afinal, extremamente eficientes.
O mesmo vale para agentes.
Um humano pode levar quinze minutos para cometer um erro.
Um agente pode realizar centenas de ações antes de alguém dizer:
“Espera. Quem autorizou isso?”
Por isso precisamos:
identidade;
least privilege;
auditoria;
classificação;
políticas;
segregação de funções;
limites;
human-in-the-loop;
observabilidade.
A velocidade da automação multiplica tanto o benefício quanto o erro.
🛰️ 17. Observabilidade: precisamos inventar o SMF dos agentes
E aqui o mainframeiro encontra terreno conhecido.
No z/OS nós gostamos de registros.
SMF.
RMF.
JES.
SYSLOG.
CICS logs.
Db2 traces.
Porque quando alguém pergunta:
“O que aconteceu às 03:17?”
não podemos responder:
“A máquina teve um sentimento.”
Precisamos reconstruir o ocorrido.
Agora imagine:
AGENT A
|
v
AGENT B
|
v
FLOW
|
v
API
|
v
CICS
|
v
DB2
Algo saiu errado.
Precisamos saber:
qual evento iniciou?
qual contexto foi recuperado?
qual modelo respondeu?
qual ferramenta foi escolhida?
quais parâmetros foram enviados?
qual identidade executou?
qual permissão foi usada?
qual API foi chamada?
qual RC voltou?
o agente tentou novamente?
qual decisão final tomou?
Pronto.
Nasceu o conceito:
SMF para agentes.
Não precisa ser literalmente SMF.
Mas filosoficamente é exatamente isso.
O livro-caixa da atividade digital.
💥 18. O S0C7 cognitivo
O velho COBOL conhece:
S0C7
S0C4
Uxxxx
SQLCODE
RESP
RESP2
RETURN-CODE
Agora chegam novos primos:
GROUNDING FAILURE
TOOL NOT FOUND
PERMISSION DENIED
TIMEOUT
HALLUCINATED PARAMETER
AGENT LOOP
CONTEXT OVERFLOW
POLICY VIOLATION
CONNECTOR FAILURE
A produção não deixou de ser produção porque colocamos IA nela.
Ao contrário.
Ficou mais interessante.
E talvez mais perigosa.
🛠️ 19. GitHub Copilot: não é só completar MOVE
Outro erro comum:
“GitHub Copilot serve para escrever código mais depressa.”
Serve.
Mas isso é apenas a camada superficial.
Imagine o SDLC:
REQUISITO
|
v
DESIGN
|
v
CÓDIGO
|
v
TESTE
|
v
REVIEW
|
v
SECURITY
|
v
CI/CD
|
v
PRODUÇÃO
|
v
OPERAÇÃO
Se você mede somente:
linhas geradas por IA
está olhando um pedaço pequeno.
Perguntas melhores:
Quanto caiu o tempo para implementar mudança?
Quantos defeitos chegam à produção?
Quanto aumentou cobertura de teste?
Quanto tempo leva code review?
Quanto conhecimento de sistema legado pode ser recuperado?
Agora imagine um programa COBOL de 9.000 linhas sem documentação.
Um assistente pode ajudar a:
explicar parágrafos;
sugerir testes;
encontrar possíveis dependências;
gerar documentação inicial;
explicar copybooks;
comparar versões;
criar exemplos de chamada.
Mas nunca esqueça:
a IA pode ajudar a ler o programa; não significa que compreendeu perfeitamente quarenta anos de regra de negócio escondida ali.
O comentário:
* CALCULA TAXA ESPECIAL
talvez tenha sido escrito em 1998 por alguém que já se aposentou.
E “especial” pode significar absolutamente qualquer coisa.
🧪 20. Laboratório para o jovem COBOLero
Vamos montar mentalmente um pequeno projeto.
Objetivo:
usuário pergunta o saldo de uma conta através de um agente.
🧪 29. Passo a passo para estudar isso sem enlouquecer
Para o programador COBOL iniciante eu seguiria esta ordem:
Primeiro: domine o seu terreno.
Aprenda:
COBOL
JCL
Db2
CICS
VSAM
z/OS
Não abandone fundamento porque apareceu IA.
Segundo: aprenda HTTP e REST.
Entenda:
GET
POST
PUT
DELETE
JSON
status codes
authentication
É a ponte entre mundos.
Terceiro: aprenda APIs no z/OS.
Descubra como programas e transações podem ser expostos com segurança.
Quarto: entenda identidade.
OAuth.
Tokens.
Scopes.
Roles.
Least privilege.
Quinto: estude automação.
Flows.
Logic Apps.
Power Automate.
Mensageria.
Eventos.
Sexto: só então mergulhe em agentes.
Porque agente sem entender os sistemas abaixo vira mágica.
E engenheiro não pode operar produção baseado em mágica.
🗺️ 30. O mapa final do Stargate
Agora podemos desenhar tudo.
USER
|
v
MICROSOFT 365
Teams / Outlook / Word
|
v
COPILOT / AGENT
|
+----------+----------+
| |
v v
KNOWLEDGE TOOLS
| |
Graph / Search Power Automate
Fabric / Data APIs / Flows
| |
+----------+----------+
|
v
INTEGRATION
|
v
ENTERPRISE SYSTEMS
SAP / CRM / MAINFRAME
|
v
CICS / IMS / Db2
|
v
COBOL
EVENT
|
v
CONTEXT
|
v
REASONING
|
v
POLICY
|
v
ACTION
|
v
TRANSACTION
|
v
AUDIT
|
v
FEEDBACK
E aqui está talvez a conclusão mais importante para quem está começando agora em COBOL:
você não chegou atrasado.
Na realidade, está entrando numa profissão no momento em que dois mundos começam a se encontrar.
De um lado:
COBOL
CICS
Db2
IMS
JCL
sistemas construídos para serem previsíveis, transacionais, auditáveis e confiáveis.
Do outro:
LLMs
Copilots
Agents
Semantic Search
Natural Language
sistemas construídos para interpretar contexto, intenção e linguagem.
O futuro empresarial provavelmente não pertence exclusivamente a nenhum deles.
Pertence à composição:
probabilidade na interpretação, determinismo na transação.
A IA pergunta:
“O que o humano está tentando fazer?”
O agente decide:
“Qual capacidade devo chamar?”
A política pergunta:
“Ele pode?”
O COBOL responde:
“Passe os parâmetros corretamente e eu executo.”
O Db2 grava.
O log registra.
O auditor dorme.
E em algum lugar do datacenter um velho programa que nasceu quando Stargate SG-1 ainda passava na televisão recebe uma chamada REST, processa quinze milhões de dólares em menos de um segundo e volta:
RETURN-CODE = 0
O jovem programador olha para aquilo.
Olha para o Copilot.
Olha novamente para o COBOL.
E finalmente entende:
o Stargate nunca serviu para destruir o planeta antigo.
MIPS, MSU e o Mistério da Conta que Cresce Mais Rápido que o Banco
Ou: como um programador COBOL iniciante descobre que um PERFORM inocente pode terminar numa reunião com o CFO
Se você está começando em COBOL, provavelmente alguém já lhe contou a versão resumida da história.
O mainframe é grande.
O mainframe é caro.
MIPS é alguma coisa relacionada a capacidade.
MSU é alguma coisa relacionada a cobrança.
E se você mexer num programa errado, algum senhor de barba grisalha aparecerá atrás de você com uma planilha impressa e uma expressão que significa:
— Filho… o que exatamente você colocou em produção ontem?
Essa versão não está completamente errada.
Mas está longe de contar a história inteira.
Porque existe um detalhe fascinante no universo IBM Z: uma linha de código pode ser tecnicamente correta, produzir exatamente o resultado esperado, passar nos testes, não gerar ABEND, não provocar S0C7, não derrubar CICS, não assustar RACF e ainda assim ser economicamente horrível.
E é aqui que nosso jovem gafanhoto COBOL entra no dojo.
Imagine o Sr. Miyagi diante de um terminal 3270.
Ele olha para você e diz:
— Bellacosa-san… programa bom não é programa que apenas funciona.
Você pergunta:
— Então o que é?
Ele aponta para o SMF.
— Programa bom trabalha certo, trabalha rápido e não põe fogo na fatura.
A aula começa.
🥋 1. Primeiro golpe: MIPS não é MSU
Antes de continuar, precisamos desmontar uma confusão muito comum.
MIPS e MSU aparecem frequentemente na mesma conversa, mas não são a mesma coisa.
MIPS significa, historicamente:
Millions of Instructions Per Second.
É uma forma tradicional de falar de capacidade computacional.
Só que em mainframe moderno isso precisa ser tratado com cuidado, porque uma “instrução” não é simplesmente uma moedinha universal que vale a mesma coisa em qualquer processador, geração ou workload.
Duas máquinas podem ter características diferentes.
Dois workloads podem exercitar partes diferentes do processador.
Uma aplicação matemática pesada se comporta de uma forma.
Um workload de transações CICS de outra.
Um batch COBOL gigante de outra.
Por isso, MIPS virou muito mais uma linguagem de capacidade e planejamento — e também, em muitos casos, uma unidade comercial usada por fornecedores de software — do que uma medida física absoluta.
MSU significa:
Million Service Units.
E aqui entramos diretamente no mundo de pricing e capacidade do software IBM Z.
A primeira regra do dojo é esta:
MIPS é normalmente uma conversa sobre capacidade. MSU pode ser uma conversa sobre capacidade, licenciamento e custo.
Mas cuidado.
Não saia por aí tentando converter:
1 MSU = 7,3 MIPS
como se estivesse convertendo quilômetros em milhas.
Não funciona assim.
Não existe uma conversão universal simples.
Se algum colega lhe entregar uma tabela mágica dizendo:
MSU × número secreto = MIPS
faça aquilo que todo programador COBOL experiente faz diante de uma planilha duvidosa:
olhe desconfiado.
Depois peça a fonte.
🧠 2. CPU também não é custo
Aqui vem a segunda rasteira.
O iniciante pensa:
“Se meu programa gastou 10% mais CPU, a empresa pagará 10% mais.”
Não necessariamente.
Você pode gastar mais CPU sem aumentar determinada parte do custo.
Pode gastar a mesma CPU e aumentar a conta.
Pode diminuir CPU e ter pouco impacto financeiro.
Pode simplesmente mudar o horário de execução e alterar completamente o efeito econômico.
Você acabou de conhecer uma das verdades mais importantes do mainframe:
Performance e custo são parentes, mas não são gêmeos.
Isso explica um fenômeno aparentemente absurdo.
Um banco pode crescer 8% em volume de negócio.
O consumo pode crescer 15%.
E a conta de software subir 30%.
O CFO olha para aquilo e pergunta:
— Quem roubou os outros 22%?
Nesse momento todos olham para o mainframe.
O mainframe olha para o teto.
O COBOL olha para o Db2.
O Db2 olha para o batch.
E o batch diz:
— Eu só estava seguindo o JCL.
⏰ 3. Conheça o monstro chamado R4HA
Agora o Sr. Miyagi pega quatro pedras e coloca sobre a mesa.
Cada pedra representa uma hora.
Ele diz:
— Quatro horas. Observe.
Em vários modelos tradicionais de subcapacity pricing existe um conceito muito importante:
Em determinados modelos tradicionais de cobrança, o pico relevante dessa média móvel pode influenciar a capacidade faturável.
E então acontece a tragédia clássica.
Durante o dia:
CICS 70
Db2 40
APIs 20
online geral 15
Tudo administrável.
Às 17h alguém dispara:
fechamento
relatório regulatório
batch contábil
extração de dados
reconciliação
backup lógico
Todos juntos.
Porque sempre foi assim.
Desde 1998.
Ninguém sabe exatamente por quê.
Mas existe um comentário no JCL:
//* NAO ALTERAR - PRODUCAO
E isso, no mainframe, às vezes tem o mesmo poder psicológico de uma placa escrita:
TUMBA DO FARAÓ — NÃO ABRIR.
O consumo dispara.
O banco não ficou três vezes maior.
O mundo não começou a fazer três vezes mais PIX.
Apenas vários workloads decidiram executar simultaneamente.
E aquela concentração pode produzir impacto econômico.
Esse é um dos motivos pelos quais scheduling pode ser tão importante quanto programação.
🎯 4. Primeira lição de ouro: deslocar não é otimizar
Imagine um batch que consome:
60 CPU seconds
Você executa às 17h.
Depois desloca para 02h.
Ele continua consumindo:
60 CPU seconds
Tecnicamente você não otimizou o código.
Não reduziu nenhuma instrução.
Não mexeu no COBOL.
Não mudou Db2.
Não alterou VSAM.
Mas pode ter melhorado a economia do ambiente dependendo do modelo de cobrança.
Isso é lindo porque destrói uma ideia muito comum:
otimização = mexer no programa.
Não.
Você pode otimizar:
código;
SQL;
scheduling;
arquitetura;
classificação de workload;
uso de processadores especializados;
política de capacidade;
configuração;
contrato.
Programador COBOL iniciante costuma enxergar apenas o programa.
Engenheiro mainframe experiente começa a enxergar o sistema inteiro.
Essa é a evolução.
🧾 5. Antes de mexer em qualquer coisa, descubra o contrato
Aqui está uma frase que deveria ser impressa em canecas:
Antes de otimizar o mainframe, descubra como o mainframe está sendo cobrado.
Porque não existe “a conta do mainframe”.
Existem várias contas.
Você pode ter:
hardware
software IBM
software ISV
storage
suporte
DR
licenças por capacidade
licenças por consumo
licenças por MIPS
modelos tradicionais
Tailored Fit Pricing
contratos especiais
E cada parte pode reagir de maneira diferente.
Imagine que você passe uma semana reduzindo um batch em 20%.
Excelente.
Mas descubra depois que aquele componente específico não altera o custo relevante do contrato atual.
Você melhorou performance.
Ótimo.
Só não economizou o que esperava.
Agora faça o contrário.
Você move um workload, altera uma janela de execução e reduz um pico economicamente relevante.
Nenhuma linha COBOL mudou.
E o financeiro percebe o efeito.
Bem-vindo ao mainframe.
🐍 6. O segundo monstro está dentro do seu COBOL
Agora finalmente chegamos à parte que interessa diretamente ao jovem programador.
Imagine este código:
PERFORM UNTIL WS-EOF = 'Y'
READ ARQUIVO-CLIENTES
...
END-PERFORM.
Em 2001 o arquivo tinha:
500.000 registros
Em 2026:
40.000.000 registros
O código não piorou.
Ele é exatamente o mesmo.
Mas o mundo ao redor cresceu.
Isso ensina uma coisa importante:
Código velho pode ficar economicamente pior sem mudar uma única linha.
Quantas execuções?
Quantos registros?
Quantas transações?
Qual crescimento mensal?
Passo 3 — observe o custo por unidade
Não pense apenas:
programa gastou 200 CPU seconds
Pergunte:
200 CPU seconds para quantos registros?
Passo 4 — procure regressões
Compare versões.
Antes:
10 ms por transação
Depois:
18 ms
Alguma coisa mudou.
Passo 5 — veja SQL
Se usa Db2:
qual access path?
qual frequência?
quantas rows examinadas?
quantas retornadas?
Passo 6 — olhe scheduling
Seu job executa quando?
Ele compete com quem?
Existe motivo?
Passo 7 — pergunte sobre WLM
Qual service class?
Qual prioridade?
Qual objetivo?
Passo 8 — correlacione com negócio
Essa aplicação atende:
PIX?
cartões?
clientes?
folha?
fraude?
Passo 9 — documente
Porque seis meses depois alguém perguntará.
E talvez esse alguém seja você.
🕵️ 19. Um exemplo completo
O CFO diz:
— Conta de mainframe subiu 30%.
O time investiga.
Descobre:
crescimento normal do negócio +8%
novo antifraude +5%
nova observabilidade +3%
SQL regressivo +7%
batch concentrado em pico +4%
processo duplicado +2%
outros +1%
----
30%
Agora a conversa mudou.
Dos 30%:
16% = crescimento + capacidade nova
13% = problemas investigáveis/otimizáveis
1% = ainda desconhecido
Isso é infinitamente melhor do que:
— Mainframe ficou caro.
Agora temos ações.
SQL regressivo?
Corrigir.
Batch?
Reagendar se fizer sentido no modelo econômico.
Processo duplicado?
Eliminar.
Antifraude?
Manter.
Porque aquilo protege o banco.
🧩 20. Easter egg para quem chegou até aqui
Existe uma velha tendência em computação de tentar transformar tudo numa métrica simples.
MIPS.
CPU.
TPS.
latência.
custo.
Mas sistemas complexos odeiam métricas isoladas.
É quase um princípio de Douglas Adams aplicado ao datacenter:
A resposta pode ser 42. O problema é descobrir qual era a pergunta.
Se alguém chegar na reunião dizendo:
— O sistema usa 12.000 MIPS.
A pergunta correta é:
— E daí?
12.000 MIPS pode ser excelente.
Pode ser horrível.
Pode ser barato.
Pode ser caro.
Pode estar processando milhões de transações com eficiência fantástica.
Ou pode estar queimando CPU lendo o mesmo arquivo quinze vezes.
A métrica sem contexto é apenas um número muito bem vestido.
🥋 21. A última lição do dojo
O jovem programador começa querendo aprender:
MOVE
PERFORM
IF
EVALUATE
READ
WRITE
CALL
Depois aprende:
JCL
VSAM
Db2
CICS
Depois entende:
SMF
RMF
WLM
R4HA
zIIP
pricing
capacity
E então acontece uma mudança interessante.
Ele deixa de pensar:
“Meu programa funciona?”
E começa a perguntar:
“Meu programa funciona bem dentro do sistema?”
Depois:
“Meu sistema usa recursos de maneira eficiente?”
E finalmente:
“O custo computacional produzido por esse workload faz sentido para o negócio?”
Nesse ponto você deixou de ser apenas programador COBOL.
Começou a pensar como engenheiro de plataforma.
☕ Epílogo — O CFO, o COBOL e a conta de luz
Voltemos à primeira cena.
Sala de reunião.
CFO na ponta da mesa.
Gráfico na tela.
Ele pergunta:
— Por que o custo do mainframe subiu 30% se o negócio cresceu 8%?
Silêncio.
Antigamente alguém responderia:
— Houve aumento de capacidade.
Hoje uma equipe madura deveria responder:
— Dos 30 pontos, oito correspondem ao crescimento do negócio. Cinco vieram do antifraude novo. Três da observabilidade. Sete são uma regressão Db2 já identificada. Quatro vieram de concentração de workloads numa janela economicamente desfavorável. Dois correspondem a processos redundantes em eliminação. Um ainda estamos investigando.
Agora o CFO entende.
E o mais importante:
confia.
Porque ninguém está defendendo mainframe com religião.
Está defendendo com dados.
Essa é talvez a grande diferença entre o velho discurso:
“Mainframe é caro, mas confiável.”
e o discurso moderno:
“Eu sei exatamente quanto custa, quem consome, por que consome e o que recebemos em troca.”
No fundo, MIPS e MSU não são apenas unidades técnicas.
São pistas.
SMF é a cena do crime.
RMF é o perito.
WLM organiza o trânsito.
Db2 às vezes é o suspeito.
O batch jura inocência.
O COBOL diz que só cumpriu ordens.
O CFO quer saber quem vai pagar.
E em algum canto escuro do datacenter existe um job de 1997 executando toda terça-feira às 02h13 porque alguém escreveu no JCL:
//* NAO REMOVER
Ninguém sabe quem.
Ninguém sabe por quê.
Mas ele continua lá.
Consumindo CPU.
Silenciosamente.
À espera de um jovem gafanhoto suficientemente curioso para perguntar:
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
