quinta-feira, 9 de dezembro de 2010

🜂 A Roupa Nova do Rei

 

Bellacosa Mainframe e a fabula o Rei vai Nu

🜂 A Roupa Nova do Rei

Quando a ilusão entra em produção, ninguém dá o ABEND e o sistema segue… até a criança apertar ENTER
Para mainframers que gostam de anime, metáforas, sistemas legados e verdades que ninguém quer logar


1️⃣ IPL cultural: por que esse conto ainda roda em produção?

Todo mainframer raiz já viu isso acontecer:
um sistema claramente errado, cheio de gambiarra, documentação inexistente, ninguém entende direito… mas todo mundo finge que está funcionando.

A história da Roupa Nova do Rei é exatamente isso.
Um batch cultural rodando há séculos, sem manutenção, sem revisão de código, mas perfeitamente compatível com a natureza humana.

Ela fala de vaidade, medo, conformismo, hierarquia, status…
e principalmente de um bug clássico:

ninguém quer ser o primeiro a dizer que o rei está pelado.


2️⃣ Origem: quem compilou essa história?

A versão mais famosa do conto foi publicada em 1837, pelo escritor dinamarquês Hans Christian Andersen, no livro Eventyr, fortalte for Børn (Contos contados para crianças).

📜 Primeira publicação conhecida:
➡️ “Kejserens nye Klæder” (em dinamarquês)

Mas atenção, padawan…

🧠 Easter egg histórico:

Andersen não inventou a história do zero.
Ela é baseada em contos muito mais antigos, especialmente um conto espanhol do século XIII, presente no livro:

📖 El Conde Lucanor, de Don Juan Manuel (c. 1335)

Nesse conto antigo, três vigaristas prometem fazer um pano invisível para quem não fosse filho legítimo.
Ou seja: a lógica do medo social já estava lá, só mudaram os parâmetros do IF.


3️⃣ O enredo resumido (ou: o sistema que ninguém quer testar)

O rei é obcecado por roupas.
Não governa. Não cuida do povo.
Só quer status, aparência, reconhecimento.

Dois vigaristas aparecem oferecendo uma roupa mágica:

✨ “Ela só pode ser vista por pessoas inteligentes e dignas do cargo que ocupam.”

📌 Tradução mainframe:

IF USER NOT SEE CLOTHES
   THEN USER = BURRO OR INCOMPETENTE

Resultado:

  • O rei não vê nada → finge que vê

  • Os ministros não veem nada → fingem que veem

  • O povo não vê nada → aplaude

Até que…

👶 uma criança, sem medo de RACF social, diz:

“O rei está pelado!”

ABEND imediato do sistema.


4️⃣ O bug não é a roupa — é o medo

O ponto genial do conto não é a nudez do rei.
É o medo coletivo de contrariar o consenso.

No mundo mainframe, isso é clássico:

  • “Esse sistema é crítico, ninguém mexe”

  • “Sempre foi assim”

  • “Não documenta porque funciona”

  • “Não pergunta, só roda o batch”

No anime, isso aparece o tempo todo:

🎌 Exemplos de paralelos em anime

  • Neon Genesis Evangelion: adultos fingindo controle enquanto tudo desmorona

  • Attack on Titan: verdades ocultas sustentadas por consenso

  • One Piece: reis, governos e símbolos vazios mantidos pelo medo

  • Akira: poder sem responsabilidade


5️⃣ Easter eggs e curiosidades culturais

🥚 Easter egg #1 — A criança não é inocente, é livre

A criança não fala porque é “pura”.
Ela fala porque não está presa ao sistema.

Não depende:

  • do cargo

  • da hierarquia

  • da aprovação

É o estagiário que pergunta:

“Mas por que isso é assim?”

E todo mundo fica desconfortável.


🥚 Easter egg #2 — O rei sabe que está pelado

Muita gente acha que o rei é enganado.
Errado.

Ele sabe que não vê nada.
Mas escolhe seguir.

Isso é mais assustador.


🥚 Easter egg #3 — O desfile é produção

O rei não testa em homologação.
Ele vai direto pra produção.

Clássico.


6️⃣ Por que essa história dialoga tanto com mainframers?

