Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

📘 REPOST: CICS Command Level para padawans

 

CICS Command Level for Padawans

📘 CICS Command Level para padawans

Um guia passo a passo para entender o que é CICS, aprender e planejar um roteiro de estudos com o orquestrador do online em Mainframe.

#ibm #mainframe #cobol #cics #t3270 #vsam #bms #ksds #esds #ceda #ceci #cemt 

Post no Linkedin

1

 

REXX – Introducing My New Friend

(ou: como eu parei de torcer o nariz e ganhei um aliado no z/OS e z/VM)

“Às vezes o melhor software não é o mais caro, nem o mais novo. É o que já está aí, esperando você parar de ignorar.”

Navegar pelas complexidades do z/OS e do z/VM exige um arsenal respeitável de ferramentas. JCL, COBOL, assembler, CLIST, utilitários do sistema, produtos terceiros… tudo isso faz parte do dia a dia.
Mas em muitos momentos, o tool ideal simplesmente não existe, é caro demais, ou não justifica um processo de aquisição que passa por 37 comitês, 12 reuniões e 2 meses de espera.

Foi exatamente aí que, meio a contragosto, eu resolvi sair da zona de conforto e mergulhar em uma linguagem que sempre esteve ali, silenciosa, quase invisível: REXX.

Confesso: no começo houve resistência.
“Mais uma linguagem?”
“Isso não é coisa de CLIST melhorado?”
“Será que vale o tempo?”

Spoiler: vale. E muito.
Hoje, o REXX não é só uma linguagem — é meu novo amigo no mainframe.

---

📜 1. Um breve passeio pela história das linguagens

Antes de falar de REXX, precisamos contextualizar.

Da força bruta à legibilidade

• Anos 40/50: código de máquina e Assembly — poder absoluto, legibilidade zero.

• Anos 60: COBOL, FORTRAN — produtividade e portabilidade começam a surgir.

• Anos 70: linguagens estruturadas, foco em legibilidade e manutenção.

• Anos 80: linguagens de script e automação ganham espaço.

É nesse cenário que, em 1979, na IBM, surge o REXX (Restructured Extended Executor), criado por Mike Cowlishaw.

👉 O objetivo era claro:

Criar uma linguagem simples, legível, poderosa e tolerante a erros humanos.

Nada de pontuação excessiva, nada de sintaxe críptica.
REXX foi pensado para gente, não só para compiladores.

📌 Easter egg histórico:
Mike Cowlishaw também é o criador da notação decimal usada em IEEE 754-2008. Ou seja, o homem sabia exatamente o que estava fazendo.

---

🧑‍💻 2. O papel real de sysprogs e devs no z/OS e z/VM

Quem vive mainframe sabe:
o trabalho não é só programar.

No mundo real, fazemos:

• Automação de tarefas repetitivas

• Análise de datasets e catálogos

• Interação com TSO/ISPF

• Chamada de comandos do sistema

• Tratamento de mensagens (WTO, WTOR, GETMSG)

• Integração entre ferramentas

• Prototipação rápida de soluções

• “Apagar incêndio” às 3h da manhã 🔥

E aqui vem a pergunta fatal:

Você vai fazer tudo isso em COBOL compilado?

REXX entra exatamente nesse espaço:

• Mais poderoso que CLIST

• Mais simples que COBOL

• Mais integrado que scripts externos

---

🔌 3. Integrando REXX ao seu workflow atual

REXX não substitui COBOL, PL/I ou Assembler.
Ele complementa.

Onde o REXX brilha:

• Dentro do TSO

• Em ISPF

• Em batch

• No z/VM (CMS, CP, EXECs)

• Chamando utilitários do sistema

• Orquestrando JCL

• Automatizando ambientes

📌 Easter egg prático:
Você pode chamar IDCAMS, IEFBR14, SDSF, comandos MVS e até programas COBOL diretamente do REXX.

REXX é o cola tudo do mainframe.

---

🧠 4. Fundamentos e base teórica do REXX

Filosofia da linguagem

• Tudo é string

• Tipagem dinâmica

• Sintaxe limpa

• Código próximo do inglês

• Pouca pontuação

• Muito foco em legibilidade

Exemplo simples:

say 'Hello, mainframe world!'

Sem ponto e vírgula.
Sem BEGIN/END obrigatórios.
Sem drama.

Estrutura básica

• Instruções lineares

• Controle por IF, DO, SELECT

• Funções internas riquíssimas

• Integração nativa com o ambiente

Variáveis

nome = 'Bellacosa'
say 'Bem-vindo,' nome

📌 Curiosidade:
Variáveis não inicializadas não quebram o programa.
Elas simplesmente retornam o próprio nome.
Isso é genial para debug… e perigoso se você não souber 😄

---

🧩 5. Pré-requisitos para aprender REXX

A boa notícia: poucos.

Idealmente você já conhece:

• Conceitos básicos de mainframe

• TSO/ISPF

• JCL (ao menos leitura)

• Dataset, PDS, PS, membros

• Comandos básicos do sistema

Se você sabe navegar no ISPF, já está 50% pronto.

---

🛠️ 6. REXX na prática – exemplos do mundo real

Exemplo 1 – Listar datasets

address tso "listcat level('USER01')"

Exemplo 2 – Automatizar ISPF

address ispexec "control errors return"
address ispexec "display panel(MYPANEL)"

Exemplo 3 – Batch REXX

//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSEXEC  DD DISP=SHR,DSN=USER.REXX.LIB
//SYSTSIN  DD *
  %MEUREXX
