✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Open Mainframe Project. Mostrar todas as mensagens

terça-feira, 9 de junho de 2026

Neo COBOL : Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Bellacosa Mainframe e o que há de mais moderno no COBOL

☕💣🚀 PADAWAN, O COBOL FUGIU DO TERMINAL VERDE!

Como Git, VS Code, APIs, Zowe, DevOps e Inteligência Artificial Estão Transformando o Desenvolvimento Mainframe

Existe uma pergunta que aparece em praticamente toda palestra sobre Mainframe.

Ela normalmente vem de alguém que nunca trabalhou com IBM Z.

Às vezes é um estudante.

Às vezes é um programador Java.

Às vezes é um gerente recém-chegado ao mundo corporativo.

A pergunta é sempre a mesma:

— Mas COBOL ainda existe?

E eu sempre respondo:

— Não apenas existe. Ele movimenta boa parte da economia mundial enquanto você dorme.

O mais curioso é que o COBOL de hoje não se parece nem um pouco com a imagem que muita gente guarda na cabeça.

Quando alguém fala em COBOL, normalmente imagina uma sala escura, um operador digitando comandos em uma tela verde, um terminal 3270 piscando e um monte de programas escritos há cinquenta anos.

Essa imagem até possui um fundo de verdade.

Mas ela representa apenas uma pequena parte da história.

A realidade é que o Mainframe passou por uma transformação silenciosa que poucas pessoas fora do mercado IBM perceberam.

E talvez essa seja uma das maiores revoluções tecnológicas dos últimos anos.

O Gigante Invisível Nunca Foi Embora

Enquanto o mundo discutia startups, aplicativos móveis e computação em nuvem, o Mainframe continuava fazendo aquilo que sempre fez melhor:

Processar volumes absurdos de dados com segurança, disponibilidade e confiabilidade.

Hoje ele continua presente em:

Bancos
Seguradoras
Bolsas de valores
Governos
Operadoras de cartão
Empresas aéreas
Sistemas de saúde

Bilhões de transações passam diariamente por sistemas COBOL.

Grande parte do dinheiro que circula pelo planeta toca algum programa COBOL em algum momento da jornada.

O curioso é que quase ninguém percebe isso.

Por isso costumo chamar o Mainframe de:

O Gigante Invisível da Computação.

O Dia em Que o Mainframe Conheceu o VS Code

Durante décadas o ambiente clássico de desenvolvimento foi dominado por ferramentas tradicionais como:

ISPF
TSO
SDSF
Editores 3270

Essas ferramentas continuam extremamente importantes.

Mas a nova geração de desenvolvedores cresceu usando interfaces gráficas, IDEs modernas e integração contínua.

A IBM percebeu isso.

O resultado foi uma mudança histórica.

Hoje um programador COBOL pode desenvolver utilizando:

Visual Studio Code
Git
GitHub
GitHub Actions
APIs REST
Zowe Explorer

Ou seja:

O desenvolvedor pode trabalhar em uma interface praticamente idêntica à utilizada por equipes Java, Python ou JavaScript.

A barreira psicológica que separava o Mainframe do restante da indústria começou a desaparecer.

Zowe: A Ponte Entre Dois Mundos

Talvez nenhuma ferramenta tenha simbolizado tanto essa transformação quanto o Zowe.

Criado sob o guarda-chuva do Open Mainframe Project, o Zowe funciona como uma ponte entre o universo moderno de desenvolvimento e o ambiente IBM Z.

Com ele é possível:

Navegar em datasets
Visualizar jobs
Consultar JES
Trabalhar com USS
Automatizar tarefas
Consumir APIs do z/OS

Tudo isso sem sair do VS Code.

Para quem cresceu usando ISPF, a experiência parece quase mágica.

Para quem veio do mundo distribuído, finalmente o Mainframe passa a parecer familiar.

Open Mainframe Project: O Movimento Que Mudou Tudo

Durante muitos anos existiu um mito.

O mito dizia que Mainframe era uma tecnologia fechada.

Que tudo era proprietário.

Que inovação só acontecia fora desse ambiente.

Então surgiu o Open Mainframe Project.

A iniciativa passou a reunir:

IBM
Bancos
Universidades
Comunidade Open Source
Grandes empresas globais

O objetivo era simples:

Modernizar o ecossistema sem destruir aquilo que o tornou confiável.

Foi dessa iniciativa que nasceram diversos projetos fundamentais.

Entre eles:

Zowe
COBOL Check
Z Open Editor
Mentorship Programs
Cursos gratuitos

O resultado foi um crescimento enorme da comunidade.

O Git Finalmente Chegou ao Mainframe

Antigamente o controle de versões era feito através de soluções corporativas específicas.

Hoje a realidade mudou.

Git tornou-se parte integrante do desenvolvimento Mainframe moderno.

Agora podemos:

Criar branches
Fazer merge
Abrir pull requests
Revisar código
Automatizar validações

Exatamente como acontece no restante da indústria.

O Mainframe deixou de ser uma ilha.

Ele tornou-se mais um participante do ecossistema DevOps.

DevOps Não É Apenas Moda

Existe quem pense que DevOps é apenas uma palavra bonita para colocar em apresentações.

Não é.

DevOps representa uma mudança cultural profunda.

No passado era comum ver equipes divididas:

Desenvolvimento de um lado.

Operação do outro.

Cada grupo trabalhando isoladamente.

Hoje o objetivo é integração.

Automação.

Colaboração.

Velocidade.

Qualidade.

E o IBM Z abraçou completamente essa filosofia.

CI/CD Também Chegou ao COBOL

Um dos maiores choques para quem está entrando no mercado Mainframe é descobrir que existem pipelines CI/CD para COBOL.

Sim.

Pipelines completos.

O fluxo pode ser algo como:

Commit → Build → Testes → Deploy → Produção

Ferramentas modernas como:

GitHub Actions
Jenkins
DBB
UrbanCode
Zowe CLI

permitem automatizar praticamente todo o ciclo de desenvolvimento.

O mesmo conceito utilizado em aplicações web agora pode ser aplicado a programas COBOL.

Testes Automatizados: O JUnit do Mainframe

Durante muito tempo existiu a falsa ideia de que COBOL não possuía testes unitários.

Hoje isso está completamente ultrapassado.

Ferramentas como COBOL Check permitem:

Criar testes automatizados
Validar regras de negócio
Executar regressões
Integrar com pipelines DevOps

O conceito é muito parecido com:

JUnit
NUnit
PyTest

A diferença é que agora estamos falando de COBOL.

Isso reduz riscos.

Melhora qualidade.

E aumenta a confiança durante mudanças em sistemas críticos.

APIs: O Mainframe Conversa Com Tudo

Outro mito clássico:

"O Mainframe é isolado."

Errado.

O Mainframe moderno conversa com praticamente qualquer tecnologia.

Hoje é comum encontrar:

APIs REST
Serviços Web
JSON
XML
Kafka
MQ
Cloud

Um programa COBOL pode ser chamado por:

Aplicativos móveis
Sites
Microserviços
Plataformas em nuvem

A integração tornou-se um dos pilares da modernização.

UTF-8: O COBOL Aprendeu Novos Idiomas

Durante décadas os sistemas corporativos lidaram principalmente com conjuntos de caracteres tradicionais.

Agora o mundo é global.

Precisamos lidar com:

Português
Japonês
Chinês
Árabe
Emojis

O Enterprise COBOL evoluiu para suportar:

UTF-8
NATIONAL
Dynamic-Length Items

Isso abre portas para aplicações verdadeiramente globais.

Multithreading e Performance

Outra área de enorme evolução foi a capacidade de execução paralela.

Recursos modernos permitem:

Multithreading
THREAD Compiler Option
LOCAL-STORAGE
THREADSAFE

Isso significa melhor aproveitamento dos recursos do hardware IBM Z.

E quando falamos de IBM Z, estamos falando de uma das plataformas mais poderosas já criadas para processamento transacional.

O Papel da Inteligência Artificial

Talvez estejamos entrando na fase mais interessante da história do Mainframe.

A Inteligência Artificial começou a chegar ao ambiente IBM Z.

Hoje já vemos:

Assistentes de código
Geração automática de documentação
Explicação de programas legados
Conversão de código
Análise de impacto
Apoio à modernização

Ferramentas como GitHub Copilot, Watsonx e soluções corporativas especializadas estão transformando a forma como trabalhamos.

O desenvolvedor deixa de gastar energia com tarefas repetitivas e passa a focar na lógica de negócio.

O Novo Programador Mainframe

O mercado mudou.

O profissional mais valorizado não é apenas aquele que conhece COBOL.

Nem apenas aquele que conhece DevOps.

O profissional mais procurado é aquele que consegue unir os dois mundos.

O desenvolvedor moderno entende:

COBOL
JCL
DB2
CICS
Git
APIs
VS Code
Zowe
DevOps
CI/CD
Testes automatizados

Ele compreende o legado.

Mas também compreende a inovação.

E essa combinação é extremamente rara.

O Futuro Já Chegou

Muitas pessoas continuam esperando o fim do Mainframe.

Esperam isso há décadas.

Enquanto isso, o IBM Z continua evoluindo.

Continua processando bilhões de transações.

Continua movimentando bancos.

Continua sustentando governos.

Continua integrando-se com nuvem, APIs, DevOps e Inteligência Artificial.

Talvez a maior surpresa não seja que o Mainframe tenha sobrevivido.

Talvez a maior surpresa seja perceber que ele nunca esteve tão moderno.

E aqui está a lição mais importante desta história.

☕💣🚀

OPERADOR, O COBOL NÃO FICOU PRESO NO PASSADO.

ELE SIMPLESMENTE ESPEROU O RESTO DA INDÚSTRIA ALCANÇÁ-LO.

Este texto já está pronto para publicação no Blogspot, LinkedIn Articles ou newsletter "Um Café no Bellacosa Mainframe".

segunda-feira, 8 de junho de 2026

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Bellacosa Mainframe e o IBM Cobol Check

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Se você trabalhou anos com COBOL, provavelmente já viveu esta situação:

Altera o programa
↓
Compila
↓
Executa o JCL
↓
Espera o batch
↓
Confere SYSOUT
↓
Descobre erro
↓
Volta para o início

Durante décadas essa foi a rotina natural do desenvolvedor Mainframe.

Enquanto isso, no mundo Java, C#, Python e JavaScript, os programadores criavam centenas de testes automatizados que validavam cada função antes mesmo do deploy.

Então surgiu uma pergunta:

"Por que COBOL não pode fazer o mesmo?"

Foi exatamente dessa necessidade que nasceu o COBOL Check.

O Que é o IBM COBOL Check?

O COBOL Check é um framework de testes unitários para COBOL inspirado diretamente em ferramentas como:

JUnit (Java)
NUnit (.NET)
PyTest (Python)
RSpec (Ruby)

Seu objetivo é permitir que desenvolvedores criem testes automatizados para programas COBOL de forma granular, validando regras de negócio sem depender de execuções batch completas. (GitHub)

Na prática, ele permite testar:

Parágrafos
Seções
Regras de negócio
Cálculos
Validações
Programas inteiros

Tudo de forma automatizada.

Quem Criou o COBOL Check?

Muita gente pensa que é um produto comercial da IBM.

Na realidade, o COBOL Check nasceu dentro do ecossistema do Open Mainframe Project, com apoio da comunidade Mainframe moderna e contribuições de empresas que utilizam COBOL em larga escala. (GitHub)

Seu propósito era resolver um problema antigo:

Como fazer microtestes em aplicações COBOL do mesmo modo que fazemos em Java?

Quando Foi Lançado?

O projeto apareceu publicamente no final da década de 2010 dentro do movimento de modernização DevOps para IBM Z.

Ele surgiu durante a onda de iniciativas Open Source voltadas ao Mainframe, juntamente com projetos como:

Zowe
IBM Z Open Editor
DBB
Galasa

e rapidamente ganhou destaque por trazer testes unitários para COBOL de forma simples. (GitHub)

O Problema Que Ele Resolve

Imagine um programa bancário.

CALCULA-JUROS.
    COMPUTE JUROS =
       SALDO * TAXA.

Sem testes unitários você normalmente:

Compila.
Executa JCL.
Alimenta arquivos.
Analisa relatórios.
Verifica resultados.

Tudo isso para validar uma única regra.

Com COBOL Check você cria um teste automatizado.

A Grande Ideia

O conceito é exatamente o mesmo do JUnit.

Você cria:

Código

CALCULA-DESCONTO.

Teste

TEST-DESCONTO.

Execução

PASS

FAIL

Simples assim.

Como Funciona Internamente?

O COBOL Check cria um ambiente de teste que:

Executa trechos específicos do programa
Injeta dados de entrada
Compara resultados
Gera relatórios

Ele também oferece suporte para:

Assertions
Stubs
Mocks
Verificação de chamadas
Relatórios JUnit XML
Relatórios HTML (GitHub)

Isso o aproxima bastante dos frameworks modernos.

Sistemas Suportados

O foco principal é:

IBM z/OS

Utilizando:

Enterprise COBOL
JCL
Ambientes tradicionais de produção

Também pode ser utilizado em ambientes modernos ligados ao ecossistema Open Mainframe.

Dependências

Uma instalação típica envolve:

Compilador COBOL

Normalmente:

Enterprise COBOL V5+
Enterprise COBOL V6+

Ambiente z/OS

TSO
ISPF
USS (quando aplicável)

Ferramentas modernas

Frequentemente combinado com:

Git
Jenkins
Zowe
DBB
IBM Z Open Editor (Marketplace do Visual Studio)

Como Instalar

O processo varia conforme a empresa.

Em geral:

1. Obter o projeto

Disponível através do repositório oficial do Open Mainframe Project. (GitHub)

2. Fazer upload

Copiar os fontes para datasets do ambiente.

Exemplo:

USER.COBOLCHECK.SOURCE

3. Compilar

Executar os jobs de instalação.

//COMPILE EXEC IGYWCL

4. Configurar bibliotecas

Adicionar:

STEPLIB
SYSLIB
COPYLIB

5. Validar instalação

Executar os exemplos fornecidos.

Primeiro Exemplo Passo a Passo

Vamos criar algo simples.

Programa

IDENTIFICATION DIVISION.
PROGRAM-ID. CALC01.

WORKING-STORAGE SECTION.
01 WS-VALOR PIC 9(5).
01 WS-DESCONTO PIC 9(5).

PROCEDURE DIVISION.

    COMPUTE WS-DESCONTO =
       WS-VALOR * 10 / 100.

    GOBACK.

Cenário de Teste

Queremos provar que:

1000 = 100 de desconto

Caso de Teste

MOVE 1000 TO WS-VALOR

PERFORM CALCULO

ASSERT WS-DESCONTO = 100

Resultado

TESTE 001
PASS

Testando Múltiplos Cenários

Você pode criar vários testes.

Caso 1

1000 -> 100

Caso 2

2000 -> 200

Caso 3

5000 -> 500

Resultado:

3 TESTS
3 PASSED

Assertions

Uma das partes mais importantes.

Exemplo:

ASSERT TRUE

ASSERT FALSE

ASSERT EQUAL

ASSERT NOT EQUAL

Muito parecido com:

assertEquals()
assertTrue()
assertFalse()

Mocks

Outro recurso extremamente poderoso.

Imagine um programa que acessa:

DB2
VSAM
IMS
MQ

Você não quer depender desses recursos durante o teste.

Então cria um Mock.

Exemplo Conceitual

Produção:

READ CLIENTE

Teste:

MOCK CLIENTE

Resultado:

CLIENTE SIMULADO

Sem acessar banco real.

Stubs

Parecido com Mock.

Você substitui componentes complexos por versões simplificadas.

Exemplo:

CONSULTA-SERASA

vira

CONSULTA-SERASA-STUB

Permitindo testes rápidos.

Relatórios

Após executar os testes você pode gerar:

HTML

PASS
FAIL
TOTAL

XML

Formato compatível com:

Jenkins
GitHub Actions
Azure DevOps
GitLab CI/CD (GitHub)

Integração com Jenkins

Fluxo clássico:

Git Commit
      ↓
Build
      ↓
COBOL Check
      ↓
Relatório
      ↓
Deploy

Se um teste falhar:

BUILD FAILED

Sem deploy.

Integração com Git

Imagine:

Pull Request

Antes da aprovação:

Executar COBOL Check

Resultado:

Todos os testes passaram

Só então ocorre o merge.

Benefícios Para Bancos

Os maiores usuários são:

Bancos
Seguradoras
Telecom
Governo

Porque possuem milhões de linhas COBOL.

Alterar uma linha sem proteção pode gerar:

S0C7
Abends
Valores incorretos
Erros financeiros

O COBOL Check reduz drasticamente esse risco.

Curiosidade #1

Muitos programadores COBOL experientes inicialmente desconfiaram da ideia.

A reação típica era:

"Teste unitário é coisa de Java."

Hoje isso mudou completamente.

Curiosidade #2

O projeto nasceu justamente porque ferramentas comerciais existentes geralmente testavam programas inteiros, mas não permitiam testar pequenos blocos de lógica com granularidade suficiente. (GitHub)

Curiosidade #3

