Translate

Mostrar mensagens com a etiqueta Debugging. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Debugging. Mostrar todas as mensagens

domingo, 29 de março de 2026

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI! O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀

 

Bellacosa Mainframe fala sobre z/OS system Service Structure

🔥 VOCÊ USA z/OS TODO DIA… MAS NUNCA VIU ISSO AQUI!
O “ESQUELETO INVISÍVEL” DO SYSTEM SERVICES QUE DECIDE SEU JOB VIVE OU MORRE 💀


Se você é dev COBOL raiz, daqueles que já tomou S0C7 no café da manhã e resolveu com dump na unha… segura essa:

👉 Existe uma camada no z/OS que você usa o tempo todo…
👉 Mas quase ninguém entende de verdade…
👉 E ela decide TUDO — do I/O ao ABEND.

Bem-vindo à z/OS System Services Structure.


🧠 O QUE É ESSA TAL DE STRUCTURE?

Pensa no z/OS como uma cidade:

  • Você (COBOL) → é o cidadão
  • JCL → é o pedido formal
  • JES2 → é o correio
  • E o System Services?
    👉 É a prefeitura, polícia, energia, trânsito e bombeiros… TUDO JUNTO.

É a estrutura que fornece serviços fundamentais como:

  • Gerenciamento de tarefas (Task Management)
  • Comunicação entre programas
  • Gerenciamento de memória
  • I/O (entrada/saída)
  • Tratamento de erros (ABENDs 👀)

⚙️ A ESTRUTURA NA PRÁTICA (SEM MIMIMI)

Aqui entra o coração técnico que muita gente ignora:

🔹 Control Blocks (os “documentos secretos”)

  • TCB (Task Control Block) → representa uma task
  • ASCB (Address Space Control Block) → representa o espaço de endereçamento
  • RB (Request Block) → encadeamento de chamadas

💡 Easter egg:
Se você já viu um dump com “TCB=…” e ignorou…
👉 você literalmente ignorou o “RG” da sua task.


🔹 Dispatcher (o maestro invisível)

  • Decide qual task roda
  • Gerencia prioridade
  • Alterna contexto

💬 Comentário Bellacosa-style:

“Se seu programa está ‘lento’, talvez o problema não seja o COBOL…
é o dispatcher dizendo: calma campeão, tem fila 😎”


🔹 SVC (Supervisor Call)

  • Porta de entrada para serviços do sistema
  • Tudo passa por aqui

👉 Quando seu COBOL faz I/O, quem resolve não é ele…
é o z/OS via SVC.

💡 Curiosidade:
SVC é tipo syscall no Linux… só que com terno e gravata 👔


💥 ONDE ISSO TE PEGA (E VOCÊ NEM SABIA)

Se liga nesses cenários:

  • ABEND estranho sem causa aparente
  • Programa “travando” sem loop
  • I/O lento do nada
  • Problemas intermitentes

👉 90% das vezes… está ligado ao System Services, não ao seu código.


🧩 COMO TUDO SE CONECTA (VISÃO RAIZ)

Fluxo simplificado:

  1. Seu COBOL executa
  2. Precisa de recurso (I/O, memória, etc)
  3. Chama um serviço via SVC
  4. System Services aciona control blocks
  5. Dispatcher decide quando executar
  6. Resultado volta pra sua aplicação

👉 Se algo falhar nesse caminho…
💥 ABEND na sua cara


🧠 GUIA DE ESTUDO (MODO GUERREIRO MAINFRAME)

Se você quer sair do nível “codador” e virar engenheiro de verdade, estude isso:

📚 Ordem sugerida:

  1. Address Spaces (ASID, ASCB)
  2. TCB e SRB
  3. Dispatcher e prioridades
  4. SVCs mais comuns
  5. Gerenciamento de memória (GETMAIN/FREEMAIN)
  6. Dump reading (IPCS)

🧪 Dica prática (ouro puro 💰)

Pegue um dump real e procure:

  • TCB atual
  • PSW
  • Última SVC chamada

👉 Isso é mais valioso que 10 cursos teóricos.


🕵️‍♂️ EASTER EGGS QUE POUCA GENTE SABE

💣 1. COBOL NÃO CONTROLA NADA
Quem controla é o z/OS. Seu programa só pede.


