☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta COBOL Padawan. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta COBOL Padawan. Mostrar todas as mensagens

quinta-feira, 2 de julho de 2026

Dos Cartões Perfurados ao Enterprise COBOL: A Evolução do STOP RUN e do GOBACK

 

Bellacosa Mainframe e as diferencas entre o goback e o stop run


Dos Cartões Perfurados ao Enterprise COBOL: A Evolução do STOP RUN e do GOBACK

Essa é uma excelente pergunta, e a resposta curta é:

Hoje, em projetos modernos de Enterprise COBOL para z/OS, a IBM e a maioria das empresas recomendam usar GOBACK em vez de STOP RUN. Não é apenas modismo; existem razões técnicas, arquiteturais e de reutilização do ambiente de execução (Language Environment). (IBM)

Vamos analisar como um arquiteto de Mainframe faria.


A origem do STOP RUN

Quando COBOL surgiu na década de 1960, praticamente todos os programas eram executados diretamente pelo sistema operacional.

O fluxo era simples:

JCL
 │
 ▼
Programa COBOL
 │
STOP RUN
 │
 ▼
MVS

Naquela época:

  • não existiam APIs REST;

  • não existiam aplicações reutilizáveis;

  • praticamente não existiam subprogramas complexos;

  • o programa começava e terminava.

O STOP RUN fazia exatamente isso:

"Acabei. Pode encerrar tudo."


O surgimento do GOBACK

Com o crescimento dos sistemas apareceram:

  • subprogramas

  • bibliotecas

  • módulos reutilizáveis

  • CICS

  • IMS

  • DB2

  • Language Environment (LE)

Agora um programa não era mais necessariamente o "programa principal".

Exemplo:

JCL

  MAIN01

     │

 CALL CLIENTE

     │

 CALL CALCJURO

     │

 CALL VALIDA

Imagine se CALCJURO executasse:

STOP RUN

O que aconteceria?

Toda a aplicação terminaria imediatamente.

Não apenas o módulo.

Todo o Run Unit.

É exatamente isso que a IBM documenta. STOP RUN termina toda a Run Unit; já GOBACK retorna ao chamador quando usado em um programa chamado. (IBM)


A grande diferença

STOP RUN

Programa

↓

encerra TODA a Run Unit

↓

retorna ao sistema operacional

GOBACK

Programa

↓

retorna para quem chamou

↓

continua a execução

Se o programa for o principal:

GOBACK

↓

faz praticamente o mesmo trabalho do STOP RUN

A IBM afirma isso explicitamente:

Em um programa principal, GOBACK funciona como STOP RUN. Em um subprograma, GOBACK funciona como EXIT PROGRAM. (IBM)


Exemplo prático

Programa principal

MAIN
CALL "A"

DISPLAY "FIM"

STOP RUN

Programa A

DISPLAY "A"

STOP RUN

Resultado

A

O DISPLAY "FIM"

nunca acontece.


Agora usando GOBACK

Programa A

DISPLAY "A"

GOBACK

Resultado

A

FIM

Porque voltou para o MAIN.


Então por que muitas empresas proíbem STOP RUN?

Não porque ele esteja errado.

Mas porque ele cria risco.

Imagine um programa hoje.

Batch

↓

Framework

↓

Biblioteca

↓

Serviço

↓

Seu Programa

Você nem sempre sabe quem chamou seu módulo.

Se usar

STOP RUN

você encerra toda a aplicação.

Se usar

GOBACK

o programa simplesmente devolve o controle.

Muito mais seguro.


O princípio da reutilização

Hoje escrevemos programas para serem reutilizados.

Um módulo pode ser chamado por:

  • Batch

  • CICS

  • IMS

  • API REST

  • MQ

  • Java

  • z/OS Connect

  • outro COBOL

O módulo não deve assumir que é o "dono" da aplicação.

Ele apenas faz seu trabalho.

Depois devolve o controle.

Isso é exatamente o comportamento do GOBACK.


O impacto no Language Environment (LE)

Aqui está uma das razões mais importantes.

O Enterprise COBOL roda sobre o Language Environment (LE).

O LE controla:

  • memória

  • pilha

  • heap

  • tratamento de exceções

  • inicialização

  • reutilização do runtime

Quando ocorre

STOP RUN

o LE encerra o Run Unit.

Quando ocorre

GOBACK

ele apenas retorna ao chamador.

Isso permite reutilizar o ambiente de execução em muitos cenários. (IBM)


O caso do RTEREUS

Pouca gente conhece essa opção.

Existe um parâmetro do LE chamado

RTEREUS

(Runtime Reuse)

Ele permite reutilizar o ambiente de execução COBOL.

A IBM afirma claramente:

Para obter os benefícios do RTEREUS, substitua STOP RUN por GOBACK. STOP RUN encerra o ambiente reutilizável. (IBM)

Ou seja:

STOP RUN

↓

destrói o ambiente

↓

novo ambiente precisa ser criado

Enquanto

GOBACK

↓

reutiliza o ambiente

↓

menos overhead

Performance

O ganho normalmente não é enorme em um programa isolado.

Mas imagine milhares de execuções por minuto.

1000 programas

↓

cada um recria o Runtime

↓

mais CPU

Com reutilização:

Runtime permanece ativo

↓

menos inicialização

↓

menos CPU

É exatamente por isso que grandes bancos adotam GOBACK como padrão.


E no CICS?

No CICS normalmente termina-se com

EXEC CICS RETURN

e não com

STOP RUN

porque quem controla a aplicação é o CICS.

O mesmo raciocínio vale para IMS.

O programa devolve o controle ao ambiente.

Não encerra a Run Unit.


Um exemplo interessante: DFSORT

A IBM é ainda mais direta na documentação de user exits do DFSORT:

User exits escritos em COBOL não devem usar STOP RUN. Para retornar ao DFSORT, use GOBACK. (IBM)

Ou seja,

STOP RUN

↓

encerra tudo

↓

ERRADO
GOBACK

↓

retorna ao DFSORT

↓

CORRETO

Existe recomendação oficial da IBM?

Sim.

A documentação oficial afirma que:

  • em programas principais, GOBACK tem o mesmo efeito de STOP RUN;

  • em subprogramas, GOBACK retorna ao chamador, enquanto STOP RUN termina toda a Run Unit. (IBM)

Além disso, para ambientes reutilizáveis (RTEREUS), a IBM recomenda trocar STOP RUN por GOBACK. (IBM)

Documentação oficial da IBM:

Minha recomendação para um COBOL Padawan

Se você está desenvolvendo em Enterprise COBOL moderno, adote esta regra simples:

SituaçãoRecomendação
Programa Batch principalGOBACK
Subprograma (CALL)GOBACK
Biblioteca reutilizávelGOBACK
Módulo chamado por Java, CICS, IMS ou APIsGOBACK
Novo desenvolvimentoGOBACK como padrão

Na prática, GOBACK é um superconjunto de STOP RUN: ele faz o papel de STOP RUN quando está no programa principal e o de EXIT PROGRAM quando está em um programa chamado. Isso reduz riscos, melhora a reutilização do runtime e torna o código mais flexível para arquiteturas modernas. Por esse conjunto de vantagens, a preferência atual por GOBACK é muito mais uma decisão de engenharia do que um simples modismo.

Design Patterns no COBOL Mainframe Os Padrões que os Grandes Programadores Sempre Usaram (Mesmo Antes de Eles Receberem um Nome)

 

Bellacosa Mainframe e os design pattern em cobol mainframe

☕ Um Café no Bellacosa Mainframe

Design Patterns no COBOL Mainframe

Os Padrões que os Grandes Programadores Sempre Usaram (Mesmo Antes de Eles Receberem um Nome)

"Todo programador COBOL iniciante acredita que um bom sistema nasce de um bom código. O programador experiente sabe que um bom sistema nasce de boas decisões de arquitetura."

Existe uma curiosidade fascinante na história da computação.

Quando ouvimos falar em Design Patterns, quase todo mundo lembra imediatamente do famoso livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1994 pelo famoso Gang of Four (GoF).

Muitos acreditam que os padrões nasceram ali.

Mas isso não é verdade.

Na realidade, os profissionais de Mainframe utilizavam padrões muito antes de eles receberem nomes elegantes.

Os sistemas bancários dos anos 70, 80 e 90 já possuíam separação de responsabilidades, reutilização de código, módulos especializados, camadas de acesso a banco, mecanismos de validação, tratamento centralizado de erros, componentes compartilhados e arquiteturas extremamente organizadas.

Eles simplesmente não chamavam isso de Pattern.

Chamavam de:

"Boa programação."

E existe um motivo simples.

Quando um sistema precisa sobreviver por 40 anos, processar bilhões de transações e nunca parar, improvisação não funciona.

É por isso que aprender Patterns em COBOL significa aprender como os grandes sistemas do mundo realmente funcionam.

Hoje vamos explorar essa jornada.

Pegue seu café.

Vamos entrar na mente dos arquitetos que construíram os sistemas que movimentam praticamente todo o dinheiro do planeta.


O que é um Pattern?

Pattern significa literalmente:

Padrão de solução.

Não é código.

Não é framework.

Não é biblioteca.

É uma maneira comprovada de resolver um problema recorrente.

Sempre que um problema aparece repetidamente, alguém encontra uma solução elegante.

Depois de milhares de aplicações, essa solução vira um padrão.


A origem dos Patterns

Antes mesmo da computação, um arquiteto chamado Christopher Alexander estudava cidades e construções.

Ele percebeu algo interessante.

As melhores cidades do mundo utilizavam soluções semelhantes para problemas semelhantes.

Uma praça.

Uma rua.

Uma entrada.

Uma janela.

Tudo seguia padrões.

Em 1977 ele publicou:

A Pattern Language.

Décadas depois, programadores perceberam:

"Software também possui problemas repetitivos."

Assim nasceram os Design Patterns modernos.


Mas... e o Mainframe?

Enquanto isso...

Em grandes bancos...

Seguradoras...

Governos...

Empresas aéreas...

Os analistas já utilizavam exatamente a mesma filosofia.

Um exemplo clássico.

Em vez de cada programa acessar DB2 diretamente...

Criava-se um módulo responsável apenas por isso.

Hoje chamaríamos isso de:

DAO Pattern.

Na época era apenas:

"O módulo que conversa com o banco."


Por que Patterns são importantes?

Imagine um hospital.

Você não quer que cada médico invente sua própria forma de operar.

Existe um procedimento.

Uma sequência.

Uma organização.

Software crítico funciona da mesma forma.

Patterns tornam sistemas:

  • previsíveis

  • fáceis de manter

  • fáceis de evoluir

  • seguros

  • reutilizáveis


