Translate

quarta-feira, 25 de maio de 2022

🚀 Da Academia da Frota Estelar ao IBM Z A Jornada do Herói para Quem Sonha Construir uma Carreira em Mainframe

 

Bellacosa Mainframe aprenda Stack Mainframe

☕ Um Café no Bellacosa Mainframe

🚀 Da Academia da Frota Estelar ao IBM Z

A Jornada do Herói para Quem Sonha Construir uma Carreira em Mainframe

"O espaço, a fronteira final..."

Essa frase marcou gerações de fãs de ficção científica. Em Jornada nas Estrelas, ela representa o desejo humano de explorar o desconhecido, aprender continuamente e evoluir como civilização.

Curiosamente, esse mesmo espírito pode inspirar quem está dando os primeiros passos na carreira de tecnologia.

Talvez você nunca tenha pilotado uma nave estelar.

Talvez nunca tenha visto um IBM Z de perto.

Mas, assim como todo grande oficial da Frota Estelar começou como um simples cadete, todo especialista em Mainframe também começou sem saber o que era um JCL, um dataset, um CICS ou um Db2.

A diferença entre quem apenas sonha e quem realmente chega à ponte de comando não está no talento extraordinário.

Está na decisão de começar.


O Convite para uma Grande Jornada

Vivemos uma época única.

Durante décadas, aprender Mainframe era privilégio de quem trabalhava em grandes bancos, seguradoras ou órgãos governamentais.

Hoje isso mudou completamente.

A IBM disponibiliza gratuitamente uma enorme quantidade de conteúdo que antes era acessível apenas dentro das empresas.

Isso significa que qualquer pessoa com curiosidade, dedicação e acesso à internet pode iniciar uma carreira em uma das áreas mais importantes da computação corporativa.

Não importa se você está começando na programação.

Não importa sua idade.

Não importa se nunca escreveu uma linha de COBOL.

Toda viagem começa com o primeiro passo.


O IBM Z é Muito Mais do que COBOL

Um dos maiores mitos sobre Mainframe é acreditar que ele se resume à linguagem COBOL.

Na realidade, um IBM Z funciona como uma verdadeira nave interestelar.

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

Assim como a USS Enterprise depende do trabalho coordenado entre engenharia, segurança, comunicações e navegação, o Mainframe reúne tecnologias que trabalham em perfeita harmonia.

Durante nossa série conhecemos algumas delas.

COBOL é a linguagem responsável pelas regras de negócio.

JCL organiza e executa as grandes missões em lote.

z/OS coordena toda a plataforma.

VSAM e QSAM armazenam e organizam informações.

Db2 administra bancos de dados relacionais.

CICS responde às transações em tempo real.

IMS continua sustentando aplicações críticas.

RACF protege os recursos da plataforma.

Git, DevOps, Zowe e APIs conectam o Mainframe ao universo moderno do desenvolvimento de software.

Quando enxergamos o IBM Z dessa forma, percebemos que aprender Mainframe significa compreender um ecossistema inteiro — e é exatamente isso que torna essa carreira tão fascinante.


A Academia da Frota Estelar Existe

Na ficção, cadetes passam anos estudando antes de receber sua primeira missão.

No universo IBM, essa academia existe na forma de plataformas gratuitas de aprendizado.

Comece por elas.

🌐 IBM Z Mainframe Skills Depot

A principal porta de entrada para novos profissionais.

Reúne trilhas organizadas por carreira, cobrindo desenvolvimento, administração, segurança, DevOps e muito mais.

👉 https://www.ibm.com/products/z/resources/mainframe-skills


🎮 IBM Z Xplore

Aprender fazendo.

A plataforma transforma o estudo em desafios práticos e gamificados.

Cada missão concluída aproxima você do universo real do IBM Z.

👉 https://www.ibm.com/products/z/resources/zxplore


💻 Learning COBOL Programming with VS Code

Uma excelente forma de aprender COBOL utilizando ferramentas modernas.

Ideal para quem está dando os primeiros passos.

👉 https://www.ibm.com/training/course/learning-cobol-programming-with-vscode-DL00015G


🎓 IBM Training

O portal oficial reúne centenas de treinamentos sobre IBM Z, LinuxONE, Inteligência Artificial, Cloud, Segurança e muito mais.

👉 https://www.ibm.com/training


🌍 IBM SkillsBuild

Além dos conhecimentos técnicos, desenvolva habilidades em comunicação, IA, dados, computação em nuvem e competências profissionais.

👉 https://skillsbuild.org


📚 IBM Developer

Tutoriais, artigos, exemplos de código e projetos produzidos por especialistas.

Excelente para aprofundar o aprendizado.

👉 https://developer.ibm.com


🚀 Open Mainframe Project

Conheça o lado open source do IBM Z.

Projetos como Zowe mostram como o Mainframe conversa naturalmente com ferramentas modernas.

👉 https://openmainframeproject.org


📕 IBM Redbooks

Os famosos "Livros Vermelhos" da IBM.

São verdadeiras enciclopédias técnicas escritas por especialistas.

👉 https://www.redbooks.ibm.com


O Caminho do Programador COBOL Padawan

Ao longo desta série utilizamos uma metáfora inspirada em Jornada nas Estrelas.

Ela não serve apenas para tornar a leitura mais divertida.

Ela ajuda a entender que aprender tecnologia é semelhante a uma missão espacial.

Primeiro você conhece a nave.

Depois aprende os sistemas.

Então pratica.

Comete erros.

Resolve problemas.

Compartilha descobertas.

Até perceber que já não é mais um cadete.

Esse processo não acontece da noite para o dia.

E isso é perfeitamente normal.


A Jornada do Herói

Toda grande história segue um padrão conhecido como Jornada do Herói.

O protagonista recebe um chamado.

Enfrenta desafios.

Encontra mentores.

Aprende novas habilidades.

Supera obstáculos.

E retorna transformado.

Talvez você não tenha percebido.

Mas sua carreira também segue esse roteiro.

O chamado pode ter sido um vídeo sobre COBOL.

