quinta-feira, 16 de janeiro de 2014

SMP/E na prática – SYSMOD Packaging sem medo

 

Bellacosa Mainframe apresenta smp/e sysmod packaging

SMP/E na prática – SYSMOD Packaging sem medo



🧠 Introdução – SMP/E não é bicho‑papão

Quem trabalha com z/OS cedo ou tarde se depara com ele: SMP/E. Para alguns, um monstro antigo. Para outros, um mal necessário. A verdade é simples:

SMP/E é só método, disciplina e leitura correta das MCS.

Neste post vamos direto ao ponto: SYSMOD Packaging, ou seja, como os produtos, correções e USERMODs são empacotados, entregues e entendidos pelo SMP/E.

Sem marketing. Sem misticismo. Só mainframe raiz.


📦 O que é um SYSMOD de verdade?

Todo SYSMOD é composto por duas partes inseparáveis:

  1. Conteúdo

    • módulos

    • macros

    • source

    • dados

    • HFS / JAR

  2. MCS – Modification Control Statements

    • instruções que dizem ao SMP/E como, onde e quando instalar

👉 Durante o RECEIVE, o SMP/E lê primeiro as MCS, cria as MCS entries e armazena tudo no SMPPTS.

Se as MCS estiverem erradas… não há santo que salve o APPLY.


🧾 Regras de ouro das MCS (decore isso)

  • Todas começam com ++

  • Colunas 1–2 obrigatórias

  • Terminam com ponto final (.)

  • Continuação de linha só se não houver ponto antes da coluna 73

  • Colunas 73–80 são ignoradas

📌 Erro clássico: esquecer o ponto final. Resultado? SMP/E surtando.


🪪 HEADER – identidade do SYSMOD

Toda SYSMOD começa com:

++HEADER

É aqui que o SMP/E descobre:

  • o tipo do SYSMOD

  • o SYSMOD‑ID

Tipos clássicos

  • FUNCTION – produto base

  • PTF – correção testada

  • APAR – correção de problema

  • USERMOD – correção local

Sem HEADER correto, não existe SYSMOD.


🧬 FMID – quem é o dono do código

O FMID (Function Modification ID):

  • tem 7 caracteres

  • identifica qual função é dona do elemento

  • aparece normalmente no ++VER

📌 Em FUNCTION SYSMOD, o FMID é o próprio SYSMOD‑ID.

Erro comum em prova e produção: FMID errado = APPLY recusado.


🔗 ++VER – o cérebro do SMP/E

O ++VER é obrigatório e define:

  • releases suportados

  • pré‑requisitos

  • co‑requisitos

  • supersedes

Principais operandos:

  • SREL – release do sistema

  • FMID – função dona

  • PRE – pré‑requisito

  • REQ – co‑requisito

  • SUP – supersede

👉 Sem ++VER, o SMP/E não confia em você.


🚦 ++HOLD – bloqueios controlados

Existem três HOLDs clássicos:

  • ERROR – correção com problema

  • SYSTEM – ação manual necessária

  • USER – regra local

O HOLD pode vir:

  • dentro do SYSMOD

  • ou separado em HOLDDATA

📌 HOLD não é erro. HOLD é controle.


🏗️ ++JCLIN – a planta da casa

O ++JCLIN descreve:

  • como o load module deve ser montado

  • quais objetos entram

  • qual link‑edit será usado

⚠️ JCLIN não executa JCL.

Ele apenas documenta a estrutura, permitindo RESTORE e rebuild corretos.

Sem JCLIN, o SMP/E fica cego.


🧩 MCS de elementos – o que realmente instala

Alguns exemplos:

  • ++MOD – módulo

  • ++SRC – source

  • ++MAC – macro

  • ++DATA – dados

  • ++HFS – arquivo Unix

  • ++JAR – JAR inteiro

  • ++JARUPD – update parcial

  • ++ZAP – patch binário

📌 ZAP e UPD alteram partes. DATA e HFS sempre substituem tudo.


☕ JAR no SMP/E (onde muita gente erra)

  • ++JAR → substituição total

  • ++JARUPD → update parcial

O SMP/E usa comandos do JDK para manipular o conteúdo.

Sim, Java também é mainframe.


📦 Técnicas de empacotamento SYSMOD

