Translate

sexta-feira, 3 de julho de 2026

Capítulo 3 — O Professor que Arquivou o Funeral

Bellacosa Mainframe e o professor que arquivou o Funeral

☕ Um Café no Bellacosa Mainframe

Capítulo 3 — O Professor que Arquivou o Funeral

Conheça a história de Wolfgang Spruth e descubra como sua coleção de reportagens preservou a memória das previsões sobre a morte do mainframe, transformando-as em um importante documento histórico da computação moderna.

Por


Wolfgang Spruth preservando a história das previsões sobre a morte do Mainframe

Wolfgang Spruth documentou décadas de previsões equivocadas sobre o fim do Mainframe, criando um importante registro histórico da computação.


Wolfgang Spruth e a Coleção das Manchetes que Tentaram Enterrar o Mainframe

"A História não é escrita apenas pelos vencedores. Às vezes ela também é escrita pelos analistas que erraram a previsão."

Antes de continuarmos...

Existe um personagem fundamental nesta história.

Curiosamente...

Ele não era jornalista.

Não era executivo de marketing.

Não era consultor.

Nem trabalhava tentando vender a próxima grande revolução da informática.

Era um professor.

Um pesquisador.

Um engenheiro.

Alguém que dedicou décadas da vida estudando computação corporativa.

Seu nome era Professor Wolfgang (Wilhelm G.) Spruth.

E, sem saber, ele acabaria produzindo um dos documentos históricos mais importantes sobre a evolução do IBM Mainframe.

Quem foi Wolfgang Spruth?

Para quem trabalha com IBM Z, principalmente na Europa, Wolfgang Spruth dispensa apresentações.

Professor da Universidade de Tübingen, na Alemanha, Spruth foi uma das maiores autoridades mundiais em Enterprise Computing, IBM Mainframe, sistemas operacionais, bancos de dados e arquitetura corporativa.

Durante décadas pesquisou:

  • IBM System/360

  • System/370

  • ESA/390

  • S/390

  • zSeries

  • z/OS

  • CICS

  • Db2

  • Virtualização

  • Arquiteturas Corporativas

  • Grandes Centros de Processamento de Dados

Muito antes da palavra "Cloud" existir...

Spruth já estudava virtualização.

Muito antes de falarmos em IA...

Ele estudava arquitetura de sistemas.

Muito antes do DevOps...

Ele analisava integração entre aplicações corporativas.

Seu foco nunca foi seguir modismos.

Seu foco sempre foi entender como os sistemas realmente funcionavam.

E essa diferença faz toda a diferença.

Um pesquisador em vez de um torcedor

Existe algo interessante sobre pesquisadores.

Eles normalmente não torcem.

Eles observam.

Registram.

Documentam.

Comparam.

Foi exatamente isso que Spruth fez.

Enquanto boa parte da imprensa anunciava o "fim inevitável" do mainframe...

Ele resolveu guardar aquelas reportagens.

Não para zombar.

Não para ridicularizar jornalistas.

Mas para construir um registro histórico.

Porque previsões tecnológicas também fazem parte da História da Computação.

O nascimento de um documento histórico

Anos depois surgiu um pequeno documento que se tornaria extremamente famoso entre profissionais IBM.

Seu título era simples.

The Death of the Mainframe

À primeira vista parecia apenas mais uma apresentação.

Alguns slides.

Algumas citações.

Poucas páginas.

Mas havia algo extremamente inteligente naquele material.

Em vez de discutir opiniões...

Spruth simplesmente mostrou as manchetes.

Uma após outra.

Em ordem cronológica.

Como um museu.

Como um álbum de fotografias.

Como um arquivo de jornal.

Cada slide representava um momento em que alguém decretou que o IBM Mainframe havia chegado ao fim.

O leitor tirava suas próprias conclusões.

Essa simplicidade tornou o trabalho tão poderoso.

O museu dos "fins do mundo"

Imagine entrar em um museu.

Na primeira sala existe uma placa.

1989

Logo abaixo.

Uma manchete.

"O Mainframe morreu."

Você caminha alguns metros.

Outra sala.

1991

Mais uma manchete.

"O último mainframe será desligado."

Mais alguns passos.

1993

"O Mainframe está correndo para a extinção."

Depois...

Outra previsão.

E outra.

E outra.

Ao final da exposição...

Você sai do museu.

Liga o aplicativo do banco.

Faz um PIX.

Compra uma passagem aérea.

Usa um cartão de crédito.

Recebe o salário.

E percebe que boa parte dessas operações ainda continua passando por plataformas IBM Z.

É impossível não sorrir.

O maior mérito de Spruth

Talvez você espere que o professor passasse páginas e páginas criticando cada jornalista.

Não.

Esse nunca foi o objetivo.

O trabalho possui um tom quase acadêmico.

Ele apenas apresenta os fatos.

Mostra as datas.

As publicações.

As frases.

E deixa que a passagem do tempo faça o restante.

É um excelente exemplo de como a História costuma ser mais convincente do que qualquer debate.

O contexto importa

E aqui existe uma lição importante para todo Padawan COBOL.

É muito fácil rir das previsões feitas há trinta anos.

Mas precisamos lembrar do contexto.

Naquela época:

Os computadores pessoais dobravam de potência rapidamente.

As redes locais cresciam.

O UNIX conquistava espaço.

O Windows NT surgia como promessa corporativa.

A internet começava sua expansão.

Os servidores Intel ficavam cada vez mais baratos.

Tudo parecia apontar para uma descentralização completa.

Se estivéssemos vivendo em 1991...

Talvez muitos de nós também acreditássemos naquelas previsões.

A História precisa ser analisada com os olhos da época.

Não apenas com o conhecimento que temos hoje.

A imprensa não inventou essa narrativa

Outro detalhe interessante.

As revistas não criaram sozinhas a ideia da morte do mainframe.

Elas refletiam um sentimento muito presente no mercado.

Fabricantes promoviam novas arquiteturas.

Consultorias recomendavam migrações.

Analistas divulgavam projeções otimistas.

Empresas buscavam reduzir custos.