Porque mainframe é:

  • legado

  • hierarquia

  • respeito

  • estabilidade

  • medo de quebrar

E isso é bom… até virar silêncio tóxico.

Quantos sistemas continuam rodando porque:

  • ninguém quer ser o chato

  • ninguém quer assumir o risco

  • ninguém quer dizer “isso não faz sentido”


7️⃣ A Roupa Nova do Rei no mundo dos animes

O Japão adora essa metáfora.

🎌 Em animes, ela aparece como:

  • líderes cegos pela própria imagem

  • sistemas falsamente perfeitos

  • tradições vazias

  • poderes simbólicos

Exemplo clássico:

  • Conselhos que ninguém questiona

  • Vilas que seguem regras absurdas

  • Mestres que ninguém ousa confrontar

O herói geralmente é:
➡️ o “idiota”
➡️ o “ingênuo”
➡️ o “fora do sistema”

A criança do conto é um protagonista de shonen sem saber.


8️⃣ A lição que ninguém gosta de ouvir

A história não ensina:

“Não seja vaidoso”

Ela ensina:

“Não silencie a verdade por medo de parecer incompetente.”

No mundo corporativo:

  • muita gente vê o problema

  • pouca gente fala

  • e quando fala… já é tarde


9️⃣ Bellacosa Mainframe Moment™ 🖥️

Se esse conto fosse um sistema:

  • A roupa é um software inexistente

  • O rei é o sponsor

  • Os ministros são os gestores

  • O povo é o usuário final

  • A criança é o operador experiente

A diferença?

O operador não tem medo de console.


🔟 Moral da história (em linguagem de data center)

IF TODOS FINGEM QUE FUNCIONA
   THEN ALGUÉM ESTÁ MENTINDO

E geralmente:

  • não é o sistema

  • não é a máquina

  • é o comportamento humano


🜂 Encerramento — por que esse conto nunca envelhece?

Porque ele fala menos de reis
e mais de nós.

Enquanto houver:

  • status

  • medo

  • hierarquia

  • modismos

  • buzzwords

  • tecnologias “mágicas”

A Roupa Nova do Rei continuará rodando.

E sempre precisaremos da criança…
ou do mainframer veterano…
ou do otaku questionador…

pra olhar pra tela e dizer:

“Pessoal… isso aí não está vestindo nada.”



segunda-feira, 6 de dezembro de 2010

🔥 Os 50 Principais ABENDs em CICS

 

Lista dos 50 principais erros em CICS

🔥 Os 50 Principais ABENDs em CICS
Possíveis causas, soluções e sabedoria de data center


☕ Midnight Lunch, região viva… e o ABEND aparece

14h07.
Tela congelou.
CEMT I TASK mostra status estranho.
O operador solta a clássica frase:

“Deu ABEND no CICS…”

Mas qual ABEND?
E mais importante: por quê?

Hoje vamos entrar no lado sombrio do CICS — os 50 ABENDs mais comuns, com causa raiz, solução e comentários de quem já apagou muito incêndio.


🏛️ História: ABEND não é erro, é aviso

No mundo CICS:

  • ABEND ≠ bug automático

  • ABEND = proteção

  • O sistema prefere matar a task do que corromper dados

📌 ABEND é o CICS dizendo: “daqui não passa”.


🧠 Conceito essencial

Quem entende ABEND, domina produção.


Lista de abends mais comuns em CICS


💥 Top 50 ABENDs em CICS (causas & soluções)


🔴 ABENDs de Programação

  1. AEIP – Comando CICS inválido
    👉 Causa: erro de lógica
    ✅ Solução: revisar comando EXEC CICS

  2. AEIM – Mapa inexistente
    👉 MAPSET não carregado
    ✅ Definir corretamente no CICS

  3. AEI0 – Erro de terminal
    👉 Sessão inválida
    ✅ Validar TC

  4. AEIS – Storage corrompido
    👉 Ponteiro inválido
    ✅ Revisar GETMAIN/FREEMAIN

  5. AEIN – Intervalo inválido
    👉 WAIT TIME errado
    ✅ Ajustar intervalo