Pattern 1 — Modularização

O primeiro pattern da história do Mainframe.

Um programa enorme faz tudo.

Depois de alguns anos...

Ninguém entende mais nada.

A solução?

Separar responsabilidades.

Exemplo:

Programa Principal

Validação

Regras de Negócio

DB2

Relatórios

Logs

Cada módulo possui apenas uma função.

Hoje isso parece óbvio.

Na década de 70 era revolucionário.


Como aplicar

Nunca escreva um programa de 5.000 linhas.

Pergunte:

Esta rotina pode virar um subprograma?

Se a resposta for sim...

Faça isso.


Pattern 2 — COPYBOOK Pattern

Uma das maiores invenções do COBOL.

Em vez de repetir estruturas...

Criamos COPYBOOKS.

Exemplo:

Cliente

Conta

Saldo

Endereço

CPF

Esses campos aparecem em centenas de programas.

Sem COPYBOOK...

Bastaria alterar um campo para criar centenas de inconsistências.

Com COPYBOOK...

Uma alteração.

Todos utilizam.


Boas práticas

Nunca copie estruturas manualmente.

Sempre centralize.


Pattern 3 — Validation Layer

Nunca misture validação com regra de negócio.

Errado:

Recebe CPF

Consulta DB2

Calcula juros

Valida CPF

Atualiza saldo

Tudo misturado.

Certo:

Entrada

Validação

Negócio

Persistência


Benefícios

Código mais limpo.

Testes mais simples.

Menos bugs.


Pattern 4 — Error Handler Centralizado

Um clássico absoluto.

Em vez de cada programa escrever mensagens diferentes...

Existe um módulo especializado.

Exemplo:

DISPLAY

ABEND

LOG

RETURN-CODE

Tudo passa por um componente comum.


Vantagens

Padronização.

Auditoria.

Facilidade de suporte.


Pattern 5 — File Access Layer

Em vez de cada programa abrir arquivos VSAM...

Criamos uma camada.

Programa

Arquivo Layer

VSAM

Se amanhã o arquivo virar DB2...

O programa quase não muda.


Isso é desacoplamento

A lógica de negócio não conhece detalhes físicos.

Esse conceito ficou famoso décadas depois.

No Mainframe já era realidade.


Pattern 6 — Database Access Layer

Muito comum em DB2.

Programa

Subprograma SQL

DB2

O programa não conhece SQL.

Conhece apenas serviços.

Exemplo:

Consultar Cliente

Atualizar Saldo

Inserir Conta

Excluir Registro

Muito semelhante aos Repository Patterns modernos.


Pattern 7 — Service Programs

Grandes empresas possuem centenas de programas.

Algumas regras aparecem em todos.

Cálculo de CPF.

Validação de agência.

Máscara.

Data.

Moeda.

Essas regras viram serviços.


Exemplo

CALL "CALCJURO"

CALL "VALIDCPF"

CALL "FORMATA"

CALL "DATAUTIL"

Isso reduz milhares de linhas duplicadas.


Pattern 8 — Dispatcher

Muito usado em CICS.

Um programa recebe uma operação.

Dependendo da função...

Chama outro programa.

Entrada

Dispatcher

Consulta

Inclusão

Alteração

Exclusão

Hoje chamamos isso de Command Dispatcher.


Pattern 9 — Table Driven Programming

Em vez de dezenas de IF...

Utilize tabelas.

Errado:

IF UF = SP

IF UF = RJ

IF UF = MG

...

Melhor:

Tabela de estados.

Pesquisa.

Resultado.

Menos código.

Mais manutenção.


Pattern 10 — Configuration Pattern

Nunca coloque constantes espalhadas.

Crie parâmetros.

Copybooks.

Arquivos.

Tabelas.

Isso evita recompilar programas para pequenas mudanças.


Pattern 11 — Batch Pipeline

Muito usado em processamento noturno.

Leitura

Validação

Transformação

Classificação

Carga

Cada etapa faz apenas uma coisa.

Se uma falhar...

A anterior permanece íntegra.


Pattern 12 — Restart Pattern

Um dos mais importantes.

Imagine um Batch de 8 horas.

Na hora 7 ocorre falha.

Sem Restart...

Tudo começa novamente.

Com Restart...

Continua do último checkpoint.

Essa ideia economiza milhões de dólares todos os anos.


Pattern 13 — Checkpoint Pattern

Muito usado com IMS.

A cada quantidade de registros...

Grava-se um ponto seguro.

Em caso de falha...

Retorna dali.


Pattern 14 — Logging Pattern

Nunca dependa apenas do DISPLAY.

Registre:

Programa

Data

Hora

Usuário

Arquivo

SQLCODE

Chave

Operação

Isso salva equipes inteiras durante incidentes.


Pattern 15 — Retry Pattern

DB2 indisponível?

Arquivo bloqueado?

MQ ocupado?

Em vez de falhar imediatamente...

Tente novamente algumas vezes.

Mas cuidado.

Retry infinito vira desastre.


Pattern 16 — Circuit Breaker (Modernização)

Muito usado via APIs.

Se um serviço externo está indisponível...

Pare de chamá-lo temporariamente.

Evita sobrecarga.


Pattern 17 — Adapter

Muito utilizado na modernização.

Sistema antigo

Adapter

API REST

O COBOL permanece praticamente igual.


Pattern 18 — Facade

Imagine vinte programas acessando vinte módulos.

Complicado.

Criamos uma fachada.

Programa

Facade

Serviços internos

Tudo fica mais simples.


Pattern 19 — Strategy

O cálculo muda conforme o produto.

Em vez de centenas de IF...

Criamos estratégias.

Produto A

Regra A

Produto B

Regra B

Produto C

Regra C


Pattern 20 — Template Process

Muito comum em Batch.

Todos os programas fazem:

Inicialização

Leitura

Processamento

Gravação

Fechamento

Apenas a lógica muda.

A estrutura permanece.


Como identificar quando usar um Pattern

Faça cinco perguntas:

  1. Estou repetindo código?

  2. Esse módulo possui mais de uma responsabilidade?

  3. Se mudar amanhã, quantos programas serão alterados?

  4. Consigo testar isoladamente?

  5. Outra equipe entenderia isso facilmente?

Se várias respostas forem "não"...

Provavelmente existe um Pattern melhor.


Os erros mais comuns dos iniciantes

O famoso "programa monolítico".

Tudo dentro da PROCEDURE DIVISION.

Milhares de linhas.

GO TO para todos os lados.

Variáveis globais.

DISPLAY espalhados.

SQL misturado.

Validação misturada.

Regras misturadas.

Esse tipo de programa funciona...

Até o primeiro incidente em produção.


Como evoluir como Programador COBOL

Existe uma evolução natural.

Nível 1

Aprende sintaxe.

MOVE.

IF.

PERFORM.

READ.

WRITE.


Nível 2

Aprende organização.

Seções.

Parágrafos.

COPYBOOKS.

Subprogramas.


Nível 3

Aprende Patterns.

Reutilização.

Arquitetura.

Modularização.


Nível 4

Aprende integração.

DB2.

CICS.

IMS.

MQ.

REST.

JSON.


Nível 5

Pensa como arquiteto.

Nesse ponto, você não escreve apenas programas.

Você desenha soluções.


Curiosidades

  • Muitos sistemas bancários escritos há mais de 35 anos continuam ativos porque seguiram padrões consistentes.

  • Diversos conceitos popularizados em Java, C# e outras linguagens já eram praticados em ambientes COBOL, ainda que com nomes diferentes.

  • O uso disciplinado de COPYBOOKS foi um dos fatores que permitiu manter aplicações enormes sincronizadas por décadas.

  • Grandes equipes de Mainframe costumam definir padrões internos de nomenclatura, tratamento de erros, chamadas de subprogramas e acesso a dados para reduzir riscos operacionais.


Melhores práticas para o dia a dia

  • Dê a cada programa uma responsabilidade clara.

  • Evite duplicação de lógica.

  • Centralize estruturas em COPYBOOKS.

  • Padronize mensagens de erro.

  • Isole acesso a arquivos e bancos de dados.

  • Documente interfaces de subprogramas.

  • Use nomes consistentes para programas, parágrafos e variáveis.

  • Escreva código pensando em quem fará a manutenção daqui a dez anos.

  • Prefira simplicidade à esperteza.

  • Revise continuamente seu código procurando oportunidades de extrair novos módulos reutilizáveis.


O futuro dos Patterns no Mainframe

O Mainframe moderno conversa com APIs REST, mensageria, microsserviços, Kubernetes, aplicações Java, Python e serviços em nuvem. Nesse cenário, os Patterns clássicos continuam mais relevantes do que nunca. Adapter, Facade, Retry, Circuit Breaker, Service Layer e Repository ajudam a integrar aplicações COBOL com tecnologias modernas sem sacrificar estabilidade.

O profissional que domina esses conceitos deixa de ser apenas um desenvolvedor de programas e passa a ser um engenheiro de soluções. Ele entende quando reutilizar, quando desacoplar, quando encapsular e quando simplificar. Esse conhecimento vale muito mais do que decorar comandos da linguagem.


Conclusão

Existe uma frase muito conhecida entre arquitetos de software:

"Código ruim pode funcionar. Arquitetura ruim cobra juros."

No universo IBM Z, essa cobrança aparece em horas extras, incidentes de produção, dificuldades de manutenção e projetos de modernização cada vez mais caros.

Os Patterns existem justamente para evitar esse cenário. Eles representam décadas de experiência acumulada por milhares de profissionais que enfrentaram os mesmos problemas e encontraram soluções elegantes, reutilizáveis e seguras.

Se você é um Programador COBOL Padawan, não tente memorizar todos os Patterns de uma vez. Comece pelos mais importantes: modularização, COPYBOOKS, validação, tratamento centralizado de erros, acesso a dados desacoplado e reutilização de serviços. À medida que sua experiência crescer, você perceberá que esses padrões aparecem naturalmente em praticamente todos os grandes sistemas corporativos.

Lembre-se: escrever código é uma habilidade. Escrever código que continuará funcionando e sendo compreendido daqui a vinte anos é uma arte. E essa arte é construída com disciplina, boas práticas e padrões sólidos.

No Bellacosa Mainframe, costumamos dizer que o verdadeiro poder de um Programador COBOL não está na quantidade de comandos que ele conhece, mas na qualidade das decisões que toma antes mesmo de começar a digitar a primeira linha de código.

Esse é o caminho que transforma um Padawan em um verdadeiro Mestre do Mainframe.

Se desejar, posso criar a Parte 2 com mais de 3.000 palavras, abordando 40+ Design Patterns específicos para COBOL, CICS, DB2, IMS, Batch, APIs REST, MQ e modernização no IBM Z, com exemplos completos de código COBOL para cada padrão.


