Mainframe e suas ferramentas CASE

Conheça algumas ferramentas CASE e IDE para desenvolvimento de codigo-fonte COBOL, permitindo subir via FTP para o TSO e posteriormente compila-lo e linkedita-lo em IBM Mainframe. Sumário Softwares existente no Mercado: CA Telon GENEXUS SADS Microfocus FAST Plugin Eclipse NETCOBOL ZOWE ALNOVA/ALTAMIRA Leia na Integra

IBM Tape Data Cartridge 700 GB

Conheça unidade de armazenamento CARTRIDGE Storage #MAINFRAME #IBM #STORAGE #cartridge

IBM Tape Data Cartridge 700 GB

Microsoft COBOL 5.00

Um antigo compilador COBOL desenvolvido e liberado pela Microsoft.

O mundo do Mainframe nos anos cinquenta do século passado

Bellacosa Mainframe e os titas do processamento de dados

☕ Um Café no Bellacosa Mainframe

Os Titãs do Processamento

Quando um Programador COBOL Descobre que Antes da IBM Existia uma Guerra de Gigantes — e que Quase Todos Foram Esquecidos pela História

"Nenhum império nasce sozinho. Antes de existir um rei, existiram dezenas de cavaleiros abrindo caminho."

---

Introdução

Quando alguém fala em mainframe, praticamente toda pessoa imagina imediatamente um enorme computador azul com o logotipo da IBM.

É compreensível.

Durante mais de quarenta anos a IBM tornou-se praticamente sinônimo de computação corporativa.

Mas existe uma história muito mais fascinante.

Muito antes de o IBM System/360 revolucionar o mercado em 1964, dezenas de empresas disputavam ferozmente quem construiria o cérebro eletrônico do futuro.

Algumas nasceram produzindo calculadoras mecânicas.

Outras fabricavam radares durante a Segunda Guerra Mundial.

Algumas vieram da telefonia.

Outras da indústria militar.

Muitas desapareceram.

Algumas foram compradas.

Pouquíssimas sobreviveram.

Entre 1940 e 1990 aconteceu aquilo que muitos historiadores chamam de A Guerra dos Mainframes.

Foi uma época onde praticamente cada fabricante possuía sua própria arquitetura, linguagem, periféricos, sistema operacional e filosofia de desenvolvimento.

Era um verdadeiro universo paralelo.

Hoje vamos prestar homenagem aos gigantes que construíram a informática moderna.

Pegue seu café.

Vamos viajar quase cinquenta anos no tempo.

---

A Era dos Pioneiros (1940-1955)

Antes mesmo da palavra computador existir da forma que conhecemos, grandes empresas já investiam milhões em máquinas capazes de resolver cálculos militares.

O cenário era dominado por necessidades extremamente específicas:

• Guerra

• Balística

• Criptografia

• Estatística

• Censos

• Engenharia

Os computadores ocupavam salas inteiras.

Consumiam quilowatts.

Possuíam milhares de válvulas.

Falhavam diariamente.

Mesmo assim eram considerados milagres tecnológicos.

---

IBM

O Gigante que já Nasceu Grande

Fundação: 1911

Origem: CTR (Computing Tabulating Recording Company)

Especialidade inicial:

• Cartões perfurados

• Máquinas Hollerith

• Relógios de ponto

• Equipamentos administrativos

Durante décadas a IBM dominou completamente o processamento por cartões.

Quando os computadores eletrônicos apareceram ela já possuía milhares de clientes.

Essa vantagem seria praticamente impossível de superar.

Modelo histórico

IBM 701

Ano:

1952

Conhecido como:

Defense Calculator

Foi o primeiro computador científico comercial da IBM.

---

Remington Rand

Pouca gente lembra dela.

Mas foi a empresa responsável por comercializar um dos computadores mais famosos da história.

Modelo

UNIVAC I

Ano:

1951

Curiosidade:

Foi o primeiro computador comercial vendido nos Estados Unidos.

O UNIVAC ficou mundialmente famoso por prever corretamente o resultado das eleições americanas de 1952.

A televisão ficou em choque.

Foi o momento em que o público percebeu que computadores poderiam "pensar".

---

Burroughs

Para muitos programadores COBOL veteranos, falar Burroughs ainda desperta nostalgia.

A empresa apostava em arquiteturas completamente diferentes.

Enquanto quase todo mundo pensava em registradores, a Burroughs acreditava em máquinas orientadas por pilha (stack machines).

Décadas depois esse conceito voltaria a aparecer nas máquinas virtuais Java.

Modelo clássico

Burroughs B5000

1961

Foi um dos computadores mais elegantes já projetados.

Era praticamente feito para linguagens de alto nível.

Muitos historiadores afirmam que seu projeto estava décadas à frente do tempo.

---

Easter Egg

A arquitetura da Burroughs lembra bastante o funcionamento interno da JVM.

Sim.

Muito antes do Java existir.

---

RCA

A Radio Corporation of America também entrou na disputa.

Ela possuía enorme experiência em eletrônica.

Produziu computadores voltados principalmente para governo.

Modelo famoso:

RCA Spectra 70

1965

Seu objetivo era competir diretamente com o System/360.

Não conseguiu.

---

Honeywell

Originalmente conhecida por equipamentos industriais.

Entrou forte no mercado de computadores corporativos.

Modelo famoso

Honeywell 200

1963

Uma curiosidade incrível.

Ele foi projetado para executar programas do IBM 1401 com poucas modificações.

Era praticamente um "compatível IBM".

Na época isso foi revolucionário.

---

Control Data Corporation (CDC)

Se existiu um gênio absoluto da engenharia de computadores, seu nome era:

Seymour Cray.

Antes dos supercomputadores Cray, ele trabalhava na CDC.

Modelo famoso

CDC 6600

1964

Considerado por muitos o primeiro supercomputador verdadeiro.

Era mais rápido que praticamente qualquer concorrente.

---

NCR

National Cash Register.

Começou fabricando caixas registradoras.

Depois migrou para sistemas bancários.

Modelo famoso

