Bellacosa Mainframe apresenta o HLASM

💾🔥 HLASM: O “MICROCÓDIGO HUMANO” QUE DOMA O MAINFRAME — DIRETO DO FERRO PARA A HISTÓRIA 🔥💾

Se tem uma linguagem que não conversa com o sistema… ela conversa com o hardware. E faz isso com elegância brutal. Bem-vindo ao universo do HLASM — onde cada instrução é praticamente um pulso elétrico com intenção.

---

🧬 ORIGEM: DO ASM/360 AO HLASM

A história do HLASM começa lá atrás, com o lendário IBM System/360 (1964). Na época, o assembler era o ASM/360, evoluindo depois para:

• Assembler F
• Assembler H
• Assembler XF
• E finalmente o HLASM

📅 Lançamento do HLASM: década de 1990 (oficialmente por volta de 1992–1994), acompanhando a evolução dos sistemas z/OS

👉 A ideia foi clara:
Manter o poder do assembler, mas adicionar recursos “high level” como:

• macros mais poderosas
• melhor diagnóstico
• estruturação mais legível
• integração moderna com o ambiente z/OS

---

⚙️ O QUE TORNA O HLASM DIFERENTE?

HLASM não é “baixo nível raiz”. Ele é um assembler evoluído, com inteligência embutida.

💡 Destaques:

• Macros sofisticadas (quase uma metalinguagem)
• Controle avançado de fluxo
• Suporte a debug e listagens detalhadas
• Integração com ferramentas modernas IBM
• Performance absurda (nível hardware)

👉 Em resumo:
Você escreve assembler… mas com superpoderes.

---

🏛️ COMPATIBILIDADE: A RELÍQUIA QUE NUNCA MORRE

HLASM mantém compatibilidade com décadas de código legado.

Isso significa:

• Código dos anos 70 ainda roda hoje 😳
• Integra com:
  • CICS
  • DB2
  • IMS
• Funciona perfeitamente nos atuais IBM Z

👉 Isso não é retrocompatibilidade…
É imortalidade corporativa.

---

🧠 FILOSOFIA: QUANDO VOCÊ PENSA COMO O PROCESSADOR

Programar em HLASM é entender:

• registradores
• endereçamento
• instruções de máquina
• pipeline do processador

É quase como conversar direto com a CPU:

“Carregue isso. Compare aquilo. Salte agora.”

Sem intermediários. Sem abstrações.

---

⚔️ HLASM vs ASSEMBLY DO MUNDO PC

Agora começa a parte divertida 😄

🖥️ x86 / x64 (PC, Windows, Linux, macOS)

• Usado em NASM, MASM
• Arquiteturas:
  • 8 bits (8080, 8085)
  • 16 bits (8086)
  • 32 bits (80386)
  • 64 bits (x86-64)

👉 Características:

• Forte dependência de registradores limitados
• Segmentação histórica (16 bits)
• Instruções mais “bagunçadas” (CISC complexo)

---

🧊 HLASM (Mainframe)

• Arquitetura limpa e consistente desde o System/360
• Registradores bem definidos (R0–R15)
• Endereçamento poderoso
• Foco em processamento massivo e confiabilidade

👉 Diferença brutal:

Aspecto	HLASM	x86/x64
Estabilidade	Décadas sem ruptura	Mudanças constantes
Legado	Totalmente preservado	Parcial
Clareza	Alta consistência	Muitas exceções
Performance	Otimizado para I/O e batch	Otimizado para geral

---

🧪 CURIOSIDADES QUE POUCA GENTE SABE

💡 HLASM é usado até hoje em:

• Núcleos bancários
• Sistemas de pagamento
• Processamento de milhões de transações por segundo

💡 Muitas rotinas críticas em COBOL chamam HLASM por baixo

💡 Algumas empresas NUNCA reescreveram seus códigos assembler… só foram evoluindo

💡 HLASM é tão eficiente que às vezes substitui C/C++ em partes críticas

---

🛠️ DICAS DE OURO (ESTILO BELLACOSA 😎)

🔥 1. Aprenda registradores como extensão do seu cérebro
R1 não é número… é propósito.

