Translate

quinta-feira, 22 de setembro de 2022

Arquitetura Final : El Jefe Midnight Lunch Wiki


Arquitetura Final

                   Blogger XML
                        │
                        ▼
              Conversão para Markdown
                        │
                        ▼
              Bellacosa Knowledge Vault
                  (Obsidian Vault)
                        │
     ┌──────────────────┼──────────────────┐
     │                  │                  │
     ▼                  ▼                  ▼
 Graph View       Busca Instantânea     IA
     │                  │                  │
     ▼                  ▼                  ▼
 Relações         Wikilinks         Melhorias
     │                  │                  │
     └──────────────┬──────────────────────┘
                    ▼
             Exportação WordPress

ETAPA 1 — Fazer backup do Blogger

Baixe o XML completo.

Exemplo:

blog-2026.xml

Nunca trabalhe diretamente sobre ele.

Faça uma cópia.

Backup/
    Blogger.xml

Trabalho/
    Blogger.xml

ETAPA 2 — Converter XML para Markdown

Objetivo:

1 artigo = 1 arquivo .md

Resultado esperado

Vault

    COBOL

        ALTER.md

        PERFORM.md

        CICS.md

    IA

        Agentes.md

        MCP.md

    LinuxONE

    Kubernetes

    Docker

    DevOps

Cada postagem vira um Markdown.


ETAPA 3 — Instalar o Obsidian

Criar um Vault chamado

Bellacosa Mainframe Vault

Estrutura recomendada

Vault

00 Inbox

01 Artigos

02 Imagens

03 Fontes

04 Templates

05 Projetos

06 Pessoas

07 Empresas

08 Cursos

09 Rascunhos

10 Publicados

99 Lixeira

ETAPA 4 — Organizar por assunto

Ao invés de datas, organize por conhecimento.

Exemplo

COBOL

CICS

IMS

JCL

VSAM

DB2

REXX

Assembler

LinuxONE

IBM Z

OpenShift

Docker

Kubernetes

Cloud

IA

Machine Learning

Anime

Star Trek

DevOps

Segurança

Observabilidade

Muito mais fácil de pesquisar.


ETAPA 5 — Padronizar FrontMatter

Todo artigo começa assim:

---
title: Docker sem Mistérios
author: Vagner Bellacosa
date: 2026-07-15
category: Docker
tags:
   - docker
   - containers
   - devops
seo:
   description: Guia Docker
status: publicado
blog: Bellacosa Mainframe
---

Depois vem o texto.


ETAPA 6 — Criar Wikilinks

Ao invés de links comuns

Docker

vira

[[Docker]]

[[Kubernetes]]

[[OpenShift]]

[[DevOps]]

[[IBM Z]]

Automaticamente nasce uma rede.


ETAPA 7 — Criar páginas índice

Exemplo

COBOL.md

Dentro

# COBOL

## Sintaxe

[[PERFORM]]

[[ALTER]]

[[CALL]]

[[SECTION]]

[[PARAGRAPH]]

## Arquivos

[[VSAM]]

[[QSAM]]

[[ESDS]]

## Banco

[[DB2]]

[[IMS]]

## CICS

[[COMMAREA]]

[[Pseudo Conversacional]]

É literalmente uma Wikipédia.


ETAPA 8 — Instalar Plugins

Dataview ⭐⭐⭐⭐⭐

Transforma notas em banco de dados.

Exemplo

TABLE tags

FROM "01 Artigos"

WHERE contains(tags,"cobol")

Omnisearch ⭐⭐⭐⭐⭐

Busca em milhares de artigos instantaneamente.

Melhor que Windows Search.


Backlinks

Mostra

Quem cita Docker?

Quem cita CICS?

Quem cita ALTER?

Tag Wrangler

Organiza milhares de tags.


Homepage

Cria uma Home bonita.


Calendar

Histórico de produção.


QuickAdd

Automatiza criação de artigos.


Templater ⭐⭐⭐⭐⭐

Cria modelos.

Novo artigo já nasce pronto.


Excalidraw

Diagramas.


Canvas

Mapas mentais.


Local Graph

Fantástico.

Mostra somente os vizinhos do artigo.


ETAPA 9 — Criar Templates

Novo artigo

Título

Resumo

Introdução

História

Como funciona

Arquitetura

Exemplo

Código

Boas práticas

Curiosidades

Easter Egg

Leia também

Links oficiais

Sempre igual.


ETAPA 10 — Criar Tags

Exemplo

#cobol

#cics

#db2

#linuxone

#ibmz

#docker

#cloud

#ia

#anime

#star-trek

#performance

#tutorial

#curso

#segurança

#devops

ETAPA 11 — Criar MOCs (Maps of Content)

Um dos recursos mais poderosos do Obsidian.

Exemplo

MOC - COBOL

↓

Sintaxe

↓

Comandos

↓

Arquivos

↓

Performance

↓

Debug

↓

Boas práticas

↓

Cursos

↓

Artigos

É o índice mestre.


ETAPA 12 — Graph View

Depois de alguns milhares de artigos...

Você verá algo assim.

             COBOL
             ●
          /  |  \
         /   |   \
      CICS DB2 VSAM
       |      |
       |      |
     IMS    SQL
       \      /
        \    /
        IBM Z
          |
      LinuxONE
          |
      OpenShift
          |
       Docker
          |
     Kubernetes
          |
      DevOps
          |
      GitHub

Seu conhecimento vira uma galáxia.


ETAPA 13 — Git

Todo Vault fica dentro de um repositório.

git init

Depois

commit

commit

commit

commit

Nunca perde nada.

Pode voltar anos.


ETAPA 14 — IA

Agora entra o ChatGPT.

Ao abrir um artigo.

Peça

Melhore este artigo.

Adicione 800 palavras.

Inclua curiosidades.

Inclua exemplos.

Explique para um COBOL Padawan.

Crie SEO.

Crie FAQ.

Crie Links Internos.

Crie Tags.

Crie Easter Eggs.

Sugira imagens.

Sugira artigos relacionados.

Encontre informações desatualizadas.

Em minutos o artigo fica muito superior.


ETAPA 15 — Exportar para WordPress

Quando terminar.

Converta Markdown para

WordPress XML

ou

HTML

ou

Gutenberg Blocks

Depois apenas importe.


ETAPA 16 — IA sobre TODO o acervo

Esse é o ponto em que seu projeto se diferencia.

Imagine perguntar:

Onde já expliquei CICS?

ou

Quais artigos falam de RACF?

ou

Liste tudo sobre IA relacionado ao Mainframe.

ou

Quais artigos precisam ser atualizados para IBM z17?

ou

Quais artigos citam Kubernetes mas não mencionam OpenShift?

A IA responde usando todo o seu acervo.


ETAPA 17 — Evolução para um "Bellacosa Mainframe Knowledge Vault"

Depois de consolidado, o Vault deixa de ser apenas um editor de artigos e passa a ser um sistema de conhecimento integrado. Além dos artigos, você pode incluir cursos, apresentações, PDFs, imagens, vídeos, laboratórios, códigos COBOL, scripts REXX, JCLs e links externos, todos interligados por wikilinks e pesquisáveis em segundos.

Resultado esperado

Ao final, você terá uma plataforma com características que vão muito além de um blog:

  • 3.000+ artigos interligados por links semânticos.

  • Pesquisa instantânea em todo o acervo.

  • Visualização em grafo das relações entre os temas.

  • Templates padronizados para novos conteúdos.

  • Versionamento completo com Git.

  • Funcionamento totalmente offline.

  • Integração com IA para revisão, expansão e atualização contínua.

  • Exportação para WordPress, HTML ou outros formatos quando desejar.

Na prática, seu conteúdo deixa de ser uma sequência cronológica de postagens e se transforma em uma enciclopédia técnica viva, onde COBOL, CICS, Db2, IMS, DevOps, IA, LinuxONE, IBM Z e todos os demais assuntos passam a formar uma rede de conhecimento navegável, preservando e valorizando o enorme patrimônio intelectual que você já construiu.


OBSIDIAN https://eljefemidnightlunch.blogspot.com/2022/09/obsidian-sem-misterios-o-guia.html

quarta-feira, 21 de setembro de 2022

Kuro no Shōkanshi : Quando um Programador COBOL Descobre que Trocar Toda a Memória RAM por Mais CPU Parecia uma Excelente Ideia... Até Precisar Fazer Debug da Própria Vida

 

Bellacosa Mainframe apresenta o Kuro no Shokanshi

☕ Um Café no Bellacosa Mainframe 

Kuro no Shōkanshi (黒の召喚士) sem Mistérios

Quando um Programador COBOL Descobre que Trocar Toda a Memória RAM por Mais CPU Parecia uma Excelente Ideia... Até Precisar Fazer Debug da Própria Vida

Os veteranos do mainframe sabem que memória é um recurso precioso. Desde os tempos dos cartões perfurados até os gigantes IBM Z atuais, ninguém em sã consciência abriria mão de informações importantes apenas para ganhar mais desempenho. Mas foi exatamente isso que Kelvin fez. Em Kuro no Shōkanshi (Black Summoner), o protagonista aceita apagar completamente suas memórias em troca de atributos absurdamente elevados. É como executar um DELETE DATASET(*) no próprio cérebro para ganhar um upgrade permanente de processamento.

Para um programador COBOL Padawan, essa parece uma péssima prática de engenharia. Para um herói de isekai... foi o início de uma das aventuras mais divertidas dos últimos anos.


Dados da Obra

  • Título original: 黒の召喚士 (Kuro no Shōkanshi)

  • Título internacional: Black Summoner

  • Autor da Light Novel: Doufu Mayoi

  • Ilustrações: Kurogin (volumes iniciais)

  • Mangá: Gin Ammo

  • Estúdio: Satelight

  • Diretor: Yoshimasa Hiraike

  • Música: Michiru

  • Exibição: 9 de julho de 2022 a 24 de setembro de 2022

  • Temporada: Verão de 2022

  • Quantidade de episódios: 12

  • Origem: Light Novel


Sinopse

Kelvin desperta em um mundo de fantasia sem qualquer lembrança de sua vida anterior.

A responsável por isso é a própria deusa Melfina.

Antes da reencarnação, ele negociou algo extremamente incomum: entregou todas as suas memórias em troca de atributos muito acima do normal.