1️⃣ Relative File (tape)

  • clássico IBM

  • MCS em um arquivo

  • elementos em arquivos seguintes

  • usa RELFILE

Muito comum em FUNCTION SYSMOD.


2️⃣ Inline

  • MCS e conteúdo juntos

  • registros fixos de 80 bytes

  • simples e direto

⚠️ Dados variáveis exigem GIMDTS.


3️⃣ Indirect Library

  • MCS no SMPPTS

  • conteúdo fora (PDS indicado no APPLY)

  • comum em USERMOD

Flexível e perigoso se mal documentado.


4️⃣ GIMZIP Archive (Shopz / Internet)

  • entrega moderna

  • tudo compactado

  • inclui MCS, conteúdo e HOLDDATA

Base do RECEIVE FROMNETWORK.


❌ Pegadinhas clássicas (anota aí)

  • ++MOD não é o último MCS

  • Inline com RELFILE

  • FMID inexistente

  • SREL inválido

  • falta de ponto final

👉 Todas já derrubaram produção algum dia.


🧠 Conclusão – SMP/E é método

RECEIVE entende
APPLY constrói
ACCEPT congela

Quando você entende SYSMOD Packaging, o SMP/E deixa de ser mistério e vira aliado.

Mainframe não é velho.
Velho é não saber o que está rodando.


💾 Até o próximo post. Porque mainframe bom é mainframe bem documentado.

quinta-feira, 9 de janeiro de 2014

🔞 Um anime bem fetichista : Kill la Kill (キルラキル)

 


Kill la Kill (キルラキル)

Autor: Kazuki Nakashima (roteiro)
Direção: Hiroyuki Imaishi
Estúdio: Trigger
Ano de lançamento: 2013


Sinopse

Em um colégio onde o uniforme concede poderes sobre-humanos, Ryuko Matoi chega armada com uma tesoura-gigante para descobrir quem assassinou seu pai.
A trama é uma montanha-russa visual e simbólica, misturando ação, sátira, erotismo e crítica social.
Cada uniforme, chamado Goku Uniform, dá força ao usuário, mas exige que ele se exponha — literalmente.

Por trás da estética provocante, há uma metáfora sobre controle, liberdade e vergonha.
Kill la Kill brinca com a ideia do corpo como arma, da roupa como identidade, e do fetiche como símbolo de poder e vulnerabilidade.


Dicas e curiosidades

  • O diretor Hiroyuki Imaishi é o mesmo de Gurren Lagann — outro anime que exagera tudo de propósito.

  • A exposição do corpo não é gratuita: simboliza a libertação das amarras sociais e a aceitação de si mesmo.

  • O anime faz críticas sutis ao consumismo, à padronização e ao uso da sexualização como ferramenta de controle.

  • A trilha sonora é vibrante, cheia de gritos de guerra e hinos épicos — impossível assistir sentado.


Principais personagens

  • Ryuko Matoi: protagonista impulsiva e corajosa, em busca de vingança e autodescoberta.

  • Satsuki Kiryuuin: líder fria e autoritária, representa o poder e o controle, mas também esconde vulnerabilidade.

  • Senktesu: o uniforme falante de Ryuko — uma metáfora viva sobre confiança e simbiose entre corpo e alma.


Comentário para padawans 🥋

“Kill la Kill” é uma aula disfarçada de insanidade.
Se você olhar só o visual, vai achar que é puro fanservice;
mas se assistir com atenção, vai perceber que é um ensaio sobre o fetiche, o poder e a autoaceitação.
É o tipo de anime que desafia o espectador a enxergar além do óbvio —
a entender que o fetichismo pode ser uma linguagem estética, uma provocação social e uma forma de autoconhecimento.


segunda-feira, 6 de janeiro de 2014

Curiosidades sobre o Japão que Todo Otaku Dev Mainframe Deveria Saber

 


🇯🇵 Curiosidades sobre o Japão que Todo Otaku Dev Mainframe Deveria Saber

Se você acha que anime é só cabelo colorido, olhos gigantes e batalhas infinitas… sinto informar: o Japão esconde mais camadas que um JCL bem escrito. Vamos abrir o dump cultural.


🧠 1. O Japão pensa em “sistemas”, não em “personagens”