🔴 ABENDs de Arquivo (File Control)

  1. AEIO – Erro de I/O
    👉 VSAM indisponível
    ✅ Verificar dataset

  2. AEIL – Arquivo não definido
    👉 FCT incorreta
    ✅ Corrigir definição

  3. AEIR – Registro não encontrado
    👉 READ sem verificação
    ✅ Tratar NOTFND

  4. AEIW – WRITE inválido
    👉 Layout errado
    ✅ Ajustar estrutura

  5. AEID – DELETE inválido
    👉 Registro inexistente
    ✅ Validar chave


🔴 ABENDs de Storage

  1. AEY9 – Falta de storage
    👉 Vazamento de GETMAIN
    ✅ Liberar storage

  2. ASRA – Protection exception
    👉 Storage corrompido
    ✅ Revisar ponteiros

  3. ASRB – Arithmetic exception
    👉 DIVIDE BY ZERO
    ✅ Validar cálculo

  4. AEYA – Storage key error
    👉 Região protegida
    ✅ Revisar chave

  5. AEYD – Stack overflow
    👉 Loop recursivo
    ✅ Corrigir lógica


🔴 ABENDs de Program Control

  1. AEIX – XCTL inválido
    👉 Programa inexistente
    ✅ Corrigir nome

  2. AEIL – LINK inválido
    👉 Parâmetros errados
    ✅ Ajustar COMMAREA

  3. AEIY – Programa não reentrante
    👉 Uso incorreto
    ✅ Tornar reentrante

  4. AEIZ – RETURN inválido
    👉 Fluxo quebrado
    ✅ Revisar lógica

  5. AEIP – LINK circular
    👉 Arquitetura ruim
    ✅ Refatorar fluxo


🔴 ABENDs de Terminal / BMS

  1. AEIM – Mapa não encontrado
    👉 MAPSET não carregado
    ✅ CEDA INSTALL

  2. AEIT – Erro de terminal
    👉 Sessão encerrada
    ✅ Validar conexão

  3. AEIB – Buffer overflow
    👉 Campo maior que área
    ✅ Ajustar tamanho

  4. AEIA – Atributo inválido
    👉 BMS errado
    ✅ Revisar mapa

  5. AEIC – Cursor inválido
    👉 Campo inexistente
    ✅ Corrigir IC


🔴 ABENDs de Transação / Task

  1. AEIT – Task inválida
    👉 Estado inconsistente
    ✅ Revisar RETURN

  2. AEI3 – Transação não definida
    👉 PCT ausente
    ✅ Definir TRANSID

  3. AEI4 – Security violation
    👉 Falta de autorização
    ✅ Ajustar RACF

  4. AEI5 – Time-out
    👉 Loop infinito
    ✅ Otimizar lógica

  5. AEI6 – Deadlock
    👉 Lock excessivo
    ✅ Reduzir escopo


🔴 ABENDs de Integração / Sistema

  1. APCT – Erro de Program Control
    👉 Configuração errada
    ✅ Revisar região

  2. AICA – Conversão inválida
    👉 Dados inconsistentes
    ✅ Validar formatos

  3. AICM – MQ error
    👉 Fila indisponível
    ✅ Verificar MQ

  4. AIDB – DB2 error
    👉 SQLCODE negativo
    ✅ Tratar SQL

  5. AIDS – Data inconsistente
    👉 Conversão errada
    ✅ Sanitizar dados


🔴 ABENDs “Clássicos de Guerra”

  1. ASRA – O mais temido
    👉 Memory overwrite
    ✅ Debug profundo

  2. AEIP – O mais comum
    👉 Código mal tratado
    ✅ Revisar lógica

  3. AEY7 – Storage leak
    👉 GETMAIN sem FREEMAIN
    ✅ Corrigir ciclo

  4. AEZC – CICS internal
    👉 Bug ou stress
    ✅ IBM support

  5. AFCA – File corruption
    👉 VSAM danificado
    ✅ Rebuild


🔴 ABENDs de Segurança

  1. AEI4 – RACF denial
    👉 Permissão faltando
    ✅ Ajustar perfil

  2. AESP – Security program
    👉 Violação
    ✅ Revisar acessos

  3. AEPI – Program protected
    👉 Programa não autorizado
    ✅ CEDA SET PROG

  4. AEXY – User exit failure
    👉 Exit defeituoso
    ✅ Debug exit

  5. AEXZ – Transaction denied
    👉 Perfil incorreto
    ✅ RACF


