💾 z/OS 1.13 — o último dos clássicos e o primeiro dos modernos ⚙️

 

☕ Bellacosa Mainframe apresenta:
💾 z/OS 1.13 — o último dos clássicos e o primeiro dos modernos ⚙️

---

🕰️ Ano de lançamento e contexto histórico

O z/OS 1.13 foi lançado em 2011, no embalo da chegada do IBM zEnterprise EC12 (zEC12).
Era o fim de uma era: o último z/OS com numeração “1.x”, antes da transição para o novo formato 2.x.
Um verdadeiro divisor de águas — onde o z/OS deixou de ser apenas o “sistema operacional do mainframe” e começou a se posicionar como o sistema nervoso central do datacenter híbrido.

No mundo real, 2011 foi o ano do boom da virtualização, do Big Data nascente e da corrida por eficiência energética e custo de CPU. E o z/OS respondeu à altura.

---

🧠 A alma técnica do z/OS 1.13

O z/OS V1R13 trouxe um pacote de avanços que preparou o terreno para o que viria com o z/OS 2.1 e o zBC12.
Vamos aos detalhes dignos de um café forte ☕💻:

⚙️ Gerenciamento de memória e performance

• Expansão da memória virtual 64-bit, permitindo endereçamento muito mais eficiente.

• Aprimoramentos no z/Architecture para lidar com Large Pages (1MB e 2GB), reduzindo TLB misses e melhorando a performance de bancos de dados e CICS.

• O Hiperspaces e o Dataspaces receberam otimizações, tornando o acesso a grandes volumes de dados em memória muito mais rápido.

• Suporte ampliado a 1 TB de memória real por LPAR (dependendo do hardware).

💡 Curiosidade Bellacosa: Foi aqui que muitos sites começaram a migrar workloads inteiros para DB2 e IMS em modo 64-bit, abrindo o caminho para o mundo da IA que viria anos depois.

---

🧩 Firmware PR/SM e créditos de CPU

O z/OS 1.13 aproveitou uma grande revisão no PR/SM (Processor Resource/System Manager) introduzida com o zEnterprise.
Esse firmware é o “síndico” do condomínio das LPARs — ele decide quem ganha tempo de CPU, quem dorme, e quem acorda.

Novidades marcantes:

• HyperDispatch aprimorado: melhora na afinidade entre threads e processadores físicos.

• HiperSockets e OSA-Express 4S com integração mais fina no z/OS — reduzindo a latência interna de rede.

• Créditos de CPU (MSU credits) mais dinâmicos, com suporte à política de “on-demand capacity” e “capacity upgrade on the fly”.

• Melhor controle de Weight e Capping, reduzindo desperdício de ciclos em workloads não prioritários.

💬 Tradução Bellacosa: o z/OS 1.13 começou a pensar em energia e custo como gente grande.
Era o mainframe dizendo: “Posso ser poderoso, mas também posso ser eficiente.”

---

🧰 Softwares internos e integração

O pacote interno do z/OS 1.13 veio turbinado. Algumas gemas técnicas:

Componente	Novidades e aprimoramentos
JES2	Suporte estendido ao spool em 64-bit e melhorias no checkpoint dataset.
RACF	Autenticação com PassTickets aprimorada e integração com LDAP.
DFSMS	Novo Space Constraint Relief e HSM otimizado para migração automática.
TCP/IP stack	Novos algoritmos de flow control e suporte a IPv6 estável.
RRS (Resource Recovery Services)	Recuperação de transações em sysplex mais rápida.
zFS	Sistema de arquivos z/OS Filesystem agora padrão, substituindo HFS.
z/OSMF (Management Facility)	Ferramenta web para gerenciamento, interface moderna (início tímido, mas promissor).

💾 Curiosidade técnica:
Foi também com o z/OS 1.13 que o z/OSMF começou a ser levado a sério — ele ainda era “meio bugado”, mas a IBM já previa que o futuro seria web-based até no mainframe.

---

🧮 O que muda nas instruções de máquina

O z/OS 1.13 passou a explorar novos z/Architecture instructions do z196 e zEC12:

• DFP e BFP Floating-Point extensions — operações matemáticas de alta precisão.

• Cryptographic Extensions — suporte a SHA-2, AES-256 e SSL/TLS acelerados via hardware.

• Transactional Execution Facility (TEF) — início do suporte a instruções atômicas de transação.