No Japão, histórias raramente giram só em torno do herói.
O foco está no sistema: vilas, clãs, corporações, regras, contratos e hierarquias.

👉 Naruto não é sobre Naruto.
👉 Ghost in the Shell não é sobre a Major.
👉 Attack on Titan não é sobre Eren.

É tudo sobre como o sistema funciona — e como ele quebra.

📌 Mainframe vibes: primeiro vem a arquitetura, depois a aplicação.



🏯 2. Castelos japoneses explicam 80% dos animes

Os castelos não eram só fortalezas.
Eram data centers feudais: controle de acesso, hierarquia rígida, caminhos confusos para invasores.

Por isso tantos animes têm:

  • corredores infinitos

  • escadas simbólicas

  • salas proibidas

  • “você não tem permissão para estar aqui”

📌 Easter egg: subir uma torre = ascender no sistema. Igual migrar de operador para sysprog.


⏱️ 3. O Japão respeita o tempo como se fosse batch window

No Japão:

  • trem atrasado dá pedido público de desculpas

  • pontualidade é honra

  • repetir o processo até a perfeição é virtude

Isso explica:

  • episódios lentos

  • cenas longas de silêncio

  • treinamentos infinitos

  • arcos de preparação maiores que a batalha

📌 Bellacosa insight: não é filler, é processamento em background.


🧩 4. Anime ama legado, não inovação vazia

Enquanto o Ocidente idolatra o “novo”, o Japão pergunta:

“Isso honra o que veio antes?”

Por isso:

  • reboots são raros

  • remakes são respeitosos

  • mestres velhos sempre sabem algo

  • o passado nunca está morto

📌 Mainframe rule: sistema antigo não é obsoleto — é estável.


👘 5. Uniformes não são estética. São contrato social.

Em animes, todo mundo usa uniforme:

  • escola

  • empresa

  • clã

  • exército

  • café temático

Não é moda.
É papel social visível.

📌 Analogicamente: seu crachá define seu acesso. Seu kimono define sua função.


🌸 6. Flores dizem mais que diálogos

O Japão usa linguagem floral (Hanakotoba).
Animes usam isso o tempo todo:

  • 🌸 Cerejeira: impermanência

  • 🌺 Lírio: pureza ou morte

  • 🌻 Girassol: devoção silenciosa

  • 🌹 Rosa branca: amor impossível

📌 Easter egg: se uma flor aparece numa cena, preste atenção. É um comentário oculto do sistema.


⚙️ 7. Tecnologia japonesa é invisível (como mainframe)

No Japão, a melhor tecnologia:

  • não faz barulho

  • não chama atenção

  • simplesmente funciona

Por isso:

  • animes não explicam tudo

  • interfaces são minimalistas

  • máquinas parecem “vivas”, mas discretas

📌 Bellacosa truth: o melhor sistema é aquele que você esquece que existe.


🐺 8. Personagens solitários = operadores noturnos

O arquétipo do personagem calado, observador, solitário:

  • samurai errante

  • hacker silencioso

  • sensei que surge do nada

Eles não falam muito porque já viram falhas demais.

📌 Midnight Lunch mode: quem segura o sistema não faz discurso — faz backup.


🍱 9. Comer junto é mais importante que lutar

Repare:

  • depois da batalha, vem a refeição

  • times se formam à mesa

  • conflitos se resolvem com comida

No Japão, partilhar alimento cria laço.

📌 El Jefe insight: anime entende que confiança nasce no almoço, não no combate.


🧠 10. Anime não explica tudo de propósito

O Japão respeita o silêncio e a interpretação.
Se algo não foi dito, é porque:

  • você deveria sentir

  • não entender ainda

  • ou aceitar o mistério

📌 Mainframe final rule: nem todo log é para o usuário final.


☕ Conclusão: Anime é Cultura de Sistema

Se você curte anime e trabalha (ou admira) sistemas complexos, saiba:

  • o Japão pensa como arquiteto

  • escreve como sysprog

  • e conta histórias como quem mantém legado

Anime não é fuga da realidade.
É documentação poética de como o mundo funciona.

🍜 Nos vemos no próximo Midnight Lunch.

domingo, 5 de janeiro de 2014

Katsushika Hokusai: o sysprog do traço que rebootou a arte japonesa (e pariu o mangá)

 