🔥 2. Domine macros
Macro em HLASM = produtividade + elegância

🔥 3. Leia listagens (LISTING)
É ali que você vira mestre.

🔥 4. Entenda o fluxo de execução real
Branch errado = desastre silencioso

🔥 5. Combine com COBOL
COBOL + HLASM = performance + legibilidade

---

🧾 COMENTÁRIO REALISTA (SEM ROMANTIZAR)

HLASM não é para iniciantes.

Ele exige:

• disciplina
• atenção absurda
• entendimento profundo do sistema

Mas em troca?

👉 Você ganha controle TOTAL.

---

🧠 ANALOGIA FINAL

Se linguagens modernas são:

• Java = carro automático
• Python = carro elétrico
• C = carro manual esportivo

👉 HLASM é:

um caça supersônico com painel analógico.

Você não dirige…
Você pilota.

---

🚀 FECHAMENTO

O HLASM não é só uma linguagem.

É um legado vivo.
Uma ponte entre 1964 e o futuro.
Um lembrete de que, às vezes…

👉 o caminho mais direto ainda é o mais poderoso.

💣 COBOL NÃO É LEGADO — É CARÁTER: O CAMINHO DO DEV QUE QUER SAIR DO “OPERADOR DE JOB” PARA ENGENHEIRO DE MISSÃO CRÍTICA

 

Bellacosa Mainframe uma conversa com DEVs Programadores COBOL

💣 COBOL NÃO É LEGADO — É CARÁTER: O CAMINHO DO DEV QUE QUER SAIR DO “OPERADOR DE JOB” PARA ENGENHEIRO DE MISSÃO CRÍTICA

---

Existe um mito silencioso no mundo corporativo:
o de que o desenvolvedor COBOL é apenas um “mantenedor de código antigo”.

Isso não só está errado — é perigoso.

Porque enquanto muitos enxergam “legado”, poucos entendem que estão sentados em cima de o sistema nervoso de bancos, seguradoras, bolsas e governos inteiros.

E aí vem a pergunta que separa os comuns dos raros:

👉 Você é um digitador de programa… ou um engenheiro de sistema crítico?

---

🧭 ORIGEM: QUANDO O COBOL NÃO ERA “VELHO” — ERA REVOLUCIONÁRIO

COBOL nasceu nos anos 60 com uma missão ousada:

ser compreensível para humanos de negócio

Enquanto outras linguagens eram matemáticas, o COBOL era quase… literatura.

Exemplo clássico:

ADD SALARIO TO TOTAL-PAGAMENTO.

Isso não é código. Isso é intenção.

💡 Easter Egg histórico:
A linguagem foi fortemente influenciada por Grace Hopper, que defendia que código deveria ser legível como inglês — algo que hoje o mundo redescobre com “clean code”.

---

⚠️ O PROBLEMA MODERNO: O DEV QUE PAROU NO TEMPO

O erro mais comum não é técnico.

É mental.

O dev COBOL muitas vezes cai em um desses perfis:

• 🔁 “Eu só faço manutenção”
• 🧱 “Sempre foi assim”
• 📦 “Não mexe nisso que funciona”

Esse mindset transforma profissionais em… gargalos humanos.

E o mercado já percebeu isso.

Hoje não falta vaga para COBOL.
Falta gente que pensa além do COBOL.

---

🧠 EVOLUÇÃO REAL: O QUE SEPARA O DEV COMUM DO DIFERENCIADO

Vamos direto ao ponto.

1. 📊 ENTENDER O NEGÓCIO (DE VERDADE)

Se você não sabe o que seu programa faz no negócio…

👉 você é substituível.

Um dev COBOL de alto nível sabe responder:

• Esse programa impacta qual produto bancário?
• Qual risco financeiro existe aqui?
• Qual o impacto de uma falha?

💡 Exemplo real:

Um simples IF mal feito pode gerar milhões em prejuízo em cálculo de juros.

---

2. 🔍 LER MAIS DO QUE ESCREVER

Dev COBOL sênior não escreve código rápido.

Ele entende código legado absurdo com facilidade.

