🍩 Churros Paulista: o mainframe açucarado das ruas de São Paulo

 

🍩 Churros Paulista: o mainframe açucarado das ruas de São Paulo

Por Vagner Bellacosa ☕💭

Existem sons que definem uma cidade.
Em São Paulo, é o apito do metrô, o freio do busão… e o bip-bip mágico do carro de churros subindo a rua às quatro da tarde.
Esse é o chamado ancestral da infância, o interrupt mais doce do sistema operacional da memória paulistana.

O churros, que nasceu na Espanha, atravessou o oceano e chegou ao Brasil pelas mãos dos imigrantes ibéricos e feirantes criativos. Mas foi nas ruas de São Paulo, nos anos 1970 e 1980, que ele ganhou alma própria: recheado, doce e ambulante.
Nada de café com leite e jornal. O verdadeiro lanche da tarde era um churros de doce de leite escorrendo, embalado em guardanapo e saudade.

---

🌆 De Madrid ao M’Boi Mirim

Na Espanha, churros se come com chocolate quente, em cafés fechados.
Em São Paulo, se come na calçada, em pé, ao som do trânsito.
O paulista, prático e faminto, não quis esperar o chocolate derreter — preferiu o recheio pronto, direto da máquina prateada que parece saída de um laboratório soviético.

O carro de churros virou parte do DNA das quebradas: inox reluzente, aroma de fritura, doce de leite fervendo, e aquele operador lendário — o sysadmin do açúcar — girando a manivela com a precisão de um programador COBOL veterano.

---

💾 Arquitetura de um churros perfeito

Um churros é basicamente uma transação batch de felicidade:

• Massa quente (input).

• Fritura crocante (processamento).

• Doce de leite ou goiabada (output).

• Açúcar e canela (logging).

Quando tudo roda sem erro, o resultado é um commit direto no coração.

---

🍯 Curiosidades e cultura

• O primeiro carro de churros paulistano data do início dos anos 70, inspirado nas “churrerías” espanholas, mas adaptado ao estilo de rua brasileiro.

• Nos anos 90, o churros de feira virou febre: doce de leite, chocolate, goiabada — e mais tarde, até “duplo recheio”, uma inovação que faria Turing sorrir.

• Hoje, há food trucks gourmet tentando reinventar o clássico… mas a verdade é: churros bom é o do tio da esquina, com óleo duvidoso e amor garantido.

---

☕ Bellacosa comenta

O churros paulista é o mainframe do açúcar urbano — sólido, resiliente e sempre em produção, mesmo sem contrato de manutenção.
Ele representa o Brasil como ele é: doce, criativo e um pouco improvisado.
E quando o bip-bip ecoa pela rua, não é só comida… é o ping da infância chamando pra login.

📟🌸 “ABEND NO SISTEMA, FOME NO SISTEMA — UM DIA COMUM NO ANTIGO ABN AMRO REAL”

 

📟🌸 “ABEND NO SISTEMA, FOME NO SISTEMA — UM DIA COMUM NO ANTIGO ABN AMRO REAL”
Crônica Bellacosa Mainframe para os padawans otakus com CPF ativo e saudade de São Paulo raiz

---

Estamos em 1999, avenida Paulista, coração financeiro do Brasil, ainda atarefados com a fusão do banco, as correções do bug do milenio, o famoso Y2k. Mas era um dia absolutamente comum no antigo ABN AMRO Real, aquele prédio onde a gente sabia que se o CICS estivesse lento, provavelmente a cafeteria também estaria, entupida de analistas parlapiando. Eu e a Lili estávamos naquela conversa matinal clássica de quem já sobreviveu a mais dumps do que relacionamentos:

— “Capitão, você já viu esse ABEND S0C7? Seu programa de rateio de acionista,, aqui tá mastigando alfanumérico como se fosse RAMEN.”
— “Manda o dump, Lili… vamos ver qual tabela ODO explodiu desta vez.”

Enquanto o SYSLOG cuspia mensagens $HASP e o RACF fazia aquele “não vai passar!” digno de Gandalf corporativo, monte de memos enviados a Analise de Produção e naquele status de waiting, quando a conversa desandou — como sempre — para comidas japonesas.

Porque é isso: nada une mais um time de mainframe do que COBOL e carboidratos.

---

🍙 ONIGUIRI — O Capitão jurava que era coxinha triangular

Lili, com a sabedoria ancestral de quem já brigou com VSAM RLS, disse:

— “Lili, não se estresse, mas eu sempre achei que oniguiri era tipo uma coxinha de sushi.”

E Lili, já em modo senpai, mas quase tacando o teclado na minha cabeça:

— “Oniguiri é arroz moldado com carinho e desespero… tipo adaptar copybook novo às 11h58 antes de virar janela.”

Falamos de umeboshi, nori, triângulos, e daquela clássica cena dos animes em que o herói segura o oniguiri com brilho mágico como se fosse um “recupera arquivo perdido” do SDSF.

---

🍢 DANGO — O trio bolinha que parece job rodando em classe A

Eu ri:

— “Dango parece spool: tudo em filinha.”

E a Lili:

— “E quando vem com molho mitarashi, parece até que passaram caramelo na JCL pra ver se roda mais rápido.”

Já estávamos naquele nível da fome em que qualquer objeto circular virava comida.

---

🍰 CASTELLA — O bolo que engana qualquer analista no horário da tarde

Este curioso e atrapalhado amigo:

— “Esse é aquele bolo de mel que parece pão de ló?”

Lili no comando...

— “Sim, o bolo importado pelos portugueses no século XVI… o único código legado dessa época que ainda funciona sem ABEND.”

---

🍮 PUDIM JAPONÊS — O PUDIM OTAKU OFICIAL

E, obviamente, caímos na discussão eterna: “Por que no anime o pudim brilha?”

Minha resposta técnica:

— “Porque os animadores usam brilho pra dizer: ‘se alguém comer isso sem permissão, o episódio vira filler de briga’.”

---

De repente…

⏰ O relógio do CICS marcava 11h59

