Translate

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

sexta-feira, 31 de julho de 2026

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

 

Bellacosa Mainframe do Html ao IBM Z uma jornada classica do Heroi

☕ Um Café no Bellacosa Mainframe

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

"Durante muitos anos acreditamos que existiam dois mundos completamente diferentes. De um lado, o navegador. Do outro, o mainframe. Hoje sabemos que eles nunca estiveram tão próximos."


Existe uma cena curiosa que provavelmente todo programador COBOL já viveu.

Você está trabalhando em um programa CICS há horas. Ajusta um COMMAREA, altera uma consulta DB2, recompila, faz o BIND, libera para homologação e, de repente, alguém da equipe Web aparece com uma pergunta aparentemente inocente:

"Você consegue disponibilizar isso numa API REST?"

Há alguns anos essa pergunta soaria quase como magia.

Hoje ela faz parte do cotidiano.

Foi justamente para reduzir essa distância que nasceu o APPDEV 33 – Introduction to Web Development – Part 2, expandindo os conceitos apresentados na Parte 1 e mostrando que HTML, CSS e JavaScript não competem com COBOL. Eles trabalham juntos.

Na verdade...

Eles dependem um do outro.



A grande mudança silenciosa

Existe uma falsa impressão de que o desenvolvimento Web pertence apenas ao universo JavaScript.

Não pertence.

Da mesma forma que existe a falsa impressão de que o Mainframe termina na tela verde.

Também não termina.

O navegador moderno tornou-se apenas mais um terminal.

Só que muito mais bonito.

Muito mais amigável.

Muito mais inteligente.

E atrás dele continua existindo aquilo que sempre sustentou bancos, seguradoras, governos, companhias aéreas e bolsas de valores:

IBM Z.


O que aprendemos na Parte 1

Na primeira parte aprendemos três pilares fundamentais.

HTML

A estrutura.

Assim como uma BMS MAP define onde cada campo aparecerá na tela 3270, o HTML define onde cada elemento será exibido dentro da página.

É o esqueleto.


CSS

A aparência.

Se na BMS alterávamos atributos como intensidade, cor, proteção e brilho, no navegador fazemos praticamente a mesma coisa utilizando CSS.

Mudam os nomes.

O conceito continua.


JavaScript

O comportamento.

Enquanto COBOL executa regras de negócio no servidor, JavaScript controla a experiência do usuário no navegador.

Ele responde cliques.

Atualiza informações.

Valida formulários.

Move elementos.

Sem precisar recarregar toda a página.


A analogia perfeita

Mundo WebMundo Mainframe
HTMLBMS MAP
CSSAtributos da Tela
JavaScriptInterface
COBOLRegras de Negócio

Quando essa tabela aparece pela primeira vez, muita gente faz exatamente a mesma expressão:

"Ahhh... agora fez sentido."



O navegador é apenas o começo

Quando digitamos:

https://empresa.com

Nossa mente costuma imaginar algo simples.

Mas, nos bastidores, ocorre uma verdadeira corrida de revezamento.

Usuário

↓

Browser

↓

Servidor Web

↓

HTML

↓

CSS

↓

JavaScript

↓

Página pronta

↓

REST API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

Observe algo interessante.

O navegador praticamente nunca conversa diretamente com o COBOL.

Existe uma camada intermediária.

E isso é excelente.


O guardião entre dois mundos

No ecossistema IBM Z moderno existe um verdadeiro tradutor universal.

z/OS Connect.

Ele recebe chamadas REST.

Converte JSON.

Invoca programas COBOL.

Executa CICS.

Consulta DB2.

Retorna novamente JSON.

Tudo isso escondendo completamente a complexidade do ambiente z/OS.

É quase como um intérprete simultâneo durante uma conferência internacional.

Cada lado continua falando sua própria língua.

Mas todos passam a se entender.


HTML deixou de ser apenas marcação

Quem aprendeu HTML há quinze anos provavelmente conheceu algo parecido com isto.

<div>
<div>
<div>

Funcionava.

Mas era praticamente impossível descobrir o significado daquela estrutura.

Então surgiu o HTML Semântico.

Agora passamos a utilizar elementos como:

<header>

<nav>

<main>

<section>

<article>

<footer>

Essas palavras possuem significado.

E significado muda tudo.

Motores de busca entendem melhor o conteúdo.

Leitores de tela conseguem navegar corretamente.

Ferramentas de Inteligência Artificial interpretam o contexto.

Até os próximos programadores agradecem.

Porque finalmente conseguem entender a organização da página.


CSS cresceu

Durante muito tempo criar layouts era uma atividade quase artesanal.

Tabelas.

Float.

Clear.

Margens.

Gambiarras.

Então surgiu o Flexbox.

De repente bastava escrever poucas linhas.

display:flex;

justify-content:space-between;

align-items:center;

Como mágica.

Tudo se alinhava.

Responsivamente.

Sem sofrimento.

Depois veio o CSS Grid.

E aí o navegador finalmente ganhou um verdadeiro sistema de layout bidimensional.

Header.

Menu.

Conteúdo.

Rodapé.

Tudo organizado como uma planta arquitetônica.

Curiosamente...

É exatamente assim que pensamos quando desenhamos uma aplicação CICS.

Primeiro definimos a arquitetura.

Depois os componentes.

Depois o fluxo.


JavaScript finalmente ganhou vida

No início JavaScript apenas executava comandos.

Hoje ele reage.

Clique.

Teclado.

Mouse.

Touch.

Formulário.

Mudança de valor.

Tudo é evento.

Usuário

↓

Evento

↓

JavaScript

↓

Resposta

Essa simplicidade mudou completamente a experiência da Web.

Não precisamos mais atualizar páginas inteiras.

Alteramos apenas aquilo que realmente mudou.

Essa ideia parece moderna.

Mas, curiosamente, programadores CICS fazem algo parecido há décadas.

Atualizamos apenas determinados campos da tela.

Não a aplicação inteira.



DOM — A página deixa de ser estática

Imagine que exista uma árvore invisível.

Cada botão.

Cada texto.

Cada imagem.

Cada tabela.

Cada formulário.

Tudo faz parte dessa árvore.

Ela recebe um nome.

DOM — Document Object Model.

JavaScript pode caminhar por essa árvore.

Encontrar um elemento.

Alterar seu conteúdo.

Modificar sua aparência.

Inserir novos componentes.

Tudo instantaneamente.

Sem recarregar o navegador.

É isso que transforma páginas estáticas em aplicações.

Parte II : Quando o Navegador Conversa com o Mainframe

Na primeira parte da nossa conversa percebemos algo importante: HTML, CSS e JavaScript não substituem o COBOL. Eles apenas ocupam uma camada diferente da aplicação.

Agora vem a pergunta que todo programador COBOL faz quando termina de aprender os conceitos básicos.

"Tudo bem... mas como exatamente um clique no navegador consegue executar um programa COBOL dentro do IBM Z?"

É justamente aqui que começa a mágica.

Ou melhor...

A engenharia.



A viagem de um clique

Imagine que um cliente acessa o Internet Banking.

Ele vê um botão.

Consultar Saldo

Aparentemente ele apenas clicou.

Mas esse clique inicia uma longa viagem.

Clique

↓

JavaScript

↓

REST API

↓

JSON

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

DB2

↓

Resposta

↓

JSON

↓

JavaScript

↓

Atualização da Tela

Em menos de um segundo tudo isso aconteceu.

Sem o usuário perceber.

Se o sistema estiver rodando em IBM Z, provavelmente essa operação ocorreu em alguns poucos milissegundos.



REST API — A língua franca da Internet

Há vinte anos cada sistema possuía seu próprio protocolo.

Cada fabricante inventava uma maneira diferente de trocar informações.

Era um verdadeiro caos.

REST mudou completamente esse cenário.

Hoje praticamente qualquer sistema consegue conversar com qualquer outro utilizando HTTP.

Isso significa que um navegador, um aplicativo Android, um iPhone, uma Smart TV ou até uma geladeira inteligente podem acessar exatamente a mesma API.

O IBM Z simplesmente tornou-se mais um participante dessa conversa.



JSON — O envelope que viaja pela Internet

Quando um navegador solicita informações, ele normalmente envia algo parecido com isto.

{
   "cliente":12345
}

Poucos milissegundos depois recebe algo semelhante.

{
   "nome":"Maria",
   "saldo":1250.90,
   "limite":5000
}

Isso é JSON.

Leve.

Organizado.

Fácil de interpretar.

Mas existe uma curiosidade.

O JSON praticamente nunca nasce no navegador.

Na maioria das aplicações corporativas ele foi produzido por um programa COBOL.

Ou seja...

Por trás daquele pequeno documento existe toda uma lógica construída durante décadas.



z/OS Connect — O tradutor universal

Imagine um diplomata durante uma reunião internacional.

Um participante fala japonês.

Outro fala português.

Outro inglês.

Outro espanhol.

Todos conseguem conversar porque existe um intérprete.

z/OS Connect faz exatamente esse papel.

Ele entende REST.

Entende HTTP.

Entende JSON.

Depois traduz tudo para o universo do IBM Z.

Do outro lado...

O programa COBOL continua exatamente igual.

Sem precisar conhecer HTML.

Sem conhecer JavaScript.

Sem conhecer navegador.

Ele apenas recebe parâmetros.

Processa.

Responde.

E volta ao trabalho.



CICS continua fazendo o que sempre fez

Muita gente acredita que REST substituiu CICS.

Na verdade aconteceu justamente o contrário.

REST fez ainda mais aplicações dependerem do CICS.

O fluxo normalmente é este.

Browser

↓

REST API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

Observe que o CICS continua sendo o gerente das transações.

Ele controla segurança.

Sincronismo.