quinta-feira, 2 de abril de 2026

☕ O Holocron do Agente IBM Bob Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM

 

Bellacosa Mainframe e o ibm bob

☕ O Holocron do Agente IBM Bob

Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM para Entender, Modernizar e Construir Sistemas Empresariais

"Os antigos Mestres decoravam milhares de comandos. Os novos Mestres ensinam agentes a trabalhar ao seu lado."


Introdução

Durante décadas, um desenvolvedor IBM Z precisava carregar consigo uma espécie de biblioteca mental.

Era necessário conhecer:

  • COBOL

  • JCL

  • DB2

  • VSAM

  • CICS

  • RACF

  • SDSF

  • ISPF

  • MQ

  • Java

  • APIs REST

  • Git

  • Jenkins

  • Ansible

  • OpenShift

Além disso, precisava compreender regras de negócio escritas há quarenta anos por analistas aposentados, interpretar copybooks obscuros e descobrir por tentativa e erro qual programa atualiza determinada tabela.

Em 2025 a IBM decidiu mudar essa história.

Nascia o Project Bob.

Em 2026 ele finalmente se tornou disponível como produto.

O objetivo é bastante ambicioso:

Ter um agente inteligente capaz de acompanhar todo o ciclo de vida do software corporativo.

Não apenas sugerir linhas de código.

Mas pensar junto.

Planejar.

Explicar.

Refatorar.

Gerar testes.

Documentar.

Modernizar aplicações.

Encontrar defeitos.

Auditar segurança.

Criar APIs.

Auxiliar equipes inteiras.

Para um Padawan COBOL, Bob talvez seja a ferramenta mais interessante surgida desde o lançamento do Enterprise COBOL 6.x.


O que é IBM Bob?

IBM Bob é um AI Coding Agent desenvolvido pela IBM.

Diferentemente dos copilotos tradicionais, Bob trabalha como um agente de desenvolvimento.

Ele atua durante praticamente todo SDLC.

SDLC significa:

Software Development Life Cycle.

Bob pode ajudar em:

Planejamento

Análise

Codificação

Testes

Documentação

Segurança

Modernização

Entrega

Em vez de apenas responder perguntas, Bob executa fluxos completos de trabalho.

IBM chama isso de:

Agentic Development

ou

Agentic SDLC


A origem do Projeto

Bob não apareceu do nada.

Ele é resultado da convergência de vários projetos IBM.

Watsonx Code Assistant for Z

Lançado em 2023.

Objetivo:

Auxiliar modernização COBOL.

Funções:

Explicar código

COBOL → Java

Gerar documentação

Analisar aplicações


Code Assistant for RPG

Criado pelo laboratório Rochester.

Focado em IBM i.


Granite

LLM desenvolvido pela IBM.


Anthropic Claude

IBM anunciou parceria para ampliar capacidades de engenharia.


Em outubro de 2025, durante o TechXchange, surgiu oficialmente:

Project Bob

Em março de 2026 surgiu a primeira versão pública.

Versão:

Bob 1.0

Data aproximada de disponibilidade:

24 Março 2026.

Atualmente existe inclusive um pacote denominado:

IBM Bob Premium Package for Z.


Por que o nome Bob?

IBM nunca divulgou oficialmente uma explicação definitiva.

Mas existe uma curiosidade interessante.

Muitos desenvolvedores brincam dizendo:

Bob é o "Bob The Builder" corporativo.

Ele não destrói aplicações.

Ele conserta.

Moderniza.

Documenta.

Amplia.

Protege.

Algo extremamente alinhado ao universo IBM Z.

Em vez de substituir programadores, Bob funciona como um companheiro.


O que Bob consegue fazer?

1 — Explicar COBOL

Prompt:

Explique este programa COBOL.

Bob responde:

Regras de negócio

Arquivos usados

Campos

Dependências

Fluxos

Excelente para sistemas bancários.


2 — Criar documentação

/document

Pode gerar:

Markdown

README

Diagramas

Comentários

Arquitetura


3 — Testes

Exemplo:

/unit-test

Pode produzir:

JUnit

PyTest

Testes Java

Estruturas automatizadas


4 — Revisão de código

Pergunta:

Existem problemas neste programa COBOL?

Bob pode apontar:

PERFORM incorreto

GO TO excessivo

dead code

duplicação

bugs


5 — Segurança

Detecta:

SQL Injection

credenciais

falhas


6 — Modernização

Talvez seja a parte mais interessante.

Bob consegue auxiliar:

COBOL

Serviços COBOL

APIs

Java


Onde usar Bob?

Atualmente Bob trabalha principalmente integrado ao:

Visual Studio Code

CLI

Ambientes SaaS

IBM Cloud

Sistemas:

Windows

Linux

MacOS


Como testar gratuitamente

Passo 1

Criar conta IBM.

Passo 2

Solicitar Trial.

Acesse:

IBM Bob

ou

bob.ibm.com


Passo 3

Instalar VSCode


Passo 4

Instalar extensão

IBM Bob


Passo 5

Login

IBM ID


Passo 6

Abrir projeto

COBOL

Python

Java


Passo 7

Conversar

Exemplo:

Explique este COPYBOOK

Documente este programa

Crie testes

Faça refatoração

Sugira API REST


Primeiro laboratório para um Padawan COBOL

Pegue um programa antigo.

Exemplo:

CALCSAL.cbl

Pergunte:

Explique este programa.

Depois:

Crie documentação Markdown.

Depois:

Gere casos de teste.

Depois:

Sugira melhoria COBOL 6.5.

Depois:

Transforme em serviço REST.

Você verá praticamente um assessment sendo realizado em minutos.


Comandos interessantes

Embora Bob esteja evoluindo, comandos similares aos usados no WCA aparecem frequentemente.

/document

Documentação


/unit-test

Testes


/review

Code review


/explain

Explicação


/refactor

Refatoração


/security

Auditoria


/plan

Planejamento


/generate

Código novo


Exemplo prático

Pergunta:

Tenho um programa COBOL que atualiza saldo de conta.

Bob pode responder:

Programa principal identificado.

Copybooks encontrados.

Tabela DB2 utilizada.

Transação CICS relacionada.

Dependências localizadas.

Sugestão de API:

GET /saldo

POST /debito

POST /credito

Em alguns minutos.

Algo que antigamente levava dias.


Curiosidades

Bob utiliza arquitetura multi-modelo.

Pode combinar:

Granite

Claude

Llama

Mistral

Dependendo da tarefa.


Mais de seis mil desenvolvedores IBM já utilizavam Bob internamente antes do lançamento público.


Bob é considerado sucessor natural do:

Watsonx Code Assistant for Z


Existe forte foco em:

COBOL

PL/I

RPG

Java

JCL

Mainframe


Dicas para começar

Dica 1

Não tente gerar sistemas inteiros.

Comece pequeno.


Dica 2

Use programas COBOL simples.

100 linhas.

200 linhas.


Dica 3

Peça explicações.

Aprenda observando.


Dica 4

Valide tudo.

IA erra.

Sempre.


Dica 5

Construa biblioteca própria.

Prompts úteis:

Explique para um iniciante.

Mostre fluxograma.

Identifique regras.

Crie README.

Faça ZUnit.

Gerar OpenAPI.

Criar testes.

Migrar para COBOL 6.5.


Como aprofundar conhecimentos

Estude:

Enterprise COBOL 6.5

VSCode

Zowe

Git

OpenAPI

REST

JUnit

Ansible

Watsonx

Granite

RAG

MCP Servers

Agentic AI

Leia documentação IBM.

Assista TechXchange.

Teste diariamente.

Uma hora por dia é suficiente.


Considerações Finais

O IBM Bob representa uma mudança semelhante à chegada do ISPF para quem programava apenas com editores lineares.

Ele não substitui experiência.

Não conhece sozinho todas as regras de negócio.

Não entende automaticamente quarenta anos de exceções bancárias.

Mas reduz drasticamente o tempo gasto procurando informações espalhadas em milhares de programas.

Para o Padawan COBOL, Bob pode ser visto como um novo Holocron.

Um Holocron que não apenas guarda conhecimento, mas conversa, explica, ensina, sugere melhorias e ajuda a transformar aplicações legadas em ativos preparados para a próxima década.

E talvez esta seja a maior lição deixada pelo agente da IBM:

O futuro do desenvolvedor Mainframe não será escrever menos COBOL. Será aprender a trabalhar ao lado de agentes capazes de compreender COBOL tão profundamente quanto nós aprendemos a compreendê-lo ao longo dos anos.


quinta-feira, 27 de julho de 2023

Lambda Expressions no Java: O Manual Definitivo para um Programador COBOL Padawan Entender o Operador -> sem Medo (e Descobrir que Ele Não é Magia)

 

Bellacosa Mainframe e a lambda expressions no Java

☕ Um Café no Bellacosa Mainframe

Lambda Expressions no Java: O Manual Definitivo para um Programador COBOL Padawan Entender o Operador -> sem Medo (e Descobrir que Ele Não é Magia)

"Todo programador COBOL já passou por isso: você abre um código Java moderno e encontra algo como (x) -> x * 2. Sua primeira reação é pensar: 'Quem apagou metade do programa?' A boa notícia é que ninguém apagou nada. Você está olhando para uma Lambda Expression."


Introdução

Se você trabalha há anos no universo IBM Z, provavelmente sua realidade é composta por tecnologias como:

  • COBOL

  • JCL

  • CICS

  • IMS

  • Db2

  • MQ

  • VSAM

  • z/OS

  • REXX

  • PL/I

Neste mundo, tudo costuma ser muito explícito.

Você declara.

Você identifica.

Você define.

Você documenta.

Você implementa.

Já no mundo Java moderno acontece exatamente o contrário.

Quanto menos código existir, melhor.

É aí que surgem as Lambda Expressions, introduzidas oficialmente no Java 8 (2014).

Para muitos profissionais Mainframe, elas parecem um idioma alienígena.

Mas a verdade é outra.

Você já conhece o conceito.

Só não conhece a sintaxe.


Antes de tudo…

Existe Arrow Function em Java?

Tecnicamente...

Não.

O nome Arrow Function pertence ao JavaScript.

No Java o nome correto é:

Lambda Expression

O símbolo é exatamente o mesmo conceito visual:

->

Por isso muita gente chama informalmente de Arrow Function.


Por que a IBM adicionou Lambdas ao Java?

A resposta é simples:

Performance + produtividade.

Na década de 2000, Java era conhecido por ser extremamente verboso.

Para executar uma simples ação era comum escrever dezenas de linhas.