Agora ele inicia uma nova vida como um Invocador (Summoner), capaz de formar contratos com criaturas, espíritos, monstros e até seres divinos.

Mas existe um pequeno detalhe...

Kelvin possui uma personalidade bastante peculiar.

Ele simplesmente ama enfrentar inimigos absurdamente fortes.

Quanto maior o perigo...

Mais feliz ele fica.


Resumo da História

No início Kelvin trabalha como um aventureiro comum.

Pouco a pouco vai conquistando fama.

Forma alianças.

Constrói uma equipe extremamente poderosa.

Explora masmorras.

Derrota monstros lendários.

Enfrenta reis demônios.

Participa de guerras.

Enquanto isso, seu nível cresce de forma quase absurda graças ao seu talento como Invocador.

A cada episódio seu grupo torna-se mais forte, funcionando praticamente como uma party perfeita de RPG.


O Universo de Black Summoner

O anime utiliza praticamente todos os elementos clássicos dos JRPGs modernos.

Há:

  • Guildas

  • Classes

  • Níveis

  • Skills

  • Evolução

  • Rank de aventureiros

  • Chefes

  • Itens mágicos

  • Espíritos

  • Demônios

  • Dragões

  • Contratos

  • Invocações

  • Magias elementais

Quem já jogou Final Fantasy, Dragon Quest ou MMORPGs como Ragnarok e Final Fantasy XIV reconhecerá imediatamente a estrutura do mundo.


Principais Personagens

Kelvin

O protagonista.

Calmo.

Extremamente inteligente.

Excelente estrategista.

Mas possui um defeito gravíssimo...

É completamente viciado em batalhas difíceis.

Para Kelvin, lutar contra um inimigo impossível é muito mais divertido do que vencer facilmente.


Melfina

A deusa responsável pela reencarnação.

Inicialmente apenas observa Kelvin.

Posteriormente torna-se uma de suas invocações.

Seu jeito gentil contrasta com o espírito aventureiro do protagonista.


Efil

A primeira companheira.

Muito dedicada.

Gentil.

Excelente arqueira e cozinheira.

Rapidamente torna-se uma das personagens mais queridas da série.


Clotho

O slime.

Começa parecendo apenas um mascote.

Logo demonstra ser extremamente poderoso.

É uma homenagem aos slimes clássicos dos JRPGs.


Gerard

Um Cavaleiro Negro lendário.

Honrado.

Experiente.

Funciona como o "tank" da equipe.


Sera

Uma poderosa demônio.

Orgulhosa.

Carismática.

Excelente combatente.

Acrescenta ainda mais força ao grupo.


Temática

O anime trabalha diversos temas:

  • crescimento pessoal

  • amizade

  • trabalho em equipe

  • estratégia

  • evolução contínua

  • liberdade

  • confiança

  • coragem

  • desafios

  • superação

Embora exista bastante ação, o foco está na construção gradual da equipe.


O que há de diferente?

Aqui encontramos uma das maiores diferenças.

Normalmente os protagonistas dos isekais desejam:

  • voltar para casa;

  • viver tranquilamente;

  • derrotar o Rei Demônio;

  • proteger alguém.

Kelvin não.

Seu objetivo principal é...

Encontrar um adversário ainda mais forte.

Ele sofre da famosa síndrome do "Battle Junkie".

Lutar é sua diversão.

Quanto mais perigoso o combate...

Melhor.


Classificação

Faixa etária: aproximadamente 14 anos.

Violência moderada.

Algum fanservice.

Pouco sangue.

Humor leve.

Sem conteúdo excessivamente pesado.


Gêneros

  • Isekai

  • Fantasia

  • Aventura

  • RPG

  • Ação

  • Comédia

  • Harém leve

  • Progressão de Poder


As Grandes Aventuras

Durante a temporada acompanhamos:

  • exploração de masmorras;

  • contratos com criaturas;

  • evolução do slime;

  • missões da guilda;

  • batalhas contra demônios;

  • guerras entre nações;

  • invocações lendárias;

  • desenvolvimento da party;

  • crescimento constante de Kelvin.

Cada arco lembra uma campanha de RPG de mesa.

Sempre existe um novo desafio.

Sempre existe um novo chefe.


As Mensagens Ocultas

1. Todo poder exige um preço

Kelvin tornou-se extremamente poderoso.

Mas perdeu todas as lembranças da vida anterior.

O anime lembra que toda escolha possui consequências.


2. Conhecimento vale mais que força

Mesmo extremamente poderoso, Kelvin vence principalmente pela estratégia.

Ele observa.

Planeja.

Analisa.

Depois executa.

É praticamente um arquiteto de software enfrentando um incidente crítico.


3. Equipes fortes superam indivíduos fortes

Embora seja poderoso, Kelvin nunca tenta fazer tudo sozinho.

Cada membro da equipe possui uma função específica.

É quase uma arquitetura de microsserviços.


4. Nunca pare de evoluir

Não existe "nível máximo".

Sempre existe alguém mais forte.

Sempre existe algo novo para aprender.

É uma metáfora interessante para qualquer profissional de tecnologia.


Bellacosa Mainframe Explica

Imagine um programador COBOL chegando ao balcão da Deusa Melfina para configurar seu novo ambiente.

Ela pergunta:

"Deseja manter todas as memórias da vida passada?"

O Padawan responde:

"Quanto ganho de performance se apagar tudo?"

Ela responde:

"Mais 999 pontos em processamento."

Cinco minutos depois...

INITIALIZE HUMANO.

MOVE ZERO TO MEMORIA-PASSADA.
MOVE 999 TO PODER.
MOVE 999 TO MAGIA.
MOVE 999 TO INVOCACOES.
MOVE 999 TO PROCESSAMENTO.

DISPLAY "JOB SUBMETIDO COM SUCESSO."
DISPLAY "SYSOUT: PARABÉNS, VOCÊ ESQUECEU ATÉ A SENHA DO TSO."

Kelvin apenas sorri.

— "Ótimo..."

— "Agora me mostra onde fica o chefe final."

A deusa responde:

— "Você ainda está no tutorial."

Kelvin abre um sorriso maior ainda.


Impacto Cultural

Kuro no Shōkanshi chegou em um momento em que o mercado estava repleto de isekais. Em vez de reinventar o gênero, refinou uma fórmula muito apreciada: progressão constante de poder, sistema de níveis e batalhas estratégicas. A adaptação do estúdio Satelight foi elogiada pela trilha sonora, pelo carisma do elenco e pelas cenas de ação, embora parte dos fãs tenha criticado o uso de CGI em alguns combates e o ritmo acelerado da adaptação da light novel. Ainda assim, consolidou-se como uma recomendação frequente para quem aprecia protagonistas extremamente fortes e sistemas de RPG bem definidos.


Curiosidades

  • Kelvin é um dos protagonistas mais fortes de sua geração de isekais.

  • Clotho tornou-se um dos slimes favoritos entre os fãs do anime.

  • O sistema de invocação lembra mecânicas de JRPGs clássicos.

  • O anime adapta apenas o início da extensa light novel.

  • A obra combina elementos de fantasia medieval com gerenciamento de recursos e evolução contínua.


Vale a Pena Assistir?

Se você gosta de:

  • Overlord

  • Tsukimichi: Moonlit Fantasy

  • Arifureta

  • The Eminence in Shadow

  • Skeleton Knight in Another World

  • The World's Finest Assassin Gets Reincarnated in Another World

  • Solo Leveling (pela sensação de progressão constante)

então Kuro no Shōkanshi é uma excelente escolha.

Ele não pretende revolucionar o gênero, mas entrega exatamente o que promete: um protagonista carismático, um sistema de RPG sólido, um grupo de companheiros memorável e batalhas cada vez mais grandiosas.


⭐ Nota Bellacosa Mainframe

CategoriaNota
História⭐⭐⭐⭐☆ (8,5/10)
Mundo⭐⭐⭐⭐☆ (8,7/10)
Personagens⭐⭐⭐⭐☆ (8,8/10)
Sistema RPG⭐⭐⭐⭐⭐ (9,5/10)
Ação⭐⭐⭐⭐⭐ (9,2/10)
Humor⭐⭐⭐⭐☆ (8,3/10)
Trilha Sonora⭐⭐⭐⭐☆ (8,6/10)
Reassistir⭐⭐⭐⭐☆ (8,8/10)
Nota Final⭐ 9,0/10

Para um Programador COBOL Padawan, a grande lição de Kuro no Shōkanshi é simples: desempenho é importante, mas nunca subestime o valor da memória. Afinal, um sistema pode ter a CPU mais poderosa do mundo; sem histórico, documentação e conhecimento acumulado, até o herói mais forte pode acabar perdido no primeiro ABEND da aventura.

Obsidian sem Mistérios : O Guia Definitivo do Programador COBOL Padawan para Construir um Segundo Cérebro Digno da Frota Estelar

 

Bellacosa Mainframe em obsidian sem msterios

☕ Um Café no Bellacosa Mainframe

Obsidian sem Mistérios

O Guia Definitivo do Programador COBOL Padawan para Construir um Segundo Cérebro Digno da Frota Estelar

"Computadores armazenam dados. Grandes profissionais constroem conhecimento."


Introdução

Imagine que você acaba de embarcar na USS Enterprise.

A nave possui milhares de manuais técnicos, mapas estelares, relatórios científicos, procedimentos de emergência, históricos de missões, registros médicos, diagramas de engenharia e bancos de dados sobre centenas de civilizações.

Agora imagine procurar qualquer informação apenas usando pastas.

Seria impossível.

Foi exatamente esse problema que surgiu no mundo moderno.

Hoje um profissional de TI lê artigos, faz cursos, salva PDFs, cria códigos COBOL, estuda Db2, aprende Docker, Kubernetes, IA, Linux, APIs, RACF, CICS, IMS...

Depois de alguns meses ninguém lembra onde guardou aquela informação.

É aqui que entra o Obsidian, uma das ferramentas de gestão de conhecimento mais revolucionárias dos últimos anos.

Para um programador COBOL, ele pode se tornar praticamente um ISPF inteligente, onde cada anotação conversa automaticamente com todas as outras.


A origem do Obsidian

O Obsidian foi criado por Shida Li e Erica Xu, dois desenvolvedores canadenses apaixonados por produtividade, organização do conhecimento e privacidade dos dados.