• Cache Subset Controls — instruções para controle fino de cache L3/L4.

📘 Nota técnica Bellacosa: O z/OS 1.13 é considerado o primeiro z/OS “totalmente preparado para o futuro”, pois ele já foi desenhado para o zEC12 e zBC12, lançados depois.

---

💬 Avanços de software e operação

Alguns pontos que brilharam:

• SDSF com interface ISPF aprimorada e novos filtros dinâmicos.

• Workload Manager (WLM) mais inteligente, com políticas adaptativas baseadas em service class goals.

• Parallel Sysplex com tolerância de latência reduzida — o tempo de comunicação entre LPARs caiu drasticamente.

• SMF expandido, com novos tipos de registros para performance e segurança.

• JES2 Checkpoint Duplexing — o checkpoint podia ser espelhado para maior confiabilidade.

---

🧬 Curiosidades, histórias e “fofoquices”

• Muitos chamam o z/OS 1.13 de “o último z/OS raiz” — o último antes da virada para o z/OS 2.x, quando a IBM mudou completamente o modelo de licenciamento e de suporte.

• O z/OS 1.13 é lembrado com carinho por sysprogs porque era estável como uma rocha — dizem que muitos ambientes o rodaram por 10 anos sem um único IPL completo.

• É também o primeiro z/OS com suporte “oficial” a RACF passphrase longa (até 100 caracteres!).

• E, claro, foi o último a rodar “confortavelmente” em hardware da geração z10 — depois disso, o 64-bit virou obrigatório de verdade.

---

🧭 Resumo técnico Bellacosa

Item	Destaque técnico
Lançamento	2011
Hardware alvo	z196 / z114 / zEC12
Memória suportada	até 1 TB por LPAR
Kernel	z/Architecture 64-bit
Firmware PR/SM	HyperDispatch + capping dinâmico
Novos recursos	zFS padrão, JES2 duplexing, z/OSMF, IPv6
Instruções novas	Criptografia, FP extensions, Transactional Execution
Curiosidade	Última versão da série 1.x do z/OS
Apelido entre sysprogs	“O último dos estáveis”

---

☕ Bellacosa Mainframe conclui:
O z/OS 1.13 foi aquele equilíbrio perfeito entre tradição e inovação.
Ele ainda tinha o charme dos painéis ISPF, a robustez do JES2 e a estabilidade lendária do MVS — mas já piscava o olho para o futuro com o z/OSMF, IPv6 e automação web.

“Se o z/OS fosse um whisky, o 1.13 seria aquele 18 anos envelhecido em tambor de Sysplex: suave, encorpado e impossível de esquecer.” 🥃💾

 

os 5 principais componentes do CICS

🔥 Five Major Components of CICS

 

---

☕ Midnight Lunch, região CICS no ar e tudo funcionando

13h26.
A região subiu limpa.
Nenhum erro no log.
Usuários entrando.

Alguém pergunta, meio desconfiado:

“Mas… o que realmente faz o CICS funcionar?”

A resposta curta: cinco grandes componentes.
A resposta Bellacosa? Bora destrinchar um por um — com história, prática e verdade de data center.

---

Five Major Components of CICS

🏛️ História: CICS não é monolito, é orquestra

Desde os anos 60, o CICS foi pensado como:

• Um monitor transacional

• Um sistema operacional dentro do z/OS

• Um orquestrador de recursos

Para isso, ele se organizou em componentes bem definidos, cada um com responsabilidade clara.

📌 CICS funciona porque cada parte sabe o seu lugar.

---

🧠 Conceito essencial

CICS é dividido em componentes especializados,
não em “funcionalidades soltas”.

Entender isso muda sua forma de debugar, otimizar e projetar.

---

🧱 Os Cinco Grandes Componentes do CICS

---

1️⃣ Program Control (PC) – o maestro

O que faz?

• Carrega programas

• Controla LINK, XCTL e RETURN

• Gerencia reentrância

• Mantém o fluxo da transação

Exemplos de comandos

• LINK

• XCTL

• RETURN

📌 Se o fluxo está errado, comece aqui.

---

2️⃣ File Control (FC) – o guardião dos dados

O que faz?

• Acesso a VSAM e outros arquivos

• Controle de concorrência

• Lock e recovery

Comandos típicos

• READ

• WRITE

• REWRITE

• DELETE

📌 Arquivo em CICS não é leitura. É compromisso.