Exemplo antigo:

Collections.sort(lista, new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return a.compareTo(b);
    }
});

Mais de dez linhas.

Hoje:

lista.sort((a,b) -> a.compareTo(b));

Uma linha.

Muito mais legível.


Mas o que é uma Lambda?

A definição acadêmica diz:

Uma função anônima.

Mas para um COBOL Padawan eu prefiro outra definição.

Pense nela como um PARÁGRAFO temporário.

No COBOL fazemos isso:

PERFORM CALCULAR-TOTAL

E em algum lugar existe:

CALCULAR-TOTAL.

    COMPUTE WS-TOTAL =
        WS-VALOR1 +
        WS-VALOR2.

EXIT.

No Java moderno, às vezes não vale a pena criar um método inteiro.

Você simplesmente entrega a lógica diretamente.

Algo parecido com:

(a,b) -> a+b

É como dizer:

"Aqui está o código. Execute quando precisar."


O significado do operador ->

Observe:

(a,b) -> a+b

Lendo em português:

Receba A

Receba B

Execute

Retorne A+B

Visualmente:

ENTRADA
   │
   ▼
(a,b)
   │
   ▼
   ->
   │
   ▼
a+b
   │
   ▼
SAÍDA

O operador -> separa:

lado esquerdo

parâmetros

lado direito

implementação


Comparando com COBOL

COBOL:

ADD A TO B GIVING C

Java:

(a,b) -> a+b

A intenção é praticamente igual.

A diferença é que no Java essa operação pode ser passada como parâmetro.


Uma mudança de paradigma

Durante décadas escrevemos programas assim:

Programa

↓

Métodos

↓

Chamadas

Com Lambdas passamos a escrever:

Programa

↓

Comportamentos

↓

Funções

↓

Funções recebendo funções

Isso é programação funcional.


Um exemplo simples

Sem Lambda:

Runnable tarefa = new Runnable() {

    @Override
    public void run() {

        System.out.println("Executando");

    }

};

Com Lambda:

Runnable tarefa =
    () -> System.out.println("Executando");

Mesmo comportamento.

Muito menos código.


O que mudou?

Antes era necessário criar uma classe anônima.

Agora basta informar:

  • parâmetros

  • comportamento


Quando usar ()

Sem parâmetros:

() -> ...

Um parâmetro:

x -> ...

Dois parâmetros:

(a,b) -> ...

Três parâmetros:

(a,b,c) -> ...

Quando usar chaves?

Uma linha:

x -> x*2

Mais de uma:

x -> {

    System.out.println(x);

    return x*2;

}

O retorno implícito

Observe:

x -> x+1

Não existe:

return

O Java entende automaticamente.

Já quando usamos bloco:

x -> {

    return x+1;

}

O return passa a ser obrigatório.


Interfaces Funcionais

Aqui existe uma diferença enorme para JavaScript.

No Java você não cria uma Lambda do nada.

Ela precisa implementar uma interface.

Exemplo:

@FunctionalInterface

interface Soma {

    int executar(int a,int b);

}

Uso:

Soma s =
    (a,b) -> a+b;

Pronto.

Sua Lambda implementou automaticamente a interface.


O segredo está na @FunctionalInterface

Ela permite apenas:

um único método abstrato.

Isso faz o compilador saber exatamente qual método será implementado.


Onde as Lambdas aparecem no Java moderno?

Praticamente em toda parte.

Principalmente em:

  • Streams

  • Comparator

  • Runnable

  • CompletableFuture

  • ExecutorService

  • Optional

  • Collections

  • APIs REST

  • Spring Boot

  • Jakarta EE

  • IBM Semeru Runtime

  • Open Liberty

Ou seja...

Se você pretende trabalhar com Java no IBM Z...

Vai encontrá-las diariamente.


Streams

Imagine uma lista.

List<Integer> numeros =
List.of(1,2,3,4,5);

Filtrar pares:

numeros.stream()

.filter(n -> n%2==0)

.forEach(System.out::println);

A Lambda diz apenas:

Receba um número

↓

Se for par

↓

Retorne verdadeiro

Comparando com COBOL

No COBOL seria algo como:

PERFORM VARYING IDX
FROM 1 BY 1

UNTIL IDX > MAX

    IF NUMERO(IDX)
       MOD 2 = ZERO

       DISPLAY NUMERO(IDX)

    END-IF

END-PERFORM

No Java:

.filter(n->n%2==0)

O comportamento é exatamente o mesmo.


Comparator

Ordenar nomes.

Antes:

mais de quinze linhas.

Hoje:

lista.sort(

(a,b)->a.compareTo(b)

);

Method Reference

Existe algo ainda menor.

Em vez de:

x -> System.out.println(x)

Podemos escrever:

System.out::println

Isso se chama:

Method Reference.

É praticamente uma Lambda reduzida.


Predicate

Representa perguntas.

Predicate<Integer> par =

n -> n%2==0;

É equivalente a:

É par?

↓

Sim ou Não

Function

Transforma algo.

Entrada:

Nome

Saída:

Maiúsculo
nome -> nome.toUpperCase()

Consumer

Recebe.

Consome.

Não devolve nada.

x -> System.out.println(x)

Supplier

Não recebe nada.

Mas produz.

() -> UUID.randomUUID()

Curiosidade

O nome Lambda vem da matemática.

Mais especificamente do Lambda Calculus, criado por Alonzo Church, em 1936.

Muito antes da invenção do COBOL.

Muito antes do Java.

Muito antes do C.


Alan Turing conhecia Lambdas?

Sim.

Church e Turing trabalharam praticamente na mesma época.

Os dois provaram matematicamente que era possível criar computação universal.


Então Java virou linguagem funcional?

Não.

Java continua sendo:

  • Orientado a Objetos

Mas ganhou recursos funcionais.


O que acontece na memória?

Muita gente imagina que uma Lambda cria um objeto enorme.

Na verdade não.

O compilador gera bytecode especial usando:

invokedynamic

Introduzido na JVM 7.

Depois entra em ação:

LambdaMetafactory

Ela cria dinamicamente uma implementação da interface funcional.

Ou seja...

Não existe necessariamente uma classe física como antigamente.


O papel do invokedynamic

Antes do Java 8:

Classe anônima

↓

Compilador

↓

Novo .class

Depois:

Lambda

↓

invokedynamic

↓

JVM

↓

Objeto criado dinamicamente

Muito mais eficiente.


Performance

Na maioria dos casos:

Lambda é mais rápida que classe anônima.

Por quê?

Porque:

  • menos bytecode

  • menos classes

  • melhor otimização JIT

  • HotSpot entende melhor o fluxo

No IBM Semeru Runtime isso também acontece.


Existe custo?

Sim.

Toda abstração possui custo.

Mas normalmente ele é insignificante.


Captura de variáveis

Exemplo:

int valor = 10;

Function<Integer,Integer> soma =

n -> n + valor;

Funciona.

Agora:

valor++;

Erro.

Por quê?

Porque a variável precisa ser:

effectively final.


Por que isso existe?

Para evitar problemas de concorrência.

Imagine:

100 Threads.

Todas alterando a mesma variável.

Seria um desastre.


O coletor de lixo

As Lambdas normalmente vivem pouco.

São excelentes candidatas para o Young Generation da JVM.

Resultado:

coleta extremamente rápida.


Java no IBM Z

Se você usa:

  • IBM Semeru Runtime

  • OpenJ9

  • Liberty

  • Spring Boot

  • z/OS Connect

Você está usando Lambdas o tempo inteiro.

Mesmo sem perceber.


Limitações

Nem tudo são flores.

Algumas limitações:

  • não possuem estado próprio

  • não substituem classes

  • não substituem objetos complexos

  • podem reduzir legibilidade quando abusadas

  • debugging pode ficar mais difícil

  • stack traces às vezes ficam estranhos


Pontos fortes

✔ Menos código

✔ Mais legibilidade

✔ Melhor integração com Streams

✔ Melhor paralelismo

✔ Melhor manutenção

✔ Melhor otimização da JVM

✔ Código moderno


Pontos fracos

✘ Curva de aprendizado

✘ Sintaxe inicialmente estranha

✘ Pode esconder lógica demais

✘ Debug mais complexo

✘ Não substitui arquitetura


Dicas para quem vem do COBOL

Não tente decorar a sintaxe.

Entenda a ideia.


Sempre pergunte:

"Esse trecho está apenas descrevendo um comportamento?"

Se sim...

Provavelmente cabe uma Lambda.


Streams + Lambdas são inseparáveis.

Aprenda ambos juntos.


Evite Lambdas gigantes.

Se passou de cinco ou seis linhas...

Crie um método.


Prefira Method Reference

Quando possível.

Em vez de:

x -> System.out.println(x)

Faça:

System.out::println

Easter Eggs

1. Nem toda Lambda gera um novo objeto.

A JVM pode reutilizar instâncias.


2. Uma Lambda pode não existir como classe.

Ao contrário das antigas Anonymous Classes.


3. O compilador gera métodos sintéticos.

Eles aparecem como:

lambda$0

lambda$1

lambda$2

Dentro do bytecode.


4. javap revela a mágica

Compile:

javac Exemplo.java

Depois:

javap -c -v Exemplo.class

Você verá instruções como:

  • invokedynamic

  • BootstrapMethods

  • referências ao LambdaMetafactory

É uma ótima forma de entender o que a JVM realmente executa.


5. Lambdas e paralelismo

Elas combinam naturalmente com:

parallelStream()

Mas atenção: paralelo não significa automaticamente mais rápido. Em cargas pequenas, o custo de dividir o trabalho pode superar o ganho.


Fazendo a ponte para o mundo Mainframe

Se você é um Programador COBOL Padawan, pense assim:

  • Um PERFORM executa um bloco identificado pelo nome.

  • Uma Lambda entrega esse bloco diretamente para quem vai executá-lo.

  • Um IF do COBOL pode virar um Predicate.

  • Uma rotina de transformação de registros pode virar uma Function.

  • Um DISPLAY pode ser representado por um Consumer.

O paradigma muda, mas o raciocínio continua familiar: dados entram, uma lógica é aplicada e um resultado é produzido.


Conclusão

As Lambda Expressions não vieram para substituir a Programação Orientada a Objetos, muito menos os princípios sólidos que sustentam aplicações corporativas. Elas surgiram para reduzir código repetitivo, aumentar a expressividade e permitir que o desenvolvedor descreva comportamentos da mesma forma que descreve dados.

Para quem vem do universo IBM Z, elas representam mais uma evolução do que uma revolução. Você já domina lógica estruturada, modularização, processamento em lote, concorrência, desempenho e confiabilidade. O desafio agora é aprender uma nova forma de expressar essas mesmas ideias.