Um artigo.

Um workshop.

Ou até uma simples curiosidade.

Agora você já encontrou seus primeiros mentores.

Os cursos.

A comunidade.

Os profissionais que compartilham conhecimento.

O próximo passo depende apenas de você.


Não Estude Apenas Tecnologia

Grandes profissionais não entendem apenas linguagens.

Eles entendem pessoas.

Negócios.

Processos.

Comunicação.

É por isso que habilidades como:

  • trabalho em equipe;

  • curiosidade;

  • organização;

  • pensamento analítico;

  • capacidade de aprender continuamente;

fazem tanta diferença quanto conhecer comandos.

A tecnologia muda.

Os princípios permanecem.


Aprenda Compartilhando

Existe um segredo conhecido por praticamente todos os grandes instrutores.

Quem ensina aprende duas vezes.

Escreva pequenos artigos.

Explique aquilo que acabou de estudar.

Monte exemplos.

Ajude iniciantes.

Participe de comunidades.

Você ficará surpreso ao perceber o quanto isso acelera sua própria evolução.


A Missão Nunca Termina

No universo Star Trek, cada nova missão leva a outra descoberta.

No Mainframe acontece exatamente o mesmo.

Depois de COBOL vêm Db2, CICS e IMS.

Depois chegam APIs, Git, DevOps, Zowe, observabilidade, segurança, automação e Inteligência Artificial.

É justamente essa evolução constante que torna a carreira tão interessante.

Sempre haverá algo novo para aprender.

Sempre existirá um desafio diferente.

Sempre haverá uma nova fronteira.


O Convite

Talvez você esteja lendo este artigo sem nunca ter aberto um terminal 3270.

Talvez ainda ache que Mainframe é um assunto distante.

Mas lembre-se: praticamente todo especialista começou exatamente assim.

Sem experiência.

Sem respostas.

Com muitas dúvidas.

A diferença é que decidiram continuar aprendendo.

Hoje, você tem acesso a cursos gratuitos, documentação oficial, laboratórios, comunidades e especialistas dispostos a compartilhar conhecimento.

Nunca foi tão fácil embarcar nessa viagem.


Vida Longa e Próspera para sua Carreira

Quando a USS Enterprise inicia uma nova missão, ninguém sabe exatamente o que encontrará pelo caminho.

Mas todos compartilham a mesma convicção: explorar o desconhecido vale a pena.

Aprender IBM Mainframe é muito parecido.

Você descobrirá um universo de tecnologias que sustentam bancos, hospitais, governos, companhias aéreas, seguradoras e empresas espalhadas por todo o planeta.

Mais do que aprender COBOL, você aprenderá como sistemas críticos permanecem confiáveis por décadas, como bilhões de transações são processadas diariamente e como tradição e inovação podem caminhar lado a lado.

Se esta série despertou sua curiosidade, aceite o convite.

Prepare seu café.

Abra seu primeiro curso.

Escreva seu primeiro programa.

Execute seu primeiro JCL.

Conquiste seu primeiro badge.

E dê o primeiro passo rumo a uma carreira que continua conectando passado, presente e futuro da computação.

Porque, no fim das contas, a maior descoberta não está nas estrelas.

Ela está na pessoa que você se tornará durante a viagem.

Vida longa, próspera... e bons estudos, futuro tripulante do IBM Z! 🖖☕


📚 Índice da Série — Da Academia da Frota Estelar ao IBM Z

Bem-vindo à sua primeira missão no universo IBM Mainframe!

Esta série foi criada para servir como um guia completo para iniciantes, utilizando uma linguagem acessível, exemplos práticos e analogias inspiradas em Jornada nas Estrelas. A ideia é mostrar que aprender Mainframe não significa decorar comandos, mas compreender um ecossistema tecnológico que continua movendo bancos, seguradoras, governos e grandes empresas ao redor do mundo.

Cada parte representa uma nova etapa da sua evolução como Programador COBOL Padawan, preparando você para assumir missões cada vez mais complexas no universo IBM Z.

🚀 Parte I — Os Primeiros Passos do Programador COBOL Padawan na Academia da Frota Estelar

Sua jornada começa aqui.

Conheça o universo IBM Mainframe, descubra por que essa tecnologia continua indispensável e explore os melhores cursos gratuitos da IBM para iniciar seus estudos, como IBM Z Mainframe Skills Depot, IBM Z Xplore, IBM Training e SkillsBuild.

Você aprenderá:

  • O que é IBM Mainframe

  • Por que aprender IBM Z

  • Como estudar gratuitamente

  • Primeiros passos para quem nunca viu um Mainframe


🖥️ Parte IIA — Conhecendo o Coração do IBM Z

Depois de entrar na Academia, chegou a hora de conhecer os sistemas fundamentais da plataforma.

Nesta etapa você entenderá como funcionam:

  • COBOL

  • JCL

  • z/OS

  • TSO/ISPF

  • QSAM

  • VSAM

São os componentes que formam a base de praticamente qualquer aplicação corporativa desenvolvida no IBM Z.

https://eljefemidnightlunch.blogspot.com/2022/02/quer-comecar-uma-carreira-em-ibm.html


🌐 Parte IIB — A Ponte de Comando da Enterprise

Agora é hora de subir para a ponte de comando.

Você conhecerá as tecnologias responsáveis pelas aplicações corporativas modernas:

  • Db2

  • SQL

  • CICS

  • IMS

  • RACF

  • APIs REST

  • z/OS Connect

  • Git

  • DevOps

  • Zowe

  • Modernização do IBM Z

Aqui você descobrirá como aplicações escritas há décadas continuam conversando com Cloud, Inteligência Artificial, microsserviços e aplicativos móveis.

https://eljefemidnightlunch.blogspot.com/2022/03/quer-comecar-uma-carreira-em-ibm.html


⭐ Parte III — Da Academia da Frota Estelar ao Convés da USS Enterprise

Toda grande jornada termina... iniciando outra.