Katsushika Hokusai: o sysprog do traço que rebootou a arte japonesa (e pariu o mangá)

Introdução – quando o batch da arte roda por 90 anos

No mainframe, a gente aprende cedo que sistemas legados bem feitos atravessam décadas. Na arte, acontece a mesma coisa.
E se existe um “MVS 3.8j” da cultura japonesa, esse sistema atende pelo nome de Katsushika Hokusai.

Hokusai não foi apenas um artista.
Ele foi um arquitetural designer cultural, um early adopter de estilos, um debugger obsessivo do próprio traço — e, sem exagero nenhum, um dos pais do mangá moderno.

Sim, mangá. Mas calma… já chegamos lá 😉



Biografia – IPL artístico iniciado em Edo (Tóquio antiga)

  • Nome: Katsushika Hokusai

  • Nascimento: 1760, Edo (atual Tóquio)

  • Morte: 1849, aos 88 anos (idade absurda pra época)

Hokusai viveu durante o Período Edo, quando o Japão era praticamente um sistema air-gapped: fechado ao mundo, sem internet, sem importações culturais externas. Mesmo assim, ele conseguiu influenciar o planeta inteiro.

Curiosidade de sysprog:
👉 Hokusai mudou de nome artístico mais de 30 vezes ao longo da vida.

No nosso mundo isso seria:

“Esse programador aqui já foi operador, analista, arquiteto, consultor, evangelista e agora atende como freelancer sênior”.

Cada nome novo representava uma nova versão do sistema, com melhorias, refatorações e até mudanças de paradigma visual.


Ukiyo-e – o VSAM da arte popular japonesa

Hokusai trabalhava com ukiyo-e, xilogravuras feitas em madeira.
Era a arte popular, barata, reproduzível — tipo print spool da cultura japonesa.

Nada de pintura única para elite:

  • Produção em massa

  • Distribuição ampla

  • Consumo cotidiano

📌 Tradução Bellacosa:

Hokusai democratizou a arte do mesmo jeito que o mainframe democratizou o processamento em larga escala.


A Grande Onda – o print que rodou o mundo

Se você já viu uma onda gigante quase engolindo barcos, parabéns: você já “executou” Hokusai sem perceber.

🌊 A Grande Onda de Kanagawa

  • Criada por volta de 1831

  • Parte da série “Trinta e Seis Vistas do Monte Fuji”

  • Influenciou artistas como Van Gogh, Monet e Debussy

Easter egg clássico:
👉 O Monte Fuji está lá… pequeno, estável, imutável.

No meio do caos, ele representa:

  • Permanência

  • Ordem

  • Estabilidade

Ou seja:

Enquanto a onda é o incidente em produção, o Fuji é o mainframe — sempre lá.


Hokusai Manga – quando nasce o “manual técnico” do mangá

Agora o ponto que interessa aos curiosos de plantão 👀

📘 Hokusai Manga

Não era mangá como conhecemos hoje (história sequencial com balões), mas sim:

  • Cadernos de esboços rápidos

  • Pessoas, monstros, cenas do cotidiano

  • Humor, exagero, movimento

“Manga” significava algo como:

desenhos espontâneos / rabiscos livres

📌 Bellacosa explica:

Hokusai criou um “dump visual” do Japão da época.

Esses cadernos:

  • Serviam para estudo

  • Inspiração

  • Ensino

  • Replicação de estilo

Sem querer, ele lançou a base conceitual do mangá moderno.


Curiosidades – o artista que nunca fechava o chamado

  • Hokusai dizia que só começou a desenhar bem depois dos 70 anos

  • Aos 88, pouco antes de morrer, afirmou:

    “Se eu tivesse mais 10 anos, seria um verdadeiro artista”

Isso é praticamente:

“Ainda não fechei esse incidente, mas o fix tá quase pronto”

Ele também:

  • Viveu pobre grande parte da vida

  • Mudava de casa constantemente (quase um nomad computing)

  • Era obcecado por melhorar o traço até o último dia


Inspiração – legado é mais forte que hype

Hokusai nos ensina algo poderoso:

  • Não importa a ferramenta

  • Não importa o contexto

  • Consistência vence moda