Rollback.

Commit.

Performance.

Disponibilidade.

Nada mudou.

Apenas surgiram novos clientes.

Antes eram terminais 3270.

Hoje são navegadores.



COBOL continua sendo o cérebro

Existe uma frase que gosto muito.

JavaScript encanta. COBOL decide.

É JavaScript quem anima a tela.

É JavaScript quem valida um campo.

É JavaScript quem muda uma cor.

Mas quem realmente decide se um empréstimo será aprovado?

Quem calcula juros?

Quem verifica limite de crédito?

Quem consulta regras fiscais?

Quem processa milhões de transações diariamente?

COBOL.

Sempre ele.

O navegador apenas apresenta o resultado.



DB2 continua guardando o tesouro

Toda aplicação precisa armazenar informações.

Clientes.

Contas.

Contratos.

Apólices.

Empréstimos.

Pedidos.

Cartões.

É aqui que entra o DB2.

O programa COBOL faz consultas.

Atualiza registros.

Executa commits.

Controla integridade.

Depois transforma essas informações em JSON.

E o navegador recebe tudo pronto.

Perceba algo interessante.

O navegador nunca conversa diretamente com o banco.

Isso seria extremamente perigoso.

Existe sempre uma camada intermediária protegendo os dados.



Organização faz diferença

Quando começamos nossos primeiros programas HTML normalmente criamos apenas um arquivo.

index.html

Pouco tempo depois aparecem outros.

style.css

app.js

logo.png

Mais tarde surgem dezenas.

Depois centenas.

É exatamente nesse momento que aprendemos a organizar projetos.

Projeto

│

├── index.html

├── css

├── js

├── images

├── api

Essa organização pode parecer apenas estética.

Não é.

Ela facilita manutenção.

Facilita testes.

Facilita integração contínua.

Facilita Git.

Facilita DevOps.

Curiosamente...

É exatamente o mesmo motivo pelo qual existem COPYBOOKS.



COPYBOOKS nasceram muito antes dos Frameworks

Muitos desenvolvedores Web acreditam que reutilização nasceu com Frameworks modernos.

Na verdade...

Programadores COBOL fazem isso desde os anos 60.

Sempre que escrevemos

COPY CLIENTE.

Estamos reutilizando componentes.

Assim como um projeto Web reutiliza:

componentes

bibliotecas

frameworks

módulos

Mudam os nomes.

O princípio continua exatamente igual.


Git mudou a forma de trabalhar

Durante décadas o controle de versões no Mainframe foi responsabilidade de ferramentas como:

  • Endevor

  • ISPW

  • Librarian

  • Panvalet

Hoje Git tornou-se praticamente obrigatório.

Não importa se o código está em Java.

Python.

COBOL.

REXX.

Assembler.

Todos podem viver no mesmo repositório.

E isso abriu uma porta enorme para DevOps.



DevOps aproximou dois mundos

Antigamente existia uma divisão muito clara.

O desenvolvedor escrevia código.

Outra equipe compilava.

Outra homologava.

Outra implantava.

Hoje pipelines fazem praticamente tudo isso automaticamente.

Commit

↓

Build

↓

Testes

↓

Análise

↓

Deploy

Essa automação não substitui o programador.

Ela elimina tarefas repetitivas.

E permite que ele invista tempo onde realmente faz diferença.

Criando soluções.

Não apertando botões.



O novo profissional IBM Z

Chegamos então ao ponto mais importante de toda esta formação.

O profissional IBM Z moderno não conhece apenas COBOL.

Ele entende a jornada completa.

COBOL

↓

JSON

↓

REST

↓

HTML

↓

CSS

↓

JavaScript

↓

Git

↓

DevOps

↓

Cloud

↓

IBM Z

Isso não significa abandonar o Mainframe.

Significa ampliar horizontes.

Quanto mais camadas você compreende, maior passa a ser seu valor dentro da organização.

Você deixa de ser apenas um programador COBOL.

Passa a ser alguém capaz de conversar com equipes Web, arquitetos de soluções, especialistas em APIs, profissionais DevOps e engenheiros de Cloud.

E isso muda completamente sua carreira.



☕ Um café antes de continuar...

Existe um detalhe curioso que costuma passar despercebido.

Durante décadas ouvimos que "o futuro substituiria o Mainframe".

Mas aconteceu exatamente o contrário.

Foi o Mainframe que aprendeu a conversar com o futuro.

Hoje ele fala REST, entende JSON, integra-se com Cloud, participa de pipelines DevOps, conversa com aplicações móveis e continua executando, silenciosamente, bilhões de transações por dia.

Talvez essa seja a maior lição desta formação.

O IBM Z nunca ficou parado. Nós é que demoramos para perceber o quanto ele evoluiu.

Parte III — O Desenvolvedor IBM Z Moderno e o Futuro que Já Chegou

"O melhor momento para aprender HTML foi quando surgiu. O segundo melhor momento é hoje. Porque o IBM Z já está esperando por você."

Depois de percorrer toda a jornada desta formação, uma pergunta inevitavelmente aparece.

"O que devo aprender agora?"

Essa talvez seja a maior ansiedade de quem vem do mundo COBOL.

São tantas tecnologias...

HTML.

CSS.

JavaScript.

Git.

REST.

JSON.

Cloud.

DevOps.

Containers.

Docker.

Kubernetes.

OpenShift.

Inteligência Artificial.

À primeira vista parece impossível.

Mas existe uma boa notícia.

Você não precisa aprender tudo de uma vez.

Muito menos abandonar o conhecimento acumulado durante anos.

Na verdade, você já possui aquilo que a maioria dos desenvolvedores modernos ainda está tentando adquirir.

Conhecimento de negócio.

E isso vale ouro.


A árvore do conhecimento

Durante a apresentação utilizamos uma imagem bastante simbólica.

Uma árvore.

À primeira vista ela parece apenas um desenho bonito.

Mas existe um significado escondido.

As raízes

São invisíveis.

Pouca gente presta atenção nelas.

Mas sustentam tudo.

No IBM Z elas representam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • RACF

  • TSO/ISPF

Curiosamente...

São justamente as tecnologias que mais movimentam dinheiro no planeta.

Ninguém faz propaganda delas.

Mas bilhões de transações acontecem todos os dias graças a elas.


O tronco

O tronco representa aquilo que conecta todas as áreas.

Na nossa metáfora...

É o próprio IBM z17.

Não apenas como computador.

Mas como plataforma.

Segura.

Disponível.

Escalável.

Resiliente.

Enquanto centenas de tecnologias aparecem e desaparecem ao longo das décadas...

O IBM Z continua crescendo.


Os galhos

É onde surgem as novidades.

HTML.

CSS.

JavaScript.

REST.

JSON.

Git.

Cloud.

DevOps.

IA.

Todos eles crescem apoiados nas raízes.

Sem elas...

A árvore não existe.


O roadmap de evolução

Ao longo da apresentação surgiu uma estrada colorida.

Ela representa algo muito importante.

Você não aprende tudo ao mesmo tempo.

Você sobe um degrau por vez.

Primeiro passo

HTML.

Aprenda estrutura.

Nada além disso.

Não tente decorar centenas de elementos.

Entenda a lógica.


Segundo passo

CSS.

Faça páginas bonitas.

Aprenda cores.

Espaçamento.

Layouts.

Responsividade.

Não é preciso virar designer.

Apenas tornar a informação agradável.


Terceiro passo

JavaScript.

Agora a página ganha vida.

Botões passam a funcionar.

Campos são validados.

Elementos aparecem.

Desaparecem.

Mudam dinamicamente.

É nesse momento que muitos programadores COBOL começam a sorrir.

Porque finalmente enxergam lógica de programação novamente.


Quarto passo

REST.

Agora você entende que aplicações conversam.

E que praticamente toda integração moderna utiliza APIs.


Quinto passo

JSON.

Descobre que arquivos gigantes de integração deram lugar a pequenos documentos extremamente simples.


Sexto passo

Git.

Talvez seja a ferramenta que mais muda a maneira de trabalhar.

Commits.

Branches.

Merge.

Pull Request.

Code Review.

Tudo passa a fazer parte da rotina.


Sétimo passo

DevOps.

Agora o código não vive mais sozinho.

Ele entra em pipelines.

Executa testes.

É compilado automaticamente.

Implantado.

Monitorado.

Tudo praticamente sem intervenção humana.


Oitavo passo

Cloud.

Você percebe que Cloud não substituiu o Mainframe.

Ela apenas adicionou mais um ambiente de execução.

Na prática...

Os dois trabalham juntos.


Nono passo

Inteligência Artificial.

Chegamos ao presente.

Mas cuidado.

Existe um enorme equívoco acontecendo.

A IA não substitui conhecimento.

Ela acelera conhecimento.

Quanto mais experiência possui o profissional...

Melhores perguntas ele faz.

Melhores respostas recebe.


Um pequeno segredo da IBM

Existe uma curiosidade interessante.

Durante muitos anos, aprender IBM significava decorar comandos.

Hoje não.

A IBM mudou completamente sua estratégia.

Ela deseja profissionais capazes de integrar tecnologias.

É exatamente por isso que vemos cada vez mais cursos envolvendo:

  • Git

  • APIs

  • HTML

  • JavaScript

  • OpenShift

  • Red Hat

  • Linux

  • Python

  • DevOps

  • IA

Tudo convivendo naturalmente com COBOL.


Easter Egg nº 1 — O retorno da BMS

Você provavelmente achou curioso estudar HTML.

Mas observe.

Uma página HTML possui:

Header.

Body.

Campos.

Botões.

Mensagens.

Formulários.

Menus.

Parece familiar?

Porque é.

BMS fazia exatamente isso.