NCR Century

1976

Muito utilizado em bancos.

---

General Electric

Pouca gente lembra, mas a GE também produziu grandes computadores.

Modelo

GE-600

1965

Influenciou diretamente o desenvolvimento do MULTICS.

Sem MULTICS talvez nunca existisse o UNIX.

---

Digital Equipment Corporation (DEC)

Embora fosse conhecida pelos minicomputadores, merece enorme respeito.

O PDP-8 democratizou a computação.

Depois veio o VAX.

Modelo famoso

VAX-11/780

1977

Era tão poderoso que muitas empresas deixaram de comprar mainframes médios.

---

Sperry

Resultado da fusão da Sperry Rand.

Modelo famoso

UNIVAC 1100

Década de 1970

Muito utilizado por governos.

---

Fujitsu

Enquanto o Ocidente brigava entre IBM e Burroughs, o Japão crescia silenciosamente.

Modelo famoso

FACOM M-190

1974

Os japoneses investiram pesadamente em compatibilidade IBM.

---

Hitachi

Outro gigante japonês.

Modelo famoso

HITAC M Series

Década de 1970

Grande presença em bancos asiáticos.

---

NEC

Modelo famoso

ACOS Series

1974

Ainda hoje existem versões modernas.

---

Siemens

Alemanha.

Modelo famoso

BS2000

Década de 1970

Muito utilizado na Europa.

---

Bull

Orgulho francês.

Modelo famoso

GCOS

Década de 1970

A Bull sobreviveu durante décadas oferecendo alternativas europeias.

---

ICL

Reino Unido.

Modelo famoso

ICL 2900

1974

Representava a tentativa britânica de manter independência tecnológica.

---

Olivetti

Conhecida pelas máquinas de escrever.

Também entrou na corrida.

Modelo

Elea 9003

1959

Projeto extremamente elegante.

---

Wang Laboratories

Muito forte em processamento de textos.

Modelo

VS Series

Década de 1980

---

Prime Computer

Muito utilizada em universidades.

Modelo

Prime 750

1979

---

A Revolução que Mudou Tudo

Em 1964 a IBM lançou algo que redefiniu completamente a indústria.

IBM System/360

Não era apenas um computador.

Era uma família inteira.

Pela primeira vez um programa escrito em um modelo podia funcionar em outro.

Hoje isso parece óbvio.

Na época era praticamente ficção científica.

O investimento foi colossal.

Mais de cinco bilhões de dólares da época.

Foi uma das maiores apostas industriais do século XX.

---

O Nascimento da Compatibilidade

Depois do sucesso do System/360, praticamente todas as empresas começaram a copiar a estratégia da IBM.

Compatibilidade virou sobrevivência.

Foi nesse momento que surgiram fabricantes conhecidos como:

Plug Compatible Manufacturers (PCMs)

Entre eles:

• Amdahl

• Hitachi

• Fujitsu

• National Advanced Systems

Essas empresas fabricavam computadores capazes de executar software IBM.

Era como vender peças compatíveis para um automóvel extremamente popular.

---

Os Grandes Modelos que Marcaram Época

Ano	Modelo	Fabricante
1951	UNIVAC I	Remington Rand
1952	IBM 701	IBM
1959	Elea 9003	Olivetti
1961	B5000	Burroughs
1963	Honeywell 200	Honeywell
1964	CDC 6600	CDC
1964	System/360	IBM
1965	Spectra 70	RCA
1965	GE-600	General Electric
1974	ICL 2900	ICL
1974	FACOM M-190	Fujitsu
1974	ACOS	NEC
1977	VAX 11/780	DEC
1980	IBM 3081	IBM
1985	IBM 3090	IBM
1990	IBM ES/9000	IBM

---

Curiosidades

O primeiro "clone"

Honeywell praticamente criou computadores capazes de executar programas IBM.

Hoje chamaríamos isso de compatibilidade binária.

---

Burroughs inspirou o futuro

Seu conceito de pilha antecipou tecnologias usadas décadas depois.

---

IBM quase faliu

O investimento no System/360 foi tão gigantesco que muitos acionistas acreditavam que seria o fim da empresa.

Foi exatamente o contrário.

---

Seymour Cray saiu para fundar sua própria empresa

E acabou criando alguns dos computadores mais rápidos do planeta.

---

A Guerra Fria acelerou tudo

Sem investimentos militares, provavelmente a evolução teria levado mais vinte anos.

---

Easter Eggs para Programadores COBOL

☕ O COBOL nasceu em 1959 e foi pensado para rodar em computadores de diferentes fabricantes. Antes do System/360, portar um programa entre máquinas era quase uma aventura arqueológica.

☕ O B5000 da Burroughs foi um dos primeiros computadores desenhados pensando em linguagens de alto nível, reduzindo a dependência da programação em Assembly.

☕ Muitos bancos brasileiros já utilizaram equipamentos Burroughs, UNIVAC, Honeywell e NCR antes de consolidarem seus parques em IBM.

☕ O nome "mainframe" só se popularizou porque a unidade central ficava instalada no main frame (gabinete principal) que concentrava CPU, memória e canais de E/S.

☕ Empresas como Amdahl provaram que era possível inovar mesmo dentro do ecossistema IBM, oferecendo equipamentos compatíveis com melhor relação custo-desempenho.

---

Dicas para Quem Deseja Estudar a História dos Mainframes

Se você deseja compreender realmente a evolução do IBM Z, vale a pena estudar a história dos seus concorrentes. Muitas ideias consideradas modernas nasceram em empresas que já não existem mais:

• Entenda a arquitetura do Burroughs B5000 para conhecer os conceitos de máquinas orientadas por pilha.

• Estude o UNIVAC I para compreender a transição dos cartões perfurados para a computação eletrônica comercial.

• Pesquise o CDC 6600 para entender como Seymour Cray revolucionou o paralelismo e a alta performance.

• Compare o IBM System/360 com seus sucessores (System/370, 308X, 3090, ES/9000) para perceber como a compatibilidade de software se tornou um dos maiores patrimônios da IBM.