Ele não viu o impacto global da sua obra.
Mas hoje:

  • Está em museus do mundo inteiro

  • Influencia quadrinhos, animações, games e cultura pop

  • Está embutido no DNA do mangá e do anime


Dicas Bellacosa (vale pra arte, código e vida)

💡 1. Refatore sempre
Hokusai nunca considerava o trabalho “pronto”.

💡 2. Documente seu processo
Os cadernos Hokusai Manga são ouro puro até hoje.

💡 3. Popular não é sinônimo de raso
Ukiyo-e era “arte barata” — e virou patrimônio mundial.

💡 4. Longa vida ao legado
Faça coisas que sobrevivam à próxima versão.


Fofoquice histórica (porque ninguém é de ferro 😄)

Dizem que Hokusai:

  • Esquecia de pagar aluguel

  • Vivia atolado em dívidas

  • Era caótico no dia a dia

Mas quando sentava pra desenhar…

rodava em modo production sem falha.

Genial, difícil, humano — como todo grande arquiteto de sistemas.


Fechamento – do ukiyo-e ao mangá, do papel ao mundo

Se hoje você lê mangá, assiste anime ou consome cultura japonesa, saiba:
👉 Hokusai está no background, rodando como um serviço essencial.

No El Jefe Midnight Lunch, a gente celebra isso:

  • Cultura

  • Profundidade

  • Curiosidade

  • E aquele prazer nerd de conectar pontos improváveis

Porque no fim…

arte, código e histórias são só diferentes formas de registrar o mundo.

☕🌊📚


sábado, 4 de janeiro de 2014

Grandes Aventuras — Versão Oni Bellacosa


 

Grandes Aventuras — Versão Oni Bellacosa

Sabe, El Jefe, quando a gente fala em grandes aventuras, o imaginário já puxa espada, dragão, nave espacial e um guerreiro cabeludo gritando numa montanha com raios ao fundo. Mas pra mim… ah, pra mim as maiores aventuras nunca foram essas de cinema. As minhas tinham cheiros, sabores, ruas de terra, vozes de vizinhos, galos cantando e ônibus fretado que as vezes quebrava no meio da estrada. Estar sempre correndo e sempre atrasado ao estilo coelho da Alice.

Minhas aventuras começaram cedo, lá no modo Oni Infantil 1.0, aquele build que vinha com joelhos ralados, coragem infinita e 0MB de noção de perigo. E eu era um pequeno oni, que estendia a corda ao limite, até imagino a dimensão da fatura, quando encontrar cara a cara com meu anjo-da-guarda e eles discriminar às vezes, que me salvou.



A primeira grande aventura foi explorar o quintal como se fosse a Amazônia inteira. Cada formigueiro era um templo perdido, cada galinha-brava uma criatura mítica pronta pra testar a minha bravura (e quase sempre eu perdia). A roupa suja, coitada, voltava pra minha mãe sem nenhuma esperança de ser recuperada. Mas ah, o orgulho de ter subido no pé de goiaba sem cair — isso, sim, era XP ganho. Teve o pulo no tanque de óleo queimado da oficina de tratores do primo Du, as bagunças na máquina de lavar roupa da vó Anna, as travessuras nos quartinhos de ferramenta desmontando e nunca conseguindo remontar cacarecos. As idas aos ferro-velhos e desmanche com meu pai. Às vezes ir no ônibus em que ele era motorista. Acompanhar suas reportagens fotográficas em casamentos, batizados, formaturas ou festas.



Depois veio a era das aventuras urbanas, quando fomos pra São Paulo. Ali o boss final chamava-se Metro, Trem e Ônibus Lotado das 6h. Só de entrar já valia um troféu. E tinha as microaventuras do cotidiano: atravessar uma rua movimentada com a ousadia de quem está em um RPG no modo “Hardcore”, comprar pão sozinho na padaria — e voltar com troco certo (ou apanhar da minha mãe por ter comprado bala com o troco, o que também fazia parte do processo educativo).



A primeira viagem sozinho a Campinas e depois a Praia Grande também foram marcos da expansão do meu pequeno mundo para dimensões estaduais, graças a autorização do juizado de menores em viajar sozinho.

Mas a maior aventura mesmo, aquela que moldou o Oni que vos escreve, começou quando comecei a trabalhar. Era o clássico enredo Bellacosa:
pouca grana, muita coragem, e um mundo gigante esperando pra ser descoberto.