A diferença é que hoje existem milhões de cores.

Animações.

Responsividade.

E um mouse.

No restante...

Os conceitos continuam incrivelmente parecidos.


Easter Egg nº 2 — O navegador virou um terminal 3270

Calma...

Antes de fechar a página dizendo que enlouqueci...

Pense comigo.

O navegador:

Recebe dados.

Envia comandos.

Mostra telas.

Executa transações.

Atualiza informações.

Consulta banco.

Exatamente como um terminal.

A diferença é que o navegador ganhou superpoderes.

Renderiza vídeos.

Executa JavaScript.

Faz chamadas REST.

Mostra gráficos.

Integra mapas.

Mas continua sendo uma interface.

Assim como o 3270 sempre foi.


Easter Egg nº 3 — HTML não substitui COBOL

Esse talvez seja o maior medo de muitos iniciantes.

"Vou precisar abandonar COBOL?"

Não.

Pelo contrário.

Quanto maior a adoção de APIs...

Mais programas COBOL acabam sendo reutilizados.

Muitos sistemas escritos há quarenta anos hoje atendem aplicações Web modernas.

Mudou apenas a porta de entrada.


O maior erro dos iniciantes

Depois de ministrar diversos treinamentos, comecei a perceber um padrão.

O erro raramente é técnico.

É psicológico.

O aluno olha para a quantidade de tecnologias e conclui:

"Jamais vou aprender tudo isso."

Mas ninguém aprende.

Nem mesmo quem trabalha há trinta anos.

Todos continuam estudando.

Inclusive os IBM Fellows.

Inclusive os Distinguished Engineers.

Inclusive quem desenvolveu boa parte dessas tecnologias.

Aprender nunca termina.


O conselho que gostaria de ter ouvido em 1988

Quando comecei minha carreira, imaginava que bastava aprender COBOL.

Depois vieram CICS.

DB2.

JCL.

VSAM.

REXX.

Assembler.

TCP/IP.

MQ.

Java.

Web Services.

XML.

JSON.

REST.

Git.

Cloud.

DevOps.

IA.

No início achei que era um problema.

Hoje percebo que foi um privilégio.

Poucas profissões permitem acompanhar tantas revoluções tecnológicas sem abandonar completamente aquilo que aprendemos décadas atrás.

O programador COBOL continua reconhecendo um IF.

Um PERFORM.

Um MOVE.

Da mesma forma que reconhece hoje um IF em JavaScript.

A lógica continua sendo a mesma.

Mudam apenas as ferramentas.


O verdadeiro objetivo desta formação

Se ao terminar estas aulas você decorar todos os comandos HTML...

O curso terá sido apenas razoável.

Se aprender Flexbox.

Grid.

DOM.

Eventos.

REST.

JSON.

Também será um bom resultado.

Mas existe um objetivo muito maior.

Perder o medo da palavra "Web".

Porque ela deixou de ser um território distante.

Hoje faz parte do ecossistema IBM Z.


Uma última xícara de café...

Quando observo um IBM z17 processando milhares de transações por segundo enquanto um navegador moderno exibe gráficos, animações e respostas instantâneas, lembro-me de como essa história começou.

Lá atrás, um simples terminal verde.

Depois uma tela BMS.

Mais tarde o TCP/IP.

Vieram XML e Web Services.

Depois JSON.

REST.

Cloud.

Git.

DevOps.

Agora Inteligência Artificial.

O curioso é que, em todas essas fases, alguém decretou que o Mainframe estava ficando para trás.

E, em todas elas, o IBM Z respondeu da melhor maneira possível.

Evoluindo.

Sem perder sua essência.

Sem abandonar sua confiabilidade.

Sem deixar de ser o coração silencioso das maiores empresas do planeta.

Talvez essa seja a maior lição desta jornada.

As tecnologias mudam.

As interfaces evoluem.

As linguagens ganham novos recursos.

Mas a lógica, a arquitetura bem construída e a capacidade de resolver problemas reais continuam sendo o verdadeiro diferencial de um grande profissional.

No fim das contas, HTML, CSS, JavaScript, REST, JSON, Git, DevOps e Inteligência Artificial não são o destino.

São apenas novas ferramentas nas mãos de quem já aprendeu, há muito tempo, que um bom programa começa antes mesmo da primeira linha de código.

E enquanto houver desafios para resolver, clientes para atender e sistemas críticos para manter funcionando, sempre haverá espaço para quem estiver disposto a aprender.

Então abasteça a caneca, abra o editor de código e continue estudando.

Porque a próxima grande evolução do IBM Z provavelmente já começou.

E, quem sabe, ela será escrita por você.

Do conceito à prática: os laboratórios da Formação APPDEV

Teoria sem prática é como um programa COBOL que nunca saiu do editor: pode estar elegante, bem comentado e perfeitamente identado, mas ainda não processou uma única transação.

Por isso, a Formação APPDEV não termina quando o último slide desaparece da tela.

Ela continua nos laboratórios.

É nesses ambientes que HTML deixa de ser apenas uma sequência de tags, CSS deixa de ser decoração, JavaScript deixa de ser uma promessa e a integração com o ecossistema IBM Z começa a ganhar forma diante dos nossos olhos.

Prepare a caneca.

Abra o navegador.

E vamos colocar a mão na massa.


IBM Web Development Labs

O primeiro ponto de partida é o laboratório de desenvolvimento Web utilizado durante a formação:

IBM Web Development Labs
https://vagnerbellacosa.github.io/Lab_WebdevelopmentCoursera/

Nesse ambiente, o aluno pode revisar os fundamentos de HTML, CSS e JavaScript, observar a organização de uma aplicação Web e experimentar a construção de páginas diretamente no navegador.

É o lugar ideal para praticar:

  • estruturação de páginas com HTML;

  • aplicação de estilos com CSS;

  • criação de comportamentos com JavaScript;

  • eventos de clique e formulário;

  • manipulação do DOM;

  • organização de componentes;

  • preparação para consumo de APIs.

O objetivo não é apenas copiar códigos.

É alterar.

Quebrar.

Testar.

Corrigir.

Executar novamente.

Programação continua sendo uma ciência experimental, mesmo quando o laboratório cabe dentro de uma aba do navegador.

O endereço desse laboratório aparece diretamente na apresentação APPDEV como recurso para continuidade dos estudos.


LAB IBM IPL Mainframe

Depois de compreender o funcionamento da camada Web, vale retornar ao coração da infraestrutura:

LAB IBM IPL Mainframe
https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

IPL significa Initial Program Load.

É, de maneira simplificada, o processo de inicialização de um sistema IBM Z. Entretanto, compará-lo apenas ao boot de um computador pessoal seria uma simplificação quase ofensiva.

Em um ambiente corporativo, um IPL envolve planejamento, volumes, parâmetros, dispositivos, subsistemas, segurança, disponibilidade e uma sequência cuidadosamente controlada de operações.

O laboratório ajuda o estudante a enxergar o IBM Z não apenas como uma máquina que executa COBOL, mas como uma plataforma completa, composta por diversas camadas trabalhando em conjunto.

Essa visão é fundamental para o Desenvolvedor IBM Z Moderno.

Mesmo que ele não execute um IPL em produção, precisa compreender o ambiente no qual seus programas vivem.

A apresentação disponibiliza esse laboratório como uma etapa complementar da jornada.


Lab IBM Storage Management

Todo programa precisa de dados.

E todo dado precisa morar em algum lugar.

Lab IBM Storage Management
https://vagnerbellacosa.github.io/Lab_IBM_StorageManagement/

Nesse laboratório, o aluno pode ampliar a compreensão sobre armazenamento no ecossistema IBM Z.

Isso inclui conceitos relacionados a:

  • datasets;

  • volumes;

  • DASD;

  • organização de arquivos;

  • gerenciamento de espaço;

  • políticas de armazenamento;

  • disponibilidade;

  • proteção de dados;

  • relacionamento entre aplicação e infraestrutura.

No mundo Web, falamos em arquivos, pastas, objetos, buckets e bancos de dados.

No IBM Z, encontramos datasets sequenciais, PDS, PDSE, VSAM, catálogos, volumes e políticas SMS.

Novamente, mudam as ferramentas e os nomes.

A necessidade permanece a mesma:

guardar a informação correta, no lugar correto, com segurança e disponibilidade.

O link para o laboratório de Storage Management também faz parte dos materiais de continuidade presentes na apresentação.


LAB IBM Capacity

Uma aplicação pode funcionar perfeitamente para dez usuários e entrar em colapso quando o décimo primeiro aparece.

É nesse momento que descobrimos que desenvolver software não significa apenas produzir resultados corretos.

Também significa produzir resultados dentro do tempo esperado.

LAB IBM Capacity
https://vagnerbellacosa.github.io/LAB_IBM_Capacity/

O laboratório de capacidade introduz uma visão essencial para aplicações corporativas:

  • utilização de CPU;

  • consumo de memória;

  • carga de trabalho;

  • crescimento de demanda;

  • gargalos;

  • throughput;

  • tempo de resposta;

  • planejamento de recursos;

  • comportamento do ambiente em períodos de pico.

Imagine uma aplicação Web consultando uma API REST que chama z/OS Connect, entra no CICS, executa COBOL e consulta DB2.

Cada camada consome recursos.

Cada camada pode introduzir espera.

Cada componente precisa ser observado.

O usuário não está preocupado com o número de instruções executadas.

Ele apenas sabe que clicou no botão e está esperando.

Por isso, capacidade e desempenho também fazem parte da experiência do usuário.

O laboratório de Capacity aparece na apresentação como parte da trilha prática recomendada.


Lab War Room Mainframe

Alguns problemas não chegam educadamente durante o horário comercial.

Eles aparecem de madrugada.