A imprensa fazia aquilo que continua fazendo até hoje.

Publicava aquilo que parecia representar o futuro.

O problema não era noticiar tendências.

O problema era transformar tendências em certezas.

Existe uma enorme diferença entre dizer:

"O Client/Server está crescendo."

E afirmar:

"O Mainframe acabou."

Uma frase descreve uma evolução.

A outra decreta um veredito.

O curioso efeito das manchetes

Manchetes possuem um poder enorme.

Poucas pessoas leem o artigo inteiro.

A maioria lê apenas o título.

Imagine um diretor financeiro em 1993.

Ele abre uma revista.

Lê:

"Mainframe: tecnologia em extinção."

Pronto.

A ideia fica plantada.

Mesmo que o restante do texto apresente ressalvas...

O título já cumpriu sua missão.

Esse fenômeno continua existindo em 2026.

Troque "Mainframe" por:

  • IA substituirá todos os programadores.

  • O fim das linguagens tradicionais.

  • O último DBA.

  • O fim do DevOps.

  • O fim do Cloud.

  • O fim do Kubernetes.

Mudam os personagens.

O mecanismo psicológico continua exatamente o mesmo.

A máquina do hype nunca parou

Os anos mudam.

Os nomes mudam.

Mas existe uma engrenagem que permanece.

Primeiro surge uma inovação.

Depois aparece entusiasmo.

Em seguida surgem previsões exageradas.

Logo aparecem manchetes definitivas.

Anos depois...

A realidade encontra um equilíbrio.

Foi assim com:

Client/Server.

SOA.

XML.

Java Applets.

CORBA.

Blockchain.

Metaverso.

NFT.

E, muito provavelmente, acontecerá com diversas previsões atuais envolvendo Inteligência Artificial.

A IA transformará profundamente a indústria?

Sem dúvida.

Mas isso não significa que todo software existente será descartado.

Nem que toda linguagem desaparecerá.

Nem que décadas de regras de negócio deixarão de existir da noite para o dia.

O verdadeiro legado de Spruth

Talvez a maior contribuição de Wolfgang Spruth não tenha sido provar que o mainframe sobreviveu.

Isso o tempo fez sozinho.

Seu verdadeiro legado foi outro.

Ele nos ensinou a importância de preservar a memória da tecnologia.

Porque engenharia também possui História.

E quem não conhece essa História corre o risco de repetir exatamente os mesmos erros.

Hoje olhamos para aquelas manchetes e sorrimos.

Daqui a vinte anos...

Talvez alguém faça exatamente a mesma coisa com muitas previsões feitas sobre Inteligência Artificial em 2026.

Um conselho para o Padawan

Quando você ouvir alguém dizendo:

"Essa tecnologia morreu."

Não pergunte apenas:

"Qual tecnologia?"

Pergunte também:

  • Quem fez essa previsão?

  • Em qual contexto?

  • Com quais dados?

  • Qual interesse econômico existia?

  • Ela resolve um problema técnico ou vende uma narrativa?

Foi exatamente esse olhar crítico que transformou um conjunto de manchetes esquecidas em um dos documentos históricos mais valiosos da computação corporativa.

Graças ao trabalho paciente do professor Wolfgang Spruth, aquelas previsões não ficaram perdidas em arquivos de jornais. Elas se tornaram uma aula permanente sobre humildade tecnológica.

Porque, no fim das contas, a maior vítima da década de 1990 não foi o mainframe.

Foram as certezas absolutas.

E a Engenharia continua ensinando, geração após geração, que modismos passam.

Arquiteturas sólidas evoluem.

 

Bellacosa Mainframe e a serie Funeral que nunca aconteceu



C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
▼ DIRETÓRIO DE CAPÍTULOS ▼

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

Programando COBOL no GitHub com VS Code Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

 


Bellacosa Mainframe usando o vs code para programar cobol numa ide moderna

☕ Um Café no Bellacosa Mainframe

Programando COBOL no GitHub com VS Code

Sem Mainframe. Sem Compilar. Apenas Aprendendo como um Desenvolvedor Moderno.

"Todo Jedi começa treinando com um sabre de luz desligado. Todo desenvolvedor Mainframe também pode começar sem um z/OS."

Antes de começarmos...

Existe um mito enorme no mundo Mainframe.

"Para aprender COBOL preciso de um IBM Z."

Não.

Outro mito:

"Para editar programas COBOL preciso de um emulador."

Também não.

Outro:

"Preciso instalar um compilador."

Ainda não.

Hoje vamos aprender exatamente como milhares de desenvolvedores modernos trabalham quando estão estudando, revisando código ou preparando alterações para um projeto.

Você vai usar apenas:

  • GitHub

  • Visual Studio Code

  • IBM Z Open Editor

  • Git

Nada mais.

Nenhum z/OS.

Nenhum TSO.

Nenhum ISPF.

Nenhuma licença IBM.

E, ainda assim, estará utilizando praticamente o mesmo editor utilizado por desenvolvedores COBOL profissionais.

Pegue seu café.

Vamos montar nosso laboratório.

Bellacosa Mainframe passo a passo na instalacao

A grande mudança de mentalidade

Imagine um mecânico.

Ele não liga um caminhão para trocar o volante.

Primeiro ele trabalha na peça.

Depois instala.

No Mainframe acontece exatamente igual.

Você pode editar, estudar, revisar e versionar milhares de programas COBOL sem sequer possuir acesso ao IBM Z.

O Mainframe só entra quando chega a hora de:

  • compilar

  • executar

  • testar online

  • acessar DB2

  • acessar CICS

  • executar JCL

Até lá...

Tudo pode ser feito localmente.

Nossa arquitetura

Imagine esta jornada.

GitHub
     │
git clone
     │
VS Code
     │
IBM Z Open Editor
     │
Editar COBOL
     │
Git Commit
     │
Git Push
     │
GitHub

Perceba.

O Mainframe nem apareceu.

O que vamos instalar

Nosso kit Bellacosa Mainframe será composto por:

✅ Visual Studio Code

✅ Git

