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".

 

Bellacosa Mainframe e as muitas ides de desenvolvimento do COBOL

☕🟩 “DA TELA VERDE AO VS CODE: A GUERRA DAS IDEs MAINFRAME QUE NINGUÉM TE CONTOU”

"Enquanto o programador moderno instala 847 extensões no VS Code… o veterano do ISPF compila COBOL usando apenas PF3, ódio corporativo e café."

---

Existe uma jornada secreta no mundo mainframe.

Todo programador z/OS passa por ela.

É quase uma evolução Pokémon corporativa:

ISPF → RDz → IDz → Zowe → VS Code → “volta pro ISPF porque era mais rápido”

E cada geração acredita que encontrou “a IDE definitiva”.

Spoiler:
ninguém encontrou.

Porque no fundo…
o programador mainframe ama sofrer um pouquinho.

---

🟩 ISPF — O IMPERADOR DA TELA VERDE

Sucessor das folhas de codificação

Antes de Eclipse.

Antes do Java.

Antes do VS Code existir.

Antes de metade da internet nascer.

Já existia o ISPF.

O Interactive System Productivity Facility.

Ou como muitos chamam:

“O cockpit do operador Jedi do mainframe.”

Criado nos anos 70, o ISPF não era bonito.
Ele era EFICIENTE.

Sem mouse.
Sem animação.
Sem autocomplete coloridinho gamer.

Mas absurdamente rápido.

Veteranos digitam comandos ISPF numa velocidade que parece hack.

Você pisca…
e o cara já:

• abriu dataset,

• editou membro,

• compilou COBOL,

• submeteu JCL,

• analisou spool,

• corrigiu abend,

• e ainda reclamou do Java.

Tudo em 40 segundos.

---

🚀 O Segredo da Performance do ISPF

Aqui vem um easter egg que juniors não acreditam:

O ISPF consome RIDICULAMENTE pouca memória.

Enquanto IDEs modernas:

• comem gigabytes de RAM,

• abrem 19 processos,

• travam por causa de plugin,

o ISPF praticamente roda no poder da determinação humana.

Em muitos ambientes:

• 2 MB já eram luxo,

• 8 MB parecia ficção científica,

• e ainda assim o sistema inteiro voava.

O motivo?

Tudo era pensado para:

• eficiência,

• terminal remoto,

• baixo consumo,

• alta responsividade.

O ISPF é tão rápido porque ele nasceu num mundo onde desperdiçar CPU era pecado mortal.

---

☕ Eclipse — O Portal Que Trouxe o Mainframe ao Mundo Moderno

Aí chegou o Eclipse.

E o mundo mainframe olhou desconfiado.

Porque pela primeira vez alguém disse:

“E se o programador COBOL usar mouse?”

Silêncio absoluto no datacenter.

---

🟦 RDz — Rational Developer for z Systems

O lendário RDz surgiu como a grande modernização visual do desenvolvimento z/OS.

Depois virou:

• Rational Developer for System z

• Rational Developer for z Systems

• e mais tarde IDz.

O RDz trouxe:

• syntax highlight,

• autocomplete,

• debug visual,

• integração DB2,

• remote edit,

• projetos modernos,

• interface gráfica.

Os juniors acharam mágico.

Os veteranos disseram:

“isso é lento.”

E honestamente?
Eles tinham razão em parte.

---

🧠 O Eclipse Tinha FOME

O Eclipse revolucionou o desenvolvimento mainframe…

mas também inaugurou um novo conceito:

“Quanto mais plugin, mais sofrimento.”

RDz/IDz dependiam muito da JVM.

Então começaram os fenômenos paranormais:

• OutOfMemoryError,

• workspace corrompido,

• garbage collection assassina,

• travamentos misteriosos,

• startup de 4 minutos.

Programadores começaram a decorar parâmetros JVM como magias ocultas:

-Xms512m
-Xmx4096m

Na época isso parecia MUITA memória.

Hoje o Chrome usa isso só pra abrir duas abas do YouTube.

---

🟨 IDz — IBM Developer for z/OS

IBM Developer for z/OS

O RDz evoluiu para o atual IBM Developer for z/OS (IDz). (IBM)

A versão moderna continua baseada em Eclipse, mas muito mais refinada.

Recursos atuais:

• integração Git,

• pipelines DevOps,

• debugging avançado,

• análise de impacto,

• integração com APIs,

• suporte híbrido,

• AI assistance.

A IBM hoje posiciona o IDz como parte da modernização enterprise do z/OS. (IBM)

---

📅 Release Atual

As linhas atuais giram em torno da família 16.x do IDz/IDzEE. (IBM)

---

🧠 Memória e Performance

Aqui entra uma verdade universal:

Quanto maior o workspace COBOL…
mais RAM você oferece em sacrifício.

Projetos enormes:

• copybooks gigantes,

• milhões de linhas,

• análise cross-reference,

fazem o Eclipse sofrer.

Ambientes corporativos frequentemente usam:

• 4 GB até 8 GB JVM,

• SSD obrigatório,

• muito tuning.

Mesmo assim…

o autocomplete COBOL moderno impressiona MUITO.

---

⚡ KDz — O Eclipse “Turbo Corporativo”

Pouca gente lembra do apelido KDz.

Muitos ambientes chamavam certas distribuições customizadas do Developer for z como:

• KDz,

• KDz tooling,

• kits corporativos z/OS.

Em geral eram empacotamentos enterprise:

• plugins internos,

• integração RACF,

• ferramentas DevOps,

• scanners,

• analyzers.

O problema?

Cada empresa criava um “Frankenstein Eclipse”.

Resultado:

• 14 plugins incompatíveis,

• 9 versões Java,

• workspace amaldiçoado,

• startup digno de filme de terror.

---

🟦 Visual Studio Code — O Escolhido da Nova Geração

Então surgiu o VS Code.

Leve.
Rápido.
Moderno.

E o mundo mainframe falou:

“Finalmente.”

---

🔥 Wazi Developer for VS Code

A IBM percebeu algo importante:

Os juniors NÃO queriam Eclipse pesado.

Então nasceu o:
IBM Developer for z/OS on VS Code, antigo Wazi for VS Code. (IBM)

Ele usa:

• VS Code,

• Z Open Editor,

• integração Zowe,

• debug moderno,

• Git nativo,

• APIs.

Hoje é uma das maiores apostas da IBM para atrair nova geração.

---

📅 Releases Atuais

• IDz on VS Code / Wazi evoluindo fortemente em 2025–2026. (Visual Studio Marketplace)

• IBM Z Open Editor 6.x já demonstrado publicamente. (YouTube)

---

🚀 Performance

Aqui acontece a magia.

VS Code:

• inicia rápido,

• consome menos RAM,

• responde melhor,

• tem ecossistema moderno.

Muitos ambientes rodam confortavelmente com:

• 1 GB a 2 GB RAM,

• contra múltiplos GB do Eclipse.

E isso seduziu MUITO programador COBOL novo.

---

🟪 Zowe — O “Linux do Mainframe”

Zowe Project

O Zowe foi outro terremoto cultural.

Porque ele trouxe algo impensável:

mainframe via CLI moderna

Veteranos ficaram confusos vendo:

• npm,

• Node.js,

• REST API,

• terminal moderno falando com z/OS.

Parecia cyberpunk corporativo.

---

🧠 O Que o Zowe Mudou

O Zowe criou:

• APIs REST para z/OS,

• CLI moderna,

• integração DevOps,

• extensões VS Code,

• acesso datasets via interface moderna.

Hoje ele é praticamente peça-chave da modernização mainframe. (Zowe Docs)

---

📅 Release Atual

A linha moderna está na família:

• Zowe V3.x em evolução contínua durante 2025–2026. (Zowe Docs)

---

☕ O Plot Twist Final

E depois de tudo isso…

sabe o que muitos veteranos fazem?

Voltam pro ISPF.

Porque:

• PF8 ainda é mais rápido,

• split screen é lendário,

• editar dataset gigante no 3270 continua absurdo,

• e submitar JCL no painel 3.4 é praticamente arte marcial.

---

🛸 O Futuro das IDEs Mainframe

Hoje o ecossistema está dividido:

Ferramenta	Filosofia
ISPF	velocidade bruta
Eclipse / IDz	enterprise pesado
VS Code	modernização leve
Zowe	DevOps/API/cloud
Wazi	ponte nova geração
3270	religião corporativa

E o mais curioso?

TODAS coexistem.

Porque o mainframe não abandona tecnologia.
Ele acumula.

Como um dragão corporativo guardando tesouros tecnológicos de 50 anos.

---

☕ Conclusão Bellacosa Mainframe

O mundo moderno acha que evolução tecnológica significa substituir tudo.

O mainframe pensa diferente.

Ele acredita em:

• compatibilidade,

• estabilidade,

• coexistência,

• sobrevivência.

Por isso hoje você encontra:

• ISPF dos anos 70,

• Eclipse dos anos 2000,

• VS Code moderno,

• APIs REST,

• IA,

• OpenShift,

• Kubernetes,

• e COBOL…

todos funcionando juntos no MESMO ambiente.

E honestamente?

Isso é uma das coisas mais incríveis da computação moderna.

---

☕🟩 Bellacosa Mainframe
"Enquanto o VS Code baixa extensões… o ISPF já compilou o COBOL e foi tomar café."

Se eu esqueci de alguma IDE, deixe nos comentarios para enriquecer ainda mais esse artigo.

Bellacosa Mainframe introducao a modernizacao do cics mainframe seculo xxi

☕💣🚀 PADAWAN, MODERNIZAR O CICS NÃO É JOGAR COBOL FORA. É ENSINAR UMA LENDA DE 50 ANOS A FALAR REST, JAVA E CLOUD!

Durante décadas, muita gente repetiu a mesma profecia:

"O Mainframe vai acabar."

Enquanto isso, silenciosamente, o CICS continuou processando bilhões de transações por dia.

E aqui está a grande ironia tecnológica da nossa época:

As empresas que tentaram substituir completamente seus sistemas CICS descobriram que recriar 40 anos de regras de negócio é muito mais difícil do que parece.

Foi então que surgiu uma pergunta mais inteligente:

E se, em vez de substituir, nós modernizarmos?

É exatamente isso que o CICS moderno faz.

---

O PRIMEIRO ERRO: CONFUNDIR MODERNIZAÇÃO COM REESCRITA

Quando alguém fala em modernização, muitos imaginam:

COBOL -> Java
Mainframe -> Cloud
3270 -> Browser

Mas o CICS moderno propõe algo diferente:

COBOL + Java
Mainframe + Cloud
3270 + REST
VSAM + APIs

A IBM chama isso de:

Hybrid Cloud

Ou seja:

O sistema continua executando onde sempre funcionou, mas agora conversa com aplicações modernas.

---

PASSO 1 – ENTENDER O QUE VOCÊ POSSUI

Antes de modernizar qualquer aplicação CICS, faça um inventário.

Identifique:

• Transações

• Programas COBOL

• Arquivos VSAM

• DB2

• COMMAREAs

• Web Services existentes

• Dependências

Perguntas importantes:

• O sistema ainda usa 3270?

• Existem APIs?

• Existe documentação?

• Existe código-fonte?

Acredite:

Nem sempre existe.

E sim...

Existem sistemas produtivos em que o fonte original desapareceu há décadas.

---

PASSO 2 – SEPARAR APRESENTAÇÃO E NEGÓCIO

A arquitetura clássica ensinada pela IBM possui:

Presentation Layer
Business Logic Layer
Data Services Layer

Exemplo clássico:

PAYPGM
    |
    v
PAYBUS
    |
    v
VSAM

O PAYPGM fala com o usuário.

