Bellacosa Mainframe estudo do caso CPU Explodindo

💥 DB2 - CENÁRIO: CPU EXPLODINDO EM PRODUÇÃO

🧪 Situação

• Batch rodando há anos
• De repente: ⬆ CPU / ⬆ elapsed time
• Usuários reclamando
• SLA estourando

---

⚠️ QUERY PROBLEMÁTICA

SELECT *
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

💣 SINTOMAS

• CPU alto 🔥
• Long elapsed time
• I/O elevado
• Threads presas

---

🔍 PASSO 1 — EXPLAIN (descobrindo o vilão)

👉 Você roda EXPLAIN e vê:

ACCESSTYPE = R (TABLE SCAN)
METHOD = 1 (Nested Loop)
MATCHCOLS = 0

---

🧠 DIAGNÓSTICO

💥 Problemas identificados:

1. Sem índice em C.CIDADE
2. Join usando nested loop pesado
3. Alto volume de leitura
4. SELECT * (puxa dados desnecessários)

---

🚨 CAUSA REAL DO CPU ALTO

👉 Db2 está:

• Varredura completa (scan)
• Fazendo join linha a linha
• Lendo MUITO mais dados que precisa

💡 Tradução:

Está trabalhando demais pra responder pouco

---

🚀 PASSO 2 — CORREÇÃO (TUNING REAL)

🔹 1. Criar índice estratégico

CREATE INDEX IDX_CLIENTES_CIDADE
ON VAGNER.CLIENTES (CIDADE);

---

🔹 2. Índice para JOIN

CREATE INDEX IDX_PEDIDOS_CLIENTE
ON VAGNER.PEDIDOS (CLIENTE_ID);

---

🔹 3. Evitar SELECT *

SELECT P.ID, C.NOME
FROM VAGNER.PEDIDOS P
JOIN VAGNER.CLIENTES C
  ON P.CLIENTE_ID = C.ID
WHERE C.CIDADE = 'SAO PAULO';

---

🔹 4. Atualizar estatísticas

RUNSTATS TABLESPACE VAGNER.TSCLIENTES;
RUNSTATS TABLESPACE VAGNER.TSPEDIDOS;

---

🔁 PASSO 3 — NOVO EXPLAIN

Agora você vê:

ACCESSTYPE = I
MATCHCOLS > 0
METHOD = melhor otimizado

---

📊 RESULTADO REAL

Métrica	Antes	Depois
CPU	🔥 Alto	⚡ Baixo
Tempo	🐢 Lento	🚀 Rápido
I/O	Alto	Reduzido

---

💣 OUTROS CENÁRIOS DE CPU ALTO (VIDA REAL)

⚠️ 1. Falta de filtro

SELECT * FROM PEDIDOS;

👉 Scan total = CPU alto

---

⚠️ 2. Função no WHERE

WHERE UPPER(NOME) = 'ANA'

👉 Índice ignorado 😬

---

⚠️ 3. OR mal usado

WHERE CIDADE = 'SP' OR CIDADE = 'RJ'

👉 Pode quebrar índice

---

⚠️ 4. RUNSTATS desatualizado

👉 Otimizador toma decisão ruim

---

⚠️ 5. Índice errado

👉 Existe… mas não ajuda

---

🧠 CHECKLIST DE INCIDENTE (use isso na guerra)

Quando CPU subir:

✔ Rodar EXPLAIN
✔ Ver ACCESSTYPE
✔ Checar índices
✔ Ver RUNSTATS
✔ Analisar SELECT *
✔ Avaliar volume de dados

---

🔥 FERRAMENTAS QUE AJUDAM

• EXPLAIN / PLAN_TABLE
• IFCID 316 (performance)
• Monitor tipo OMEGAMON
• Accounting traces

---

😎 FRASES DE QUEM RESOLVE INCIDENTE

• “Isso tá fazendo tablespace scan”
• “O access path mudou”
• “Faltou índice nesse predicado”
• “RUNSTATS tá velho”

---

💥 MENTALIDADE FINAL

👉 CPU alto no Db2 quase nunca é “o mainframe lento”

👉 Normalmente é:

✔ SQL ruim
✔ Índice errado
✔ Estatística desatualizada

💥 Db2 13 – Introduction (Guia Completo)

 

Bellacosa Mainframe apresenta Db2 13

💥 Db2 13 – Introduction (Guia Completo)