✅ IBM Z Open Editor

✅ GitHub Pull Requests

✅ Error Lens

✅ Material Icon Theme

✅ Markdown All in One

✅ Code Spell Checker

✅ Todo Tree

✅ Peacock

Opcionalmente:

  • GitLens

  • Better Comments

  • YAML

  • XML

  • Rainbow CSV

  • Hex Editor

  • REST Client

Você perceberá que quase tudo é gratuito.

Passo 1 — Instale o Git

Sem Git...

não existe GitHub.

Baixe:

https://git-scm.com

Durante a instalação aceite praticamente tudo.

Depois abra um terminal.

Digite:

git --version

Se aparecer algo parecido com:

git version 2.51

Parabéns.

Seu sabre de luz foi montado.

Passo 2 — Instale o VS Code

Baixe em

https://code.visualstudio.com

Instale normalmente.

Abra.

Você verá uma tela praticamente vazia.

É aqui que a mágica acontece.

Passo 3 — Faça login no GitHub

No canto inferior esquerdo existe o ícone da conta.

Clique.

Escolha:

Sign In with GitHub

O navegador abrirá.

Autorize.

Volte ao VS Code.

Pronto.

Agora seu VS Code conversa diretamente com o GitHub.

Passo 4 — Instale o IBM Z Open Editor

Abra Extensions.

Pesquise:

IBM Z Open Editor

Instale.

Este plugin entende COBOL.

Ele conhece:

  • DIVISION

  • SECTION

  • PARAGRAPH

  • COPY

  • EXEC SQL

  • EXEC CICS

  • comentários

  • copybooks

É praticamente um ISPF moderno.

O que ele faz?

Quando você abre:

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.

Ele já entende que aquilo é COBOL.

Você ganha:

✔ Colorização

✔ Outline

✔ Auto Complete

✔ Navegação

✔ Hover

✔ Referências

✔ Folding

✔ Sintaxe

Tudo gratuitamente.

Passo 5 — Instale GitHub Pull Requests

Esse plugin é fantástico.

Ele permite:

  • abrir Pull Requests

  • revisar código

  • comentar linhas

  • aprovar alterações

Sem sair do VS Code.

Passo 6 — Material Icon Theme

Pequeno detalhe.

Grande diferença.

Agora:

📄 COBOL

📄 COPYBOOK

📄 JCL

📄 REXX

ganham ícones.

Seu projeto fica muito mais agradável.

Passo 7 — Error Lens

Esse plugin faz algo simples.

Mostra erros diretamente na linha.

Sem precisar olhar outro painel.

Economiza muito tempo.

Passo 8 — Better Comments

Imagine:

*> TODO

vira verde.

*> WARNING

fica amarelo.

*> BUG

fica vermelho.

Seu código passa a conversar com você.

Passo 9 — Todo Tree

Agora imagine possuir 3.000 programas.

Você procura:

TODO

Ele encontra todos.

Fantástico para projetos enormes.

Passo 10 — Clone seu GitHub

No terminal:

git clone https://github.com/seuusuario/IBMLearnCOBOL.git

ou simplesmente:

No VS Code:

Clone Repository

Cole a URL.

Pronto.

Estrutura típica

COBOL/
    HELLO.CBL
    CLIENTE.CBL
COPY/
    CLIENTE.CPY
JCL/
    COMPILA.JCL
REXX/
README.md

Tudo organizado.

Abrindo o projeto

Arquivo

Open Folder

Escolha:

IBMLearnCOBOL

Agora tudo aparece na lateral.

Exatamente como Java.

Exatamente como Python.

Editando um programa

Abra:

HELLO.CBL

Modifique:

DISPLAY "HELLO WORLD".

para

DISPLAY "HELLO BELLACOSA MAINFRAME".

Salve.

Só isso.

Observe o Git

Na lateral existe:

Source Control

Aparecerá:

M HELLO.CBL

M significa:

Modified.

Veja a diferença

Clique no arquivo.

O VS Code mostra:

esquerda

arquivo antigo

direita

arquivo novo.

Em verde:

linhas adicionadas.

Em vermelho:

linhas removidas.

É maravilhoso.

Criando um Commit

Na caixa superior escreva:

Alterado texto do HELLO WORLD

Clique:

Commit

Pronto.

Fazendo Push

Agora clique:

Sync

ou

Push

O Git envia tudo para o GitHub.

Seu código agora está online.

Histórico

Clique:

Timeline

Você verá:

  • quem alterou

  • quando

  • qual commit

  • diferença

É uma máquina do tempo.

GitLens

Se instalar GitLens...

fica ainda melhor.

Você passa o mouse.

Ele mostra:

Vagner Bellacosa

14 dias atrás

Commit:

Correção cálculo IRRF

Parece mágica.

Trabalhando com Branches

Nunca altere diretamente a Main.

Crie:

feature/curso-cobol

bugfix/cliente

feature/json

feature/db2

Isso é padrão de mercado.

Commits bons

Ruim:

teste

Ruim:

aaaa

Ruim:

mudança

Bom:

Inclui validação do CPF

Corrige cálculo de juros

Refatora rotina de leitura VSAM

Atualiza documentação

Organização Bellacosa

COBOL
COPY
JCL
BMS
DBRM
SQL
DOCS
LABS
QUIZZES

Tudo separado.

Tudo fácil.

Markdown

Documente tudo.

README.

Arquitetura.

Fluxo.

Exemplos.

O VS Code possui preview fantástico.

Dica de Ouro

Ative:

Auto Save

Você nunca esquecerá de salvar.

Outra dica

Use:

Minimap.

Você enxerga programas COBOL gigantes.

Outra

Breadcrumbs.

Você sabe exatamente:

DIVISION

SECTION

PARAGRAPH

onde está.

Outra

Outline.

Clique:

CALCULA-TOTAL

Vai direto para o parágrafo.

Adeus Page Down.

Outra

CTRL+P

Digite:

cliente

Abre CLIENTE.CBL imediatamente.

Outra

CTRL+SHIFT+O

Lista todos os parágrafos.