O PAYBUS contém as regras de negócio.

Quando isso já existe, a modernização fica muito mais simples.

---

PASSO 3 – TRANSFORMAR O NEGÓCIO EM SERVIÇO

O erro mais comum é tentar modernizar a tela.

A tela não tem valor.

O valor está na regra de negócio.

Por isso o melhor caminho normalmente é:

Browser
    |
REST API
    |
PAYBUS
    |
VSAM

Observe:

O COBOL continua vivo.

Apenas ganhou uma nova interface.

---

PASSO 4 – APOSENTAR A COMMAREA

A COMMAREA foi uma revolução.

Mas ela possui um limite:

32767 bytes

Isso era enorme em 1975.

Hoje não é.

A solução moderna:

Channels
Containers

Antes:

EXEC CICS LINK
     COMMAREA(...)
END-EXEC

Depois:

EXEC CICS LINK
     CHANNEL('PAYROLL')
END-EXEC

Benefícios:

• Sem limite prático

• Dados organizados

• Menos copybooks gigantes

• Melhor integração

---

PASSO 5 – INTRODUZIR JAVA SEM TRAUMA

Aqui surge a pergunta que assombra muitos programadores COBOL:

"Precisamos reescrever tudo em Java?"

Não.

E provavelmente você não deveria.

O CICS permite executar Java dentro do próprio ambiente.

Arquitetura:

CICS
   |
JVM Server
   |
Liberty
   |
Java

Agora o cenário fica interessante:

COBOL
   |
LINK
   |
Java

e também:

Java
   |
LINK
   |
COBOL

Os dois mundos coexistem.

---

PASSO 6 – DESCOBRIR O PODER DO LINK TO LIBERTY

Este é um dos recursos mais elegantes do CICS moderno.

Um programa COBOL pode chamar um método Java.

Exemplo:

@CICSProgram("CUSTGET")

Agora o COBOL pode executar:

EXEC CICS LINK
     PROGRAM('CUSTGET')
END-EXEC

Sem HTTP.

Sem REST.

Sem MQ.

Sem gambiarra.

Tudo dentro do próprio CICS.

---

PASSO 7 – ADOTAR APIs REST

Uma das formas mais comuns de modernização é expor programas COBOL como APIs REST.

Arquitetura:

Mobile App
     |
REST
     |
Java
     |
PAYBUS
     |
VSAM

O usuário nem imagina que existe COBOL por trás.

E isso é perfeitamente aceitável.

Aliás...

É exatamente o objetivo.

---

PASSO 8 – IMPLEMENTAR EVENT PROCESSING

Aqui está um superpoder pouco conhecido.

Imagine um sistema de apostas.

Toda vez que alguém aposta mais de R$ 50.000:

Evento

Mas você perdeu o fonte.

Como alterar o programa?

Você não altera.

O CICS observa eventos.

Exemplo:

EXEC CICS LINK

Ao detectar o comando:

Evento gerado

Sem modificar uma linha de COBOL.

Isso é Event Processing.

---

PASSO 9 – PROGRAMAÇÃO ASSÍNCRONA

Outro recurso poderoso.

Tradicional:

Programa A
espera B
espera C
espera D

Moderno:

Programa A

+---- B
|
+---- C
|
+---- D

Tudo executando simultaneamente.

Novas APIs:

RUN TRANSID
FETCH CHILD
FETCH ANY
FREE CHILD

Menos espera.

Mais throughput.

Mais escalabilidade.

---

PASSO 10 – ENTRAR NO MUNDO DEVOPS

Aqui muitos profissionais acreditam que existe:

DevOps Linux
DevOps Mainframe

Mas a IBM foi direta:

Existe apenas:

DevOps

Ferramentas modernas:

Git
VS Code
Zowe
Jenkins
DBB
Ansible
UrbanCode

O fluxo torna-se:

Git
 |
Build
 |
Test
 |
Deploy
 |
CICS

---

ERROS MAIS COMUNS

Erro 1

Tentar reescrever tudo.

Resultado:

Projeto de 5 anos.

Orçamento explode.

Sistema antigo continua rodando.

---

Erro 2

Modernizar a interface e esquecer a regra de negócio.

A regra é o patrimônio.

A tela é apenas um detalhe.

---

Erro 3

Ignorar testes.

Use:

ZUnit
JUnit
Mockito
Galasa

---

Erro 4

Não envolver o System Programmer.

Lembre-se:

Arquivos.

Recovery.

Resources.

Bundles.

JVM Servers.

Tudo isso depende dele.

---

SOLUÇÃO DE PROBLEMAS

EIBCALEN = 0

Primeira entrada da transação.

---

Programa novo não atualiza

Execute:

NEWCOPY

ou

REFRESH PROGRAM

---

COMMAREA truncada

Provavelmente ultrapassou:

32K

Migre para Containers.

---

LINK retornando erro

Verifique:

RESP
RESP2

Sempre.

---

CURIOSIDADE

Pouca gente sabe, mas o CICS nasceu em uma época em que muitos computadores ainda trabalhavam com cartões perfurados.

Hoje ele executa:

• APIs REST

• Java

• JSON

• Liberty

• Cloud

• DevOps

Sem abandonar sua essência transacional.

Isso talvez explique sua longevidade.

---

EASTER EGG MAINFRAME

Existe uma frase que quase todo profissional experiente de CICS aprende depois de alguns anos:

"O problema nunca está no CICS."

Primeiro você culpa:

• CICS

• VSAM

• RACF

• DB2

• MQ

Depois de algumas horas investigando...

Descobre que esqueceu de fazer:

EXEC CICS RETURN
END-EXEC

ou

EXEC CICS HANDLE CONDITION
END-EXEC

ou simplesmente compilou o programa errado.

Acontece mais do que deveria.

---

CONCLUSÃO

☕💣🚀 PADAWAN, O MAIOR SEGREDO DA MODERNIZAÇÃO NÃO É TROCAR COBOL POR JAVA.