---

3️⃣ Terminal Control (TC) – a interface humana

O que faz?

• Comunicação com terminais

• Envio e recebimento de telas (BMS)

• Gerenciamento de sessões

Comandos comuns

• SEND

• RECEIVE

📌 Se o usuário vê algo estranho, o problema mora aqui.

---

4️⃣ Storage Control (SC) – o gerente invisível

O que faz?

• Gerencia memória (MAIN e AUX)

• Aloca e libera storage

• Evita vazamentos

Tipos

• GETMAIN

• FREEMAIN

📌 Storage mal cuidado derruba região.

---

5️⃣ Task Control (Dispatcher) – o coração pulsante

O que faz?

• Cria e encerra tasks

• Escalona CPU

• Garante multitasking

📌 É por isso que mil usuários trabalham ao mesmo tempo.

---

🥊 Componentes vs Problemas comuns

Problema	Componente suspeito
Fluxo errado	Program Control
Arquivo travado	File Control
Tela não aparece	Terminal Control
Storage crescendo	Storage Control
Lentidão geral	Task Control

📌 Diagnóstico começa pelo componente certo.

---

🛠️ Passo a passo Bellacosa (como pensar CICS)

1️⃣ Usuário entra → Task Control
2️⃣ Tela aparece → Terminal Control
3️⃣ Programa executa → Program Control
4️⃣ Dados acessados → File Control
5️⃣ Storage usado → Storage Control

📌 O CICS é um fluxo vivo.

---

⚠️ Erros clássicos (easter eggs)

🐣 Misturar responsabilidades
🐣 Culpar “o CICS” sem analisar componente
🐣 Ignorar SC até faltar storage
🐣 READ UPDATE desnecessário
🐣 LINK infinito

📌 Todo incidente grave passa por um desses.

---

📚 Guia de estudo para mainframers

Para dominar o CICS de verdade:

• CICS Architecture

• Program Control & Task Control

• Storage Management

• File Control internals

• Performance tuning

📖 Manual essencial: CICS Transaction Server Administration Guide

---

🤓 Curiosidades de boteco mainframe

🍺 CICS gerencia memória melhor que muito runtime moderno
🍺 Task Control antecede schedulers atuais
🍺 Program Control inspirou frameworks
🍺 CICS roda há décadas com o mesmo conceito-base

---

💬 Comentário El Jefe Midnight Lunch

“Quando você entende os componentes,
o CICS deixa de ser mistério e vira ferramenta.”

---

🚀 Aplicações reais hoje

• Core bancário

• Sistemas governamentais

• Seguros e previdência

• Pagamentos globais

• APIs corporativas

---

🎯 Conclusão Bellacosa

Os cinco grandes componentes do CICS são a espinha dorsal do online corporativo.

Quem domina:

• Debuga mais rápido

• Desenha melhor

• Evita incidente feio

🔥 CICS não é complexo. Ele é organizado.

 

Aprenda COBOL com DB2 ao estilo Bellacosa Mainframe

🔥 Aprender COBOL com DB2 — o caminho do programador mainframer de verdade

---

🧠 Introdução: por que COBOL + DB2 ainda manda no jogo

Se você quer ser programador mainframe COBOL com DB2, precisa entender uma verdade simples:

COBOL processa.
DB2 guarda.
SQL conecta o cérebro à memória do negócio.

Não estamos falando de tecnologia “antiga”.
Estamos falando da infraestrutura que processa bilhões por dia, com ACID, consistência e auditoria que muita stack moderna ainda tenta copiar.

Esse artigo é um mapa de estrada, do zero até o código profissional, misturando:

• técnica

• história

• prática

• fofoca de data center

• e aquela sabedoria que só mainframer velho passa no café ☕

---

DB2 o banco de dados do Mainframe

🧱 PARTE 1 — Conhecendo o DB2 (o coração dos dados)

📜 Um pouco de história

O DB2 nasce na IBM nos anos 80, baseado no modelo relacional proposto por Edgar F. Codd.

👉 Conceito revolucionário:

• dados em tabelas

• relações lógicas

• SQL como linguagem declarativa

Enquanto o mundo brigava com arquivos VSAM:

“Me diga o que você quer, não como buscar.”

---

🧩 Modelo Relacional (base de tudo)

• Tabela → entidade de negócio

• Linha (row) → registro

• Coluna (column) → atributo