Fantástico.

Outra

CTRL+SHIFT+F

Procura em TODOS os programas.

Imagine localizar:

EXEC SQL

em 12.000 fontes.

Leva segundos.

Easter Egg nº 1

Troque o tema.

Experimente:

IBM Carbon Theme

ou

One Dark Pro.

Seu COBOL fica lindíssimo.

Easter Egg nº 2

Instale Peacock.

Cada Workspace ganha uma cor.

Nunca mais confundirá produção e laboratório.

Easter Egg nº 3

Digite:

>Preferences: Open Keyboard Shortcuts

Personalize tudo.

Easter Egg nº 4

Use emojis nos commits.

✨ Novo programa

🐞 Corrige bug

📚 Atualiza documentação

♻ Refatoração

🚀 Nova funcionalidade

Easter Egg nº 5

Use Copilot apenas para sugerir código.

Nunca aceite sem entender.

O bom desenvolvedor continua pensando.

Quando chegar o Mainframe...

Nada muda.

Você apenas instala:

IBM Zowe Explorer.

Então passa a acessar:

PDS

PDSE

USS

JES

Jobs

Datasets

O editor continua exatamente o mesmo.

É como aprender a dirigir em um simulador e depois entrar no carro real: os comandos principais permanecem familiares.

O verdadeiro objetivo

Aprender COBOL nunca foi decorar comandos do ISPF.

O objetivo é entender:

  • lógica de negócio;

  • arquitetura de sistemas;

  • qualidade de código;

  • versionamento;

  • colaboração;

  • documentação.

Essas habilidades acompanham você em qualquer plataforma.

Conclusão

Durante décadas, muitos imaginaram que o desenvolvimento Mainframe dependia de telas verdes, terminais 3270 e comandos memorizados. Hoje, essa realidade mudou. O Visual Studio Code, aliado ao IBM Z Open Editor e ao GitHub, oferece uma experiência moderna, produtiva e acessível para estudar, revisar e evoluir programas COBOL sem a necessidade imediata de um ambiente z/OS.

Ao dominar Git, commits bem escritos, branches, documentação em Markdown e a organização de projetos, você desenvolve competências valorizadas em qualquer equipe de engenharia de software. Quando chegar o momento de conectar-se a um IBM Z com o Zowe Explorer, a curva de aprendizado será muito menor, pois o editor, os atalhos e o fluxo de trabalho continuarão praticamente os mesmos.

Você não está abandonando o Mainframe tradicional. Está adicionando ferramentas modernas à sua caixa de ferramentas. Como costumo dizer no Bellacosa Mainframe: o terminal pode mudar, mas a excelência em engenharia de software continua sendo a mesma. ☕

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,

quinta-feira, 2 de julho de 2026

Capítulo 2 — A Década dos Buzzwords

Bellacosa Mainframe invente um nome um jargao e mate o mainframe

☕ Um Café no Bellacosa Mainframe

Capítulo 2 — A Década dos Buzzwords

Quando Bastava Inventar um Nome Bonito para Declarar a Morte do Mainframe

Uma análise histórica e bem-humorada dos buzzwords dos anos 1990, como Client/Server, Downsizing, Open Systems, RISC e Windows NT, que prometiam substituir o mainframe enquanto COBOL, CICS, Db2, JCL, z/OS e IBM Z continuavam evoluindo.

Por

A Década dos Buzzwords e as previsões sobre a morte do mainframe 

"Toda geração acredita ter inventado a computação. Toda geração descobre, alguns anos depois, que ainda existe um COBOL pagando salários."
— Bellacosa Mainframe

Bem-vindo aos anos 90

Se você é um Padawan COBOL e nasceu depois dos anos 2000, talvez seja difícil imaginar o clima que existia na indústria de tecnologia durante a década de 1990.

Hoje estamos acostumados a ouvir expressões como:

  • IA Generativa

  • LLM

  • Agentic AI

  • RAG

  • MCP

  • AI Native

  • Platform Engineering

  • Data Mesh

  • Cloud Native

Mas, naquela época, esses nomes ainda nem existiam.

Em compensação...

Os corredores das empresas eram inundados por outra coleção de palavras mágicas.

Client/Server.

Open Systems.

Downsizing.

Distributed Computing.

Workgroups.

LAN Computing.

Enterprise Networking.

Network Computing.

Object-Oriented.

Visual Programming.

Windows NT.

RISC.

Cada uma dessas expressões era apresentada como a solução definitiva para todos os problemas da computação corporativa.

Se um fabricante queria vender um servidor...

Colocava "Open" no nome.

Se queria vender uma ferramenta...

Chamava de "Client/Server".

Se queria convencer o diretor financeiro...

Prometia "Downsizing".

Se queria impressionar investidores...

Falava em "Distributed Computing".

Era a época em que o marketing tecnológico descobriu que uma boa buzzword podia vender mais do que um bom benchmark.

A religião do Client/Server

Nenhum termo foi tão poderoso quanto Client/Server.

Hoje ele parece apenas uma arquitetura comum.

Mas, no início dos anos 90, era quase uma religião.

Consultores viajavam o mundo inteiro mostrando diagramas semelhantes.

          [PC]
            |
          [Servidor]

Depois olhavam para um desenho de um mainframe.

          [IBM Mainframe]

E diziam:

— Está vendo?

Esse modelo é antigo.

Centralizado.

Monolítico.

O futuro é distribuído.

A ideia parecia excelente.

Dividir a carga.

Comprar servidores menores.

Dar autonomia às áreas.

Substituir um computador gigantesco por centenas de máquinas menores.

Na teoria...

Tudo fazia sentido.

Na prática...

As empresas descobriram algo curioso.

Um servidor pequeno é barato.

Quinhentos servidores pequenos...

Nem tanto.

Downsizing: a promessa de economizar milhões

Outra palavra extremamente popular era Downsizing.

O discurso era sedutor.

"Por que comprar um computador enorme quando podemos comprar dezenas de computadores baratos?"

A lógica parecia impecável.

O problema era um pequeno detalhe.