No fim das contas, a Lambda é apenas uma ferramenta. Ela não torna um sistema melhor por si só. Assim como um bom PERFORM, ela precisa ser usada no lugar certo, com clareza e equilíbrio.

E talvez essa seja a maior lição para todo COBOL Padawan que começa a explorar Java no Mainframe: a tecnologia muda, a boa engenharia de software permanece.


segunda-feira, 9 de maio de 2022

GIT - O Que Todo Programador COBOL Padawan Precisa Saber Sobre Controle de Versão Profissional na Era da Inteligência Artificial, DevOps e IBM Mainframe

 

Bellacosa Mainframe muito alem do git commit

☕ Um Café no Bellacosa Mainframe

Git Muito Além do git commit

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Controle de Versão Profissional na Era da Inteligência Artificial, DevOps e IBM Mainframe

"Existe uma enorme diferença entre saber usar comandos do Git e compreender como o Git realmente pensa. É exatamente essa diferença que separa um programador que apenas grava código de um engenheiro de software capaz de colaborar em projetos globais."


Introdução

Recentemente encontrei uma imagem bastante interessante intitulada "Top 20 Git Commands Every Developer Should Know". À primeira vista, ela parece apenas mais um resumo para consulta rápida.

Ela lista comandos como:

  • git init

  • git clone

  • git add

  • git commit

  • git push

  • git pull

e muitos outros.

Para um desenvolvedor iniciante, essa imagem parece representar praticamente todo o universo do Git.

Mas existe um detalhe importante.

Ela mostra o volante, o acelerador e o freio.

Ela não mostra o motor.

E quem trabalha com sistemas críticos — especialmente quem vem do universo IBM Mainframe — sabe que entender somente os comandos nunca foi suficiente.

No mundo do z/OS não basta decorar:

IEFBR14

É preciso entender:

  • JES2

  • Address Space

  • Dispatching

  • Storage

  • Dataset Catalog

  • VSAM

  • RACF

  • SMF

  • WLM

Da mesma forma, no Git não basta decorar comandos.

É preciso entender a arquitetura.

Hoje vamos tomar um café e mergulhar no funcionamento interno do Git.


Git não é apenas um programa

O Git é um Sistema Distribuído de Controle de Versão (Distributed Version Control System - DVCS).

Essa definição parece simples.

Mas ela muda completamente a forma como o desenvolvimento acontece.

Antes do Git existiam ferramentas como:

  • CVS

  • SourceSafe

  • SVN

Todas eram centralizadas.

Imagine um servidor.

Servidor

     Projeto

Todos os desenvolvedores dependiam dele.

Se o servidor parasse...

Ninguém trabalhava.

Se a rede caísse...

Ninguém fazia commit.


O Git mudou completamente essa arquitetura

Quando você executa:

git clone

Você não baixa apenas os arquivos.

Você baixa:

  • todos os commits

  • todas as branches

  • todas as tags

  • todo o histórico

Na prática, você cria um espelho completo do repositório.

É como se cada desenvolvedor carregasse um mini GitHub dentro do notebook.


Fazendo uma analogia com o Mainframe

Imagine um enorme PDS onde vivem todos os programas COBOL.

Agora imagine que cada desenvolvedor possui uma cópia completa daquele PDS, incluindo todas as versões desde a criação do sistema.

É exatamente isso que o Git faz.

Só que muito melhor.


A pasta mais importante do projeto

Quando executamos:

git init

Algo aparentemente simples acontece.

É criada uma pasta escondida.

.git

Muitos iniciantes ignoram essa pasta.

Grande erro.

É nela que mora todo o Git.

Se ela desaparecer...

O histórico desaparece.

Os commits desaparecem.

As branches desaparecem.

As tags desaparecem.

O projeto volta a ser apenas uma pasta comum.


O que existe dentro da pasta .git?

Normalmente encontramos algo parecido com isto:

.git

objects

refs

HEAD

config

hooks

logs

index

packed-refs

Cada item possui uma função específica.


objects

É o verdadeiro banco de dados do Git.

Tudo fica aqui.

Arquivos.

Commits.

Branches.

Trees.

Tags.

Tudo.


refs

São os ponteiros.

Eles dizem onde cada branch está.


HEAD

É o famoso ponteiro atual.

Sempre indica onde você está trabalhando.


config

Contém toda configuração local.

Usuário.

Email.

Remotos.

Aliases.


hooks

Automação.

Podemos executar scripts antes de:

  • commit

  • push

  • merge

Muito usado em DevOps.


O Git não salva diferenças

Essa talvez seja a maior surpresa para quem começa.

Muitos acreditam que o Git grava apenas as linhas modificadas.

Não.

Ele trabalha principalmente com snapshots.

Imagine um diretório.

Projeto

Programa1.cbl

Programa2.cbl

JCL1.jcl

README.md

Quando fazemos:

git commit

O Git registra um retrato completo daquele momento.

Como uma fotografia.

Não apenas um patch.

Isso torna a recuperação extremamente eficiente.


Os quatro tipos de objetos do Git

O banco interno do Git possui apenas quatro tipos fundamentais.

Blob

Representa o conteúdo de um arquivo.

Não conhece nomes.

Não conhece diretórios.

Conhece apenas bytes.


Tree

Organiza os blobs.

Funciona como um diretório.


Commit

Liga uma árvore ao histórico.

Contém:

  • autor

  • data

  • mensagem

  • commit anterior


Tag

Marca um commit especial.

Normalmente versões:

v1.0

v2.0

Release-2026

SHA: a identidade única de tudo

Cada objeto recebe um hash.

Exemplo:

c83f92b15c4...

Esse hash é calculado sobre o conteúdo.

Se um único byte mudar...

Todo o hash muda.

Essa característica garante integridade.


Os três estados dos arquivos

Esse é provavelmente o conceito mais importante do Git.

Todo arquivo percorre três etapas.

Working Directory

↓

Staging Area

↓

Repository

Working Directory

É onde editamos.

Abrimos o COBOL.

Mudamos um SELECT.

Alteramos um PERFORM.

Ainda não existe histórico.


Staging Area

É uma área intermediária.

O comando:

git add

Não grava nada.

Ele apenas prepara.

É como colocar documentos sobre a mesa antes de arquivá-los.


Repository

Somente quando executamos:

git commit

O histórico realmente nasce.


Git Status

Se existisse apenas um comando obrigatório seria:

git status

Ele responde perguntas como:

  • O que mudou?

  • O que será enviado?

  • O que ainda não entrou no commit?

Executar esse comando diversas vezes ao longo do dia é uma excelente prática.


Git Add

Existe uma diferença enorme entre:

git add arquivo.cbl

e

git add .

O primeiro adiciona apenas um arquivo.

O segundo adiciona praticamente tudo.

Isso inclui arquivos temporários.

Logs.

Arquivos de configuração.

Até senhas esquecidas.

Daí nasce a importância do:

.gitignore

Git Ignore

Imagine esquecer dentro do projeto:

senha.txt

backup.zip

log.txt

database.db

Sem o .gitignore, tudo isso pode ir para o repositório.

Alguns vazamentos famosos de credenciais ocorreram exatamente por causa disso.


Commits são sua documentação

Existe um velho hábito ruim.

Update

Outro.

Correções

Outro.

Mudanças

Meses depois...

Ninguém sabe o que foi alterado.

Uma boa mensagem explica a intenção.

Por exemplo:

Valida CPF antes da gravação no DB2

ou

Corrige cálculo do IOF para operações acima de R$ 50.000

Muito mais útil.


Branches: linhas paralelas de desenvolvimento

Imagine um banco.

Enquanto uma equipe trabalha no PIX...

Outra trabalha no Open Finance.

Outra corrige produção.

Tudo ao mesmo tempo.

Isso só é possível porque existem branches.

main

├── feature-pix

├── feature-openfinance

└── hotfix

Cada equipe trabalha isoladamente.


Merge

Quando uma funcionalidade termina:

feature-pix

ela precisa voltar para:

main

É aqui que entra o:

git merge

Ele une dois históricos.


Conflitos

Imagine dois desenvolvedores alterando a mesma linha.

Um escreve:

MOVE ZERO TO WS-TOTAL.

Outro escreve:

MOVE WS-VALOR TO WS-TOTAL.

Quem está certo?

O Git não decide.

Ele apresenta:

<<<<<<<
=======
>>>>>>>

E cabe ao desenvolvedor resolver.


Fetch versus Pull

Muitos iniciantes acreditam que são iguais.

Não são.

git fetch

Baixa novidades.

Mas não altera seu trabalho.

Já:

git pull

Baixa e integra imediatamente.

É praticamente:

fetch

+

merge

Em projetos críticos, muitos profissionais preferem primeiro:

git fetch

Analisar.

Depois integrar.


Push

Sem ele ninguém verá seu trabalho.

git push

Envia seus commits ao servidor.

É a promoção do desenvolvimento local para o repositório compartilhado.


Git Diff

Antes de qualquer commit execute:

git diff

Você verá exatamente:

-

+

Tudo que será enviado.

Isso evita inúmeros erros.


Git Stash

Imagine este cenário.

Você está desenvolvendo uma API.

Surge uma emergência em produção.

Você ainda não pode fazer commit.

O que fazer?

git stash

Ele guarda temporariamente tudo.

Depois:

git stash pop

Seu trabalho retorna exatamente como estava.


Git Reset

Esse comando merece respeito.

Especialmente:

git reset --hard

Ele pode apagar alterações locais sem possibilidade simples de recuperação.

Não é um comando para testar.

É um comando para compreender profundamente antes de usar.


O verdadeiro poder das branches

No Git, uma branch é extremamente leve.

Ela não copia o projeto.

Ela cria apenas um ponteiro.

Por isso podemos criar dezenas ou centenas delas.


O Git e o DevOps

Hoje praticamente toda pipeline utiliza Git.

Por exemplo:

Commit

↓

GitHub

↓

GitHub Actions

↓

Build

↓

Testes

↓

Deploy

↓

Produção

Sem Git praticamente não existe DevOps moderno.


GitHub não é Git

Outro erro muito comum.

Git é uma tecnologia.

GitHub é um serviço.

Também existem:

  • GitLab

  • Bitbucket

  • Azure DevOps

  • Gitea

  • Forgejo

Todos utilizam Git.


Git e Inteligência Artificial

Ferramentas como:

  • GitHub Copilot

  • ChatGPT

  • Claude

  • Gemini

podem escrever código.

Mas todas dependem de algo extremamente importante.

Histórico.

Contexto.

Versionamento.

Quando uma IA gera uma alteração, ela precisa ser rastreável.

Quem alterou?