Nesta última parte você encontrará um roteiro completo para transformar conhecimento em carreira.

Entre os assuntos abordados estão:

  • Plano de estudos

  • Como montar um portfólio

  • Badges IBM

  • Comunidades

  • Documentação oficial

  • Dicas para entrevistas

  • Evolução profissional

  • Como continuar aprendendo durante toda a carreira

É o momento em que o Padawan deixa de ser aluno e começa a construir sua própria história no universo IBM Z.

https://eljefemidnightlunch.blogspot.com/2022/04/quer-comecar-uma-carreira-em-ibm.html


☕ Continue Explorando

Assim como a USS Enterprise sempre segue em direção a uma nova fronteira, o aprendizado em Mainframe nunca termina.

Ao concluir esta série, recomendamos aprofundar seus estudos nos seguintes temas:

  • Workload Manager (WLM)

  • RMF e SMF

  • RACF Avançado

  • MQ

  • z/OS Connect

  • Ansible para IBM Z

  • Zowe CLI

  • DevOps

  • CI/CD

  • Docker e Kubernetes aplicados ao Mainframe

  • Linux on IBM Z

  • Inteligência Artificial com IBM watsonx

  • Observabilidade

  • Performance

  • Resiliência

  • Segurança Corporativa

O IBM Mainframe continua evoluindo e incorporando novas tecnologias sem abrir mão da confiabilidade que o tornou referência mundial.

Agora é a sua vez de embarcar nessa missão.

Pegue seu café, abra seu primeiro curso, escreva seu primeiro programa COBOL e comece sua própria Jornada do Herói rumo às estrelas.

Vida longa e próspera, futuro tripulante do IBM Z! 🖖




----------------------------------------

terça-feira, 24 de maio de 2022

Da Compilação à Execução de um Programa COBOL

 

Bellacosa Mainframe e a compilaçao de um programa cobol

☕ Um Café no Bellacosa Mainframe

Da Compilação à Execução de um Programa COBOL

A jornada completa do código-fonte até a CPU do IBM Z

Para quem está começando no universo mainframe, compilar um programa COBOL pode parecer uma tarefa simples:

Escrever o código
Compilar
Executar

Mas, no IBM Z, existe uma verdadeira cadeia industrial entre a primeira linha do fonte e o momento em que uma CPU começa a executar as instruções do programa.

O código pode depender de copybooks, comandos CICS, instruções SQL, chamadas IMS, interfaces Adabas, arquivos QSAM, clusters VSAM, bibliotecas de carga, JCL, JES2, Language Environment, memória e vários componentes do z/OS.

Por isso, dizer que um programa foi apenas “compilado e executado” é como afirmar que um avião simplesmente saiu do papel e começou a voar.

Entre o projeto e o voo existem dezenas de etapas.

Esta série em quatro capítulos foi criada para mostrar essa jornada completa de maneira progressiva, sempre pensando no Programador COBOL Padawan que deseja compreender não apenas como escrever código, mas como o mainframe realmente pensa.


O grande mapa da jornada

Antes de conhecer cada capítulo, observe o fluxo completo:

Regra de negócio
       ↓
Código-fonte COBOL
       ↓
Copybooks
       ↓
Tradução CICS
       ↓
Processamento Db2
       ↓
Interfaces IMS e Adabas
       ↓
Compilação
       ↓
Código objeto
       ↓
Binder
       ↓
Load module
       ↓
Load library
       ↓
JCL ou transação
       ↓
JES2 ou subsistema online
       ↓
Loader
       ↓
Memória
       ↓
Dispatcher
       ↓
CPU
       ↓
Dados, relatórios e resultados

Cada etapa possui uma responsabilidade específica.

Quando uma delas falha, o problema pode aparecer como:

  • erro de compilação;

  • erro de linkedição;

  • package Db2 inválido;

  • programa não encontrado;

  • arquivo ausente;

  • FILE STATUS;

  • SQLCODE;

  • erro CICS;

  • status IMS;

  • response code Adabas;

  • return code;

  • abend.

A melhor forma de investigar qualquer problema é descobrir em qual parte dessa cadeia ele ocorreu.


Parte I — O nascimento do programa COBOL

Código-fonte, bibliotecas e copybooks

O primeiro capítulo apresenta o ponto de partida: o código-fonte COBOL.

É nele que o programador transforma uma regra de negócio em instruções como:

MOVE
COMPUTE
PERFORM
READ
WRITE
CALL

Porém, o programa raramente vive sozinho.

Muitas aplicações utilizam copybooks para compartilhar:

  • layouts de arquivos;

  • registros;

  • áreas de comunicação;

  • constantes;

  • códigos de retorno;

  • estruturas de mensagens;

  • campos de tabelas;

  • contratos entre programas.

Um programa pode conter:

       COPY CPYCLI01.

Durante o processo de compilação, o conteúdo desse copybook é incorporado logicamente ao fonte.

O capítulo também explica uma diferença fundamental:

COPY inclui fonte.
CALL executa outro programa.

Essa distinção é importante porque um copybook não é um módulo executável.

Ele é uma estrutura reutilizável inserida no programa durante sua preparação.

Outro ponto central é que o copybook funciona como um contrato.

Se dois programas compartilham uma área de memória, ambos precisam interpretar exatamente o mesmo layout.

Uma alteração feita sem análise de impacto pode provocar:

  • campos deslocados;

  • valores incorretos;

  • erros numéricos;

  • corrupção de dados;

  • abends;

  • falhas silenciosas.

A primeira parte também mostra como o compilador localiza copybooks por meio de bibliotecas associadas a DD statements como SYSLIB.

A ordem dessas bibliotecas pode determinar qual versão do copybook será utilizada.

Isso significa que até mesmo uma compilação com retorno zero pode gerar um programa incorreto caso tenha utilizado uma versão inadequada de determinada estrutura.

Leia a Parte I

https://eljefemidnightlunch.blogspot.com/2022/01/da-compilacao-execucao-de-um-programa.html


Parte II — CICS, Db2, IMS e Adabas