É entender que o verdadeiro valor está nas regras de negócio acumuladas durante décadas.

O CICS moderno permite adicionar:

• REST

• Java

• Liberty

• Eventos

• APIs

• DevOps

• Cloud

sem destruir aquilo que já funciona.

E essa talvez seja a definição mais elegante de modernização:

Evoluir sem perder a confiança conquistada por milhões de transações executadas corretamente ao longo de décadas.

 

Bellacosa Mainframe apresenta o zowe 3.0

💻 Zowe: O Guia Completo de Server, CLI, SDK e Explorer para Mainframe

Se você está entrando no universo Zowe, seja para modernizar aplicações z/OS ou integrar ambientes DevOps, este guia é para você. Vamos destrinchar componentes do Zowe, pacotes de instalação, SDKs, CLI, Explorer e políticas de suporte, do jeito Bellacosa Mainframe: direto, didático e cheio de dicas de prova IBM.

---

1️⃣ O que é Zowe?

Zowe é um framework open source que permite que desenvolvedores, mesmo sem profundo conhecimento de z/OS, acessem e integrem recursos mainframe usando CLI, APIs REST e GUI.
Ele suporta tanto z/OS nativo quanto ambientes containerizados (Docker/Kubernetes), trazendo agilidade e modernidade para o mainframe.

Principais objetivos:

• Tornar z/OS acessível a desenvolvedores modernos

• Permitir integração com DevOps e pipelines CI/CD

• Oferecer APIs REST, CLI e GUI para operações mainframe

---

2️⃣ Zowe Server Components

O Zowe Server é distribuído em vários componentes que podem rodar no z/OS ou em containers.

Principais componentes:

Componente	Função	Plataforma
ZLUX	GUI web para navegação e dashboards	z/OS / Container
API Gateway	Mediação e roteamento de APIs REST	z/OS / Container
ZSS (Zowe Security Server)	Autenticação, autorização e gerenciamento de tokens	z/OS
File Explorer API	Serviços REST para manipulação de arquivos USS e PDS	z/OS / Container

⚠️ Nota: O Zowe CLI não é um servidor — ele roda no cliente.

Pacotes de distribuição do Zowe Server

Zowe Server pode ser instalado usando diferentes formatos:

• SMP/E Package – Método clássico IBM para z/OS (RECEIVE → APPLY → ACCEPT)

• Convenience Build (.pax file) – Binários compactados para extração e instalação em USS

• Docker Container – Permite execução em containers Linux/Kubernetes

Dica Bellacosa: .msi e .deb não são usados para Zowe Server; eles são apenas para clientes ou sistemas externos.

---

3️⃣ Instalando Zowe via SMP/E

O SMP/E package contém:

• FMID do Zowe (compactado em .pax)

• Program Directory

• Jobs auxiliares para instalação

Passo a passo:

1. Transferir o arquivo .pax para o USS

2. Extrair o conteúdo

3. Usar SMP/E commands: RECEIVE, APPLY, ACCEPT

4. Aplicar PTFs de correções ou atualizações

Atenção: após a instalação, é necessário criar instância Zowe, configurar segurança e iniciar started tasks. Não basta instalar o FMID.

---

4️⃣ Zowe CLI – A linha de comando

O Zowe CLI é um cliente que roda em Windows, Linux ou macOS.
Ele permite que você consuma APIs REST, interaja com USS, DB2, Jobs e muito mais, sem precisar abrir TSO ou ISPF.

Pré-requisitos:

• Node.js + npm instalado no sistema

Comandos básicos de instalação:

npm install -g @zowe/cli
zowe plugins install <plugin-name>
zowe profiles create zosmf-profile

Dicas de uso:

• Cada máquina que usa o CLI precisa de sua própria instalação

• Você pode criar profiles para armazenar endereços de host e credenciais

• É possível instalar múltiplos plug-ins para estender funcionalidades

---

5️⃣ Zowe Client SDKs

Zowe oferece SDKs para Python e Node.js, permitindo desenvolver scripts e aplicações customizadas usando APIs Zowe.

Instalação:

• Python SDK:

pip install zowe_zos_files_for_zowe_sdk-<version>.whl

• Node.js SDK:

npm install @zowe/core-for-zowe-sdk

Dica Bellacosa: Python SDK usa pip e Node.js SDK usa npm. Não confunda os dois!

---

6️⃣ Zowe Explorer – GUI no VSCode

O Zowe Explorer é uma extensão para VSCode, permitindo interações gráficas com z/OS.

Requisitos:

• VSCode instalado

• Perfis Zowe ou Zowe Team configurados (TCP/IP + credenciais)

Funcionalidades:

• Navegação visual de USS e PDS

• Execução de jobs TSO

• Extensibilidade via VSCode APIs ou Zowe Explorer APIs

Dica: extensões adicionais podem ser criadas para expandir o Zowe Explorer.

---

7️⃣ Suporte das versões Zowe

A política de suporte segue o modelo clássico Active / Maintenance / End-of-Support:

Versão	Status	Releases / Correções
V3.x.x	Active	Novas funcionalidades a cada 6 semanas + fixes críticos e de segurança
V2.x.x	Maintenance	Apenas fixes críticos e de segurança, sem novas funcionalidades
V1.x.x	End-of-Support	Nenhum fix, nenhuma atualização

Atenção a pegadinhas de prova IBM:

• Active = novas features + fixes

• Maintenance = apenas fixes críticos

• End-of-Support = nada

---

8️⃣ Conclusão

Zowe é a porta de entrada moderna para o mainframe, combinando:

• Zowe Server (z/OS ou container)

• Zowe CLI (Windows/Linux/macOS)

• Zowe SDKs (Python/Node.js)

• Zowe Explorer (GUI VSCode)

Se você quer dominar DevOps mainframe, integração z/OS e modernização de aplicações, Zowe é o seu aliado.