Quando?

Por quê?

Qual problema resolveu?

Git responde todas essas perguntas.


Git no universo IBM Mainframe

Durante muitos anos o desenvolvimento Mainframe utilizou ferramentas como:

  • Endevor

  • Changeman

  • Librarian

  • Panvalet

Hoje muitas empresas estão integrando esses ambientes ao Git.

Isso permite:

  • CI/CD

  • Pull Requests

  • Code Review

  • Integração com Jenkins

  • GitHub Actions

  • Azure DevOps

  • IBM Dependency Based Build (DBB)

  • Zowe CLI

  • VS Code

  • OpenShift

  • Ansible

O código COBOL continua executando no IBM Z, mas o ciclo de desenvolvimento passa a seguir práticas modernas de engenharia de software.


Git para um COBOL Padawan

Se você está iniciando na programação COBOL, encare o Git como uma habilidade tão importante quanto aprender:

  • IF

  • PERFORM

  • EVALUATE

  • READ

  • WRITE

  • EXEC SQL

  • CICS LINK

Hoje um profissional que domina apenas a linguagem perde competitividade.

As empresas procuram desenvolvedores que também entendam de colaboração, automação, revisão de código e integração contínua.


Boas práticas para o dia a dia

Algumas recomendações fazem enorme diferença:

  • Faça commits pequenos e frequentes.

  • Cada commit deve representar uma única alteração lógica.

  • Escreva mensagens claras e objetivas.

  • Nunca desenvolva diretamente na branch main.

  • Revise as mudanças com git diff antes de cada commit.

  • Consulte git status constantemente.

  • Configure um .gitignore adequado ao seu projeto.

  • Prefira git fetch quando quiser analisar alterações antes de integrá-las.

  • Evite git reset --hard sem compreender totalmente suas consequências.

  • Utilize Pull Requests para revisão de código e compartilhamento de conhecimento.


Conclusão

O Git é muito mais do que uma coleção de comandos. Ele representa uma mudança de paradigma na forma como construímos software, promovendo colaboração, rastreabilidade e segurança. Para o programador COBOL Padawan, dominar essa ferramenta significa conectar décadas de experiência em sistemas corporativos às práticas modernas de DevOps, integração contínua e desenvolvimento assistido por Inteligência Artificial.

Assim como aprender JCL vai muito além de decorar //JOB e //EXEC, aprender Git vai muito além de executar git add, git commit e git push. O verdadeiro diferencial está em compreender sua arquitetura interna, seus objetos, seus fluxos de trabalho e a filosofia que sustenta um dos projetos de software mais influentes da história.

No universo Bellacosa Mainframe, o Git não substitui a disciplina que sempre caracterizou o desenvolvimento em IBM Z — ele a amplia. Ele oferece mecanismos para preservar conhecimento, facilitar auditorias, permitir revisões estruturadas e integrar aplicações legadas a pipelines modernas de entrega contínua. Em uma era em que a Inteligência Artificial acelera a escrita de código, o Git continua sendo a memória confiável do projeto, registrando cada decisão técnica e garantindo que a evolução do software seja transparente, reproduzível e segura.

O conselho final para todo COBOL Padawan é simples: não estude apenas os comandos. Estude os conceitos. Entenda como o Git pensa. Quando isso acontecer, você deixará de ser apenas um usuário da ferramenta e passará a utilizá-la como um verdadeiro engenheiro de software, preparado para atuar tanto em aplicações modernas quanto nos ambientes críticos que movimentam bancos, seguradoras, governos e grandes corporações ao redor do mundo. Afinal, tecnologias mudam, linguagens evoluem, mas a capacidade de controlar, compreender e colaborar sobre o código continuará sendo uma das competências mais valiosas da engenharia de software.

quinta-feira, 19 de dezembro de 2019

Do Logon ao Primeiro Programa: A Jornada do Padawan COBOL pelo TSO, ISPF e o Mundo do Desenvolvimento no IBM Z

 

Bellacosa Mainframe uma jornada no tso ispf e seus comandos para os primeiros passos em programacção cobol

☕ Um Café no Bellacosa Mainframe

Do Logon ao Primeiro Programa: A Jornada do Padawan COBOL pelo TSO, ISPF e o Mundo do Desenvolvimento no IBM Z

"Um Jedi não nasce sabendo usar um sabre de luz. Um programador Mainframe também não nasce dominando o ISPF. Ambos aprendem um comando de cada vez."

Quando alguém chega ao universo Mainframe pela primeira vez, normalmente enxerga apenas uma tela preta cheia de caracteres verdes. Acostumado com Visual Studio Code, Eclipse ou IntelliJ, o iniciante costuma pensar:

"Como alguém consegue desenvolver sistemas críticos aqui?"

A resposta surpreende.

Depois de algumas semanas de prática, muitos descobrem que aquele ambiente aparentemente simples foi projetado para maximizar produtividade, estabilidade e eficiência muito antes de existirem as IDEs modernas.

Bem-vindo ao universo do IBM Z.

Hoje vamos caminhar juntos, passo a passo, pela jornada de um verdadeiro Programador COBOL Padawan, entendendo como funciona o desenvolvimento utilizando TSO, ISPF e os principais comandos do editor que há décadas ajudam a construir bancos, seguradoras, bolsas de valores, companhias aéreas e governos ao redor do planeta.


O Mainframe não é apenas um computador

Antes de abrir um editor ou escrever uma linha de COBOL, precisamos entender onde estamos.

Um IBM Z não é simplesmente um servidor maior.

Ele foi concebido para atender milhares de usuários simultaneamente com disponibilidade praticamente contínua.

Enquanto um notebook executa dezenas de processos, um IBM Z pode executar milhões de transações diariamente, mantendo segurança, auditoria, criptografia por hardware e altíssima confiabilidade.

É por isso que grandes instituições financeiras ainda executam seus sistemas centrais nessa plataforma.

Mas como um desenvolvedor conversa com essa máquina?

A resposta começa com três letras.

TSO.


O TSO: sua porta de entrada para o universo IBM Z

TSO significa Time Sharing Option.

Hoje parece algo comum termos diversos usuários conectados simultaneamente a um sistema operacional. Entretanto, décadas atrás isso era revolucionário.

Antes do TSO, um programador preparava cartões perfurados, entregava o lote para processamento e esperava horas — às vezes um dia inteiro — para descobrir que havia esquecido um ponto final.

O TSO mudou completamente essa realidade.

Agora cada usuário possui sua própria sessão interativa.

Quando você realiza o Logon, não está apenas entrando em um sistema.

Na verdade, o z/OS inicia todo um ambiente personalizado para você.

Diversos componentes entram em ação simultaneamente.

O RACF autentica seu usuário.

Os datasets do seu perfil são alocados.

As permissões são carregadas.

Os comandos disponíveis são habilitados.

Seu ambiente de desenvolvimento é preparado.

É como abrir um escritório inteiro apenas para você trabalhar.


O herói invisível chamado RACF

Todo Padawan precisa entender uma verdade muito importante.

No Mainframe, segurança vem antes da programação.

Antes mesmo de abrir o editor, o RACF já decidiu o que você poderá fazer.

Ele verifica sua identidade.

Confere sua senha.

Analisa seus grupos de acesso.

Define quais bibliotecas podem ser acessadas.

Autoriza ou bloqueia comandos.

Controla acesso ao CICS.

Controla acesso ao DB2.

Controla acesso ao SDSF.

Controla praticamente tudo.

É por isso que muitas mensagens de erro não significam defeito no programa.

Às vezes significam simplesmente:

"Você não possui autorização."

No mundo IBM Z, privilégios são tão importantes quanto conhecimento técnico.


Depois do Logon aparece o verdadeiro laboratório

Após autenticar-se, normalmente encontramos o ISPF.

Seu nome completo é Interactive System Productivity Facility.

Quem olha rapidamente imagina tratar-se apenas de um editor de texto.

Esse é um dos maiores equívocos de quem está começando.

O ISPF é praticamente uma IDE completa construída décadas antes das IDEs modernas.

Dentro dele encontramos:

  • Editor de código

  • Navegação entre bibliotecas

  • Gerenciamento de datasets

  • Utilitários

  • Comparação de arquivos

  • Execução de comandos

  • Macros

  • REXX

  • CLIST

  • Painéis personalizados

  • Ferramentas administrativas

Tudo extremamente integrado.

Tudo extremamente rápido.

Tudo utilizando poucos recursos da máquina.

Essa eficiência explica por que tantos desenvolvedores continuam preferindo o ambiente 3270 mesmo após conhecer ferramentas gráficas.


O menu principal é muito mais poderoso do que parece

O famoso menu inicial do ISPF apresenta diversas opções numéricas.

À primeira vista parecem simples.

Mas cada número abre um universo diferente.

A opção 2 leva ao editor.

A opção 3 reúne utilitários.

A famosa 3.2 permite criar datasets.

A clássica 3.4 lista bibliotecas.

A opção 6 executa comandos TSO diretamente.

Cada menu representa anos de evolução do ambiente de desenvolvimento IBM.

O curioso é que muitos profissionais trabalham décadas utilizando apenas parte desses recursos.

Sempre existe algo novo para aprender.


Os Datasets: a organização é parte da engenharia

No Windows estamos acostumados com pastas.

No Mainframe trabalhamos com datasets.

Entre eles existe um dos mais importantes para quem desenvolve COBOL:

O PDS.

Partitioned Data Set.

Imagine uma estante.

O PDS é a estante.

Cada membro é um livro.

Dentro dessa estante normalmente encontramos programas, JCLs, copybooks e diversos componentes relacionados.

Uma organização típica pode conter:

  • USER.COBOL.SOURCE

  • USER.JCL

  • USER.COPYLIB

  • USER.LOAD

  • USER.TEST

  • USER.REXX

Separar corretamente essas bibliotecas facilita manutenção, controle de versões e automação.

Em ambientes corporativos essa organização torna-se ainda mais importante, pois centenas de desenvolvedores trabalham simultaneamente.


Escrever COBOL é construir uma casa

Muitos iniciantes querem começar digitando comandos imediatamente.

Mas COBOL possui uma arquitetura muito organizada.

Cada programa é dividido em grandes áreas de responsabilidade.

A IDENTIFICATION DIVISION identifica o programa.

A ENVIRONMENT DIVISION descreve recursos externos.

A DATA DIVISION declara toda a memória utilizada.

A PROCEDURE DIVISION contém a lógica de negócio.

Essa divisão clara faz com que programas escritos há quarenta anos ainda possam ser compreendidos atualmente.

Não é coincidência.

Foi uma escolha de engenharia.

COBOL privilegia legibilidade.

O objetivo nunca foi escrever menos linhas.