O que acontece antes da compilação

O segundo capítulo mostra que nem tudo o que aparece dentro de um programa COBOL pertence diretamente à linguagem.

Comandos como:

           EXEC CICS
                READ FILE('CLIENTES')
           END-EXEC.

ou:

           EXEC SQL
                SELECT NOME
                  INTO :WS-NOME
                  FROM CLIENTES
           END-EXEC.

precisam ser processados por componentes especializados.

CICS

Os comandos EXEC CICS são interpretados pelo tradutor CICS.

O fluxo conceitual é:

Fonte COBOL com EXEC CICS
             ↓
Tradutor CICS
             ↓
Fonte COBOL preparado
             ↓
Compilador

O programa pede ao CICS que execute serviços como:

  • leitura de arquivos;

  • envio e recebimento de mapas;

  • acesso a filas;

  • chamada de programas;

  • controle de transações;

  • sincronização;

  • gerenciamento de recursos.

O COBOL contém a regra de negócio.

O CICS administra o ambiente transacional.

Db2

Comandos EXEC SQL precisam ser processados pelo pré-compilador Db2 ou por um coprocessador integrado.

Esse processamento pode gerar:

Fonte COBOL preparado
DBRM

O fonte segue para o compilador.

O DBRM segue para o BIND do Db2.

Esse BIND cria um package com as instruções SQL preparadas.

O capítulo esclarece uma confusão frequente:

Binder do z/OS cria o executável.
BIND do Db2 cria o package SQL.

São processos diferentes.

IMS

Programas COBOL podem acessar bancos hierárquicos e mensagens IMS por meio de chamadas DL/I.

Entre as funções comuns estão:

GU
GN
GNP
ISRT
REPL
DLET

O ambiente também utiliza estruturas como:

  • DBD;

  • PSB;

  • PCB;

  • SSA;

  • layouts de segmentos.

Adabas

O acesso ao Adabas pode envolver:

  • control blocks;

  • format buffers;

  • record buffers;

  • search buffers;

  • value buffers;

  • interfaces de chamada;

  • response codes.

Apesar de suas diferenças, CICS, Db2, IMS e Adabas compartilham o mesmo princípio:

O programa COBOL executa a regra de negócio e solicita serviços a subsistemas especializados.

Leia a Parte II

https://eljefemidnightlunch.blogspot.com/2022/02/da-compilacao-execucao-de-um-programa.html


Parte III — Compilação, linkedição e load library

Como o fonte se transforma em executável

O terceiro capítulo entra no coração técnico da transformação.

Depois que o fonte foi preparado, o compilador COBOL entra em cena.

Seu trabalho não se limita a trocar comandos por instruções de máquina.

Ele também analisa:

  • sintaxe;

  • campos;

  • tipos de dados;

  • tamanhos;

  • parágrafos;

  • referências;

  • opções;

  • arquivos;

  • copybooks;

  • expressões;

  • compatibilidade;

  • oportunidades de otimização.

O resultado principal é o código objeto.

Fonte COBOL
      ↓
Compilador
      ↓
Código objeto

Porém, o código objeto ainda pode possuir referências não resolvidas.

Um programa pode chamar:

           CALL 'PGMVALID'
                USING AREA-DADOS.

Se essa chamada precisar ser resolvida antecipadamente, será necessário localizar o módulo correspondente durante a linkedição.

O Binder

O Binder do z/OS reúne:

  • código objeto;

  • rotinas;

  • interfaces;

  • módulos externos;

  • pontos de entrada;

  • componentes de runtime.

O resultado é o módulo executável.

Código objeto
      +
Dependências
      ↓
Binder
      ↓
Load module ou program object

Esse executável é gravado em uma biblioteca como:

EMPRESA.SISTEMA.LOADLIB(PGMCLI01)

Chamadas estáticas e dinâmicas

O capítulo também explica a diferença entre chamadas estáticas e dinâmicas.

Estática

A dependência é resolvida durante a linkedição.

Dinâmica

O módulo é procurado durante a execução.

Essa escolha afeta:

  • implantação;

  • tamanho do executável;

  • manutenção;

  • versionamento;

  • risco de programa não encontrado;

  • necessidade de relinkedição.

Return codes

Compilador e Binder produzem mensagens e return codes.

Um RC=0 indica que a etapa terminou normalmente, mas não prova que a lógica está correta.

Um RC=4 pode conter warnings importantes.

Um erro de linkedição pode indicar:

  • símbolo não resolvido;

  • módulo ausente;

  • biblioteca errada;

  • ponto de entrada incorreto;

  • interface incompatível.

O capítulo reforça uma lição essencial:

Programa compilado não significa programa testado.

Leia a Parte III

https://eljefemidnightlunch.blogspot.com/2022/03/da-compilacao-execucao-de-um-programa.html


Parte IV — Da load library à CPU

JCL, JES2, QSAM, VSAM, memória e processamento

O quarto capítulo acompanha o executável durante a execução real.

Depois da linkedição, o programa está pronto, mas ainda permanece parado em uma load library.

No ambiente batch, o JCL solicita sua execução:

//STEP01 EXEC PGM=PGMCLI01

Uma STEPLIB pode informar onde o módulo deve ser procurado:

//STEPLIB DD DISP=SHR,
//           DSN=EMPRESA.SISTEMA.LOADLIB

Se o módulo não for encontrado, pode ocorrer um erro como S806.

QSAM

Programas que acessam arquivos sequenciais podem utilizar QSAM.

No COBOL:

ASSIGN TO CLIENTES

No JCL:

//CLIENTES DD DISP=SHR,
//            DSN=EMPRESA.DADOS.CLIENTES

A ligação é:

Nome lógico COBOL
       ↓
DDNAME
       ↓
Dataset físico

VSAM

VSAM oferece organizações como:

  • KSDS;

  • ESDS;

  • RRDS;

  • LDS;

  • VRRDS.

Um KSDS pode ser acessado por chave e também de forma sequencial.

O programa precisa verificar o FILE STATUS depois das operações.