🔴 Os últimos, mas não menos perigosos

  1. AEZ9 – Resource unavailable
    👉 Falta de recurso
    ✅ Ajustar região

  2. AEZA – Internal error
    👉 Estado crítico
    ✅ Restart controlado

  3. AEZH – Program load failure
    👉 Load module ausente
    ✅ Reinstalar

  4. AEZI – System overload
    👉 Pico de tasks
    ✅ Tuning

  5. AEZZ – O “não documentado”
    👉 Algo muito errado
    ✅ Chamar o mais velho da sala 😈


📚 Guia de estudo para mainframers

Domine:

  • HANDLE ABEND

  • CEMT I TASK

  • DFHDU

  • Dumps CICS

  • SMF + logs

📖 Manual essencial: CICS Problem Determination Guide


🤓 Curiosidades de boteco mainframe

🍺 ASRA já aposentou muita gente
🍺 AEIP é quase rito de passagem
🍺 Todo ABEND ensina algo
🍺 Quem lê dump vira referência


💬 Comentário El Jefe Midnight Lunch

“ABEND não é o fim.
É o CICS pedindo para você pensar.”


🎯 Conclusão Bellacosa

Conhecer ABEND:

  • Reduz MTTR

  • Evita pânico

  • Dá respeito em produção

🔥 Quem entende ABEND, manda no CICS.


domingo, 5 de dezembro de 2010

Bellacosa Index Page: Checklist de Indexação SEO – Guia Completo

 

Check list seo page

Checklist de Indexação SEO – Guia Completo

1. Permitir indexação nos motores de busca

Antes de qualquer otimização, é essencial garantir que o site possa ser indexado. Verifique se não há bloqueios globais, como:

  • noindex aplicado ao site inteiro

  • configurações de privacidade ativadas

  • cabeçalhos HTTP do tipo X-Robots-Tag: noindex

Use o Google Search Console para confirmar se as páginas estão “Disponíveis para o Google”.


2. Robots.txt bem configurado

O arquivo robots.txt controla o rastreamento. Uma configuração correta:

  • permite acesso às páginas importantes

  • bloqueia áreas irrelevantes (ex: páginas de busca internas)

  • declara o sitemap

Exemplo recomendado:

User-agent: * Disallow: /search Allow: / Sitemap: https://www.seusite.com/sitemap.xml

Evite erros graves como Disallow: /, que bloqueia todo o site.


3. Sitemap XML funcional e enviado

O sitemap ajuda o Google a descobrir URLs.
Boas práticas:

  • gerar sitemap automático

  • incluir apenas páginas indexáveis

  • enviar no Google Search Console

  • monitorar erros de leitura

O sitemap não deve ser indexado, apenas lido por robôs.


4. Uso correto de meta robots

As tags meta robots ou regras de robôs personalizadas devem ser usadas com cautela:

  • páginas e posts importantes: index, follow

  • páginas de busca e arquivo: noindex

Nunca aplique noindex em páginas que você deseja que apareçam nos resultados.


5. Estrutura correta de títulos (Headings)

Cada página deve conter:

  • 1 único H1 (título principal)

  • H2 para subtítulos

  • H3/H4 para hierarquia interna

Os headings ajudam o Google a entender o tema e a organização do conteúdo.


6. Títulos e meta descrições otimizados

Cada página deve ter:

  • título único e descritivo (50–60 caracteres)

  • meta descrição clara e atrativa (120–160 caracteres)

Esses elementos influenciam diretamente o CTR (taxa de cliques) nos resultados de busca.


7. Conteúdo com qualidade e profundidade

Conteúdo é um dos principais fatores de SEO.
Checklist mínimo:

  • textos com 300 palavras ou mais

  • conteúdo original

  • respostas claras à intenção do usuário

  • parágrafos curtos e escaneáveis

Conteúdo fraco tende a ser ignorado ou removido do índice.


8. URLs amigáveis

Boas URLs:

  • curtas

  • sem parâmetros desnecessários

  • com palavras-chave

  • sem caracteres especiais

Exemplo bom:

/checklist-indexacao-seo.html

