Bellacosa Mainframe apresenta SMP/E Apply Processing

SMP/E for z/OS – Apply Processing

O momento em que o código vira sistema

Se o RECEIVE é quando o código chega na casa e o ACCEPT é quando ele vira herança oficial, o APPLY é o momento crítico: quando o código realmente entra em produção técnica, nos target libraries.

É aqui que o SMP/E deixa de ser teoria, CSI e HOLDDATA… e começa a mexer em load modules, macros, fontes, JARs, HFS e dados reais do sistema.

No estilo Bellacosa Mainframe: APPLY não é comando — é cirurgia.

---

O que o APPLY faz (sem romantizar)

O comando APPLY:

• Instala elementos fornecidos por SYSMODs nas Target Libraries

• Atualiza o Target Zone (TZONE) com o novo estado do sistema

• Garante que nenhum serviço seja regredido

• Controla dependências, pré-requisitos, co-requisitos e IF-REQs

• Invoca utilitários reais do sistema (Binder, IEBCOPY, IEBUPDTE, BPXCOPY, etc.)

📌 Importante:

APPLY NUNCA deve ser feito diretamente em produção. Sempre em clone, test system, shadow libraries.

---

Target Libraries, Target Zone e Distribution Zone

• Target Libraries: onde vivem os executáveis, macros, fontes e dados usados pelo sistema

• Target Zone (TZONE): o mapa vivo do que está instalado e em qual nível

• Distribution Libraries (DLIB): código base, mantido pelo ACCEPT

• Distribution Zone (DZONE): mapa do código base

👉 APPLY mexe apenas em Target Libraries e TZONE.

---

SET BDY – dizendo ao SMP/E onde operar

Antes do APPLY:

SET BDY(TARGET1)
APPLY ...

Cada Target Zone mapeia um conjunto específico de bibliotecas.

💡 Estratégia clássica:

• APPLY no sistema de teste

• Validação

• Promoção do clone para produção

---

Como o SMP/E escolhe os SYSMODs

A seleção é controlada pelos operandos do APPLY:

Seleção direta

• SELECT

• EXCLUDE

• FORFMID

Por tipo

• FUNCTION

• PTF

• APAR

• USERMOD

Por origem

• SOURCEID

• EXSRCID

Se nenhum tipo for especificado:
👉 default = apenas PTFs

---

GROUP e GROUP EXTEND – o efeito dominó controlado

GROUP

Inclui automaticamente:

• Pré-requisitos (PRE)

• Co-requisitos (REQ)

• IF-requisitos

Exemplo:

• UL9 → requer UL7 e UL8

• UL7 → requer UL5

• UL8 → requer UL6

👉 APPLY com GROUP seleciona UL9, UL7, UL8, UL5 e UL6

GROUP EXTEND

Vai além:

• Resolve HOLDs automaticamente

• Procura SYSMODs que supersedem erros ou requisitos faltantes

• Pesquisa no GZONE e PTS

⚠️ Pode ser restringido:

• NOAPARS

• NOUSERMODS

---

BYPASS – a alavanca perigosa

Quando uma condição geraria erro fatal, o BYPASS manda o SMP/E ignorar.

Exemplos:

• BYPASS(ID)

• BYPASS(HOLD)

• BYPASS(XZIFREQ)

• BYPASS(HOLDFIXCAT)

⚠️ Use com extremo cuidado

Todo desastre em SMP/E começa com alguém que confiou demais no BYPASS.

---

APPLY CHECK – a simulação obrigatória

APPLY CHECK ...

O CHECK:

• Não atualiza bibliotecas

• Não altera CSI

• Simula seleção, dependências e validações

• Detecta regressões

🚨 CHECK não valida espaço em disco

📌 Dica Bellacosa:

CHECK sempre com BYPASS(HOLDSYSTEM,HOLDID)

---

REDO – reaplicando serviço

Usado quando:

• Biblioteca foi restaurada de backup antigo