O IBM Db2 13 for z/OS não é só uma evolução… é praticamente um “upgrade de mentalidade” no mundo mainframe. Ele traz automação, performance absurda e inteligência embutida — e é exatamente isso que costuma cair nesse tipo de teste.

Vou te dar o mapa mental + respostas comentadas no estilo prova 👇

---

🧠 1. O que é o Db2 13?

👉 Resposta esperada:
Um sistema gerenciador de banco de dados relacional (RDBMS) para z/OS.

💡 Na prática:

• Armazena dados de forma estruturada (tabelas)
• Usa SQL como linguagem padrão
• Integra profundamente com CICS, batch, IMS

---

⚙️ 2. Principais melhorias do Db2 13

👉 Fique esperto — isso cai MUITO:

🔥 Destaques:

• AI-powered optimization (auto tuning)
• Melhor uso de CPU (redução de MIPS 💰)
• Maior throughput (mais transações por segundo)
• Melhor compressão de dados
• Processamento contínuo (menos downtime)

👉 Resposta típica:

Improved performance, scalability, and AI-driven optimization.

---

🧩 3. Continuous Delivery (CD)

👉 Conceito chave!

👉 Resposta:
Modelo de entrega contínua de funcionalidades sem precisar fazer upgrade completo.

💡 Tradução Bellacosa:

Você não precisa mais “parar o avião pra trocar o motor”.

---

📊 4. Tipos de objetos no Db2

👉 Isso aparece em matching / drag-and-drop:

• TABLE → armazena dados
• VIEW → visão lógica
• INDEX → melhora performance
• TABLESPACE → armazenamento físico
• SCHEMA → organização lógica

👉 Dica de prova:
Se falou “logical representation” → é VIEW

---

⚡ 5. SQL no Db2

👉 Clássico:

• DDL → CREATE, ALTER, DROP
• DML → INSERT, UPDATE, DELETE
• DCL → GRANT, REVOKE

👉 Pergunta comum:

CREATE é usado para quê?

✔️ Criar objetos

---

🔐 6. Segurança

👉 Db2 trabalha junto com o RACF

• Controle de acesso
• Autorização por usuário
• Proteção de dados sensíveis

---

🚀 7. Performance

👉 O Db2 13 brilha aqui:

• Buffer pools otimizados
• Melhor uso de memória
• Menos CPU por transação

👉 Resposta típica:

Improved efficiency and reduced resource consumption.

---

🧪 8. Perguntas clássicas de prova (com resposta)

❓ Db2 é:

✔️ Um RDBMS

---

❓ SQL é usado para:

✔️ Manipular e definir dados

---

❓ Continuous Delivery significa:

✔️ Entrega contínua de funcionalidades sem upgrade tradicional

---

❓ INDEX serve para:

✔️ Melhorar performance de acesso

---

❓ VIEW é:

✔️ Uma tabela lógica baseada em SELECT

---

❓ CREATE é:

✔️ Comando DDL

---

💣 Dica de OURO (nível sênior)

Se cair pergunta conceitual mais “maldosa”, pensa assim:

👉 Db2 13 =
Menos custo + mais performance + mais automação + menos intervenção humana

---

🧠 Mentalidade que passa na prova

Não decore só comando — entenda o porquê:

• Db2 não é só banco → é motor transacional do core banking
• Performance = dinheiro
• CPU = custo direto
• Índice mal feito = desastre silencioso

A primeira de muitas mortes do COBOL

 

Um Café no Bellacosa Mainframe

2,167 subscribers

A primeira morte do COBOL

Bellacosa Mainframe

4,424 followers

July 26, 2025

Salve jovem padawan no artigo de hoje, relembrarei um causo hilario, algo que durante 20 anos perturbou e provocou as pessoas envolvidas no CODASYL 1959. Comitê que originou e desenvolveu o COBOL.

Segunda as histórias de bastidores, o desenvolvimento da Linguagem de Programação COBOL, foi uma guerra infernal, imagine juntar diversas empresas de Mainframe, que se degradiavam insanamente pela cota de mercado, numa época em que a frase padrão era o "Meu é Maior", melhor, mais rápido, mais barato, mais isso e mais aquilo.

Os contratos eram draconianos e as empresas que contratavam serviços informáticos eram obrigadas a comprar hardware e software do mesmo fabricante, que o código não era portável, os dados necessitavam de serem tratador para migrar entre equipamentos e acabam vitimas presos a determinado fornecedor.