Retornos como 00, 10, 22, 23, 35 e 39 possuem significados diferentes conforme a operação e o contexto.

JES2

O JES2 administra o fluxo batch.

Ele:

  • recebe o job;

  • mantém filas;

  • utiliza o spool;

  • organiza classes;

  • administra saídas;

  • acompanha o processamento.

O JES2 não executa diretamente as instruções COBOL.

O fluxo correto é mais próximo de:

JES2 administra o job
Initiator inicia o step
z/OS prepara o ambiente
Loader carrega o módulo
Dispatcher entrega processador
CPU executa as instruções

Memória e CPU

O programa é carregado em um address space.

O Language Environment prepara o runtime.

O dispatcher distribui capacidade de processamento.

O WLM ajuda a priorizar workloads conforme objetivos de serviço.

A CPU não executa comandos COBOL como:

MOVE
READ
PERFORM
COMPUTE

Ela executa as instruções de máquina produzidas pelo compilador.

O capítulo também explica a diferença entre:

Tempo de CPU
Tempo decorrido

Um job pode permanecer dez minutos em execução e consumir apenas alguns segundos de CPU.

O restante pode ser espera por:

  • arquivos;

  • Db2;

  • IMS;

  • Adabas;

  • locks;

  • filas;

  • mensagens;

  • armazenamento;

  • rede.

Leia a Parte IV

https://eljefemidnightlunch.blogspot.com/2022/04/da-compilacao-execucao-de-um-programa.html


O que o Padawan aprende com a série

Ao concluir os quatro capítulos, o iniciante passa a compreender que um programa COBOL não é apenas um membro dentro de uma biblioteca.

Ele faz parte de uma cadeia maior.

Fonte
Copybook
Tradutor
Pré-compilador
Compilador
Objeto
Binder
Load
Package
JCL
JES2
Spool
Loader
Memória
CPU
Dados
Resultado

Essa visão permite investigar problemas com muito mais precisão.

Em vez de dizer:

“O programa não funciona”,

o profissional começa a perguntar:

  • O fonte correto foi compilado?

  • O copybook correto foi utilizado?

  • O CICS traduziu os comandos?

  • O DBRM foi gerado?

  • O package Db2 foi criado?

  • O Binder resolveu todas as referências?

  • O load foi gravado na biblioteca correta?

  • A STEPLIB aponta para essa biblioteca?

  • O DDNAME corresponde ao ASSIGN TO?

  • O dataset existe?

  • O FILE STATUS foi tratado?

  • O SQLCODE foi verificado?

  • O programa terminou com return code ou abend?

  • O tempo foi gasto em CPU ou em espera?

Essas perguntas transformam uma investigação baseada em tentativa e erro em um diagnóstico técnico estruturado.


A diferença entre escrever COBOL e entender o mainframe

Escrever COBOL é uma habilidade importante.

Mas compreender o ciclo completo de construção e execução é o que permite ao profissional atuar com segurança em ambientes corporativos.

O programador que conhece apenas o fonte pode corrigir uma linha.

O profissional que conhece o ecossistema consegue compreender:

  • por que uma alteração não chegou ao ambiente;

  • por que o programa antigo continua executando;

  • por que um package está incompatível;

  • por que o arquivo não abriu;

  • por que o job está aguardando;

  • por que o tempo decorrido aumentou;

  • por que a CPU não é a causa da lentidão;

  • por que uma recompilação em massa foi necessária;

  • por que um copybook deve ser tratado como contrato.

Esse é o verdadeiro objetivo da série.

Não ensinar apenas comandos.

Ensinar a enxergar o sistema completo.


Leia a série completa

Parte I

O Nascimento do Programa COBOL: Código-fonte e Copybooks

Parte II

CICS, Db2, IMS e Adabas: O Código Antes da Compilação

Parte III

Compilação, Linkedição e Load Library

Parte IV

Da Load Library à CPU: JCL, JES2, QSAM, VSAM e Execução


Conclusão

A jornada de um programa COBOL começa muito antes da execução.

Ela nasce na regra de negócio.

Ganha forma no código-fonte.

Reutiliza estruturas por meio de copybooks.

Conversa com CICS, Db2, IMS e Adabas.

É analisada pelo compilador.

Transforma-se em código objeto.

É reunida pelo Binder.

Torna-se um módulo executável.

É armazenada em uma load library.

Depois, um JCL, uma transação ou um subsistema solicita sua execução.

O JES2 administra o job.

O initiator inicia os steps.

O loader coloca o programa em memória.

O z/OS gerencia recursos.

O WLM orienta prioridades.

O dispatcher entrega capacidade de processamento.

A CPU executa as instruções.

QSAM, VSAM, Db2, IMS, CICS e Adabas fornecem os dados e serviços necessários.

Por fim, o programa produz relatórios, atualizações, mensagens, arquivos e resultados de negócio.

Nada simplesmente “roda”.

Tudo é preparado, ligado, controlado, carregado, executado e registrado.

“O Padawan observa o código-fonte. O especialista acompanha toda a jornada, desde o primeiro COPY até o último ciclo de CPU.”

 

Laboratório Forense Bellacosa Mainframe

CSI z/OS: Da Compilação à Execução de um Programa COBOL

Cinco arquivos de evidências revelam como o código-fonte COBOL atravessa copybooks, CICS, Db2, IMS, compilação, Binder, load library, JCL, JES2, memória e CPU até produzir um resultado no IBM Z.

CASO: COBOL-2022-EXEC EVIDÊNCIAS: 05 ARTIGOS AMBIENTE: IBM Z / z/OS STATUS: ARQUIVO ABERTO

Esta investigação técnica apresenta o ciclo completo de um programa COBOL no mainframe IBM Z. A série explica o nascimento do código-fonte, o uso de copybooks, a preparação de comandos CICS e SQL, a geração de código objeto, a atuação do Binder, o armazenamento em load libraries e a execução por JCL, JES2, loader, Language Environment, dispatcher e CPU. Selecione uma evidência abaixo para ler o artigo correspondente dentro do visualizador.