9. Links internos estratégicos

Links internos:

  • ajudam o Google a descobrir páginas

  • distribuem autoridade

  • aumentam tempo de permanência

Checklist:

  • cada post deve linkar para outros conteúdos relevantes

  • páginas importantes devem ser acessíveis a partir da home


10. Links externos confiáveis

Links para sites relevantes:

  • aumentam credibilidade

  • contextualizam o conteúdo

  • melhoram a experiência do usuário

Evite links quebrados ou para sites de baixa qualidade.


11. Otimização de imagens

Imagens também são indexáveis:

  • usar nomes descritivos

  • preencher o atributo alt

  • comprimir arquivos

  • evitar imagens muito pesadas

Isso melhora SEO e velocidade.


12. Performance e velocidade

Sites lentos têm pior desempenho nos rankings.
Verifique:

  • tempo de carregamento

  • excesso de scripts

  • imagens não otimizadas

Ferramenta recomendada: Google PageSpeed Insights.


13. Mobile-friendly (responsivo)

A indexação do Google é mobile-first.
Checklist:

  • layout responsivo

  • textos legíveis no celular

  • botões clicáveis

  • sem pop-ups intrusivos


14. Evitar conteúdo duplicado

Conteúdo duplicado confunde os buscadores.
Cuidados:

  • não repetir textos inteiros

  • usar canonical quando necessário

  • evitar múltiplas URLs com o mesmo conteúdo


15. Dados estruturados (Schema)

Sempre que possível, use dados estruturados para:

  • artigos

  • breadcrumbs

  • reviews

  • vídeos

Isso pode gerar rich snippets e aumentar o CTR.


16. Frequência de publicação

Sites atualizados com frequência são rastreados com mais regularidade.

  • mantenha consistência

  • evite longos períodos sem novos conteúdos


17. Monitoramento constante

SEO não é tarefa única.
Checklist de acompanhamento:

  • revisar relatórios do Search Console

  • corrigir páginas excluídas

  • atualizar conteúdos antigos

  • acompanhar desempenho


18. Experiência do usuário

O Google avalia sinais de uso:

  • tempo na página

  • taxa de rejeição

  • navegação intuitiva

Conteúdo bom e bem estruturado retém o visitante.


Conclusão

Um Checklist de Indexação SEO bem aplicado garante que seu site:

  • seja rastreável

  • seja indexado corretamente

  • tenha conteúdo compreendido pelos motores de busca

  • ofereça boa experiência ao usuário

SEO não é sobre truques, mas sobre clareza, qualidade e consistência.
Ao seguir este checklist, você cria uma base sólida para crescer organicamente, ganhar visibilidade e construir autoridade nos motores de busca de forma sustentável.


sexta-feira, 3 de dezembro de 2010

🧱 IBM Mainframe Storage Management no z/OS

Bellacosa Mainframe apresenta Storage Management no IBM z/OS



🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.


☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

  • Já sofreu com SMS override

  • Já ouviu “o ACS mandou”

  • Já viu dataset ir parar num disco que você nem sabia que existia

  • Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.


🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

  • Disco era caro

  • Poucos volumes

  • Programador escolhia tudo

  • Erro humano era rotina

💣 Anos 80: o caos

  • Explosão de dados

  • Batch gigante

  • Fragmentação absurda

  • Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

  • Padronizar

  • Automatizar

  • Controlar

  • Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.


🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

  • Parte nativa do z/OS

  • Gerente de dados

  • Juiz das decisões de disco

  • Guarda-costas da infraestrutura

Ele cuida de:

  • DASD

  • TAPE

  • Migração

  • Backup

  • Alocação

  • Performance

  • Disponibilidade


💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

  • z/OS

  • SYS1

  • Aplicações

  • VSAM

  • Logs

  • Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

  • Tape é barato

  • Tape é denso

  • Tape é confiável

  • Tape é rei do backup

DFSMS controla:

  • Migração HSM

  • Recall automático

  • Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.


🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

  • VOL=SER

  • SPACE

  • UNIT

Vantagem:

  • Controle total

Desvantagem:

  • Risco total

📌 Hoje: usado só em casos muito específicos.


🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

  • Nome do dataset

O SMS decide:

  • Onde fica

  • Quanto espaço

  • Performance

  • Migração