• Explore a história da Honeywell, Bull, ICL e Fujitsu para descobrir como diferentes países buscaram independência tecnológica durante a Guerra Fria.

---

O Fim da Guerra e o Monopólio da IBM

Durante os anos 1970 e 1980, a competição diminuiu drasticamente.

A IBM havia conseguido algo extraordinário: transformar sua arquitetura em um padrão de mercado. Quem escolhia um System/370 ou, mais tarde, um 3090, investia em um ecossistema completo de hardware, sistemas operacionais, linguagens, bancos de dados, ferramentas e suporte técnico. Mudar de fornecedor passou a significar reescrever aplicações inteiras, treinar equipes e substituir uma infraestrutura construída ao longo de décadas.

Enquanto isso, muitos concorrentes enfrentaram dificuldades:

• A Burroughs fundiu-se com a Sperry, formando a Unisys em 1986.

• A CDC abandonou gradualmente o mercado de mainframes para concentrar esforços em supercomputação.

• A RCA vendeu sua divisão de computadores.

• A Honeywell deixou o segmento após diversas reestruturações.

• Empresas europeias como ICL, Bull e Siemens reduziram sua participação ou migraram para outros mercados.

• Fabricantes japoneses permaneceram relevantes, mas em grande parte adotando estratégias de compatibilidade com a arquitetura IBM.

Esse cenário levou muitos analistas da época a falar em um "monopólio de fato" da IBM no universo dos grandes sistemas corporativos. Embora outras empresas continuassem existindo e produzindo soluções importantes, a influência do ecossistema IBM tornou-se dominante.

Mas há uma ironia digna do Bellacosa Mainframe.

A IBM venceu a guerra dos fabricantes, porém jamais venceu sozinha.

Cada concorrente deixou uma peça fundamental no quebra-cabeça da computação moderna. O conceito de compatibilidade, as arquiteturas orientadas por pilha, a alta performance, os sistemas operacionais multiprogramados, a confiabilidade extrema e até muitas ideias presentes hoje no IBM Z, em máquinas virtuais e em ambientes de nuvem nasceram ou amadureceram graças à ousadia desses gigantes.

Assim, quando um programador COBOL executa um simples EXEC CICS, um READ VSAM ou um SELECT no Db2, ele também carrega um pouco do legado de engenheiros da Burroughs, da Honeywell, da UNIVAC, da CDC, da DEC, da Bull, da Fujitsu, da Hitachi e de tantas outras empresas que desafiaram os limites da tecnologia.

Porque a verdadeira história dos mainframes não é apenas a história da IBM.

É a história de uma geração de visionários que, entre 1940 e 1990, construiu as fundações invisíveis sobre as quais o mundo digital continua funcionando até hoje. E essa merece ser lembrada, estudada e homenageada por todos que amam a computação clássica.

Um pouco da historia do Mainframe Conheça os grandes fabricantes nos anos 50.

 

☕ OPERADOR, TALVEZ A MATRIX NÃO CHEGUE DE UMA VEZ: VIVENDO NA REALIDADE VIRTUAL

 

Bellacosa Mainframe uma vida artificial totalmente feliz numa realidade virtual

☕ OPERADOR, TALVEZ A MATRIX NÃO CHEGUE DE UMA VEZ

Muita gente imagina que a transição será:

MUNDO REAL
↓
CÁPSULA
↓
MATRIX

---

Mas historicamente as mudanças tecnológicas raramente acontecem assim.

---

Elas acontecem em pequenas etapas.

---

Primeiro:

• televisão

Depois:

• videogames

Depois:

• internet

Depois:

• redes sociais

Depois:

• smartphones

Depois:

• realidade virtual

Depois:

• IA conversacional

---

Cada etapa aumenta o tempo que passamos em ambientes artificiais.

---

JÁ EXISTEM PESSOAS QUE PREFEREM O MUNDO DIGITAL

Sem exagero.

---

Hoje existem pessoas que:

• trabalham online

• estudam online

• namoram online

• jogam online

• possuem amigos online

---

Uma parte significativa da experiência humana já acontece em ambientes digitais.

---

O QUE FALTA?

O gargalo atual é a imersão.

---

Ainda existe uma diferença enorme entre:

TELA

e

REALIDADE

---

Mas imagine daqui a 30 ou 50 anos.

---

A PERGUNTA MUDA

A questão deixa de ser:

"É real?"

e passa a ser:

"É melhor?"

💣

---

O ARGUMENTO DE CYPHER

Lembra da nossa conversa sobre Cypher?

---

Ele já estava fazendo essa pergunta.

---

Se uma simulação consegue fornecer:

• felicidade

• significado

• amor

• aventura

---

Por que alguém escolheria uma realidade objetivamente pior?

---

O EPISÓDIO DE ARQUIVO X

Acho que você está lembrando de um episódio que explora exatamente esse medo.

O tema apareceu em várias séries dos anos 90:

• The X-Files

• The Outer Limits

• VR.5

• Harsh Realm

---

A ideia era:

Pessoas marginalizadas descobrem um mundo virtual melhor.

---

E gradualmente abandonam o físico.

---

Na época parecia ficção.

---

Hoje parece previsão.

---

O PARADOXO

Existe uma armadilha interessante.

---

Imagine dois cenários.

---

Cenário A

Vida real.

• dores

• envelhecimento

• doenças

• limitações

---

Cenário B

Vida simulada.

• saúde perfeita

• aventuras

• liberdade

• aparência ideal

---

A pergunta não é técnica.

---

A pergunta é filosófica.

---

O QUE TORNA UMA VIDA REAL?

Se você ama alguém numa simulação.

---

O sentimento é falso?

---

Seu cérebro produz:

• alegria

• tristeza

• paixão

da mesma forma.

---

O PROBLEMA QUE POUCOS PERCEBEM

As pessoas imaginam que todos correriam para a simulação.

---

Eu não tenho tanta certeza.

---

Porque o ser humano também valoriza:

• autenticidade

• imprevisibilidade

• conquista real

---