Evidência selecionada Parte I — Código-fonte, bibliotecas e copybooks
Processando evidência digital...

Laudo preliminar: o nascimento do programa

A primeira parte acompanha a transformação da regra de negócio em código-fonte COBOL, explica o papel das bibliotecas e mostra por que copybooks funcionam como contratos de dados compartilhados entre programas.

COBOL código-fonte copybook SYSLIB IBM Z
Bellacosa Mainframe Forensic Lab · Nenhum byte é inocente até que os logs provem o contrário.

segunda-feira, 23 de maio de 2022

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

 

Bellacosa Mainframe ci cd em devops sem misterios



☕ Um Café no Bellacosa Mainframe

DevOps sem Mistérios para Programadores COBOL

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

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


Antes de tudo...

Imagine um banco.

Todos os dias existem milhares de programas COBOL sendo alterados.

Imagine fazer isso manualmente.

Editar.

Compilar.

Gerar Load Module.

Fazer BIND.

Atualizar CICS.

Liberar produção.

Executar testes.

Se cada desenvolvedor fizesse isso do seu jeito...

...o banco pararia em poucas horas.

Foi exatamente para resolver esse problema que nasceu o DevOps.

Não para Cloud.

Não para Containers.

Mas para organizar o desenvolvimento.


1 — CI/CD

A imagem mostra:

Código

↓

Build

↓

Testes

↓

Deploy

Parece moderno.

Mas vamos traduzir.

No Mainframe seria algo parecido com:

Editar COBOL

↓

Compile

↓

Link Edit

↓

BIND DB2

↓

Newcopy CICS

↓

Testes

↓

Produção

Percebe?

É praticamente igual.

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


O que significa CI?

Continuous Integration.

Integração Contínua.

Na prática:

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

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

Imagine cinco programadores.

Cada um altera um programa.

Antigamente:

João altera.

Maria altera.

José altera.

Carlos altera.

Tudo junta sexta-feira.

Sexta-feira...

Nada compila.

Ninguém sabe quem quebrou.

Hoje:

Commit

↓

Compile automático

↓

Teste automático

↓

Se falhar...

ninguém faz Merge.

Muito mais seguro.


No Mainframe

Imagine ISPW.

Imagine Endevor.

Imagine Changeman.

Quando você promove um componente...

Já existe uma pipeline.

Hoje ela apenas ficou mais inteligente.


2 — Container

Essa talvez seja a palavra mais mal compreendida.

Todo mundo fala:

"Container."

Mas...

O que é?

Imagine que você escreveu um programa COBOL.

Ele precisa:

  • Enterprise COBOL

  • LE Runtime

  • Db2 Client

  • MQ

  • Bibliotecas

  • Configuração

  • Certificados

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

Não funciona.

O Container resolve exatamente isso.

Ele empacota tudo.

Programa

+

Bibliotecas

+

Dependências

+

Configuração

+

Runtime

Tudo vira um único pacote.


Analogia Mainframe

Imagine um LOADLIB completo.

Ou uma STEPLIB preparada.

Você leva exatamente o ambiente necessário.

O Container faz isso para Linux.


Por que isso é importante?

Porque elimina:

"Na minha máquina funciona."

Essa frase praticamente desaparece.


3 — Kubernetes

A imagem chama Kubernetes de controlador de tráfego.

Gostei dessa definição.

Imagine um banco.

Existem:

Servidor A

Servidor B

Servidor C

Servidor D

Se um servidor morrer?

Quem percebe?

Quem cria outro?

Quem redistribui usuários?

Quem balanceia carga?

No mundo Cloud:

Kubernetes.


No Mainframe...

Quem faz isso?

Vários componentes.

WLM.

Sysplex.

Coupling Facility.

Dynamic Routing do CICS.

VIPA.

Parallel Sysplex.

Na prática...

IBM resolveu isso muito antes.

Só usou outros nomes.


O Kubernetes faz:

  • escala

  • reinicia

  • monitora

  • distribui

  • atualiza

Tudo sozinho.


4 — Infrastructure as Code (IaC)

Essa talvez seja a maior revolução.

Imagine instalar um servidor manualmente.

Clique.

Clique.

Clique.

Próximo.

Avançar.

OK.

Agora imagine repetir isso cem vezes.

Impossível.

Então surgiu:

Infrastructure as Code.

Em vez de clicar...

Você escreve.

Exemplo simplificado:

Servidor:

Linux

8 CPUs

32 GB

Porta 443

Firewall ativo

Rede privada

Pronto.

Um script cria tudo.


No mundo IBM Z

Isso lembra muito:

JCL.

Pense nisso.

JCL descreve infraestrutura.

Quero executar

este programa

com esta memória

este dataset

esta região

estas bibliotecas

Na essência...

JCL já era Infrastructure as Code.

Décadas antes do termo existir.


5 — Pipeline

Pipeline é uma linha de produção.

Literalmente.

A imagem mostra:

Código

Build

Teste

Scan

Deploy


No banco isso pode virar:

Developer

↓

Git

↓

Compile COBOL

↓

Compile Copybooks

↓

SQL Precompiler

↓

DBRM

↓

Bind

↓

Unit Test

↓

SonarQube

↓

Deploy QA

↓

Deploy Homologação

↓

Deploy Produção

Tudo automático.


Ferramentas comuns

GitHub Actions

GitLab CI

Azure DevOps

Jenkins

Tekton

ArgoCD

UrbanCode Deploy

ISPW

Endevor


6 — Monitoring

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

Acabou?

Muito pelo contrário.

Começa o trabalho.

Monitoramento significa responder perguntas como:

CPU está alta?

Memória?

Tempo de resposta?

Fila MQ?

Db2?

CICS?

VSAM?

JES2?

SMF?


No IBM Z

Você já conhece muitos monitores.

RMF

OMEGAMON

SMF

SDSF

NetView

Tivoli

Z APM

Instana

Todos fazem exatamente isso.


Sem monitoramento...

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


7 — Configuration Management