E Lili soltou:

— “Capitão, se a gente não sair AGORA, só sobra aquele obentô triste com arroz duro do bar da esquina.”

E como dois analistas experientes evitando S322 em batch crítico, levantamos imediatamente.

---

🍜 Destino: Um restaurante japonês delicioso na Brigadeiro Luís Antônio

Saímos pela Paulista com aquela sensação de missão crítica:
“Se não chegar antes do meio-dia, a fila é maior que validação de RACF num dia de troca de senha.”

E fomos lembrando dos clássicos:

• Temaki do tamanho de um volume VSAM

• Lámen fumegante que cura até dump de madrugada

• Katsu que crunch-crunch igual teclado mecânico novo do programador

• Karaage que te dá vontade de escrever copybooks melhores

Lili, empolgada:

— “Hoje eu quero katsudon. Igual o do Yu-Gi-Oh.”
— “Mano… katsudon é do Yuri on Ice.”
— “É tudo com Y… deixa quieto.”

E rimos.

Porque mainframe é isso:
entre um ABEND e outro, a gente cria histórias, gargalha e sempre, sempre planeja o almoço.

🍡🍡🍡 Para saber mais sobre delícias da culinária niponica: 🍱🍱🍱

30 comidas japonesas em animes

https://eljefemidnightlunch.blogspot.com/2012/08/30-comidas-otaku-que-aparecem-em-animes.html

Doces niponicos para otakus

https://eljefemidnightlunch.blogspot.com/2013/06/parte-1-doces-otaku.html

Comidas japonesas de rua e barraquinhas

https://eljefemidnightlunch.blogspot.com/2014/10/parte-2-lanches-street-food-otaku.html

Pratos quentes e deliciosos da culinaria japonesa

https://eljefemidnightlunch.blogspot.com/2015/09/parte-3-pratos-quentes-caseiros-otaku.html

Comidas classicas japonesas.

https://eljefemidnightlunch.blogspot.com/2016/07/parte-4-classicos-tradicionais.html

Comidas exoticas e bizarras no Japão

https://eljefemidnightlunch.blogspot.com/2017/01/parte-5-comidas-estranhas-bizarras-dos.html

🧨 Parte 2 — O Século da Pressa: O Mercado Engoliu o Homem

 

🧨 Parte 2 — O Século da Pressa: O Mercado Engoliu o Homem

por Bellacosa Mainframe ☕💼

O novo milênio chegou prometendo liberdade, tecnologia e prosperidade.
Mas entregou algo bem diferente: pressa, cobrança e cansaço crônico.

Os anos 2000 e 2010 foram o laboratório da ansiedade.
O crachá, antes símbolo de pertencimento, virou algema digital.
E o antigo pacto entre empresa e empregado se dissolveu como café solúvel na água morna do RH.

A meritocracia virou religião, e o PowerPoint, seu evangelho.
Coach virou profeta, KPI virou mandamento.
Aquele escritório onde o chefe conhecia o nome de todos foi substituído por open spaces com eco de solidão — e frases motivacionais coladas na parede pra disfarçar o vazio:

“Sonhe grande”,
“Pense fora da caixa”,
“Vista a camisa.”

Sim, a mesma camisa que agora ninguém mais lavava — porque ninguém mais tinha tempo.

---

⚙️ A Era do Desempenho Infinito

A lógica mudou.
Trabalhar deixou de ser um meio de vida e passou a ser um modo de sobrevivência emocional.
As metas se multiplicaram, os bônus diminuíram, e a pressão virou combustível.

As empresas descobriram que o medo é mais eficiente que o salário.
Basta ameaçar o desligamento, e pronto: nasce o colaborador ideal, sempre disponível, sempre sorrindo, mesmo com o burnout pendurado no crachá.

💻 As salas ficaram mais modernas, as pessoas mais exaustas.
Os computadores ficaram mais rápidos, os dias mais curtos.
E o elogio se tornou uma moeda rara — trocada apenas por “proatividade”, “resiliência” e “espírito de dono”.

---

🧠 Curiosidade de bastidor

Foi nessa época que o departamento de Recursos Humanos deixou de cuidar de pessoas e passou a administrar métricas.
RH virou planilha, e gente virou dado.
Os “colaboradores” começaram a se tratar como “ativos humanos”.
A linguagem corporativa virou uma espécie de dialeto orwelliano:
“Desligamento” no lugar de “demissão”.
“Sinergia” no lugar de “ordem”.
“Propósito” no lugar de “lucro”.

---

📟 Easter-egg: O 3270 do Capitalismo Turbo

No mainframe, o terminal 3270 responde rápido — mas só se você sabe o comando certo.
No capitalismo moderno, os comandos mudaram.
O “F3=Exit” foi substituído por “F∞=MaisMetas”.
E o “Enter” virou o novo “Sim, senhor”.

A velocidade que antes era sinal de eficiência virou sinônimo de ausência de pausa.
Trabalhar virou rodar em loop, sem commit de reconhecimento.

---

💣 O novo credo

O trabalhador pós-2000 aprendeu a sorrir cansado.
A dizer “tudo bem” quando não está.
A acreditar que o sucesso está a um curso online de distância — quando o verdadeiro curso é pra dentro, não pra fora.

A empresa virou um organismo faminto:
se alimenta da energia, do tempo e da juventude de seus colaboradores.
E ainda manda um e-mail motivacional no fim do expediente com o assunto:

“Juntos, somos mais fortes.”

---

🎯 Conclusão Bellacosa

A pressa virou o novo status.
Quem dorme, perde.
Quem sente, atrasa.
Quem pensa, questiona — e quem questiona, é desligado.

Vivemos a era em que o crachá não abre portas — abre feridas.
A meritocracia virou máscara pra desigualdade, e o “propósito corporativo” virou anestesia pra um sistema que suga em nome da performance.

A alma do trabalho foi substituída por métricas, e o tempo virou um ativo tóxico.
Bem-vindo ao Século da Pressa —
onde todo mundo corre, mas ninguém chega a lugar nenhum.