📌 Naming convention é lei.


🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

  • Data Class

  • Storage Class

  • Storage Group

Baseado em:

  • Nome do dataset

  • Usuário

  • Programa

  • Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.


🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

  • Storage admin

  • Infra

  • Arquitetura

Aqui você vê:

  • Volumes

  • Classes

  • Storage Groups

  • ACS

  • Espaço real

📌 Programador geralmente não entra aqui.


🧱 Data Class – O DNA do dataset

Define:

  • RECFM (FB, VB…)

  • LRECL

  • DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.


🚀 Storage Class – Performance e SLA

Define:

  • Prioridade

  • Backup

  • Migração

  • Disponibilidade

📌 Onde o negócio fala mais alto que o código.


🗄️ Storage Group – O endereço físico

  • Conjunto de volumes

  • Abstração total

  • Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.


📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

  • Batch

  • Relatórios

  • Entrada/Saída simples


📚 PO / PDS / PDSE

  • Código

  • JCL

  • Copybooks

📌 PDSE > PDS (sempre que possível).


🧬 VSAM

  • KSDS

  • ESDS

  • RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.


📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”


🧪 Passo a passo prático (vida real)

  1. Dataset criado

  2. ACS roda

  3. Classes atribuídas

  4. Volume escolhido

  5. Espaço ajustado

  6. Catálogo atualizado

Tudo automático.


🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito


🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype


☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

  • 📚 Transformar isso em curso

  • 🧪 Criar labs práticos

  • 🎓 Adaptar para aula corporativa

  • 🔐 Criar versão bancária real

  • 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️


sexta-feira, 5 de novembro de 2010

🐱 Maneki-neko – o gato que dá IPL na sorte

 

Bellacosa Mainframe apresenta o famoso gato da sorte maneki neko

Perfeito. Vamos de Maneki-neko no modo Bellacosa Mainframe 🐱⚙️
Origem, história, fofoca, easter egg, curiosidade inútil-útil e aquele paralelo inevitável com sistemas que não podem cair.


🐱 Maneki-neko – o gato que dá IPL na sorte

Se você já entrou num restaurante japonês, numa lojinha de bairro ou até num boteco “meio oriental”, provavelmente viu ele lá:
um gato sentado, uma patinha levantada, olhando para o nada… mas trabalhando pesado.

O Maneki-neko (招き猫) não está acenando.
Ele está chamando.

E isso muda tudo.


Maneki neko

📜 Origem: logs antigos do Japão feudal

O termo Maneki-neko vem de:

  • maneku (招く) → convidar, chamar

  • neko (猫) → gato

Ou seja:

“o gato que chama”

As origens mais aceitas ficam entre os séculos XVII e XVIII, no Período Edo, quando o Japão começa a urbanizar, surgem comércios, rotas internas e… concorrência.

Existem três lendas principais, como qualquer sistema legado respeitável.


🏯 Lenda do Templo Gotoku-ji (a mais famosa)

Um senhor feudal passava por um templo pobre durante uma tempestade.
Viu um gato levantando a pata, como se chamasse.

Curioso, se aproximou.
No instante seguinte, um raio caiu exatamente onde ele estava antes.

Resultado:

  • Sobreviveu

  • Financiou o templo

  • O gato virou símbolo de proteção + prosperidade

Failover espiritual bem-sucedido.


🏮 Lenda da velha comerciante pobre

Uma senhora, sem dinheiro, sonha com um gato dizendo:

“Faça estátuas de mim e você nunca passará fome.”

Ela obedece.
As pessoas começam a comprar.
O dinheiro volta.

Primeiro caso documentado de monetização de mascote.


🧧 Lenda da gueixa e o gato enforcado (a versão dark)

Um gato puxa o quimono da gueixa repetidamente.
Assustado, um cliente decapita o gato.

A cabeça voa, mata uma cobra venenosa que estava prestes a atacar a gueixa.

Culpa, remorso, estátuas do gato…

Backup tardio, mas com aprendizado.


🐾 A pata levantada NÃO é aleatória