Esse conceito nasceu porque administradores faziam mudanças manualmente.

Servidor 1:

Java 17

Servidor 2:

Java 11

Servidor 3:

Java 21

Resultado?

Caos.

Ferramentas como:

Ansible

Chef

Puppet

SaltStack

garantem que todos fiquem iguais.


Analogia Mainframe

Pense em PROCLIB.

PARMLIB.

IEASYSxx.

JES2PARM.

RACF.

Tudo precisa permanecer consistente.

A diferença é que hoje isso é automatizado.


8 — CI/CD novamente

A oitava imagem aprofunda o assunto.

Vale destacar uma diferença importante.

Continuous Integration

Sempre compila.

Sempre testa.

Sempre valida.

Mas nem sempre publica.


Continuous Delivery

Tudo pronto.

Apenas alguém aperta:

Deploy.


Continuous Deployment

Nem isso.

Terminou os testes?

Produção automaticamente.


Bancos normalmente fazem:

CI

+

Continuous Delivery

Poucos usam Continuous Deployment completo.

Por razões regulatórias.


9 — IaC novamente

Agora aparecem ferramentas.

Terraform.

CloudFormation.

Pulumi.

Ansible.


Para um programador COBOL

A ideia é simples.

Você não administra servidores.

Você administra código que administra servidores.

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


10 — DevOps Culture

Essa é provavelmente a imagem mais importante.

Porque DevOps NÃO é ferramenta.

É cultura.

Imagine:

Desenvolvimento culpa Infraestrutura.

Infraestrutura culpa Banco.

Banco culpa Segurança.

Segurança culpa Rede.

Rede culpa Middleware.

Middleware culpa COBOL.

COBOL culpa CICS.

CICS culpa Db2.

Resultado?

Ninguém resolve.

DevOps diz:

Todos são responsáveis.


O objetivo

Eliminar silos.

Criar colaboração.

Automatizar tarefas repetitivas.

Aprender continuamente.

Compartilhar conhecimento.


O que muda para um Programador COBOL Padawan?

Antigamente bastava dominar:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

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

  • Git e GitHub

  • GitFlow e Pull Requests

  • Jenkins, GitHub Actions ou Azure DevOps

  • UrbanCode Deploy ou ISPW Pipelines

  • SonarQube para análise estática

  • Docker e conceitos de Containers (mesmo que não execute COBOL dentro deles)

  • Kubernetes e OpenShift para entender onde vivem as APIs modernas

  • Ansible para automação de tarefas no z/OS

  • APIs REST e JSON

  • z/OS Connect Enterprise Edition

  • Observabilidade com Instana, OMEGAMON e OpenTelemetry

  • Segurança integrada com RACF, certificados digitais, OAuth2, JWT e TLS

  • Integração contínua de aplicações COBOL com pipelines automatizadas


A Grande Lição do Mestre

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

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

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





domingo, 22 de maio de 2022

Yuusha, Yamemasu — Muito Além do "Herói Aposentado"

Bellacosa Mainframe apresenta yuusha yamemasu

☕ Um Café no Bellacosa Mainframe

Yuusha, Yamemasu — Muito Além do "Herói Aposentado"

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Liderança, Sistemas Legados, Inteligência Artificial, Propósito e Como um Anime de Fantasia Ensina Lições que Valem para IBM Z, DevOps e Engenharia de Software

"Todo sistema nasce para resolver um problema. O verdadeiro desafio começa quando o problema desaparece, mas o sistema continua existindo."


Ficha Técnica

Título original

勇者、辞めます ~次の職場は魔王城~
(Yūsha, Yamemasu: Tsugi no Shokuba wa Maōjō)

Título internacional

I'm Quitting Heroing

Autor (Light Novel)

Quantum

Ilustrações

Hana Amano

Mangá

Nori Kazato

Estúdio de animação

EMT Squared

Diretor

Hisashi Ishii

Diretor-chefe

Yuu Nobuta

Roteiro

Shigeru Murakoshi

Trilha sonora

Kōhei Munemoto

Exibição original

  • 5 de abril de 2022

  • 21 de junho de 2022

Quantidade de episódios

  • 12 episódios

  • 2 OVAs lançadas posteriormente

Gênero

  • Fantasia

  • Aventura

  • Comédia

  • Drama

  • Filosofia

  • Ficção científica (em sua essência)

Classificação indicativa

  • Aproximadamente 14 anos (TV-14)


Sinopse

Durante séculos, o lendário herói Leo Demonheart foi o maior defensor da humanidade. Quando finalmente derrota a Rainha Demônio Echidna, espera ser recebido como salvador.

Mas acontece exatamente o contrário.

Com medo de seu poder, os próprios humanos passam a rejeitá-lo. Sem um propósito e sem lugar no mundo, Leo toma uma decisão improvável: oferecer seus serviços ao antigo inimigo e trabalhar para o exército demoníaco.

O que parecia uma simples comédia logo revela uma história profunda sobre liderança, identidade, propósito e o peso da imortalidade.


Resumo

A primeira temporada acompanha a chegada de Leo ao castelo de Echidna. Para conquistar a confiança dos generais demônios, ele resolve problemas de logística, treinamento, motivação, planejamento e organização.

Enquanto ajuda o reino demoníaco a se reerguer, descobrimos lentamente que Leo não é apenas um herói extremamente poderoso. Seu passado esconde uma verdade capaz de mudar completamente a forma como enxergamos sua existência.

Nos episódios finais, a narrativa deixa de ser uma fantasia convencional e se transforma em uma reflexão sobre humanidade, inteligência artificial e livre-arbítrio.


A História

À primeira vista, parece um anime de fantasia medieval.

Castelos.

Espadas.

Magia.

Demônios.

Heróis.

Mas tudo isso funciona apenas como cenário.

O verdadeiro tema da obra é a jornada de alguém criado para cumprir uma única missão e que, após concluí-la, precisa descobrir quem é sem essa missão.