• Fix aplicado se perdeu

APPLY SELECT(AZ81463) REDO

👉 Reinstala mesmo que já conste como aplicado

---

Espaço em disco: RETRY e COMPRESS

COMPRESS

• COMPACTA bibliotecas alvo

• Pode ser:

  • Por DDNAME

  • ALL

RETRY

• Default = YES

• Reage a erros de espaço

• Usa lista definida no GZONE (RETRYDDN)

⚠️ Pegadinha clássica:

CHECK + COMPRESS ALL não faz sentido

CHECK não atualiza nada → COMPRESS não ocorre.

---

Applicability Checks – o funil do SMP/E

Depois da seleção:

1. Verifica se o FMID pertence ao Target Zone

2. Valida PRE, REQ e IF-REQ

3. Verifica HOLDs (SYSTEM, ERROR, USER, FIXCAT)

4. Executa cross-zone IFREQ (XZIFREQ)

5. Determina ordem de processamento

Ordem padrão:

1. Functions

2. PTFs

3. APARs

4. USERMODs

---

DELETE em Functions – quando uma versão morre

Funções podem ter:

++VER DELETE

Efeito:

• Remove elementos da função antiga

• Remove entradas no TZONE

• Remove serviços dependentes

👉 DELETE explícito e implícito

---

JCLIN – a alma estrutural do APPLY

JCLIN:

• É processado durante o APPLY

• Cria estrutura no TZONE

• Define MOD, LMOD, SYSLIB, LKEDCNTL

📦 Resultado:

• SMP/E sabe como montar o load module

CALLLIBS

• Indica linkagens implícitas

• Binder é chamado duas vezes

• Usa SMPMTS para restore futuro

---

Element Selection – evitando regressão

Cada elemento é rastreado por:

• FMID – quem introduziu

• RMID – quem substituiu

• UMID – quem atualizou

SMP/E usa:

• ++VER PRE

• ++VER SUP

Para garantir:

Nenhum APPLY reduz o nível atual do elemento

---

Instalação real dos elementos

Dependendo do tipo:

• MOD → Binder (link-edit)

• MAC / SRC → IEBCOPY / IEBUPDTE

• JAR → COPY ou GIMDRS

• DATA / HFS → COPY / BPXCOPY

GIMDTS / GIMDRS

• Permitem empacotar elementos não FB80

• Reconversão automática no APPLY

---

CSI Updates – o inventário consolidado

Após o APPLY:

• Atualiza entradas de elementos no TZONE

• Atualiza FMID, RMID, UMID

• Cria SYSMOD entry no TZONE

• Atualiza APPID no GZONE

📌 Regra de ouro:

Status de APPLY se verifica no TZONE, não no GZONE

---

Relatórios – o SMP/E contando vantagem

Principais relatórios:

• SYSMOD Status Report

• Element Summary Report

• Causer SYSMOD Summary (Root Cause)

• Regression Report

• Unresolved HOLD Report

• HOLDDATA Summary

DDs importantes:

• SMPRPT

• SMPHRPT (HOLDDATA separado)

---

FIXCAT no APPLY moderno

FIXCAT permite:

• Expressar interesse por categorias

• Bloquear APPLY se serviço crítico faltar

• Automatizar PSP buckets

Exemplo estratégico:

FIXCAT(IBM.ProductInstall-RequiredService)

👉 Garante instalação de todo serviço recomendado

---

Conclusão Bellacosa

APPLY é onde o SMP/E deixa de ser administrativo e vira operacional.

Quem domina APPLY:

• Não quebra produção

• Não regride serviço

• Não depende de sorte

No mainframe, conhecimento não é poder — é sobrevivência.

No próximo capítulo: ACCEPT – quando o código vira base do sistema.

 

Bellacosa Mainframe e a assustadora Kuchisake-Onna

☕👄💣 KUCHISAKE-ONNA — O CHAMADO DE PRODUÇÃO QUE NINGUÉM DEVERIA ATENDER