Existe uma satisfação especial em saber:

"Isso aconteceu de verdade."

---

BELLACOSA MAINFRAME

Imagine dois sistemas.

---

Sistema A:

100% REAL

FALHAS:
MUITAS

DOR:
ALTA

IMPREVISIBILIDADE:
ALTA

---

Sistema B:

100% SIMULADO

FALHAS:
ZERO

FELICIDADE:
CONFIGURÁVEL

RISCO:
MÍNIMO

---

Aos 20 anos:

ESCOLHER SISTEMA A

---

Aos 50 anos:

😂

SOLICITAR APRESENTAÇÃO COMERCIAL
DO SISTEMA B

---

O CENÁRIO MAIS PROVÁVEL

Acho improvável que vejamos pessoas entrando em cápsulas e abandonando imediatamente o corpo.

---

Mas acho muito provável que vejamos algo mais sutil.

---

Pessoas passando:

• 2 horas

• 4 horas

• 8 horas

• 12 horas

por dia em realidades artificiais extremamente convincentes.

---

E então surge a pergunta que assombrava os roteiristas dos anos 90.

---

Quando a experiência simulada se tornar mais agradável que a física...

QUANTAS PESSOAS VOLTARÃO VOLUNTARIAMENTE?

💣

---

☕💣👁️ VEREDITO FINAL DO OPERADOR

O mais curioso é que filmes como Matrix, The Thirteenth Floor, eXistenZ, Vanilla Sky, Arquivo X e tantas outras obras talvez nunca tenham sido sobre tecnologia.

Talvez fossem sobre uma pergunta muito mais humana:

Se pudéssemos escolher entre uma realidade dura e imperfeita e uma ilusão confortável e significativa...

quantos de nós realmente escolheríamos a verdade?

Quando eu era jovem, a resposta parecia óbvia.

Hoje, como você observou com humor e honestidade, a pergunta parece muito mais difícil.

E talvez essa seja a razão pela qual essas histórias continuam fascinando pessoas décadas depois.

Porque elas não falam sobre máquinas.

Elas falam sobre o que cada um de nós considera mais valioso:

VERDADE
OU
EXPERIÊNCIA

☕👁️📂💣

E não tenho certeza se a humanidade inteira daria a mesma resposta.

Seu LinkedIn é o Novo Terminal 3270 da Sua Carreira

 

Bellacosa Mainframe e o perfil do linkedin

☕ Um Café no Bellacosa Mainframe

Seu LinkedIn é o Novo Terminal 3270 da Sua Carreira

Como um Programador COBOL Pode Construir Autoridade, Ser Encontrado e Abrir Portas Sem Depender Apenas do Currículo

"No mundo do Mainframe aprendemos que um JOB mal parametrizado pode nunca chegar à fila de execução. No LinkedIn acontece exatamente a mesma coisa: um perfil mal configurado pode impedir que grandes oportunidades sequer encontrem você."

---

Durante muitos anos bastava ter um bom currículo em PDF.

Hoje isso mudou.

Muito.

Se um recrutador procura um especialista em COBOL, CICS, DB2 ou IBM Z, dificilmente ele começará perguntando aos amigos.

Ele vai pesquisar.

E onde?

No LinkedIn.

O LinkedIn deixou de ser uma rede social para se tornar uma enorme base de dados profissional, quase como um catálogo do RACF misturado com um Google especializado em pessoas.

Para quem trabalha com Mainframe, isso representa uma oportunidade enorme.

O problema é que muitos programadores COBOL ainda tratam o LinkedIn como um repositório de currículo.

É um erro.

Seu perfil é muito mais do que isso.

Ele é:

• seu cartão de visitas;

• seu portfólio;

• sua marca pessoal;

• sua prova social;

• sua página de vendas profissional;

• e principalmente...

• um mecanismo de busca.

Hoje vamos tomar um café e entender por que um bom perfil pode abrir portas que um currículo sozinho jamais abriria.

---

Imagine o LinkedIn como um Catálogo do z/OS

Todo programador COBOL conhece o catálogo do sistema.

Quando um programa precisa localizar um dataset, ele consulta o catálogo.

Se o dataset não estiver catalogado...

Ele praticamente não existe.

Agora pense na carreira.

Os recrutadores fazem buscas como:

COBOL CICS DB2 São Paulo

ou

IBM Z Modernization

ou

Java Mainframe APIs

Se seu perfil não contém essas informações...

Você simplesmente não aparece.

É como tentar executar um JOB apontando para um dataset inexistente.

---

O Algoritmo Também Faz "SEARCH"

Muitos acreditam que o LinkedIn funciona apenas mostrando publicações.

Na verdade, existe uma enorme camada de indexação.

Ele analisa:

• título

• resumo

• experiências

• habilidades

• certificados

• publicações

• palavras-chave

É praticamente um mecanismo de SEO.

Aliás...

Curiosidade

SEO significa:

Search Engine Optimization

Ou seja...

O LinkedIn possui seu próprio "Google interno".

---

1. Sua Foto é o IPL da Sua Marca

No Mainframe existe um momento crítico.

O IPL.

Sem ele...

Nada sobe.

Sua foto é exatamente isso.

Ela inicializa a percepção das pessoas.

Em menos de um segundo alguém decide:

"Esse perfil parece profissional."

ou

"Depois eu vejo."

Não precisa ser uma fotografia de estúdio.

Mas precisa transmitir:

• confiança;

• clareza;

• profissionalismo.

Nada de:

❌ foto da praia

❌ churrasco

❌ casamento

❌ cachorro cobrindo metade do rosto

❌ selfie no espelho

---

Bellacosa Dica

Se sua foto parece saída de uma câmera VGA de 2003...

Atualize.

Você provavelmente evoluiu muito desde então.

Seu perfil também deveria.

---

2. O Título é Seu Cartão Perfurado Moderno

Quem viveu a era dos cartões perfurados sabe:

As primeiras colunas eram fundamentais.

Elas identificavam praticamente tudo.

O título do LinkedIn funciona da mesma maneira.

Nunca escreva apenas:

Analista de Sistemas

Existem milhões.

Explique seu valor.

Por exemplo:

Especialista IBM Z | COBOL | CICS | DB2 | APIs REST | Modernização | IA para Mainframe

Observe algo interessante.

Além de explicar quem você é...

Esse título contém inúmeras palavras-chave.

Isso ajuda o algoritmo.

E ajuda humanos.

---

Easter Egg nº 1

Os antigos cartões IBM possuíam 80 colunas.

O LinkedIn também possui um limite de espaço.

Moral da história?

Na computação...

Espaço sempre foi precioso.

---

3. O Resumo Conta Sua História

Não escreva:

Sou dedicado.

Trabalho em equipe.

Sou proativo.

Isso aparece em milhares de perfis.

Conte uma história.

Algo como:

"Comecei minha carreira desenvolvendo sistemas bancários em COBOL..."

Depois explique:

• quais problemas resolve;

• quais tecnologias domina;

• quais resultados entrega.

Pessoas lembram histórias.

Não listas.

---

Curiosidade

Nos livros de marketing existe um conceito chamado:

Storytelling.

Nos livros de engenharia chamamos de:

Documentação que alguém realmente lê.

---

4. Habilidades Não São Decoração

Imagine um catálogo DB2.

Quanto melhor o índice...

Mais rápido a consulta.

As habilidades funcionam como índices.

Escolha aquilo pelo qual deseja ser encontrado.

Não adianta querer trabalhar com IA e listar apenas:

• Windows

• Word

• Excel

Ou querer trabalhar com Mainframe e esquecer:

• COBOL

• JCL

• DB2

• CICS

• VSAM

• IMS

• RACF

---

Easter Egg nº 2

Um índice ruim no DB2 piora performance.

Um perfil sem habilidades piora sua encontrabilidade.

Os conceitos são surpreendentemente parecidos.

---

5. Experiência Deve Mostrar Resultado

Muitos escrevem:

Desenvolvimento COBOL.

Isso não diz absolutamente nada.

Prefira:

Desenvolvi solução responsável pelo processamento diário de aproximadamente 8 milhões de transações bancárias utilizando COBOL, CICS e DB2, reduzindo em 35% o tempo médio de processamento após otimizações SQL.

Agora existe contexto.

Existe impacto.

Existe credibilidade.

---

Bellacosa Insight

Empresas contratam resultados.

Não apenas tecnologias.

---

6. Recomendações Valem Ouro

Imagine dois perfis.

O primeiro diz:

Sou excelente.

O segundo possui dez clientes dizendo isso.

Qual inspira mais confiança?

Exatamente.

Recomendações são prova social.

Peça para:

• líderes;

• clientes;

• colegas;

• professores;

• parceiros.

Mas peça algo específico.

Não:

Excelente profissional.

Prefira:

Liderou a migração COBOL reduzindo o tempo de deploy em 60%.

---

7. Revise Seus Contatos

Parece óbvio.

Mas acontece muito.

Email desatualizado.

Site fora do ar.

GitHub vazio.

Portfólio quebrado.

Imagine um recrutador tentando entrar em contato.

Ele consegue?

---

8. Personalize Sua URL

Ao invés de:

linkedin.com/in/usuario-874635829182

Utilize:

linkedin.com/in/vagnerbellacosa

Fica mais elegante.

Mais fácil de memorizar.

Mais profissional.

---

Curiosidade

Na internet chamamos isso de identidade digital.

No RACF chamaríamos de um bom User ID.

---

9. Destaques Funcionam Como um Portfólio

Pouca gente usa.

E justamente por isso poucos se diferenciam.

Coloque:

• artigos;

• GitHub;

• apresentações;

• vídeos;

• cursos;

• newsletter;

• projetos.

Mostre.

Não apenas diga.

---

Bellacosa Dica

Seu código fala.

Seu conteúdo também.

---

10. Certificações

Não transforme seu perfil em uma coleção infinita.

Escolha aquelas realmente relevantes.

IBM.

AWS.

Microsoft.

Google.

Oracle.

Cisco.

E principalmente...

Certificações relacionadas ao caminho que deseja seguir.

---

Easter Egg nº 3

Ter cinquenta certificados de ferramentas que nunca utilizou lembra muito instalar cinquenta produtos SMP/E sem nunca executar um único deles.

---

11. Educação Nunca Para

A maior diferença entre profissionais seniores e iniciantes não é idade.

É aprendizado contínuo.

Quem trabalha com Mainframe hoje também aprende:

Python.

Java.

Cloud.

Git.

DevOps.

Docker.

IA.

O mercado mudou.

Nós também devemos mudar.

---

12. Palavras-chave São o Novo Índice VSAM

Esse talvez seja um dos pontos mais ignorados.

Se você deseja aparecer quando pesquisarem:

COBOL

Então escreva COBOL.

Se quer aparecer para:

IBM Z

Escreva IBM Z.

Se domina:

• CICS

• DB2

• MQ

• DevOps

• Git

• APIs

• REST

Inclua naturalmente no perfil.

---

Curiosidade

O algoritmo entende contexto.

Mas ele ainda depende bastante das palavras presentes no texto.

---

13. Conteúdo Gera Autoridade

Aqui está o divisor de águas.

Imagine dois especialistas.

Os dois possuem o mesmo conhecimento.

Um publica toda semana.

Outro nunca publica.

Quem será lembrado?

Quem ensina.

---

Bellacosa Insight

Conhecimento escondido gera satisfação pessoal.

Conhecimento compartilhado gera oportunidades.

---

14. Sua Capa é um Outdoor

Antes mesmo de ler seu perfil...

As pessoas veem sua capa.

Ela comunica seu posicionamento.

Exemplo:

IBM Champion

Especialista IBM Z

COBOL • CICS • DB2

Autor da Newsletter

Um Café no Bellacosa Mainframe

Em segundos fica claro quem você é.

---

15. Aberto ao Trabalho

Configure corretamente.

Não deixe em branco.

Informe:

• remoto;

• híbrido;

• presencial;