Nestes caos que foram os primeiros anos da Informatica na década de 40 e 50 do seculo passado. O Governo americano, vendo que parte de seu orçamento ser consumido em Tecnologia, resolveu agir e convocou a todos. Dete chamado surgiu o CODASYL, onde o todos os envolvidos queriam um padrão, uma linguagem de programação fácil de entender e rápida de aprender.

Diferente de até então onde o Assembly e Linguagem de Máquina dominavam e raras outras linguagens tentavam angariar novos programadores, como exemplo havia o Fortran e o Flow-Matic. O nirvana desejado seria um lugar, onde não engenheiros eletrônicos pudessem trabalhar, e transformar dados comerciais em informação lucrativas, onde com um certo grau de liberdade, podemos comparar com o MS Excel dos nossos dias.

Esse era o cenário em 1959, ano em que os melhores se reuniram e durante um ano trabalhando ora juntos, ora cada um por si, criaram a lendária LP COBOL de Terceira Geração. Mas nem tudo foram flores, egos foram feridos, sabotadores tentaram acabar com a linguagem recém nascida. Como sabemos, falharam redondamente.

Voltando a historia,Charles A. Phillips o presidente do comitê Codasyl em fevereiro de 1960 recebe via correio, uma estranha caixa, ao abrir, se surpreende com o conteúdo, uma pessoa anonima enviou uma Lápide do COBOL.

Phillips que tinha como lema [não dobre, não enrole nem mutile!] levou o projeto a bom porto e conseguiu agradar a gregos e troianos. Num prazo recorde o mundo começou a linguagem de programação que revolucionou a informatica.

Levou 20 anos para descobrir quem havia sido o Troll, o gozador que havia comprado e enviado a lapide ao Codasyl. Fora um dos membros, um dos participantes da esfera civil-comercial: Howard Bromberg, na época funcionário da RCA, que despeitado e nao acreditando no sucesso da empreitada, gorou e vaticinou a morte prematura do COBOL, sendo o primeiro de muitos a fazê-lo, sem sucesso.

Então o gozão com meia culpa se desculpou e confessou estar admirado que em 1985, passado 25 anos o COBOL dominava o mercado, imagine se ele fosse vivo hoje e testemunhasse os 65 anos do Cobol.

Os primórdios da computação foram cheios de grandes personagens, homens e mulheres que trabalharam duro para criar um mundo novo, pensando fora da caixa, lutando para transformar o mundo.

Eu em 2024 só posso agradecer a todos esses gigantes, que abriram e pavimentaram a estrada onde já dediquei 35 anos da minha vida.

Muito obrigado

 

Bellacosa Mainfrae e os principais erros no cics e suas possiveis soluções

Um Café no Bellacosa Mainframe

2,167 subscribers

Principais Erros do CICS e Suas Possíveis Soluções

Bellacosa Mainframe

4,424 followers

July 24, 2025

Salve jovem padawan, na aula de hoje, entre muitos abends da transação de teste no CICS de desenvolvimento, fiquei pensativo em como ajudar minha turma, deste pensamento, após um loop que quase derrubou o CICS, mapset faltante, conteiner inexistente, erro de logica na navegação. Resolvi criar um mini tour, sobre os erros mais comuns e possiveis soluções.

Introdução

O CICS (Customer Information Control System) é um monitor de transações extremamente robusto e confiável, amplamente utilizado em ambientes corporativos com mainframes IBM. No entanto, como qualquer sistema complexo, ele pode gerar mensagens de erro que desafiam até os analistas mais experientes. Muitas vezes bugs simples, que causam grande dor de cabeça ao iniciante.

Neste artigo, vamos explorar os principais erros do CICS, o que significam, e como resolvê-los de forma prática. Se você é um dos alunos da formação, ira se recordar destes erros ocorridos na aula. Nosso trabalho de Analista de Sistemas e isso, sermos os Freuds do Sistema Z, identificando os erros e corrigindo, num trabalho de idas e vindas, com muita reviravolta.

---

🔧 1. APCT (Program Not Found)

🛑 Erro:

DFHAP0001 CICSTRN Transaction abended with abend code APCT.

📌 Causa:

O programa especificado na transação não foi encontrado ou não foi definido no CICS (via RDO ou CSD).

✅ Soluções:

• Verifique se o programa foi definido corretamente via RDO (CEDA) ou no DFHCSD.
• Confira se o programa foi link-editado como reentrant.
• Assegure que o LOADLIB onde o programa reside esteja no DFHRPL.

---

🔧 2. AEI0 (Map Not Found)

🛑 Erro:

DFHAC2001 CICSTRN Transaction abended with abend code AEI0.