💣 2. ABEND NÃO É ERRO — É DECISÃO
O sistema decidiu parar você.
👉 E sempre tem motivo.


💣 3. TUDO É BLOCO ENCADEADO
z/OS é basicamente um grande “linked list corporativo” 😂


💣 4. PERFORMANCE NÃO É SÓ CÓDIGO
Pode ser prioridade de TCB, dispatching, ou contenção.


🚀 FRASE PRA LEVAR PRA VIDA (E PRO LINKEDIN 😎)

“Quem não entende System Services no z/OS…
não depura problema — só apaga incêndio.”


🔥 CONCLUSÃO (SEM ENROLAR)

Se você:

  • Só olha código COBOL → você vê a superfície
  • Entende System Services → você vê o sistema inteiro

👉 E é aqui que mora a diferença entre:

  • Programador
    vs
  • Especialista em Mainframe

segunda-feira, 28 de julho de 2025

Homenagem a Incrível Grace

 

Bellacosa Mainframe homenageia Grace Hopper

Homenagem a Incrível Grace

4,424 followers

  • #Desperte o potencial
  • #Marketing Digital

Dia 9 - Homenagem a Incrível Grace

Dia 9 - Pesquise e escreva sobre uma inspiração na área de tecnologia e por que essa pessoa é uma inspiração para você.

Homenagem a Grace Hopper

Bem-vindo jovem padawan, hoje irei falar sobre a mestra das mestras Jedi, aquele que foi a mãe de todos os Analistas de Sistemas e programadores, tudo o que fazemos hoje, devemos fazer um agradecimento a esta mulher. Uma programadora impar, a mais famosa DEV da história e como ela ajudou a criar uma das primeiras linguagem de alto nível. Senta que la vem historia.

Num próximo artigo irei falar dos primeiros computadores criados la longe no século XIX e seu complicados programas em linguagem de máquina e cartões perfurados e se não fosse a Grace ainda estávamos com esses cartões.

Introdução

O primeiro computador ou contador foi criado por Hollerith e usava cartões perfurados para funcionar, sendo muito difícil a sua codificação, com a evolução das indústrias e a necessidade de computação os computadores evoluíram drasticamente. Mas um evento obrigou o mundo a automatizar e aumentar a rapidez.

Este evento foi a Segunda Guerra Mundial, mas por que uma guerra necessita de computadores? Primeiro imagine a logística de enviar suprimentos para milhares de soldados em centenas de campos de batalha? Calcular as baixas e os recrutamentos? Pagar os salários?

Um trabalho hoje extinto, mas num passado não tão distante, existiam os computadores humanos, pessoas com grandes habilidades em cálculo, numa época em que calculadoras mecânicas eram caras.

Então uma das suas funções mais importante era o cálculo das tabelas de balísticas. Sim jovem padawan imagine que antigamente os artilheiros e operadores de canhões e baterias de artilharia precisavam de tabelas ou tabuas com cálculos dos alvos, conforme o local onde estavam tinham as coordenadas tipo potencia, angulo e distância.

Imagine-se no meio de uma batalha, aquele caos ninguém terá tempo de calcular corretamente a posição, por isso existiam tabelas pré-calculadas com essa informação.

Nos quartéis existiam centenas de matemáticos nessa tarefa, os melhores eram envolvidos em projetos de espionagem, criando tabelas de criptografia para esconder as mensagens inimigas.

Mas onde entra a admirável Grace nisto tudo?

No esforço de guerra, todo se voluntariaram para lutar e Grace Hopper queria chutar a bunda dos nazistas, deslocando-se ao centro de alistamento da Marinha como voluntaria, porem foi considerada velha para o combate, mas como era professora de Matemática.

Foi convidada para servir na retaguarda, mais precisamente na NAVY RESERVES, afinal ela PHD em matemática, logo foi envolvida nas equipes de computação. Programando no MARK I e participando do projeto UNIVAC I, criando artigos científicos que auxiliaram muito a evolução dos computadores.

UNIVAC

Article content

UNIVAC I (Universal Automatic Computer I)

Um gigante que revolucionou o mundo, era da dimensão de um armário, pesava 13 toneladas e custava entre 1,25 e 1,5 milhões de dólares. Estes são alguns dos fatos mais interessantes sobre o UNIVAC I, o primeiro computador comercial da história entregue ao Departamento do Censo dos Estados Unidos a 31 de março de 1951,

