Sardinhas na brasa a portuguesa.

O prato mais saboroso do verão português

Vou partilhar com vocês o prato da culinária portuguesa que mais me encanta no final da primavera/inicio do verão.

Estou falando das Sardinhas na Brasa, comidas em todo território português e também no mundo todo onde tiver um imigrante português.

Um prato super simples de fazer, mas com um sabor único que me faz ficar com agua na boca so de lembrar.

Quer tentar fazer em casa? Compre sardinhas inteiras bem gordas, tire as escamas com uma faca, use muito sal grosso e deixe descansar por uma hora.

Acenda o carvão na churrasqueira na altura que estiver bem quente, ponha as sardinhas na brasa e va virando para não deixar ficar muito seca, o aroma se espalha pelo ar, deixando qualquer um com agua na boca.

Acompanha lindamente com batata cozida e pimentões assados na brasa; puré de batata; sanduíche de pão português e sanduíche de broa.

 

🔎 Guia Prático de Comandos TSO para Padawans

Salve jovem padawan em nosso segundo artigo de 2026, vamos mergulhar um pouco em comandos de linha no TSO, onde poderemos explorar melhor o sistema Z, criar dataset, consultar, limpar, alocar e testar.

Ganhando velocidade em nosso desenvolvimento e dominando melhor o ambiente Z, seja bem-vindo e conto com seu comentarios e criticas para melhorarmos e irmos mais longe.

Para não apanhar do terminal logo no login

---

🧠 Antes de tudo: o que é TSO de verdade?

TSO (Time Sharing Option) não é: 

❌ só uma tela preta 

❌ um “modo antigo” 

❌ um castigo divino

TSO é:

A interface raiz do z/OS para trabalhar diretamente com o sistema.

Se o mainframe fosse um avião:

• TSO é o painel cru de instrumentos
• ISPF é o cockpit amigável

Todo mainframeiro de respeito precisa saber sobreviver no TSO puro.

---

⌨️ Sintaxe básica do TSO (lei universal)

COMANDO OPERANDO PARÂMETROS

Regras não escritas:

• Espaço separa argumentos
• Parênteses organizam opções
• Aspas protegem nomes longos
• Abreviações são comuns (e perigosas 😈)

---

📂 Comandos essenciais para datasets

📌 LISTDS – listar datasets

LISTDS 'USERID.*'

🔎 Dica El Jefe:

• Use LEVEL para evitar varrer o catálogo inteiro

LISTDS LEVEL(USERID)

⚠️ Perigo:

• LISTDS * pode virar pecado mortal em produção

---

📌 DELETE – apagar datasets

DELETE 'USERID.TESTE.ARQUIVO'

☠️ Atenção:

• Não existe lixeira
• Apagou, rezou

---

📌 RENAME – renomear

RENAME 'USERID.OLD' 'USERID.NEW'

---

📖 Visualização de conteúdo

📌 LISTCAT – catálogo é lei

LISTCAT ENTRIES('USERID.ARQ') ALL

Use quando:

• Dataset “existe mas não existe”
• Erro estranho de allocation
• Discussão com storage admin 😎

---

📌 PRINT – ver conteúdo

PRINT DS('USERID.ARQ')

⚠️ Não abuse com arquivos grandes. Seu spool agradece.

---

⚙️ Execução e controle de ambiente

📌 ALLOC – alocar datasets

ALLOC FI(ARQ1) DA('USERID.TESTE') SHR

🧠 Tradução humana:

• FI = nome lógico
• DA = dataset físico
• SHR = leitura compartilhada

---

📌 FREE – liberar alocação

FREE FI(ARQ1)

Nunca confie que o sistema vai limpar sozinho.

---

📤 Trabalhando com JOBs

📌 SUBMIT – enviar JCL

SUBMIT 'USERID.JCL.TESTE'

🔥 Dica El Jefe:

• Use SUBMIT * dentro do editor para ganhar tempo

---

📌 STATUS – ver jobs ativos

STATUS

Simples. Antigo. Funcional.

---

👤 Usuário e sessão

📌 PROFILE – perfil do usuário

PROFILE

Mostra:

• Prefixo
• Tamanho de região
• Opções ativas

---

📌 LOGOFF – sair com dignidade

LOGOFF

Nunca feche o navegador achando que “tá tudo bem”.

---

🧨 Erros clássicos de padawan

❌ Digitar dataset sem aspas

❌ Apagar sem conferir

❌ LISTDS muito genérico

❌ Esquecer FREE

❌ Confundir TSO com ISPF

---

🥚 Easter-eggs de veterano

• Muitos comandos aceitam abreviação
• HELP funciona (sim, sério)

HELP LISTDS

• TSO responde melhor quando você é educado (quase)

---

🎓 Palavra final do El Jefe

Quem domina TSO, domina o chão de fábrica do mainframe.

ISPF é conforto. TSO é poder.

Aprender TSO não te torna antigo. Te torna consciente do que o sistema realmente faz.

Viagem de Maria Fumaça ate Jaguariuna

Partindo de Anhumas em Campinas

A linha da Mogiana é o destino de todos aqueles que desejam sentir o prazer em andar em uma locomotiva a vapor, sentir o cheirinho da lenha, ver a fumaça subindo e ouvir o apito do trem.

O revisor grita todos a bordos!!!! A criançada vibra, bilhetes na mão e todos adentram no vagão de passageiros, ansiosos por ouvir o apito de partida.

Em breve o revisor se aproxima, verifica o bilhete e valida-o com o perfurador de bolso. A locomotiva vai ganhando força, ouve-se o ta-ta-tatatata aumentando em velocidade. Vez por outra ouve-se o apito.

Olhando pela janela ve-se o finzinho da cidade, campos, pastos e antigas fazendas de café estamos chegando em Tanquinho outra estação no caminho de Jaguariuna.

Os passeios de trem partem tanto da estação Anhumas (Campinas) como de Jaguariuna aos finais de semana, verifiquem no site, para saberem os horários e preços.

 

📊 Tabela de Erros Comuns no COBOL 5.x

(Quando o compilador resolve dizer a verdade)

“COBOL 5 não quebrou seu programa.
Ele apenas revelou o que sempre esteve errado.”
— Bellacosa

---

🟥 ERROS DE DADOS (o choque de realidade)

Erro comum	O que mudou no COBOL 5	Sintoma típico	Impacto
MOVE inválido alfa → numérico	NUMCHECK rigoroso	Erro de compilação ou runtime	Job aborta cedo
Campo não inicializado	INITCHECK ativo	Warning/erro	Resultado imprevisível exposto
Uso de lixo em COMP	Validação agressiva	Falha imediata	S0C7 antecipado
PIC incompatível	Validação estrita	Compile error	Código não sobe
Truncamento inesperado	TRUNC mais explícito	Valor incorreto	Erro contábil

🥚 Easter-egg:

O erro “novo” já existia no COBOL 4 — só não gritava.

---

🟧 ERROS DE CONTROLE DE FLUXO

Erro comum	COBOL 5 faz diferente	Sintoma	Consequência
PERFORM THRU mal definido	Análise de fluxo	Warning severo	Lógica rejeitada
GO TO cruzando blocos	Restrição maior	Erro de compilação	Código não compila
IF/END-IF inconsistentes	Estrutura rígida	Compile error	Refatoração obrigatória
EXIT mal posicionado	Regras mais claras	Erro lógico	Fluxo interrompido

Bellacosa note:

Se o COBOL 5 reclama, o código está errado — ponto.

---

🟨 ERROS DE STORAGE E MEMÓRIA

Erro comum	COBOL 5 expõe	Sintoma	Resultado
REDEFINES mal alinhado	SSRANGE ativo	Runtime error	S0C4
OCCURS fora de limite	Checagem ativa	Abort imediato	Proteção de memória
DEPENDING ON inválido	Validação em runtime	Abend	Corrupção evitada
Índice mal usado	Tipagem rígida	Compile error	Correção forçada

🥚 Easter-egg técnico:

SSRANGE não cria erro — ele evita desastre.

---

🟦 ERROS DE ARQUIVOS (mais disciplina)