• cidades;

• países;

• cargos desejados.

Ajude o algoritmo.

---

16. O Modo Criador Acabou...

...mas a criação continua.

O botão desapareceu.

As funcionalidades não.

Continue produzindo:

• artigos;

• newsletters;

• vídeos;

• lives;

• documentos;

• PDFs.

---

Curiosidade

Ferramentas mudam.

Princípios permanecem.

Assim como o COBOL continua processando bilhões de transações.

---

17. Networking Não é Pedir Emprego

Imagine conhecer alguém hoje.

Cinco minutos depois:

"Você pode me indicar?"

Complicado.

Networking é relacionamento.

Primeiro:

comente.

Ajude.

Compartilhe.

Converse.

Depois as oportunidades aparecem naturalmente.

---

Bellacosa Dica

Networking é igual ao buffer de um CICS.

Primeiro você alimenta.

Depois recebe resposta.

---

18. Atualize Seu Perfil

Tecnologias evoluem.

Sua carreira também.

A cada três meses revise:

• experiências;

• cursos;

• foto;

• banner;

• resumo;

• certificações;

• projetos.

Seu perfil deve representar quem você é hoje.

---

O Erro que Quase Todo Programador Júnior Comete

Esperar ter dez anos de experiência para publicar.

Não faça isso.

Publique sua evolução.

Mostre:

"Hoje aprendi..."

"Hoje descobri..."

"Hoje resolvi..."

As pessoas gostam de acompanhar jornadas.

Não apenas resultados finais.

---

O LinkedIn Também é um Laboratório

Você pode testar:

• títulos;

• formatos;

• horários;

• imagens;

• artigos;

• vídeos.

Observe quais geram mais interação.

Ajuste.

Repita.

É praticamente um ciclo DevOps aplicado à marca pessoal:

Planejar → Publicar → Medir → Aprender → Melhorar.

---

Curiosidade Histórica

No início da computação, os profissionais eram conhecidos principalmente dentro de suas empresas. Hoje, graças ao LinkedIn, um desenvolvedor COBOL em uma cidade do interior pode compartilhar conhecimento com profissionais do mundo inteiro. O alcance da sua reputação deixou de depender apenas da empresa onde trabalha e passou a depender também do valor que entrega publicamente.

---

Easter Egg Final ☕

Se você chegou até aqui, percebeu que praticamente todos os conceitos discutidos possuem um equivalente no universo Mainframe:

• Foto → IPL da sua marca.

• Título → Cartão perfurado com as informações essenciais.

• Palavras-chave → Índices do DB2 e do VSAM.

• Perfil → Catálogo do sistema.

• Conteúdo → Log de auditoria da sua evolução.

• Networking → Comunicação entre regiões CICS.

• Recomendações → RC=0000 emitido por quem já trabalhou com você.

• Atualização periódica → RUNSTATS e REORG da sua carreira.

• Autoridade → Um sistema em produção que entrega resultados todos os dias.

Perceba como os princípios são os mesmos: organização, consistência, documentação, evolução contínua e foco em entregar valor.

Conclusão: Sua Carreira Também Precisa de Manutenção Preventiva

No Mainframe aprendemos que os melhores sistemas não são aqueles que nunca precisam de manutenção, mas os que são constantemente monitorados, ajustados e aprimorados. Com a carreira acontece exatamente o mesmo.

Seu perfil no LinkedIn não deve ser tratado como um documento estático criado no dia da contratação e esquecido no dia seguinte. Ele é um sistema vivo, que precisa acompanhar sua evolução técnica, seus projetos, suas conquistas e sua forma de contribuir com a comunidade.

Para um programador júnior, o LinkedIn é uma oportunidade de mostrar potencial antes mesmo de acumular décadas de experiência. Para um profissional sênior, é a vitrine que transforma conhecimento em autoridade reconhecida. E, para ambos, publicar conteúdo, manter o perfil atualizado e construir relacionamentos genuínos são práticas que aumentam a visibilidade e facilitam que oportunidades encontrem você.

No fim das contas, o melhor perfil não é o que parece perfeito. É o que demonstra aprendizado contínuo, resultados reais e vontade de compartilhar conhecimento.

Porque, assim como no IBM Z, confiabilidade não se conquista em um único JOB. Ela é construída uma execução de cada vez.

E lembre-se: ninguém encontra um dataset que não está catalogado. Da mesma forma, o mercado dificilmente encontrará um excelente profissional que permanece invisível. Transforme seu LinkedIn em um ambiente bem documentado, bem indexado e atualizado. Afinal, sua próxima oportunidade pode começar com uma simples pesquisa feita por alguém que ainda não conhece seu nome — mas está procurando exatamente as habilidades que você tem para oferecer.

Nos vemos no próximo café. ☕

JCL e USS: Eu Sabia Fazer... Até Descobrir que Precisava Aprender de Novo

 

Bellacosa Mainframe jcl e uss eu sabia fazer ate que li esse artigo

☕ Um Café no Bellacosa Mainframe

Eu Sabia Fazer... Até Descobrir que Precisava Aprender de Novo

JCL, USS e a maior lição que um Programador Mainframe pode aprender na era da Modernização

"O conhecimento verdadeiro não está em decorar comandos. Está em reconhecer padrões, independentemente da linguagem utilizada."

---

Existe um momento curioso na carreira de praticamente todo profissional de tecnologia.

Não importa se você programa em COBOL, Java, Python ou C.

Não importa se trabalha em Linux, Windows ou IBM z/OS.

Mais cedo ou mais tarde você olha para uma tarefa simples — algo que faz há vinte anos — e pensa:

"Espera... como é mesmo que faz isso aqui?"

A primeira reação costuma ser de frustração.

"Será que estou esquecendo?"

Na maioria das vezes, não.

Você continua sabendo exatamente o que precisa ser feito.

O problema é que o ambiente mudou.

E quando o ambiente muda, a maneira de conversar com ele também muda.

Foi exatamente isso que aconteceu quando muitos profissionais Mainframe conheceram o USS (Unix System Services).

