🜂 El Jefe Midnight Lunch apresenta
Por Bellacosa Mainframe
Existem duas forças supremas no universo:
O Grande Rei Demônio (Dai Maou), soberano das trevas nas histórias japonesas.
O Programador Mainframe que acorda a empresa inteira quando decide “só ajustar rapidinho esse JCL” às 3h da manhã.
Ambos operam no silêncio absoluto, ambos manipulam poderes que mortais não compreendem, e ambos têm aquela aura de respeito misturado com medo reverente.
E, como todo bom filósofo da madrugada com café frio na mão e ISPF aceso, afirmo:
o programador noturno É o Dai Maou corporativo.
O Dai Maou não nasce vilão.
Ele é escolhido, invocado, empurrado por circunstâncias, destino ou… ticket crítico aberto no ServiceNow.
Assim também é o programador mainframe:
ninguém dorme tranquilo;
o telefone vibra com aquele “P1 - Sistema de Pagamentos Parado”;
a iluminação do quarto vira o prelúdio do modo batalha;
a alma desperta direto no nível épico.
É nesse instante que o programador assume seu destino:
“Se eu não for agora, ninguém vai.”
Isso, meu amigo, é a verdadeira coroação do Dai Maou da Madrugada.
Todo Dai Maou domina magia proibida.
Todo programador das 3h domina:
reprocessamento de job com override obscuro,
permutação de DDs sem documentação,
JES2 como quem recita mantras,
debugging mental na penumbra,
e aquele talento secreto de descobrir onde está o maldito space abend sem print.
É magia?
É experiência?
É trauma?
É tudo junto.
O poder supremo do Dai Maou é manipular energia demoníaca.
O do programador:
manipular datasets compartilhados sem derrubar o sistema.
Ambos exigem pacto.
O castelo do Dai Maou é sombrio, cheio de livros proibidos e ecos de almas perdidas.
O castelo do programador noturno é:
um terminal 3270 piscando;
um caderno cheio de senhas riscadas;
um monitor com tabs de JCLs ancestrais;
e uma luminária queimada desde 2017.
Ali, no silêncio absoluto da madrugada, nasce o feitiço supremo:
Pergunte para qualquer veterano:
esse é o verdadeiro grimório proibido.
Assim como o Dai Maou governa sozinho,
o programador das 3h enfrenta batalhas com a mesma solidão trágica:
ninguém responde no Teams,
o on-call sumiu,
o líder mandou “boa sorte 👍” e voltou a dormir,
a documentação está quase correta (e essa é a pior parte),
e a única testemunha da batalha é um café de micro-ondas.
Essa solidão é o preço do poder.
E ambos aceitam.
Quando o Dai Maou aparece, o mundo treme.
Quando o programador aparece às 9h com olheira preta e cara de “revivi três vezes esta noite”, as pessoas desviam o olhar.
Há uma reverência natural.
E o diálogo é sempre o mesmo:
— Nossa, você veio hoje?
— Sistema voltou às 4h.
— Nossa, obrigado!
Ninguém comenta muito.
Ninguém pergunta detalhes.
É tabu.
É sagrado.
(Se tem Bellacosa, tem fofura sombria.)
Há empresas onde o programador noturno é chamado informalmente de “O senhor das trevas”.
Em equipes mais jovens, virou moda dizer “fulano é o Maou do CICS”.
Em grupos de zap, rola o sticker: “Chamem o Dai Maou — o batch caiu!”
Alguns dizem que quando um job dá RC=0012 sem motivo, é porque o Dai Maou interior do programador está testando sua fé.
O Dai Maou, no fundo, é um arquétipo do poder solitário, da responsabilidade inevitável, do peso de manter o mundo girando.
Assim como o programador da madrugada.
Ambos são:
temidos,
respeitados,
incompreendidos,
e absolutamente essenciais.
Quando tudo falha,
quando ninguém sabe o que fazer,
quando o caos ameaça o reino…
é ele que surge,
cansado, mal-humorado, com café na mão,
mas capaz de restaurar a ordem no mundo.
Por isso, querido leitor,
deixo aqui meu mantra:
Dai Maou não é inimigo.
É guardião.
É mantenedor.
É o programador que salva o sistema quando todos estão dormindo.
E é por isso que, no universo do mainframe —
assim como nas lendas —
a noite pertence aos poderosos.
Ao melhor estilo Bellacosa Mainframe, direto dos porões do CPD para o El Jefe Midnight Lunch
Durante décadas, o COBOL foi injustamente carimbado como uma linguagem verborrágica, rígida e cheia de GOTOs selvagens pulando de parágrafo em parágrafo como gremlins em madrugada de fechamento mensal. O COBOL estruturado surge justamente como a vacina contra esse caos.
Mais do que uma evolução sintática, COBOL estruturado é postura, disciplina mental e, acima de tudo, respeito ao próximo programador — normalmente você mesmo daqui a 6 meses.
COBOL estruturado é a aplicação dos princípios da programação estruturada ao COBOL clássico:
Nada de saltos caóticos com GO TO
Fluxo lógico previsível
Blocos com início, meio e fim bem definidos
Ele se apoia em três pilares universais:
Sequência – código executado em ordem natural
Seleção – decisões claras (IF, EVALUATE)
Iteração – repetição controlada (PERFORM UNTIL, PERFORM VARYING)
Se você domina isso, domina qualquer código mainframe.
Porque ele conta uma história.
Compare:
Parágrafos pequenos e objetivos
END-IF, END-PERFORM explícitos
Nomes semânticos (CALCULA-TOTAL, VALIDA-CPF)
O código deixa de ser um labirinto e vira um manual técnico executável.
💡 Dica Bellacosa: se o código parece um romance russo, algo está errado.
Desenhe o fluxo:
O que entra?
Quais decisões existem?
Onde o processamento termina?
Um parágrafo = uma responsabilidade.
Errado:
PROCESSA-TUDO
Certo:
LE-ARQUIVO
VALIDA-DADOS
CALCULA-VALORES
GRAVA-SAIDA
PERFORM VALIDA-DADOS
PERFORM CALCULA-TOTAL
Isso é COBOL estruturado em sua forma mais pura.
Se você precisa de GO TO, provavelmente:
O parágrafo está grande demais
O fluxo está mal pensado
🔹 Menos é mais: COBOL estruturado prefere muitos parágrafos pequenos a poucos gigantes.
🔹 IF aninhado demais é cheiro de problema: use EVALUATE.
🔹 Comentários explicam o porquê, não o como:
* Validação exigida pelo Bacen após incidente de 2009
🔹 Código bem estruturado envelhece melhor que documentação externa.
O impulso pela programação estruturada veio forte nos anos 70, após sistemas críticos se tornarem impossíveis de manter.
Grandes bancos só aceitaram novas rotinas COBOL sem GO TO.
Há sistemas em produção hoje que seguem padrões estruturados criados nos anos 80 — e funcionam melhor que muito microserviço moderno.
🕵️♂️ Já reparou que muitos sistemas usam parágrafos chamados MAIN-PARA ou 0000-INICIO? Isso é herança direta da transição do COBOL não estruturado.
🐘 Alguns compiladores modernos avisam quando você usa GO TO. É o mainframe te julgando silenciosamente.
☕ Programadores COBOL estruturado costumam dormir melhor em fechamento contábil.
✔ Um parágrafo não deve passar de uma tela
✔ Nomeie tudo com significado de negócio
✔ Prefira EVALUATE a IF encadeado
✔ Evite variáveis globais desnecessárias
✔ Código deve ser lido como um roteiro lógico
COBOL estruturado é como um bom uísque: não precisa de modinha, precisa de respeito. Ele entrega previsibilidade, estabilidade e clareza — exatamente o que sistemas críticos exigem.
No fim das contas, não é sobre COBOL.
É sobre engenharia, disciplina e responsabilidade.
E como todo bom código mainframe…
Ele não faz barulho. Ele simplesmente funciona.
— Bellacosa Mainframe, servido à meia-noite no El Jefe Midnight Lunch 🌙
 |