Erro comum	Diferença no COBOL 5	Sintoma	Impacto
FILE STATUS ignorado	Warning severo	Job rejeitado	Erro detectado cedo
READ sem AT END	Análise estática	Compile warning	Loop evitado
WRITE sem validação	Checagem formal	Runtime error	Integridade garantida
OPEN fora de ordem	Validação rígida	Abend	Erro explícito

---

🟪 ERROS DE PERFORMANCE (o paradoxo)

Erro comum	Por que aparece no COBOL 5	Sintoma	Efeito
Código “lento” após migração	Otimização diferente	CPU aumenta	Ajustar OPTIMIZE
Dependência de MOVE	Nova análise	Código inchado	Refatoração
DISPLAY em loop	Runtime moderno	Batch mais lento	Remover debug
Falta de INLINE	Compilação conservadora	Performance ruim	Ajustar opções

Bellacosa truth:

COBOL 5 é mais rápido — se o código merecer.

---

🟫 ERROS DE COMPILAÇÃO (novos padrões)

Erro comum	COBOL 5 exige	Sintoma	Ação
Código legado ambíguo	Sintaxe clara	Compile error	Refatorar
Ignorar warnings	Warnings viram erros	Build falha	Corrigir
TRUNC inconsistente	Padronização	Valor errado	Revisar
Dependência de defaults	Defaults mudaram	Resultado inesperado	Definir parms

---

☠️ ABENDS mais associados ao COBOL 5

ABEND	Motivo
S0C7	Detectado mais cedo
S0C4	Proteção de memória
U4038	INITCHECK / NUMCHECK
U4087	Violação de range
U4093	Lógica inválida

---

🎓 Resumo para Padawans

✔ COBOL 5 não tolera código sujo
✔ Erros aparecem mais cedo
✔ Migração revela dívidas técnicas
✔ Mais seguro, mais rápido, mais previsível

---

🧠 Frase Final Bellacosa™

“COBOL 4 confiava no programador.
COBOL 5 confia nos dados.”

 

💾 z/OS 2.1 — O salto técnico rumo à era híbrida do Mainframe ☁️⚙️

Por Bellacosa Mainframe — onde bits, café e história se misturam ☕🖥️

---

Quando a IBM lançou o z/OS 2.1 em setembro de 2013, o mundo mainframe vivia uma encruzilhada: ou se isolava como um dinossauro tecnológico, ou se reinventava como o titã resiliente da nova era digital.
Adivinha qual caminho ele escolheu? 😎
Spoiler: o z/OS 2.1 é o marco da virada para a era híbrida e cognitiva do mainframe.

Vamos destrinchar o que mudou, as camadas técnicas e as curiosidades que tornam essa versão um divisor de águas.

---

🧬 1. Contexto histórico — o z/OS reencontra o futuro

O z/OS 2.1 nasceu junto com os mainframes IBM zEnterprise EC12 (zEC12), um monstro de 5.5 GHz, com 2 TB de memória, 120 processadores físicos e uma arquitetura pensada para virtualização de workloads e análise em tempo real.

O grande desafio da IBM era:

“Como preparar o z/OS para o futuro da integração, da nuvem e do mobile sem perder o legado que roda o planeta?”

Assim surge o z/OS 2.1, com foco em eficiência, elasticidade e conectividade.

---

🧠 2. Arquitetura e uso de memória — o cérebro expandido

O z/OS 2.1 trouxe uma reengenharia no gerenciamento de memória, aproveitando melhor a arquitetura z/Architecture e as inovações do PR/SM (Processor Resource/System Manager).

Principais avanços:

• Suporte a 16 TB de memória virtual (um salto em relação ao 2.0).

• Melhor uso da 64-bit addressing mode, reduzindo page faults e swaps.

• Buffer Pools e dataspaces otimizados — ideal para DB2, IMS e CICS.

• Cross Memory Services mais rápidos e isolados.

💡 Curiosidade Bellacosa: O kernel do z/OS 2.1 literalmente “aprende” a liberar memória mais rápido para workloads que mudam de prioridade — algo que hoje chamamos de “inteligência operacional”.

---

⚙️ 3. PR/SM, LPAR e créditos de CPU — o cérebro por trás da mágica