📌 Causa:

O mapa solicitado com o comando EXEC CICS SEND MAP não foi encontrado.

✅ Soluções:

• Verifique se o mapa foi montado e link-editado corretamente.
• Certifique-se de que o mapa está presente na biblioteca mapset associada ao CICS.
• Use o comando CEDA DISPLAY MAPSET(...) para validar se o mapset está definido no CICS.

---

🔧 3. AEY9 (DB2 Not Available)

🛑 Erro:

DFHAC2001 CICSTRN Transaction abended with abend code AEY9.

📌 Causa:

Erro relacionado ao DB2, geralmente porque:

• O DB2 está inativo;
• A thread não está alocada corretamente;
• A autorização RACF está faltando.

✅ Soluções:

• Verifique o status da conexão DB2/CICS com DSNC DISPLAY THREAD.
• Certifique-se de que o usuário da transação tem permissão RACF para acessar o plano do DB2.
• Verifique se o recurso está definido com o parâmetro correto no RDO (DB2ENTRY, DB2TRAN).

---

🔧 4. AEIP (Security Violation)

🛑 Erro:

DFHAC2001 CICSTRN Transaction abended with abend code AEIP.

📌 Causa:

Violação de segurança – usuário sem permissão para a transação, recurso, ou dataset.

✅ Soluções:

• Analise o log do RACF (SMF 80 ou comandos SEARCH CLASS(...)) para identificar a violação.
• Verifique as regras no RACF para a transação (TCICSTRN, PROGRAM, DATASET, etc).
• Utilize RACFIND ou RACROUTE para testes com permissões temporárias.

---

🔧 5. AEZC (Web Service Error)

🛑 Erro:

DFHAC2001 CICSTRN Transaction abended with abend code AEZC.

📌 Causa:

Erro durante invocação ou resposta de um CICS Web Service.

✅ Soluções:

• Verifique os arquivos PIPELINE e as definições de WEBSERVICE.
• Analise os logs do SIT (System Initialization Table) para mensagens associadas ao WS.
• Revise o SOAPMessage para erros de XML/SOAP malformado.

---

🔧 6. ASRA (Program Check - ABEND 0Cxx)

🛑 Erro:

DFHAC2206 CICSTRN Transaction abended with abend code ASRA.

📌 Causa:

Erro de execução em linguagem de programação (COBOL/PLI) – divisão por zero, index inválido, etc.

✅ Soluções:

• Execute um TRACE ou veja o auxiliary trace para identificar o ponto de falha.
• Compile com TEST ou NOSSRANGE e utilize um debugger como CEEDUMP ou CEDF.
• Avalie o uso de variáveis não inicializadas ou ponteiros incorretos.

---

🔧 7. AEIM (Invalid Request)

🛑 Erro:

DFHAC2001 CICSTRN Transaction abended with abend code AEIM.

📌 Causa:

Comando CICS inválido para o contexto (ex: RECEIVE fora de uma transação terminal).

✅ Soluções:

• Revise a lógica do programa. Alguns comandos devem estar dentro de contexto apropriado.
• Habilite CEDF para debug em tempo real da transação.

---

Extras: Outras Mensagens Comuns e Dicas

AEIO
Terminal indisponível
Use CEMT I TERM(...) para verificar o status

AEYD
Erro ao iniciar DB2
Reanalise parâmetros DB2ENTRY

AICA
Loop detectado no programa
Confirme presença de comandos EXEC CICS RETURN

ASRB
Interrupção por usuário (ex: ATTN)
Pode indicar travamento

Erros cics

---

Conclusão

Não entre em panico, os erros no CICS fazem parte do dia a dia de qualquer analista mainframe. A chave é entender o contexto do abend, dominar ferramentas como CEDF, CEEDUMP, CEDA, CEMT e manter boas práticas de logging e rastreamento.

Por isso é importante testar, fazer um check-list dos elementos a serem criados no CEDA, verificar a Instalação dos mesmo, usar o CEMT para atualizar as novas versões do executavel.

Ter muita, mas muita paciência, regados a café e no pior cenário, levante-se da cadeira, vá caminhar um pouco, relaxe e a solução surgirá na mente. Quando estiver muito difícil, consulte o manual da IBM, converse com colegas e chame o professor. Juntos iremos mais longe.

💡 Dica de ouro:

Mantenha uma tabela interna de erros recorrentes no seu ambiente, com soluções testadas e links de documentação. Isso acelera o diagnóstico e reduz o retrabalho.