| Bellacosa Mainframe apresenta Python na Ciencia de Dados |
Python é a principal linguagem utilizada em Data Science, permitindo transformar grandes volumes de dados em insights valiosos para negócios e pesquisa.
Com bibliotecas essenciais como NumPy, Pandas, Matplotlib, Seaborn e Scikit-learn, é possível realizar todo o ciclo analítico: carregamento, limpeza, exploração, visualização e modelagem de dados.
O Pandas oferece DataFrames poderosos para manipulação eficiente de informações, enquanto o NumPy garante cálculos vetorizados de alta performance. Ferramentas de visualização ajudam a identificar padrões, tendências e outliers, fundamentais para a análise exploratória. Já o Scikit-learn possibilita a criação de modelos de Machine Learning para previsões e classificações.
Esse ecossistema torna Python indispensável em áreas como finanças, marketing, saúde, engenharia e Big Data. Aprender esses fundamentos é o primeiro passo para atuar como cientista de dados, analista ou engenheiro de dados, acompanhando a crescente demanda por profissionais capazes de extrair valor estratégico a partir dos dados.
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
👉 90% dos projetos começam assim.
a = np.array([1, 2, 3])
b = np.zeros(5)
c = np.ones((2,3))
d = np.arange(0,10)
e = np.linspace(0,1,5)
a * 2
a + b
np.sqrt(a)
np.mean(a)
np.sum(a)
👉 Sem loops → extremamente rápido.
df = pd.DataFrame({
"nome": ["Ana", "João"],
"idade": [25, 30]
})
pd.read_csv("dados.csv")
pd.read_excel("dados.xlsx")
pd.read_json("dados.json")
df.head()
df.tail()
df.info()
df.describe()
df.shape
df.columns
👉 Primeiros comandos após carregar dados.
df["idade"]
df[["nome", "idade"]]
df[df["idade"] > 25]
df[(df["idade"] > 25) & (df["cidade"] == "SP")]
df["idade_futura"] = df["idade"] + 5
df.drop("idade", axis=1)
df.isna()
df.dropna()
df.fillna(0)
df.groupby("cidade")["salario"].mean()
👉 Essencial para análise exploratória.
df.sort_values("idade")
df.sort_values("idade", ascending=False)
df.mean()
df.median()
df.std()
df.min()
df.max()
df.corr()
plt.plot(df["idade"])
plt.show()
plt.hist(df["idade"])
plt.show()
plt.scatter(df["idade"], df["salario"])
plt.show()
sns.histplot(df["idade"])
sns.boxplot(x=df["idade"])
sns.scatterplot(x="idade", y="salario", data=df)
df.drop_duplicates()
df["idade"] = df["idade"].astype(int)
df["data"] = pd.to_datetime(df["data"])
df["ano"] = df["data"].dt.year
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LinearRegression
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, random_state=42
)
model = LinearRegression()
model.fit(X_train, y_train)
pred = model.predict(X_test)
1️⃣ Carregar dados
2️⃣ Explorar
3️⃣ Limpar
4️⃣ Transformar
5️⃣ Visualizar
6️⃣ Modelar
7️⃣ Avaliar
df["log_salario"] = np.log(df["salario"])
df["categoria"] = df["idade"].apply(
lambda x: "Adulto" if x >= 18 else "Menor"
)
df.sample(5)
df["cidade"].value_counts()
df.to_csv("saida.csv", index=False)
df.to_excel("saida.xlsx")
🐍 Python
📊 Pandas
⚡ NumPy
📈 Matplotlib / Seaborn
🤖 Scikit-Learn
🧠 TensorFlow / PyTorch
☁️ Spark / Databricks
👉 “Sem Pandas, Python é só uma linguagem.
Com Pandas, vira uma ferramenta de descoberta.”
☕ Um Café no Bellacosa Mainframe
Se existe uma discussão eterna no mundo IBM Mainframe — quase tão antiga quanto JCL vs PROC ou COBOL fixo vs free — ela atende pelo nome:
CA Changeman ZMF x CA Endevor SCM
Não é guerra.
É clássico.
É derby.
É mainframe raiz.
Vamos colocar os dois frente a frente ao melhor estilo Bellacosa Mainframe: com história, passo a passo, comandos, dicas práticas, curiosidades, easter eggs e comentários de quem já suou em janela de produção.
❌ Não exatamente.
✔ Ambos fazem Software Change Management
✔ Ambos controlam código, versões e promoção
❌ Mas a filosofia é completamente diferente
👉 Changeman é processo e pacote
👉 Endevor é ambiente e mapa
Pense assim:
Changeman: “Vou criar um pacote com tudo que muda.”
Endevor: “Vou mover o elemento dentro do fluxo do sistema.”
Nasceu nos anos 70/80
Criado para ambientes grandes, complexos e altamente integrados
Muito usado em bancos, seguradoras e telecom
Filosofia: onde o código vive importa
Surge depois, focado em governança e auditoria
Ideal para ambientes com:
Muitos desenvolvedores
Processos rígidos
Separação clara de responsabilidades
Filosofia: o pacote é a unidade da mudança
| Conceito | Changeman | Endevor |
|---|---|---|
| Unidade principal | Package | Element |
| Controle | Por pacote | Por ambiente |
| Promoção | Promote Package | Move Element |
| Versão | Baseline | Level |
| Auditoria | Muito forte | Forte, mas diferente |
| Curva de aprendizado | Média | Alta 😅 |
Você cria um Package contendo:
Programas
JCLs
Copybooks
Tudo que muda vai dentro dele.
Edita
Compila
Testa
Usa View Changes para validar
DEV → QA → HML → PRD
Aprovações
Auditoria feliz
Produção protegida
👉 O pacote é rei.
O código já vive dentro de:
Environment
System
Subsystem
Type
Stage
Você:
EDIT o Element
GENERATE
Endevor cria versões (Levels)
MOVE Stage 1 → Stage 2
O elemento sobe no fluxo
Tudo rastreado pelo caminho
👉 O mapa do sistema é rei.
ADD – adicionar elemento
EDIT – editar
GENERATE – compilar
MOVE – promover
BROWSE – visualizar
HISTORY – ver histórico
💬 “Sem GENERATE, não existe Endevor.”
Create Package
Add Components
Edit
Build
Test
Promote
View Changes
💬 “Sem Package, não existe Changeman.”
Ambientes com auditoria pesada
Times grandes
Mudanças agrupadas
Governança forte
Muitas áreas envolvidas
👉 Ideal para bancos e órgãos regulados
Sistemas gigantes
Fluxos complexos
Dependência entre componentes
Times técnicos maduros
👉 Ideal para core systems antigos e robustos
Endevor não precisa de pacote
Changeman vive de pacote
Endevor é extremamente customizável
Changeman é mais user friendly
Ambos integram com RACF
Ambos deixam rastro (log) até do seu suspiro 😄
🥚 O “MOVE errado” no Endevor
Mover o elemento para o stage errado é como:
“scp direto em produção”
🥚 O pacote Frankenstein no Changeman
Package com:
1 programa
2 JCLs
3 COPYs
1 PROC
E ninguém lembra por quê
🥚 Auditor vs Desenvolvedor
Auditor ama Changeman.
Arquiteto raiz ama Endevor.
E o programador… só quer ir pra casa 😂
| Hoje | Mainframe |
|---|---|
| Git Flow | Endevor |
| Pull Request | Changeman Package |
| CI/CD Pipeline | Generate / Promote |
| Diff | View Changes / History |
Resposta honesta Bellacosa:
Depende do ambiente, da cultura e do tamanho do monstro.
❌ Não existe vencedor absoluto
✔ Existe ferramenta certa para o problema certo
Mainframe não é moda.
É engenharia.
Changeman e Endevor não são inimigos.
São filosofias diferentes para o mesmo objetivo:
Proteger produção, garantir rastreabilidade e manter o caos sob controle.
Se você domina os dois, você não é só programador:
👉 Você é guardião do sistema.
☕🚀