Aqui entra a parte que pouca gente sabe:

  • 🐱 Pata esquerda levantada
    → chama clientes, pessoas, movimento
    → comum em lojas e restaurantes

  • 🐱 Pata direita levantada
    → chama dinheiro, prosperidade
    → comum em empresas, caixas, escritórios

  • 🐱 Duas patas levantadas
    → proteção total
    → também conhecido como “overkill visual”

Duas patas = firewall + IDS + backup offsite.


🎨 Cores e seus significados

Nada no Maneki-neko é decorativo. Tudo é configuração.

  • 🤍 Branco → pureza, novos começos (default)

  • 🖤 Preto → proteção contra azar

  • ❤️ Vermelho → saúde

  • 💛 Dourado → dinheiro (o mais vendido)

  • 💚 Verde → estudos, crescimento

  • 💗 Rosa → amor (versão moderna)


🧧 A moeda oval (koban)

Muitos Maneki-nekos seguram uma moeda com inscrição:

千万両 (sen man ryō)

Tradução livre:

“10 milhões de ryō”
(uma fortuna absurda na época)

É o equivalente espiritual a:

MAX-AMOUNT=YES


🥚 Easter eggs culturais

  • O gesto japonês de “chamar alguém” é com a palma para baixo, não para cima
    → o gato NÃO está dando tchau

  • No anime Natsume Yuujinchou, Doraemon, Pokémon, Bleach e até Hello Kitty, referências ao Maneki-neko aparecem o tempo todo

  • O bairro de Gotoku-ji, em Tóquio, tem milhares de estátuas acumuladas
    → um spool espiritual de agradecimento


🧠 Tradução para o mundo mainframe

O Maneki-neko representa:

  • Alta disponibilidade

  • Chamada constante de recursos

  • Proteção contra eventos inesperados

  • Resiliência silenciosa

Ele não faz barulho.
Não promete milagres.
fica lá, funcionando.

Como um CICS estável numa sexta-feira à noite.


☕ Comentário final estilo El Jefe

Talvez o Maneki-neko não traga dinheiro sozinho.
Mas ele lembra algo fundamental:

Sorte também é disciplina, atenção e constância.

O gato não corre atrás da prosperidade.
Ele senta, observa…
e chama.

Como todo bom sistema que dura décadas.


🐾⚙️

quinta-feira, 4 de novembro de 2010

🧠 SMP/E for z/OS – Uma Revisão

 

Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉


🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

  • O sistema vinha em DLIB tapes

  • O SYSGEN tinha Stage 1 e Stage 2

  • O programador montava tudo na unha

  • E manutenção?
    👉 Manual. Muito manual.

Resultado?

  • Instabilidade

  • Erros humanos

  • Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.


🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

  • Global Zone → cérebro

  • Target Zone → sistema em execução

  • Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.


🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

  • O que está instalado?

  • Onde está?

  • Como foi construído?

  • Quem depende de quem?

Zonas:

  • Global Zone
    Índice mestre + opções de controle

  • Target Zone
    Reflete o que está rodando

  • Distribution Zone
    Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.


📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

  • FUNCTION → produto novo

  • PTF → serviço preventivo

  • APAR → correção corretiva

  • USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

  • MCS (++ statements) → inteligência

  • Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.


🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

  1. RECEIVE

    • Entra no SMPPTS

    • Atualiza Global Zone

    • Nada muda no sistema ainda

  2. APPLY

    • Atualiza Target Libraries

    • Sistema pode ser testado

    • Ainda reversível

  3. RESTORE

    • Volta ao último nível aceito

    • Usa DLIB como fonte

    • Seu botão de “desfazer”

  4. ACCEPT

    • Atualiza DLIB

    • Ponto sem volta

    • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.


🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

  • Menos fita

  • Mais automação

  • Menos transporte físico

  • Mais rastreabilidade

Opções modernas:

  • ServerPac → replace completo

  • CBPDO → produto ou serviço incremental

  • Internet Delivery

    • RECEIVE FROMNETWORK

    • RECEIVE FROMNTS

    • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.


🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

  • Ele aparece como Open

  • Depois Submitted ou Order Center

  • E você acompanha em:
    👉 In Progress

Quando muda para Download
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade


🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

  • Ordena PTF automaticamente

  • Agenda serviço

  • Controla origem dos fixes (SourceID)

  • Centraliza histórico