---

💼 #ElJefeMidnight #BellacosaMainframe #CrônicasDoTrabalho
🚀 #Meritocracia #FuturoDoTrabalho #RH #Performance #AnsiedadeCorporativa #COBOLDaVida

Lean vs Kaizen vs Six Sigma : O Que Todo Programador COBOL Padawan

 

Bellacosa Mainframe lean kaizen e six sigma 

☕ Um Café no Bellacosa Mainframe

Lean vs Kaizen vs Six Sigma

O Que Todo Programador COBOL Padawan Precisa Saber Sobre as Três Filosofias que Mantêm Bancos, Mainframes e Grandes Empresas Funcionando Há Décadas

"Qualidade não acontece por acaso. Ela é construída todos os dias, medida continuamente e aperfeiçoada infinitamente."

Quando alguém começa a estudar melhoria contínua, normalmente encontra três nomes que parecem sinônimos:

• Lean

• Kaizen

• Six Sigma

Mas eles não são a mesma coisa.

Na verdade, eles atacam problemas completamente diferentes.

É como administrar um IBM Z.

Você pode:

• eliminar processamento desnecessário;

• melhorar continuamente seus procedimentos;

• ou reduzir erros críticos em produção.

Cada abordagem resolve um tipo específico de problema.

A grande descoberta das empresas mais eficientes do mundo foi perceber que não existe competição entre Lean, Kaizen e Six Sigma. Existe complementaridade.

Toyota, IBM, GE, Amazon, Boeing, Intel e praticamente toda empresa de classe mundial utiliza uma combinação dessas filosofias.

Vamos entender por quê.

---

Antes de tudo...

Imagine um sistema bancário rodando em COBOL.

Durante um processamento batch noturno existem três problemas possíveis.

Problema 1

O processamento demora 8 horas.

Não existem erros.

Tudo funciona.

Mas demora demais.

Esse é um problema de...

Lean.

---

Problema 2

O processamento funciona hoje.

Mas amanhã alguém encontra uma pequena melhoria.

Depois outra.

Depois outra.

Todos colaboram.

Esse é um problema de...

Kaizen.

---

Problema 3

O processamento termina em 2 horas.

Mas a cada 5 dias aparece um ABEND diferente.

Ou registros inconsistentes.

Ou valores incorretos.

Esse é um problema de...

Six Sigma.

Observe que são problemas completamente diferentes.

---

Lean

A arte de eliminar desperdícios

Lean nasceu no Sistema Toyota de Produção.

Seu objetivo é extremamente simples.

Fazer mais utilizando menos.

Menos:

• tempo

• estoque

• movimentação

• espera

• retrabalho

• burocracia

• custo

Lean pergunta constantemente:

"Existe alguma atividade aqui que não agrega valor ao cliente?"

Se a resposta for sim...

Ela deve ser eliminada.

---

O que é desperdício?

No Lean, desperdício recebe o nome japonês:

Muda (無駄)

Taiichi Ohno identificou sete desperdícios clássicos, depois ampliados para oito.

1. Superprodução

Produzir antes da hora.

Exemplo Mainframe:

Gerar dezenas de relatórios que ninguém lê.

---

2. Espera

Jobs aguardando recursos.

Exemplo:

Batch esperando dataset.

---

3. Transporte

Mover informações desnecessariamente.

Exemplo:

Transferências repetidas entre ambientes.

---

4. Processamento excessivo

Fazer mais do que o necessário.

Exemplo:

Executar SORTs redundantes.

---

5. Estoque

Acumular trabalho.

Exemplo:

Milhares de requisições aguardando aprovação.

---

6. Movimentação

Pessoas gastando energia desnecessária.

Exemplo:

Operadores alternando entre dezenas de painéis.

---

7. Defeitos

Retrabalho.

Exemplo:

ABENDs.

Correções.

Reprocessamentos.

---

8. Talento desperdiçado

Talvez o maior desperdício moderno.

Ter profissionais excelentes realizando tarefas mecânicas.

---

Lean no Mainframe

Imagine um batch.

JOB A

↓

SORT

↓

SORT

↓

SORT

↓

COPY

↓

COPY

↓

REPORT

Após análise...

Descobre-se que dois SORTs são desnecessários.

Resultado:

• menos CPU

• menos I/O

• menos tempo

• menos custo

Isso é Lean.

---

Kaizen

A filosofia do "sempre um pouco melhor"

Kaizen significa literalmente:

改善

Kai = mudança

Zen = melhor

Ou seja...

"Mudança para melhor."

Mas existe um detalhe importante.

Kaizen não busca revoluções.

Busca pequenas melhorias.

Todos os dias.

---

O poder das pequenas melhorias

Imagine melhorar um processo apenas 1% por dia.

Parece insignificante.

Mas ao longo do tempo...

A melhoria composta torna-se gigantesca.

É exatamente isso que tornou a Toyota uma referência mundial.

---

Kaizen não depende da chefia

Esse é um dos maiores erros de interpretação.

Muitos acreditam que melhoria depende do gerente.

Kaizen diz justamente o contrário.

Todo colaborador deve sugerir melhorias.

Desde:

• estagiário

• operador

• analista

• desenvolvedor

• arquiteto

• diretor

Todos participam.

---

Exemplo Mainframe

Um desenvolvedor COBOL percebe que:

Todos os programas repetem o mesmo código de validação.

Ele cria uma COPYBOOK.

Agora:

Antes:

200 linhas repetidas

Depois

COPY VALIDA-CPF.

Pequena melhoria.

Grande impacto.

Isso é Kaizen.

---

Six Sigma

A ciência da redução da variabilidade

Enquanto Lean pergunta:

"Existe desperdício?"

Six Sigma pergunta:

"Por que o processo produz resultados diferentes?"

A palavra-chave aqui é:

Variabilidade.

---

Imagine um caixa eletrônico.

Ele deve entregar exatamente:

R$100

Sempre.

Não:

R$99

Nem:

R$101

Nem:

Erro de leitura.