Uma das metas do COBOL Check era incentivar melhores práticas de desenvolvimento, como:

Separação de responsabilidades
Modularização
Refatoração segura

Conceitos já populares no mundo Java. (GitHub)

Dicas de Ouro

Dica 1

Comece pelos cálculos.

São os testes mais fáceis.

Dica 2

Não tente cobrir o sistema inteiro.

Comece pelos módulos críticos.

Dica 3

Automatize tudo.

Teste manual não escala.

Dica 4

Integre com Jenkins.

O ganho de produtividade é enorme.

Dica 5

Execute testes a cada alteração.

Não espere a homologação.

Erros Comuns

Erro 1

Criar testes enormes.

Ruim:

Testar 20 regras juntas

Bom:

1 regra = 1 teste

Erro 2

Depender de dados reais.

Use mocks.

Erro 3

Não automatizar.

Se o teste depende de ação humana:

Você perdeu metade do benefício.

Easter Egg Mainframe ☕

Existe uma ironia divertida na história.

Durante décadas ouvimos:

"COBOL é antigo."

Mas hoje encontramos no mundo COBOL:

✅ Git

✅ VS Code

✅ Pipelines CI/CD

✅ DevOps

✅ Open Source

✅ APIs REST

✅ Containers

✅ Testes Unitários

✅ Inteligência Artificial

Enquanto muitos sistemas "modernos" desaparecem após poucos anos, aplicações COBOL escritas nos anos 70 continuam processando bilhões de dólares diariamente.

O COBOL Check é um símbolo dessa evolução.

Ele mostra que o Mainframe não ficou parado no tempo.

Pelo contrário.

O gigante apenas incorporou as melhores ideias do desenvolvimento moderno sem abrir mão da estabilidade que o tornou lendário.

Conclusão

O COBOL Check representa uma das iniciativas mais importantes da modernização do desenvolvimento Mainframe.

Ele trouxe para o COBOL conceitos consagrados por ferramentas como JUnit, permitindo:

Testes unitários automatizados
Mocks e Stubs
Relatórios HTML e XML
Integração com CI/CD
Maior qualidade de código
Refatoração segura
Menor risco em produção (GitHub)

No estilo Bellacosa Mainframe, podemos resumir assim:

O COBOL Check é a prova definitiva de que o COBOL não ficou preso ao passado. O gigante aprendeu a testar como os sistemas modernos, mas continua entregando a confiabilidade que mantém bancos, governos e grandes empresas funcionando todos os dias. ☕💣🚀

terça-feira, 1 de outubro de 2024

🧠 Zowe na Veia: o Mainframe para Padawans com IDE VSCODE

Bellacosa Mainframe apresenta o Zowe

🧠 Zowe na Veia: o Mainframe para Padawans com IDE VSCODE

Durante décadas, o mainframe foi visto como um monólito inalcançável, protegido por telas verdes, comandos crípticos e um pequeno grupo de “iniciados”.
Mas o mundo mudou. DevOps chegou, APIs dominaram, CI/CD virou regra — e o z/OS precisava conversar com esse novo ecossistema.

É aqui que entra o Zowe.

Zowe não substitui o mainframe.
Zowe traduz o mainframe.

🔷 O que é Zowe, afinal?

Zowe é um framework open source que permite que desenvolvedores não-mainframe e ferramentas modernas acessem e utilizem recursos e serviços do z/OS de forma padronizada, segura e moderna.

Em vez de forçar todo mundo a aprender ISPF no primeiro dia, o Zowe oferece:

CLI
APIs REST
Interface Web (Desktop)
Plugins para IDEs
SDKs modernos (Python e Node.js)

👉 Resultado?
O mainframe passa a ser plataforma, não “ilha”.

🏗️ Arquitetura do Zowe: Server x Client

🖥️ Zowe Server Components (rodam no z/OS ou container)

Os principais componentes de servidor são:

ZLUX (Zowe Application Framework)
Onde executam aplicações web e o Zowe Desktop
API Gateway
Parte do API Mediation Layer, responsável por roteamento e segurança
API Catalog
Catálogo central de todas as APIs REST conhecidas pelo Zowe
ZSS Server (Zowe System Services)
Executa chamadas nativas ao z/OS
Cross Memory Server
Executa serviços autorizados em nome do ZSS
File Explorer API
API REST para datasets, USS e arquivos

📌 Tudo isso respeitando RACF / SAF / ACF2 / Top Secret.
Sem atalhos. Sem gambiarra.

💻 Zowe Client Components (rodam na máquina do usuário)

No lado do cliente, o Zowe entrega:

🔹 Zowe CLI

Executa em Windows, Linux e macOS
Usa Node.js + npm
Não tem componente no z/OS
Acessa o mainframe via REST APIs (z/OSMF, Zowe APIs)

👉 Ideal para automação, scripts e pipelines CI/CD.

🔹 Zowe Explorer

Plugin para VS Code (ou IntelliJ)
Navegação de datasets como pastas
Submissão de JCL sem ISPF

👉 Onboarding rápido para quem vem do mundo distribuído.

🔹 Zowe Desktop

Interface gráfica via browser
Gerenciamento de jobs, datasets e aplicações
Estilo “Windows-like”

🔹 SDKs do Zowe

Zowe SDK for Python → precisa de Python
Zowe SDK for Node.js → precisa de Node.js

❌ Não existe SDK C++
❌ Zowe não é emulador 3270

⚙️ Pré-requisitos do Zowe Server (pegadinha de prova)

O Zowe Server pode exigir:

✅ Java SDK
✅ Node.js
✅ npm
✅ z/OSMF

❌ z/OS Connect não é requisito
❌ WAS Liberty não é necessário
❌ Enterprise COBOL não tem relação

🧩 Extensibilidade: onde o Zowe brilha

🔌 Zowe Application Framework (ZLUX)

Plugins podem oferecer:

Interfaces gráficas no Zowe Desktop
Aplicações em Angular ou React
Serviços RESTful
Comunicação entre aplicações
Preferências e configurações persistentes

❌ Nada de COBOL
❌ Nada de PHP
❌ Nada de código nativo

É web, simples assim.

🌐 API Mediation Layer

Para registrar um serviço REST no Zowe, você pode:

📄 Criar um YAML em api-defs
🔁 Chamar a API Discovery REST
⚙️ Usar onboard enablers do Zowe

❌ API Catalog não registra
❌ Nada é “auto-detectado”

🧪 Zowe CLI Plug-ins

Para criar um plug-in do CLI, você precisa:

Escrever em JavaScript ou TypeScript
Usar o Zowe Imperative Framework
Empacotar com npm
Instalar com zowe plugins install

❌ Não existe “packaging tool” do Zowe
❌ Não mexa no PATH

🧠 Bellacosa Insight Final

“Zowe não é para acabar com o ISPF.
É para impedir que o mainframe vire um museu.”

Quem ignora o Zowe hoje:

trava CI/CD
afasta novos desenvolvedores
isola o z/OS do negócio

Quem entende o Zowe:

transforma o mainframe em API Platform
integra com DevOps de verdade
garante longevidade tecnológica

🎯 Conclusão

Zowe é o ponto de convergência entre:

robustez do mainframe
agilidade do mundo moderno
segurança corporativa
cultura DevOps

Não é hype.
É sobrevivência arquitetural.

segunda-feira, 23 de maio de 2022

CI/CD: DevOps sem Mistérios para Programadores COBOL

Bellacosa Mainframe ci cd em devops sem misterios

☕ Um Café no Bellacosa Mainframe

DevOps sem Mistérios para Programadores COBOL

Como entender CI/CD, Containers, Kubernetes, IaC e DevOps usando exemplos do IBM Z

"Um programador COBOL experiente descobre rapidamente que DevOps não substitui o Mainframe. Ele apenas automatiza aquilo que os grandes bancos já faziam há muitos anos."

Antes de tudo...

Imagine um banco.

Todos os dias existem milhares de programas COBOL sendo alterados.

Imagine fazer isso manualmente.

Editar.

Compilar.

Gerar Load Module.

Fazer BIND.

Atualizar CICS.

Liberar produção.

Executar testes.

Se cada desenvolvedor fizesse isso do seu jeito...

...o banco pararia em poucas horas.

Foi exatamente para resolver esse problema que nasceu o DevOps.

Não para Cloud.

Não para Containers.

Mas para organizar o desenvolvimento.

1 — CI/CD

A imagem mostra:

Código

↓

Build

↓

Testes

↓

Deploy

Parece moderno.

Mas vamos traduzir.

No Mainframe seria algo parecido com:

Editar COBOL

↓

Compile

↓

Link Edit

↓

BIND DB2

↓

Newcopy CICS

↓

Testes

↓

Produção

Percebe?

É praticamente igual.

A diferença é que hoje tudo isso acontece automaticamente.

O que significa CI?

Continuous Integration.

Integração Contínua.

Na prática:

Em vez de esperar um mês para juntar alterações...

...cada alteração é integrada imediatamente.

Imagine cinco programadores.

Cada um altera um programa.

Antigamente:

João altera.

Maria altera.

José altera.

Carlos altera.

Tudo junta sexta-feira.

Sexta-feira...

Nada compila.

Ninguém sabe quem quebrou.

Hoje:

Commit

↓

Compile automático

↓

Teste automático

↓

Se falhar...

ninguém faz Merge.

Muito mais seguro.

No Mainframe

Imagine ISPW.

Imagine Endevor.

Imagine Changeman.

Quando você promove um componente...

Já existe uma pipeline.

Hoje ela apenas ficou mais inteligente.

2 — Container

Essa talvez seja a palavra mais mal compreendida.

Todo mundo fala:

"Container."

Mas...

O que é?

Imagine que você escreveu um programa COBOL.

Ele precisa:

Enterprise COBOL
LE Runtime
Db2 Client
MQ
Bibliotecas
Configuração
Certificados

Se você copiar apenas o executável...

Não funciona.

O Container resolve exatamente isso.

Ele empacota tudo.

Programa

+

Bibliotecas

+

Dependências

+

Configuração

+

Runtime

Tudo vira um único pacote.

Analogia Mainframe

Imagine um LOADLIB completo.

Ou uma STEPLIB preparada.

Você leva exatamente o ambiente necessário.

O Container faz isso para Linux.

Por que isso é importante?

Porque elimina:

"Na minha máquina funciona."

Essa frase praticamente desaparece.

3 — Kubernetes

A imagem chama Kubernetes de controlador de tráfego.

Gostei dessa definição.

Imagine um banco.

Existem:

Servidor A

Servidor B

Servidor C

Servidor D

Se um servidor morrer?

Quem percebe?

Quem cria outro?

Quem redistribui usuários?

Quem balanceia carga?

No mundo Cloud:

Kubernetes.

No Mainframe...

Quem faz isso?

Vários componentes.

WLM.

Sysplex.

Coupling Facility.

Dynamic Routing do CICS.

VIPA.

Parallel Sysplex.

Na prática...

IBM resolveu isso muito antes.

Só usou outros nomes.

O Kubernetes faz:

escala
reinicia
monitora
distribui
atualiza

Tudo sozinho.

4 — Infrastructure as Code (IaC)

Essa talvez seja a maior revolução.

Imagine instalar um servidor manualmente.

Clique.

Clique.

Clique.

Próximo.

Avançar.

OK.

Agora imagine repetir isso cem vezes.

Impossível.

Então surgiu:

Infrastructure as Code.

Em vez de clicar...

Você escreve.

Exemplo simplificado:

Servidor:

Linux

8 CPUs

32 GB

Porta 443

Firewall ativo

Rede privada