Ninguém havia calculado o custo de administrar centenas de computadores.

De repente apareceram problemas novos.

Mais backups.

Mais discos.

Mais sistemas operacionais.

Mais patches.

Mais licenças.

Mais administradores.

Mais falhas.

Mais consumo de energia.

Mais refrigeração.

Mais monitoramento.

Mais suporte.

O CPD não desapareceu.

Ele apenas ficou espalhado por vários racks.

Open Systems

Outra expressão quase obrigatória era:

Open Systems

Era impossível abrir uma revista técnica sem encontrar esse termo.

O curioso é que poucas pessoas conseguiam definir exatamente o que significava.

Na prática, "Open" podia significar qualquer coisa.

UNIX.

POSIX.

TCP/IP.

X/Open.

Padrões.

Interoperabilidade.

Ou simplesmente...

Marketing.

Parecia existir uma regra informal:

Se o produto fosse chamado de "Open", automaticamente ficava moderno.

Enquanto isso...

O IBM já executava protocolos abertos, TCP/IP, UNIX (AIX), SNA, APPC e diversas tecnologias de interoperabilidade, embora raramente recebesse esse crédito.

O medo do "grande computador"

Havia também um componente psicológico.

Mainframes eram enormes.

Caros.

Impressionantes.

Ficavam em salas refrigeradas.

Tinham operadores.

Consoles.

Fitas magnéticas.

Grandes discos.

Para muitos executivos, aquilo parecia representar uma tecnologia "do passado".

Os servidores menores transmitiam outra sensação.

Modernidade.

Agilidade.

Liberdade.

Só havia um problema.

A física não liga para marketing.

Nem a teoria das filas.

Nem a consistência transacional.

Nem o CAPEX.

Nem o OPEX.

Nem a Lei de Amdahl.

O nascimento da guerra comercial

Pouca gente comenta isso.

Mas boa parte daquela narrativa foi impulsionada por uma disputa extremamente agressiva entre fabricantes.

IBM.

DEC.

Sun Microsystems.

HP.

Compaq.

Silicon Graphics.

Data General.

Tandem.

Se uma empresa conseguisse convencer o mercado de que o mainframe estava morrendo...

Automaticamente venderia mais servidores.

Não havia nada de ilegal nisso.

Era competição.

Mas muitas análises técnicas começaram a misturar engenharia com marketing.

E essa mistura quase nunca produz boas previsões.

A guerra das arquiteturas

Outro grande "vilão" da época era o processador CISC.

Segundo muitos especialistas, o futuro pertencia aos processadores RISC.

As apresentações eram quase sempre iguais.

RISC era simples.

Elegante.

Rápido.

CISC era complexo.

Antigo.

Lento.

O detalhe curioso?

Enquanto essa discussão acontecia, os engenheiros da IBM continuavam evoluindo silenciosamente sua arquitetura, introduzindo novas gerações de processadores, cache, canais de I/O e mecanismos sofisticados de paralelismo.

No mundo real...

O cliente queria saber apenas uma coisa.

"Meu banco continua funcionando?"

Quando o PowerPoint venceu a engenharia

Existe uma piada antiga entre arquitetos.

"Quanto mais bonito o slide, maior a chance de esconder um benchmark incompleto."

Nos anos 90 isso acontecia frequentemente.

Os gráficos mostravam:

⬆️ Crescimento dos PCs.

⬆️ Crescimento das LANs.

⬆️ Crescimento do UNIX.

⬇️ Queda do preço dos servidores.

E então aparecia a conclusão inevitável:

"O mainframe acabou."

Só que os gráficos raramente mostravam:

  • disponibilidade;

  • MTBF;

  • MTTR;

  • throughput;

  • custo operacional ao longo de dez anos;

  • consistência transacional;

  • segurança;

  • auditoria;

  • produtividade por administrador;

  • custo de migração.

Era como comparar um caminhão com uma motocicleta apenas pelo preço de compra.

O Padawan COBOL observa tudo isso...

Imagine nosso Padawan viajando no tempo.

Ele entra em uma feira de tecnologia de 1993.

Escuta uma palestra.

"COBOL acabou."

Ele sorri.

Passa em outro estande.

"CICS morreu."

Ele continua andando.

Mais adiante.

"Db2 será substituído."

Ele pega um café.

Mais um corredor.

"O futuro é sem mainframe."

Ele olha discretamente para o relógio.

Naquele exato momento...

Milhões de cartões de crédito estão sendo autorizados.

Bilhões de dólares estão sendo transferidos.

Companhias aéreas continuam emitindo passagens.

Governos processam impostos.

Seguradoras calculam riscos.

Tudo em plataformas que, segundo os palestrantes, já deveriam estar mortas.

Nosso Padawan apenas pensa:

— "Esse defunto trabalha bastante..."

Buzzwords envelhecem. Engenharia permanece.

Existe uma diferença fundamental entre uma moda e uma arquitetura.

A moda vende expectativa.

A arquitetura entrega resultado.

Durante mais de cinquenta anos, dezenas de buzzwords apareceram prometendo substituir completamente o mainframe.

Algumas realmente trouxeram avanços importantes.

Outras desapareceram tão rapidamente quanto surgiram.

A computação distribuída venceu?

Sim.

Cloud existe?

Claro.

Containers revolucionaram o desenvolvimento?

Sem dúvida.

Mas nenhuma dessas tecnologias eliminou automaticamente a necessidade de plataformas transacionais altamente confiáveis.

Elas passaram a coexistir.

E o IBM Z evoluiu para integrar-se a esse novo ecossistema.

A primeira lição para um Padawan COBOL

Quando você ouvir alguém afirmar que uma tecnologia "vai morrer em dois anos", faça três perguntas simples:

  1. Quem está dizendo isso?

  2. Quem ganha dinheiro se isso acontecer?

  3. Os maiores bancos do mundo concordam?

Se a terceira resposta for "não"...

Talvez seja apenas mais uma buzzword.

O verdadeiro inimigo nunca foi o mainframe

O maior erro da década de 1990 não foi apostar em novas arquiteturas.