Nem:

Travamento.

Nem:

Falha ocasional.

Processos críticos precisam ser previsíveis.

É isso que Six Sigma busca.

---

O significado de Sigma

Sigma (σ) representa o desvio padrão.

Quanto menor a variação...

Mais previsível o processo.

Six Sigma significa atingir um nível extremamente alto de qualidade.

Na prática, a meta clássica é cerca de 3,4 defeitos por milhão de oportunidades (DPMO) sob premissas específicas do método.

---

DMAIC

Six Sigma utiliza um roteiro muito conhecido.

D — Define

Definir o problema.

---

M — Measure

Medir.

Sem dados...

Não existe Six Sigma.

---

A — Analyze

Descobrir a causa raiz.

---

I — Improve

Implementar melhorias.

---

C — Control

Garantir que o problema não volte.

---

Six Sigma no Mainframe

Imagine um sistema financeiro.

De cada

10 milhões

de transações...

120 apresentam erro.

O objetivo é descobrir:

Por quê?

Em qual módulo?

Qual horário?

Qual banco?

Qual rotina?

Qual variável?

Six Sigma vive de estatística.

Não de opiniões.

---

Lean x Kaizen x Six Sigma

Lean	Kaizen	Six Sigma
Remove desperdícios	Melhoria contínua	Remove variabilidade
Mais velocidade	Mais evolução	Mais qualidade
Fluxo	Cultura	Estatística
Eficiência	Pessoas	Dados
Custos	Engajamento	Precisão

---

Uma analogia perfeita

Imagine uma rodovia.

Lean:

Retira congestionamentos.

Kaizen:

Melhora a estrada diariamente.

Six Sigma:

Garante que nenhum carro saia da pista.

São problemas diferentes.

---

Como IBM Mainframe utiliza essas filosofias?

Embora muitas vezes associadas à indústria automotiva, essas abordagens são extremamente relevantes em ambientes IBM Z.

Lean

• redução de consumo de CPU

• otimização de JCL

• eliminação de etapas redundantes

• redução de I/O

• tuning de SQL no Db2

• consolidação de jobs

---

Kaizen

• padronização de COPYBOOKs

• melhoria contínua de procedimentos operacionais

• revisão de convenções de nomenclatura

• documentação viva

• automação incremental com REXX, Ansible ou Zowe

---

Six Sigma

• redução de ABENDs

• análise estatística de falhas

• monitoramento de SLAs

• controle de incidentes

• melhoria da confiabilidade em sistemas financeiros

• uso de métricas de qualidade em testes e produção

---

Onde entram os Core Quality Tools?

As três filosofias utilizam diversas ferramentas de apoio.

Por exemplo:

• Lean: Value Stream Mapping (VSM), Kanban, 5S, SMED, Heijunka, Takt Time.

• Kaizen: PDCA, 5W2H, Brainstorming, A3 Report, Gemba Walk, Círculos de Qualidade.

• Six Sigma: DMAIC, Controle Estatístico de Processo (SPC), Cartas de Controle, Histograma, Diagrama de Pareto, Análise de Capabilidade, DOE, MSA e FMEA.

Os 7 Core Quality Tools (Fluxograma, Folha de Verificação, Pareto, Ishikawa, Histograma, Diagrama de Dispersão e Carta de Controle) são amplamente utilizados em Kaizen e Six Sigma, fornecendo dados para análise e melhoria.

---

A falsa competição

Muitas empresas perguntam:

"Devemos implantar Lean ou Six Sigma?"

A pergunta correta é:

"Qual problema queremos resolver?"

Se há desperdício...

Use Lean.

Se falta cultura de melhoria...

Use Kaizen.

Se há muitos defeitos...

Use Six Sigma.

---

Lean Six Sigma

Foi justamente por perceber que as metodologias se complementavam que surgiu o Lean Six Sigma.

Lean acelera.

Six Sigma estabiliza.

Kaizen garante que a evolução nunca pare.

É por isso que organizações maduras combinam as três abordagens em seus programas de Excelência Operacional.

---

A grande lição para um Programador COBOL Padawan

No universo IBM Mainframe, não basta escrever programas que funcionem. É preciso escrever programas eficientes, evolutivos e confiáveis.

Pense nessas três filosofias como três lentes complementares:

• Lean pergunta: "Posso fazer isso com menos recursos e menos desperdício?"

• Kaizen pergunta: "O que posso melhorar hoje, mesmo que seja apenas 1%?"

• Six Sigma pergunta: "Como garantir que esse processo produza o mesmo resultado correto, todas as vezes?"

Os sistemas bancários, de seguros, telecomunicações e governo executados em IBM Z permanecem relevantes há décadas porque incorporam esses princípios. A combinação entre eficiência operacional, melhoria contínua e controle rigoroso da qualidade é o que permite processar milhões de transações diariamente com alta disponibilidade e confiabilidade.

No fim, a verdadeira excelência operacional não surge da escolha entre Lean, Kaizen ou Six Sigma, mas da capacidade de aplicar cada abordagem no momento certo. Empresas que fazem isso constroem processos mais rápidos, equipes mais engajadas e sistemas mais robustos — exatamente as características esperadas dos ambientes críticos onde o Mainframe continua sendo referência mundial.

🧠 Modems Clássicos dos Anos 1990

Bellacosa Mainframe e os modens classicos dos anos 1990

🧠 Modems Clássicos dos Anos 1990

🧠 Introdução

Muito antes do Wi-Fi, da fibra óptica e das conexões de centenas de megabits por segundo, existia um pequeno equipamento responsável por abrir as portas para um universo completamente novo: o modem. Para milhões de pessoas durante os anos 1990, ele foi o passaporte para as primeiras BBS, para a internet comercial, para o IRC, o ICQ, o e-mail e as intermináveis madrugadas navegando enquanto a linha telefônica permanecia ocupada. Conectar-se era quase um ritual: ligar o computador, iniciar o software de comunicação, ouvir a sequência de chiados, apitos e estalos da negociação entre dois modems e torcer para que ninguém tirasse o telefone do gancho.