Se você trabalhou anos em produção de mainframe, sabe que existe uma regra não escrita:

Quando o telefone toca às 3 da manhã, raramente vem coisa boa.

Agora imagine receber uma chamada em uma rua vazia.

Uma mulher se aproxima.

Ela usa máscara.

Ela olha diretamente para você e faz apenas uma pergunta:

"Eu sou bonita?"

Nesse exato momento, você acaba de iniciar um dos jobs mais perigosos da história do folclore japonês.

Bem-vindos ao caso de Kuchisake-Onna, a Mulher da Boca Rasgada, uma lenda urbana que há décadas assombra o imaginário japonês e continua aterrorizando novas gerações.

---

O DATASET MAIS ASSUSTADOR DO FOLCLORE JAPONÊS

Kuchisake-Onna (口裂け女) significa literalmente:

"Mulher da Boca Cortada".

Segundo a lenda, ela aparece usando uma máscara cirúrgica — algo extremamente comum no Japão.

À primeira vista, parece apenas mais uma pessoa caminhando pela rua.

Mas então ela faz a pergunta fatal:

"Watashi, kirei?"

"Eu sou bonita?"

Se a vítima responder "não", ela é morta imediatamente.

Se responder "sim", a mulher remove a máscara.

É então que o sistema sofre um ABEND.

Sua boca está rasgada de uma orelha à outra.

Uma cicatriz grotesca atravessa todo o rosto.

Ela então faz a segunda pergunta:

"E agora?"

Nesse momento não existe resposta correta.

É como um programa COBOL preso em loop infinito sem condição de saída.

---

O BUG LÓGICO DA MALDIÇÃO

A genialidade da lenda está justamente na armadilha.

A pergunta parece simples.

Mas qualquer resposta leva ao desastre.

Se disser que ela continua bonita, ela pode cortar seu rosto para deixá-lo igual ao dela.

Se disser que ela é horrível, ela o mata.

Ou seja:

Você entrou em um fluxo sem rollback.

Um job condenado desde o primeiro EXEC.

Por isso muitos estudiosos classificam Kuchisake-Onna como uma das primeiras lendas urbanas modernas do Japão.

Ela funciona quase como um algoritmo psicológico.

Não depende de força física.

Não depende de poderes sobrenaturais espetaculares.

Depende apenas de uma decisão impossível.

---

O IPL DA LENDA

Existem diversas versões para a origem da Mulher da Boca Rasgada.

A mais famosa remonta ao período Heian, entre os séculos VIII e XII.

Segundo a história, ela era uma mulher extremamente bonita.

Seu marido, consumido pelo ciúme, acreditava que ela o traía.

Tomado pela fúria, rasgou sua boca com uma espada.

Enquanto a mutilava, teria gritado:

"Quem vai achar você bonita agora?"

Após a morte, seu espírito teria retornado para buscar vingança.

Como acontece com muitos sistemas antigos, ninguém sabe exatamente qual é a versão original.

Existem dezenas de forks da mesma história.

Mas o núcleo do código permanece o mesmo.

Trauma.

Vaidade.

Violência.

Vingança.

---

O INCIDENTE DE PRODUÇÃO DE 1979

Foi em 1979 que a lenda sofreu seu maior upgrade.

E foi aí que ela deixou de ser apenas folclore.

Virou pânico nacional.

Durante aquele ano começaram a surgir relatos por todo o Japão.

Crianças afirmavam ter visto a Mulher da Boca Rasgada.

Professores relatavam boatos.

Pais organizavam grupos para escoltar alunos.

Algumas escolas passaram a recomendar que as crianças voltassem para casa em grupos.

A mídia amplificou o fenômeno.

Em pouco tempo o país inteiro estava falando dela.

Imagine uma falsa mensagem JES2 circulando em milhares de consoles simultaneamente.

Foi exatamente esse o efeito.

O mito se espalhou mais rápido que qualquer mecanismo tradicional de comunicação.