• Primary Key → identidade

• Foreign Key → relacionamento

💬 Bellacosa comenta:

“Se você não entende modelo relacional, não adianta saber COBOL.”

---

🧾 Tipos de Dados DB2 (o casamento com COBOL)

DB2	COBOL
CHAR / VARCHAR	PIC X
INTEGER	PIC S9
DECIMAL	PIC S9V
DATE	PIC X(10)
TIMESTAMP	PIC X(26)

🥚 Easter egg:
DB2 guarda DECIMAL melhor do que muito banco moderno guarda FLOAT 😏

---

Queries SQL no DB2 

🧑‍💻 PARTE 2 — Linguagem SQL no DB2

🗣️ SQL: a língua franca dos dados

SQL não é procedural.
SQL é declarativa.

🔹 DDL — Data Definition Language

CREATE TABLE CLIENTE (
  ID_CLIENTE INTEGER NOT NULL,
  NOME       VARCHAR(50),
  SALDO      DECIMAL(9,2),
  PRIMARY KEY (ID_CLIENTE)
);

• CREATE

• DROP

• ALTER

---

🔹 DCL — Data Control Language

GRANT SELECT ON CLIENTE TO USER01;

Controle de acesso.
Segurança raiz de banco.

---

🔹 DML — Data Manipulation Language

INSERT INTO CLIENTE VALUES (1, 'JOÃO', 1500.00);

SELECT * FROM CLIENTE;

UPDATE CLIENTE
SET SALDO = SALDO + 100
WHERE ID_CLIENTE = 1;

DELETE FROM CLIENTE
WHERE ID_CLIENTE = 1;

💬 Bellacosa:

“DELETE sem WHERE é como RM -RF /”

---

🔍 SELECT, JOIN e afins (onde o bicho pega)

SELECT C.NOME, P.VALOR
FROM CLIENTE C
JOIN PEDIDO P
  ON C.ID_CLIENTE = P.ID_CLIENTE;

👉 JOIN mal feito = batch lento = gente te ligando às 3 da manhã.

---

🛠️ SPUFI e QMF

• SPUFI → SQL direto no TSO

• QMF → consultas, relatórios, análise

💡 Dica Bellacosa:

“Todo mundo começa no SPUFI.
Quem fica bom, aprende QMF.”

---

🧩 PARTE 3 — COBOL com DB2 (onde nasce o profissional)

🏛️ História rápida do COBOL

• Criado em 1959

• Foco: negócio

• Legibilidade

• Estabilidade

👉 Não é bonito.
👉 É confiável.

---

🧠 Estrutura de um programa COBOL

• IDENTIFICATION DIVISION

• ENVIRONMENT DIVISION

• DATA DIVISION

• PROCEDURE DIVISION

📌 Árvore programática é fundamental para não virar macarrão lógico.

---

🔗 Host Variables (a ponte COBOL ↔ DB2)

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CLIENTE
    WHERE ID_CLIENTE = :WS-ID
END-EXEC.

• Sempre com :

• Tipagem correta

• Conversão consciente

---

📊 SQLCA — seu melhor amigo

IF SQLCODE = 0
   CONTINUE
ELSE
   DISPLAY 'ERRO DB2 ' SQLCODE
END-IF

SQLCODE	Significado
0	OK
+100	NOT FOUND
< 0	ERRO

💬 Bellacosa:

“Quem ignora SQLCODE vira operador sem saber.”

---

📚 DCLGEN — o BOOK sagrado

• Gera layout da tabela

• Gera host variables

• Evita erro humano

//STEP01 EXEC PGM=DSNTEP2

👉 Nunca escreva layout DB2 na mão. Nunca.

---

Consulta pagina via cursor no DB2

🌀 PARTE 4 — Cursores (nível profissional)

🔄 Cursor para leitura

EXEC SQL
   DECLARE C1 CURSOR FOR
   SELECT ID_CLIENTE, NOME
     FROM CLIENTE
END-EXEC.

EXEC SQL
   FETCH C1 INTO :WS-ID, :WS-NOME
END-EXEC.

📌 Sempre:

• OPEN

• FETCH

• CLOSE

---

✍️ Inserindo, alterando e excluindo via COBOL

• INSERT → novo registro

• UPDATE → alteração controlada

• DELETE → cuidado máximo

💡 Boa prática:

“Nunca DELETE direto sem histórico.”

---