Cada nova geração representava uma verdadeira revolução. Dos 9.600 bps aos lendários 56K, fabricantes como U.S. Robotics, Hayes, Supra, Zoom, Motorola e Creative disputavam o mercado oferecendo velocidades maiores, correção de erros, compressão de dados e recursos como fax e secretária eletrônica. Para quem administrava uma BBS, trabalhava remotamente ou simplesmente queria baixar um arquivo sem esperar horas, escolher o modem certo era quase uma decisão estratégica.

Nesta viagem nostálgica do Bellacosa Mainframe, vamos revisitar os modems que marcaram uma geração, entender a evolução dos padrões V.32, V.34, V.90 e V.92, relembrar curiosidades da internet discada e descobrir por que aquele inesquecível som de conexão ainda desperta um sorriso em quem viveu a década de 1990.

🧠 Modems Clássicos dos Anos 1990

Ano	Modelo / Fabricante	Velocidade Máxima	Tipo / Padrão	Observações
1990	U.S. Robotics Courier HST	9.600 bps	Proprietário (HST)	Muito usado por BBS e hackers; top de linha.
1991	Hayes Smartmodem 9600	9.600 bps	V.32	Referência da época; “Hayes Compatible” virou padrão.
1992	SupraFAXModem 14400	14.400 bps	V.32bis	Popular por incluir fax e preço acessível.
1993	Zoom Telephonics 14.4	14.400 bps	V.32bis	Um dos mais vendidos para uso doméstico.
1994	USRobotics Sportster 28800	28.800 bps	V.34	Alta performance para BBS e primeiras ISPs.
1995	Hayes Accura 28800	28.800 bps	V.34	Modem confiável e fácil de configurar.
1996	USRobotics Courier V.34+	33.600 bps	V.34+	Um dos melhores modems analógicos antes do 56K.
1997	3Com/USRobotics 56K X2	56.000 bps	X2 (pré-V.90)	Tecnologia proprietária, depois virou padrão.
1998	Motorola VoiceSurfer 56K	56.000 bps	V.90	Primeiro padrão global de 56K.
1999	Creative Modem Blaster 56K	56.000 bps	V.90 / V.92	Incluía software de fax e voz, muito usado no Windows 98.

---

🧠 Como Funciona um Modem?

A palavra modem é uma abreviação de MOdulator-DEModulator (Modulador-Demodulador), e seu papel é servir como um tradutor entre o computador e a rede telefônica. Enquanto o computador trabalha exclusivamente com sinais digitais — compostos por zeros e uns —, a linha telefônica convencional foi projetada para transportar apenas sinais analógicos, ou seja, variações contínuas de frequência e amplitude semelhantes à voz humana.

Quando você enviava um arquivo ou acessava um site, o modem convertia os bits gerados pelo computador em sons eletrônicos. Esse processo é chamado de modulação. Esses sons percorriam a linha telefônica até o modem do outro lado da conexão. Ao recebê-los, o segundo modem realizava a operação inversa, denominada demodulação, reconstruindo os bits originais para que o computador receptor pudesse interpretá-los corretamente.

Antes da transmissão começar, os dois modems realizavam uma espécie de "aperto de mãos", conhecido como handshake. Era justamente essa sequência de chiados, apitos e ruídos metálicos tão característica dos anos 1990. Durante alguns segundos, os equipamentos negociavam automaticamente a maior velocidade possível, verificavam a qualidade da linha telefônica, escolhiam algoritmos de compressão de dados e ativavam mecanismos de correção de erros.

Depois que a negociação terminava, estabelecia-se uma conexão estável. Os dados passavam a trafegar em pequenos blocos, continuamente verificados para detectar perdas ou interferências. Se algum bloco chegasse corrompido pelo ruído da linha, ele era retransmitido automaticamente, garantindo a integridade da comunicação.

Nos modems mais modernos da era discada, padrões como V.34, V.90 e V.92 permitiam velocidades teóricas de até 56 Kbps. Entretanto, limitações da rede telefônica faziam com que a velocidade real normalmente ficasse entre 40 e 48 Kbps.

Embora extremamente lentos pelos padrões atuais, os modems foram a tecnologia que permitiu a popularização da internet doméstica. Eles conectaram milhões de pessoas ao mundo digital, abriram caminho para BBSs, e-mails, IRC, ICQ e para o nascimento da Web comercial, tornando-se um dos equipamentos mais importantes da história da informática e das telecomunicações.

💾 Extras e curiosidades

• 🔌 Interface: maioria conectava via porta serial RS-232, e só no fim da década surgiram os modems PCI internos.

• 📞 Linha telefônica: exigia conexão discada (com aquele som icônico “chiado de modem”).

• 📠 Fax: muitos modelos tinham função fax embutida (classe 1 e 2).

• 🖥️ Softmodems (“winmodems”) surgiram no final da década — mais baratos, mas dependentes da CPU.

• 🌐 Velocidade real: embora chamados “56K”, raramente passavam de 48 Kbps em uso real.,

Animes com Temas de Maturidade Emocional e Infância Distorcida

Bellacosa Mainframe apresenta animes com temas de maturidade

 Animes com Temas de Maturidade Emocional e Infância Distorcida

Durante muito tempo, os animes foram vistos por muita gente apenas como entretenimento infantil. No entanto, basta conhecer algumas obras para perceber que a animação japonesa é capaz de explorar temas psicológicos, filosóficos e sociais com uma profundidade surpreendente. Entre esses temas, poucos são tão impactantes quanto a maturidade emocional e a infância distorcida.

Essas histórias apresentam protagonistas que cresceram cedo demais, enfrentando abandono, violência, guerra, preconceito, perdas ou responsabilidades incompatíveis com a própria idade. Em vez de uma infância marcada por brincadeiras e descobertas, seus personagens aprendem a sobreviver em mundos onde a inocência é um luxo raro. Essa jornada transforma o amadurecimento em algo doloroso, mas também revela extraordinárias demonstrações de coragem, empatia e resiliência.