Pronto.

Um script cria tudo.

No mundo IBM Z

Isso lembra muito:

JCL.

Pense nisso.

JCL descreve infraestrutura.

Quero executar

este programa

com esta memória

este dataset

esta região

estas bibliotecas

Na essência...

JCL já era Infrastructure as Code.

Décadas antes do termo existir.

5 — Pipeline

Pipeline é uma linha de produção.

Literalmente.

A imagem mostra:

Código

↓

Build

↓

Teste

↓

Scan

↓

Deploy

No banco isso pode virar:

Developer

↓

Git

↓

Compile COBOL

↓

Compile Copybooks

↓

SQL Precompiler

↓

DBRM

↓

Bind

↓

Unit Test

↓

SonarQube

↓

Deploy QA

↓

Deploy Homologação

↓

Deploy Produção

Tudo automático.

Ferramentas comuns

GitHub Actions

GitLab CI

Azure DevOps

Jenkins

Tekton

ArgoCD

UrbanCode Deploy

ISPW

Endevor

6 — Monitoring

Depois que o sistema entra em produção...

Acabou?

Muito pelo contrário.

Começa o trabalho.

Monitoramento significa responder perguntas como:

CPU está alta?

Memória?

Tempo de resposta?

Fila MQ?

Db2?

CICS?

VSAM?

JES2?

SMF?

No IBM Z

Você já conhece muitos monitores.

RMF

OMEGAMON

SMF

SDSF

NetView

Tivoli

Z APM

Instana

Todos fazem exatamente isso.

Sem monitoramento...

Você só descobre o problema quando o cliente liga.

7 — Configuration Management

Esse conceito nasceu porque administradores faziam mudanças manualmente.

Servidor 1:

Java 17

Servidor 2:

Java 11

Servidor 3:

Java 21

Resultado?

Caos.

Ferramentas como:

Ansible

Chef

Puppet

SaltStack

garantem que todos fiquem iguais.

Analogia Mainframe

Pense em PROCLIB.

PARMLIB.

IEASYSxx.

JES2PARM.

RACF.

Tudo precisa permanecer consistente.

A diferença é que hoje isso é automatizado.

8 — CI/CD novamente

A oitava imagem aprofunda o assunto.

Vale destacar uma diferença importante.

Continuous Integration

Sempre compila.

Sempre testa.

Sempre valida.

Mas nem sempre publica.

Continuous Delivery

Tudo pronto.

Apenas alguém aperta:

Deploy.

Continuous Deployment

Nem isso.

Terminou os testes?

Produção automaticamente.

Bancos normalmente fazem:

CI

+

Continuous Delivery

Poucos usam Continuous Deployment completo.

Por razões regulatórias.

9 — IaC novamente

Agora aparecem ferramentas.

Terraform.

CloudFormation.

Pulumi.

Ansible.

Para um programador COBOL

A ideia é simples.

Você não administra servidores.

Você administra código que administra servidores.

É um novo nível de abstração.

10 — DevOps Culture

Essa é provavelmente a imagem mais importante.

Porque DevOps NÃO é ferramenta.

É cultura.

Imagine:

Desenvolvimento culpa Infraestrutura.

Infraestrutura culpa Banco.

Banco culpa Segurança.

Segurança culpa Rede.

Rede culpa Middleware.

Middleware culpa COBOL.

COBOL culpa CICS.

CICS culpa Db2.

Resultado?

Ninguém resolve.

DevOps diz:

Todos são responsáveis.

O objetivo

Eliminar silos.

Criar colaboração.

Automatizar tarefas repetitivas.

Aprender continuamente.

Compartilhar conhecimento.

O que muda para um Programador COBOL Padawan?

Antigamente bastava dominar:

COBOL
JCL
CICS
DB2
VSAM

Hoje isso continua essencial, mas não é suficiente em muitos projetos de modernização. Um profissional de IBM Z passa a ganhar vantagem competitiva quando também compreende:

Git e GitHub
GitFlow e Pull Requests
Jenkins, GitHub Actions ou Azure DevOps
UrbanCode Deploy ou ISPW Pipelines
SonarQube para análise estática
Docker e conceitos de Containers (mesmo que não execute COBOL dentro deles)
Kubernetes e OpenShift para entender onde vivem as APIs modernas
Ansible para automação de tarefas no z/OS
APIs REST e JSON
z/OS Connect Enterprise Edition
Observabilidade com Instana, OMEGAMON e OpenTelemetry
Segurança integrada com RACF, certificados digitais, OAuth2, JWT e TLS
Integração contínua de aplicações COBOL com pipelines automatizadas

A Grande Lição do Mestre

Quando um Padawan olha para CI/CD, Kubernetes, Infrastructure as Code ou DevOps, pode parecer que tudo isso pertence apenas ao mundo Linux e à Cloud. Mas um profissional experiente de IBM Z percebe algo diferente: esses conceitos representam uma evolução natural de princípios que o ecossistema mainframe já aplicava há décadas — padronização, automação, controle de mudanças, alta disponibilidade, rastreabilidade e confiabilidade.

A grande transformação não está em abandonar o COBOL. Está em conectá-lo a um ecossistema moderno de desenvolvimento contínuo, APIs, automação e observabilidade. O futuro do programador COBOL não é escolher entre "mainframe" ou "DevOps"; é dominar ambos e entender como fazer o IBM Z conversar com o restante da arquitetura corporativa.

No fim das contas, DevOps não substitui o conhecimento de um programador COBOL. Ele amplia esse conhecimento, permitindo que aplicações críticas continuem evoluindo com velocidade, segurança e qualidade — exatamente o que os maiores bancos do mundo esperam de seus sistemas mais importantes.

sexta-feira, 5 de abril de 2019

IBM Mainframe Discovery : Capítulo XVI — A Fábrica Automática da Federação

Bellacosa Mainframe apresenta o ibm mainframe parte xvi