Exemplo clássico:

IF WS-IND = 'S' OR 'Y' AND NOT = 'N'

👉 Isso aqui é bug esperando acontecer.

O profissional evoluído:

• refatora
• documenta
• simplifica

---

3. ⚙️ DOMINAR O ECOSSISTEMA (NÃO SÓ COBOL)

COBOL sozinho não vive.

Você precisa dominar:

• JCL (o sangue do batch)
• CICS (o tempo real)
• DB2 (a memória do sistema)
• VSAM (o legado vivo)
• SORT / IDCAMS (os bastidores)

💥 Easter Egg técnico:
Muitos problemas de “performance COBOL” são, na verdade, problemas de JCL mal desenhado ou acesso ineficiente ao DB2.

---

4. 🚀 PERFORMANCE É DIFERENCIAL (E POUCOS DOMINAM)

Um dev comum faz funcionar.
Um dev avançado faz escalar.

Exemplo:

• Evitar READ NEXT desnecessário
• Usar buffers corretamente
• Reduzir I/O
• Escolher entre VSAM vs DB2 com critério

💡 Curiosidade:
Mainframe ainda processa bilhões de transações por dia — e COBOL está no centro disso.

---

5. 🌐 APRENDER A CONVERSAR COM O MUNDO MODERNO

Aqui está o divisor de águas atual.

Você precisa saber integrar COBOL com:

• APIs REST
• JSON
• Mensageria
• z/OS Connect
• Microservices

Exemplo simples de mentalidade:

Antes:

Programa batch gera arquivo

Depois:

Programa expõe serviço consumido por app mobile

💥 Isso muda tudo.

---

6. 🧩 REFACTORING: A ARTE QUE QUASE NINGUÉM FAZ

Código COBOL antigo muitas vezes é um labirinto.

Mas cuidado:

👉 refatorar sem entender é quebrar produção.

O profissional diferenciado:

• entende fluxo completo
• cria versões paralelas
• valida com dados reais
• documenta decisões

---

7. 📚 DOCUMENTAR COMO SE SUA VIDA DEPENDESSE DISSO

Porque depende.

Mainframe tem um problema clássico:

conhecimento tribal

Se você sair… o sistema para.

Quem documenta bem:

• vira referência
• cresce rápido
• reduz riscos

---

🧪 EXEMPLO PRÁTICO: DO DEV COMUM AO ENGENHEIRO

Situação:

Programa COBOL lê VSAM e calcula saldo.

Dev comum:

• ajusta campo
• recompila
• entrega

Dev evoluído:

• entende regra de negócio
• valida consistência histórica
• analisa impacto em batch downstream
• melhora performance
• documenta fluxo
• sugere evolução (API, por exemplo)

👉 Resultado: ele não entrega código.

Ele entrega segurança operacional.

---

🧿 FILOSOFIA DO MAINFRAME: DISCIPLINA > MODISMO

Enquanto o mundo corre atrás de frameworks…

o mainframe exige:

• precisão
• previsibilidade
• responsabilidade

💡 Um erro aqui não derruba um site.

👉 Derruba um banco.

---

🧨 EASTER EGG FINAL (PARA QUEM É RAIZ)

Se você nunca:

• analisou um dump S0C7 na unha
• perseguiu um abend fantasma
• ou depurou JOB em produção

… você ainda não viu o verdadeiro mainframe.

---

🏁 CONCLUSÃO: O DEV COBOL DO FUTURO NÃO É LEGADO — É RARO

O mercado não quer mais alguém que “sabe COBOL”.

Quer alguém que:

• entende negócio
• domina ecossistema
• pensa em arquitetura
• integra com o mundo moderno
• resolve problemas críticos

👉 Isso não é um programador.

Isso é um engenheiro de missão crítica.

---

☕ FRASE FINAL (ESTILO BELLACOSA)

“COBOL não é sobre o passado.
É sobre quem tem coragem de carregar o presente… sem margem para erro.”

 

🧠 SMP/E na Prática: O que são MCS — Modification Control Statements?

Bellacosa Mainframe apresenta SMP/E na pratica o fluxo de um MCS