Elas eram necessárias e transformaram a indústria.

O erro foi acreditar que inovação exige destruição completa do que veio antes.

A história mostrou exatamente o contrário.

Os sistemas corporativos evoluíram por integração, não por substituição.

O IBM Z incorporou Linux, Java, APIs REST, OpenShift, DevOps, Zowe, watsonx, IA embarcada, COBOL moderno, Db2 13 e CICS TS, enquanto as arquiteturas distribuídas amadureceram ao seu redor.

O resultado não foi a vitória de um lado sobre o outro.

Foi um ecossistema híbrido, onde cada tecnologia ocupa o espaço em que entrega mais valor.

E talvez essa seja a maior ironia da década dos buzzwords:

Enquanto muitos gastavam energia tentando enterrar o mainframe, os engenheiros da IBM estavam ocupados fazendo algo muito menos chamativo...

Preparando a próxima geração.

Bellacosa Mainframe e a serie Funeral que nunca aconteceu


C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
▼ DIRETÓRIO DE CAPÍTULOS ▼

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

 


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

As 16 Recomendações da IBM que Todo Programador COBOL Padawan Deveria Conhecer

 

Bellacosa Mainframe e 16 recomendacoes Jedi para seu programa COBOL século XXI

☕ Um Café no Bellacosa Mainframe

As 16 Recomendações da IBM que Todo Programador COBOL Padawan Deveria Conhecer

Da Era dos Cartões Perfurados ao IBM Z Moderno: Como Escrever COBOL Preparado para os Próximos 30 Anos

"A maior diferença entre um Programador COBOL Júnior e um Arquiteto Mainframe não está em quantos comandos ele conhece, mas em entender por que a linguagem evoluiu."

Existe uma frase muito comum entre desenvolvedores iniciantes:

"Sempre fizemos assim."

Ela parece inofensiva.

Mas, no mundo Mainframe, ela pode esconder décadas de dívida técnica.

Muitos sistemas COBOL que ainda executam hoje foram escritos quando:

  • o IBM System/360 ainda era novidade;

  • cartões perfurados eram utilizados;

  • memória era medida em kilobytes;

  • não existia Internet;

  • não existia Java;

  • não existia JSON;

  • ninguém imaginava APIs REST.

Mesmo assim, esses sistemas continuam processando bilhões de dólares diariamente.

Então surge uma pergunta inevitável:

Se eles funcionam tão bem, por que a IBM continua evoluindo o COBOL?

A resposta é simples.

Porque o mundo mudou.

O hardware mudou.

Os processadores IBM Z mudaram.

O Language Environment (LE) mudou.

As aplicações passaram a conversar com Java, Python, Node.js, microsserviços, OpenShift, APIs REST e serviços em nuvem.

O COBOL também precisou evoluir.

E é exatamente isso que veremos neste café.

A filosofia da IBM

Existe um detalhe curioso.

A IBM raramente muda uma linguagem apenas porque existe uma novidade tecnológica.

Ela muda quando existe ganho real.

Os princípios normalmente são:

  • mais segurança

  • mais desempenho

  • menos CPU

  • menos manutenção

  • melhor integração

  • melhor diagnóstico

  • maior reutilização

Sempre que surgir uma recomendação da IBM, pergunte:

"Qual problema essa mudança resolveu?"

Essa pergunta transforma um Padawan em um profissional que entende arquitetura.

1. STOP RUN → GOBACK

Provavelmente a recomendação mais conhecida.

Durante décadas escrevíamos:

STOP RUN.

Hoje, novos projetos costumam utilizar:

GOBACK.

Por quê?

Imagine um restaurante.

Você pede um café.

O garçom leva até sua mesa.

Quando termina de beber, o correto é devolver a xícara ao garçom.

Não faz sentido fechar o restaurante inteiro.

Foi exatamente isso que aconteceu com o COBOL.

Nos anos 60 o programa era praticamente o dono da execução.

Hoje ele normalmente é apenas um componente.

Pode ser chamado por:

  • outro COBOL

  • CICS

  • IMS

  • Java

  • API REST

  • MQ

  • z/OS Connect

Se um módulo chamado executar STOP RUN...

Toda a Run Unit termina.

Com GOBACK...

O controle simplesmente retorna ao chamador.

Dica Bellacosa

Sempre imagine:

"Meu programa está prestando um serviço."

Quem chamou deve decidir quando terminar a aplicação.

2. NUMCHECK

Todo programador já viu um S0C7.

Normalmente ele aparece na madrugada.

Em produção.

Na sexta-feira.

O motivo quase sempre é simples.

Dados inválidos.

Exemplo:

MOVE "ABC" TO WS-VALOR.
ADD 10 TO WS-VALOR.

Visualmente parece correto.

Na prática...

Explode.

NUMCHECK faz o compilador inserir verificações para identificar esse tipo de problema antes que ele vire um incidente.

Curiosidade

Muitos S0C7 não nascem onde ocorrem.

O dado inválido pode ter sido gravado horas antes por outro programa.

3. SSRANGE

Imagine um armário com 100 gavetas.

Você tenta abrir a gaveta 101.

Ela simplesmente não existe.

Sem SSRANGE...

Seu programa pode acessar memória indevida.

Com SSRANGE...

O erro é detectado imediatamente.

Exemplo:

01 TABELA.
   05 ITEM OCCURS 100 TIMES.

MOVE "X" TO ITEM(101).

Esse erro pode permanecer escondido durante anos.

Até que um dia...

Produção.

Curiosidade

Grande parte dos erros difíceis de reproduzir está relacionada ao acesso indevido de memória.

SSRANGE ajuda justamente nisso.

4. TEST

Quantos DISPLAY você já encontrou em produção?

DISPLAY "CHEGUEI AQUI".

DISPLAY SQLCODE.

DISPLAY WS-CLIENTE.

Eles ajudam?

Sim.

Mas apenas temporariamente.

Hoje existem ferramentas de Debug muito mais completas.

Com TEST, o programa pode ser analisado sem transformar o código em uma árvore de DISPLAY.

5. Unicode