O objetivo sempre foi escrever programas que outra pessoa consiga entender muitos anos depois.


As famosas colunas do COBOL

Todo Padawan escuta falar das colunas.

Área A.

Área B.

Indicador.

Numeração.

Hoje o compilador moderno aceita formato livre em muitos ambientes.

Mesmo assim, compreender o formato clássico continua sendo essencial.

Grande parte dos sistemas corporativos ainda mantém milhões de linhas utilizando o layout tradicional.

Conhecer essas convenções permite navegar com segurança entre sistemas desenvolvidos nas décadas de 1980, 1990 e 2000.

Mais importante ainda: ajuda a compreender por que determinados padrões existem.


O editor ISPF: simples na aparência, poderoso na prática

Agora chegamos ao verdadeiro companheiro do desenvolvedor.

O Editor ISPF.

Quem o vê pela primeira vez acredita que seja limitado.

Na realidade ele foi otimizado para velocidade.

Cada comando foi pensado para reduzir movimentos repetitivos.

Cada tecla possui uma função.

Cada recurso procura economizar tempo.

É uma filosofia completamente diferente das interfaces gráficas modernas.

Enquanto uma IDE gráfica oferece dezenas de botões, o ISPF aposta em comandos curtos e extremamente rápidos.

Depois que a memória muscular é desenvolvida, editar programas torna-se surpreendentemente eficiente.


COLS: a régua que salva programas

Um dos primeiros comandos que todo Padawan deveria aprender é:

COLS

Ele exibe uma régua mostrando exatamente onde cada coluna está posicionada.

Isso evita deslocamentos acidentais.

Ajuda no alinhamento.

Facilita manutenção.

Principalmente quando trabalhamos com código legado.

É um comando simples.

Mas evita muitos problemas.


CREATE: criando novos membros

Criar um programa novo também é extremamente simples.

O comando CREATE gera um novo membro dentro da biblioteca.

É como criar um novo arquivo dentro de uma pasta.

Em poucos segundos o desenvolvedor já possui um ambiente pronto para iniciar seu código.


FIND: o comando que economiza horas

Imagine um sistema com 20 mil linhas.

Ou cem programas diferentes.

Encontrar uma variável manualmente seria inviável.

É exatamente aqui que entra o FIND.

Ele pesquisa palavras.

Pesquisa comandos.

Pesquisa literais.

Pesquisa variáveis.

Pesquisa praticamente qualquer texto.

Dominar FIND representa um enorme ganho de produtividade.


CUT e PASTE: refatoração antes da palavra existir

Muito antes da palavra "refatoração" tornar-se popular, o ISPF já permitia reorganizar blocos inteiros de código.

Selecionamos linhas.

Executamos CUT.

Depois utilizamos PASTE.

Tudo muito rápido.

Sem mouse.

Sem janelas.

Sem menus.

A produtividade impressiona.


UNDO: porque todos erram

Até os desenvolvedores mais experientes cometem erros.

Por isso existe o UNDO.

Alterou uma linha indevidamente?

Desfaça.

Removeu um bloco inteiro?

Desfaça.

Movimentou código para o lugar errado?

Desfaça.

É um recurso simples.

Mas extremamente valioso durante manutenção de sistemas críticos.


SAVE e CANCEL

Esses dois comandos representam decisões completamente diferentes.

SAVE grava alterações.

Permite continuar trabalhando.

CANCEL abandona tudo.

Sai sem gravar.

Aprender quando utilizar cada um faz parte da maturidade do desenvolvedor.


Existem comandos que poucos conhecem

Depois de dominar os comandos básicos, o Padawan descobre um universo ainda maior.

CHANGE permite substituir centenas de ocorrências automaticamente.

HEX ON mostra o conteúdo hexadecimal de um registro.

RESET limpa exclusões temporárias.

EXCLUDE oculta blocos inteiros de código.

FLIP alterna entre linhas visíveis e ocultas.

CAPS controla conversão automática para maiúsculas.

LOCATE posiciona rapidamente em pontos específicos.

Cada novo comando aprendido representa mais produtividade.


O desenvolvimento não termina ao escrever o programa

Um erro comum dos iniciantes é pensar que o trabalho termina quando o código está pronto.

Na realidade, ele está apenas começando.

Agora entra em cena outro personagem fundamental.

O JCL.


O JCL é o maestro da orquestra

COBOL não executa diretamente.

Primeiro precisa ser compilado.

Depois ligado.

Depois transformado em módulo executável.

O JCL coordena todas essas etapas.

Ele chama o compilador.

Executa o Binder.

Resolve bibliotecas.

Gera módulos.

Organiza arquivos temporários.

É como um roteiro detalhado dizendo ao sistema exatamente o que fazer.

Sem JCL não existe processamento Batch.

Sem Batch boa parte do Mainframe simplesmente deixaria de existir.


O Binder: o construtor do executável

Pouca gente explica o papel do Binder.

Ele recebe diversos objetos compilados.

Localiza subprogramas.

Conecta bibliotecas.

Resolve referências externas.

Monta o módulo executável final.

É como montar um quebra-cabeça gigante onde cada peça precisa encaixar perfeitamente.

Quando tudo funciona, nasce o Load Module.

É ele que será realmente executado pelo sistema.


Finalmente chega o momento da verdade

Depois da compilação vem a execução.

E logo depois...

A análise.

É aqui que entra o SDSF.


SDSF: a janela para dentro do processamento

O SDSF permite acompanhar tudo o que aconteceu durante um Job.

Podemos verificar:

Tempo de CPU.

Tempo de espera.

Mensagens.

Arquivos gerados.

SYSOUT.

Return Code.

Condition Code.

Abends.

É praticamente o painel de controle do processamento Batch.

Nenhum desenvolvedor experiente ignora o SDSF.

Ali estão todas as pistas necessárias para descobrir por que um programa funcionou...

Ou por que falhou.


Aprenda a ler mensagens antes de procurar culpados

Muitos iniciantes ficam desesperados quando aparece um S0C7.

Ou um S806.

Ou um JCL ERROR.

O profissional experiente faz exatamente o contrário.

Primeiro lê cuidadosamente as mensagens.

Depois interpreta o contexto.

Somente então começa a corrigir o problema.

Grande parte do trabalho em Mainframe consiste justamente em interpretar informações produzidas pelo próprio sistema.

O IBM Z fala com o desenvolvedor o tempo inteiro.

É preciso aprender seu idioma.


O verdadeiro segredo do Mainframe

Depois de estudar TSO.

ISPF.

Datasets.

COBOL.

JCL.

SDSF.

Comandos.

Compilação.

Execução.

Uma conclusão torna-se inevitável.

O segredo do Mainframe nunca esteve na tela preta.

Nunca esteve nas teclas PF.

Nunca esteve nos menus numéricos.

O verdadeiro diferencial sempre foi a disciplina.

Cada biblioteca possui uma finalidade.

Cada programa segue uma estrutura.

Cada Job possui um fluxo definido.

Cada autorização é controlada.

Cada alteração pode ser auditada.

Cada execução produz evidências.

Esse nível de organização permitiu que aplicações escritas há décadas continuassem evoluindo sem perder confiabilidade.

E é justamente essa filosofia que transforma um simples aprendiz em um verdadeiro Programador COBOL Padawan.

No Bellacosa Mainframe, acreditamos que aprender IBM Z não significa apenas decorar comandos ou sintaxe. Significa compreender uma cultura de engenharia construída ao longo de mais de sessenta anos, onde estabilidade, clareza e responsabilidade caminham lado a lado. Cada LOGON, cada programa editado no ISPF, cada JCL submetido e cada mensagem analisada no SDSF representam um novo passo nessa jornada. Com curiosidade, prática constante e vontade de entender o "porquê" por trás de cada recurso, o terminal 3270 deixa de ser uma tela intimidadora e passa a ser uma poderosa oficina de desenvolvimento. Que este seja apenas o primeiro capítulo da sua aventura. O IBM Z continua evoluindo, o COBOL continua moderno e o próximo grande especialista pode muito bem ser você.


quarta-feira, 26 de setembro de 2018

journalctl Muito Além do tail -f

 

Bellacosa Mainframe e o journalctl no linux

☕ Um Café no Bellacosa Mainframe

journalctl Muito Além do tail -f

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Logs, Systemd, DevOps, Observabilidade e Como Grandes Bancos Descobrem Problemas em Produção Antes Que Eles Virem Incidentes

"O bom programador escreve código. O excelente programador aprende a investigar sistemas. E o profissional que trabalha em grandes ambientes críticos sabe que, muitas vezes, o log conta uma história muito antes do usuário abrir um chamado."


Introdução

Quando um desenvolvedor COBOL começa sua jornada no universo Linux, normalmente encontra um ambiente completamente diferente daquele que conheceu durante anos no IBM Z.

No Mainframe existe uma enorme quantidade de ferramentas especializadas:

  • SDSF

  • JES2

  • JES3

  • SYSLOG

  • LOGREC

  • RMF

  • SMF

  • RACF

  • IPCS

  • CICS Messages

  • DB2 Messages

Cada uma possui sua finalidade.

No Linux moderno existe algo semelhante, porém muito mais integrado.

Seu nome é Systemd Journal.

E a ferramenta que permite conversar com ele chama-se:

journalctl

Muitos iniciantes acreditam que o journalctl serve apenas para "ver logs".

Na realidade, ele é muito mais do que isso.

Ele é praticamente um mecanismo de investigação forense do sistema operacional.

Hoje vamos tomar um café e descobrir por que praticamente todo Engenheiro DevOps vive com uma janela do journalctl aberta.


O problema dos arquivos de log tradicionais

Durante décadas, o Linux utilizou arquivos texto.

Você provavelmente já ouviu falar em:

/var/log/messages
/var/log/syslog
/var/log/auth.log
/var/log/secure
/var/log/dmesg

Cada aplicação escrevia seus próprios registros.

Imagine um servidor contendo:

  • Apache

  • Nginx

  • Docker

  • PostgreSQL

  • Java

  • Python

  • Kubernetes

  • SSH

  • Firewall

  • Redis

Cada um gerando milhares de linhas por minuto.

Agora imagine descobrir por que uma API caiu exatamente às 14:32.

Você teria que abrir dezenas de arquivos diferentes.

Era exatamente esse o problema.


Imagine um grande banco

Vamos fazer uma analogia.

Imagine um banco processando:

  • PIX

  • TED

  • DOC

  • Internet Banking

  • Mobile Banking

  • Cartões

  • Crédito

  • Investimentos

Cada sistema produzindo logs.

Agora imagine que esses logs fossem gravados em centenas de arquivos espalhados.