No fechamento mensal.

Durante uma grande campanha.

Ou exatamente quando todos acreditavam que a mudança estava sob controle.

Lab War Room Mainframe
https://vagnerbellacosa.github.io/LAB_WarRoom_Mainframe/

O conceito de War Room representa a investigação coordenada de incidentes.

É o lugar — físico ou virtual — onde profissionais de diferentes áreas analisam juntos:

  • sintomas;

  • logs;

  • mensagens;

  • falhas;

  • tempos de resposta;

  • consumo de recursos;

  • dependências;

  • mudanças recentes;

  • comportamento das aplicações;

  • impacto para o negócio.

No ambiente moderno, uma falha aparentemente simples no navegador pode ter começado muito longe dele.

O botão não respondeu.

Mas a causa pode estar em:

JavaScript
    ↓
REST API
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
DB2
    ↓
Storage

É por isso que o profissional capaz de compreender toda a cadeia possui enorme valor.

Ele não observa apenas a mensagem de erro.

Ele segue as pegadas.

O laboratório War Room Mainframe também está entre os recursos indicados na apresentação APPDEV.


Para ir mais longe: Bellacosa Mainframe

A formação termina.

O aprendizado, felizmente, não.

Para continuar explorando COBOL, CICS, DB2, JCL, VSAM, APIs, HTML, CSS, JavaScript, DevOps, segurança, arquitetura e cultura Mainframe, visite:

Um Café no Bellacosa Mainframe
https://eljefemidnightlunch.blogspot.com/

O blog funciona como uma grande biblioteca construída ao longo do tempo.

Há artigos para iniciantes.

Conteúdos técnicos aprofundados.

Histórias sobre a evolução da computação.

Analogias com filmes, séries, quadrinhos, ficção científica e cultura popular.

Porque aprender tecnologia também significa construir memórias.

Um conceito técnico pode ser esquecido.

Mas uma boa história costuma permanecer.

A apresentação indica o Bellacosa Mainframe como espaço para aprofundamento e continuidade dos estudos.


Projeto Coursera Web Developer no GitHub

Ler códigos é importante.

Executá-los é melhor.

Modificá-los é onde o aprendizado realmente começa.

Projeto Coursera Web Developer
https://github.com/VagnerBellacosa/Lab_WebdevelopmentCoursera

Nesse repositório, o aluno pode explorar a organização de um projeto real, comparar arquivos, analisar versões e compreender como HTML, CSS e JavaScript convivem dentro de uma estrutura profissional.

Um repositório Git não é apenas um lugar para guardar código.

Ele registra a história do projeto.

Mostra o que mudou.

Quando mudou.

Por que mudou.

E quem realizou a alteração.

Essa rastreabilidade aproxima o desenvolvimento Web das práticas modernas de DevOps utilizadas também no IBM Z.

O projeto e seu endereço no GitHub aparecem entre os materiais finais da apresentação.


Mais repositórios HTML: mão na massa

Para explorar outros exemplos, projetos e experiências relacionadas a HTML, acesse:

Repositórios HTML de Vagner Bellacosa
https://github.com/VagnerBellacosa?tab=repositories&q=html

Aqui vale seguir uma pequena rotina de laboratório:

  1. Escolha um projeto.

  2. Observe a estrutura de diretórios.

  3. Localize o index.html.

  4. Identifique os arquivos CSS.

  5. Encontre os códigos JavaScript.

  6. Execute a aplicação.

  7. Altere um elemento.

  8. Teste novamente.

  9. Quebre alguma coisa propositalmente.

  10. Descubra como corrigir.

O aprendizado verdadeiro começa quando deixamos de ser visitantes do código e passamos a ser seus investigadores.

A apresentação encerra a seção prática justamente apontando para os repositórios HTML disponíveis no GitHub.


Uma trilha prática sugerida

Para aproveitar melhor os materiais, siga esta sequência:

1. IBM Web Development Labs
              ↓
2. Projeto Web Developer no GitHub
              ↓
3. Repositórios HTML
              ↓
4. LAB IBM IPL Mainframe
              ↓
5. Lab IBM Storage Management
              ↓
6. LAB IBM Capacity
              ↓
7. Lab War Room Mainframe
              ↓
8. Bellacosa Mainframe

Começamos pela interface.

Seguimos para o código.

Entramos no controle de versões.

Descemos até a infraestrutura.

Observamos armazenamento e capacidade.

Investigamos incidentes.

E retornamos ao blog para continuar estudando.

Essa é a verdadeira jornada do Desenvolvedor IBM Z Moderno.

Ele não precisa dominar todas as áreas como especialista.

Mas precisa compreender como elas se conectam.


O diploma encerra uma etapa, não a jornada

Ao terminar a Formação APPDEV, o aluno leva muito mais do que alguns comandos HTML, propriedades CSS ou funções JavaScript.

Ele passa a compreender uma cadeia completa:

Usuário
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
REST API + JSON
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
IBM z17

Essa visão integrada é o verdadeiro resultado da formação.

O certificado registra que uma etapa foi concluída.

Os laboratórios demonstram que a prática começou.

O GitHub registra a evolução.

E o conhecimento de negócio transforma tudo isso em valor.

Por isso, quando alguém perguntar o que existe entre um botão HTML e uma transação COBOL, você não precisará mais imaginar dois mundos separados.

Verá uma única arquitetura.

Uma longa linha luminosa atravessando navegador, API, middleware, transação, programa e banco de dados.

De um lado, a experiência do usuário.

Do outro, a confiabilidade do IBM Z.

No meio deles...

O Desenvolvedor IBM Z Moderno.

Com uma caneca de café sobre a mesa e muitos caminhos ainda esperando para serem explorados.


quarta-feira, 29 de julho de 2026

IBM zSkill Fest 2026 : O Caso do Evento que Todo Profissional IBM Z Deveria Investigar

Bellacosa Mainframe orgulhosamente apresenta zSkill Fest 2026

🕵️☕ Um Café no Bellacosa Mainframe

O Caso do Evento que Todo Profissional IBM Z Deveria Investigar

"Elementar, meu caro Watson..."

Sherlock Holmes jamais ignoraria uma pista importante.

Então permita-me fazer uma pergunta...

🔎 Você já garantiu sua participação no ZSkillsFest 2026?

Falta menos de uma semana para o início de um dos maiores encontros da comunidade IBM Z do mundo, reunindo milhares de profissionais, estudantes, especialistas, IBM Champions, arquitetos, desenvolvedores, administradores de sistemas e apaixonados pelo Mainframe.

Se você acredita que conhecimento é poder, então este é o lugar onde novos capítulos da história do IBM Z serão escritos.

🧐 O mistério não é "vale a pena participar?".

O verdadeiro mistério é...

Por que você ainda não se registrou?

Mais de 4.000 participantes já confirmaram presença para aprender, compartilhar experiências, conhecer novidades e fortalecer sua rede de contatos com profissionais de diversos países.

Se você já está inscrito...

💬 Escreva nos comentários:

"Eu já estou inscrito!"

E melhor ainda...

🔁 Compartilhe esta publicação e convide mais pessoas para essa grande investigação tecnológica.

Se ainda não fez sua inscrição...

🎩 Considere este o seu convite oficial.

A comunidade IBM Z sempre cresce quando compartilhamos conhecimento.

Nos encontramos no ZSkillsFest 2026!



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚀 INSCREVA-SE AGORA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📌 Registro Oficial
IBM.biz/zsf2026

📌 Formulário de Inscrição
https://airtable.com/app4e1B2CCUAsPp9c/paguvQoyaG8u4jH1a/form

📌 Página Oficial do Evento
https://community.ibm.com/community/user/events/event-description?CalendarEventKey=b9bca5b1-51ec-4102-a1a7-019e8ffdc8fc&CommunityKey=e7b7d299-8509-4572-8cf1-c1112684644f


🔍 Porque, no universo do Mainframe, a maior descoberta nunca acontece sozinho... ela acontece em comunidade.

#IBMZ #Mainframe #ZSkillsFest2026 #COBOL #zOS #CICS #Db2 #RACF #DevOps #IBMChampion #BellacosaMainframe

segunda-feira, 27 de julho de 2026

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

 

Bellacosa Mainframe compara o aws com o mainframe

☕ Um Café no Bellacosa Mainframe

AWS vs Mainframe: O Grande Dicionário Bilíngue da Computação Corporativa

Quando um Programador COBOL Descobre que a Nuvem Não Inventou Tudo... Apenas Deu Novos Nomes às Velhas Ideias

Existe uma frase muito conhecida entre os profissionais de tecnologia:

"Toda tecnologia nova parece revolucionária... até você descobrir que o mainframe já fazia algo parecido há décadas."

Naturalmente, essa frase é um exagero. A computação em nuvem trouxe inúmeras inovações reais: elasticidade praticamente infinita, cobrança sob demanda, infraestrutura global distribuída, APIs padronizadas e uma velocidade de provisionamento que seria impensável nos anos 1970.

Por outro lado...

Quem trabalhou muitos anos em IBM Z percebe rapidamente algo curioso.

Boa parte dos conceitos fundamentais da Cloud Computing já existiam, apenas recebiam outros nomes.

É justamente isso que o infográfico procura mostrar.

Não se trata de afirmar que AWS = Mainframe.

Muito menos que um substitui o outro.

A proposta é muito mais inteligente:

Traduzir conceitos.

Da mesma forma que um brasileiro aprende inglês associando "house" com "casa", um programador COBOL aprende AWS muito mais rapidamente quando pensa:

"EC2... isso lembra uma LPAR."

É exatamente essa mudança mental que acelera o aprendizado.

Vamos aprofundar essa comparação.


Antes de tudo...

Existe um erro extremamente comum.