Ao acompanhar essas narrativas, o espectador é convidado a refletir sobre traumas, identidade, saúde mental, relações familiares, amizade, culpa, perdão e esperança. Muitos desses animes mostram que crescer não significa apenas envelhecer, mas aprender a lidar com as próprias feridas sem permitir que elas definam quem somos.

Neste artigo, conheceremos algumas das obras mais marcantes que abordam maturidade emocional e infância distorcida. São histórias que emocionam, provocam reflexões profundas e demonstram por que o anime se tornou uma das formas mais ricas de contar histórias sobre a condição humana.

🧠 1. Animes com Temas de Maturidade Emocional e Infância Distorcida

Esses mostram crianças enfrentando o mundo adulto cedo demais — como Rin.

a) Usagi Drop (2011)

• Tema: Adoção, crescimento, amadurecimento emocional.

• Semelhança: Relação entre adulto e criança com tom sensível e ético.

• Curiosidade: O mangá muda o tom no final (de forma polêmica), mas o anime foca apenas na parte pura e paternal.

• Mensagem: Amor responsável e amadurecimento mútuo.

b) Aishiteruze Baby★★ (2004)

• Tema: Responsabilidade, família, afeto.

• Sinopse: Um adolescente mulherengo precisa cuidar de uma garotinha abandonada.

• Semelhança: Mostra a transformação emocional de um adulto imaturo que aprende o valor da empatia e do cuidado.

c) Elfen Lied (2004)

• Tema: Trauma, abandono, inocência e violência.

• Semelhança: Assim como Rin, a protagonista Lucy carrega traumas profundos de infância e expressa amor de forma confusa e destrutiva.

---

💔 2. Animes sobre Amores Impossíveis e Relações Éticas

Retratam sentimentos complicados entre pessoas de idades ou mundos diferentes, mas com reflexão moral.

a) Koi Kaze (2004)

• Tema: Relação proibida, moral e conflito interno.

• Sinopse: Um homem adulto se apaixona pela própria irmã mais nova.

• Semelhança: Conflito entre sentimento e ética, tratado com maturidade e sofrimento, não com fetichismo.

b) Mahou Shoujo Madoka Magica (2011)

• Tema: Infância confrontando sacrifício e dor.

• Semelhança: Crianças enfrentando dilemas adultos e consequências irreversíveis.

• Mensagem: Crescer é entender a perda da inocência.

---

💬 3. Animes com Reflexão sobre Educação, Proteção e Psicologia Infantil

Retratam o papel do adulto como guia, e o impacto das emoções infantis.

a) Barakamon (2014)

• Tema: Encontro entre um artista e uma menina curiosa de uma ilha.

• Semelhança: A relação é de crescimento mútuo e ternura, sem tons provocativos.

• Mensagem: A pureza da infância pode curar um adulto quebrado.

b) Bunny Drop (Usagi Drop) – novamente se destaca aqui, como versão ética e emocional do mesmo tema.

c) March Comes in Like a Lion (2016)

• Tema: Depressão, trauma e cura emocional.

• Semelhança: A relação entre o protagonista e as irmãs Kawamoto tem a mesma função curadora que Rin tinha para Aoki, mas sem transgredir limites morais.

---

🔥 4. Obras Mais Polêmicas e Psicologicamente Pesadas

Se você quer explorar o lado mais provocativo, sem cair no vulgar, mas sim no questionamento ético e humano, essas são opções interessantes:

a) School Days (2007)

• Tema: Relações tóxicas, amor distorcido, consequência emocional.

• Semelhança: Mostra o que acontece quando o desejo não é mediado pela ética.

b) Saishuu Heiki Kanojo (Saikano) (2002)

• Tema: Amor e destruição no limite da inocência.

• Semelhança: Personagens jovens enfrentando sentimentos e responsabilidades muito além de sua idade.

c) Kodomo no Omocha (1996)

• Tema: Traumas de infância, amadurecimento, responsabilidade emocional.

• Curiosidade: Apesar do tom de comédia, trata de abandono, violência doméstica e amadurecimento precoce — um espelho mais leve de Kodomo no Jikan.

---

💡 Se você busca a mesma “energia emocional” de Kodomo no Jikan:

→ Experimente começar nesta ordem:

1. Usagi Drop (para o lado ético e emocional)

2. Koi Kaze (para o dilema moral)

3. Aishiteruze Baby★★ (para o amadurecimento afetivo)

4. March Comes in Like a Lion (para a profundidade psicológica)

5. Kodomo no Omocha (para o contraste infância x trauma)

---

Os 5 Core Quality Tools na Stack IBM Mainframe

 

Bellacosa Mainframe e as 5 core quality tools

☕ Um Café no Bellacosa Mainframe

Os 5 Core Quality Tools na Stack IBM Mainframe

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como Construir Sistemas Bancários que Não Podem Falhar

"A qualidade não nasce durante o teste. Ela nasce muito antes da primeira linha de código ser compilada."

Quando um desenvolvedor COBOL inicia sua jornada no mundo do IBM Mainframe, normalmente acredita que qualidade significa apenas "o programa compilou sem erro" ou "o teste passou".

Essa visão funciona para pequenos projetos.

Mas desaparece completamente quando você entra em uma instituição financeira, seguradora, empresa aérea ou governo.

Ali, uma única linha de COBOL pode movimentar bilhões de reais diariamente.

Uma alteração aparentemente simples em um programa de cálculo de juros pode impactar milhões de clientes.

Uma mudança em um COPYBOOK pode afetar centenas de programas.

Um campo alterado em um registro VSAM pode quebrar integrações com CICS, DB2, MQ, IMS e dezenas de aplicações.

É por isso que grandes empresas não dependem apenas da habilidade do programador.

Elas dependem de processos.

Esses processos são conhecidos mundialmente como Core Quality Tools.

Embora tenham surgido na indústria automotiva através da AIAG (Automotive Industry Action Group) e hoje façam parte da IATF 16949, seus princípios são universais.