💡 Dica final Bellacosa Mainframe: memorize Server vs Client vs SDK vs Explorer, entenda instalação, perfis e suporte, e nunca confunda pip vs npm vs SMP/E. Isso salva em prova IBM e na vida real.

 

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.

 

Bellacosa Mainframe apresenta o Zowe 3.0

🔥 ZOWE: O Mainframe Falando a Língua do Mundo Moderno

Um guia definitivo para quem vive entre COBOL, APIs e DevOps

Se você ainda acha que mainframe é só tela verde, ISPF e 3270, chegou a hora de atualizar o firmware mental.
O nome disso é Zowe — e ele não veio para substituir o z/OS, mas para traduzir o mainframe para o século XXI.

Neste artigo, vamos direto ao ponto, sem marketing vazio, no melhor estilo Bellacosa Mainframe:
o que é Zowe, para que serve, onde brilha, onde NÃO entra e por que ele é essencial hoje.

---

Zowe 3.0

🧠 O que é o Zowe, afinal?

Zowe é um framework open source criado para permitir que aplicações modernas, desenvolvedores não-mainframe e ferramentas DevOps trabalhem com e sobre o z/OS.

Ele nasce para resolver um problema clássico:

“Como integrar o mainframe ao ecossistema web, cloud e DevOps sem quebrar tudo o que funciona há 40 anos?”

A resposta foi: abstração, APIs, CLI e Web — sem mexer no core.

---

🧩 Os 3 Pilares do Zowe

1️⃣ Zowe CLI – O mainframe na linha de comando

O Zowe Command Line Interface permite executar operações no z/OS a partir de:

• Windows

• Linux

• macOS

Usando shell local, scripts e pipelines.

Com ele você pode:

• Submeter batch jobs

• Emitir comandos TSO e z/OS

• Manipular datasets MVS e USS

• Automatizar tarefas em Jenkins, GitHub Actions, Bamboo etc.

⚠️ Importante (pegadinha de prova):
👉 Zowe CLI NÃO emula 3270
👉 Zowe CLI NÃO executa transações CICS interativas

CLI é comando, automação e integração — não tela verde.

---

2️⃣ Zowe Application Framework – Web no coração do z/OS

Aqui mora o Zowe Desktop, a interface web desktop-like, acessível via browser.

Ele oferece:

• Navegação e edição de datasets

• Visualização de jobs e spool

• Integração com TN3270

• Aplicações web plugáveis

E o mais importante:

• Suporte a Angular, React e IFrame

• Desenvolvimento em JavaScript, Java e tecnologias mainstream

• Ambiente amigável para devs que nunca ouviram falar de ISPF

📌 Zowe não substitui ISPF, CICS ou IMS
Ele complementa — e muito bem.

---

3️⃣ Zowe API Mediation Layer – O gateway do mainframe

O API Mediation Layer (API ML) é o tradutor oficial entre o z/OS e o mundo REST.

Ele fornece:

• Ponto único de acesso a múltiplos serviços REST

• Catálogo de APIs com Swagger/OpenAPI

• Segurança centralizada

• Roteamento e balanceamento de carga

⚠️ Atenção:

• Zowe não cria APIs automaticamente

• Zowe não melhora performance das APIs

Ele organiza, protege e expõe o que já existe.

---

🔐 Segurança: nada de gambiarra

Zowe usa a segurança nativa do z/OS:

• RACF

• ACF2

• Top Secret

Autenticação é feita com:

• User ID e password válidos

• Permissões reais do sistema

Nada de “security by JavaScript”.

---

🟢 Onde o Zowe BRILHA (e muito)

• Integração do mainframe com DevOps e CI/CD

• Abertura do z/OS para desenvolvedores não-mainframe

• Automação moderna sem mexer no core

• Criação de dashboards web com dados do z/OS

• Padronização e governança de APIs

• Open source de verdade, com comunidade ativa

---

🔴 Onde o Zowe NÃO entra

Vamos ser claros:

Zowe NÃO é:

• Emulador 3270

• Substituto do ISPF

• Substituto do z/OSMF

• Ferramenta de automação interna (WTOR, exits, SMF)

• Ambiente J2EE/WebSphere

• Solução mágica de performance

👉 Se envolve tela verde interativa, exits, automação interna, SDSF raiz
👉 não é Zowe

---

📊 Regra de ouro Bellacosa Mainframe

Web, API, CLI, DevOps, automação externa → ZOWE
3270, ISPF, CICS interativo, automação interna → NÃO ZOWE

Simples assim.

---

🚀 Por que o Zowe é estratégico hoje?

Porque ele resolve um problema real:

• O mainframe continua crítico

• O mercado exige integração, velocidade e automação

• Novos desenvolvedores não querem aprender ISPF antes de produzir

Zowe não mata o mainframe.
Ele garante que o mainframe continue vivo, integrado e relevante.

---

☕ Conclusão – estilo Bellacosa

Zowe não é moda.
Zowe é sobrevivência arquitetural.
Quem entende Zowe hoje, lidera a modernização amanhã — sem quebrar o legado que paga as contas.

Se você trabalha com IBM Z e ainda ignora o Zowe, o problema não é o mainframe.
É a sua estratégia.

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO: As 4 Estradas da Transformação Digital no IMS

 

Bellacosa Mainframe evoluindo em IMS 4 vias para crescer mais

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO!

As 4 Estradas da Transformação Digital no IMS: APIs, Java, SQL e DevOps na Visão da IBM

Quando alguém fala em transformação digital, normalmente surgem palavras como Cloud, Kubernetes, APIs, Microservices, DevOps, Inteligência Artificial e OpenShift.

Logo depois aparece alguém apontando para o mainframe e dizendo:

"Precisamos substituir tudo isso porque é legado."

E é exatamente nesse momento que começam alguns dos projetos mais caros, demorados e arriscados da história da TI corporativa.