Muitos profissionais perguntam:

"Qual é o equivalente do AWS Lambda no Mainframe?"

Na verdade essa pergunta está errada.

O correto seria perguntar:

"Qual tecnologia do Mainframe resolve um problema semelhante?"

Porque tecnologias diferentes podem resolver o mesmo problema de maneiras completamente distintas.

É exatamente isso que veremos.


EC2 × LPAR

AWS

EC2 fornece máquinas virtuais sob demanda.

Você cria.

Liga.

Desliga.

Apaga.

Escala.

Tudo em minutos.


Mainframe

A comparação natural é a LPAR (Logical Partition).

Mas aqui existe uma enorme diferença filosófica.

Uma instância EC2 normalmente é um servidor virtual.

Uma LPAR é praticamente um computador completo.

Dentro dela existe:

  • z/OS

  • JES

  • RACF

  • CICS

  • Db2

  • MQ

  • milhares de usuários

Ou seja...

Uma única LPAR frequentemente faz o trabalho de centenas de servidores Linux.

Por isso muitos profissionais dizem:

"Comparar uma EC2 com uma LPAR é como comparar um apartamento com um condomínio inteiro."


Curiosidade

O conceito de particionamento lógico apareceu comercialmente décadas antes da virtualização popularizada pelo VMware.

A IBM fazia isso quando a maioria dos servidores ainda era física.


S3 × VSAM / DASD

Esta comparação merece cuidado.

S3 não é um disco.

É um armazenamento de objetos.

VSAM não é armazenamento de objetos.

É um método de acesso.

Então por que a comparação?

Porque ambos representam onde os dados vivem.


S3

Armazena objetos.

  • fotos

  • backups

  • vídeos

  • PDFs

  • logs

Escala praticamente infinita.


Mainframe

No IBM Z os dados normalmente ficam em:

  • DASD

  • VSAM

  • Sequential datasets

  • GDGs

  • PDS/PDSE

O conceito é diferente.

Enquanto S3 trabalha com objetos identificados por chaves, o mainframe trabalha com datasets catalogados e métodos de acesso especializados.

Um VSAM KSDS, por exemplo, comporta-se muito mais como um banco de dados indexado do que como um bucket S3.


Melhor analogia

Talvez fosse mais correto dizer:

S3 ≈ Conjunto de datasets altamente duráveis.

Não existe equivalente perfeito.


RDS × Db2 for z/OS

Aqui a aproximação é muito boa.

AWS oferece banco relacional gerenciado.

Db2 oferece banco relacional corporativo.

Mas termina aí.


O que muda?

No AWS:

Você administra menos infraestrutura.

No Mainframe:

Você administra muito mais parâmetros.

Em compensação...

Obtém níveis absurdos de disponibilidade.

Db2 z/OS foi construído para:

  • bancos

  • cartões

  • bolsas

  • governos

  • seguradoras

Milhões de transações por segundo.

Décadas de evolução.

Consistência extrema.


Easter Egg

Quando alguém diz:

"Meu banco usa RDS."

O programador de mainframe responde:

"Interessante... o meu banco inteiro usa Db2."


Lambda × CICS

Essa comparação é conceitual.

Lambda executa código quando um evento ocorre.

CICS executa transações quando uma requisição chega.

Ambos respondem a eventos.

Mas de maneiras completamente diferentes.


Lambda

Sem servidor visível.

Escala automaticamente.

Cada chamada inicia uma execução.


CICS

Servidor transacional residente.

As tarefas reutilizam recursos.

Baixíssima latência.

Controle rigoroso.

Extrema confiabilidade.


Uma transação CICS pode durar poucos milissegundos.

E atender milhares de usuários simultaneamente.

Há bancos onde o cliente insere a senha no caixa eletrônico...

E em menos de um décimo de segundo:

  • RACF valida

  • CICS executa

  • Db2 consulta

  • MQ envia mensagens

  • resposta retorna

Tudo isso antes do usuário piscar.


API Gateway × CICS Web Services

Nos últimos anos o CICS tornou-se um verdadeiro servidor de APIs.

Hoje é possível expor programas COBOL como:

  • REST

  • SOAP

  • JSON

Sem reescrever décadas de código.

A ideia é semelhante ao API Gateway:

publicar serviços de forma segura.

A diferença é que no CICS o backend muitas vezes continua sendo um programa escrito em 1989.

E funcionando perfeitamente.


CloudWatch × RMF / SMF

Talvez uma das melhores comparações.

CloudWatch monitora.

RMF mede.

SMF registra praticamente tudo.


No mainframe existem registros para:

CPU.

I/O.

Memória.

Logons.

Jobs.

CICS.

Db2.

MQ.

Segurança.

Tudo vira SMF.

Depois essas informações alimentam:

  • relatórios

  • capacity planning

  • billing interno

  • auditoria

  • performance

É praticamente uma caixa-preta de avião.


VPC × VTAM / TCP-IP

VPC cria uma rede privada lógica.

No mainframe temos:

  • TCP/IP

  • Enterprise Extender

  • SNA

  • VTAM (historicamente)

São tecnologias diferentes.

Mas ambas organizam comunicações seguras entre aplicações.

Hoje, o TCP/IP é predominante no z/OS, enquanto o VTAM permanece como parte importante da arquitetura SNA e do gerenciamento de sessões legadas.


IAM × RACF

Esta talvez seja a comparação mais intuitiva.

IAM controla identidades.

RACF controla identidades.

Mas RACF faz isso desde os anos 1970.


No RACF encontramos:

  • usuários

  • grupos

  • perfis

  • datasets

  • transações

  • comandos

  • permissões

Tudo centralizado.

Em ambientes corporativos enormes, RACF continua sendo um dos sistemas de segurança mais robustos do mercado.


CloudFront

Aqui o infográfico coloca:

Sem equivalente.

Concordo parcialmente.

CloudFront é uma CDN.

Mainframe nunca precisou distribuir imagens para milhões de navegadores.

Mas existe um conceito parecido.

CICS, z/OS Connect e balanceadores corporativos podem distribuir carga entre regiões, embora isso não seja uma CDN. Portanto, realmente não há um equivalente direto.


DynamoDB

Também não existe equivalente perfeito.

O mainframe tradicional trabalha principalmente com:

  • Db2

  • IMS DB

  • VSAM

Entretanto...

IMS Hierarchical Database possui algumas características que lembram bancos NoSQL modernos.

Não são iguais.

Mas resolvem certos problemas semelhantes.


SQS × IBM MQ

Esta comparação é excelente.

Ambos trabalham com filas.

Mensagens.

Processamento assíncrono.

Desacoplamento.

A principal diferença está no foco.

IBM MQ nasceu para ambientes corporativos críticos.

SQS nasceu para aplicações distribuídas na nuvem.

Ambos resolvem brilhantemente problemas de integração, mas IBM MQ oferece recursos avançados de transação, persistência e integração com sistemas legados que o tornam um pilar do processamento empresarial.


SNS × WTO / Console Messages

Aqui talvez seja a comparação mais discutível.

SNS distribui notificações para diversos assinantes.

Já WTO (Write To Operator) envia mensagens ao console do operador do z/OS.

Embora ambos "notifiquem", cumprem papéis muito diferentes.

Uma analogia funcional mais próxima seria:

  • SNS ↔ combinação de IBM MQ + Event Notification + automação (como IBM Z System Automation ou NetView), dependendo do cenário.

WTO é muito mais voltado para operação do sistema do que para publicação de eventos para consumidores.


O que ficou faltando?

O universo AWS é enorme. Diversos serviços modernos também encontram paralelos conceituais no ecossistema IBM Z:

AWSMainframe
EBSVolumes DASD
EFSzFS / HFS
Elastic Load BalancerSysplex Distributor
Auto ScalingWLM + Capacity on Demand
Secrets ManagerRACF Key Rings + ICSF
KMSICSF + Hardware Crypto Express
CloudTrailSMF + RACF Auditing
Systems Managerz/OSMF
ECS/EKSzCX (z/OS Container Extensions)
EventBridgeIBM MQ + CICS START + automação
Step FunctionsJCL + Scheduler (TWS/IWS, CA 7, Control-M)
GlueDFSORT, SyncSort, DataStage e ferramentas ETL
AthenaDb2 Analytics, SQL Federation e consultas distribuídas
RedshiftDb2 Analytics Accelerator (IDAA)
CognitoRACF + provedores de identidade (LDAP, SAF, z/OS Connect)

A Filosofia por Trás da Comparação

A maior lição do infográfico não é decorar equivalências.

É perceber que os problemas fundamentais da computação permanecem os mesmos:

  • executar aplicações;

  • armazenar dados;

  • proteger acessos;

  • integrar sistemas;

  • monitorar ambientes;

  • processar eventos;

  • escalar capacidade.

O que muda é a forma como cada arquitetura resolve esses desafios.

O IBM Z foi concebido para oferecer estabilidade, consistência transacional e disponibilidade extrema em um ambiente centralizado. A AWS foi projetada para privilegiar elasticidade, automação, distribuição geográfica e provisionamento sob demanda em uma infraestrutura de nuvem.

Essas filosofias não são concorrentes em todos os casos — são frequentemente complementares. Hoje, é comum encontrar bancos, seguradoras e governos executando seus sistemas críticos em IBM Z enquanto utilizam AWS para APIs, analytics, inteligência artificial, aplicações móveis e serviços digitais.


Conclusão: O Melhor Profissional Fala Dois "Idiomas"

No início da carreira, muitos especialistas em mainframe enxergavam a nuvem como uma ameaça. Da mesma forma, muitos profissionais de cloud acreditavam que o mainframe era apenas uma tecnologia ultrapassada.