Muito antes da internet.

Muito antes das redes sociais.

Muito antes dos smartphones.

---

ENGENHARIA SOCIAL SOBRENATURAL

Do ponto de vista psicológico, Kuchisake-Onna é fascinante.

Ela explora vulnerabilidades profundamente humanas.

Primeiro:

O medo da deformidade.

Segundo:

O medo do desconhecido.

Terceiro:

A incapacidade de tomar decisões sob pressão.

Ela age exatamente como um atacante especializado em engenharia social.

A vítima acredita estar participando de uma conversa simples.

Na realidade já foi comprometida.

A pergunta é apenas o vetor de ataque.

O exploit acontece na resposta.

---

AS TÉCNICAS DE CONTORNO

Como todo problema em produção, logo surgiram soluções improvisadas.

Segundo algumas versões da lenda, é possível escapar respondendo:

"Você está normal."

Outras sugerem responder com outra pergunta.

Há versões que afirmam que oferecer doces pode distraí-la.

Outras dizem que ela fica confusa se você responder algo ambíguo.

Na linguagem mainframe:

São workarounds.

Nenhum oficialmente homologado.

Nenhum garantido.

Todos criados por usuários desesperados tentando evitar um crash inevitável.

---

A MÁSCARA QUE SE TORNOU UM ÍCONE

Existe um detalhe que torna a lenda ainda mais poderosa.

A máscara.

No Japão, máscaras cirúrgicas são comuns há décadas.

Por causa disso, qualquer pessoa mascarada pode ativar um gatilho psicológico associado ao mito.

Essa é a força das melhores lendas urbanas.

Elas não vivem em castelos assombrados.

Não vivem em florestas misteriosas.

Vivem no cotidiano.

Na esquina.

No ônibus.

Na rua vazia.

Na caminhada para casa.

É exatamente aí que o cérebro humano começa a preencher os espaços em branco.

---

O LEGADO NO CINEMA E NA CULTURA POP

Kuchisake-Onna tornou-se uma das figuras mais importantes do horror japonês.

Sua influência aparece em filmes, mangás, animes, videogames e séries de televisão.

Ela ajudou a consolidar um tipo específico de terror japonês:

O horror do encontro casual.

A ideia de que o sobrenatural não está escondido em algum lugar distante.

Ele está esperando na próxima esquina.

Essa abordagem influenciou inúmeras obras posteriores.

De certa forma, ela é uma ancestral espiritual de várias entidades assustadoras que surgiriam nas décadas seguintes.

---

O RCA FINAL

Se um sysprog fosse contratado para investigar Kuchisake-Onna, provavelmente encontraria a seguinte causa raiz:

O monstro nunca foi a boca cortada.

O monstro nunca foi a máscara.

O monstro nunca foi o fantasma.

O verdadeiro problema sempre esteve no ser humano.

Na obsessão pela aparência.

Na crueldade.

Na insegurança.

No julgamento.

No medo de não ser aceito.

Kuchisake-Onna sobrevive há gerações porque fala diretamente dessas falhas.

Ela é um dump psicológico da sociedade.

Um relatório de erros que nunca foi corrigido.

Um bug humano executado continuamente através dos séculos.

E talvez seja exatamente por isso que sua pergunta continua tão assustadora.

Porque, no fundo, todos nós sabemos que algumas perguntas não possuem resposta segura.

Principalmente quando são feitas por alguém que já perdeu tudo.

Inclusive a própria humanidade.

☕👄💣 STATUS FINAL DO JOB:

KUCHISAKE-ONNA CONTINUA EM EXECUÇÃO.

SEM PATCH.

SEM ROLLBACK.

SEM DATA PREVISTA PARA ENCERRAMENTO.

☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção

 

Bellacosa Mainframe e lei da recorrência

☕ Lei da Recorrência — ou: nada acontece só uma vez, você é que não prestou atenção

 