Encontrar uma única falha seria semelhante a procurar uma agulha num palheiro.

Foi justamente para resolver esse caos que nasceu o Systemd Journal.


O que é o Systemd Journal?

Pense nele como um enorme banco de dados de eventos.

Em vez de simplesmente gravar texto em arquivos, o Systemd Journal armazena informações estruturadas.

Cada evento contém muito mais do que apenas uma mensagem.

Por exemplo:

Horário

Servidor

PID

UID

GID

Nome do Serviço

Executável

Container

Prioridade

Boot

Mensagem

Hostname

Machine ID

Kernel

Cgroup

Namespace

Ou seja...

O log deixa de ser somente texto.

Ele passa a possuir contexto.


Uma analogia para quem vem do Mainframe

No IBM Z temos diversas fontes de informação.

IBM MainframeLinux
SDSFjournalctl
JESMSGLGJournal
SYSLOGJournal
Console do Operadorjournalctl -f
LOGRECEventos críticos
RMFMétricas do sistema
SMFEventos estruturados

Não é exatamente igual.

Mas o conceito é extremamente parecido.

O administrador consulta um repositório central de eventos.


Como funciona internamente?

Imagine esta arquitetura.

Aplicação

↓

stdout

↓

stderr

↓

Kernel

↓

systemd-journald

↓

Banco de Eventos

↓

journalctl

Observe que o journalctl não cria logs.

Quem cria é o systemd-journald.

O journalctl apenas consulta.


Uma biblioteca gigante

Imagine uma biblioteca.

Cada livro possui:

  • autor

  • assunto

  • data

  • idioma

  • editora

Você consegue localizar qualquer livro em segundos.

O Journal faz exatamente isso.

Cada log recebe etiquetas.

Depois basta perguntar.


O comando mais simples

journalctl

Resultado:

Todos os eventos do sistema.

Pode facilmente retornar centenas de milhares de linhas.

Por isso quase nunca utilizamos o comando sozinho.


Consultando apenas um serviço

Aqui começa a verdadeira magia.

Imagine um servidor rodando Nginx.

Basta fazer:

journalctl -u nginx

Agora o Journal retorna apenas:

  • inicialização

  • parada

  • reload

  • erros

  • avisos

Tudo relacionado ao Nginx.

Sem grep.

Sem filtros complicados.


O que significa "-u"?

O parâmetro:

-u

Significa:

Unit

Ou seja:

Uma unidade do Systemd.

Normalmente um serviço.

Exemplos:

journalctl -u docker

journalctl -u nginx

journalctl -u ssh

journalctl -u postgresql

journalctl -u mysql

É um dos comandos mais utilizados em produção.


E se eu tiver minha própria aplicação?

Imagine que você criou uma API Java.

Ela roda como:

minha-api.service

Consultar seus eventos é simples.

journalctl -u minha-api

Pronto.

Todos os logs aparecem organizados.


Logs em tempo real

Uma das funções favoritas dos profissionais DevOps.

journalctl -f

O "-f" significa:

Follow.

É praticamente o equivalente moderno ao famoso:

tail -f

Enquanto chegam novos eventos, eles aparecem imediatamente.

Muito utilizado durante:

  • Deploy

  • Testes

  • Atualizações

  • Migrações

  • Produção


O que acontece durante um Deploy?

Imagine uma API.

Você faz:

systemctl restart minha-api

Em outra janela:

journalctl -u minha-api -f

Você observa tudo acontecendo.

Stopping service...

Loading configuration...

Connecting database...

Listening on port 8080...

Application Started.

Caso exista um erro, ele aparece na hora.


O famoso journalctl -xe

Você provavelmente verá esse comando em praticamente todo tutorial.

journalctl -xe

Ele mostra:

  • erros recentes

  • contexto

  • mensagens relacionadas

  • detalhes

Em vez de apenas:

Falhou.

Você recebe praticamente uma investigação.


Filtrando por tempo

Uma das maiores vantagens do Journal.

Últimos 30 minutos.

journalctl --since "30 min ago"

Última hora.

journalctl --since "1 hour ago"

Hoje.

journalctl --since today

Ontem.

journalctl --since yesterday

Intervalo específico.

journalctl \
--since "2026-07-04 08:00" \
--until "2026-07-04 10:00"

Isso elimina milhares de linhas desnecessárias.


Investigando um incidente

Imagine.

Às 15:22 um cliente informou:

"O sistema caiu."

Você pode consultar exatamente aquele período.

journalctl \
--since "15:15" \
--until "15:30"

É praticamente viajar no tempo.


Boot atual

journalctl -b

Mostra tudo desde o último boot.

Extremamente útil para investigar:

  • drivers

  • inicialização

  • montagem de discos

  • serviços


Boot anterior

journalctl -b -1

Imagine que o servidor reiniciou sozinho durante a madrugada.

Você consegue analisar exatamente aquele boot.

Isso economiza horas de investigação.


Prioridades

Nem todo log possui a mesma importância.

O Journal utiliza níveis.

0 Emergency

1 Alert

2 Critical

3 Error

4 Warning

5 Notice

6 Info

7 Debug

Consultar somente erros.

journalctl -p err

Somente críticos.

journalctl -p crit

Somente warnings.

journalctl -p warning

A verdadeira força: combinar filtros

O Journal permite combinar praticamente tudo.

Exemplo.

journalctl \
-u nginx \
-p err \
--since "1 hour ago"

Tradução.

Mostre:

  • apenas o Nginx

  • apenas erros

  • apenas na última hora

É exatamente isso que um analista faria durante um incidente.


O Journal é inteligente

Imagine um processo.

PID:

5412

Consultar.

journalctl _PID=5412

Ou um executável.

journalctl _EXE=/usr/bin/python3

Ou um usuário.

journalctl _UID=1000

Ou um comando.

journalctl _COMM=java

Você não precisa procurar texto.

Você consulta atributos.

É muito mais eficiente.


Kernel

Quer apenas mensagens do Kernel?

journalctl -k

Ali aparecem informações sobre:

  • CPU

  • Memória

  • USB

  • Drivers

  • Rede

  • Disco

  • NVMe

  • SATA

Muito útil para administradores.


Persistência

Um detalhe extremamente importante.

Algumas distribuições mantêm logs apenas na memória.

Após reboot.

Tudo desaparece.

Para ativar armazenamento permanente.

sudo mkdir -p /var/log/journal

Depois.

sudo systemctl restart systemd-journald

Agora os logs permanecem.


Configuração

Arquivo principal.

/etc/systemd/journald.conf

Ali controlamos:

Storage

Compress

Seal

SplitMode

SystemMaxUse

RuntimeMaxUse

MaxRetentionSec

RateLimitInterval

RateLimitBurst

Controle de espaço

Imagine um servidor Kubernetes.

Milhões de eventos.

O Journal possui limites automáticos.

Exemplo.

SystemMaxUse=5G

Nunca utilizará mais de cinco gigabytes.


Limpando logs

Por tamanho.

journalctl --vacuum-size=2G

Por tempo.

journalctl --vacuum-time=30d

Por quantidade.

journalctl --vacuum-files=10

Muito mais elegante do que apagar arquivos manualmente.


JSON

Pouca gente conhece.

O Journal consegue exportar em JSON.

journalctl -o json

Isso permite integração com:

  • Elastic

  • OpenSearch

  • Grafana Loki

  • Splunk

  • SIEM

  • Ferramentas de IA

  • Pipelines DevOps


Containers

O Docker pode enviar seus logs diretamente ao Journal.

Assim você pode consultar informações de containers utilizando filtros específicos, sem precisar acessar cada arquivo de log individualmente.

Em ambientes com dezenas ou centenas de containers, isso simplifica muito a operação e a análise de incidentes.


Observabilidade

Nos últimos anos surgiu uma palavra muito importante.

Observabilidade.

Ela responde perguntas como:

  • O sistema está saudável?

  • O que aconteceu?

  • Onde ocorreu?

  • Quando começou?

  • Qual serviço falhou?

  • Qual usuário foi afetado?

A observabilidade moderna normalmente é baseada em três pilares:

Logs

Métricas

Traces

O journalctl representa o primeiro pilar.


DevOps

Uma equipe DevOps dificilmente trabalha sem logs.

Imagine um pipeline.

Git Push

↓

Build

↓

Testes

↓

Deploy

↓

Restart

↓

journalctl

↓

Validação

Os logs confirmam se tudo ocorreu corretamente.


Um exemplo prático para um COBOL Padawan

Imagine que você modernizou um sistema COBOL utilizando IBM z/OS Connect para expor um serviço REST. Um gateway Nginx recebe as requisições, encaminha para uma API Java que, por sua vez, conversa com programas COBOL em CICS. Após um deploy, as chamadas começam a retornar erro HTTP 502.

Em vez de procurar em diversos arquivos, um engenheiro pode seguir uma sequência lógica:

  1. Verificar os logs do Nginx:

    journalctl -u nginx --since "10 min ago"
    
  2. Verificar a API Java:

    journalctl -u minha-api --since "10 min ago"
    
  3. Consultar apenas mensagens de erro:

    journalctl -p err --since "10 min ago"
    
  4. Acompanhar a recuperação em tempo real:

    journalctl -u minha-api -f
    

Em poucos minutos é possível identificar se o problema está na aplicação, na infraestrutura ou em um serviço dependente.


Bellacosa Insight ☕

Existe uma frase muito conhecida entre administradores experientes:

"Logs não impedem falhas. Eles impedem que você fique perdido durante uma falha."

No Mainframe aprendemos a consultar o JES, o SYSLOG, o SDSF e os registros do sistema para entender o comportamento de uma aplicação. No Linux moderno, o journalctl desempenha um papel semelhante: ele centraliza informações críticas e fornece ferramentas poderosas para filtrar, correlacionar e investigar eventos.

Dominar o journalctl não significa decorar dezenas de parâmetros. Significa desenvolver uma mentalidade investigativa. O profissional deixa de apenas executar comandos e passa a formular perguntas ao sistema: o que aconteceu?, quando começou?, qual serviço foi afetado?, qual a gravidade?, o problema ocorreu antes ou depois do último reboot?.

É exatamente essa mudança de postura que diferencia um programador que apenas desenvolve software de um engenheiro capaz de manter aplicações críticas funcionando 24 horas por dia, sete dias por semana.

No fim das contas, em um grande banco, em uma fintech ou em qualquer ambiente corporativo moderno, os logs contam a história do sistema. Aprender a ler essa história é uma das habilidades mais valiosas para qualquer Programador COBOL Padawan que deseja evoluir para o universo de DevOps, SRE e Engenharia de Software Moderna.

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
GitHub LinkedIn
Inicializando conteúdo...