A aventura era acordar 5:20, regime espartano, banhar-me, beber café, correr para pegar o trem lotado às 6:15, trabalhar o dia todo, estudar à noite, voltar pra casa destruído e ainda assim abrir um sorriso quando sentia o cheiro do bolo da Dona Mercedes assando no forno — sinal claro de que a vida, apesar de dura, tinha seus patches de atualização de felicidade.

E olha só que curioso: quando finalmente pude ajudar em casa e trazer dinheiro pra mesa, percebi que a aventura não estava em viajar longe ou enfrentar monstros imaginários. Estava ali, bem ali:
na sensação de fazer a vida melhorar um pixel por dia.

As grandes aventuras não foram viagens épicas, mas sim momentos — pequenos, imperfeitos, reais — que hoje carrego com carinho:
⭐ o primeiro salário
⭐ o primeiro almoço pago com meu esforço
⭐ o primeiro livro técnico que comprei sem parcelar
⭐ o primeiro “muito bem, filho” dito pela minha mãe
⭐ o primeiro sonho que começou a virar realidade

Crescer, sobreviver, evoluir… isso sim é uma aventura digna de mainframe:
robusta, resiliente, cheia de sistemas legados, mas que ainda entrega magia quando ninguém espera.

Hoje olho pra trás e percebo:
o mundo nunca me deu grandes aventuras; fui eu que transformei as pequenas em gigantes.

Isso que eu ainda não contei completamente da Vagneida.

Foram quase 15 anos, em que fui Odisseu, em minhas viagens pelo velho continente, uma vida Isekai, que enche de nostalgia e deixa algumas lagriminhas no canto do olho.

Tantos lugares, tantas pessoas, tantos sabores, culturas e idiomas diferentes, novo com velho, me senti em casa, me senti fazer parte de algo realmente grande e apesar das dimensões continentais do Brasil, realmente entendi o que era diferença, o que era pisar na terra dos meus ancestrais. Mas isso é uma longa história, que ainda tenho que desenrolar o fio desse novelo.

E sigo assim, El Jefe, Oni de coração, Bellacosa de essência, encarando cada dia como se fosse mais uma missão em um mapa aberto chamado Vida.

E que aventura maravilhosa tem sido.


sexta-feira, 3 de janeiro de 2014

☕ Jean Sammet: a mulher que colocou ordem no caos das linguagens

 



💾 EL JEFE MIDNIGHT LUNCH — Bellacosa Mainframe Chronicles
“☕ Jean Sammet: a mulher que colocou ordem no caos das linguagens”


Há gente que programa.
Há gente que projeta linguagens.
E há gente raríssima que para, olha tudo isso de cima e diz: “isso precisa fazer sentido”.

Jean E. Sammet não ficou famosa por uma linguagem só.
Ela ficou eterna porque organizou o pensamento sobre linguagens de programação — e ajudou a transformar o COBOL de uma ideia ousada em algo formal, sustentável e historicamente consciente.

Se o mainframe é estável, se o COBOL é legível, se linguagens têm história, muito disso passa por Jean Sammet.

Café servido. ☕
Vamos à história.



👩‍💻 Quem foi Jean Sammet (biografia essencial)

  • Nome completo: Jean E. Sammet

  • Nascimento: 23 de março de 1928

  • Falecimento: 20 de maio de 2017

  • Formação: Matemática

  • Empresas-chave: Sylvania Electric, IBM

  • Áreas de atuação: Linguagens de programação, compiladores, padronização, história da computação

Jean Sammet era matemática de formação, mas historiadora por vocação e engenheira por necessidade.
Ela entrou na computação quando tudo ainda estava sendo inventado — inclusive as regras.


🕰️ O mundo que ela encontrou

Anos 50 e 60.
Cada máquina tinha:

  • Uma linguagem

  • Um dialeto

  • Um conjunto de regras implícitas

Documentação? Pouca.
Padrões? Quase nenhum.
História? Ninguém achava importante registrar.

🧠 Comentário Bellacosa:
Jean Sammet olhou esse caos e pensou:

“Se não organizarmos isso agora, ninguém vai entender nada depois.”

Ela estava certa.


💻 Jean Sammet e o COBOL