🧠 PARTE 5 — Boas práticas Bellacosa Mainframe

✔ Use DCLGEN
✔ Sempre trate SQLCODE
✔ Evite SELECT *
✔ Documente regra de negócio
✔ Separe lógica de acesso a dados
✔ Teste com volume real
✔ Pense em performance desde o SELECT

🥚 Easter egg clássico:

“O batch estava lento porque alguém esqueceu o índice.”

---

🧪 Exercícios de fixação (mentalidade correta)

1. Criar tabela DB2

2. Gerar DCLGEN

3. Programa COBOL com:

   • INSERT

   • SELECT

   • UPDATE

   • DELETE

4. Programa com CURSOR

5. Programa com JOIN

6. Analisar SQLCODE

7. Ajustar performance

👉 Isso forma programador, não copiador de código.

---

🧠 Comentário final Bellacosa

Aprender COBOL com DB2 não é aprender uma linguagem.
É aprender:

• como dados movem o mundo

• como sistemas críticos pensam

• como escrever código que não pode falhar

🔥 COBOL + DB2 não é passado.
É o núcleo silencioso do presente.

Enquanto modas passam,
o batch fecha o dia.

 

 

Bellacosa Mainframe apresenta JCL Job Control Language

🔥 JCL no z/OS V1R1 — quando o “antigo” ganhou sobrenome moderno

---

📅 Datas importantes

• Release (GA): outubro de 2000

• Final de suporte (EoS/EoM): entre 2004 e 2005 (dependendo do nível de suporte IBM e migração para V1R2+)

O z/OS V1R1 marcou oficialmente a transição do OS/390 para z/OS, e o JCL veio junto — o mesmo DNA dos anos 60, agora rodando num sistema “novo em folha”.

---

🧬 Contexto histórico

Quando a IBM lançou o z/OS V1R1, o JCL já era um veterano respeitado. Ele não nasceu no z/OS — nasceu lá atrás, no OS/360 (1964) — mas sobreviveu a tudo: MVT, MVS, ESA, OS/390… e chegou ao z/OS sem pedir licença.

O que muda aqui não é a linguagem, mas o ambiente, o poder da máquina, a integração com UNIX System Services, TCP/IP nativo e workloads híbridos.

👉 Moral da história:

“Troca o sistema, troca o nome, troca o marketing… mas o JCL continua mandando no turno da noite.”

---

JCL V1R1

✨ O que há de “novo” no JCL do z/OS V1R1

Tecnicamente, o JCL é compatível para trás, mas o z/OS V1R1 trouxe melhorias indiretas importantes:

🆕 1. Integração total com o z/OS

• JCL agora orquestra:

  • Batch tradicional

  • Utilitários do DFSMS

  • Programas que acessam USS (OMVS)

  • Processos ligados a TCP/IP e middleware

🆕 2. JES2/JES3 mais maduros

• Melhor gerenciamento de:

  • Spool

  • Classes

  • Prioridades

  • Restart de jobs

🆕 3. DFSMS mais forte

• JCL passa a explorar melhor:

  • SMS-managed datasets

  • Storage Groups

  • Management Classes

  • Data Classes

👉 O JCL continua simples, mas o ecossistema ao redor ficou muito mais poderoso.

---

🔧 Melhorias e mudanças percebidas no dia a dia

✔ Melhor estabilidade no processamento batch
✔ Melhor convivência entre online (CICS) e batch
✔ Menos “abend misterioso” por problemas de storage
✔ Maior previsibilidade de execução noturna

Nada de comandos novos mirabolantes — o ganho foi operacional.

---

🥚 Easter Eggs (para mainframer raiz)

• 🥚 JCL que funcionava no OS/390 funcionava igual no z/OS V1R1
  Isso facilitou migrações gigantes sem reescrever milhares de jobs.

• 🥚 Muitos shops migraram para z/OS sem mudar uma linha de JCL
  Só recompilaram programas e ajustaram SMS.

• 🥚 O //STEPLIB DD * continuava sendo usado… mesmo sendo má prática 😅

---

💡 Dicas Bellacosa para quem viveu (ou estuda) essa época

🔹 Aprenda JCL como linguagem de orquestração, não só como “script batch”
🔹 Entenda bem:

• DISP

• SPACE

• UNIT

• COND vs IF/THEN/ELSE
  🔹 Leia syslog e JESMSGLG como quem lê log de produção moderna
  🔹 Lembre-se:

JCL errado não falha — ele executa errado.

---

📈 Evolução a partir do V1R1

Depois do z/OS V1R1, o JCL seguiu firme:

• V1R3+ → IF/THEN/ELSE mais usado

• V1R6+ → Melhor integração com ferramentas modernas

• V2.x → JCL convivendo com DevOps, schedulers e automação

Mas a base?
👉 Exatamente a mesma.

---

📜 Exemplo clássico de JCL (estilo raiz)

//BELLJOB  JOB (ACCT),'BELLACOSA',CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=IEFBR14
//OUTFILE  DD  DSN=BELLACOSA.TESTE.JCL,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             UNIT=SYSDA

💬 Comentário Bellacosa:

“Se você entende esse JCL, você entende 70% do batch do mainframe.”

---

🧑‍🔧O que é DFSMS?

Na verdade, o DFSMS (Data Facility Storage Management Subsystem) não é apenas um utilitário único, mas sim uma suíte poderosa de componentes da IBM para o ambiente z/OS.

Em termos simples: ele é o "gerente de logística" do seu mainframe. Ele automatiza e centraliza a gestão de onde os dados são gravados, por quanto tempo ficam guardados e como são protegidos.

---

Os 4 Pilares do DFSMS

Para entender o DFSMS no dia a dia do JCL, é preciso conhecer seus principais componentes:

1. DFSMSdfp (Data Facility Product): O coração do sistema. Gerencia o acesso aos dados e a movimentação básica. É aqui que mora o famoso utilitário IDCAMS.

2. DFSMSdss (Data Sets Services): Focado em cópia, movimentação e backup de alta performance. O programa principal chamado via JCL é o ADRDSSU.

3. DFSMShsm (Hierarchical Storage Manager): Responsável por "limpar a casa". Ele migra dados pouco usados para mídias mais baratas (como fita ou discos lentos) e faz o backup automático.

4. DFSMSrmm (Removable Media Manager): Gerencia suas fitas (físicas ou virtuais), controlando quem pode usá-las e quando podem ser apagadas.

---

Como ele aparece no seu JCL?

No passado, você precisava dizer exatamente em qual disco (UNIT e VOL=SER) seu arquivo deveria morar. Com o DFSMS (especificamente o componente SMS), o sistema faz isso sozinho através de três parâmetros principais no comando DD:

• DATACLAS (Data Class): Define os atributos físicos (organização, formato de registro, tamanho).

• STORCLAS (Storage Class): Define o nível de serviço (em qual disco ele vai morar, se precisa ser um disco rápido ou SSD).

• MGMTCLAS (Management Class): Define o "prazo de validade" (quando o HSM deve deletar ou migrar o arquivo para fita).

Exemplo de DD com SMS:

Snippet de código

//ARQUIVO  DD DSN=USER.TESTE.DADOS,
//            DISP=(NEW,CATLG,DELETE),
//            DATACLAS=DCPADRAO,
//            STORCLAS=SCFAST,
//            MGMTCLAS=MGT030D

---

🛠️ Principais Utilitários que você usará

Se você está procurando o "programa" para rodar, os mais comuns vinculados ao DFSMS são:

Utilitário	Para que serve?
IDCAMS	Criar, deletar, listar e gerenciar VSAM e catálogos.
ADRDSSU	Copiar volumes inteiros ou datasets específicos em alta velocidade.
IEBCOPY	(Gerenciado pelo DFP) para copiar e comprimir bibliotecas (PDS/PDSE).

🧠 Comentário final

O JCL no z/OS V1R1 prova uma verdade que todo mainframer aprende cedo:

Tecnologia boa não morre — ela evolui sem fazer barulho.

Enquanto linguagens vêm e vão, o JCL segue lá, silencioso, confiável, rodando milhões de jobs por noite…
…e garantindo que o mundo acorde com banco, energia, avião e folha de pagamento funcionando.

🔥 Longa vida ao JCL.

🔥 Map Programming no CICS Structure, Rules, Hierarchy & Checklist para Design de Mapas BMS

 

Programação de mapa BMS em CICS

🔥 Map Programming no CICS

Structure, Rules, Hierarchy & Checklist para Design de Mapas BMS

Workflow de compilação mapa bms cics

---

☕ Midnight Lunch, tela piscando e o mapa “quase certo”