A primeira versão pública foi lançada em 24 de março de 2020, justamente no início da pandemia da COVID-19, período em que muitas pessoas passaram a estudar e trabalhar remotamente. (The Verge)

Enquanto diversos aplicativos apostavam em armazenamento exclusivamente na nuvem, o Obsidian nasceu com uma filosofia diferente:

Seus dados pertencem a você.

Essa decisão mudaria completamente sua história.


Por que o nome "Obsidian"?

Obsidiana é uma rocha vulcânica formada pelo resfriamento extremamente rápido da lava.

Ela possui características interessantes:

  • extremamente resistente;

  • aparência elegante;

  • utilizada por antigas civilizações para fabricar ferramentas;

  • extremamente afiada quando quebrada.

É uma excelente metáfora para o software.

Ele transforma conhecimento bruto em uma ferramenta extremamente poderosa.


A filosofia do Obsidian

A maior ideia do projeto pode ser resumida em apenas três palavras:

Local First Software

Ou seja:

Seu conhecimento fica armazenado no seu computador.

Não em servidores de terceiros.

Não depende da Internet.

Não depende de uma empresa existir daqui vinte anos.

Cada nota é simplesmente um arquivo Markdown (.md), um formato de texto simples, legível por qualquer editor. (Obsidian)


O que o Obsidian faz?

Na superfície parece apenas um editor de texto.

Na prática ele é um verdadeiro sistema operacional para conhecimento.

Você pode criar:

  • documentação técnica

  • manuais

  • diário

  • wiki pessoal

  • documentação COBOL

  • documentação CICS

  • mapas mentais

  • planejamento

  • estudos

  • livros

  • artigos

  • projetos

  • documentação DevOps

  • anotações de cursos IBM

  • base de conhecimento corporativa

Tudo isso conectado entre si.


O verdadeiro diferencial

Imagine estas notas:

COBOL
CICS
IMS
Db2
VSAM

Normalmente seriam cinco documentos isolados.

No Obsidian você cria links assim:

[[COBOL]]

[[CICS]]

[[IMS]]

[[Db2]]

[[VSAM]]

Instantaneamente tudo passa a formar uma enorme rede de conhecimento.

É praticamente uma Wikipédia construída por você.


O famoso Graph View

Uma das funcionalidades mais impressionantes.

Ela transforma todas as notas em um grafo.

Visualmente você enxerga:

  • assuntos mais importantes

  • temas relacionados

  • áreas pouco exploradas

  • conexões inesperadas

  • clusters de conhecimento

É como observar o computador da Enterprise mostrando todas as ligações entre planetas da Federação.


Backlinks

Imagine criar uma nota:

ABEND S0C7

Meses depois você escreve:

Tratamento de erro COBOL

Sem perceber, o Obsidian informa:

Esta nota também é referenciada por:

  • ABEND

  • Debug

  • TEST

  • CICS

  • SQLCODE

Você nunca perde relações entre informações.


Markdown

O Obsidian utiliza Markdown.

Exemplo:

# Título

## Subtítulo

**Negrito**

*Itálico*

- Lista