Tudo isso com:

  • RECEIVE ORDER

  • ORDER Management (Option 7)

  • Java ou ICSF

  • FTPS + Hash SHA-1


🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

  • Clone do sistema

  • Program Directory

  • PSP Buckets

  • Espaço em Target, DLIB e SMP/E datasets

  • IVP depois

  • Testes reais

  • Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.


🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.


quarta-feira, 3 de novembro de 2010

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.


🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

  • Substituir JCL “verboso”

  • Padronizar scripts

  • Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.


🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

  • TSO/E

  • Batch

  • SDSF

  • ISPF

  • CICS (indiretamente)

  • Programas externos

Cada ambiente define:

  • Comandos válidos

  • RC interpretado

  • Recursos disponíveis

  • Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.


🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

  • Tipagem dinâmica

  • Strings como cidadão de primeira classe

  • Sem declaração obrigatória

  • Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2 if parm1 = '' then exit 8

Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.


🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

  1. Identificação

  2. Validação de ambiente

  3. Tratamento de RC

  4. Controle de erro

  5. Cleanup

📌 Exemplo base:

/* REXX */ signal on error signal on failure signal on syntax address tso "ALLOC FI(IN) DA('DATASET') SHR" ... exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.


🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A' tab.2 = 'B' tab.0 = 2

Curiosidade:
Stem mal controlado vira memory leak conceitual.


📂 Acesso a Arquivos & Geração de Relatórios

  • ALLOC / FREE

  • EXECIO DISKR / DISKW

  • Geração de relatórios spoolados

  • Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)" do i=1 to L.0 say L.i end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.


🔃 Classificação & Manipulação de Dados

  • SORT via IDCAMS

  • SORT via ICETOOL

  • Manipulação em memória (lento)

  • Pipeline híbrido REXX + SORT

Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.


🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

  • LMDINIT

  • LMMLIST

  • LMCLOSE

📌 Exemplo:

address ispexec "LMINIT DATAID(DID) DATASET('MY.PDS')" "LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.


🧑‍💻 Interatividade com Usuário (TSO)

  • Pseudo-conversational

  • Command-level

  • SAY / PULL

  • Mensagens controladas

Fofoquice:
Interface feia, mas resolve crise em minutos.


🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

  • Interativo

  • Debug rápido

  • Dependente de perfil

🟡 REXX Batch Script (Interpretado)

  • Executa via IKJEFT01

  • Dependente de ambiente

  • Mais flexível

🔴 REXX Batch Compilado

  • Performance superior

  • RC previsível

  • Menos tolerante a erro

  • Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.


🔐 REXX + RACF

REXX não ignora segurança:

  • Herda permissões do usuário

  • Pode consultar via RACROUTE (indireto)

  • Controla acesso via classes

Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.


🗄️ REXX + DB2

  • DSNREXX

  • SQL dinâmico

  • RC + SQLCODE + SQLSTATE

  • Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX "EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.


🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

  • TSO

  • ISPEXEC

  • SDSF

  • CONSOLE

  • DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.


🔢 Return Code (RC) — o idioma da produção

  • RC ≠ erro sempre

  • RC precisa ser interpretado

  • Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.


📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

  • Ambiente restritivo

  • Casos reais

  • Incidentes simulados

Instruções REXX

  • IF, DO, SELECT

  • SIGNAL, EXIT

  • PARSE

Funções Internas / Sub-rotinas

  • Modularização

  • Reuso

  • Controle de escopo

Comandos REXX

  • SAY, PULL, TRACE

  • QUEUE / PULL

  • EXECIO

Funções TSO / CONSOLE

  • WTO

  • MODIFY

  • DUMP

  • SDSF

INTERPRET (🔥 perigoso)

  • Execução dinâmica

  • Flexibilidade extrema

  • Risco máximo

Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.


🥚 Easter Eggs & Fofoquices REXX

  • Todo ambiente tem um EXEC “salvador”

  • Sempre existe um REXX sem comentários rodando há anos

  • O melhor REXX é o que não precisa ser explicado

  • Debug começa com TRACE ?R


☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

  • Script simples

  • Linguagem de iniciante

  • Alternativa ao COBOL

REXX é:

  • Cola do z/OS

  • Automação estratégica

  • Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.