13h42.
O programa compila.
O mapa gera.
A tela aparece… toda desalinhada.

O operador olha.
O usuário reclama.
O programador jura:

“Mas o BMS tá certo…”

Hoje vamos falar do map programming no CICS — a arte esquecida que separa interface profissional de poluição verde-fosforescente.

---

🏛️ História: antes do HTML, existia BMS

Antes de:

• HTML

• CSS

• Front-end frameworks

o CICS já tinha separação clara entre lógica e apresentação usando BMS (Basic Mapping Support).

📌 BMS é UI declarativa antes da web existir.

---

🧠 Conceito essencial (guarde isso)

Mapa não é tela.
Mapa é contrato entre usuário e programa.

Se o contrato é ruim, o sistema sofre.

---

🧩 Hierarquia de Mapas no CICS

Entender a hierarquia evita 80% dos erros.

📐 Estrutura hierárquica

MAPSET
 └── MAP
      └── FIELD

📦 MAPSET

• Conjunto lógico de mapas

• Compilado como uma única unidade

• Gera um load module

📌 MAPSET é o pacote.

---

🖥️ MAP

• Uma tela específica

• Ex: entrada, consulta, confirmação

📌 Um MAP = um propósito.

---

🔤 FIELD

• Campos de entrada ou saída

• Posicionados na tela

• Com atributos definidos

📌 Campo mal definido = bug visual.

---

🧾 Estrutura básica de um BMS Map

DFHMSD TYPE=MAP,MODE=INOUT,LANG=COBOL,STORAGE=AUTO
MAP01  DFHMDI SIZE=(24,80),LINE=1,COLUMN=1
FLD01  DFHMDF POS=(5,10),LENGTH=10,ATTRB=(UNPROT)
DFHMSD TYPE=FINAL

📌 Simples. Poderoso. Exigente.

---

📐 Regras fundamentais de Map Programming

1️⃣ Um mapa, uma função

❌ Tela “faz tudo”
✅ Tela objetiva

---

2️⃣ Campos bem definidos

• Entrada → UNPROT

• Saída → PROT

• Proteção correta evita erro de digitação

---

3️⃣ Nunca confie no input

• Sempre valide no programa

• Mapa ajuda, mas não garante

---

4️⃣ Use atributos conscientemente

• INTENS

• MDT

• IC (cursor)

• ASKIP

📌 Atributo errado confunde usuário.

---

🧠 Estrutura do Programa de Mapa (lado COBOL)

Fluxo clássico

1️⃣ RECEIVE MAP
2️⃣ Processa dados
3️⃣ Prepara saída
4️⃣ SEND MAP
5️⃣ RETURN

📌 Mapa não decide lógica. Programa decide.

---

🛠️ Passo a passo: desenhando um mapa decente

🧩 Planejamento

• O que o usuário vê?

• O que ele digita?

• Qual é o fluxo?

---

🧩 Design

• Campos alinhados

• Mensagens claras

• Uso consciente de cores

---

🧩 Implementação

• BMS limpo

• Nomes consistentes

• Sem “gambiarras visuais”

---

🧩 Teste

• Campo obrigatório

• Campo inválido

• Tela cheia

• Tela vazia

📌 Tela também precisa de teste.

---

✅ Checklist Bellacosa – antes de subir o mapa

✔ Campos protegidos corretamente
✔ Cursor posicionado logicamente
✔ Mensagens claras e humanas
✔ Nenhum campo sobreposto
✔ MAPSET organizado
✔ Nomes padronizados
✔ Layout documentado

📌 Mapa ruim vira chamado eterno.

---

⚠️ Erros clássicos (easter eggs)

🐣 Campo UNPROT que deveria ser PROT
🐣 Mensagem fixa escrita no mapa
🐣 Mapa gigante e confuso
🐣 Layout “ajustado no chute”
🐣 BMS tratado como código secundário

📌 Todo sistema feio começa assim.

---

📚 Guia de estudo para mainframers

Domine estes tópicos:

• BMS syntax

• Mapset generation

• SEND / RECEIVE MAP

• MDT, IC, ASKIP

• Pseudo-conversational design

📖 Manual essencial: CICS Basic Mapping Support Guide

---

🤓 Curiosidades de boteco mainframe

🍺 BMS já separava UI e lógica antes do MVC
🍺 Muitas telas CICS têm mais de 30 anos
🍺 Um bom mapa reduz erro humano
🍺 Operador odeia mapa mal alinhado