☕ Um Café no Bellacosa Mainframe

Capítulo XVI — A Fábrica Automática da Federação

DevOps, Git, Zowe, CI/CD e Ansible: Quando a Nave Aprendeu a Construir a Si Mesma

DÉCIMA TERCEIRA REGRA DOS CONSTRUTORES DO UNIVERSO

Nunca conserte manualmente uma nave espacial...

...se você pode ensinar a nave a se consertar sozinha.

Essa frase parece preguiça.

Na realidade...

é sobrevivência.

Imagine uma frota composta por:

400 naves;
25 mil computadores;
milhões de linhas de código;
milhares de engenheiros.

Agora imagine que cada atualização seja feita manualmente.

Um computador por vez.

Um arquivo por vez.

Um comando por vez.

Boa sorte.

Você vai precisar de umas quatro vidas.

A Oficina da Enterprise

Imagine entrar no enorme hangar de manutenção da nave.

Você espera encontrar centenas de mecânicos.

Mas encontra algo curioso.

Braços robóticos.

Esteiras.

Sensores.

Drones.

Computadores.

Tudo funcionando praticamente sozinho.

Os engenheiros apenas observam.

Foi exatamente essa transformação que aconteceu na engenharia de software.

Ela ganhou um nome.

DevOps.

O Grande Mal-Entendido

Existe um mito que atravessa gerações.

"DevOps é uma ferramenta."

Não.

Outro diz:

"DevOps é um software."

Também não.

DevOps é uma filosofia.

Uma forma diferente de pensar.

Quando Existiam Dois Planetas

Durante décadas existiram dois mundos.

No primeiro viviam os:

Desenvolvedores.

No segundo:

Operações.

Os desenvolvedores diziam:

"Na minha máquina funciona."

Operações respondiam:

"Aqui não."

E assim começaram inúmeras guerras interplanetárias.

Surge a Federação

Alguém finalmente fez uma pergunta inteligente.

"E se, em vez de brigarem, eles trabalhassem juntos?"

Nascia uma nova civilização.

Seu nome era:

DevOps.

Não significava eliminar diferenças.

Significava criar cooperação.

O Grande Esteira Espacial

Imagine uma enorme fábrica.

Em uma ponta entra:

código COBOL.

Na outra ponta sai:

software em produção.

No caminho existem dezenas de robôs.

Cada um realiza uma tarefa.

Compilar.

Testar.

Analisar.

Empacotar.

Implantar.

Documentar.

Monitorar.

Tudo automaticamente.

Essa esteira chama-se:

Pipeline.

Git — O Grande Livro da História

Imagine uma gigantesca biblioteca.

Cada vez que um engenheiro altera um projeto...

uma nova página é escrita.

Nada desaparece.

Tudo permanece registrado.

Quem fez.

Quando fez.

Por que fez.

Esse livro chama-se:

Git.

A Máquina do Tempo

Imagine descobrir que a alteração feita ontem destruiu metade da nave.

Pânico?

Não.

O Git responde calmamente:

"Podemos voltar para terça-feira às 14h37."

É quase uma máquina do tempo.

Branches — Universos Paralelos

Agora imagine cientistas criando versões diferentes da mesma nave.

Uma possui motores novos.

Outra testa novos radares.

Outra modifica apenas o painel.

Nenhuma interfere nas demais.

Esses universos paralelos chamam-se:

Branches.

Quando tudo funciona...

eles se unem novamente.

Pull Request — O Conselho da Federação

Imagine um jovem engenheiro.

Ele desenvolveu uma melhoria.

Mas antes de instalar...

apresenta o projeto ao conselho científico.

Todos analisam.

Comentam.

Sugestões aparecem.

Depois aprovam.

No Git isso chama-se:

Pull Request.

O Robô Incansável

Imagine um funcionário.

Ele nunca dorme.

Nunca tira férias.

Nunca esquece um comando.

Nunca se distrai.

Sempre faz exatamente a mesma tarefa.

Esse funcionário chama-se:

CI.

Continuous Integration.

CI — A Oficina Inteligente

Toda vez que alguém modifica o código...

o robô imediatamente:

compila.

executa testes.

verifica qualidade.

analisa segurança.

gera relatórios.

Tudo antes que alguém aperte qualquer botão.

CD — A Nave Decola Sozinha

Depois surge outro robô.

Ele pergunta:

"Os testes passaram?"

Sim.

Então ele próprio instala a nova versão.

Sem intervenção humana.

Esse é o:

Continuous Delivery

Continuous Deployment.

Dependendo do nível de automação.

Jenkins — O Maestro da Oficina

Imagine um enorme maestro.

Ele não toca instrumentos.

Mas coordena toda a orquestra.

Quem entra.

Quem espera.

Quem executa.

Esse maestro chama-se:

Jenkins.

Durante muitos anos tornou-se um dos grandes orquestradores de pipelines corporativos, inclusive em ambientes IBM Z.

Zowe — O Novo Painel de Controle

Agora imagine um jovem piloto chegando à Enterprise.

Ele olha para o tradicional terminal verde.

Depois pergunta:

"Posso usar VS Code?"

Os veteranos respondem:

"Pode."

Graças ao:

Zowe.

O Zowe aproxima o universo IBM Z das ferramentas modernas de desenvolvimento, oferecendo CLI, APIs e integração com ambientes como Visual Studio Code.

O Terminal Universal

Imagine possuir um controle remoto capaz de conversar com toda a nave.

Datasets.

Jobs.

USS.

JES.

RACF.

Arquivos.

Tudo através de comandos simples.

Essa é uma das funções da:

Zowe CLI.

VS Code Chega à Nave

Durante décadas o desenvolvimento acontecia principalmente em terminais 3270.

Hoje muitos profissionais escrevem COBOL utilizando:

Visual Studio Code.

Syntax Highlight.