Com o tempo, o mercado mostrou uma realidade bem diferente.

Os ambientes corporativos mais sofisticados são híbridos.

O cartão de crédito pode ser autorizado por um programa COBOL executando em CICS e Db2 no IBM Z, enquanto o aplicativo móvel utiliza APIs hospedadas na AWS, com autenticação moderna, monitoramento em nuvem e microsserviços.

Em vez de escolher entre "mainframe ou cloud", as organizações escolhem mainframe e cloud.

Para o profissional de tecnologia, isso significa uma oportunidade extraordinária: dominar os dois mundos. Quem entende como traduzir conceitos entre AWS e IBM Z consegue atuar como uma ponte entre equipes, acelerar projetos de modernização e preservar décadas de conhecimento corporativo enquanto incorpora as práticas mais recentes da computação em nuvem.

No fim das contas, aprender AWS não exige esquecer o mainframe. Pelo contrário: para quem já conhece IBM Z, muitas ideias da nuvem deixam de parecer completamente novas e passam a ser apenas uma nova linguagem para resolver problemas que a computação empresarial enfrenta — e resolve — há mais de meio século.

domingo, 26 de julho de 2026

A Academia Jedi do COBOL: Tudo o Que um Padawan Precisa Saber para Dominar o Mainframe

 

Bellacosa Mainframe e a academia mainframe

 A Academia Jedi do COBOL: Tudo o Que um Padawan Precisa Saber para Dominar o Mainframe

FUNDAMENTOS DO DESENVOLVIMENTO COBOL


1. Conceitos Básicos

Antes de escrever uma linha de código, o aluno precisa entender o que é COBOL.

COBOL significa:

COmmon Business Oriented Language

Criada em 1959 para resolver problemas de negócios.

Enquanto linguagens modernas nasceram para matemática ou sistemas operacionais, COBOL nasceu para:

  • Folha de pagamento

  • Bancos

  • Seguros

  • Governo

  • Contabilidade

  • Controle financeiro

Exemplo:

Imagine um banco processando:

  • 50 milhões de contas

  • 300 milhões de transações por dia

Grande parte disso ainda roda em COBOL.


Estrutura clássica

IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
DATA DIVISION.
PROCEDURE DIVISION.

Comparação:

COBOLCasa
IdentificationNome do dono
EnvironmentInfraestrutura
DataMóveis
ProcedureO que acontece dentro

2. Tipos de Programas

Um erro comum é achar que existe apenas um tipo de programa COBOL.

Na prática temos:


Programas Batch

Executados sem interação humana.

Exemplo:

Processamento noturno do banco.

23:00 Início
04:00 Fim

Milhões de registros processados.


Programas Online

Executados pelo usuário.

Exemplo:

Caixa eletrônico.

Saque
Extrato
Transferência

Normalmente via CICS.


Subprogramas

Programas chamados por outros programas.

Exemplo:

CALL 'CALCJURO'

Reutilização de código.


Utilitários

Ferramentas auxiliares.

Exemplo:

  • Conversão de arquivos

  • Formatação

  • Migração de dados


3. Etapas para Desenvolvimento

Aqui o aluno aprende que programar é apenas uma parte do trabalho.


Levantamento de requisitos

Perguntas:

  • O que o usuário quer?

  • Quais entradas existem?

  • Quais saídas são necessárias?


Análise

Transformar regra de negócio em lógica.

Exemplo:

Se idade >= 65
então aposentado

Projeto

Definir:

  • Arquivos

  • Variáveis

  • Fluxo

  • Relatórios


Codificação

Somente agora começa o COBOL.


Testes

Muitos iniciantes pulam esta etapa.

Erro gravíssimo.

Um programa sem testes:

COMPILA ≠ FUNCIONA

4. Terminologia, Conceitos e Recursos

Aqui nasce o vocabulário do programador.


Registro

Uma linha lógica.

Exemplo:

001 João      2500.00

Campo

Parte do registro.

Nome
Salário
CPF

Arquivo

Conjunto de registros.


Programa

Conjunto de instruções.


Job

Execução do programa.

No Mainframe:

//STEP01 EXEC PGM=FOLHA001

☕💣 LÓGICA DE PROGRAMAÇÃO


5. Ferramentas de Planejamento

O pior programador é aquele que abre o editor antes de pensar.

Planejamento economiza horas.


Diagrama de Processo

Entrada
 ↓
Validação
 ↓
Cálculo
 ↓
Saída

Tabela de Decisão

Muito usada em bancos.

Exemplo:

SaldoCrédito
>10000Sim
<10000Não

6. Projeto Estruturado

A filosofia:

Resolver problemas grandes
dividindo em pequenos problemas

Exemplo:

Sistema de Folha

LER FUNCIONÁRIO
CALCULAR SALÁRIO
CALCULAR IMPOSTOS
IMPRIMIR

Cada parte vira um parágrafo.


7. Fluxogramas

Antes do COBOL existia o fluxograma.

Exemplo:

INÍCIO
  |
LER ARQUIVO
  |
FIM DO ARQUIVO?
 /      \
SIM      NÃO
 |         |
FIM      PROCESSA

Benefícios

  • Facilita entendimento

  • Ajuda documentação

  • Facilita manutenção


8. Pseudocódigo

Traduz a regra para linguagem humana.

Exemplo:

LER CLIENTE

SE IDADE >= 18
   APROVAR
SENÃO
   REJEITAR
FIM-SE

Depois converte para COBOL.

IF IDADE >= 18
   MOVE 'S' TO APROVADO
ELSE
   MOVE 'N' TO APROVADO
END-IF.

9. Instruções e Operadores

Comandos básicos.


MOVE

MOVE SALARIO TO SALARIO-ANTIGO

COMPUTE

COMPUTE TOTAL = VALOR + JUROS

ADD

ADD 100 TO SALDO

SUBTRACT

SUBTRACT 50 FROM SALDO

MULTIPLY

MULTIPLY QTDE BY PRECO
    GIVING TOTAL

DIVIDE

DIVIDE TOTAL BY PARCELAS
    GIVING VALOR-PARCELA

10. Estruturas de Controle

O cérebro do programa.


IF

IF SALDO > 0

EVALUATE

Equivalente ao SWITCH.

EVALUATE TIPO
   WHEN 1
      ...
   WHEN 2
      ...
END-EVALUATE

PERFORM

Laços de repetição.

PERFORM 100 TIMES

PERFORM UNTIL

PERFORM UNTIL EOF = 'S'

Muito usado em batch.


☕💣 PADRÕES PROFISSIONAIS


11. Padrões de Nomes

Programador júnior:

01 X.
01 Y.

Programador profissional:

01 WS-SALDO-CLIENTE.
01 WS-LIMITE-CREDITO.

Prefixos comuns

PrefixoSignificado
WSWorking Storage
LKLinkage
FDFile Description
INEntrada
OUTSaída

Parágrafos

Ruim:

1000.

Bom:

1000-LER-CLIENTE.
2000-PROCESSAR-CLIENTE.
3000-EMITIR-RELATORIO.

☕💣 ARQUIVOS E RELATÓRIOS


12. Arquivos Sequenciais

A base histórica do COBOL.

Imagine uma fita magnética.

Leitura:

READ ARQ-CLIENTE

Fluxo clássico:

OPEN INPUT ARQ

PERFORM UNTIL EOF
   READ ARQ
END-PERFORM

CLOSE ARQ

13. Relatórios

Objetivo:

Transformar dados em informação.

Exemplo:

RELATÓRIO DE VENDAS

TOTAL VENDIDO:
R$ 1.500.000

Aspectos importantes:

  • Cabeçalho

  • Detalhes

  • Totais

  • Quebras de controle


Quebra de Controle

Exemplo:

Departamento A
Total A

Departamento B
Total B

Técnica extremamente usada em batch.


☕💣 NÍVEL CORPORATIVO


14. Arquivos Indexados

Aqui o aluno entra no mundo dos bancos e seguradoras.


Sequencial

Procurar conta 9000

1
2
3
4
...
9000

Lento.


Indexado

Índice → Registro

Busca quase instantânea.


Exemplo VSAM KSDS:

READ CLIENTE-KSDS
     KEY IS CPF

15. Tabelas Internas

Equivalente aos arrays modernos.

01 TAB-CLIENTES.
   05 CLIENTE OCCURS 100 TIMES.

Acesso:

CLIENTE(15)

Busca binária:

SEARCH ALL

Tema importantíssimo para entrevistas.


16. Subprogramas

Onde o aluno começa a pensar como arquiteto.


Programa principal:

CALL 'CALCIR'

Subprograma:

LINKAGE SECTION.

Recebe parâmetros.


Benefícios:

  • Reuso

  • Manutenção

  • Modularidade

  • Padronização


O QUE ESTÁ FALTANDO PARA O MERCADO ATUAL?

Se eu fosse enriquecer esse módulo para formar um desenvolvedor COBOL moderno, incluiria também:

Módulo Extra 1 – JCL Básico

  • JOB

  • EXEC

  • DD

  • Condições de execução

  • Return Codes


Módulo Extra 2 – VSAM

  • KSDS

  • ESDS

  • RRDS

  • Alternates Index


Módulo Extra 3 – DB2

  • SELECT

  • INSERT

  • UPDATE

  • CURSOR


Módulo Extra 4 – CICS

  • MAPS

  • COMMAREA

  • Pseudo-conversação


Módulo Extra 5 – Debugging

  • Abend S0C7

  • Abend S0C4

  • FILE STATUS

  • CEEDUMP

  • SYSUDUMP


Módulo Extra 6 – Boas Práticas de Mainframe

  • Naming standards

  • Estrutura de parágrafos

  • Controle de versões

  • Revisão de código

  • Performance

  • Segurança RACF