---

💬 Comentário El Jefe Midnight Lunch

“Código ruim quebra sistema.
Mapa ruim quebra usuário.”

---

🚀 Aplicações reais hoje

• Sistemas bancários

• Governo

• Seguradoras

• Atendimento corporativo

• Ambientes híbridos (3270 + APIs)

---

🎯 Conclusão Bellacosa

Map programming não é detalhe.
É experiência do usuário, disciplina e respeito.

Quem domina BMS:

• Recebe menos chamado

• Facilita suporte

• Cria sistemas longevos

🔥 Tela bem feita envelhece melhor que código.

 

Hatsumode a primeira visita ao Templo no ano novo

🎍 Hatsumōde — O “IPL” Espiritual do Japão

Todo início de ano, enquanto aqui a gente ainda está digerindo o peru, o panetone e os boletos de janeiro, no Japão o pessoal está fazendo algo muito sério, simbólico e organizado: o Hatsumōde.

Traduzindo do japonês:

• Hatsu (初) = primeiro

• Mōde (詣) = visita a um templo

Ou seja: a primeira visita do ano a um templo xintoísta ou budista.
É basicamente o RESET espiritual + COMMIT de intenções para o ano que começa.

---

Hatsumode

🏯 Origem & História (modo batch antigo)

O Hatsumōde começou lá atrás, no período Heian (794–1185), quando famílias nobres faziam peregrinações no início do ano para agradecer e pedir proteção aos deuses (kami).

Com o tempo, o costume saiu da elite e virou job obrigatório para o povo inteiro. Hoje, milhões de japoneses fazem Hatsumōde entre 1º e 3 de janeiro, alguns estendendo até a primeira semana do ano.

Sim: é alta carga, pico de acesso e fila maior que JES2 em fechamento mensal.

---

🙏 Como funciona o “procedimento padrão”

1. Ir ao templo (jinja ou tera)

2. Purificação

   • Lavar mãos e boca (limpeza de buffer espiritual)

3. Oração

   • Jogar moeda

   • Bater palmas (xintoísmo)

   • Inclinar a cabeça

4. Pedidos e agradecimentos

   • Saúde, trabalho, estudos, amor, paz

Nada de pedir Ferrari. O Japão gosta de request modesto e estável.

---

🎁 Omamori, Omikuji e bug conhecido

🔮 Omikuji (sorte do ano)

Você tira um papelzinho com sua previsão:

• Daikichi (grande sorte)

• Kichi (boa sorte)

• Kyō (má sorte)

Se der ruim, amarram o papel no templo para “deixar o erro ali” e não levar para casa.
Rollback espiritual clássico.

🧿 Omamori (amuletos)

Proteção para:

• Estudos

• Saúde

• Trânsito

• Amor

• Trabalho

Cada um é contextual, não adianta usar errado.

---

🐉 Curiosidades & Easter Eggs

• Templos famosos recebem milhões de pessoas em 3 dias

• Casais fazem Hatsumōde juntos (check de compatibilidade)

• Muitos vão de kimono, só para o evento

• Animes usam Hatsumōde para:

  • Avançar romance

  • Mostrar novos começos

  • Criar situações constrangedoras 😄

📺 Aparece em:

• Your Name

• Toradora

• Love Live

• Clannad

• Bunny Girl Senpai

---

🤫 Fofoquices culturais

• Alguns vão mais pela selfie do que pela fé

• Outros pulam a oração e vão direto comprar comida

• Tem gente que faz Hatsumōde em vários templos, tipo redundância geográfica

• Existe disputa silenciosa por quem pega o melhor omamori

---

💡 Dicas Bellacosa Mainframe

✔ Vá cedo ou de madrugada (menos fila)
✔ Respeite o fluxo, não é lugar de bagunça
✔ Não ria das tradições (auditoria cultural ativa)
✔ Se der sorte ruim, amarre o papel e siga o jogo

---

🧠 Conclusão — visão de arquiteto

O Hatsumōde é mais do que religião.
É manutenção preventiva da alma, alinhamento de expectativas e um jeito elegante de dizer:

“O ano virou, bora tentar fazer melhor.”

No fundo, todo mundo precisa de um RESET limpo, sem perder os dados importantes.

E você, leitor do El Jefe Midnight Lunch…
Já fez o seu Hatsumōde pessoal este ano? 🎍