Vou confessar logo de cara: a Lei da Recorrência sempre me assombrou. Principalmente quando eu jurava que “isso nunca mais vai acontecer”… e pronto, lá estava ela de novo, batendo na porta, usando outra roupa, mas com o mesmo cheiro de déjà-vu.

📜 Origem da Lei da Recorrência

A ideia de recorrência aparece em vários lugares:

• Na filosofia (Nietzsche e o “eterno retorno”)

• Na matemática (funções recursivas)

• Na física (ciclos naturais)

• Na psicologia (padrões de comportamento)

• E, claro, no mainframe 😄

A essência é simples e cruel:

aquilo que não é compreendido, resolvido ou encerrado… retorna.

🧠 Recorrência em modo Bellacosa

No mundo real, a recorrência aparece assim:

• Você muda de emprego, mas o mesmo tipo de problema aparece

• Troca de sistema, mas os erros se repetem

• Muda de cidade, mas carrega os mesmos conflitos

• Refatora o código, mas mantém a mesma lógica ruim

O cenário muda. O padrão não.

🖥️ Recorrência no Mainframe (easter egg técnico)

Todo veterano já viu:

• Abend recorrente em fim de mês

• Job que falha sempre no feriado

• Programa que “só dá problema em produção”

• Correção rápida que vira permanente

E o clássico comentário:

* ESTE PROBLEMA JA ACONTECEU EM 2003

A recorrência ri disso.

📺 Curiosidades & Easter Eggs

• Em Groundhog Day (Feitiço do Tempo), o filme inteiro é sobre recorrência

• Em Re:Zero, o sofrimento do protagonista é um loop recorrente

• No Japão, ciclos são respeitados — as estações, os rituais, os hábitos

🗣️ Fofoquices filosóficas

A recorrência é educada: ela avisa antes de ensinar.
Ignorada, ela vira pedagógica.
Persistente, ela vira trauma.

E sim, ela adora pessoas que dizem:

“dessa vez vai ser diferente”
…sem mudar nada.

🛠️ A prática da antirrecorrência

Para quebrar ciclos, é preciso:

• Consciência (ver o padrão)

• Registro (documentar)

• Decisão (mudar algo real)

• Ação sustentada (não só promessa)

No mainframe: post-mortem decente.
Na vida: autocrítica honesta.

🧘 Como entender a Lei da Recorrência

Pergunte-se:

• Onde já vi isso antes?

• O que eu evitei aprender da última vez?

• O que continua igual em mim?

A recorrência não acusa. Ela repete.

🌏 Significado e importância

Ela nos ensina:

• Que padrões governam mais que eventos

• Que repetir erros é mais fácil que mudar hábitos

• Que evolução exige ruptura consciente

No Japão, isso conversa com karma, mujo e kaizen.
No mainframe, com melhoria contínua e disciplina operacional.

☕ Conclusão Bellacosa

A Lei da Recorrência não quer te punir.
Ela quer ver se você aprendeu.

Se algo está sempre voltando, não é azar.
É lição pendente.

E como todo bom sistema legado ensina:

enquanto você não resolver a causa,
o problema volta — com outro nome,
outro horário,
e muito mais caro.

Hora feliz... pensa que um viajante não come?

A Brigite comanda o Espectáculo

Bom visitar um pais é uma experiência única, conhecer o povo, a cultura, as relíquias religiosas, as jóias arquitectónicas, ruínas arqueológicas e tesouros do passado.

Porem se não provarmos da culinária local, não podemos dizer que imergimos no pais. Eu sou uma pessoa de mente aberta e estômago de avestruz, adoro provar sabores, conhecer a culinária local

Um ícone da culinária são os biscoitinho secos e chá de hortelã bem doce que provei de norte a sul do Egipto.

De comidas posso dizer que provei carne de camelo, comi frango, búfalo... provei espagueti, arroz árabe, pão egípcio, batatas fritas e assadas, azeitonas, grão de bico, lentilha e outros quitutes mais.