Durante décadas tudo era EBCDIC.

Hoje recebemos:

  • JSON

  • XML

  • APIs

  • Web

  • Smartphones

  • Emojis

  • Idiomas internacionais

O COBOL moderno suporta Unicode.

Isso significa muito mais integração.

Imagine um banco atendendo clientes no Japão, Brasil e Alemanha.

Tudo utilizando a mesma aplicação.

Curiosidade

Muitos desenvolvedores COBOL nunca perceberam que o Enterprise COBOL moderno possui excelente suporte a Unicode.

6. JSON PARSE

Há alguns anos montar JSON significava algo parecido com isto:

STRING "{"

...

"}"

Muito código.

Muito risco.

Muito difícil de manter.

Hoje basta utilizar:

JSON GENERATE.

Ou

JSON PARSE.

O compilador faz praticamente todo o trabalho.

Isso muda completamente a modernização

Imagine integrar COBOL com:

  • React

  • Angular

  • Flutter

  • Java

  • Python

JSON virou a linguagem universal.

7. XML PARSE

O mesmo aconteceu com XML.

Antes era comum utilizar:

UNSTRING.

INSPECT.

STRING.

Hoje o compilador entende XML nativamente.

Menos código.

Menos bugs.

Mais produtividade.

8. RENT

Talvez uma das opções menos conhecidas pelos iniciantes.

RENT significa:

Reentrant.

Ou seja...

O programa pode ser executado simultaneamente por diversos usuários.

Imagine um banco.

Cinco mil clientes consultando saldo.

O mesmo programa atende todos.

Isso só funciona porque ele foi escrito corretamente.

Dica

Sempre evite gravar informações temporárias em áreas compartilhadas.

9. DYNAM

No passado quase tudo era ligado durante o Link-Edit.

Hoje queremos mais flexibilidade.

CALL dinâmico permite substituir módulos sem reconstruir toda a aplicação.

É um grande aliado em ambientes modernos.

10. EVALUATE

Existe um momento na vida de todo Padawan em que ele escreve isto:

IF
ELSE
IF
ELSE
IF
ELSE

Depois de alguns meses...

Nem ele entende mais.

EVALUATE resolve exatamente isso.

Exemplo:

EVALUATE WS-TIPO

WHEN 1

WHEN 2

WHEN 3

WHEN OTHER

END-EVALUATE

Muito mais limpo.

11. END-IF

Antigamente muitos programas dependiam de ponto final e NEXT SENTENCE.

Isso gerava ambiguidades.

Hoje escrevemos:

IF ...

END-IF

O compilador entende exatamente onde cada bloco termina.

12. Intrinsic Functions

Durante muitos anos criávamos rotinas para tudo.

Hoje o compilador já oferece dezenas de funções.

Exemplos:

FUNCTION CURRENT-DATE

FUNCTION LENGTH

FUNCTION TRIM

FUNCTION LOWER-CASE

FUNCTION UPPER-CASE

Além de deixar o código mais elegante, elas costumam ser mais eficientes.

13. Evitar ALTER

ALTER era considerado brilhante.

Na década de 70.

Hoje virou pesadelo.

Ele altera dinamicamente o fluxo do programa.

Resultado:

  • difícil de entender;

  • difícil de depurar;

  • difícil de otimizar.

Por isso praticamente desapareceu dos novos projetos.

14. Reduzir GO TO

Existe um mito.

GO TO não é proibido.

Mas o excesso dele transforma um programa em um labirinto.

Imagine tentar seguir uma história cuja página seguinte muda aleatoriamente.

É exatamente essa sensação.

PERFORM e EVALUATE tornam o fluxo muito mais claro.

15. Migrar para Enterprise COBOL 6.x

Essa talvez seja a maior evolução dos últimos anos.

O compilador moderno entende muito melhor os processadores IBM Z atuais.

Isso significa:

  • menos CPU;

  • otimizações automáticas;

  • melhores diagnósticos;

  • suporte ampliado a JSON e XML;

  • novas funções intrínsecas.

Em muitos casos, apenas recompilar um programa com ajustes adequados já produz ganhos perceptíveis de desempenho.

16. Pensar em Integração

Esta talvez seja a maior mudança cultural.

Antes escrevíamos programas Batch.

Hoje escrevemos serviços corporativos.

Um programa COBOL pode atender:

  • Mobile Banking

  • Internet Banking

  • PIX

  • APIs REST

  • Java

  • Python

  • Node.js

  • OpenShift

  • Mensageria MQ

O código precisa nascer preparado para esse mundo.

O impacto nos programas antigos

A boa notícia é que a IBM sempre valorizou compatibilidade. Muitos programas escritos há décadas ainda compilam e executam nas versões atuais do Enterprise COBOL.

Isso, porém, não significa que estejam aproveitando os recursos modernos.

É comum encontrar aplicações com:

  • STOP RUN em todos os módulos;

  • dezenas de GO TO;

  • ALTER;

  • manipulação manual de XML e JSON;

  • ausência de verificações de dados;

  • poucas opções de diagnóstico.

Esses programas continuam funcionando, mas tendem a ser mais difíceis de manter, testar e integrar.

Modernizar não significa reescrever tudo. Em muitos casos, basta evoluir gradualmente: substituir comandos antigos, ativar opções do compilador, introduzir funções intrínsecas e organizar melhor o código.

A evolução de um Programador COBOL

Todo desenvolvedor passa por etapas.

Padawan

Aprende a sintaxe.

Consegue compilar.

Resolve problemas.

Programador

Começa a reutilizar código.

Escreve módulos.

Documenta interfaces.

Desenvolvedor Sênior

Pensa em desempenho.

CPU.

Memória.

Escalabilidade.

Arquiteto

Pensa no sistema inteiro.

Integração.

Disponibilidade.

Evolução.

Governança.

Perceba que, à medida que você cresce, a linguagem deixa de ser o foco principal. O importante passa a ser a qualidade das decisões.

O Mainframe moderno

Existe um mito antigo de que o Mainframe "parou no tempo".

Nada poderia estar mais distante da realidade.