Visão de carreira do Padawan COBOL

A evolução típica é:

Padawan
 ↓
Programador Júnior
 ↓
Programador Pleno
 ↓
Programador Sênior
 ↓
Analista de Sistemas
 ↓
Arquiteto Mainframe
 ↓
Especialista Corporativo

O segredo não está em decorar comandos COBOL, mas em compreender profundamente processamento de dados, regras de negócio, arquivos, bancos de dados, performance e arquitetura corporativa, pois é exatamente isso que diferencia um simples codificador de um verdadeiro Jedi do Mainframe. ☕💣🚀



sábado, 25 de julho de 2026

O Código Nunca Foi o Mistério : Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

 

Bellacosa Mainframe na aventura onde o codigo nunca foi o misterio

☕ Um Café no Bellacosa Mainframe

O Código Nunca Foi o Mistério

Quando um Programador COBOL Descobre que Alterar Dez Linhas é Fácil... Difícil é Sobreviver ao Templo Esquecido do Sistema

"Arqueologia não é procurar coisas velhas. É descobrir a história escondida por trás delas."

Se Indiana Jones tivesse escolhido Ciência da Computação em vez de Arqueologia, provavelmente terminaria trabalhando em um grande banco desenvolvendo COBOL.

Pode parecer exagero.

Mas pense comigo.

Indiana nunca encontrava o artefato logo na primeira sala.

Primeiro havia um mapa incompleto.

Depois uma caverna.

Uma armadilha.

Um diário escrito há cinquenta anos.

Um símbolo perdido.

Um templo subterrâneo.

Uma pedra falsa.

Uma ponte quebrada.

E somente depois de horas de investigação ele finalmente colocava as mãos no objeto que havia saído para procurar.

No Mainframe acontece exatamente a mesma coisa.

O gerente chega à sua mesa.

— "É só alterar umas dez linhas."

Você sorri.

Respira.

Abre o ISPF.

E cinco minutos depois percebe que acaba de entrar no equivalente computacional do Templo da Perdição.

Bem-vindo ao verdadeiro trabalho de um desenvolvedor COBOL.


Capítulo 1 — O Mapa Perdido

Todo aventureiro começa com um mapa.

O problema é que, no mundo corporativo, esse mapa quase nunca existe.

Ou pior.

Existe.

Mas foi escrito em 1994.

Em WordPerfect.

Impresso.

Escaneado.

Convertido para PDF.

E armazenado numa pasta chamada:

Documentacao_Final_Versao_Final_2_AgoraVai.pdf

Que obviamente está desatualizada desde 1998.

É nesse momento que o jovem programador descobre uma das maiores verdades da profissão.

O COBOL não é o sistema.

O programa é apenas uma pequena pedra dentro de uma pirâmide construída durante décadas.


Capítulo 2 — O Chicote Não é o COBOL

Muita gente acredita que dominar COBOL significa dominar Mainframe.

É o mesmo que dizer:

"Indiana Jones venceu porque sabia usar um chicote."

Não.

O chicote era apenas uma ferramenta.

O verdadeiro diferencial era compreender:

  • história

  • culturas

  • idiomas

  • símbolos

  • armadilhas

  • comportamento humano

Com COBOL acontece exatamente igual.

Conhecer:

MOVE
ADD
PERFORM
IF
READ
WRITE

é apenas aprender a usar o chicote.

O arqueólogo ainda nem entrou no templo.


Capítulo 3 — A Primeira Porta

Chega o chamado.

Modificar o programa FAT001.

Perfeito.

Onde ele está?

Ninguém sabe.

Começa então a expedição.

Primeira parada:

PDS COBOL

Nada.

Segunda parada.

LIBLOAD

Nada.

Terceira.

JCLLIB

Quarta.

PROCLIB

Quinta.

Scheduler

Somente depois de muito procurar você descobre:

JOBFIN01

↓

PROCFAT

↓

STEP040

↓

PGM=FAT001

Parabéns.

Você encontrou a porta do templo.

Agora começa a aventura.


Capítulo 4 — O Diário do Professor Ravenwood

Indiana Jones sempre encontrava um velho diário.

No Mainframe ele possui outro nome.

JCL.

O JCL é praticamente um diário de viagem.

Ele conta:

  • quem chamou o programa;

  • quais arquivos entram;

  • quais arquivos saem;

  • qual biblioteca foi usada;

  • quais parâmetros chegaram;

  • qual região executa;

  • qual ambiente está sendo utilizado.

Um simples trecho como:

//EXEC PGM=FAT001

parece insignificante.

Mas atrás dele existem dezenas de decisões arquitetônicas tomadas durante décadas.

O JCL responde perguntas que o próprio programa COBOL jamais responderá.


Capítulo 5 — As Pegadas na Poeira

Indiana observava pegadas.

Você observa datasets.

Imagine encontrar:

CLIENTE.GDG(+1)

Quem criou?

Quando?

Qual layout?

Possui compressão?

É VB?

FB?

RECFM?

LRECL?

Existe SORT anterior?

Existe IDCAMS?

Existe IEBGENER?

Cada dataset é uma pegada deixada por alguém que passou antes.

E cada pegada pode revelar uma história completamente diferente.


Capítulo 6 — O Labirinto dos Processamentos

Na imagem analisada, uma das partes mais brilhantes é justamente a existência de dois mundos:

Traitements Amont

e

Traitements Aval.

Pouca gente percebe a importância disso.

Imagine uma corrente.

Sistema A

↓

Sistema B

↓

Sistema C

↓

Sistema D

↓

Seu programa

O problema talvez tenha começado cinco programas antes.

Agora imagine o contrário.

Seu programa

↓

Financeiro

↓

PIX

↓

SPED

↓

Data Warehouse

↓

BI

↓

IA

Alterar um campo pode quebrar seis departamentos.

É como retirar uma pedra da parede de um templo maia.

Talvez nada aconteça.

Ou talvez toda a construção desabe.


Capítulo 7 — A Câmara das Armadilhas

Nos filmes existe sempre uma sala cheia de mecanismos mortais.

No Mainframe essa sala chama-se:

Regras de Negócio

Elas raramente aparecem documentadas.

Você encontra coisas como:

IF UF = "AM"

Por quê?

Silêncio.

Outro exemplo.

IF CODIGO = 37

Por quê?

Ninguém sabe.

Até que um veterano lembra.

— Em 1996 surgiu uma legislação especial.

Pronto.

Você acaba de resolver um mistério de trinta anos.


Curiosidade Bellacosa nº 1

Existe uma frase muito conhecida entre desenvolvedores experientes:

"Todo IF estranho possui uma história triste."

E normalmente ela envolve:

  • imposto;

  • banco central;

  • auditoria;

  • legislação;

  • cliente VIP;

  • bug ocorrido numa madrugada de domingo.


Capítulo 8 — O Cálice Sagrado Chama-se DB2

Muitos iniciantes acreditam que alterar uma tabela significa apenas executar:

ALTER TABLE

Longe disso.

Uma coluna nova pode afetar:

  • índices;

  • packages;

  • plans;

  • RUNSTATS;

  • REORG;

  • BIND;

  • stored procedures;

  • triggers;

  • views;

  • aplicações Java;

  • aplicações .NET;

  • relatórios;

  • APIs REST.

No filme, Indiana precisava escolher o cálice correto.

No Mainframe você precisa alterar a coluna correta.

Escolher errado custa muito mais caro que um filme de Hollywood.


Capítulo 9 — O Reino Invisível do CICS

Durante o dia:

Cliente consulta saldo.

À noite:

Batch recalcula saldo.

São dois mundos completamente diferentes.

Mas compartilham os mesmos dados.

É como duas expedições arqueológicas explorando entradas diferentes do mesmo templo.

Se um explorador mover uma pedra...

O teto pode cair sobre o outro.


Capítulo 10 — O Calendário Maia do Scheduler

Existe uma entidade misteriosa.

Poucos iniciantes lhe dão atenção.

Scheduler.

Ele sabe exatamente:

  • que horas tudo começa;

  • quanto cada JOB demora;

  • quem depende de quem;

  • qual janela operacional existe;

  • qual SLA precisa ser cumprido.

Imagine:

22:00 Recepção

22:30 Validação

23:10 DB2

00:20 COBOL

01:30 SPED

03:40 Banco Central

Você aumenta cinco minutos no processamento.

Agora tudo termina quinze minutos depois.

Às vezes isso significa apenas atraso.

Às vezes significa multa milionária.


Easter Egg nº 1 — A Pedra Rolante

Todo programador COBOL já viveu algo parecido.

Você altera uma linha.

Executa o teste.

Tudo funciona.

Vai para homologação.

Tudo funciona.

Vai para produção.

Então aparece uma "pedra rolante" gigantesca.

Não era seu programa.

Era um JOB executado apenas no último dia útil do mês, usando um parâmetro que ninguém lembrava existir.

A pedra não persegue Indiana Jones apenas no cinema.

Ela também aparece às 02h47 da manhã, durante o fechamento contábil.


Capítulo 11 — A Arqueologia Digital

Talvez a maior habilidade de um desenvolvedor Mainframe não seja programar.

Seja investigar.

Você vira uma mistura de:

  • arqueólogo;

  • historiador;

  • investigador;

  • detetive;

  • matemático;

  • contador;

  • psicólogo;

  • engenheiro.

Cada programa é uma civilização antiga.

Cada comentário:

* NÃO ALTERAR

é uma inscrição hieroglífica.

Cada COPYBOOK é um pergaminho.

Cada PDS é uma biblioteca de Alexandria.

Cada JOB é uma rota comercial entre impérios.


Passo a Passo — Como um Desenvolvedor Experiente Investiga uma Alteração