🧠 SMP/E na Prática : O que são MCS — Modification Control Statements?

Os MCS (Modification Control Statements) são instruções de controle usadas pelo SMP/E para descrever o que um pacote de manutenção contém e como ele deve ser instalado.

👉 Pense no MCS como a “receita” que diz ao SMP/E:

• quais módulos vão ser substituídos,
• quais macros entram ou saem,
• dependências necessárias,
• pré-requisitos,
• co-requisitos,
• SYSMODs substituídos,
• módulos afetados,
• e onde tudo deve ser aplicado.

Essas instruções aparecem normalmente dentro de:

• PTFs (Program Temporary Fixes)
• APARs
• USERMODs
• FMIDs (instalação de produtos)

---

🧾 Como os MCS são emitidos?

Você não digita MCS manualmente durante a aplicação normal. Eles vêm dentro dos pacotes de manutenção, distribuídos pelo fornecedor (ex.: IBM).

O fluxo típico é:

1. Você recebe um PTF/APAR.
2. Dentro dele existem blocos MCS, como:
   • ++VER
   • ++MOD
   • ++MAC
   • ++JCLIN
   • ++HOLD
   • ++IF / ++REQ / ++PRE
3. Esses blocos descrevem ao SMP/E:
   • quais módulos substituir
   • como montar link-edit
   • dependências
   • regras de instalação

---

⚙️ Onde o APPLY entra nessa história?

O comando APPLY do SMP/E processa as instruções MCS e efetivamente instala as mudanças no ambiente target.

Fluxo simplificado:

1. RECEIVE
   • lê os MCS e registra no banco SMP/E.
2. APPLY
   • valida dependências declaradas nos MCS.
   • verifica PRE/REQ/IF.
   • monta JCL se houver ++JCLIN.
   • atualiza módulos, macros, etc.
3. ACCEPT
   • confirma no DLIB (distribution library).

---

🔄 Relação direta entre MCS e APPLY

✔ Os MCS dizem o que fazer.
✔ O APPLY executa o que foi declarado.

Exemplo conceitual:

++VER
++MOD(MYMOD) DISTLIB(AOSL)
++MAC(MYMAC)
++JCLIN

O APPLY vai:

• validar PREs e REQs,
• aplicar módulos,
• montar e executar o JCLIN,
• atualizar o ambiente.

---

🧩 O APPLY “lê” os MCS?

Exatamente. O SMP/E usa os MCS como instruções de engenharia. O APPLY:

• lê os blocos ++VER / ++MOD / ++MAC / ++JCLIN
• monta a sequência correta
• valida integridade
• garante consistência entre FMIDs, SYSMODs e bibliotecas

Sem MCS, o APPLY não saberia o que fazer.

---

🧪 Exemplo didático

Imagine um PTF que corrige um módulo COBOL:

O MCS pode declarar:

++VER(Z038) FMID(HBB7780).
++MOD(IGYCRCTL) DISTLIB(SIGYLOAD).

O APPLY irá:

• verificar FMID HBB7780
• garantir dependências
• substituir o módulo IGYCRCTL na loadlib correta

---

🧠 Resumo prático

• MCS = linguagem que descreve a manutenção.
• SMP/E = interpretador/engine.
• APPLY = ação que materializa as mudanças.

---

Um exemplo de MCS realista para um PTF que altera componentes do IBM Enterprise COBOL for z/OS e depende do runtime do IBM Language Environment (LE).

⚠️ Este é um exemplo didático (estrutura fiel, mas nomes ilustrativos).

---

📦 Exemplo — MCS de um PTF de COBOL/LE

Imagine um PTF que:

• Atualiza o módulo IGZCCTL (runtime LE para COBOL)
• Atualiza o compilador IGYCRCTL
• Exige um pré-requisito
• Inclui JCLIN para link-edit

Exemplo MCS

++PTF(UX12345) REWORK(20260413).
++VER(Z038)
     FMID(HIGY170)
     PRE(UJ99999)
     REQ(LE37000).