/*

📌 Easter egg avançado:
REXX pode ler e escrever datasets linha a linha com EXECIO.
Sim, você pode fazer mini-SORTs sem DFSORT.

---

🤯 7. Curiosidades que poucos contam

• REXX existe fora do mainframe (OS/2, Windows, Linux)

• É base de automação em vários produtos IBM

• Muitos produtos “enterprise” usam REXX internamente

• CLIST perdeu espaço por causa do REXX

• É uma das linguagens mais subestimadas do ecossistema IBM Z

---

☕ Conclusão – Por que REXX virou meu novo amigo

REXX não é moda.
REXX não é hype.
REXX é eficiência silenciosa.

Ele resolve problemas reais:

• rápido

• integrado

• sem burocracia

• sem custo extra

• com curva de aprendizado amigável

Se você trabalha com z/OS ou z/VM e ainda ignora o REXX, deixo o conselho de veterano:

Não subestime uma linguagem que a IBM colocou no coração do sistema.

Porque às vezes, o melhor amigo já estava no mainframe…
você só nunca tinha puxado assunto 😉

 

🔥 Como Criar uma Tela CICS BMS – Guia Definitivo Passo a Passo

---

☕ Introdução — Antes do HTML, existia o BMS

Antes de React, Angular e CSS, o mainframe já fazia interface rica — só que com disciplina, regra e respeito ao terminal.

No mundo CICS, tela não é arte.
Tela é contrato, estado, performance e sobrevivência em produção.

Vamos do zero absoluto até a tela rodando, sem pular etapas.

---

🧱 Conceitos Fundamentais (Sem isso, tudo quebra)

📌 O que é BMS?

BMS (Basic Mapping Support) é a linguagem declarativa usada para definir telas CICS.

Ela descreve:

• Campos

• Posições

• Atributos

• Proteção

• Entrada e saída de dados

📌 BMS não tem lógica.
Ele só descreve como a tela se comporta.

---

🧠 MAP vs MAPSET — A confusão clássica

Conceito	O que é
MAPSET	Conjunto de mapas (arquivo fonte BMS)
MAP	Uma tela individual dentro do MAPSET

📌 Analogia Bellacosa:

• MAPSET = arquivo HTML

• MAP = página individual

• FIELD = input / label

---

🧭 Passo a Passo — Criando uma Tela CICS BMS

---

1️⃣ Criar o Fonte BMS (MAPSET)

Exemplo básico:

MAPSET01 DFHMSD TYPE=MAP,MODE=INOUT,LANG=COBOL,TERM=3270

Parâmetros importantes:

• TYPE=MAP → indica que é um MAPSET

• MODE=INOUT → entrada e saída

• LANG=COBOL → gera copybook COBOL

• TERM=3270 → terminal padrão

📌 Erro comum: esquecer LANG=COBOL → não gera copybook.

---

2️⃣ Definir um MAP (Tela)

MAP01 DFHMDI SIZE=(24,80),LINE=1,COLUMN=1

O que isso faz:

• Cria uma tela de 24x80

• Posiciona no canto superior

📌 Um MAPSET pode ter vários MAPs.

---

3️⃣ Definir Campos (DFHMDF)

Exemplo:

CAMPO1 DFHMDF POS=(5,10),
       LENGTH=10,
       ATTRB=(UNPROT,IC),
       INITIAL='Digite:'

Parâmetros essenciais:

Parâmetro	Função
POS	Linha e coluna
LENGTH	Tamanho
ATTRB	Atributos
INITIAL	Texto inicial

---

🎛️ Atributos Importantes (Onde mora o poder)

Atributo	Função
PROT	Campo protegido
UNPROT	Campo editável
IC	Cursor inicial
MDT	Campo alterado
BRT	Brilho
ASKIP	Pula o campo

📌 Erro clássico: esquecer MDT → CICS acha que o campo não mudou.

---

4️⃣ Finalizar o MAPSET

DFHMSD TYPE=FINAL
END

📌 Sem isso, não compila.

---

⚙️ Workflow de Compilação (Onde muitos erram)

1️⃣ Fonte BMS
2️⃣ Assembler
3️⃣ Gera MAPSET (LOAD)
4️⃣ Gera COPYBOOK
5️⃣ COPYBOOK entra no programa COBOL
6️⃣ Programa SEND/RECEIVE MAP

📌 BMS não é compilado como COBOL.

---

🧪 Usando o MAP no Programa COBOL

Enviar a tela:

EXEC CICS SEND
     MAP('MAP01')
     MAPSET('MAPSET01')
     ERASE
END-EXEC

Receber dados:

EXEC CICS RECEIVE
     MAP('MAP01')
     MAPSET('MAPSET01')
END-EXEC

📌 O COPYBOOK gerado contém:

• campos de entrada

• campos de saída

• indicadores MDT

---

🚀 Otimização — Dicas Bellacosa de Produção

✅ Boas práticas

• Campos pequenos → menos tráfego

• Use PROT para labels

• Use UNPROT só onde necessário

• Evite mapas gigantes

• Reutilize MAPSETs

❌ Erros comuns

• Um MAP por MAPSET sem necessidade

• Tela cheia de campos UNPROT

• Esquecer MDT

• Misturar lógica com tela

• Hardcode de posição no COBOL

---

🧠 Hierarquia Mental do BMS (Grave isso)

MAPSET
 ├── MAP
 │    ├── FIELD
 │    ├── FIELD
 │    └── FIELD

📌 Se você entende isso, não se perde mais.

---

🧯 Erros Clássicos em Produção

Problema	Causa
Tela não aparece	MAPSET não instalado
Campos vazios	MDT ausente
Cursor errado	IC mal posicionado
Dump AEIM	MAP inexistente
Dados não chegam	RECEIVE errado

---

🎓 Guia de Estudo Rápido

1. Entenda MAPSET vs MAP

2. Crie tela simples

3. Compile e gere copybook

4. Faça SEND

5. Faça RECEIVE

6. Trate MDT

7. Otimize

---

💬 Comentário El Jefe Midnight Lunch

“Quem domina BMS, domina o ritmo do CICS.”

---

🏁 Conclusão Bellacosa

Tela CICS não é UI.
É contrato, estado e performance.

🔥 Quem respeita o BMS:

• evita ABEND

• entrega rápido

• sobrevive em produção

 

🧠🔥 O Mainframer do Século XXI: sobrevivente, arquiteto e tradutor de mundos

---

02:17 — Prólogo: o profissional que já foi dado como extinto

Se você perguntar para um recruiter distraído, ele dirá:

“Mainframe é legado.”

Se você perguntar para o sistema financeiro mundial, ele responde:

“Sem ele, nada abre.”

O mainframer do século XXI não é um fóssil.
Ele é um sobrevivente técnico, um arquiteto silencioso e, acima de tudo, um tradutor entre mundos.

---

1️⃣ História curta de uma profissão longa 🕰️

• Anos 70–80: operador, JCL, respeito ao batch

• Anos 90: analista, CICS, DB2, MQ

• Anos 2000: integração, web, SOA

• Anos 2010: APIs, eventos, cloud

• Hoje: core engineer + distributed architect

😈 Easter egg histórico:
Quem aprendeu CICS antes de REST já entendia request/response melhor que muito dev moderno.

---

2️⃣ Sobrevivente: por que o mainframer ainda está aqui 🧱

Ele sobreviveu porque:

• Aprendeu a respeitar estado

• Desconfiou de “eventual”

• Nunca romantizou falha

• Tratou produção como território sagrado

📌 Tradução Bellacosa:
Enquanto outros aprendiam com outage, o mainframer evitava que eles existissem.

---

3️⃣ Arquiteto: quando aplicações viraram distribuídas 🧩

Aplicações distribuídas trouxeram:

• Falha parcial

• Latência

• Observabilidade obrigatória

• Orquestração complexa

O mainframer já conhecia:

• Controle transacional

• Limites claros

• Contratos estáveis

• Disciplina operacional

💣 Easter egg:
Two-Phase Commit traumatiza, mas educa.

---

4️⃣ Tradutor de mundos: o papel invisível 🌍

O mainframer moderno traduz:

• Cloud → Core

• Stateless → Stateful

• Velocidade → Consistência

• Experimento → Produção

Ele explica:

“Não é que não dê para fazer.
É que não dá para fazer assim.”

---

5️⃣ Passo a passo: mentalidade distribuída para mainframers

1️⃣ Aceite falha parcial
2️⃣ Desacople sem perder controle
3️⃣ Publique eventos, não segredos
4️⃣ Trate APIs como contratos legais
5️⃣ Observe tudo
6️⃣ Documente o óbvio
7️⃣ Nunca confie só no retry

🔥 Dica Bellacosa:
Retry sem idempotência é só negação organizada.

---

6️⃣ Conhecimento básico essencial (sem modinha) 📚

Conceitos

• CAP Theorem

• Event-driven architecture

• Observabilidade

• Resiliência

• SRE

• Arquitetura híbrida

Ferramentas

• MQ / Kafka

• APIs

• z/OS Connect

• Instana / APM

• CI/CD no z/OS

---

7️⃣ Curiosidades que só mainframer percebe 👀

• “Alta disponibilidade” sempre foi requisito

• Segurança nunca foi opcional

• Batch quebrado ensina humildade

• Produção não é laboratório

😈 Easter egg:
Quem já leu SMF em hexadecimal entende logs distribuídos sem chorar.

---

8️⃣ Guia de estudo prático 🗺️

Para evoluir sem perder identidade

• Estude arquitetura, não frameworks

• Entenda cloud sem romantizar

• Aprenda a dizer “não” com argumentos

• Leia post-mortems

• Observe sistemas reais

📌 Mantra:
Tecnologia muda. Fundamentos não.

---

9️⃣ Aplicações reais desse perfil 💼

• Arquitetura corporativa

• Core banking

• Integrações críticas

• Governança técnica

• Modernização sem suicídio operacional

🎯 Mercado:
Quem entende mainframe e distribuído não fica desempregado.
Fica sobrecarregado.

---

🔟 Comentário final (03:02 — tudo verde)

O mainframer do século XXI:

• Não nega o passado

• Não idolatra o futuro

• Não quebra produção por hype

Ele conecta eras.

🖤 El Jefe Midnight Lunch encerra assim:
“Enquanto uns discutem se o mainframe morreu, ele segue processando o mundo.”

 

 

☁️🔥 Mainframe não morreu: ele só aprendeu a falar cloud

---

00:59 — Introdução: o boato da morte que nunca se confirmou

Toda década alguém decreta:

“Agora o mainframe acabou.”

E toda década o mainframe responde do mesmo jeito:

processando mais transações, com menos falha, mais segurança e menos barulho.

O que mudou não foi o mainframe.
Foi o jeito de conversar com o mundo.

Aplicações distribuídas não mataram o mainframe.
Elas forçaram o mainframe a virar poliglota.

---

1️⃣ Um pouco de história: do green screen à nuvem ☁️

• Anos 60–80: centralização total, terminais burros

• Anos 90: client-server, CICS como backbone

• Anos 2000: web, SOA, serviços expostos

• Anos 2010: cloud, APIs, eventos

• Hoje: mainframe como core cloud-ready

😈 Easter egg histórico:
CICS sempre foi serverless. Só não tinha marketing.

---

2️⃣ O mito: cloud substitui mainframe 🧠

Cloud é ótima para:

• Elasticidade

• UX

• Experimento rápido

• Carga variável

Mainframe é imbatível em:

• Consistência

• Segurança

• Throughput

• Custo por transação estável

📌 Tradução Bellacosa:

“Cloud corre. Mainframe sustenta.”

---

3️⃣ O que significa “falar cloud” no mainframe

Não é migrar tudo.
É integrar de forma inteligente.

Significa:

• Expor transações como APIs

• Publicar eventos

• Integrar via mensageria

• Ser observado como qualquer serviço moderno

• Participar de pipelines distribuídos

😈 Easter egg:
Quem já integrou CICS com MQ já estava no caminho.

---

4️⃣ Aplicações distribuídas: onde o mainframe entra 🧩

Em arquiteturas modernas:

• Frontend → cloud

• Backend → microservices

• Core → mainframe

O mainframe vira:

• System of Record

• Fonte de verdade

• Pilar de consistência

📎 Mainframer entende:
O dado crítico mora onde sempre morou.

---

5️⃣ Passo a passo para tornar o mainframe cloud-friendly

1️⃣ Identifique o core estável
2️⃣ Exponha capacidades (não tabelas)
3️⃣ Use APIs ou eventos
4️⃣ Evite acoplamento síncrono excessivo
5️⃣ Adicione observabilidade
6️⃣ Trate segurança como prioridade
7️⃣ Evolua sem big bang

💣 Dica Bellacosa:
Modernizar não é reescrever. É orquestrar.

---

6️⃣ Ferramentas que fazem o mainframe falar cloud 🛠️

• CICS Web Services / APIs

• IBM MQ

• z/OS Connect

• Kafka integration

• Instana / observabilidade

• CI/CD para z/OS

😈 Easter egg:
JCL em pipeline CI/CD assusta mais dev cloud do que dump hex 😈

---

7️⃣ Guia de estudo para mainframers do futuro 📚

Conceitos

• Aplicações distribuídas

• APIs

• Event-driven

• Observabilidade

• Resiliência

• Segurança zero trust

Habilidades

• Pensar em fluxo

• Aceitar falha parcial

• Trabalhar com times cloud

• Defender o core com argumentos técnicos

---

8️⃣ Aplicações práticas no mundo real

• Bancos digitais

• Fintechs

• Seguros

• Governo

• Telecom

🎯 Mainframer que fala cloud vira arquiteto indispensável.

---

9️⃣ Curiosidades que só veterano percebe 👀

• Mainframe já era multi-tenant

• Isolamento sempre foi nativo

• Segurança nunca foi opcional

• Disponibilidade sempre foi requisito

📌 Verdade inconveniente:
A cloud ainda está aprendendo o que o mainframe já domina.

---

🔟 Comentário final (01:43, sistema estável)

Mainframe não morreu.
Ele só parou de pedir licença.

Hoje ele:

• fala API,

• publica eventos,

• participa de cloud,

• sustenta o impossível.

Se você já:

• Defendeu o core contra modinha

• Integrau legado com futuro

• Entendeu que estabilidade é poder

Então você sabe:

🖤 El Jefe Midnight Lunch encerra com respeito:
O futuro é distribuído. O coração continua central.

CICS Multi Tasking versus Multi Threading no Mainframe

🔥 Multi Tasking vs Multi Threading no Mainframe CICS

 

---

☕ Midnight Lunch, 500 usuários logados e o CICS impassível

13h11.
Fila cheia no atendimento.
Centenas de usuários pressionando ENTER ao mesmo tempo.
E o CICS… tranquilo. 😎

Alguém novo pergunta:

“Isso é multi-threading, né?”

O veterano sorri, toma um gole de café e responde:

“Não. Isso é multi-tasking de verdade.”

Vamos acertar essa confusão de uma vez por todas.

---

🏛️ História: concorrência antes de virar buzzword

Muito antes de:

• Java threads

• pthreads

• containers

• Kubernetes

o mainframe já executava milhares de unidades de trabalho simultâneas.

O CICS nasceu para isso:

• Processar milhares de transações

• Compartilhar recursos

• Garantir integridade

📌 Concorrência não é novidade. É herança.

---

🧠 Conceito essencial (guarde isso)

Multi-tasking = várias tarefas concorrentes
Multi-threading = vários fluxos dentro de uma tarefa

No CICS, isso muda tudo.

---

🔄 O que é Multi-Tasking no CICS?

Definição

Multi-tasking é a capacidade do CICS de:

• Executar múltiplas tasks (transações) ao mesmo tempo

• Cada uma com seu próprio contexto

• Compartilhando a mesma região

Cada ENTER do usuário = uma task CICS.

---

Características

✔ Cada task é independente
✔ Isolamento de contexto
✔ Escalonamento pelo dispatcher
✔ Altíssima escalabilidade

📌 O CICS vive de multi-tasking.

---

Exemplo mental Bellacosa

1000 usuários → 1000 tasks
Cada uma:

• Seu COMMAREA/CHANNEL

• Seus locks

• Seu tempo de CPU

🔥 Tudo rodando em harmonia.

---

🧵 O que é Multi-Threading no CICS?

Definição

Multi-threading é quando:

• Um mesmo programa pode ser executado

• Simultaneamente

• Por várias tasks

📌 Atenção:
No CICS, thread ≠ task como no mundo distribuído.

---

Como o CICS lida com isso?

• Programas devem ser reentrantes

• Não podem depender de storage estático

• Precisam ser “thread-safe”

📌 O CICS não cria threads. Ele compartilha programas.

---

🥊 Task vs Thread (comparação raiz)

Conceito	Task (CICS)	Thread (conceito geral)
Unidade	Transação	Fluxo interno
Controle	CICS Dispatcher	Runtime
Isolamento	Alto	Médio
Uso	Usuários	Execução interna

📌 Confundir task com thread é erro de formação.

---

🧠 Reentrância: o coração do multi-threading no CICS

O que é?

Um programa reentrante:

• Pode ser executado por várias tasks

• Ao mesmo tempo

• Sem interferência

Regras de ouro

✔ Nada de storage estático mutável
✔ Use WORKING-STORAGE dinâmico
✔ Use COMMAREA / CHANNEL
✔ Trate recursos compartilhados

📌 Programa não reentrante em CICS é bomba relógio.

---

⚠️ Erros clássicos (easter eggs)

🐣 Variável global alterada
🐣 WORKING-STORAGE assumido como exclusivo
🐣 TSQ compartilhada sem controle
🐣 READ UPDATE segurando lock
🐣 “Funciona em teste, quebra em carga”

📌 Todo bug concorrente nasce aqui.

---

🛠️ Passo a passo Bellacosa (como pensar concorrência)

1️⃣ Cada usuário = uma task
2️⃣ Programas são compartilhados
3️⃣ Dados nunca são exclusivos
4️⃣ Locks devem ser mínimos
5️⃣ Storage deve ser limpo

📌 Concorrência se projeta, não se improvisa.

---

📚 Guia de estudo para mainframers

Domine estes tópicos:

• CICS Task lifecycle

• Dispatcher e TCBs

• Program reentrancy

• Storage management

• ENQ/DEQ

📖 Manual essencial: CICS Application Programming Guide

---

🤓 Curiosidades de boteco mainframe

🍺 CICS roda milhares de tasks em um único endereço
🍺 “Thread-safe” nasceu no mainframe
🍺 Programas não reentrantes já derrubaram regiões
🍺 Java copiou conceitos do CICS sem admitir

---

💬 Comentário El Jefe Midnight Lunch

“O mundo descobriu concorrência.
O mainframe sempre viveu dela.”

---

🚀 Aplicações reais hoje

• Core bancário

• Sistemas de pagamento

• Governo

• Seguradoras

• Ambientes híbridos (CICS + APIs)

---

🎯 Conclusão Bellacosa

No CICS:

• Multi-tasking é nativo

• Multi-threading é disciplina

• Reentrância é obrigatória

🔥 Concorrência não é luxo. É fundamento.