Jean Sammet participou ativamente do Short-Range Committee (1959), o comitê que definiu o COBOL.

🔹 Seu papel no COBOL

  • Defendeu clareza sintática

  • Ajudou a estruturar regras formais da linguagem

  • Garantiu que o COBOL fosse mais do que inglês solto disfarçado

🧠 Fofoquice técnica:
Enquanto alguns queriam algo “mais acadêmico”, Jean brigava para manter consistência e previsibilidade.
Sem isso, COBOL viraria um Frankenstein.


🖥️ Contribuição direta ao Mainframe

Jean Sammet entendia que o mainframe não era brinquedo de laboratório.
Era máquina de negócio.

Ela ajudou a moldar princípios que até hoje sustentam o ecossistema mainframe:

  • Linguagens precisam ser estáveis

  • Mudanças devem ser evolutivas, não destrutivas

  • Código precisa durar mais que hardware

🧠 Comentário Bellacosa Mainframe:
A filosofia do z/OS — compatibilidade para trás quase obsessiva — conversa diretamente com a mentalidade de Jean Sammet.


📚 O livro que mudou tudo



📖 Programming Languages: History and Fundamentals (1969)

Esse livro não é apenas referência.
É a certidão de nascimento da história das linguagens de programação.

🔹 O que ela fez:

  • Catalogou linguagens

  • Explicou conceitos

  • Criou taxonomias

  • Registrou decisões técnicas

🥚 Easter egg:
Até hoje, pesquisadores citam esse livro como fonte primária para linguagens que nem existem mais.


🧬 Principais trabalhos e feitos

  • Participante do comitê original do COBOL

  • Autora do primeiro grande livro de história das linguagens

  • Pesquisadora e líder técnica na IBM

  • Presidente da ACM (1974–1976)

  • Defensora da preservação histórica da computação

🧠 Curiosidade:
Ela foi uma das poucas pessoas da época que documentava enquanto o trem ainda estava andando.


🧩 Fofoquices e bastidores (porque ninguém é de ferro 😄)

  • Jean Sammet tinha fama de exigente e direta

  • Não tolerava “achismo técnico”

  • Corrigia colegas em público se achasse necessário

  • Era respeitada — e temida — em reuniões

🧠 Tradução Bellacosa:
Ela não queria ganhar debates.
Queria que o futuro entendesse o passado.


👶 Para Padawans do Mainframe

Se você está começando agora, Jean Sammet deixa lições valiosas:

  • Documente decisões

  • Pense em longo prazo

  • Linguagens são ferramentas sociais, não só técnicas

  • Compatibilidade não é fraqueza — é maturidade

COBOL não sobreviveu por acaso.
Sobreviveu porque pessoas como Jean pensaram além da próxima versão.


🏛️ O legado de Jean Sammet

Jean Sammet deixou algo raro:

  • Uma linguagem melhor estruturada

  • Uma indústria mais consciente

  • Uma memória histórica preservada

Sem ela:

  • COBOL seria menos consistente

  • O mainframe seria menos previsível

  • A história da computação seria cheia de buracos


☕ Reflexão final do El Jefe

“Código pode ser reescrito.
História perdida, não.”
— espírito de Jean Sammet

Se hoje sabemos de onde viemos,
se conseguimos entender por que certas decisões foram tomadas,
é porque alguém teve o cuidado de escrever isso enquanto todo mundo só queria entregar software.

Jean Sammet não apenas participou da história.
Ela garantiu que a história sobrevivesse.


domingo, 29 de dezembro de 2013

Brasil 2013: quando o sistema entrou em modo batch e ninguém sabia onde estava o console

 


Brasil 2013: quando o sistema entrou em modo batch e ninguém sabia onde estava o console

ao estilo bellacosa mainframe, para o El Jefe Midnight Lunch

Voltei ao Brasil em 2013 depois de doze anos vivendo na Europa. Doze anos é tempo suficiente para um sistema operacional mudar de versão, uma arquitetura inteira ser aposentada e o manual virar item de museu. Eu saí de um Brasil analógico, cheio de gambiarras assumidas, e voltei para um país aparentemente mais moderno, mais conectado, mais confiante. Parecia online. Mas bastou alguns meses para perceber: o sistema estava rodando, sim — só ninguém sabia exatamente qual job tinha sido submetido.