O material da IBM "The 4 Paths to Digital Transformation in IMS", apresentado por Haley Fung, mostra uma visão radicalmente diferente. Em vez de substituir o IMS, a estratégia proposta é transformá-lo em um participante ativo do ecossistema digital moderno.

A mensagem principal do documento é simples:

O problema não é o IMS.

O problema é quando o IMS fica isolado.

Durante décadas, o IMS foi responsável por processar algumas das cargas mais críticas do planeta. Bancos, seguradoras, governos, operadoras de telecomunicações e empresas aéreas construíram seus negócios sobre ele.

E agora?

Agora a IBM mostra quatro caminhos principais para trazer o IMS para a era digital:

1. APIs

2. Java

3. Open Database (SQL/JDBC)

4. DevOps e Cloud

Vamos mergulhar profundamente em cada um deles.

---

O GRANDE MITO: MODERNIZAR NÃO É REESCREVER

Uma das maiores mentiras da indústria é:

Modernizar = Reescrever.

Não.

A IBM deixa claro que o objetivo é preservar o ativo mais valioso:

• Dados

• Regras de negócio

• Processos transacionais

• Disponibilidade

• Segurança

Tudo isso já existe dentro do IMS.

A pergunta correta não é:

Como substituir o IMS?

Mas sim:

Como conectar o IMS ao mundo moderno?

Essa diferença de mentalidade pode representar milhões de dólares economizados.

---

A PRIMEIRA ESTRADA: API-ENABLE EVERYTHING

Transformando transações IMS em APIs REST

Durante décadas, acessar uma transação IMS exigia:

• 3270

• MQ

• Sockets proprietários

• Middleware especializado

Para um desenvolvedor React, Angular ou Mobile isso parece arqueologia.

A solução apresentada pela IBM é simples:

Transformar ativos IMS em APIs REST.

---

z/OS Connect Enterprise Edition

O protagonista dessa transformação é:

IBM z/OS Connect EE

Ele permite expor:

• Transações IMS TM

• Dados IMS DB

• Aplicações COBOL

• Serviços z/OS

como APIs REST modernas.

---

O cenário tradicional

Imagine um banco.

Aplicação Mobile
↓
Middleware
↓
Gateway Proprietário
↓
MQ
↓
IMS

Múltiplas camadas.

Complexidade.

Custos.

---

O cenário moderno

Aplicação Mobile
↓
REST API
↓
z/OS Connect
↓
IMS

Muito mais simples.

Muito mais rápido.

Muito mais alinhado ao mercado.

---

O FIM DA DEPENDÊNCIA DE ESPECIALISTAS MAINFRAME

Uma observação extremamente interessante da IBM:

Não é necessário conhecimento profundo de mainframe para consumir APIs IMS.

Isso muda completamente a equação.

Um desenvolvedor Node.js pode consumir uma API IMS da mesma forma que consome:

• Salesforce

• SAP

• Oracle Cloud

• AWS

Sem saber o que é um PCB.

Sem saber o que é um GU.

Sem saber o que é um PSB.

---

IMS DE CENTRO DE CUSTO PARA CENTRO DE RECEITA

Essa é uma frase poderosa do material:

Converter IMS de Cost Center para Revenue Center.

Historicamente o IMS era visto como:

• Custo operacional

• Infraestrutura necessária

Com APIs ele passa a gerar novos negócios.

Exemplo:

Uma seguradora possui regras de cotação em IMS.

Em vez de reescrever tudo:

• expõe APIs

• integra parceiros

• cria novos canais digitais

O IMS continua executando a regra.

O mercado passa a consumi-la.

---

CASOS REAIS DE SUCESSO

O documento apresenta diversos exemplos.

Um deles reduziu um processo de abertura de contas de:

3 dias
para
menos de 1 segundo.

Resultado:

• 5.500 novas contas

• milhões em novos depósitos

• centenas de horas economizadas

Tudo sem substituir o IMS.

---

A SEGUNDA ESTRADA: JAVA NO IMS

Agora chegamos ao tema mais polêmico.

Quando alguém fala:

Java no Mainframe

sempre surge alguém dizendo:

Isso não faz sentido.

Mas a IBM vem investindo nisso há mais de 15 anos.

---

POR QUE JAVA?

Porque existe um problema real.

Encontrar:

• COBOL Developers

• IMS Specialists

• DL/I Experts

está cada vez mais difícil.

Enquanto isso existem milhões de desenvolvedores Java no mundo.

A IBM percebeu isso há muito tempo.

---

NÃO É COBOL VS JAVA

Esse é outro erro comum.

O documento não propõe eliminar COBOL.

Ele propõe:

COBOL + Java

Trabalhando juntos.

---

ESTRATÉGIA 1: EXTENDER APLICAÇÕES EXISTENTES

Imagine um programa COBOL IMS.

Você possui uma rotina extremamente pesada:

• validação

• criptografia

• cálculo complexo

A IBM sugere mover partes específicas para Java.

Benefícios:

• melhor manutenção

• maior disponibilidade de profissionais

• possibilidade de uso de frameworks modernos

---

ESTRATÉGIA 2: NOVAS APLICAÇÕES EM JAVA

Outra abordagem:

Criar novas aplicações IMS diretamente em Java.

O banco continua sendo IMS.

As transações continuam sendo IMS.

Mas a lógica é Java.

---

O SEGREDO CHAMADO zIIP

Aqui está uma das partes mais interessantes.

Java pode utilizar melhor os processadores especializados zIIP.

Para muitos ambientes isso significa:

• menor consumo de MIPS

• redução de custos

• melhor escalabilidade

---

O MITO DA PERFORMANCE

Existe outro preconceito:

Java é lento.

A IBM apresenta benchmark demonstrando mais de:

25.000 transações por segundo

em workload Java sobre IMS.

Isso desmonta completamente a narrativa de que Java no Z seria apenas experimental.

---

O MODELO HÍBRIDO MAIS INTELIGENTE

O que muitos clientes estão fazendo?