Antes de escrever qualquer linha de código, siga uma metodologia quase arqueológica:

Etapa 1 — Entenda o requisito

Não aceite frases como:

"É só mudar um IF."

Pergunte:

  • Qual problema de negócio será resolvido?

  • Existe documentação?

  • Quem é o usuário afetado?


Etapa 2 — Localize o programa

  • PDS fonte

  • Load Library

  • Histórico de versões

  • Chamadores

  • Programas chamados


Etapa 3 — Analise o JCL

Verifique:

  • EXEC PGM

  • DD Statements

  • GDGs

  • SYSIN

  • SYSOUT

  • PROCs

  • PARM


Etapa 4 — Descubra os arquivos

Para cada dataset pergunte:

  • Quem gera?

  • Quem consome?

  • Qual layout?

  • Existe versionamento?


Etapa 5 — Analise o banco

  • Tabelas

  • Índices

  • Views

  • Packages

  • Plans

  • Estatísticas

  • SQLs afetados


Etapa 6 — Verifique integrações

Existe:

  • CICS?

  • MQ?

  • Web Services?

  • z/OS Connect?

  • APIs?

  • Batch paralelo?


Etapa 7 — Procure regras escondidas

Nunca confie apenas na documentação.

Leia o código.

Leia comentários antigos.

Converse com analistas.

Converse com usuários.

Muitas regras vivem apenas na memória das pessoas.


Etapa 8 — Teste impacto

Pergunte sempre:

Quem depende disso?

Quem será afetado?

Quem vai perceber?


Curiosidade Bellacosa nº 2

Em muitos bancos existem programas COBOL executando diariamente há mais de quarenta anos.

Alguns foram escritos antes mesmo do nascimento dos desenvolvedores que hoje fazem sua manutenção.

É como entrar em uma tumba egípcia sabendo que o arquiteto original nunca imaginou que alguém, quatro décadas depois, ainda pisaria naquele corredor para instalar uma nova "porta secreta".


Easter Egg nº 2 — O "X" Nunca Marca o Lugar

Nos filmes, o mapa sempre mostra um enorme X indicando o tesouro.

No desenvolvimento corporativo acontece exatamente o contrário.

O chamado diz:

"Alterar o programa FAT001."

Você passa dois dias investigando e descobre que o problema verdadeiro está em:

  • um parâmetro no Scheduler;

  • um SORT que remove registros;

  • um COPYBOOK compartilhado;

  • uma VIEW DB2;

  • um arquivo recebido de outro sistema.

O X nunca marca o lugar certo. A jornada até ele é que revela onde o verdadeiro problema estava escondido.


Conclusão — O Tesouro Não é o Código

Quando iniciamos nossa jornada em COBOL, acreditamos que aprenderemos uma linguagem de programação.

Com o tempo percebemos que aprendemos algo muito maior.

Aprendemos engenharia de sistemas.

O programa COBOL é apenas a ponta visível de um enorme continente tecnológico formado por JCLs, PROCs, Scheduler, Db2, CICS, VSAM, arquivos, integrações, calendários operacionais e regras de negócio acumuladas ao longo de décadas.

É por isso que dois profissionais com o mesmo domínio da sintaxe podem ter desempenhos completamente diferentes. Um conhece os verbos da linguagem; o outro conhece a história do templo, onde estão as armadilhas, quais corredores desabam, onde ficam as passagens secretas e qual pedra jamais deve ser removida.

No universo Bellacosa Mainframe, o verdadeiro desenvolvedor COBOL não é apenas um programador. Ele é um explorador da computação corporativa, alguém que entra diariamente em ruínas digitais construídas por gerações de engenheiros e retorna trazendo o artefato mais valioso de todos: uma alteração segura, compreendida e confiável, capaz de preservar sistemas que movimentam bancos, governos, seguradoras e a economia mundial sem que milhões de usuários sequer percebam que uma aventura aconteceu durante a madrugada.

E, como diria um certo arqueólogo de chapéu e chicote, ao fechar mais um chamado aparentemente simples:

"O código pertence ao sistema... mas o conhecimento pertence a quem teve coragem de explorar o templo inteiro antes de alterar uma única linha."

quinta-feira, 16 de julho de 2026

🚀 Quer Começar uma Carreira em IBM Mainframe? Estes Cursos Gratuitos São o Melhor Ponto de Partida

 

Bellacosa Mainframe inicie sua carreira em ibm mainframe tudo gratuito

☕ Um Café no Bellacosa Mainframe

🚀 Quer Começar uma Carreira em IBM Mainframe? Estes Cursos Gratuitos São o Melhor Ponto de Partida

Durante muitos anos, aprender Mainframe significava ter acesso a um IBM Z físico ou trabalhar em uma grande empresa. Hoje esse cenário mudou completamente. A IBM e sua comunidade disponibilizam uma excelente coleção de cursos gratuitos, laboratórios práticos e trilhas de aprendizado que permitem a qualquer pessoa iniciar uma carreira em uma das áreas mais estáveis e valorizadas da Tecnologia da Informação.

Se você é um Programador COBOL Padawan, considere esta lista como sua Academia da Frota Estelar. Antes de assumir o controle da USS Enterprise (ou de um IBM Z), é preciso dominar os fundamentos.


🖖 1. IBM Z Mainframe Skills Depot (A Academia Oficial da IBM)

O melhor ponto de partida para quem deseja aprender Mainframe.

A plataforma reúne centenas de horas de treinamento organizadas por trilhas de carreira, incluindo:

  • COBOL

  • JCL

  • Db2

  • CICS

  • IMS

  • VSAM

  • RACF

  • z/OS

  • DevOps

  • Segurança

  • Modernização

  • Linux on IBM Z

👉 IBM Z Mainframe Skills Depot


🎮 2. IBM Z Xplore

Aprender jogando.

O IBM Z Xplore transforma o aprendizado em desafios práticos. Você resolve missões reais, ganha badges digitais e aprende utilizando um ambiente IBM Z.

Ideal para quem nunca teve contato com Mainframe.

Você encontrará desafios envolvendo:

  • COBOL

  • JCL

  • TSO/ISPF

  • USS

  • Python

  • Db2

  • VS Code

  • Linux on Z

👉 IBM Z Xplore


💻 3. Learning COBOL Programming with VS Code

Um dos melhores cursos gratuitos para iniciantes.

Ao invés de começar diretamente na tradicional tela verde, você aprende COBOL utilizando o Visual Studio Code e ferramentas modernas.

Conteúdo:

  • Introdução ao COBOL

  • Variáveis

  • IF

  • PERFORM

  • Arquivos

  • Estruturas de dados

  • Desenvolvimento moderno

👉 Learning COBOL Programming with VS Code


🎓 4. IBM Training

O portal oficial de treinamento da IBM reúne centenas de cursos gratuitos e pagos sobre IBM Z, LinuxONE, automação, segurança, IA e diversas tecnologias corporativas.

👉 IBM Training


🌎 5. IBM SkillsBuild

Excelente plataforma para desenvolver competências em tecnologia.

Além de Mainframe, oferece cursos de:

  • Computação em Nuvem

  • Inteligência Artificial

  • Segurança

  • Programação

  • Dados

  • Soft Skills

Tudo isso ajuda a formar um profissional completo.

👉 IBM SkillsBuild


⚙️ 6. IBM Developer

Portal com artigos, tutoriais, exemplos de código, projetos e conteúdos produzidos por especialistas da IBM.

Ideal para aprofundar os estudos depois dos cursos básicos.

👉 IBM Developer


📚 7. Open Mainframe Project

Uma excelente fonte para conhecer o ecossistema open source voltado ao IBM Z.

Você encontrará projetos como:

  • Zowe

  • Feilong

  • COBOL Programming Course

  • Modernização

  • DevOps

👉 Open Mainframe Project


🧑‍💻 8. IBM Redbooks

Os famosos "livros vermelhos" da IBM.

São referências técnicas escritas por especialistas e cobrem praticamente todos os assuntos relacionados ao IBM Z.

👉 IBM Redbooks


🚀 Roteiro recomendado para iniciar

Não tente aprender tudo de uma vez. Uma sequência eficiente é:

  1. Conceitos de Mainframe e z/OS

  2. COBOL

  3. JCL

  4. VSAM e QSAM

  5. SQL e Db2

  6. CICS

  7. IMS

  8. TSO/ISPF

  9. REXX

  10. RACF

  11. Git e DevOps para IBM Z

  12. APIs e Modernização (z/OS Connect, REST)

  13. Ansible, Zowe e automação

  14. IA aplicada ao IBM Z


💡 Dicas para o Programador COBOL Padawan

  • Não estude apenas COBOL: o ecossistema Mainframe é composto por diversas tecnologias que trabalham em conjunto.

  • Faça os laboratórios sempre que possível; a prática acelera o aprendizado.

  • Conquiste badges e certificados para enriquecer seu currículo e perfil no LinkedIn.

  • Participe de comunidades, eventos e programas como IBM Z Day e IBM TechXchange.

  • Compartilhe seus projetos e aprendizados. Ensinar também é uma excelente forma de consolidar conhecimento.


🖖 Mensagem Final

Na USS Enterprise, o conhecimento era a ferramenta mais valiosa da tripulação. No universo IBM Z, a lógica, a disciplina e o aprendizado contínuo desempenham o mesmo papel. Com tantos recursos gratuitos disponíveis hoje, nunca foi tão acessível iniciar uma carreira em Mainframe. O importante é começar, evoluir um passo de cada vez e transformar curiosidade em experiência prática.

Como diria o Sr. Spock:

"A lógica é o começo da sabedoria, não o fim."

Que sua jornada no universo IBM Mainframe seja longa, próspera e repleta de novos conhecimentos. 🖖

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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...