2013 foi o ano em que o Brasil deu um abend coletivo.

Na Europa, eu tinha me acostumado a outro ritmo. Transporte público previsível, impostos altos mas compreensíveis, protestos organizados como change management: data marcada, pauta clara, negociação depois. Ao pisar novamente em solo brasileiro, encontrei um país economicamente otimista, ainda surfando a onda do consumo, do crédito fácil e do discurso de “nova classe média”. O Brasil parecia um mainframe recém-upgradado, com LEDs piscando e discursos dizendo que agora tudo era 64 bits.

Mas quem já trabalhou com sistemas grandes sabe: nem todo problema aparece no dashboard.

Economia: números bons, latência alta

Em 2013, os números macroeconômicos ainda sustentavam uma narrativa positiva. Emprego relativamente alto, consumo aquecido, eventos internacionais no horizonte. Por fora, o hardware parecia robusto. Por dentro, porém, a latência social aumentava. Serviços públicos ruins, inflação corroendo silenciosamente o poder de compra, transporte caro e ineficiente. Era como rodar um sistema crítico com CPU sobrando, mas I/O travando tudo.

O estopim foi simbólico: vinte centavos. Quem viveu fora entende rápido — não era sobre a tarifa. Era sobre a sensação de pagar caro por um serviço que não entrega. Na Europa, eu pagava impostos altos, mas via retorno. No Brasil, pagava-se cada vez mais — em dinheiro, tempo e paciência — e recebia-se timeout.

Sociedade: quando o usuário final resolve apertar ENTER

O que me chocou, como ex-imigrante, foi a diversidade das ruas. Em poucos dias, vi algo que o Brasil raramente tinha feito daquela forma: gente diferente, por motivos diferentes, ocupando o mesmo espaço. Não havia um manual de operações. Era bonito e caótico. Classe média, periferia, estudantes, trabalhadores, gente que nunca tinha protestado na vida.

Do ponto de vista humano, 2013 foi um grito de “chega de rodar esse sistema sem saber quem programou”. Mas, como em todo ambiente sem governança clara, surgiram processos órfãos. Pautas se misturaram, oportunistas entraram, ruído substituiu sinal. Quem já viu um job crítico rodando sem controle sabe: uma hora alguém derruba a fila inteira.

Cultura: o espelho rachado

Culturalmente, 2013 escancarou algo que eu só percebi ao voltar: o brasileiro tinha mudado. Mais conectado, mais informado, mas também mais impaciente. A internet — especialmente as redes sociais — funcionou como um terminal 3270 emocional: todo mundo digitando rápido, pouca validação, muita reação.

Na Europa, eu tinha aprendido a desconfiar de soluções simples para problemas complexos. No Brasil de 2013, vi crescer exatamente o oposto: a busca por atalhos, por culpados únicos, por DELETE ALL como se fosse possível resetar décadas de desigualdade com um comando mágico.

A cultura do diálogo entrou em maintenance mode. O país começou a falar mais alto e a escutar menos.

População: o operador cansado

O sentimento dominante não era ideologia — era cansaço. Cansaço de acordar cedo, pegar transporte ruim, trabalhar muito e ainda ser tratado como variável descartável. Como operador veterano de mainframe, reconheci o sintoma: quando ninguém mais confia no sistema, qualquer alarme vira pânico.

2013 não resolveu nada. E talvez esse seja o ponto mais honesto. Foi um dump de memória emocional. Um registro bruto do que estava errado, sem análise posterior adequada. O Brasil seguiu rodando, mas com logs ignorados — e o preço disso veio depois.

Epílogo de quem voltou

Voltar ao Brasil em 2013 foi como reassumir um sistema legado que você ajudou a construir, mas que mudou enquanto você estava fora. Você reconhece os comandos, mas não entende mais as rotinas. Ainda assim, sabe que desligar tudo não é opção.

2013 foi o aviso na tela preta:
“System running, but integrity compromised.”

Quem viveu aquilo com atenção sabe: não foi o começo do caos. Foi o momento em que o operador percebeu que algo estava errado — e hesitou entre corrigir o código ou fingir que era só mais um warning.

E todo mainframe ensina a mesma lição: warnings ignorados viram falhas críticas.