O firmware PR/SM (Processor Resource/System Manager) foi profundamente atualizado nesta geração para oferecer:

• Dynamic CPU Weight Management: ajuste automático da prioridade das LPARs.

• Intelligent Capping: limita o consumo sem matar o desempenho.

• Soft Capping por Workload: controle fino para billing e otimização.

• Suporte ao zAAP/zIIP integrados — sem necessidade de hardware dedicado.

🎩 Easter egg técnico: no z/OS 2.1, as LPARs começaram a “conversar” melhor via HiperSockets IPv6, abrindo caminho para a nuvem privada z/OS Connect.

---

💬 4. Aplicativos internos e softwares — a revolução silenciosa

O z/OS 2.1 veio com uma leva de atualizações internas e ferramentas novas:

🔹 CICS TS 5.1

Suporte a aplicações RESTful, JSON e web services nativos, antecipando o que hoje chamamos de API Economy.

🔹 DB2 11 for z/OS

Melhoria brutal no storage engine e otimização de index rebuild.
Menos CPU, mais throughput.

🔹 JES2 e JES3

Ambos ganharam compressão de spool, melhor suporte a Unicode e integração com RACF e SAF aprimorada.
O JES2, inclusive, ficou mais “verbozão” — logs mais inteligentes para devs e ops.

🔹 UNIX System Services (USS)

Expansão total: mais comandos POSIX, shell modernizado e integração com ferramentas open source (hello, Perl e Python!).

🔹 Communications Server

Nativo IPv6, com QoS aprimorado e integração direta com o z/OSMF.

---

🧩 5. z/OSMF e o renascimento do operador

O z/OS Management Facility (z/OSMF) virou protagonista.
Pela primeira vez, o operador do mainframe podia administrar o sistema via interface web, com dashboards, workflows e diagnósticos integrados.

Isso mudou tudo:

• A operação ficou mais visual e menos criptográfica (adeus, painéis 3270 infinitos).

• Surgiram scripts e automações REST, abrindo portas para DevOps no mainframe.

• O z/OS começou a dialogar com o mundo Linux e Cloud.

💬 Bellacosa insight: o z/OSMF foi o primeiro passo real para o que hoje chamamos de “Mainframe as Code”.

---

🔍 6. Instruções de máquina e otimizações no zEC12

O z/OS 2.1 foi ajustado para o novo processador zEC12, que introduziu:

• Instruções novas como Transactional Execution (TX) — acelera commits em DB2.

• Crypto Express4S — hardware de criptografia de ponta.

• Simultaneous Multithreading (SMT) — mais threads, menos gargalo.

• HiperDispatch refinado — balanceia threads automaticamente.

Tudo isso sob o comando de um PR/SM mais “inteligente”, que distribuía créditos de CPU conforme prioridade, workload e até custo horário da LPAR (sim, billing inteligente já era realidade).

---

🕹️ 7. Curiosidades, fofoquices e bastidores

• 🧙‍♂️ Dentro da IBM, o z/OS 2.1 era apelidado de “O Feiticeiro do Silício”, por causa da automação mágica dos workloads.

• 🧩 O time que desenvolveu o z/OSMF tinha ex-devs do OS/2!

• 💬 Foi a primeira versão oficialmente “Cloud Ready”, base dos projetos iniciais do z/OS Connect EE.

• 🕵️‍♂️ Algumas funções experimentais do z/OS 2.1 só foram “oficializadas” no 2.2, como a integração com zAware e zCX.

---

🚀 8. Conclusão — o mainframe, renascido

O z/OS 2.1 é o elo entre o legado e o futuro.
Ele consolidou a base técnica que permitiria o z/OS rodar workloads modernos, APIs REST, automações web e integração em nuvem — tudo sem quebrar um único programa COBOL dos anos 70.
Esse é o verdadeiro superpoder do mainframe: evoluir sem perder o passado.

---

Bellacosa Mainframe
☕ Onde bits têm alma e memória tem história.
💬 Deixe nos comentários: você chegou a migrar para o z/OS 2.1? Qual foi o impacto no seu ambiente?