COBOL continua cuidando do núcleo.

Java assume:

• APIs

• integrações

• componentes modernos

• novas funcionalidades

Resultado:

Baixo risco.

Alta velocidade.

---

A TERCEIRA ESTRADA: OPEN DATABASE

Agora chegamos ao assunto que faz muitos DBAs arregalarem os olhos.

IMS e SQL.

Sim.

IMS e SQL.

---

O FIM DO "IMS É FECHADO"

Durante muitos anos ouvimos:

IMS é fechado.

A IBM respondeu criando a estratégia Open Database.

---

JDBC DIRETO NO IMS

O modelo apresentado permite:

Aplicação Java
↓
JDBC
↓
IMS

Sem extrações complexas.

Sem replicações desnecessárias.

Sem ETLs gigantescos.

---

POR QUE ISSO É REVOLUCIONÁRIO?

Porque tradicionalmente o fluxo era:

IMS
↓
ETL
↓
Data Warehouse
↓
Analytics

Horas depois.

Às vezes dias depois.

---

Novo modelo

IMS
↓
SQL
↓
Analytics

Quase em tempo real.

---

IMS COMO FONTE DE IA E ANALYTICS

O material mostra integração com:

• Apache Spark

• IBM Machine Learning for z/OS

• Db2 Analytics Accelerator

Tudo consumindo dados IMS.

Isso é enorme.

Porque o dado mais valioso da empresa geralmente está no IMS.

---

IMS CATALOG: A JOIA ESCONDIDA

Outro componente importante é o IMS Catalog.

Historicamente:

DBD
PSB
ACB

eram artefatos compreendidos por poucos especialistas.

O Catalog transforma isso em metadados mais acessíveis.

Resultado:

• melhor governança

• descoberta de dados

• integração simplificada

---

DDL NO IMS

Uma das maiores mudanças modernas.

Desde o IMS 14:

• CREATE DATABASE

• CREATE TABLE

• ALTER DATABASE

passaram a fazer parte do ecossistema IMS.

Para quem passou décadas vivendo apenas de:

• DBDGEN

• PSBGEN

• ACBGEN

isso representa uma mudança cultural gigantesca.

---

O QUE ISSO SIGNIFICA PARA O DBA?

Significa que o DBA IMS moderno precisa conhecer:

• Hierarquia

• SQL

• Metadata

• APIs

• Analytics

O perfil profissional está mudando.

---

A QUARTA ESTRADA: DEVOPS E CLOUD

Agora chegamos à transformação mais profunda.

---

O FIM DO DESENVOLVIMENTO MAINFRAME ISOLADO

Antigamente:

Desenvolvimento Distribuído
↓
Pipeline Moderno

e

Mainframe
↓
Mudanças manuais

Dois mundos separados.

---

A VISÃO DA IBM

Integrar o IMS ao pipeline corporativo.

Mesmas ferramentas.

Mesma metodologia.

Mesmo fluxo.

---

GIT NO MAINFRAME

O documento mostra integração com:

• Git

• Jenkins

• Maven

• Nexus

• Artifactory

e outros componentes DevOps.

Hoje isso já é realidade em muitos ambientes.

---

WAZI

Uma das iniciativas mais interessantes mostradas no material.

IBM Wazi oferece:

• VS Code

• Eclipse

• Red Hat CodeReady

• OpenShift

para desenvolvimento z/OS.

---

O impacto cultural

O novo desenvolvedor pode trabalhar em:

VS Code

e desenvolver para IMS.

Algo impensável vinte anos atrás.

---

ANSIBLE NO IMS

Essa talvez seja a parte que mais chama atenção de Sysprogs.

A IBM apresenta coleções específicas Ansible para:

• z/OS

• IMS

• automação operacional

---

IMS COMO INFRAESTRUTURA PROGRAMÁVEL

Imagine executar:

• geração de DBD

• geração de PSB

• geração de ACB

• comandos IMS

automaticamente.

O documento mostra exatamente isso através dos módulos:

• ims_dbd_gen

• ims_psb_gen

• ims_acb_gen

• ims_command

Para um Sysprog isso é quase ficção científica comparado ao modelo tradicional.

---

ZOWE: O NOVO ROSTO DO MAINFRAME

Outro destaque é o Zowe.

Ele fornece:

• REST APIs

• CLI

• Automação

para administrar IMS.

Exemplos:

• iniciar regiões

• parar regiões

• consultar transações

• automatizar deploys

Tudo através de scripts modernos.

---

O IMS ESTÁ VIRANDO CLOUD?

Na prática...

Sim.

Ou pelo menos absorvendo conceitos cloud.

---

z/OS CLOUD BROKER

O documento mostra o z/OS Cloud Broker integrado ao OpenShift.

Isso permite provisionar serviços como:

• IMS

• Db2

• CICS

• MQ

• z/OS Connect

de forma semelhante ao mundo cloud.

---

O QUE ISSO SIGNIFICA PARA O FUTURO DO IMS?

A conclusão mais importante do material é que a IBM não vê o IMS como tecnologia do passado.

Ela vê o IMS como:

• Plataforma transacional

• Fonte de dados

• Plataforma API

• Plataforma DevOps

• Plataforma híbrida

---

A GRANDE LIÇÃO PARA O PADAWAN MAINFRAME

Se você é:

• Desenvolvedor COBOL

• DBA IMS

• Sysprog

• Arquiteto

• Gestor

precisa entender uma coisa.

A guerra não é:

COBOL vs Java

Mainframe vs Cloud

IMS vs Microservices

A verdadeira batalha é:

Sistema Isolado vs Sistema Conectado.

O documento da IBM demonstra que o IMS moderno pode participar de:

✅ APIs REST

✅ OpenAPI

✅ Swagger

✅ Java

✅ JDBC

✅ SQL

✅ Analytics

✅ Machine Learning

✅ Git

✅ Jenkins

✅ OpenShift

✅ Ansible

