✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe ensina como encontrar um abend em menos de 60 segundos
🔥 O método de 60 segundos para descobrir por que um Job ABENDOU (sem abrir nenhum dataset)
No dia a dia de produção em IBM z/OS, quando um job ABEND acontece, muitos profissionais iniciantes começam abrindo datasets, dumps ou navegando em dezenas de telas.
Operadores experientes fazem diferente.
Eles usam um método rápido baseado no SDSF que normalmente revela a causa do problema em menos de 60 segundos — muitas vezes sem abrir nenhum dataset.
Este é um dos truques clássicos que circulam em grandes ambientes de produção.
☕ Bem-vindo a mais um Um Café no Bellacosa Mainframe.
🧠 A lógica por trás do método
Quando um job falha, o sistema sempre deixa rastros em três lugares principais:
1️⃣ Status do job
2️⃣ Mensagens do JES
3️⃣ Mensagens do sistema (SYSLOG)
O segredo é seguir a ordem correta.
⚡ Passo 1 — Abrir o SDSF e localizar o Job
Entre no SDSF:
SDSF
Depois vá ao painel de status:
ST
Agora filtre rapidamente:
PREFIX JOBNAME
Exemplo:
PREFIX PAYROLL*
Isso reduz a lista para apenas os jobs relevantes.
🔍 Passo 2 — Identificar rapidamente o ABEND
Na coluna RC / CC / ABEND você verá algo como:
ABEND=S0C7 ABEND=S322 ABEND=SB37
Cada código já indica uma pista importante.
Exemplos clássicos:
ABEND
Significado
S0C7
erro de dados numéricos
S0C4
violação de memória
S322
timeout (tempo excedido)
SB37
falta de espaço em dataset
Mas ainda não sabemos onde aconteceu.
📜 Passo 3 — Usar o “?” do SDSF (o atalho mais poderoso)
Digite ? ao lado do job.
Isso abre imediatamente o Job Output:
JESMSGLG
JESJCL
JESYSMSG
Sem abrir nenhum dataset manualmente.
🎯 Passo 4 — Ir direto ao JESYSMSG
O arquivo JESYSMSG quase sempre contém a causa.
Procure por linhas como:
IEF450I JOBNAME ABENDED S0C7
ou
IEC030I B37-04
ou
CSV031I LIBRARY NOT FOUND
Em muitos casos a causa já aparece claramente aqui.
🔎 Passo 5 — Confirmar no SYSLOG
Agora abra o log do sistema:
LOG
e procure pelo JobID:
FIND JOB12345
Isso mostra mensagens do sistema relacionadas ao job.
Exemplos:
IEC141I DATA SET NOT FOUND
ou
IEF861I STEP TERMINATED DUE TO ERROR
⚡ Resultado: diagnóstico em menos de 60 segundos
Seguindo apenas estes passos:
SDSF ST PREFIX jobname ? JESYSMSG LOG FIND jobid
Normalmente você já descobre:
✔ o step que falhou
✔ o tipo de erro
✔ a mensagem exata do sistema
Sem abrir nenhum dataset manualmente.
🧠 Exemplo real de diagnóstico
Imagine um job que termina assim:
ABEND=SB37
Seguindo o método:
No JESYSMSG aparece:
IEC030I B37-04 ON SYSDA
Diagnóstico imediato:
👉 Dataset ficou sem espaço.
Nenhuma investigação adicional necessária.
💡 A regra de ouro dos operadores experientes
Nos grandes datacenters existe uma regra não escrita:
“Se você abriu dataset antes de olhar o JESYSMSG, começou a investigação do jeito errado.”
80% dos problemas podem ser identificados apenas com SDSF.
☕ Conclusão
O segredo não está em ferramentas complexas.
Está em saber onde olhar primeiro.
Dominar o SDSF significa:
investigar incidentes mais rápido
reduzir tempo de troubleshooting
ganhar confiança em ambientes de produção
E isso separa operadores iniciantes de profissionais experientes no mundo mainframe.
Um olho no passado, dois olhos no futuro: Diagrama de Fluxo de Dados.
Salve jovem padawan, mais uma vez faremos uma viagem no tempo, para os primórdios da informática, onde as grandes ideias surgiram, sementes foram semeadas e gradualmente o sistema foi sendo criado.
O artigo de hoje irei para beber na fonte de dois gigantes Ed Yourdon e Larry Constantine que publicaram na década de setenta o livro Projeto Estruturado de Sistemas. Uma rocha forte que serviu de alicerce para gerações de DEVS e inpirou David Martin e Gerald Estrina a criarem sua ferramenta, mas antes que pergunte-me por que falo deles numa era de orientação a objetos e tanta tecnologia de ponta.
Elementar meu caro Watson, digo padawan, existem milhões de linhas de código legado, inúmeras bases de dados esperando serem preparadas para migração mediante a ETL, a maioria das pessoas que as construíram foram para a reforma e estão curtindo a boa vida de aposentados no Caribe.
Introdução
Quando falamos de migrar software legado, primeiro pensamos nas regras de negócios, abrindo as fontes para extrair a lógica e migrá-la para uma nova ferramenta ou tecnologia, porem uma das áreas que mais engenho necessita são os dados.
O pobre analista se vê, frente a centenas de tabelas e milhões de registros, queries que retornam tuplas e mais tuplas de dados, mas o que serão? Qual a necessidade? Por onde começar? Como funciona? Socorro.
Seus problemas acabaram, existe uma prática oriunda dos laboratórios da IBM e que aqueles dois gigantes ajudaram a refinar, melhorando e servindo de base para outros grandes mestres aprimorarem, estou falando do D.F.D.
O que é D.F.D.?
Eis que surge mais um acrônimo para a louca sopa de letrinhas da informática. Nunca me canso de repetir isso, essa sigla refere-se ao Diagrama de Fluxo de Dados, uma ferramenta que permite conhecer o Sistema, suas fronteiras, seus caminhos críticos, suas comunicações e repositórios de dados.
Mas que raio de ferramenta milagrosa è essa? Uma que serve de mapa, um guia das origens e destinos, possuindo vários níveis de detalhes, partindo do mais genérico até o menor detalhe, sendo uma das suas vantagens a simplicidade, possuindo poucos sinais ajudando a evitar confusões e interpretações fantasiosas.
Normalmente o DFD começa no nível 0, a visão macro descendo ao detalhe nos níveis 1 até o 5. Alguns termos serão obscuros, necessitando serem clarificados num dicionário de dados. Dependendo da instalação e das equipes de mantenimento, dedicarem um tempinho para atualizarem-no.
Usando o Dicionário de Dados
Este documento como o próprio nome diz é um dicionário onde os principais termos e variáveis do Sistema estão armazenadas, num próximo artigo entrarei em maiores detalhes.
Como funciona o DFD?
Seu funcionamento é mais simples do que imaginamos, o pulo do gato dos seus criadores foi a simplicidade, poucos símbolos, poucas regras. Martin & Estrin sabiam que quanto mais complexidade, menos utilizado, muitas regras iriam gerar confusão e a sua aceitabilidade seria reduzida.
Existem 4 símbolos que representam todo o conjunto de trabalho.
• entidade externa
um retângulo
• processo
um círculo
• armazenamento de dados
um cilindro retangular
• fluxo de dados
uma flecha
O processo consiste em definir as fronteiras do Sistema, dentro destes limites teremos as Entidades Externas. Que pro sua vez alimentam e recebem informações do Sistema, os Círculos que representam os processos internos de transformação da informação, os Cilindros que armazenam as informações em diversos estados e as flechas que indicam o controle do fluxo do processamento.
Qual a vantagem deste diagrama?
A vantagem é ser de fácil entendimento, onde um usuário do Sistema, mesmo sem possuir nenhum conhecimento de programação, pode ler e entender a origem, o destino, o processo da informação em cada etapa.
O usuário de posse deste MAPA saberá o contexto, onde ele esta e para onde vai, quais os processos alimentam o Sistema. Descobrindo quais manipulações importantes ocorrem na informação antes de ser entregue, podendo inclusive perceber falhas ocultas, afinal ele é o dono da informação e sabe melhor que nos, o real processamento.
O que é um diagrama de Contexto?
O DFD nível 0 também chamado de diagrama de contexto por ser a visão mais macro e geral de todo o Sistema ou Processo. Sua principal missão é apresentar o sistema no mais alto nível, com todos os players envolvidos e limites bem definidos.
Tem que ser claro e de fácil entendimento, apresentando os principais inputs, outputs e processos internos e externos, para o público externo poder conhecer e saber responder às perguntas básicas: O que, onde, porque e quando.
O que significa DFD 0 , DFD 1, DFD 2.etc ?
Esta numeração indica ao leitor o nível de detalhe e grau de aprofundamento do diagrama, partindo do nível 0 o mais geral possível até o nível N explodindo o detalhe ao menor nível.
Atualmente este diagrama esta sendo pouco usado e muitos DEVs desconhecem seu uso, meu artigo tem por objetivo resgatar e apresentar aos leitores os detalhes e auxiliar na documentação dos projetos, melhorando a qualidade do software.
Como usá-la na atualidade?
A maneira mais rápida é rascunhar em lápis e papel, depois convido aos aspirantes a Analistas de Sistemas a conhecerem o MS VISIO, ou qualquer outra das dezenas de ferramentas onlines de elaboração de fluxos de processos.
Não é um processo difícil é facilita enormemente a projetar front-ends, aconselho aos parceiros de UX e UI, a debruçarem-se e conhecerem mais sobre o Diagrama de Fluxo de Dados, recomendação estendidas aos DBAs, afinal conhecer o processo de transformação na raiz, facilita encontrar erros e anomalias.
Um conhecimento importante, guarde sempre em mente, a força de uma corrente é determinada pelo seu elo mais fraco, então conheça o sistema, conheça a origem do dado, descubra suas transformações e seus principais processos.
Regra de ouro do DFD.
Um dado somente deve ser armazenado no sistema se passar por um processo
Não existe dados sem processamento e o armazenamento de dados obrigatoriamente deve ter sempre um fluxo, seja de entrada, seja de saída ou mesmo ambos.
O processamento é o rei, transformando sempre os dados, por isso também obrigatoriamente tem que ter uma entrada e uma saída.
Num DFD todo processo ou vai para outro processo ou um armazenamento de dados.
A informação não surge do nada, todo dado armazenado em um sistema obrigatoriamente deve passar por um processo.
Conclusão
O objetivo deste artigo foi apresentar ao jovem padawan, os conceitos fundamentais sobre o Diagrama de Fluxo de Dados, falar sobre seus símbolos e uso, deixo em aberto a utilização do UML e a evolução em novos diagramas.
A ideia foi resgatar uma ferramenta do passado e comentar sobre os benefícios do seu uso, alertando, claro, que para alguns autores ela está obsoleta e sem vantagens ao DEV do século XXI, o que discordo bravamente. Afinal existem muitos sistemas legados, desenhados sob esta metodologia.
Espero ter ajudado até o próximo artigo.
Mais momento jabá, para distrair um nostálgico vídeo do Natal em Itatiba. Onde inúmeros voluntários percorrem as ruas da cidade distribuindo doces as crianças, fazendo a loucura aos miúdos, saudades eternas do Luizão: o papai Noel de Itatiba que inventou essa divertida festa nos anos 70, visite meu vídeo e veja para onde fui desta vez:https://www.youtube.com/watch?v=oAXwZYdo3d4