Na prática, eles representam exatamente aquilo que faz um ambiente IBM Z operar durante décadas com níveis de disponibilidade próximos de 99,9999%.

E talvez você nunca tenha percebido...

Grande parte da cultura de desenvolvimento Mainframe já segue esses princípios há décadas.

Vamos descobrir como.

---

O verdadeiro significado de qualidade

Existe uma diferença enorme entre:

"Meu programa funciona."

e

"Meu sistema continuará funcionando pelos próximos vinte anos."

Essa diferença chama-se engenharia de qualidade.

O Mainframe sempre foi pioneiro nisso.

Enquanto muitas plataformas modernas seguem o famoso:

"Deploy rápido e corrige depois."

O Mainframe tradicionalmente segue outra filosofia:

"Planeje tanto que quase não seja necessário corrigir."

Parece exagero?

Pense em um banco.

Imagine que durante o fechamento financeiro do mês:

• um JOB falha

• uma transação CICS trava

• um cálculo de imposto gera valores incorretos

• um débito é executado duas vezes

Agora multiplique isso por:

• dez milhões de clientes.

A qualidade deixa de ser uma característica técnica.

Ela passa a ser um requisito de sobrevivência.

---

A fábrica de software também é uma fábrica

Quando olhamos para uma montadora, vemos:

• matéria-prima

• máquinas

• operadores

• inspeções

• manutenção

• produção

Agora olhe para um ambiente Mainframe.

Temos praticamente a mesma estrutura.

Na indústria	No Mainframe
Matéria-prima	Requisitos
Projeto	Arquitetura
Linha de produção	Pipeline DevOps
Máquinas	LPARs IBM Z
Ferramentas	COBOL, JCL, DB2, CICS
Inspeção	Testes
Controle estatístico	Monitoramento SMF/RMF
Produto final	Aplicação em produção

Mudam os nomes.

A engenharia continua exatamente igual.

---

APQP

Planejamento Avançado da Qualidade

O primeiro erro de um desenvolvedor júnior é acreditar que programação começa no editor COBOL.

Não começa.

Começa muito antes.

Imagine que o banco deseja criar uma nova modalidade de PIX internacional.

Antes de alguém escrever:

MOVE VALOR TO WS-TOTAL.

centenas de decisões já foram tomadas.

Será utilizado DB2?

VSAM?

MQ?

CICS?

Batch?

Online?

REST?

z/OS Connect?

Quais campos serão adicionados?

Quem fará rollback?

Como será a auditoria?

Qual será o SLA?

Como será a recuperação após desastre?

Tudo isso faz parte do equivalente Mainframe do APQP.

---

O APQP na prática

Em grandes empresas essa etapa envolve:

• levantamento de requisitos

• arquitetura corporativa

• análise de impacto

• padrões COBOL

• convenções JCL

• segurança RACF

• definição de índices DB2

• planejamento de backup

• definição de monitoramento

• cronograma

Observe algo interessante.

Nenhuma linha de código foi escrita.

Mesmo assim já existe enorme trabalho.

É exatamente isso que reduz defeitos.

---

Um exemplo real

Imagine alterar um programa responsável pelo cálculo do FGTS.

Sem planejamento:

"É só incluir um campo."

Na prática:

Esse campo pode existir em:

• COPYBOOK

• DB2

• VSAM

• MQ

• CICS

• telas BMS

• APIs REST

• batch noturno

• relatórios

• ETL

• Data Warehouse

Uma alteração pode atingir centenas de programas.

O APQP identifica isso antes.

---

FMEA

Failure Mode and Effects Analysis

Se existe uma ferramenta que todo desenvolvedor deveria aprender, é esta.

O FMEA faz uma pergunta simples:

"O que pode dar errado?"

Mas a resposta nunca é simples.

---

Exemplo COBOL

Programa:

PAGTO001

Função:

Efetuar pagamento.

O programador pensa:

"O código está certo."

O FMEA pergunta:

E se o arquivo VSAM estiver cheio?

E se ocorrer DEADLOCK no DB2?

E se o MQ estiver indisponível?

E se o cliente enviar CPF inválido?

E se faltar espaço no SORTWK?

E se ocorrer S0C7?

E se houver rollback?

E se duas transações atualizarem o mesmo registro?

Percebe?

O FMEA obriga a pensar como um arquiteto.

---

Exemplo prático

Modo de falha

Registro duplicado.

Efeito

Cliente recebe pagamento em dobro.

Consequência

Prejuízo financeiro.

Severidade

10

Ocorrência

4

Detecção

3

Risco elevado.

Ação recomendada

Implementar chave única.

Controle transacional.

Logs.

Rollback.

Auditoria.

---

O FMEA e os ABENDs

Os ABENDs representam excelente fonte para alimentar um FMEA.

Por exemplo:

S0C7

Pode indicar:

dados inválidos.

S806

Programa inexistente.

SB37

Dataset sem espaço.

S322

Timeout.

Cada um desses eventos deveria gerar perguntas:

Como evitar?

Como detectar antes?

Como recuperar automaticamente?

---

MSA

Measurement System Analysis

Imagine um gerente perguntar:

"Nosso sistema está rápido?"

Resposta:

"Mais ou menos."

Isso não serve.

No Mainframe tudo precisa ser medido.

Mas...

Quem garante que a medição está correta?

Esse é exatamente o papel do MSA.

---

No mundo IBM Z

O equivalente do MSA inclui:

SMF

RMF

OMEGAMON

IBM Z IntelliMagic

IBM Instana

Grafana

Prometheus

Z APM Connect

Todos precisam fornecer dados confiáveis.

---

Imagine.

Uma ferramenta informa:

CPU 95%.

Outra:

CPU 52%.

Qual está correta?

Sem confiabilidade na medição não existe gerenciamento.

---

Gage R&R aplicado ao Mainframe

Na indústria mede-se paquímetro.

No Mainframe mede-se observabilidade.

Por exemplo:

Tempo CICS.

Tempo DB2.

Tempo MQ.