Agora a gloria foi provar caldo de cana, nossa em Portugal não existe, então só quando visitava o Brasil tirava a barriga da miséria. Mas desta vez, não sempre que via um engenho, eu pedia para parar o bus e corria para comprar uma garrafinha. Ajuda aos navegantes o caldo de cana no Egito se chama ;  Gasab

Visita ao bairro Copta no Cairo

Reduto cristão em meio a Cairo muçulmana.

Dentro da cidade do Cairo existe um bairro cristão onde se encontra a igreja Copta, hoje ligada a Igreja Católica Romana, mas em tempos idos, foi a sede da divulgação e guardiã de diversos documentos e relíquias.

São Marcos viveu em Alexandria, vários sábios e eruditos afluíam para esta região para compartilharem esse conhecimento, ainda hoje em escavações arqueológicas encontram fragmentos de escritos que constituem provas muito antigas dos livros Bíblicos.

Nesta região protegida dos extremistas existem museus, uma Sinagoga e diversas igrejas entre elas podemos citar a Igreja de São Jorge, que segundo a tradição foi ali martirizado e as correntes que o acorrentaram ainda estão ali, num outro ponto existe uma igreja construída sob uma antiga gruta que dizem ter abrigado São José, Maria e o Menino Jesus em sua fuga para o Egipto.

Também estão as ruínas romanas mais bem conservadas de todo o Cairo, resto da muralha e uma torre defensiva do quartel romano.

Necrópoles de Luxor: Conheça o Vale dos Reis

The Valley of the Kings 

O ponto alto da visita a Luxor, estamos visitando o Vale dos Reis a Necrópole mais famosa do mundo, onde estavam enterrado um grande numero de faraós egípcios, muitos deles grandiosos generais e conquistadores, hábeis políticos e grandes religiosos, porem todos foram suplantados pelo pequeno e insípido faraó Tutankhamon.

Mas graças aquelas pequenas ironias da vida. Tutankhamon cujo reinado foi um peidinho na historia do Egipto, se tornou o maior e mais famoso faraó do Mundo. Nao existe em nenhum registro um rei que ficou tão famoso e conhecido no mundo todo, tornando-se um ícone do mundo moderno.

Filmes, livros, gibis, fotos, lendas e maldiçoes o rei Tut se espalhou na cultura popular, que basicamente todo mundo, já ouviu ou ouvira falar nele.

Mas por que o faraó Tut ficou tão famoso? Graças ha um pequeno azar dos ladroes de túmulo. Enquanto todas as necrópoles do Vale dos Reis foram saqueadas, profanadas, roubadas, pilhadas e sacaneadas o nosso amigo Tut, foi esquecido e manteve seus tesouros originais guardados por quase 2500 anos, antes de ser profanado por arqueólogos modernos.

Traduzindo seu nome temos algo como "A imagem viva de Amon"  Tut (Imagem) Ankh (vida) Amon (deus egipcio), porem anteriormente seu nome era TutAnkhAton, porem como foi convertido a ponta da espada, trocou o deus. Outra curiosidade seu sarcófago e múmia são os únicos que ainda se encontram no Vale dos Reis.

Cavalgando uma mulinha no Vale dos Reis (Egito)

Donkey Rider

Tirando a parte da dozinha da Mulinha este passeio foi uma doideira, beirando o absurdo aquele mundareu de ocidentais, provenientes das maiores metrópoles e de países bem desenvolvidos. Se divertindo com algo tão simples e inocente como andar de mulinha.

Em Junho de 2010 numa grande viagem aventura no Egipto, tive a oportunidade de cavalgar uma mulinha com destino final o Vale do Reis no Egipto, foi super divertido a experiência... passar por vilarejos, ver egípcios em seus afazeres contidianos, ver fabricas, uma mesquita.

E se assistir com calma ate o final verá uns motoqueiros passando pelas mulas com caras divertidas, note como são rígidas as normas de segurança no Egipto.