Git.

Autocomplete.

Debug.

Integração contínua.

O universo mudou.

O COBOL também.

Ansible — O Capitão das Missões Repetitivas

Imagine precisar configurar:

500 naves.

Você faria manualmente?

Claro que não.

Você escreveria um roteiro.

O comandante robótico executaria tudo.

Esse comandante chama-se:

Ansible.

Os Playbooks

Imagine um caderno.

Cada página descreve uma missão.

Instalar software.

Criar usuários.

Atualizar servidores.

Executar backups.

Configurar RACF.

Aplicar patches.

Esse caderno chama-se:

Playbook.

O robô apenas segue as instruções.

Infrastructure as Code

Chegamos a uma ideia revolucionária.

Imagine descrever uma cidade inteira utilizando texto.

Depois apertar um botão.

A cidade aparece.

Isso parece ficção científica.

Mas existe.

Chama-se:

Infrastructure as Code.

A infraestrutura deixa de existir apenas na memória dos administradores.

Ela passa a ser descrita em código.

Versionada.

Testada.

Automatizada.

Testes Nunca Dormem

Imagine construir uma nave.

Antes da decolagem...

milhares de sensores verificam:

motores.

combustível.

comunicações.

escudos.

radares.

Tudo automaticamente.

O mesmo acontece na engenharia moderna.

Testes automatizados executam continuamente.

No universo IBM Z encontramos ferramentas como:

ZUnit.

Galasa.

ZVTP.

que ajudam a validar aplicações antes que cheguem à produção.

A Inteligência Artificial Entra na Oficina

Agora imagine outro personagem.

Ele observa milhares de alterações.

Sugere melhorias.

Escreve testes.

Explica código.

Detecta riscos.

A IA começa a atuar como um engenheiro auxiliar.

Não substitui especialistas.

Amplia suas capacidades.

O Que Diz Spruth?

Quando Wilhelm G. Spruth escreveu seu relatório em 2010, muitos dos conceitos modernos de DevOps ainda estavam amadurecendo. Entretanto, ele já destacava que uma das grandes forças do IBM Z era sua capacidade de integrar tecnologias novas sem abandonar os princípios fundamentais de confiabilidade, automação e administração centralizada.

Essa visão preparou o terreno para que Git, pipelines, APIs, Zowe e automação encontrassem um ambiente naturalmente preparado para evoluir.

O Que Mudou Desde 2010?

Se Spruth visitasse um centro de desenvolvimento IBM Z em 2026...

provavelmente encontraria:

GitHub;
GitLab;
Jenkins;
GitHub Actions;
Azure DevOps;
IBM Dependency Based Build (DBB);
IBM zBuilder;
Zowe Explorer;
IBM Z Open Editor;
VS Code;
Ansible Collections for IBM Z;
Galasa;
ZUnit;
SonarQube;
OpenTelemetry;
IA auxiliando desenvolvimento;
pipelines executando centenas de validações automaticamente.

O curioso?

O COBOL continua presente.

Mas agora trabalha em uma fábrica muito mais inteligente.

O Verdadeiro Segredo

Muitos acreditam que DevOps serve para acelerar entregas.

Isso é apenas parte da história.

Seu verdadeiro objetivo é:

reduzir erros.

eliminar tarefas repetitivas.

aumentar qualidade.

permitir evolução contínua.

Velocidade é consequência.

Não finalidade.

Uma Lição Para Além da Tecnologia

Existe uma reflexão escondida neste capítulo.

Os grandes exploradores da galáxia nunca gastam energia repetindo aquilo que uma máquina pode fazer.

Eles preferem utilizar seu tempo para:

pensar.

criar.

resolver problemas.

descobrir novos mundos.

Automatizar não significa substituir pessoas.

Significa libertá-las para tarefas mais inteligentes.

Talvez seja exatamente por isso que DevOps tenha transformado a engenharia de software.

Curiosidades do Diário de Bordo

🚀 O Open Mainframe Project impulsionou ferramentas como Zowe, aproximando o IBM Z do ecossistema moderno de desenvolvimento colaborativo.

🔧 O Ansible permite automatizar tarefas administrativas no z/OS utilizando playbooks declarativos, reduzindo erros operacionais.

📚 Ferramentas como IBM Dependency Based Build (DBB) e IBM zBuilder modernizaram pipelines de compilação COBOL, integrando-os naturalmente ao Git e aos ambientes CI/CD.

🤖 A Inteligência Artificial já auxilia desenvolvedores IBM Z na geração de testes, análise de código, documentação e investigação de problemas.

Diário de Bordo do Padawan COBOL

Antes de deixar a Grande Oficina da Federação, grave estas coordenadas no seu Holocron Técnico:

✅ DevOps é uma cultura de colaboração, não apenas um conjunto de ferramentas.

✅ Git preserva a história do código e permite evolução segura através de branches, revisões e versionamento.

✅ CI/CD transforma a construção e implantação de software em processos repetíveis, confiáveis e automatizados.

✅ Zowe, VS Code, Jenkins, DBB, zBuilder, Ansible e IA mostram que o IBM Z não ficou parado no tempo; ele aprendeu a construir o futuro continuamente.

Próxima Missão

No próximo capítulo faremos nossa última grande viagem.

Entraremos na Ponte de Comando do Futuro.

Conheceremos o IBM z17, a Inteligência Artificial embarcada, o watsonx, a computação quântica, a criptografia pós-quântica e as próximas décadas da arquitetura IBM Z.

Descobriremos que a maior surpresa de toda esta jornada é que a nave mais antiga da Federação... talvez seja justamente a mais preparada para explorar os próximos cinquenta anos da computação.

E então, finalmente, responderemos à pergunta que acompanha este livro desde o primeiro capítulo:

O Mainframe sobreviveu ao futuro... ou foi o futuro que acabou se parecendo com o Mainframe?

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.