Eles não estavam aprendendo um novo trabalho.

Estavam aprendendo uma nova língua.

E, curiosamente, isso costuma ser muito mais difícil.

Pegue uma xícara de café.

Hoje vamos conversar sobre uma das maiores armadilhas da modernização do IBM Z.

---

Quando o piloto entra em outro avião

Imagine um comandante com trinta anos de experiência pilotando um Boeing 737.

Um belo dia ele recebe treinamento para voar um Airbus A320.

Ele esqueceu como voar?

Claro que não.

Ele continua entendendo:

• sustentação

• velocidade

• meteorologia

• navegação

• segurança

Tudo isso continua igual.

O que muda é:

• onde fica cada botão;

• como os sistemas conversam;

• quais procedimentos devem ser executados.

Durante alguns dias ele parece um iniciante.

Mas ele não voltou ao zero.

Ele apenas precisa reconstruir seus reflexos.

É exatamente isso que acontece quando um programador experiente em JCL começa a trabalhar no USS.

---

O erro mais comum dos iniciantes

Quando um programador júnior aprende COBOL, tudo é novidade.

Ele aceita naturalmente ser iniciante.

Mas existe um problema curioso com profissionais experientes.

Quando entram em um ambiente parecido...

...eles esperam que tudo funcione igual.

E aí começam as comparações.

"Cadê o EXEC PGM?"

"Cadê o DD?"

"Cadê o DSN?"

"Cadê o DISP?"

"Cadê o SYSIN?"

A resposta é simples.

Eles continuam existindo...

...mas não da forma que você espera.

---

O IBM z/OS possui dois universos

Muitos iniciantes imaginam que existe um único ambiente Mainframe.

Na verdade existem dois mundos convivendo harmoniosamente.

Mundo tradicional

• Batch

• JES2/JES3

• JCL

• DFSORT

• IDCAMS

• IEBGENER

• TSO/ISPF

• Dataset

É o universo clássico.

É onde o Mainframe cresceu.

---

Mundo USS

Agora imagine colocar um Unix inteiro dentro do z/OS.

Foi exatamente isso que a IBM fez.

O USS oferece:

• Shell

• Bash

• Diretórios

• Arquivos

• Scripts

• Permissões POSIX

• OpenSSH

• Python

• Git

• Java

• Node.js

• Zowe CLI

Sem sair do z/OS.

Esse detalhe é importantíssimo.

O USS não substitui o Mainframe.

Ele amplia o Mainframe.

---

O maior equívoco sobre o USS

Muita gente pensa:

"Agora o Mainframe virou Linux."

Não.

Nem perto disso.

O Kernel continua sendo o z/OS.

O gerenciamento de memória continua sendo do z/OS.

O Workload Manager continua sendo do z/OS.

O RACF continua protegendo recursos.

O JES continua executando Batch.

O USS apenas fornece outra interface para conversar com o sistema operacional.

É como trocar o painel de instrumentos de um carro.

O motor continua o mesmo.

---

Dataset não morreu

Uma das primeiras confusões acontece aqui.

Durante décadas escrevemos:

CLIENTE.VENDAS.ARQUIVO

No USS passamos a enxergar algo como:

/u/vagner/clientes/vendas.txt

A primeira impressão é:

"Agora só existem arquivos."

Não.

Os datasets continuam existindo.

Inclusive é possível acessá-los a partir do USS.

Da mesma forma, programas Batch conseguem trabalhar com arquivos do USS.

Os dois mundos conversam.

E isso é fantástico.

---

DD Statements versus Pathnames

Durante anos aprendemos:

//INPUT DD DSN=CLIENTE.INPUT,DISP=SHR

O programa COBOL nunca conhecia o nome físico do dataset.

Ele apenas dizia:

SELECT CLIENTES
ASSIGN TO INPUT.

O JCL fazia a ligação.

Isso separava infraestrutura do programa.

No USS isso muda.

Agora normalmente fazemos:

programa entrada.txt saida.txt

Ou

fopen("/u/input/clientes.txt")

É outra filosofia.

Não melhor.

Não pior.

Diferente.

---

EXEC PGM virou comando

No Batch.

//STEP01 EXEC PGM=COBPROG

No USS.

./cobprog

Ou

cobprog

A intenção continua exatamente igual.

Executar um programa.

Mas agora o pensamento é imperativo.

Você manda executar imediatamente.

Enquanto o JCL descreve um processo inteiro.

---

Ordenação: o exemplo perfeito

Durante décadas utilizamos DFSORT.

//STEP EXEC PGM=SORT

Depois:

SORT FIELDS=(1,10,CH,A)

No USS tudo parece diferente.

Agora temos:

sort arquivo.txt

Ou:

syncsort

Ou pipelines:

cat clientes.txt | sort

Ou:

sort clientes.txt > clientes_ordenados.txt

Você continua ordenando.

Mas agora conversa diretamente com o sistema operacional.

---

Copiar arquivos

Batch.

IEBGENER.

PGM=IEBGENER

USS.

cp origem destino

Uma linha.

Fim.

---

Excluir arquivos

Batch.

DELETE CLIENTE.ARQ

USS.

rm arquivo

Mesma ação.

Outra gramática.

---

O verdadeiro desafio é psicológico

Essa talvez seja a parte mais interessante.

Quando tudo é completamente novo...

Nosso cérebro aceita aprender.

Mas quando algo parece familiar...

Tentamos usar nossos velhos reflexos.

É aí que começamos a tropeçar.

É como trocar de carro.

Você continua sabendo dirigir.

Mas procura o limpador de para-brisa no lugar errado.

---

O cérebro funciona por padrões

Programadores experientes não decoram comandos.

Eles criam padrões mentais.

Por exemplo.

Quando alguém fala:

"Preciso copiar dados."

Seu cérebro já responde:

IEBGENER.

Isso virou memória muscular.

Agora imagine trocar isso por:

cp

Não é difícil.

Mas o cérebro insiste em procurar o antigo caminho.

---

O mesmo acontece em outras tecnologias

COBOL → Java