O UNIVAC usava 5 200 válvulas e consumia 125 kW para fazer 1905 operações por segundo, com um clock de 2,25 MHz. O sistema completo ocupava mais de 35 m² de espaço no piso.

Sua memória de mil palavras era armazenada num dispositivo chamado delay line memory, construído com mercúrio e cristais piezoelétricos.

A entrada e saída de informações eram realizadas por uma fita metálica de 1/2 polegada de largura e 400 m de comprimento. Normalmente acompanhados de um dispositivo impressor chamado Uniprinter, que, sozinho, consumia 14 kW.

Article content

Pré-história da Codificação

Neste ambiente de mudança e evolução constante, cada empresa queria que seu equipamento e método fossem o padrão, onde ninguém se entendia e fica difícil a troca de conhecimento.

Nisso a nossa Admirável Grace entra em ação, trabalhando na padronização e criação de melhores praticas no uso do computador. Com esse desafio em mãos, ela criou o FLOW-MATIC (Business Language version 0, abreviado B-0) é a primeira linguagem de programação em alto nível, ou linguagem natural, assemelhada ao inglês.

A Flow-matic foi criada e especificada a partir de 1955 por Grace Hopper no Remington Rand para ser usada no primeiro computador comercial UNIVAC I.

COBOL

O grande trabalho de Grace foi ter iniciado a longa trilha que culminou na especificação da linguagem de programação COBOL que durante mais de 6 décadas dominou o mercado de mainframes e passou aos mini e micros computadores.

Gerações de programadores no mundo inteiro trabalharam unicamente com esta linguagem e ainda hoje milhares de código legado funcionam nos CPDs pelo mundo afora.

Conclusão

Neste pequeno artigo fiz a minha justa homenagem a essa mulher que foi a primeira HACKER do mundo, criou a sua própria linguagem de computador, fez o unboxing do UNIVAC I, chutou a bunda de nazistas trabalhando arduamente em codificação.

Chegou ao mais alto grau de distinção da US NAVY, chegando a almirante e ainda tem um navio navegando com seu nome. Entrou para a história criando inúmeros artigos sobre programação e foi pioneira na solução de bugs informáticos.

Por isso fica meu muito obrigado admirável Grace, fabulosa, fantástica a mãe de todos os DEVS.

Espero ter ajudado. Bom curso a todos.

Article content
Article content

Mais momento jabá, entrevista para a ITV exposição primavera e suas flores, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=IqmW8rWqmx8

Bom curso a todos.


Article content

https://www.linkedin.com/in/vagnerbellacosa/


Article content

https://github.com/VagnerBellacosa/

#Desafio21DiasNaDIO

Article content

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa


domingo, 16 de fevereiro de 2014

💣🔥 GUIA PRÁTICO — DO TERMINAL À PRODUÇÃO: O OPERADOR QUE DOMINA ISPF, TSO, JCL E JES2 NÃO PEDE AJUDA… ELE RESOLVE 🔥💣

Bellacosa Mainframe em um laboratorio pratico TSO ISPF JCL e JES2 

💣🔥 GUIA PRÁTICO — DO TERMINAL À PRODUÇÃO: O OPERADOR QUE DOMINA ISPF, TSO, JCL E JES2 NÃO PEDE AJUDA… ELE RESOLVE 🔥💣

Se você quer sair do “sei mexer” e entrar no nível “sei operar sob pressão”, este é o seu campo de treinamento.

Aqui não tem teoria solta.

👉 Aqui é lab, erro real, diagnóstico e correção — estilo produção.


🧭 VISÃO DO TREINAMENTO

Você vai simular o ciclo completo:

  1. Navegação e produtividade no ISPF
  2. Manipulação de datasets via TSO
  3. Construção e execução de JCL
  4. Debugging real no JES2

Tudo rodando no ecossistema do z/OS com spool via JES2.


🔬 LAB 1 — ISPF NA VELOCIDADE DE PRODUÇÃO

🎯 Objetivo

Eliminar lentidão operacional.

🧪 Exercício

  1. Acesse:
=3.4
  1. Liste datasets com filtro:
