Translate

Mostrar mensagens com a etiqueta buildmcs. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta buildmcs. Mostrar todas as mensagens

quarta-feira, 15 de abril de 2026

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

 

Bellacosa Mainframe Laboratorio SMP/E do caos a orquestração

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

🎯 Objetivo do Lab

Você vai executar:

  1. 📦 RECEIVE / APPLY (com erro)
  2. 📊 REPORT (diagnóstico)
  3. 🔗 LINK MODULE (correção)
  4. 🏗️ BUILDMCS (empacotamento)

👉 Resultado final:

Um ambiente corrigido, analisado e exportável


🧱 CENÁRIO DO LAB

👉 Situação:

  • Produto instalado parcialmente
  • Módulo faltando no LMOD
  • PTF aplicada sem dependência

💥 Resultado:

Erro de execução + inconsistência SMP/E


🔥 PASSO 1 — RECEIVE (entrada da manutenção)

//RECEIVE JOB (ACCT),'SMP/E LAB',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPTS DD DISP=SHR,DSN=SYS1.SMP.PTS
//SMPCNTL DD *
SET BOUNDARY(GLOBAL).

RECEIVE SYSMODS
FROMDS('USER.PTF.INPUT')
BYPASS(HOLDSYSTEM).
/*

💡 O que está acontecendo

  • Carrega SYSMOD no SMPPTS
  • Ignora HOLD SYSTEM (perigoso 👀)

⚠️ PASSO 2 — APPLY (com erro proposital)

//APPLY JOB (ACCT),'SMP/E APPLY',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

APPLY PTFS(UX12345)
GROUPEXTEND
BYPASS(HOLDCLASS).
/*

💥 Resultado esperado

Erro tipo:

GIM35901E - REQUIRED SYSMOD NOT FOUND

👉 Tradução:

Dependência faltando


🧠 PASSO 3 — REPORT (diagnóstico inteligente)

//REPORT JOB (ACCT),'SMP/E REPORT',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

REPORT CROSSZONE.

REPORT ERRSYSMODS.

REPORT SYSMODS.
/*

🔍 O que você vai ver

  • Dependências faltantes
  • PTFs necessárias
  • Conflitos

💡 E mais importante:
👉 SMPPUNCH com comandos prontos


🔗 PASSO 4 — LINK MODULE (cirurgia)

//LINKMOD JOB (ACCT),'SMP/E LINK',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

LINK MODULE(CSAMPLE)
FROMZONE(TZONE2).
/*

🧠 O que acontece

  • Busca módulo em outra zona
  • Rebuild do LMOD
  • Cria TIEDTO

💡 Resultado:

Executável corrigido sem reinstalar tudo


🏗️ PASSO 5 — BUILDMCS (empacotar o ambiente)

//BUILDMCS JOB (ACCT),'SMP/E BUILD',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

BUILDMCS FORFMID(CICS123).
/*

📦 Resultado

No SMPPUNCH:

  • ++FUNCTION
  • ++MOD
  • ++JCLIN

👉 Você criou um:

produto instalável do seu ambiente


🔁 PASSO 6 — APPLY CORRIGIDO

//APPLY2 JOB (ACCT),'SMP/E APPLY OK',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

APPLY PTFS(UX12345)
GROUPEXTEND
CHECK.
/*

💡 Agora

  • Sem erro
  • Dependências resolvidas
  • Ambiente consistente

🎯 LIÇÕES DO LAB (ESSENCIAL)

🧠 1. APPLY sem REPORT = risco

🧠 2. LINK MODULE = solução cirúrgica

🧠 3. BUILDMCS = portabilidade

🧠 4. REPORT = prevenção


💥 EASTER EGGS (NÍVEL BELLACOSA)

😈 Se você ignorar HOLDDATA
👉 vai quebrar produção

😈 Se usar LINK demais
👉 cria acoplamento invisível

😈 Se não usar BUILDMCS
👉 não consegue reconstruir ambiente


🚀 DESAFIO (NÍVEL HARDCORE)

Tente:

  1. Rodar APPLY sem GROUPEXTEND
  2. Ver erro
  3. Resolver com REPORT + FIXCAT

🧠 FRASE FINAL DO LAB

“Quem roda SMP/E executa comando…
quem domina SMP/E controla o sistema.”


sábado, 25 de fevereiro de 2023

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

 

Bellacosa Mainframe apresenta o software com poder de vida e morte no Mainframe SMP/E

🔥 SMP/E Não Instala Software — Ele Decide se o Seu Sistema Vive ou Morre

Se você é um dev COBOL sênior, deixa eu te provocar logo de cara:

Você confia no seu programa…
mas você confia no ambiente onde ele roda?

Porque no mundo do z/OS, não é o COBOL que quebra primeiro.

👉 É o ecossistema invisível que o SMP/E controla.


☕ A História que Ninguém Te Conta

Antes do SMP/E, instalar software no mainframe era quase artesanal:

  • Fita magnética 📼
  • JCL manual
  • Catálogo na mão
  • E muita… muita reza

Quando a IBM criou o SMP/E, a ideia não era só instalar software.

Era algo muito maior:

Criar um sistema de governança de software


🧠 O Que é SMP/E (de verdade)

Esquece a definição de manual.

👉 SMP/E é:

  • Inventário vivo do sistema
  • Motor de instalação
  • Mecanismo de auditoria
  • Sistema de dependência

💡 Tradução Bellacosa:

É o Git + Maven + Kubernetes do mainframe… só que criado décadas antes.


🧱 Como o Sistema é Construído (e você provavelmente nunca viu assim)

O SMP/E enxerga o mundo em camadas:

SOURCE → MACRO → MODULE → LOAD MODULE → LIBRARY

👉 E aí vem o pulo do gato:

  • Seu programa COBOL → vira MODULE
  • Vários MODULEs → viram LMOD
  • LMOD → roda no sistema

💥 Se UMA peça estiver errada…

Seu programa perfeito vira erro em produção


🔥 APPLY — O Comando Mais Perigoso do Seu Ambiente

Todo mundo já rodou:

APPLY PTFS(...)

E pensou:

“RC=0… sucesso!”

😈 Aqui está o problema:

  • Dependência pode estar faltando
  • HOLD pode estar ignorado
  • Outra zona pode quebrar

👉 E o erro?

Vai aparecer depois… no seu COBOL


🧠 Easter Egg (nível produção)

O APPLY não instala software…
ele muda o estado do sistema inteiro


🔍 LIST vs REPORT — O Momento em que você vira adulto no SMP/E

LIST

  • Mostra dados
  • Não pensa

👉 Tipo um dump bonito


REPORT

  • Analisa
  • Detecta problema
  • Sugere ação

💡 Tradução:

LIST responde
REPORT decide


💥 Exemplo real

Você roda:

REPORT CROSSZONE

E descobre:

  • Dependência faltando
  • Outro produto impactado

👉 Antes do APPLY

💥 Resultado:

Você evitou um incidente


🔗 LINK MODULE — A Cirurgia que Salva Madrugada

Cenário clássico:

  • Programa chama módulo
  • Módulo não está no LMOD

💣 Resultado:

  • Abend
  • Erro estranho
  • Chamado urgente

💡 Solução:

LINK MODULE(...)

👉 O SMP/E:

  • Busca módulos em outra zona
  • Reconstrói o executável

💥 Sem reinstalar nada


😈 Easter Egg

Isso resolve rápido…
mas cria dependência (TIEDTO)

👉 Você resolveu hoje… e criou um problema silencioso amanhã


🏗️ BUILDMCS — O Superpoder Escondido

Pouca gente usa. Pouca gente entende.

👉 Mas isso aqui é ouro:

BUILDMCS FORFMID(...)

O que ele faz?

  • Pega um ambiente instalado
  • Gera um SYSMOD completo
  • Permite reinstalar tudo

💡 Analogia moderna

BUILDMCS é o “docker commit” do mainframe


📖 Caso real

  • Sistema com USERMOD crítico
  • Sem documentação
  • Sem backup lógico

👉 Solução?

BUILDMCS

💥 Ambiente salvo


⚠️ O Lado Sombrio

Se você tiver:

  • Shared LMOD
  • Elementos comuns

👉 BUILDMCS pode gerar inconsistência


🌐 SMP/E Moderno — Ele Já Virou DevOps

Hoje você não precisa mais:

  • Fita
  • PSP manual
  • Caçar PTF

🚀 RECEIVE ORDER

RECEIVE ORDER

👉 SMP/E:

  • Pede manutenção
  • Baixa
  • Organiza

🧠 FIXCAT

O SMP/E escolhe o que você precisa instalar


🔄 Pipeline moderno

ORDER → RECEIVE → APPLY → ACCEPT

💡 Isso é CI/CD… no mainframe


🔥 Exemplo Real (nível enterprise)

Upgrade de ambiente:

  1. RECEIVE HOLDDATA
  2. REPORT MISSINGFIX
  3. APPLY FIXCAT
  4. VALIDAR

👉 Sem PSP manual
👉 Sem chute


😈 Easter Egg final

Quem ainda usa fita…
está em 1998


🧠 O Que Isso Muda para um Dev COBOL

Você deixa de ser:

❌ “quem escreve programa”

E vira:

✅ quem entende o ambiente
✅ quem evita erro antes de acontecer
✅ quem conversa com sysprog de igual para igual


💥 Passo a Passo Mental (guarda isso)

Antes de qualquer APPLY:

  1. 🔍 REPORT
  2. 📊 Analisar dependência
  3. ⚙️ APPLY CHECK
  4. 🚀 APPLY real
  5. 📦 ACCEPT

🚀 Frase Final (nível Bellacosa)

“Seu COBOL pode estar perfeito…
mas quem decide se ele roda é o SMP/E.”

domingo, 15 de agosto de 2010

SMP/E for z/OS Workshop : BUILDMCS, LINK MODULE e LINK LMODS

 

Bellacosa Mainframe apresenta SMP/E buildmcs link lmods e module

SMP/E for z/OS Workshop

BUILDMCS, LINK MODULE e LINK LMODS

Quando o SMP/E deixa de ser manutenção e vira engenharia de produto

Até agora, no mundo SMP/E, falamos muito de rotina operacional:
RECEIVE, APPLY, ACCEPT, RESTORE.
O famoso arroz com feijão do dia a dia.

Mas existe um outro SMP/E.
Menos usado.
Mais poderoso.
Mais perigoso se mal compreendido.

Hoje entramos no território de product build, onde aparecem três comandos que não são para iniciantes:

  • BUILDMCS

  • LINK MODULE

  • LINK LMODS

Aqui o SMP/E deixa de ser só manutenção e passa a ser engenharia reversa, migração e reconstrução de produtos.


SMP/E e a visão estrutural do z/OS

O SMP/E enxerga o z/OS como uma hierarquia:

  • 🔹 Elementos simples (SRC, MAC, MOD, PARM)

  • 🔹 Objetos intermediários (OBJ, módulos)

  • 🔹 Estruturas complexas (LMODs)

  • 🔹 Bibliotecas do sistema (target libraries)

Tanto o APPLY quanto os processos de geração de produto fazem a mesma coisa no fundo:

Pegam módulos, macros, source e dados
e combinam tudo para gerar load modules e bibliotecas executáveis

O segredo está em como o SMP/E entende essa estrutura:
👉 entries e subentries no CSI


Revisão rápida das principais subentries (a base de tudo)

🔹 DISTLIB=

Aponta para a distribution library
(cópia oficial, aceita, segura)

🔹 FMID=

Define o nível funcional

Quem é o dono original do elemento

🔹 RMID / UMID=

Definem o nível de serviço

Última substituição e atualizações

🔹 SYSLIB=

Usado por SRC, MAC, DATA, HFS
Define o DDNAME da target library

🔹 LMOD=

Usado em MODULE entries
Direciona o SMP/E para a estrutura do load module

Sem entender isso, BUILDMCS vira magia negra.


Distribution Zone: conteúdo sem estrutura

Um ponto crítico que muita gente erra:

Na DZONE não existe estrutura de LMOD

Na distribution zone:

  • Existem MOD entries

  • Não existem LMOD= subentries

  • O foco é conteúdo, não link-edit

A estrutura só nasce no target, durante APPLY, GENERATE ou LINK.


BUILDMCS – o “clonar produto” do SMP/E

O que é o BUILDMCS?

O BUILDMCS analisa um target zone ou distribution zone
e gera um SYSMOD funcional completo, contendo:

  • ++FUNCTION

  • ++MOD, ++MAC, ++SRC, ++PARM, ++HFS

  • ++JCLIN completo

  • FROMDS apontando para as DLIBs

📦 Resultado:

Um SYSMOD portátil, capaz de reinstalar um produto inteiro em outro ambiente SMP/E


Para que isso existe no mundo real?

Cenários clássicos:

  • Migração de produto entre ambientes

  • Criação de novo CSI

  • Consolidação de sistemas

  • Produto sem mais mídia oficial

  • Ambientes isolados (sem internet, sem Shopz)

BUILDMCS cria uma imagem funcional completa do produto, incluindo:

  • Função

  • Serviço

  • Usermods já aplicados


O que o BUILDMCS NÃO faz

🚫 Não altera o ambiente original
🚫 Não aplica nem aceita nada
🚫 Não “adivinha” dependências externas

Ele fotografa o estado atual do produto.


Como o BUILDMCS funciona por dentro

1️⃣ Analisa o zone (T ou D)
2️⃣ Reconstrói MCS a partir do CSI
3️⃣ Usa FROMDS para apontar para DLIBs
4️⃣ Gera SYSMOD superseding
5️⃣ Grava tudo no SMPPUNCH

Depois disso:

RECEIVE APPLY ACCEPT

em outro ambiente.


Relatórios gerados pelo BUILDMCS

BUILDMCS não é silencioso. Ele gera:

📄 Function Summary Report

  • FMIDs processados

  • SYSMODs substituídos

📄 Entry Summary Report

  • Todos os elementos do FMID

  • MODs, LMODs, DDDEFs

📄 Subentry Summary Report

  • Detalhe fino de cada entry

Se você não leu esses relatórios, você não sabe o que copiou.


⚠️ Restrições do BUILDMCS (a parte que cai em produção)

BUILDMCS não é para todo produto.

Problemas aparecem quando existem:

❌ Load modules compartilhados

Um LMOD com módulos de mais de um produto

❌ Elementos comuns

Mesmo nome e tipo fornecido por produtos diferentes

❌ VERSION, ASSEM, PREFIX

Essas operações não são recriadas

❌ Informações ausentes no Target Zone

  • LEPARM

  • ALIAS

  • DALIAS

Resultado?
👉 SYSMOD gerado incompleto ou incorreto


LINK MODULE – resolvendo dependência entre target zones

Agora imagine isso:

  • Produto A em TZONE1

  • Produto B em TZONE2

  • Um LMOD precisa de módulos dos dois

Sem reinstalar nada.

👉 LINK MODULE resolve isso


O que o LINK MODULE faz?

  • Reexecuta o link-edit

  • Inclui módulos faltantes

  • Atualiza ambos os target zones

  • Cria relacionamento cruzado (TIEDTO)

Tudo isso sem APPLY, sem ACCEPT.


Como o SMP/E documenta isso?

Após o LINK MODULE:

  • XZMODP no LMOD que foi relinkado

  • XZLMODP nos módulos envolvidos

  • TIEDTO nos dois target zones

Isso garante que o SMP/E:

  • Saiba da dependência

  • Avise (ou relinke automaticamente) no futuro


XZLINK – avisar ou agir?

No TIEDTO ZONE:

  • XZLINK(DEFERRED)
    👉 Apenas avisa possível inconsistência

  • XZLINK(AUTOMATIC)
    👉 SMP/E relinka automaticamente

Escolha errada aqui = surpresa em manutenção futura.


LINK LMODS – o REPORT CALLIBS que deu certo

O LINK LMODS substitui o antigo REPORT CALLIBS.

Ele:

  • Identifica LMODs por nome ou CALLIBS

  • Localiza todos os módulos

  • Executa link-edit direto nas target libraries

  • Tem CHECK mode

  • Tenta recuperação automática (compress + retry)

É APPLY sem SYSMOD.


Resumo Bellacosa Mainframe

ComandoPapel
BUILDMCSClona um produto
LINK MODULEResolve dependência entre zones
LINK LMODSRelinka LMODs diretamente

Frase final (estilo Bellacosa)

RECEIVE instala mídia.
APPLY constrói código.
ACCEPT oficializa.
RESTORE ensina humildade.
BUILDMCS revela quem realmente entende SMP/E.

No próximo módulo, entramos em LIST e REPORT — onde o SMP/E finalmente começa a contar a verdade sobre o seu sistema.

sábado, 29 de maio de 2010

SMP/E for z/OS Workshop – RECEIVE e REJECT

 

Bellacosa Mainframe analisando o smp/e for zos workshop

SMP/E for z/OS Workshop – RECEIVE e REJECT

Quando o SMP/E recebe, avalia… e decide se aceita ou devolve 📦⚖️

No mundo SMP/E, RECEIVE é a porta de entrada e REJECT é a porta de saída. Antes de qualquer APPLY ou ACCEPT, o SMP/E precisa estagiar, validar e registrar tudo que chega. É aqui que muita gente acha que RECEIVE é só “copiar fita”, mas na prática ele é um processo de seleção, validação e controle rigoroso.

Neste post, vamos destrinchar RECEIVE e REJECT, com visão de produção, exemplos reais e aquele toque Bellacosa Mainframe que separa quem decora de quem entende.


🧭 Onde RECEIVE e REJECT se encaixam no SMP/E

Os cinco comandos básicos do SMP/E:

  1. RECEIVE – Estagia SYSMODs e HOLDDATA

  2. APPLY – Instala nos target libraries

  3. ACCEPT – Consolida nos distribution libraries

  4. RESTORE – Volta DLIB → target

  5. REJECT – Desfaz RECEIVE

👉 RECEIVE e REJECT atuam exclusivamente no Global Zone (GZONE).


📥 RECEIVE – muito além de copiar SYSMOD

O que o RECEIVE faz de verdade?

  • Seleciona SYSMODs e HOLDDATA

  • Valida aplicabilidade ao ambiente

  • Estagia dados nos datasets SMP/E

  • Atualiza o Global Zone

  • Produz relatórios e logs

📌 Nada é instalado ainda. Apenas preparado.


📦 Entradas do RECEIVE

  • SYSMODs (Function, PTF, APAR, USERMOD)

  • HOLDDATA (++HOLD / ++RELEASE)

Fontes possíveis:

  • 📼 Tape (CBPDO / ESO)

  • 💾 DASD

  • 🌐 Network (FTP / SMPNTS / Shopz)


⚙️ SET BDY(GLOBAL): regra número zero

Todo RECEIVE começa com:

SET BDY(GLOBAL)

Sem isso, o SMP/E nem conversa com você.


🎯 Seleção de SYSMODs – quem entra na fila?

A seleção é controlada por operandos do RECEIVE:

Exemplos comuns

  • Sem operandos → tudo é candidato

  • FMID / FMIDSET → restringe por função

  • SELECT / EXCLUDE → filtra SYSMODs

  • SOURCEID → agrupa SYSMODs

💡 Bellacosa Tip: SOURCEID é ouro para automação de APPLY/ACCEPT.


✅ Regras de aplicabilidade

Para um SYSMOD ser realmente recebido:

Function SYSMOD

  • ++VER SREL deve existir no GZONE

PTF / APAR / USERMOD

  • ++VER SREL e FMID devem existir no GZONE

🛑 Exceção: BYPASS(FMID) ignora o FMID check.

Outras regras:

  • SYSMOD não pode já ter sido recebido

  • HOLDDATA só processa se solicitado


🗂️ O que é estagiado pelo RECEIVE

SMPPTS

  • Armazena MCS + textos de modificação

  • Um membro por SYSMOD (nome = SYSMODID)

Global Zone

  • Entrada de SYSMOD

  • Entrada de HOLDDATA

  • Atualização da lista de FMIDs

📌 Nenhum elemento é instalado ainda.


📁 RELFILE SYSMODs e SMPTLIB

Quando o SYSMOD vem em RELFILE:

  • Cada RELFILE → um SMPTLIB

  • RFDSNPFX define HLQ dos datasets

  • TLIBs podem ser:

    • Pré-alocados

    • Dinamicamente alocados

💡 Dica Bellacosa: defina spill para SMPPTS e TLIBs, ou prepare-se para o caos.


🌐 RECEIVE via Network

FROMNETWORK

  • Usa pacote GIMZIP

  • Conecta via TCP/IP (FTP)

  • Requer SERVER operand

FROMNTS

  • Usa diretório SMPNTS

  • Identificado por PKGID ou Order Entry

📦 Base da instalação moderna via Shopz.


🧾 Relatórios gerados pelo RECEIVE

  • Receive Summary Report

  • Exception SYSMOD Data Report (++HOLD / ++RELEASE)

  • Dynamic Allocation Report

📌 Leitura obrigatória antes do APPLY.


🛑 HOLDDATA – quando o SMP/E levanta a mão

HOLDDATA sinaliza SYSMODs que:

  • Exigem ação manual

  • Dependem de outro fix

  • Podem causar impacto operacional

Tipos de HOLD

  • SYSTEM

  • ERROR

  • USER

  • FIXCAT

🛑 SYSMOD com HOLD não aplica nem aceita.


🏷️ FIXCAT – inteligência aplicada

FIXCAT agrupa APARs por:

  • Hardware

  • Software

  • Função

Durante RECEIVE:

  • FIXCAT HOLDS criam SOURCEIDs automaticamente

  • PTFs resolutores herdam o SOURCEID

Resultado:

APPLY SOURCEID(FIXCAT_xxx)

🎯 Simples, limpo e auditável.


📌 FIXCAT persistente (Options Entry)

  • Lista salva no OPTIONS entry

  • Usada por APPLY / ACCEPT / REPORT MISSINGFIX

  • Configurada via:

    • UCLIN

    • Admin Dialog

    • Fix Category Explorer

💡 Bellacosa Truth: FIXCAT bem mantido evita outage silencioso.


🚪 REJECT – desfazendo o RECEIVE

REJECT reverte RECEIVE, não APPLY.

O que ele remove:

  • SYSMOD entry no GZONE

  • HOLDDATA entry

  • MCS no SMPPTS

  • SMPTLIBs associados


🎛️ Modos de REJECT

  • MASS – tudo recebido e não instalado

  • SELECT – SYSMOD específico

  • PURGE – aceitos em uma DZONE

  • NOTAPPLICABLE – não aplicáveis ao sistema

🔍 CHECK faz simulação (sempre use!).


🧠 Conclusão Bellacosa

RECEIVE é controle. APPLY é ação. ACCEPT é compromisso.

Quem domina RECEIVE:

  • Evita lixo no SMPPTS

  • Controla HOLDDATA

  • Organiza SOURCEIDs

  • Dorme melhor antes do APPLY

No próximo capítulo do workshop, entramos de vez no APPLY processing, onde o código finalmente toca o sistema.

🚀 Até lá, respeite o RECEIVE. Ele sabe mais do que parece.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...