Tempo Batch.

Latência API.

Precisamos validar:

• consistência

• repetibilidade

• precisão

---

SPC

Statistical Process Control

Esta talvez seja a ferramenta mais próxima do universo dos operadores Mainframe.

Imagine acompanhar diariamente:

Quantidade de JOBs.

Tempo médio Batch.

CPU.

IOPS.

Locks DB2.

Tempo CICS.

Uso DASD.

Uso de memória.

Esses indicadores possuem comportamento normal.

Quando começam a fugir do padrão...

Algo está acontecendo.

---

Exemplo

Um JOB sempre executa em:

7 minutos.

Durante semanas.

Depois:

8

9

10

11

13

15 minutos.

Ainda termina.

Mas existe tendência.

SPC detecta.

O operador investiga.

Descobre:

Novo índice DB2.

Plano alterado.

RUNSTATS desatualizado.

Sem SPC isso só seria descoberto quando o batch atrasasse horas.

---

PPAP

Production Part Approval Process

Agora imagine o momento mais temido.

Deploy em produção.

O desenvolvedor diz:

"Funciona na homologação."

O gerente pergunta:

"Você tem evidências?"

Entra o equivalente Mainframe do PPAP.

---

Antes do Go Live

São revisados:

Código COBOL.

Resultados dos testes.

Testes unitários.

Testes integrados.

Performance.

Planos DB2.

EXPLAIN.

SCAN de segurança.

Revisão RACF.

Validação CICS.

JCL.

Rollback.

Documentação.

Plano de retorno.

Checklist CAB.

Aprovação do negócio.

Somente depois ocorre o deploy.

---

O PPAP moderno

Hoje muitas empresas automatizam esse processo.

Ferramentas:

Git

Jenkins

UrbanCode Deploy

Endevor

Changeman

ISPW

SonarQube

Zowe CLI

Ansible

Cada etapa produz evidências.

O pipeline torna-se um PPAP digital.

---

A relação entre os cinco

Observe como cada ferramenta depende da anterior.

Sem planejamento...

não existe análise de risco.

Sem análise de risco...

não sabemos o que medir.

Sem medição...

não sabemos controlar.

Sem controle...

não existe aprovação.

É uma cadeia.

---

Os Core Tools dentro do ciclo de vida do software

Imagine um projeto para modernizar um sistema COBOL de empréstimos.

Durante o planejamento (APQP), arquitetos definem requisitos, integração com APIs via z/OS Connect, impactos em DB2, VSAM e CICS, requisitos de segurança RACF e critérios de desempenho.

Na sequência, realiza-se o FMEA, identificando riscos como indisponibilidade de serviços externos, deadlocks em tabelas DB2, falhas de comunicação com IBM MQ, concorrência entre transações CICS, erros de conversão de dados e possíveis ABENDs. Para cada risco são propostas ações preventivas.

Com o projeto definido, entram em cena as práticas equivalentes ao MSA. Ferramentas como SMF, RMF, OMEGAMON, Instana e Grafana são configuradas para garantir que CPU, I/O, tempos de resposta e utilização de recursos sejam medidos de forma consistente e confiável.

Durante testes e homologação, aplica-se o conceito de SPC. A equipe monitora métricas como tempo médio de execução de jobs, consumo de CPU, quantidade de locks DB2, latência de transações CICS e volume de mensagens em filas MQ. O objetivo é identificar tendências antes que se transformem em incidentes.

Por fim, o PPAP se materializa no processo de aprovação para produção. Revisões de código, testes automatizados, análise estática, validação de planos DB2, documentação, plano de rollback, aprovação da CAB (Change Advisory Board) e conformidade com normas corporativas garantem que o software esteja apto para operar em produção com segurança.

---

A Qualidade como Cultura

O maior ensinamento dos Core Tools não é preencher formulários.

É desenvolver uma forma de pensar.

Um bom programador pergunta:

"Como faço isso funcionar?"

Um excelente engenheiro pergunta:

• Como isso pode falhar?

• Como detectarei a falha?

• Como evitarei que ela ocorra novamente?

• Como monitorarei esse comportamento ao longo do tempo?

• Como demonstrarei, com evidências, que o sistema é confiável?

Essa mudança de mentalidade transforma desenvolvedores em arquitetos de soluções resilientes.

---

O que Todo COBOL Padawan Deve Levar para a Carreira

Se existe uma lição que atravessa décadas de evolução tecnológica, do COBOL ao DevOps, do batch ao cloud híbrido, é que qualidade nunca é um evento; é um processo contínuo.

Os 5 Core Quality Tools mostram que sistemas robustos não são fruto de sorte ou de programadores "geniais". Eles são resultado de planejamento disciplinado, análise de riscos, medições confiáveis, monitoramento estatístico e processos rigorosos de aprovação.

No universo IBM Mainframe, essa filosofia sempre esteve presente. É por isso que aplicações escritas há 30 ou 40 anos continuam processando milhões de transações diariamente com níveis extraordinários de disponibilidade e confiabilidade.

Ao estudar APQP, FMEA, MSA, SPC e PPAP, o COBOL Padawan percebe que essas ferramentas não pertencem apenas à indústria automotiva. Elas representam uma forma universal de construir sistemas críticos: pensar antes de programar, prevenir antes de corrigir, medir antes de decidir, controlar antes que o problema aconteça e liberar para produção apenas quando houver evidências objetivas de que o software está pronto.

No fim das contas, o maior legado da Stack IBM Mainframe talvez não seja apenas sua tecnologia, mas sua cultura de engenharia. Uma cultura em que cada linha de código, cada JCL, cada tabela DB2, cada transação CICS e cada job batch fazem parte de um ecossistema projetado para entregar confiança. E confiança, em sistemas que movimentam bilhões de reais todos os dias, é a mais valiosa das qualidades. Afinal, como costumo dizer aos novos Padawans do Mainframe:

"No IBM Z, qualidade não é um departamento. É uma característica da arquitetura, do processo e da mentalidade de quem escreve cada linha de código." ☕