SEU.USERID.*
  1. Use comandos de linha:
  • V → visualizar
  • E → editar
  • B → browse

⚡ Desafio Bellacosa

Sem usar mouse mental:

  • encontre um dataset específico em < 10 segundos
  • navegue entre 3 membros sem perder contexto

💡 Insight

Você não está navegando.

👉 Você está executando operações cognitivas.


🔬 LAB 2 — TSO: CONTROLE DE DADOS

🎯 Objetivo

Dominar datasets sem depender de tela.

🧪 Exercício

🔹 Criar dataset

ALLOC DSN('SEU.USERID.TESTE') NEW SPACE(1,1) TRACKS DIR(5) RECFM(F,B) LRECL(80)

🔹 Listar propriedades

LISTDS 'SEU.USERID.TESTE' ALL

🔹 Deletar

DELETE 'SEU.USERID.TESTE'

⚠️ Erro proposital

Tente alocar sem parâmetros corretos.

👉 Veja o erro
👉 Use HELP ALLOC
👉 Corrija


💡 Insight

TSO não é comando.

👉 É infraestrutura sob demanda


🔬 LAB 3 — JCL: O JOB QUE ORQUESTRA TUDO

🎯 Objetivo

Executar um job funcional.

🧪 Exercício

Crie um membro:

//BELLALAB JOB (ACCT),'TESTE',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=SEU.USERID.ARQ.TESTE,
// DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(1,1)),
// DCB=(RECFM=FB,LRECL=80)

▶️ Submeter

SUBMIT

🔍 Verificar saída no JES2

  • SDSF → ST
  • veja status
  • abra output

💡 Insight

IEFBR14 não faz nada…

👉 mas prova que seu JCL faz tudo certo


🔬 LAB 4 — DEBUGGING REAL (O LAB MAIS IMPORTANTE)

🎯 Objetivo

Aprender a errar… e corrigir rápido.


🧪 Cenário com erro

//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=SEU.USERID.ARQ.TESTE,
// DISP=(NEW,CATLG),
// SPACE=(TRK,(1,1))

👉 Falta parâmetro no DISP.


🔥 Tarefa

  1. Submeta o job
  2. Vá no JES2
  3. Abra:
    • JESMSGLG
    • JESJCL
    • JESYSMSG

🧠 Diagnóstico esperado

  • mensagem de erro de alocação
  • falha no catálogo
  • possível RC ≠ 0

🛠️ Correção

Corrigir para:

DISP=(NEW,CATLG,DELETE)

💡 Insight crítico

Quem lê log… domina o sistema
Quem ignora log… vira incidente


🔬 LAB 5 — ANÁLISE PROFISSIONAL DE JOB

🎯 Objetivo

Interpretar execução como operador sênior.


🧪 Checklist

Após execução:

  • RC = 0?
  • dataset foi criado?
  • houve warning?
  • alocação correta?

🧠 Leitura obrigatória

No spool:

  • JESMSGLG → sistema
  • JESJCL → o que foi interpretado
  • JESYSMSG → execução real

💣 Desafio Bellacosa

Pegue um job com erro e responda:

  • Onde falhou?
  • Por quê?
  • Qual impacto?
  • Como evitar?

🧬 LAB EXTRA — SIMULANDO VIDA REAL

🎯 Cenário

Você recebe:

“Job falhou em produção. Corrigir urgente.”


🔥 Procedimento

  1. Identificar job no JES2
  2. Analisar RC
  3. Ler logs
  4. Identificar dataset envolvido
  5. Corrigir JCL ou dado
  6. Reprocessar

💡 Isso é ouro:

👉 velocidade + precisão = operador de elite


🚀 EVOLUÇÃO (PRÓXIMO NÍVEL)

Depois disso, você deve avançar para:

  • Integração com CICS
  • Acesso a DB2
  • Automação com REXX
  • Monitoramento com SDSF avançado

⚠️ ERROS QUE VOCÊ NÃO PODE MAIS COMETER

  • rodar job sem ler output
  • ignorar RC
  • editar dataset em produção sem critério
  • confiar que “deu certo”

💣 FRASE FINAL

“No mainframe, erro não é exceção…
erro é ferramenta de aprendizado — desde que você saiba ler o sistema.”