✅ Zowe

✅ DevOps

✅ Hybrid Cloud

sem abandonar décadas de investimento corporativo.

E talvez essa seja a maior lição de todas:

O futuro não pertence aos sistemas novos.

Pertence aos sistemas que conseguem evoluir.

E poucos sistemas na história da computação provaram tantas vezes sua capacidade de evolução quanto o IMS. ☕💣🚀

Fonte analisada: The 4 Paths to Digital Transformation in IMS, Haley Fung, IBM IMS.

 

Bellacosa Mainframe apresenta o Open Mainframe Project

O que é Open Mainframe Project?

O Open Mainframe Project (OMP) é uma iniciativa global criada para apoiar o desenvolvimento, a modernização e a adoção de tecnologias abertas no ecossistema Mainframe.

O projeto foi lançado em 2015 e é hospedado pela Linux Foundation, reunindo empresas, universidades, desenvolvedores e especialistas Mainframe de todo o mundo.

---

Definição Simples

O Open Mainframe Project é uma comunidade colaborativa que busca:

✅ Atrair novos profissionais para Mainframe

✅ Incentivar projetos Open Source

✅ Modernizar aplicações legadas

✅ Promover educação e treinamento

✅ Integrar Mainframe com tecnologias modernas

---

Por que o Projeto Foi Criado?

Durante muitos anos o Mainframe foi visto como um ambiente fechado.

Ao mesmo tempo:

Cloud
DevOps
Git
Linux
Open Source
Containers
APIs

ganhavam popularidade.

O Open Mainframe Project surgiu para aproximar o Mainframe desse universo moderno.

---

Objetivos Principais

Educação

Capacitar novas gerações de profissionais.

---

Comunidade

Criar um ecossistema colaborativo.

---

Open Source

Estimular projetos abertos para IBM Z.

---

Modernização

Conectar Mainframe às tecnologias atuais.

---

Quem Participa?

Diversas empresas fazem parte da iniciativa.

Entre elas:

• IBM

• Broadcom

• Rocket Software

• Vicom Infinity

• BMC

• SUSE

• Phoenix Software

• Universidades e instituições acadêmicas

---

Estrutura do Projeto

Open Mainframe Project
           │
           ├── Educação
           ├── Open Source
           ├── Eventos
           ├── Mentoria
           └── Comunidade

---

Projetos Importantes

Zowe

Um dos projetos mais famosos do Open Mainframe Project.

O que é?

Framework Open Source para Mainframe.

Permite:

• CLI moderna

• APIs REST

• Interface Web

• Integração DevOps

---

Arquitetura

Desenvolvedor
      ↓
Zowe CLI
      ↓
z/OS
      ↓
CICS
DB2
Datasets
JES

---

Zowe CLI

Exemplo:

zowe jobs list jobs

Consulta Jobs do z/OS usando linha de comando moderna.

---

Mentorship Program

Programa internacional de mentoria.

Conecta:

Estudantes
     ↓
Mentores
     ↓
Projetos Reais

---

Mainframe Open Education

Iniciativas educacionais para:

• COBOL

• JCL

• RACF

• CICS

• DB2

• LinuxONE

• DevOps

---

Ambientes Gratuitos

O projeto disponibiliza acesso a recursos de aprendizado.

Incluindo:

• Laboratórios

• Cursos

• Documentação

• Trilhas de certificação

---

Eventos

O Open Mainframe Project participa de:

• SHARE

• GSE

• Open Source Summit

• IBM TechXchange

---

Mainframe e Open Source

O projeto ajuda a integrar:

Git
GitHub
Python
Java
Node.js
Linux
Ansible
Docker
Kubernetes

com o ambiente Mainframe.

---

DevOps no Mainframe

Promove ferramentas modernas como:

• Git

• Jenkins

• GitLab

• Ansible

• Zowe

---

Exemplo

GitHub
   ↓
Pipeline CI/CD
   ↓
Teste COBOL
   ↓
Deploy z/OS

---

LinuxONE e Open Mainframe

O projeto também incentiva o uso de:

LinuxONE
Red Hat
Ubuntu
SUSE
OpenShift

executando sobre hardware IBM Z.

---

Programa de Embaixadores

O Open Mainframe Project possui uma rede global de:

Ambassadors

que promovem:

• palestras;

• workshops;

• treinamentos;

• eventos técnicos.

---

Benefícios para Estudantes

✅ Conteúdo gratuito

✅ Mentorias internacionais

✅ Contato com especialistas

✅ Projetos Open Source

✅ Networking global

---

Benefícios para Empresas

✅ Formação de talentos

✅ Modernização tecnológica

✅ Integração Open Source

✅ Aumento da comunidade Mainframe

---

Curiosidades

1. O projeto é mantido pela Linux Foundation

2. Possui participantes de dezenas de países

3. O Zowe nasceu dentro do Open Mainframe Project

4. Milhares de estudantes participam de programas educacionais todos os anos

5. É uma das maiores iniciativas globais de promoção da plataforma Mainframe

---

Recursos Oficiais

Site Oficial

Open Mainframe Project

Projeto Zowe

Zowe

Linux Foundation

Linux Foundation

---

Resumo Rápido

Conceito	Função
Open Mainframe Project	Comunidade global Mainframe
Linux Foundation	Organização mantenedora
Zowe	Framework Open Source
Mentorship	Programa de mentoria
Educação	Formação de profissionais
DevOps	Modernização Mainframe
Open Source	Projetos colaborativos
LinuxONE	Integração Linux e IBM Z

---

Conclusão

O Open Mainframe Project é uma iniciativa global da Linux Foundation dedicada a fortalecer o ecossistema Mainframe através de educação, colaboração, inovação e projetos Open Source. Seu objetivo é conectar a robustez do IBM Z às tecnologias modernas, formando novos profissionais e garantindo que o Mainframe continue evoluindo como uma das plataformas mais importantes do mundo corporativo.