Hoje um IBM Z pode:

  • expor APIs REST;

  • consumir serviços externos;

  • executar aplicações Java;

  • trabalhar com contêineres;

  • integrar-se ao OpenShift;

  • processar JSON e XML;

  • utilizar DevOps, Git e pipelines CI/CD;

  • compartilhar dados em tempo real com aplicações distribuídas.

O COBOL moderno acompanha essa evolução. As recomendações da IBM existem justamente para que o código continue relevante nesse novo cenário.

Conclusão

Existe uma frase que resume toda essa evolução:

"O melhor código não é aquele que apenas funciona hoje; é aquele que continuará funcionando, sendo compreendido e evoluído daqui a vinte anos."

As recomendações da IBM não representam uma ruptura com o passado. Elas representam a continuidade de uma filosofia que sempre guiou o Mainframe: estabilidade, desempenho, confiabilidade e evolução gradual.

Trocar STOP RUN por GOBACK, utilizar NUMCHECK, adotar SSRANGE nos testes, explorar JSON PARSE, JSON GENERATE, XML PARSE, RENT, funções intrínsecas e estruturas mais legíveis não é seguir uma moda. É escrever código preparado para um ambiente onde COBOL conversa diariamente com APIs, microsserviços, aplicações móveis e plataformas em nuvem.

Como Programador COBOL Padawan, seu objetivo não deve ser apenas aprender comandos. Deve ser entender por que eles existem, quando utilizá-los e como eles ajudam a construir sistemas capazes de sobreviver por décadas.

No Bellacosa Mainframe, costumamos dizer que a verdadeira modernização não começa com uma nova tecnologia. Ela começa quando o desenvolvedor muda sua forma de pensar. O compilador evolui, o hardware evolui, o IBM Z evolui — e o profissional que acompanha essa jornada deixa de apenas escrever programas para construir soluções que atravessam gerações.


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

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

 

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


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

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

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

Vamos analisar como um arquiteto de Mainframe faria.

A origem do STOP RUN

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

O fluxo era simples:

JCL
 │
 ▼
Programa COBOL
 │
STOP RUN
 │
 ▼
MVS

Naquela época:

  • não existiam APIs REST;

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

  • praticamente não existiam subprogramas complexos;

  • o programa começava e terminava.

O STOP RUN fazia exatamente isso:

"Acabei. Pode encerrar tudo."

O surgimento do GOBACK

Com o crescimento dos sistemas apareceram:

  • subprogramas

  • bibliotecas

  • módulos reutilizáveis

  • CICS

  • IMS

  • DB2

  • Language Environment (LE)

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

Exemplo:

JCL

  MAIN01

     │

 CALL CLIENTE

     │

 CALL CALCJURO

     │

 CALL VALIDA

Imagine se CALCJURO executasse:

STOP RUN

O que aconteceria?

Toda a aplicação terminaria imediatamente.

Não apenas o módulo.

Todo o Run Unit.

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

A grande diferença

STOP RUN

Programa

↓

encerra TODA a Run Unit

↓

retorna ao sistema operacional

GOBACK

Programa

↓

retorna para quem chamou

↓

continua a execução

Se o programa for o principal:

GOBACK

↓

faz praticamente o mesmo trabalho do STOP RUN

A IBM afirma isso explicitamente:

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

Exemplo prático

Programa principal

MAIN

CALL "A"

DISPLAY "FIM"

STOP RUN

Programa A

DISPLAY "A"

STOP RUN

Resultado

A

O DISPLAY "FIM"

nunca acontece.

Agora usando GOBACK

Programa A

DISPLAY "A"

GOBACK

Resultado

A

FIM

Porque voltou para o MAIN.

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

Não porque ele esteja errado.

Mas porque ele cria risco.

Imagine um programa hoje.

Batch

↓

Framework

↓

Biblioteca

↓

Serviço

↓

Seu Programa

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

Se usar

STOP RUN

você encerra toda a aplicação.

Se usar

GOBACK

o programa simplesmente devolve o controle.

Muito mais seguro.

O princípio da reutilização

Hoje escrevemos programas para serem reutilizados.

Um módulo pode ser chamado por:

  • Batch

  • CICS

  • IMS

  • API REST

  • MQ

  • Java

  • z/OS Connect

  • outro COBOL

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

Ele apenas faz seu trabalho.

Depois devolve o controle.

Isso é exatamente o comportamento do GOBACK.

O impacto no Language Environment (LE)

Aqui está uma das razões mais importantes.

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

O LE controla:

  • memória

  • pilha

  • heap

  • tratamento de exceções

  • inicialização

  • reutilização do runtime

Quando ocorre

STOP RUN

o LE encerra o Run Unit.

Quando ocorre

GOBACK

ele apenas retorna ao chamador.

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

O caso do RTEREUS

Pouca gente conhece essa opção.

Existe um parâmetro do LE chamado

RTEREUS

(Runtime Reuse)

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

A IBM afirma claramente:

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

Ou seja:

STOP RUN

↓

destrói o ambiente

↓

novo ambiente precisa ser criado

Enquanto

GOBACK

↓

reutiliza o ambiente

↓

menos overhead

Performance

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

Mas imagine milhares de execuções por minuto.

1000 programas

↓

cada um recria o Runtime

↓

mais CPU

Com reutilização:

Runtime permanece ativo

↓

menos inicialização

↓

menos CPU

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

E no CICS?

No CICS normalmente termina-se com

EXEC CICS RETURN

e não com

STOP RUN

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

O mesmo raciocínio vale para IMS.

O programa devolve o controle ao ambiente.

Não encerra a Run Unit.

Um exemplo interessante: DFSORT

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

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

Ou seja,

STOP RUN

↓

encerra tudo

↓

ERRADO

GOBACK

↓

retorna ao DFSORT

↓

CORRETO

Existe recomendação oficial da IBM?

Sim.

A documentação oficial afirma que:

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

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

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

Documentação oficial da IBM:

Minha recomendação para um COBOL Padawan

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

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

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

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,
Subscrever: Mensagens (Atom)