Você continua escrevendo lógica.

Mudam:

• sintaxe;

• paradigma;

• bibliotecas.

---

DB2 → PostgreSQL

SQL continua sendo SQL.

Mas:

• utilitários;

• administração;

• backup;

• tuning;

mudam completamente.

---

ISPF → VS Code

Você continua editando programas.

Mas os atalhos mudam.

A organização muda.

O fluxo muda.

---

JCL → Shell Script

Você continua automatizando processos.

Mas agora usa:

• variáveis;

• loops;

• funções;

• pipelines;

• redirecionamento;

• permissões.

---

Shell pensa diferente

JCL é declarativo.

Você descreve.

Quero executar isso.

Depois usar esse dataset.

Depois gravar ali.

Depois liberar espaço.

O sistema organiza tudo.

Shell é imperativo.

Você diz:

faça isso

agora isso

agora aquilo

agora copie

agora compacte

agora envie

Parece uma conversa.

---

A revolução silenciosa

Pouca gente percebe.

Hoje praticamente todas as ferramentas modernas do IBM Z passam pelo USS.

Git.

Python.

OpenSSH.

OpenSSL.

Java.

Node.js.

Ansible.

Docker Build Tools.

Make.

Maven.

Gradle.

VS Code.

Zowe CLI.

IBM Dependency Based Build.

Open Enterprise SDK.

Tudo isso vive ou conversa intensamente com o USS.

Quem domina USS ganha acesso ao universo moderno do Mainframe.

---

Curiosidade #1

O USS segue os padrões POSIX.

Isso significa que muito software originalmente criado para Unix pode ser recompilado para z/OS com poucas adaptações.

É um dos motivos pelos quais Python, Git e OpenSSH funcionam tão bem no IBM Z.

---

Curiosidade #2

Você pode acessar datasets tradicionais usando caminhos especiais dentro do USS.

Algo parecido com:

//CLIENTE.INPUT

Ou utilizando APIs específicas do z/OS.

É uma ponte entre os dois mundos.

---

Curiosidade #3

O comando ls mostra arquivos.

Mas também pode mostrar permissões POSIX.

Enquanto datasets continuam possuindo atributos completamente diferentes como:

• RECFM

• LRECL

• BLKSIZE

• DSORG

São dois modelos coexistindo.

---

Curiosidade #4

Muitos programas COBOL modernos conseguem trabalhar simultaneamente com:

• datasets tradicionais;

• arquivos USS;

• bancos DB2;

• APIs REST;

• filas MQ.

Tudo no mesmo programa.

Essa integração é uma das maiores forças do IBM Z atual.

---

Dicas para o Programador Júnior

Não tente decorar comandos

Aprenda conceitos.

Quem entende conceitos aprende comandos rapidamente.

---

Entenda o objetivo

Antes de perguntar:

"Qual comando faz isso?"

Pergunte:

"O que eu quero fazer?"

A resposta quase sempre será:

• copiar;

• ordenar;

• executar;

• pesquisar;

• transformar.

Depois descubra como cada ambiente expressa essa ideia.

---

Aprenda os dois mundos

Não escolha entre JCL e USS.

Aprenda ambos.

O mercado procura profissionais híbridos.

---

Pratique pequenos scripts

Faça scripts simples.

Copie arquivos.

Liste diretórios.

Ordene textos.

Execute programas.

Quanto mais prática, menos estranhos parecerão os comandos.

---

Leia JCL antigo

Muita lógica de negócio ainda vive em Batch.

Conhecer esse mundo é um enorme diferencial.

---

Explore o USS sem medo

Abra um shell.

Digite:

pwd
ls
cd
mkdir
cp
mv
rm
cat
grep
sort
find

São comandos simples.

Mas representam uma mudança enorme na forma de pensar.

---

Easter Egg do Bellacosa ☕

Existe uma frase famosa entre administradores Unix:

"Everything is a file."

No mundo Mainframe poderíamos adaptá-la para:

"Everything is a dataset... até você conhecer o USS."

---

Easter Egg Mainframe Nerd 🤓

Repare na sequência dos utilitários clássicos:

• IEBGENER copia.

• IEBCOPY copia PDS.

• IDCAMS administra VSAM e datasets.

• DFSORT organiza dados.

Agora observe os equivalentes Unix:

• cp

• mv

• rm

• sort

Quatro comandos substituem dezenas de utilitários especializados. Isso não significa que um modelo seja superior ao outro; significa apenas que cada ecossistema evoluiu para atender necessidades diferentes. O z/OS privilegiou controle, rastreabilidade e processamento corporativo em larga escala. O Unix priorizou simplicidade, composição de ferramentas e interatividade.

---

Conclusão: Aprender de Novo Não é Recomeçar

Existe uma enorme diferença entre recomeçar do zero e reconstruir seus referenciais.

Quando um desenvolvedor COBOL aprende Java, ele não esquece lógica de programação.

Quando um DBA DB2 aprende PostgreSQL, ele não esquece bancos de dados.

Quando um especialista em JCL aprende USS, ele não desaprende Batch.

Ele apenas descobre uma nova maneira de conversar com o mesmo sistema.

E talvez essa seja a maior lição da modernização do IBM Z: a tecnologia evolui, as interfaces mudam, as ferramentas se renovam, mas os princípios fundamentais permanecem. Quem entende esses princípios consegue atravessar décadas de inovação sem perder sua essência técnica.

No fim das contas, a verdadeira competência não está em decorar comandos como EXEC PGM, cp, sort ou rm. Ela está em compreender o problema, reconhecer padrões e adaptar-se rapidamente a novas formas de expressar soluções.

É por isso que os melhores profissionais de Mainframe não são aqueles que conhecem apenas o legado, nem os que dominam apenas as ferramentas modernas. São aqueles capazes de caminhar com naturalidade entre o JCL e o Bash, entre o ISPF e o VS Code, entre o dataset e o pathname, entre o Batch e o DevOps.

Porque, no IBM Z, existem dois mundos. E o profissional do futuro é aquele que fala fluentemente os dois.