```COBOL
MOVE ZERO TO WS-TOTAL.

É simples.

Limpo.

Durará décadas.

---

# Vault

No Obsidian tudo acontece dentro de um Vault.

Pense nele como um grande PDS.

Dentro dele ficam:

Artigos

Cursos

COBOL

Db2

IMS

Docker

Linux

IA

Projetos

Livros


Mas diferente de um PDS tradicional...

Tudo pode conversar automaticamente.

---

# Plugins

Este talvez seja o maior poder do Obsidian.

Existem milhares de plugins criados pela comunidade, permitindo expandir a ferramenta com calendários, quadros Kanban, diagramas, gerenciamento de tarefas, flashcards, integração com IA e muito mais. O ecossistema oficial reúne uma ampla coleção de plugins e temas mantidos pela comunidade. :contentReference[oaicite:2]{index=2}

Alguns dos mais famosos:

## Dataview

Transforma notas em banco de dados.

---

## Kanban

Cria quadros estilo Trello.

---

## Calendar

Agenda integrada.

---

## Excalidraw

Desenhos técnicos.

Arquiteturas.

Diagramas.

Fluxogramas.

---

## Tasks

Gerenciador profissional de tarefas.

---

## Git

Versionamento automático.

Ideal para documentação técnica.

---

# IA dentro do Obsidian

Hoje existem plugins que integram:

- ChatGPT
- Ollama
- Claude
- Gemini
- modelos locais

Isso significa que sua base inteira pode ser consultada usando IA.

Imagine perguntar:

> "Mostre todos os artigos onde citei RACF junto com CICS."

Ou:

> "Resuma minhas notas sobre Db2."

Ou:

> "Gere documentação deste programa COBOL."

É praticamente um oficial científico vulcano analisando seu acervo.

---

# Para programadores COBOL

Aqui o Obsidian realmente brilha.

Você pode criar uma wiki completa contendo:

COBOL

PERFORM

CALL

COPYBOOKS

CICS

EXEC SQL

IMS

VSAM

JCL

IDCAMS

SORT

DFSORT

SMF

RMF

RACF

REXX

ISPF

SDSF

MQ

z/OSMF


Tudo interligado.

Cada conceito aponta automaticamente para outros relacionados.

---

# Como organizar um Vault técnico

Uma boa estrutura seria:

01-Cursos

02-Artigos

03-Laboratórios

04-Códigos

05-Projetos

06-Livros

07-Glossário

08-Comandos

09-Diagramas

10-Ideias


---

# Um exemplo Bellacosa Mainframe

Imagine escrever:

ABEND S806


Essa nota aponta para:

LOADLIB

LINKEDIT

STEPLIB

JOBLIB

IEWL

Binder


Ao abrir LOADLIB...

Você encontra:

PDSE

PDS

APF

LNKLST

Program Object


Em poucos meses você terá criado sua própria Wikipédia Mainframe.

---

# Curiosidades

## Tudo é texto

Nenhum banco proprietário.

Tudo fica em Markdown.

---

## Funciona offline

Internet não é obrigatória.

---

## Muito rápido

Mesmo com dezenas de milhares de notas.

---

## Temas

Centenas de temas visuais.

---

## Comunidade enorme

Milhares de plugins gratuitos.

---

## Sincronização opcional

Você pode usar:

- Git
- OneDrive
- Dropbox
- Google Drive

Ou contratar o serviço oficial **Obsidian Sync**, com criptografia de ponta a ponta. :contentReference[oaicite:3]{index=3}

---

# Evolução da ferramenta

Desde 2020, o Obsidian evoluiu continuamente:

- suporte multiplataforma (Windows, macOS, Linux, Android e iOS);
- editor Live Preview;
- melhorias no desempenho;
- milhares de plugins da comunidade;
- sincronização oficial;
- publicação de sites com Obsidian Publish;
- novos recursos de organização de metadados, incluindo a funcionalidade **Bases**, que amplia a visualização das notas em formatos como tabelas e outros modos estruturados. :contentReference[oaicite:4]{index=4}

---

# Dicas técnicas

## Use um Vault por assunto?

Não.

Prefira um Vault único.

Conectividade é o verdadeiro poder.

---

## Escreva pouco

Uma nota.

Um conceito.

---

## Abuse dos links

Sempre utilize:

[[ ]]


---

## Utilize Tags

#COBOL

#CICS

#IMS

#DB2

#JCL


---

## Crie notas permanentes

Não copie artigos.

Escreva com suas palavras.

---

## Faça revisões

Conhecimento parado envelhece.

---

## Versione tudo

Git + Obsidian é uma combinação extraordinária para documentação técnica.

---

# Como tirar o máximo proveito

O segredo não está em escrever muito.

Está em conectar muito.

Cada nota deve responder:

- isso depende de quê?
- isso explica o quê?
- onde mais esse conceito aparece?
- qual comando está relacionado?
- existe um exemplo COBOL?
- existe um exemplo JCL?
- existe um laboratório?

Quanto mais links...

Mais inteligente seu segundo cérebro se torna.

---

# Uma analogia para a Frota Estelar

Imagine que o computador central da USS Enterprise possua bilhões de documentos.

O que realmente o torna poderoso não é armazenar arquivos.

É saber relacioná-los.

Quando Spock pergunta:

> "Mostre todos os registros envolvendo cristais de dilítio."

O computador responde imediatamente.

É exatamente isso que o Obsidian faz.

Ele não organiza apenas arquivos.

Ele organiza conexões.

Cada nota funciona como um planeta da Federação.

Cada link representa uma rota estelar.

Cada backlink revela novas alianças.

E o Graph View transforma toda essa galáxia de conhecimento em um mapa navegável, mostrando onde novas descobertas podem surgir.

---

# Conclusão

Para um programador COBOL Padawan, aprender linguagens, comandos e tecnologias é apenas o primeiro passo. O verdadeiro diferencial ao longo da carreira está em construir uma base de conhecimento que cresça junto com sua experiência.

O Obsidian oferece exatamente isso: um ambiente onde documentação, código, laboratórios, artigos, diagramas e ideias deixam de ser arquivos isolados e passam a formar uma rede viva de conhecimento. Sua filosofia *local-first*, o uso de arquivos Markdown, a ampla personalização por plugins e a possibilidade de conectar conceitos fazem dele uma ferramenta valiosa tanto para estudantes quanto para arquitetos de software, especialistas em IBM Z e profissionais de IA.

Se o ISPF foi, por décadas, a ponte entre o programador e o mainframe, o Obsidian pode ser visto como a ponte entre o conhecimento acumulado e a sabedoria prática. Em uma era em que aprender continuamente é essencial, construir um "segundo cérebro" bem organizado pode ser tão importante quanto dominar COBOL, CICS ou Db2.

Como diria um oficial científico da Frota Estelar:

> *"Conhecimento armazenado é útil. Conhecimento conectado é transformador."*

---

## Site oficial

:contentReference[oaicite:5]{index=5}

## Download oficial

:contentReference[oaicite:6]{index=6}

terça-feira, 20 de setembro de 2022

Os 50 Comandos do Subsistema Db2 sem Mistérios

 

Bellacosa Mainframe e uma lista de 50 comandos do subsistema db2 sem misterios

☕ Um Café no Bellacosa Mainframe

Os 50 Comandos do Subsistema Db2 sem Mistérios

O guia operacional para o programador COBOL padawan conversar com o coração do Db2 for z/OS

Imagine o seguinte cenário: você terminou seu programa COBOL, passou pelo pré-compilador, compilou, linkeditou, executou o BIND e finalmente colocou o módulo em produção.

Então chega uma mensagem:

DSNT500I RESOURCE UNAVAILABLE

O programa está correto. O SQL está correto. A tabela existe. Mas o tablespace está parado.

Em outro momento, o programa fica esperando durante vários minutos. Não há abend, não há SQLCODE negativo e ninguém sabe exatamente o que está acontecendo. Depois de alguma investigação, descobre-se que uma thread está segurando um lock e bloqueando dezenas de transações.

É nesse ponto que entramos no mundo dos comandos do subsistema Db2.

Esses comandos não são comandos SQL. Eles são ordens operacionais enviadas diretamente ao mecanismo do Db2 for z/OS para consultar, iniciar, parar, alterar, recuperar ou controlar componentes do subsistema.

A IBM define esses comandos como recursos usados para controlar grande parte do ambiente operacional do Db2. Eles podem ser emitidos pelo console do z/OS, pelo SDSF, por uma sessão DSN no TSO, pelo painel DB2 Commands do DB2I e, dependendo da configuração, por terminais IMS, CICS ou aplicações autorizadas. A exceção mais importante é -START DB2, que normalmente precisa ser emitido pelo console do z/OS ou pelo TSO/SDSF. (IBM)


Bellacosa Mainframe e o DB2 na intimidade

1. Antes de começar: SQL não é comando Db2

Um iniciante frequentemente mistura quatro coisas diferentes:

SELECT * FROM CLIENTES;

Isso é uma instrução SQL.

RUNSTATS TABLESPACE DBVENDAS.TSVENDAS;

Isso é uma utility control statement, normalmente executada pelo utilitário DSNUTILB.

BIND PACKAGE(COLLID) MEMBER(PROGRAMA);

Isso é um subcomando do processador DSN.

-DISPLAY DATABASE(DBVENDAS)

Isso é um comando operacional do subsistema Db2.

O hífen inicial é uma pista fundamental:

-DISPLAY
-START
-STOP
-ALTER
-CANCEL
-SET
-RECOVER

Nos exemplos deste artigo, considere que o subsistema se chama DB2P, embora o prefixo usado no console dependa da instalação.

No console, você poderá encontrar algo como:

-DB2P DISPLAY DATABASE(DBVENDAS)

No painel DB2 Commands do DB2I, normalmente será digitado apenas:

-DISPLAY DATABASE(DBVENDAS)

2. Regra de ouro do operador Jedi

Antes de executar qualquer comando que modifique o ambiente:

  1. Execute um DISPLAY.

  2. Leia todas as mensagens retornadas.

  3. Confirme o nome do subsistema.

  4. Confirme o nome do objeto.

  5. Verifique se está em desenvolvimento, homologação ou produção.

  6. Registre o motivo da intervenção.

  7. Tenha um comando de retorno preparado.

  8. Nunca copie comandos cegamente de outra instalação.

O Db2 costuma retornar DSN9022I quando o processamento do comando termina normalmente e DSN9023I quando termina de forma anormal. Porém, não basta procurar apenas a última mensagem: as mensagens anteriores explicam o que realmente aconteceu. (IBM)


Parte I — Comandos de diagnóstico e observação

1. -DISPLAY DATABASE

Para que serve

Exibe o estado de databases, tablespaces, indexspaces e partições.

É provavelmente o comando operacional mais importante para o programador COBOL.

Exemplo

-DISPLAY DATABASE(DBVENDAS)

Para um tablespace específico:

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Para obter informações adicionais:

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS) RESTRICT

Passo a passo

  1. Identifique o database.

  2. Informe opcionalmente o nome do espaço.

  3. Execute o comando.

  4. Procure estados restritivos.

  5. Investigue situações como STOP, COPY, RECP, REORP, RBDP, UTRO ou UTRW.

Vantagem

Permite verificar rapidamente por que uma aplicação não consegue acessar um objeto.

Perigo

Usar curingas muito abrangentes pode produzir uma enorme quantidade de mensagens no console.

-DISPLAY DATABASE(*) SPACENAM(*)

Em produção, isso pode transformar o console em uma cachoeira de mensagens.

A IBM documenta que o comando apresenta informações de status sobre databases Db2 e possui escopo de grupo em ambientes data sharing. (IBM)


2. -DISPLAY THREAD

Para que serve

Mostra as threads que estão conectadas ao Db2.

Uma thread representa o contexto de uma conexão ou unidade de trabalho de uma aplicação. Pode ser uma aplicação TSO, CICS, IMS, batch, stored procedure ou uma conexão distribuída.

Exemplos

-DISPLAY THREAD(*)
-DISPLAY THREAD(*) TYPE(ACTIVE)
-DISPLAY THREAD(*) DETAIL

O que observar

  • authorization ID;

  • plan;

  • correlation ID;

  • connection name;

  • token;

  • status;

  • LUWID;

  • atividade local ou distribuída.

Dica COBOL

Em um job batch, o correlation ID frequentemente ajuda a relacionar a thread ao job ou à aplicação.

Perigo

Não confunda uma thread aparentemente parada com uma thread inútil. Ela pode estar esperando I/O, lock, resposta de rede ou trabalho de outra região.

O comando mostra informações sobre allied threads, database access threads e tarefas paralelas, que podem estar ativas, inativas, indoubt ou postponed. (IBM)


3. -DISPLAY BLOCKERS

Para que serve

Mostra locks e claims mantidos por threads que estão bloqueando determinados objetos.

Exemplo

-DISPLAY BLOCKERS DATABASE(DBVENDAS)
-DISPLAY BLOCKERS DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Quando usar

  • jobs esperando recursos;

  • SQLCODE -911 ou -913;

  • utility sem conseguir realizar drain;

  • transações CICS acumulando;

  • tablespace que não consegue parar.

Vantagem

Reduz o tempo de investigação de contenção.

Ponto de atenção

O bloqueador nem sempre é o culpado. Pode ser apenas uma aplicação legítima executando uma longa unidade de trabalho.

O comando mostra locks e claims mantidos por threads ativas contra databases, tabelas, índices ou espaços especificados. (IBM)


4. -DISPLAY DDF

Para que serve

Exibe o estado da Distributed Data Facility, responsável pelas conexões distribuídas com o Db2.

Exemplo

-DISPLAY DDF
-DISPLAY DDF DETAIL

Pode mostrar

  • status do DDF;

  • endereço TCP/IP;

  • porta DRDA;

  • número de conexões;

  • número de DBATs;

  • parâmetros de conexão;

  • filas relacionadas a limites.

Uso típico

Uma aplicação Java, API, ferramenta externa ou outro Db2 não consegue conectar-se ao subsistema.

Atenção

DDF ativo não significa que toda conexão funcionará. Ainda podem existir problemas de TCP/IP, RACF, certificados, AT-TLS, location, package ou autorização.

A IBM descreve -DISPLAY DDF como o comando que mostra configuração, status e estatísticas das conexões e threads controladas pelo DDF. (IBM)


5. -DISPLAY GROUP

Para que serve

Exibe informações sobre o data sharing group ou, mesmo fora de um grupo ativo, dados importantes sobre níveis do Db2.

Exemplo

-DISPLAY GROUP
-DISPLAY GROUP DETAIL

Mostra informações como

  • membros;

  • status dos membros;

  • code level;

  • catalog level;

  • function level;

  • coexistência e compatibilidade.

Curiosidade

É um dos primeiros comandos que um especialista executa para descobrir “em que Db2 estou pisando”.

O Db2 pode ter código em um nível, catálogo em outro e function level em outro. A versão comercial isoladamente não conta toda a história.


6. -DISPLAY BUFFERPOOL

Para que serve

Mostra status e características dos buffer pools.

Exemplo

-DISPLAY BUFFERPOOL(BP0)
-DISPLAY BUFFERPOOL(*)
-DISPLAY BUFFERPOOL(BP8K0) DETAIL

O que investigar

  • tamanho atual;

  • page size;

  • thresholds;

  • parâmetros de escrita;

  • situação ativa ou inativa;

  • frames alocados.

Vantagem

Ajuda a verificar se uma alteração de buffer pool foi realmente aplicada.

Desvantagem

O comando não substitui RMF, Statistics Trace ou ferramentas de performance. Ele mostra estado operacional, não toda a história de desempenho.


7. -DISPLAY GROUPBUFFERPOOL

Para que serve

Mostra o estado dos group buffer pools em data sharing.

Exemplo

-DISPLAY GROUPBUFFERPOOL(GBP0)
-DISPLAY GROUPBUFFERPOOL(*) TYPE(GCONN)

Quando é importante

  • problemas de data sharing;

  • falhas de coupling facility;

  • rebuild de GBP;

  • objetos em GBP-dependent;

  • inconsistências entre membros.

Atenção

Este comando pertence ao reino do sysprog e do DBA de infraestrutura. Um programador deve conhecê-lo, mas não alterar um GBP sem um procedimento formal.


8. -DISPLAY LOG

Para que serve

Mostra informações sobre active logs, offload, checkpoints e situação do processo de logging.

Exemplo

-DISPLAY LOG

Pode ajudar a identificar

  • active log corrente;

  • progresso de offload;

  • parâmetros de checkpoint;

  • ocupação ou indisponibilidade de logs;

  • risco de aplicações pararem por falta de espaço de log.

Easter egg operacional

O log é a máquina do tempo do Db2. Sem ele, rollback, restart e recuperação deixam de ser operações confiáveis.

A IBM explica que, quando o Db2 preenche um active log, precisa descarregá-lo para um archive log. Se as aplicações alcançarem o processo de offload, elas podem ser suspensas até que haja espaço disponível. (IBM)


9. -DISPLAY ARCHIVE

Para que serve

Mostra informações sobre archive logs usados como entrada e sobre a atividade de arquivamento.

Exemplo

-DISPLAY ARCHIVE

Ponto de atenção em data sharing

O comando mostra informações do membro no qual foi executado. Para visualizar todos os membros, pode ser necessário executá-lo individualmente em cada um. (IBM)


10. -DISPLAY UTILITY

Para que serve

Mostra o estado das utilities registradas no Db2.

Exemplos

-DISPLAY UTILITY(*)
-DISPLAY UTILITY(UTIL1234)

Pode revelar

  • utility ID;

  • nome da utility;

  • fase atual;

  • objeto processado;

  • contagem de registros;

  • situação parada ou ativa;

  • membro do data sharing group.

Uso típico

Um REORG aparentemente não avança. Antes de cancelar o job, execute DISPLAY UTILITY.

Perigo

A utility pode estar em uma fase crítica ou aguardando drain. Interrompê-la sem entender o estado pode deixar o objeto restrito.


11. -DISPLAY TRACE

Para que serve

Lista traces ativos no Db2.

Exemplo

-DISPLAY TRACE(*)
-DISPLAY TRACE(P)

Tipos comuns

  • statistics;

  • accounting;

  • audit;

  • performance;

  • monitor;

  • global.

Atenção

Tracing custa recursos. Um trace excessivamente detalhado pode aumentar CPU, geração de SMF e volume de dados.


12. -DISPLAY STATS

Para que serve

Exibe estatísticas de uso de determinados recursos e processos internos do Db2.

Exemplo

-DISPLAY STATS

Utilidade

É usado em diagnósticos operacionais específicos, geralmente por DBAs e suporte.

Limitação

Não deve ser confundido com RUNSTATS. DISPLAY STATS consulta estatísticas operacionais; RUNSTATS coleta estatísticas de objetos para catálogo e otimizador.


13. -DISPLAY LOCATION

Para que serve

Mostra informações sobre locations remotas conhecidas pelo Db2.

Exemplo

-DISPLAY LOCATION(*)
-DISPLAY LOCATION(DSNREM01)

Quando usar

  • falha em conexão remota;

  • aplicações DRDA;

  • aliases e locations incorretas;

  • investigação de comunicação entre subsistemas.


14. -DISPLAY PROFILE

Para que serve

Mostra se a função de profiles está ativa.

Exemplo

-DISPLAY PROFILE

O que são profiles

As profile tables permitem aplicar controles e comportamentos a conexões e threads, incluindo limites e regras para aplicações distribuídas.

Atenção

Uma aplicação pode funcionar em homologação e ser limitada em produção por causa de um profile específico.


15. -DISPLAY RLIMIT

Para que serve

Mostra o estado do Resource Limit Facility, tradicionalmente conhecido como governor.

Exemplo

-DISPLAY RLIMIT

Para que serve o governor

Pode limitar ou controlar o consumo estimado de recursos por instruções SQL dinâmicas.

Pegadinha

Um SQL pode estar sintaticamente correto e ter um bom access path, mas ser bloqueado por política de resource limit.


16. -DISPLAY PROCEDURE

Para que serve

Mostra informações e estatísticas sobre stored procedures externas acessadas pelas aplicações.

Exemplo

-DISPLAY PROCEDURE(*)
-DISPLAY PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso típico

  • stored procedure não inicia;

  • excesso de chamadas;

  • procedure parada;

  • comportamento inesperado no WLM application environment.


17. -DISPLAY FUNCTION SPECIFIC

Para que serve

Mostra estatísticas sobre funções externas definidas pelo usuário.

Exemplo conceitual

-DISPLAY FUNCTION SPECIFIC(MEU_SCHEMA.MINHA_FUNCAO)

Atenção

O nome específico pode ser diferente do nome SQL usado para chamar a função.


18. -DISPLAY RESTSVC

Para que serve

Mostra o estado dos serviços REST definidos no Db2.

Exemplo

-DISPLAY RESTSVC(*)

Curiosidade

O mesmo Db2 tradicionalmente acessado por COBOL, CICS e batch pode expor operações como serviços REST.

É a velha fortaleza do mainframe abrindo portões controlados para o mundo das APIs.


19. -DISPLAY ACCEL

Para que serve

Mostra informações sobre servidores aceleradores associados ao Db2, como ambientes IBM Db2 Analytics Accelerator.

Exemplo

-DISPLAY ACCEL(*)

Ponto de atenção

Uma query elegível para aceleração pode deixar de ser executada no accelerator quando o servidor está indisponível, dependendo da configuração e do comportamento definido.


20. -DISPLAY ML

Para que serve

Mostra o estado de funções relacionadas ao IBM Db2 AI for z/OS ou ao IBM Z Database Assistant.

Exemplo

-DISPLAY ML

Curiosidade

É um exemplo de como a lista de comandos do Db2 evolui. O velho painel verde agora também conversa com recursos de inteligência artificial.


21. -DISPLAY OTEL

Para que serve

Exibe o estado da integração OpenTelemetry do Db2.

Exemplo

-DISPLAY OTEL

Ponto de atenção

Esse comando depende do nível de código, manutenção e function level aplicáveis ao ambiente. Ele pode não existir em instalações mais antigas.

O catálogo atual do Db2 13 inclui comandos para exibir, iniciar e parar funções OpenTelemetry. (IBM)


22. -DISPLAY DYNQUERYCAPTURE

Para que serve

Mostra monitores ativos de captura de queries dinâmicas.

Exemplo

-DISPLAY DYNQUERYCAPTURE

Utilidade

Ajuda em processos de estabilização de access paths para SQL dinâmico.

Atenção

Isso não é a mesma coisa que olhar o dynamic statement cache. O comando está relacionado aos monitores de captura configurados.


Parte II — Comandos para iniciar componentes

23. -START DB2

Para que serve

Inicializa o subsistema Db2.

Exemplo no console

-DB2P START DB2

Passo a passo simplificado

  1. O z/OS inicia as started tasks do Db2.

  2. O Db2 conecta-se ao IRLM.

  3. Abre BSDS e logs.

  4. Executa restart processing quando necessário.

  5. Recupera unidades de trabalho.

  6. Disponibiliza serviços internos.

  7. Permite conexões de TSO e subsistemas anexados.

Perigo

Não é um simples “ligar banco de dados”. Um restart pode envolver recuperação, backout e resolução de unidades de trabalho.


24. -START DATABASE

Para que serve

Torna um database ou espaço novamente disponível.

Exemplos

-START DATABASE(DBVENDAS)
-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS) ACCESS(RW)

Modos de acesso comuns

  • RW: leitura e escrita;

  • RO: somente leitura;

  • UT: acesso para utilities;

  • modos específicos dependem da situação e da sintaxe suportada.

Atenção

Dar START não remove magicamente todos os estados restritivos. Um objeto em RECP, RBDP ou COPY pode exigir uma utility apropriada.

A IBM define esse comando como a forma de tornar o database especificado disponível para uso. (IBM)


25. -START DDF

Para que serve

Inicia a Distributed Data Facility.

Exemplo

-START DDF

Antes de usar

  1. Execute -DISPLAY DDF.

  2. Confirme que o DDF está parado.

  3. Verifique TCP/IP e segurança.

  4. Inicie.

  5. Execute outro -DISPLAY DDF.

Perigo

Iniciar o DDF pode reabrir imediatamente o acesso de centenas de clientes externos.


26. -START TRACE

Para que serve

Inicia traces do Db2.

Exemplo conceitual

-START TRACE(P) CLASS(1,2,3) DEST(SMF)

Atenção máxima

Classes de trace devem ser escolhidas conscientemente. Ativar classes em excesso pode gerar alto volume de SMF e overhead.

Boa prática

Defina antecipadamente:

  • por que o trace será iniciado;

  • qual classe é necessária;

  • qual destino será utilizado;

  • quanto tempo ficará ativo;

  • quem irá pará-lo;

  • como os registros serão analisados.


27. -START PROFILE

Para que serve

Carrega ou recarrega as profile tables para a memória do Db2.

Exemplo

-START PROFILE

Pegadinha

Alterar as tabelas de profile não significa necessariamente que o Db2 já esteja usando a nova configuração. O reload pode ser necessário.


28. -START RLIMIT

Para que serve

Inicia o Resource Limit Facility.

Exemplo conceitual

-START RLIMIT ID=RLST01

Atenção

A sintaxe exata e a tabela utilizada dependem da configuração da instalação.


29. -START PROCEDURE

Para que serve

Ativa ou atualiza a definição de uma stored procedure no cache.

Exemplo

-START PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso interessante

Depois de uma alteração autorizada na definição ou no programa externo, o DBA pode usar o comando para atualizar o estado da procedure.


30. -START FUNCTION SPECIFIC

Para que serve

Inicia uma função externa que foi anteriormente parada.

Exemplo conceitual

-START FUNCTION SPECIFIC(MEU_SCHEMA.FUNCAO01)

Limitação

Aplica-se a funções externas suportadas pelo comando, não a qualquer função built-in do Db2.


31. -START RESTSVC

Para que serve

Inicia um serviço REST que estava parado.

Exemplo

-START RESTSVC(COLLECTION.SERVICO)

Ponto de atenção

Iniciar o serviço não corrige problemas de package, autorização, endpoint, certificado ou SQL interno.


32. -START ACCEL

Para que serve

Notifica o Db2 para utilizar determinado servidor acelerador.

Exemplo conceitual

-START ACCEL(*)

Atenção

Deve fazer parte de um procedimento de administração do accelerator, não de uma tentativa aleatória de “fazer query correr mais rápido”.


33. -START ML

Para que serve

Inicia funções ligadas ao Db2 AI for z/OS ou IBM Z Database Assistant.

Exemplo

-START ML

Dependências

O produto correspondente precisa estar instalado e corretamente configurado.


34. -START OTEL

Para que serve

Inicia as funções OpenTelemetry do Db2.

Exemplo

-START OTEL

Uso

Pode fazer parte de uma estratégia moderna de observabilidade distribuída, correlacionando aplicações externas com processamento dentro do Db2.


35. -START DYNQUERYCAPTURE

Para que serve

Inicia captura e monitoramento de SQL dinâmico qualificado para estabilização de access paths.

Exemplo conceitual

-START DYNQUERYCAPTURE

Vantagem

Ajuda a tornar determinados comportamentos de SQL dinâmico mais previsíveis.

Desvantagem

Introduz administração adicional e exige entendimento sobre quais queries estão sendo capturadas.


Parte III — Comandos para parar componentes

36. -STOP DATABASE

Para que serve

Torna databases ou espaços indisponíveis e fecha seus data sets.

Exemplos

-STOP DATABASE(DBVENDAS)
-STOP DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
-STOP DATABASE(DBVENDAS) SPACENAM(TSVENDAS) MODE(QUIESCE)

Passo a passo seguro

  1. Execute DISPLAY DATABASE.

  2. Identifique aplicações usando o objeto.

  3. Verifique blockers e claims.

  4. Escolha o modo adequado.

  5. Execute o STOP.

  6. Confirme o estado.

  7. Execute a manutenção planejada.

  8. Use START DATABASE para restaurar o acesso.

Perigo

Parar um objeto em produção pode causar:

  • SQLCODE -904;

  • transações CICS falhando;

  • jobs batch interrompidos;

  • filas e reprocessamentos;

  • indisponibilidade de APIs.

Nunca use MODE(FORCE) apenas porque MODE(QUIESCE) está demorando.


37. -STOP DB2

Para que serve

Encerra o subsistema Db2.

Exemplo

-STOP DB2 MODE(QUIESCE)

Modos importantes

MODE(QUIESCE) tenta realizar uma parada organizada.

MODE(FORCE) força o encerramento e pode exigir maior processamento de restart posteriormente.

Regra Jedi

FORCE não significa “mais rápido e melhor”. Significa “aceito as consequências operacionais de não esperar”.


38. -STOP DDF

Para que serve

Interrompe a interface distribuída do Db2 com TCP/IP ou VTAM.

Exemplo

-STOP DDF

Efeito

As aplicações locais podem continuar funcionando, mas novas conexões distribuídas serão afetadas e conexões existentes dependerão do modo usado.

Perigo

Pode derrubar acesso de APIs, servidores Java, ferramentas de dados e outros subsistemas.


39. -STOP TRACE

Para que serve

Interrompe traces.

Exemplo conceitual

-STOP TRACE(P) TNO(03)

Boa prática

Sempre guarde o identificador do trace retornado no START TRACE.

O erro clássico é começar um trace e depois ninguém saber qual trace deve ser encerrado.


40. -STOP PROFILE

Para que serve

Desativa a função de profiles.

Exemplo

-STOP PROFILE

Atenção

Desativar profiles pode remover proteções, limites ou comportamentos definidos para várias conexões. Não é apenas uma ação técnica neutra.


41. -STOP RLIMIT

Para que serve

Interrompe o Resource Limit Facility.

Exemplo

-STOP RLIMIT

Risco

SQLs que antes eram controlados pelo governor podem passar a executar sem aquela limitação.


42. -STOP PROCEDURE

Para que serve

Impede que o Db2 aceite novas chamadas para uma ou mais stored procedures.

Exemplo

-STOP PROCEDURE(MEU_SCHEMA.MINHA_PROC)

Uso típico

  • manutenção;

  • correção emergencial;

  • stored procedure causando falhas;

  • preparação para atualização do módulo.


43. -STOP RESTSVC

Para que serve

Impede novas solicitações de descoberta ou invocação de um serviço REST.

Exemplo

-STOP RESTSVC(COLLECTION.SERVICO)

Vantagem

Permite isolar uma API sem necessariamente parar todo o DDF.


Parte IV — Comandos de alteração e controle

44. -ALTER BUFFERPOOL

Para que serve

Altera atributos de buffer pools ativos ou inativos.

Exemplo conceitual

-ALTER BUFFERPOOL(BP8K0) VPSIZE(20000)

Passos recomendados

  1. Execute DISPLAY BUFFERPOOL.

  2. Analise a necessidade.

  3. Avalie memória real e impacto.

  4. Aplique a alteração.

  5. Execute novo DISPLAY.

  6. Monitore paging, hit ratio, I/O e desempenho.

Vantagem

Certos parâmetros podem ser ajustados dinamicamente.

Desvantagem

Aumentar buffer pool indiscriminadamente pode pressionar a memória do sistema e prejudicar o conjunto, mesmo que um objeto isolado pareça melhorar.


45. -ALTER GROUPBUFFERPOOL

Para que serve

Altera atributos de group buffer pools em data sharing.

Exemplo conceitual

-ALTER GROUPBUFFERPOOL(GBP0) ...

Atenção máxima

Mudanças em GBP podem afetar todos os membros e milhares de objetos compartilhados. É território de change control, capacity planning e especialistas em Parallel Sysplex.


46. -ALTER UTILITY

Para que serve

Altera certos parâmetros de uma utility que já está em execução.

Pode ser usado em algumas execuções de:

  • REORG SHRLEVEL REFERENCE;

  • REORG SHRLEVEL CHANGE;

  • REBUILD SHRLEVEL CHANGE.

Exemplo conceitual

-ALTER UTILITY(UTIL1234) ...

Vantagem

Permite ajustar determinados comportamentos sem terminar e reiniciar toda a utility.

Limitação

Não é possível alterar qualquer parâmetro. Somente opções explicitamente suportadas pela utility e pela fase atual.


47. -MODIFY DDF

Para que serve

Modifica configurações e comportamentos operacionais do DDF.

Exemplo conceitual

-MODIFY DDF PKGREL(BNDOPT)

Possíveis usos

  • ajustar comportamento de packages;

  • controlar determinadas características das conexões;

  • resetar estatísticas;

  • modificar parâmetros suportados dinamicamente.

Perigo

Uma alteração aparentemente pequena pode afetar milhares de conexões distribuídas.


48. -SET SYSPARM

Para que serve

Altera parâmetros do subsistema que podem ser atualizados online.

Exemplo conceitual

-SET SYSPARM ...

Importante

Nem todo ZPARM é dinâmico.

Alguns parâmetros:

  • aceitam alteração online;

  • exigem restart;

  • dependem de function level;

  • possuem relacionamentos com outros parâmetros.

Boa prática

Registre tanto a mudança dinâmica quanto a atualização permanente nos parâmetros de instalação. Caso contrário, o valor pode retornar ao anterior no próximo restart.


49. -SET LOG

Para que serve

Controla aspectos críticos do logging.

Pode ser usado para:

  • alterar frequência de checkpoint;

  • suspender logging;

  • retomar logging;

  • adicionar active log;

  • remover active log.

A IBM confirma essas funções na documentação do comando. (IBM)

Exemplos conceituais

-SET LOG LOGLOAD(500000)
-SET LOG SUSPEND
-SET LOG RESUME

Perigo extremo

SET LOG SUSPEND não é um botão de pausa casual. Ele participa de procedimentos específicos, frequentemente relacionados a cópias consistentes e operações de storage.

Uma suspensão indevida pode paralisar atualizações e causar um incidente de grandes proporções.


Parte V — Comandos de intervenção, emergência e recuperação

50. -CANCEL THREAD

Para que serve

Cancela o processamento de uma thread local ou distribuída específica.

Procedimento correto

Primeiro localize a thread:

-DISPLAY THREAD(*) TYPE(ACTIVE) DETAIL

Identifique o token.

Depois, somente com autorização:

-CANCEL THREAD(token)

Para determinados casos distribuídos, pode ser usado:

-CANCEL DDF THREAD(token)

A IBM recomenda usar o DISPLAY THREAD DETAIL para identificar uma thread distribuída problemática antes do cancelamento. (IBM)

O que pode acontecer

  • rollback da unidade de trabalho;

  • liberação de locks;

  • abend ou erro na aplicação;

  • mensagens para CICS, IMS ou cliente remoto;

  • recuperação de recursos;

  • aumento temporário de logging pelo backout.

Perigo

Cancelar a thread errada pode derrubar:

  • fechamento contábil;

  • processamento de folha;

  • transferência financeira;

  • utility;

  • stored procedure;

  • transação crítica;

  • aplicação de outro usuário.

Regra de ouro

CANCEL THREAD não é ferramenta de performance. É uma intervenção operacional.


Seis comandos extras que você precisa conhecer

Embora a lista principal tenha cinquenta comandos, existem comandos que não podem ficar fora do seu radar.

-ARCHIVE LOG

Fecha o active log atual, passa para o próximo e inicia o processo de offload conforme a configuração.

-ARCHIVE LOG

Com quiesce:

-ARCHIVE LOG MODE(QUIESCE)

MODE(QUIESCE) tenta fazer com que as unidades de atualização alcancem commit, criando um ponto consistente antes do arquivamento. Isso pode suspender temporariamente atividades de atualização e deve ser utilizado com planejamento. (IBM)


-TERM UTILITY

Termina uma utility registrada e libera os recursos associados.

-TERM UTILITY(UTIL1234)

Antes:

-DISPLAY UTILITY(UTIL1234)

Perigo

O job pode ter terminado no JES, mas a utility continuar registrada no Db2. Por outro lado, terminar uma utility no momento errado pode deixar objetos em estados restritivos.


-RECOVER INDOUBT

Resolve threads que ficaram indoubt porque Db2 e o coordenador da transação não conseguiram determinar automaticamente se a unidade deveria receber commit ou rollback.

-RECOVER INDOUBT ...

Perigo extremo

Escolher incorretamente entre commit e abort pode gerar inconsistência lógica entre sistemas participantes.

Esse comando exige evidência, coordenação e procedimento de recuperação.


-RECOVER POSTPONED

Completa backout de unidades de recuperação que ficaram como postponed abort durante um restart anterior.

-RECOVER POSTPONED

É um comando de recuperação do subsistema, não um substituto da utility RECOVER.


-RECOVER BSDS

Reestabelece o dual BSDS quando uma das cópias foi desabilitada por erro de data set.

-RECOVER BSDS

O BSDS contém informações vitais sobre logs, checkpoints e restart. Mexer nele sem conhecimento especializado equivale a abrir o painel de navegação da nave durante uma tempestade hyperspace.


-ACCESS DATABASE

Pode forçar a abertura física de espaços, remover certos estados relacionados a GBP ou externalizar informações mantidas em memória, dependendo do MODE.

-ACCESS DATABASE(DBVENDAS) SPACENAM(TSVENDAS) MODE(OPEN)

A sintaxe e os modos devem ser confirmados para o nível específico do Db2.


Um roteiro prático para investigar “RESOURCE UNAVAILABLE”

Considere o erro:

DSNT500I
RESOURCE UNAVAILABLE
REASON 00C90081
TYPE 00000200
NAME DBVENDAS.TSVENDAS

Passo 1 — Não chute

Leia:

  • reason code;

  • resource type;

  • resource name;

  • horário;

  • job ou transação afetada.

Passo 2 — Verifique o objeto

-DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS) RESTRICT

Passo 3 — Procure utility

-DISPLAY UTILITY(*)

Passo 4 — Procure bloqueadores

-DISPLAY BLOCKERS DATABASE(DBVENDAS) SPACENAM(TSVENDAS)

Passo 5 — Verifique threads

-DISPLAY THREAD(*) TYPE(ACTIVE) DETAIL

Passo 6 — Descubra a causa

O objeto pode estar:

  • parado administrativamente;

  • aguardando recovery;

  • esperando COPY;

  • esperando REORG;

  • em uso por utility;

  • bloqueado por aplicação;

  • restrito por falha anterior.

Passo 7 — Aplique a solução correta

Somente se o objeto estiver apenas parado e houver autorização:

-START DATABASE(DBVENDAS) SPACENAM(TSVENDAS) ACCESS(RW)

Se estiver em RECP, por exemplo, dar START não substitui a recuperação necessária.


Exemplo de execução por JCL

Comandos Db2 podem ser enviados em batch por meio do processador DSN, dependendo das autorizações e da configuração da instalação.

//DB2CMD  JOB (ACCT),'DB2 COMMAND',
//             CLASS=A,
//             MSGCLASS=X,
//             NOTIFY=&SYSUID
//*
//CMDSTEP  EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB  DD DISP=SHR,DSN=DB2P.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSTSIN  DD *
  DSN SYSTEM(DB2P)
  -DISPLAY DATABASE(DBVENDAS) SPACENAM(TSVENDAS)
  -DISPLAY DDF
  -DISPLAY LOG
  END
/*

Explicação linha por linha

PGM=IKJEFT01

Executa o Terminal Monitor Program do TSO em batch.

DYNAMNBR=20

Reserva alocações dinâmicas para a execução.

STEPLIB

Aponta para a biblioteca de load modules do Db2. O nome varia em cada instalação.

SYSTSPRT

Recebe a saída produzida pela sessão TSO e pelo processador DSN.

SYSPRINT

Recebe mensagens adicionais de programas executados.

SYSUDUMP

Recebe dump em caso de abend.

SYSTSIN

Contém os comandos de entrada para a sessão TSO batch.

DSN SYSTEM(DB2P)

Abre uma sessão com o subsistema indicado.

-DISPLAY ...

Envia o comando operacional ao Db2.

END

Encerra a sessão DSN.

Atenção

Não coloque comandos destrutivos em um JCL genérico deixado em uma biblioteca compartilhada. Um simples submit acidental pode transformar um exemplo didático em incidente.


Tabela de bolso do programador COBOL padawan

SintomaPrimeiro comando
Objeto indisponível-DISPLAY DATABASE
Programa esperando-DISPLAY THREAD
Suspeita de lock-DISPLAY BLOCKERS
API não conecta-DISPLAY DDF
Utility travada-DISPLAY UTILITY
Problema de logging-DISPLAY LOG
Dúvida sobre nível do Db2-DISPLAY GROUP
Stored procedure parada-DISPLAY PROCEDURE
Serviço REST indisponível-DISPLAY RESTSVC
Suspeita de trace esquecido-DISPLAY TRACE

Erros clássicos de iniciantes

1. Executar START DATABASE para qualquer estado restritivo

Nem todo estado é resolvido por START. Alguns exigem COPY, RECOVER, REORG, REBUILD INDEX, CHECK DATA ou outra utility.

2. Usar CANCEL THREAD sem identificar o dono

O token é apenas o identificador técnico. Você também precisa saber:

  • qual aplicação;

  • qual unidade de negócio;

  • qual transação;

  • qual impacto;

  • qual rollback será provocado.

3. Confundir job cancelado com utility terminada

Cancelar o job no JES não garante que todos os recursos e registros da utility foram eliminados do Db2.

4. Usar STOP DATABASE(*)

Curingas são poderosos. Em produção, poder sem escopo é perigo.

5. Usar MODE(FORCE) por impaciência

Se o quiesce não termina, existe uma razão: claims, threads, units of work ou aplicações ainda estão utilizando o recurso.

6. Olhar apenas DSN9022I

O comando pode ter terminado normalmente, mas cada objeto solicitado pode apresentar estado diferente. Leia a resposta completa.

7. Copiar sintaxe de outra versão

Comandos, opções e comportamentos podem variar conforme:

  • versão;

  • function level;

  • APARs e PTFs;

  • modo data sharing;

  • parâmetros locais;

  • produtos adicionais instalados.

O Db2 13 recebe capacidades por function levels e manutenção contínua; portanto, “é Db2 13” não define sozinho todas as funções disponíveis. (IBM)


Vantagens dos comandos do subsistema

  • resposta operacional imediata;

  • integração com console e automação;

  • grande capacidade de diagnóstico;

  • controle granular de componentes;

  • suporte a ambientes data sharing;

  • possibilidade de operação por TSO, SDSF, DB2I e batch;

  • manutenção sem restart para diversas configurações;

  • visibilidade sobre threads, locks, logs e utilities.

Desvantagens e riscos

  • exigem autoridade elevada;

  • alguns comandos têm impacto sistêmico;

  • mensagens podem ser complexas;

  • sintaxe muda conforme o comando;

  • curingas podem ampliar demais o escopo;

  • ações forçadas podem gerar longos rollbacks;

  • alterações dinâmicas podem ser perdidas após restart;

  • um comando correto no subsistema errado continua sendo um comando perigoso;

  • data sharing exige atenção ao escopo de membro ou grupo.


O easter egg final: o hífen que separa dois mundos

Para o programador COBOL, o Db2 costuma parecer uma caixa onde entram instruções SQL:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE NUM_CONTA = :WS-CONTA
END-EXEC.

Mas, por trás dessa consulta, existe uma cidade inteira:

  • threads sendo criadas;

  • locks sendo negociados;

  • pages entrando em buffer pools;

  • logs registrando mudanças;

  • checkpoints delimitando recuperação;

  • utilities reorganizando objetos;

  • DDF conversando com clientes externos;

  • IRLM controlando concorrência;

  • data sharing coordenando membros;

  • stored procedures executando em ambientes WLM;

  • traces registrando o caminho percorrido.

Os comandos do subsistema são as janelas da torre de controle dessa cidade.

O programador iniciante não precisa ter autoridade para executar todos eles. Precisa, porém, saber que existem, compreender suas respostas e conversar com operadores, DBAs e sysprogs usando a linguagem correta.

Quando alguém disser:

“A aplicação está travada, vamos cancelar o job.”

O padawan treinado perguntará:

“Já verificamos a thread, o blocker, o estado do tablespace e a utility registrada?”

Nesse instante, ele deixa de ser apenas alguém que escreve EXEC SQL.

Ele começa a compreender o Db2 como subsistema operacional — e dá seu primeiro passo para se tornar um verdadeiro Jedi do mainframe.

A lista segue a referência atual do Db2 13 for z/OS, mas exemplos que alteram o ambiente devem ser ajustados às autorizações, function level e padrões operacionais da instalação. (IBM)

segunda-feira, 19 de setembro de 2022

De Delphi ao COBOL no IBM Z Você Não Está Abandonando o Desenvolvimento RAD. Está Descobrindo Onde a Engenharia de Software Aprendeu a Nunca Parar.

 

Bellacosa Mainframe do delphi ao cobol no zos

☕ Um Café no Bellacosa Mainframe

De Delphi ao COBOL no IBM Z

Você Não Está Abandonando o Desenvolvimento RAD. Está Descobrindo Onde a Engenharia de Software Aprendeu a Nunca Parar.

Existe uma pergunta que aparece com frequência:

"Eu programo em Delphi. Será que aprender COBOL no Mainframe vai ser difícil?"

Minha resposta quase sempre surpreende.

Não.

Na verdade, desenvolvedores Delphi possuem uma vantagem enorme.

Quem passou anos construindo aplicações comerciais em Delphi aprendeu algo que muitas linguagens modernas deixaram em segundo plano: regras de negócio importam mais do que frameworks.

Enquanto muita gente aprende primeiro React, Angular, Kubernetes, Docker, dezenas de bibliotecas e só depois pensa no problema do cliente, o desenvolvedor Delphi normalmente começou pelo caminho inverso.

Primeiro veio o sistema.

Depois vieram as telas.

Depois o banco de dados.

Depois as regras.

Depois a performance.

Essa mentalidade é exatamente a mesma encontrada dentro do IBM Z.

O que muda não é a engenharia.

É o ambiente.

Pegue seu café.

Vamos conversar.


O Delphi e o Mainframe nasceram para resolver problemas de negócio

Durante décadas, Delphi foi uma das principais plataformas para desenvolvimento de aplicações corporativas.

ERPs.

Controle financeiro.

Folha de pagamento.

Estoque.

Logística.

Automação comercial.

Em praticamente todos esses sistemas existia muito mais regra de negócio do que efeitos visuais.

O IBM Z nasceu exatamente para isso.

Só que em uma escala gigantesca.

Enquanto um sistema Delphi pode controlar uma empresa...

Um sistema COBOL pode controlar milhares delas simultaneamente.


Bellacosa Mainframe Delphi versus cobol no zos

O desenvolvedor Delphi já pensa de forma procedural

Quem programa em Delphi conhece perfeitamente conceitos como:

  • variáveis

  • registros

  • procedimentos

  • funções

  • parâmetros

  • validações

  • arquivos

  • exceções

  • banco de dados

  • SQL

Tudo isso existe no COBOL.

Com outra sintaxe.

Mas a lógica permanece praticamente idêntica.

Você continua recebendo dados.

Processando regras.

Gravando resultados.


A maior mudança não é a linguagem

A maior mudança é descobrir que existe um computador inteiro trabalhando para o seu programa.

No Delphi normalmente pensamos em:

Meu programa.

Meu banco.

Meu usuário.

No Mainframe pensamos em:

Meu programa.

Milhares de usuários.

Centenas de programas.

Filas.

Transações.

Jobs.

Datasets.

Controle de concorrência.

Recuperação automática.

Segurança centralizada.

Tudo isso faz parte do ambiente.


Comparando Delphi e COBOL

Delphi

Normalmente você trabalha com:

  • Forms

  • Eventos

  • Componentes

  • Data Modules

  • FireDAC

  • SQL

  • Objetos

  • Classes

Grande parte do trabalho acontece na interface.


COBOL

O foco muda completamente.

Você trabalha com:

  • processamento

  • dados

  • arquivos

  • transações

  • validações

  • integração

  • desempenho

  • estabilidade

Quase nunca existe interface gráfica.

O programa conversa com:

  • CICS

  • Batch

  • DB2

  • VSAM

  • MQ

  • APIs


O código COBOL costuma ser mais "falado"

Veja um exemplo.

Em Delphi:

if Saldo >= Valor then

Em COBOL:

IF SALDO >= VALOR

Quase igual.

Outro exemplo.

Delphi:

while not EOF do

COBOL:

PERFORM UNTIL EOF

Mais uma vez...

A lógica é praticamente a mesma.


O RECORD do Delphi lembra muito o PIC do COBOL

Em Delphi:

type
TCliente = record

No COBOL:

01 CLIENTE.

Campos.

Tipos.

Tamanhos.

Estruturas.

A ideia continua igual.

Só muda a sintaxe.


String fixa assusta no começo

Delphi trabalha naturalmente com strings variáveis.

COBOL trabalha muito com campos de tamanho fixo.

Por exemplo:

PIC X(30)

Isso inicialmente parece estranho.

Depois de alguns programas você percebe que isso facilita:

  • integração

  • arquivos

  • performance

  • compatibilidade

  • processamento em massa


Delphi ensina algo muito importante

Quem programou Delphi aprendeu a valorizar desempenho.

Isso ajuda muito.

No IBM Z desempenho continua sendo levado extremamente a sério.

Um programa que economiza alguns milissegundos...

Pode economizar milhares de horas de CPU por ano.


Banco de dados continua sendo banco de dados

Se você já usou:

  • FireDAC

  • IBX

  • Zeos

  • ADO

  • dbExpress

Então SQL não será novidade.

A diferença é o banco.

Em vez de:

  • Firebird

  • SQL Server

  • PostgreSQL

  • Oracle

Você encontrará frequentemente:

  • IBM Db2 for z/OS

Mas SELECT continua sendo SELECT.

JOIN continua sendo JOIN.

UPDATE continua sendo UPDATE.


Batch é o "Console Application" em escala industrial

Quem fazia aplicações Console em Delphi entenderá rapidamente o Batch.

A diferença é que o Batch:

  • recebe arquivos enormes;

  • executa milhares ou milhões de registros;

  • produz relatórios;

  • atualiza bases críticas;

  • roda de forma agendada.

O conceito é semelhante.

A escala muda completamente.


CICS lembra um servidor de aplicações

Quem conhece DataSnap, WebBroker, RAD Server ou serviços REST em Delphi perceberá alguns paralelos.

O CICS recebe requisições.

Executa programas.

Controla transações.

Garante consistência.

Gerencia sessões.

A diferença é que faz isso há décadas, com níveis de disponibilidade impressionantes.


O Delphi usa Units.

O COBOL usa COPYBOOKS.

Em Delphi:

uses

No COBOL:

COPY

Os dois evitam duplicação.

Os dois padronizam estruturas.

Os dois facilitam manutenção.


Debug também existe

Muita gente imagina que desenvolver Mainframe significa escrever código às cegas.

Não.

Hoje existem ferramentas modernas como:

  • VS Code

  • Zowe Explorer

  • IBM Developer for z/OS

  • Debug Tool

  • Fault Analyzer

A experiência é muito mais próxima do desenvolvimento moderno do que muitos imaginam.


Git também existe

Outra surpresa.

Hoje é perfeitamente possível trabalhar com:

  • Git

  • GitHub

  • GitLab

  • Azure DevOps

  • Jenkins

  • SonarQube

  • pipelines

Mainframe moderno não vive isolado.

Ele participa do mesmo ecossistema DevOps.


O que um desenvolvedor Delphi precisa aprender?

Etapa 1 — COBOL puro

Antes de pensar em Mainframe, aprenda:

  • DATA DIVISION

  • PROCEDURE DIVISION

  • WORKING-STORAGE

  • FILE SECTION

  • PERFORM

  • IF

  • EVALUATE

  • MOVE

  • COMPUTE

  • STRING

  • UNSTRING

  • INSPECT

  • tabelas (OCCURS)

  • índices

  • SEARCH

  • SEARCH ALL

Treine até escrever programas sem consultar documentação o tempo todo.


Etapa 2 — Arquivos

Aprenda profundamente:

  • Sequential Files

  • VSAM KSDS

  • VSAM ESDS

  • VSAM RRDS

Entenda:

  • leitura;

  • gravação;

  • atualização;

  • chave;

  • organização.

Arquivos continuam sendo extremamente importantes.


Etapa 3 — JCL

Aqui muitos iniciantes assustam.

Mas pense assim:

JCL é o "script de execução" do Mainframe.

Algo entre:

  • Batch Script

  • Shell Script

  • PowerShell

Só que voltado ao ambiente z/OS.

Aprenda:

  • JOB

  • EXEC

  • DD

  • PROC

  • INCLUDE

  • GDG

  • datasets

  • utilitários


Etapa 4 — TSO/ISPF

Você precisa sentir o ambiente.

Aprenda:

  • Edit

  • Browse

  • Allocate

  • Submit

  • SDSF

  • comandos básicos

No início parece antigo.

Depois percebe que é extremamente eficiente.


Etapa 5 — DB2

Aprenda:

  • SQL

  • Embedded SQL

  • Cursor

  • FETCH

  • COMMIT

  • ROLLBACK

  • Bind

  • Package

Quem já conhece SQL sai muito na frente.


Etapa 6 — CICS

Aqui você descobrirá o mundo online.

Aprenda:

  • COMMAREA

  • Channels

  • Containers

  • BMS

  • MAP

  • SEND

  • RECEIVE

  • LINK

  • XCTL

  • RETURN


Etapa 7 — VS Code + Zowe

Não fique preso apenas ao terminal clássico.

Aprenda:

  • Zowe Explorer

  • Git

  • pipelines

  • APIs

  • Debug moderno

O Mainframe de hoje conversa naturalmente com ferramentas modernas.


O que deve treinar diariamente?

Uma sugestão prática.

Segunda-feira

Escreva pequenos programas COBOL.


Terça-feira

Resolva exercícios de manipulação de arquivos.


Quarta-feira

Treine SQL.


Quinta-feira

Monte pequenos JCLs.


Sexta-feira

Faça desafios misturando COBOL + DB2.


Sábado

Leia manuais IBM.

Não para decorar.

Para aprender como a IBM documenta software.

É uma excelente escola de engenharia.


Domingo

Revise tudo.

A repetição constrói confiança.


Habilidades que já vêm do Delphi

Você já sabe:

✓ lógica de programação

✓ modularização

✓ SQL

✓ regras de negócio

✓ depuração

✓ organização do código

✓ manutenção

✓ documentação

✓ tratamento de erros

✓ arquitetura em camadas

Essas competências têm enorme valor no universo IBM Z.


Habilidades novas

Você precisará desenvolver:

  • processamento batch

  • arquitetura z/OS

  • datasets

  • VSAM

  • JCL

  • CICS

  • RACF

  • JES2

  • SDSF

  • controle transacional

  • concorrência

  • alta disponibilidade

  • desempenho em larga escala

São conceitos específicos do ecossistema IBM Z e fazem parte do diferencial de um profissional de Mainframe.


Erros comuns de quem vem do Delphi

O primeiro é tentar transformar COBOL em Delphi. COBOL não é orientado a objetos por natureza; ele privilegia clareza, previsibilidade e regras de negócio explícitas.

O segundo é subestimar o ambiente. No Mainframe, entender o z/OS, o JCL, o escalonamento de jobs e a segurança é tão importante quanto escrever código.

O terceiro é ignorar a documentação. A cultura IBM valoriza manuais, padrões e convenções. Aprender a navegar nessa documentação é uma habilidade profissional.

O quarto é focar apenas na sintaxe. Empresas contratam quem entende processos de negócio, integração e operação, não apenas comandos da linguagem.


Uma trilha de transição em 90 dias

Dias 1–15

  • Fundamentos de COBOL.

  • Estrutura do programa.

  • Variáveis, PIC, IF, PERFORM e EVALUATE.

Dias 16–30

  • Arquivos sequenciais.

  • OCCURS, tabelas, SEARCH.

  • Programas maiores com modularização.

Dias 31–45

  • Introdução ao z/OS.

  • TSO/ISPF.

  • JCL básico.

  • Datasets.

Dias 46–60

  • Db2 for z/OS.

  • SQL embarcado.

  • Cursores.

  • COMMIT e ROLLBACK.

Dias 61–75

  • CICS.

  • Programação transacional.

  • COMMAREA, LINK, XCTL, BMS.

Dias 76–90

  • VS Code + Zowe Explorer.

  • Git.

  • Debug.

  • Integração com APIs.

  • Boas práticas, testes e exercícios completos.

Ao final desse período, você já terá uma visão consistente do ecossistema IBM Z e poderá evoluir para temas como MQ, IMS, z/OS Connect, DevOps e observabilidade.


A maior descoberta

Talvez a maior surpresa para quem vem do Delphi seja perceber que o Mainframe não é um museu tecnológico.

É uma plataforma que evoluiu continuamente por mais de cinquenta anos.

Hoje ela executa APIs REST, Java, Python, Node.js, containers, inteligência artificial e aplicações COBOL lado a lado. O que mudou não foi a missão: continuar processando transações críticas com disponibilidade, segurança e desempenho.

Quando você aprende COBOL no IBM Z, não está trocando uma linguagem moderna por uma antiga. Está ampliando sua visão de engenharia de software para incluir um ambiente onde cada decisão técnica precisa resistir ao tempo, ao crescimento do negócio e a milhões de transações diárias.

E talvez essa seja a maior lição que um desenvolvedor Delphi pode levar para sua carreira: frameworks mudam, interfaces evoluem e linguagens ganham novas versões, mas sistemas que movimentam bancos, seguradoras, governos, companhias aéreas e grandes varejistas continuam exigindo código legível, previsível e confiável.

No fim, Delphi e COBOL compartilham a mesma essência: transformar regras de negócio em software que gera valor. A diferença é que, no IBM Z, essa missão acontece em uma escala que poucos ambientes conseguem alcançar.

Bem-vindo ao Mainframe. O café está servido, e a conversa está apenas começando.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988