++HOLD(UX12345)
     SYSTEM
     REASON(ACTION)
     DATE(260413)
     COMMENT(
       'Este PTF atualiza módulos do compilador COBOL e
        componentes de runtime LE. Requer rebind após APPLY.'
     ).

++MOD(IGYCRCTL) DISTLIB(SIGYCOMP) SYSLIB(SIGYCOMP).
++MOD(IGZCCTL)  DISTLIB(SCEERUN)  SYSLIB(SCEERUN).

++MAC(IGZMAC01) DISTLIB(SCEEMAC).

++JCLIN.
 //LKED EXEC PGM=IEWL,PARM='LIST,XREF,LET'
 //SYSLMOD DD DSN=CEE.SCEERUN,DISP=SHR
 //SYSLIN  DD *
   INCLUDE SYSLIB(IGZCCTL)
   ENTRY IGZCCTL
   NAME IGZCCTL(R)
 /*
++END

---

🧠 O que cada bloco faz?

✔️ ++PTF

Define o SYSMOD e metadados.

✔️ ++VER

Define o FMID alvo (feature a ser mantida) e dependências:

• PRE → pré-requisitos
• REQ → requisitos obrigatórios

✔️ ++HOLD

Impede instalação automática e obriga ação manual (por exemplo, rebind).

✔️ ++MOD

Declara módulos a substituir e onde instalá-los.

✔️ ++MAC

Declara macros a atualizar.

✔️ ++JCLIN

Fornece instruções de link-edit que o SMP/E executará no APPLY.

---

⚙️ Como isso interage com APPLY?

Quando você executa:

SET BDY(TGT1).
APPLY PTFS(UX12345).

O SMP/E irá:

1. Verificar FMID e PRE/REQ
2. Validar HOLDS
3. Copiar módulos declarados em ++MOD
4. Rodar o JCLIN para link-edit
5. Registrar o resultado no CSI

---

🧩 Resumo rápido

• MCS = contrato do PTF
• APPLY = motor que executa esse contrato
• O ++JCLIN evita você montar manualmente link-edits 

 

Bellacosa Mainframe introduz o DB2

💀 “Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações”

Se você acha que banco de dados é só “guardar informação”… prepare-se: no mundo corporativo pesado — bancos, seguradoras, governos — quem reina é a dupla COBOL + Db2.
E não, isso não é legado morto. Isso é infraestrutura crítica global.

---

🧬 Origem: quando dados viraram ciência

Antes do Db2, existia caos.

• arquivos flat
• duplicação
• dificuldade de acesso

Então surge o modelo relacional, criado por Edgar F. Codd na IBM.

👉 Resultado:

• tabelas
• chaves
• SQL

E nos anos 80 nasce o Db2, trazendo isso para o mundo enterprise.

---

🏛️ Db2 no Mainframe: onde o jogo é sério

O Db2 roda no z/OS, lado a lado com:

• COBOL
• CICS
• IMS

💀 Tradução:

Isso aqui processa dinheiro de verdade

---

☕ O Dev COBOL Sênior (vida real)

Imagine um sistema bancário:

Cliente faz transferência → COBOL → Db2 → commit

---

💡 Exemplo COBOL + Db2

EXEC SQL
   UPDATE CONTA
   SET SALDO = SALDO - 100
   WHERE ID = :ORIGEM
END-EXEC.

EXEC SQL
   UPDATE CONTA
   SET SALDO = SALDO + 100
   WHERE ID = :DESTINO
END-EXEC.

EXEC SQL
   COMMIT
END-EXEC.

👉 Simples? Sim.
👉 Crítico? ABSURDAMENTE.

---

🔄 Transações: o coração do sistema

Você viu isso no módulo — aqui é onde ganha vida:

START → UPDATE → COMMIT

Se falhar:

ROLLBACK

💀 Isso evita:

• dinheiro sumir
• inconsistência

---

📜 Logging: a caixa preta do banco

Db2 registra TUDO:

• INSERT
• UPDATE
• DELETE

👉 Isso permite:

• auditoria
• recovery
• rastreamento

---

💡 Insight

Sem log… você está cego
Com log… você reconstrói o passado

---

🔄 Recovery: sobrevivência do sistema

Cenário:

• backup às 6:00
• falha às 11:00

👉 solução:

Backup + Logs = estado correto

---

💾 Backup no mundo real

❄️ Cold

• banco parado

🌡️ Warm

• leitura apenas

🔥 Hot

• banco online (produção)

💀 No banco:

parar sistema não é opção → usa hot backup

---

🔒 Locking: guerra silenciosa

3 programas acessando o mesmo registro:

App1 → lock
App2 → espera
App3 → leitura controlada

👉 Locks evitam corrupção

---

💡 Regra de ouro

Lock só é liberado no COMMIT

---

⚡ Performance: onde o DBA brilha

📦 Buffers

• memória → rápido

📚 Index

• busca instantânea

⚙️ Optimizer

• escolhe melhor plano

---

👉 Exemplo:

Sem índice:

SELECT * FROM CLIENTE WHERE NOME='JOÃO';

Com índice:

CREATE INDEX IDX_NOME ON CLIENTE(NOME);

⚡ diferença absurda

---

🌐 Integração moderna (sim, Db2 evoluiu)

Hoje Db2 conversa com:

• APIs
• Java (JDBC)
• ODBC
• microservices

👉 Não é mais só terminal verde 😄

---

🧠 Stored Procedures: lógica dentro do banco

CREATE PROCEDURE TRANSFERIR(...)

👉 roda dentro do Db2
👉 menos rede
👉 mais performance

---

🧬 Easter Eggs & Curiosidades

💡 Db2 nasceu dentro da IBM Research
💡 COBOL ainda processa ~70% das transações financeiras mundiais
💡 Muitos sistemas críticos têm décadas sem downtime significativo

---

💀 Easter Egg raiz:

“If it ain’t broken, don’t migrate it”
(tradução: se está rodando há 30 anos… NÃO mexe 😄)

---

🔥 Insight nível Bellacosa

Mainframe não é legado…
é infraestrutura estável, segura e absurda em escala

---

🧠 Visão final (arquitetura)

Usuário → Aplicação (COBOL) → Db2 → Dados
                       ↓
                   Logs / Backup / Recovery

---

🚀 Conclusão

Você começou aprendendo:

• o que é banco
• modelos
• DBMS
• transações
• logs
• backup
• performance

👉 E chegou aqui:

💀 Entendendo como o mundo financeiro roda

---

💥 Frase final

Enquanto todo mundo fala de cloud…
o dinheiro do mundo continua passando por COBOL + Db2

 

🚀 Seu cérebro COBOL está pronto para Python? O guia que acelera a migração em horas, não anos

 

Bellacosa Mainframe apresenta Python para Engenheiros e Analistas de Mainframe

🚀 Seu cérebro COBOL está pronto para Python? O guia que acelera a migração em horas, não anos

Python tornou-se uma linguagem estratégica para engenheiros de mainframe que desejam expandir suas habilidades para automação, integração moderna, Data Engineering e Inteligência Artificial. 

Para profissionais acostumados com COBOL, JCL e DB2, Python oferece um modelo mental mais simples e produtivo, substituindo estruturas como WORKING-STORAGE por variáveis dinâmicas, PERFORM por loops e FILE SECTION por manipulação direta de arquivos. 

Com bibliotecas poderosas e sintaxe clara, é possível automatizar rotinas operacionais, processar logs, integrar sistemas legados a APIs REST, consumir serviços web e construir pipelines de dados com muito menos código. 

Python também facilita DevOps, testes de batch, RPA corporativo e modernização de aplicações críticas. Seu uso crescente em nuvem, analytics e machine learning torna essa linguagem uma ponte natural entre o ambiente z/OS e o ecossistema digital atual. 

Aprender Python é, portanto, um passo essencial para mainframe engineers que desejam permanecer relevantes na transformação tecnológica.

🐍🔥 Cheatsheet Python para Mainframe Engineers

🧠 Mental Model — COBOL → Python

Conceito Mainframe	Equivalente Python
Program	Script / Module
WORKING-STORAGE	Variáveis
PIC clauses	Tipagem dinâmica
PERFORM UNTIL	while
PERFORM VARYING	for
COPYBOOK	Module / Class
FILE SECTION	File handling
DB2 cursor	Iteração
JCL orchestration	Scripts + Scheduler

---

📦 Variáveis (sem DATA DIVISION 😎)

COBOL

01 WS-NUM PIC 9(4) VALUE 100.

Python

ws_num = 100

✔ Sem declaração
✔ Sem tamanho fixo
✔ Tipagem dinâmica

---

📚 Estruturas de Dados — “Working Storage Turbo”

🔹 List → Tabelas OCCURS

clientes = ["Ana", "João", "Maria"]
clientes.append("Carlos")

👉 Similar a:

OCCURS n TIMES

---

🔹 Dictionary → Registro com campos nomeados

cliente = {
    "nome": "Ana",
    "saldo": 1500
}

👉 Mistura de:

✔ Registro
✔ Índice por chave
✔ Estrutura dinâmica

---

🔹 Tuple → Registro imutável

coordenada = (10, 20)

👉 Ideal quando dados não devem mudar.

---

🔹 Set → Lista sem duplicatas

codigos = {101, 102, 102, 103}

Resultado:

{101, 102, 103}

👉 Excelente para deduplicação de dados.

---

🔎 Indexação

nome = "BELLACOSA"

nome[0]   # B
nome[-1]  # A

👉 Python começa em ZERO (como C, não como COBOL).

---

⚖️ Condições (IF sem THEN/END-IF)

saldo = 100

if saldo > 0:
    print("Positivo")
else:
    print("Negativo")

---

🔁 Loops

🔹 For (PERFORM VARYING)

for i in range(5):
    print(i)

---

🔹 For em coleção

for cliente in clientes:
    print(cliente)

👉 Cursor implícito.

---

🔹 Enumerate (índice + valor)

for i, nome in enumerate(clientes):
    print(i, nome)

---

🔹 While (PERFORM UNTIL)

x = 0

while x < 5:
    print(x)
    x += 1

---

🧩 Funções (Subprogramas leves)

def calcular_taxa(valor):
    return valor * 0.05

Chamada:

taxa = calcular_taxa(1000)

---

📏 Built-ins que substituem muito código COBOL

len(lista)        # tamanho
sum(lista)        # soma
max(lista)
min(lista)
sorted(lista)

---

⚠️ Tratamento de Erros (sem Abend 😎)

COBOL

ON EXCEPTION

Python

try:
    x = int("abc")
except ValueError:
    print("Erro de conversão")

---

📂 Arquivos (QSAM moderno)

Leitura

with open("dados.txt", "r") as f:
    for linha in f:
        print(linha)

---

Escrita

with open("saida.txt", "w") as f:
    f.write("Hello Mainframe")

👉 with garante fechamento automático.

---

🧱 Classes (Estruturas + Comportamento)

class Conta:
    def __init__(self, saldo):
        self.saldo = saldo

    def depositar(self, valor):
        self.saldo += valor

Uso:

c = Conta(1000)
c.depositar(500)

---

🔍 Tipos e Debug

type(x)

---

🚀 Automação — O Superpoder

Executar comandos do sistema

import os

os.system("dir")

---

Processar arquivos em lote

import glob

for arquivo in glob.glob("*.txt"):
    print(arquivo)

---

🌐 Integração moderna

Consumir API

import requests

r = requests.get("https://api.github.com")
print(r.status_code)

👉 Equivalente moderno de MQ + Web Services.

---

🧠 Padrões mentais úteis

Python é:

✔ Scriptável
✔ Interativo
✔ Orientado a objetos
✔ Ideal para automação
✔ Excelente para integração

---

💥 Onde Python brilha para Mainframe Engineers

🔥 Automação operacional
🔥 DevOps e pipelines
🔥 Testes de batch
🔥 Processamento de logs
🔥 APIs REST para legado
🔥 Data Engineering
🔥 Machine Learning
🔥 RPA e scripting corporativo

---

☕ Frase estilo War Room

👉 COBOL mantém o mundo funcionando.
Python automatiza o mundo que muda.