A revelação de que Leo foi criado por uma civilização tecnologicamente avançada há milhares de anos muda completamente a percepção do espectador. A fantasia passa a dialogar com ficção científica, mostrando que sua força, longevidade e habilidades extraordinárias fazem parte de um projeto criado para proteger a humanidade.


Os Personagens

Leo Demonheart

O protagonista.

Extremamente inteligente, estratégico e praticamente invencível.

Mais do que um guerreiro, é um solucionador de problemas.

No estilo Bellacosa Mainframe, Leo representa um sistema legado robusto: confiável, eficiente e indispensável, mas construído para um contexto que já mudou.


Echidna

A Rainha Demônio.

Carismática, racional e profundamente preocupada com seu povo.

Apesar da imagem de vilã, demonstra qualidades de uma excelente líder.

Ela entende que liderança não significa mandar, mas inspirar.


Shutina

General responsável pelas forças militares.

Competente, disciplinada e dedicada.

Representa o profissional técnico que assume responsabilidades demais.


Edvard

Especialista em logística.

Organizado e metódico.

Sempre pensa em eficiência operacional.

É o "gerente de infraestrutura" do reino.


Mernes

Responsável pela inteligência.

Especialista em informações estratégicas.

Mostra como conhecimento pode ser mais poderoso do que força.


Lily

General da magia.

Gentil, otimista e extremamente talentosa.

Representa empatia e colaboração.


Temática

A obra aborda diversos temas:

  • Liderança

  • Gestão de pessoas

  • Burnout

  • Propósito

  • Solidão

  • Inteligência Artificial

  • Imortalidade

  • Livre-arbítrio

  • Evolução pessoal

  • Administração de organizações

  • Confiança

  • Cooperação


O Que Torna o Anime Diferente?

Grande parte dos animes de fantasia termina quando o herói derrota o Rei Demônio.

Yuusha, Yamemasu começa exatamente nesse ponto.

A pergunta deixa de ser:

"Como vencer a guerra?"

E passa a ser:

"Como reconstruir depois dela?"

Além disso, o anime substitui batalhas constantes por desafios administrativos, mostrando que liderar pessoas pode ser tão difícil quanto derrotar monstros.


As Aventuras

Ao longo da temporada, Leo ajuda cada general a superar problemas específicos:

  • reorganiza equipes;

  • melhora processos;

  • resolve gargalos logísticos;

  • otimiza treinamento militar;

  • aumenta a motivação dos soldados;

  • cria estratégias mais eficientes;

  • fortalece a confiança entre líderes.

Cada episódio funciona como um estudo de caso sobre resolução de problemas.


As Mensagens Ocultas

O verdadeiro inimigo pode ser a falta de propósito

Leo descobre que vencer não significa encontrar felicidade.


Liderança é desenvolver pessoas

Em vez de resolver tudo sozinho, Leo ensina os outros a crescer.


Organizações sobrevivem graças aos processos

Mesmo indivíduos brilhantes não conseguem sustentar uma organização sem estrutura.


Poder exige responsabilidade

Quanto maior a capacidade de alguém, maior sua responsabilidade em decidir como utilizá-la.


Evoluir é mais importante do que permanecer perfeito

Leo percebe que seguir eternamente a mesma programação não faz sentido quando o mundo muda.


Bellacosa Mainframe: A Grande Analogia

Imagine um programa COBOL escrito há quarenta anos.

Ele foi criado para resolver um problema específico.

Funcionou perfeitamente durante décadas.

Mas o negócio mudou.

As regras mudaram.

Os clientes mudaram.

Mesmo assim, o programa continua executando exatamente a mesma lógica.

Leo Demonheart representa esse sistema legado.

Não porque esteja ultrapassado.

Mas porque continua executando sua missão original sem questionar se ela ainda faz sentido.

Modernizar um sistema não significa descartá-lo.

Significa permitir que ele evolua.

É exatamente a jornada de Leo.


O Que Todo Programador COBOL Padawan Aprende com Yuusha, Yamemasu

  • Resolver problemas é mais importante do que demonstrar poder.

  • Sistemas robustos precisam evoluir junto com o negócio.

  • Documentação, processos e treinamento são fundamentais.

  • Grandes líderes criam sucessores.

  • Tecnologia sem propósito perde valor.

  • Modernização deve preservar o que funciona e transformar o que limita.


Impacto Cultural

Embora não tenha alcançado o sucesso comercial de franquias como Overlord, Re:Zero ou Tate no Yuusha no Nariagari, Yuusha, Yamemasu conquistou uma base fiel de fãs por oferecer uma narrativa madura, focada em reconstrução, liderança e identidade.

A obra é frequentemente lembrada por sua reviravolta narrativa nos episódios finais, que transforma uma aparente fantasia medieval em uma história com elementos de ficção científica e reflexões sobre inteligência artificial, memória e propósito. Esse contraste tornou o anime um exemplo de como subverter expectativas sem depender apenas de cenas de ação.


Classificação Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ (10/10)
Originalidade⭐⭐⭐⭐⭐
Desenvolvimento dos personagens⭐⭐⭐⭐⭐
Filosofia⭐⭐⭐⭐⭐
Liderança e gestão⭐⭐⭐⭐⭐
Humor⭐⭐⭐⭐☆
Ação⭐⭐⭐⭐☆
Trilha sonora⭐⭐⭐⭐☆
Reviravoltas⭐⭐⭐⭐⭐

Veredito Final

Yuusha, Yamemasu é muito mais do que um anime sobre um herói desempregado. É uma aula sobre adaptação, liderança e evolução contínua.

No universo do Bellacosa Mainframe, Leo Demonheart simboliza um sistema IBM Z de missão crítica: extremamente confiável, resiliente e poderoso. Porém, assim como aplicações COBOL que atravessam décadas, seu verdadeiro desafio não é continuar funcionando, e sim adaptar-se a novas necessidades sem perder sua essência.

A grande lição da primeira temporada é clara: vencer uma batalha é importante, mas construir um futuro sustentável — para pessoas, organizações ou sistemas — é o que realmente define um herói.

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