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

domingo, 8 de janeiro de 2012

🖥️🧙‍♂️ Comandos de gerenciamento do IBM CICS

 



🖥️🧙‍♂️ Comandos de gerenciamento do IBM CICS

Bellacosa Mainframe Style — Guia definitivo para Padawan CICS

Os comandos de gerenciamento do IBM CICS são o coração operacional do ambiente transacional em mainframe. Diferentemente dos comandos EXEC CICS, usados dentro de programas COBOL, PL/I ou assembler, os comandos de gerenciamento são transações interativas, executadas diretamente no terminal 3270, com foco em administração, diagnóstico e controle em tempo real do sistema.

Esses comandos surgiram para dar autonomia ao operador e ao analista, permitindo gerenciar recursos sem reiniciar o CICS ou recorrer a JCL. O principal deles é o CEMT (CICS Execute Master Terminal), usado para consultar e alterar o estado de tarefas, programas, arquivos, transações e conexões. Já o CEDA (CICS Execute Definition) permite definir e instalar recursos no CSD (CICS System Definition), funcionando como um catálogo central de configurações. O CECI é voltado a testes, permitindo executar comandos EXEC CICS de forma interativa, enquanto o CEDF atua como ferramenta básica de depuração, interceptando chamadas EXEC CICS durante a execução de programas.

Outros comandos importantes incluem o CESN (login e segurança), CEOT (reset de sessão), CEBR (navegação em arquivos VSAM) e CEVT (controle de eventos temporizados). Em conjunto, esses comandos transformam o CICS em um ambiente altamente controlável, onde estabilidade, disciplina e observabilidade são valores centrais — características que explicam sua longevidade em sistemas críticos até hoje.


Antes de existir DevOps, Kubernetes ou observabilidade, o CICS já tinha seu próprio painel de controle Jedi:
as transações de gerenciamento, executadas direto no terminal 3270.

Elas não são EXEC CICS, são comandos operacionais — a diferença entre programar e governar o império.


🧠 O que são comandos de gerenciamento do CICS?

São transações especiais, quase sempre iniciadas com CE ou CM, usadas para:

  • administrar recursos

  • diagnosticar problemas

  • testar comandos

  • depurar programas

  • controlar o runtime

📌 Insight Bellacosa:

EXEC CICS é para o código.
CEMT é para quem manda.


Comando CEMT


🔹 1️⃣ CEMT — CICS Execute Master Terminal

O CEMT (CICS Execute Master Terminal) é o principal comando de gerenciamento do IBM CICS, usado para monitorar e controlar recursos em tempo real a partir do terminal 3270. Com ele, o operador ou analista pode consultar (INQUIRE) e alterar (SET) o estado de tarefas, programas, arquivos, transações, terminais e conexões, sem reiniciar o sistema. Criado para dar autonomia operacional, o CEMT permite ações críticas como NEWCOPY de programas, cancelamento de tasks presas e verificação de uso de recursos. É uma ferramenta poderosa, rápida e perigosa: um comando mal aplicado pode impactar produção instantaneamente. Dominar o CEMT é passo essencial para qualquer profissional CICS.

📟 O console supremo

📜 História

Criado para substituir comandos internos e dar controle online do CICS.

🔧 Para que serve

  • Ver e alterar status de:

    • Tasks

    • Programs

    • Files

    • Transactions

    • Terminals

    • Connections

🧪 Exemplo (Padawan)

CEMT I TASK
CEMT I PROG(DMCPGM01)
CEMT SET PROG(DMCPGM01) NEWCOPY

💡 Dicas

  • I = INQUIRE

  • SET muda o estado em produção 😈

🥚 Easter egg:
CEMT I TASK já derrubou mais produção que bug em COBOL mal testado.


Comando CEDA


🔹 2️⃣ CEDA — CICS Execute Definition

O CEDA (CICS Execute Definition) é o comando de gerenciamento do CICS responsável por definir e administrar recursos no CSD (CICS System Definition). Por meio dele, o analista cria, altera, remove e instala definições como PROGRAM, TRANSACTION, FILE, MAPSET e DB2ENTRY, sem necessidade de JCL. O CEDA separa conceito de execução: definir não é instalar, sendo necessário o comando INSTALL para ativar o recurso no ambiente. Criado para dar flexibilidade e padronização ao CICS, o CEDA é essencial para mudanças controladas. Seu uso correto garante consistência, rastreabilidade e estabilidade em ambientes transacionais críticos.

📚 O catálogo de schemas do CICS

📜 História

Criado para definir recursos sem JCL.

🔧 Para que serve

  • Definir recursos no CSD:

    • PROGRAM

    • TRANSACTION

    • FILE

    • MAPSET

    • DB2ENTRY

🧪 Exemplo

CEDA DEF PROGRAM(DMCPGM01)
CEDA INS TRAN(DMC1)
CEDA INSTALL

💡 Dicas

  • Definir ≠ Instalar

  • Só vira realidade após INSTALL

🥚 Easter egg:
Já existia Infrastructure as Data antes do YAML virar moda.



Comando CECI

🔹 3️⃣ CECI — CICS Execute Command Interpreter

O CECI (CICS Execute Command Interpreter) é o comando de gerenciamento do CICS usado para testar comandos EXEC CICS de forma interativa, sem escrever ou compilar programas. Ele permite simular operações como READ, WRITE, LINK, SEND e RECEIVE, facilitando aprendizado, validação e diagnóstico rápido de problemas. Criado como laboratório do CICS, o CECI é muito utilizado por iniciantes e analistas experientes para entender o comportamento dos recursos em tempo real. Apesar de ser uma ferramenta didática, o CECI pode alterar dados reais, exigindo cuidado em ambientes produtivos. É um recurso valioso para estudo e testes controlados.

🧪 Laboratório nuclear

📜 História

Criado para testar EXEC CICS sem escrever programa.

🔧 Para que serve

  • Simular comandos EXEC CICS

  • Testar arquivos, filas, links

🧪 Exemplo

EXEC CICS READ FILE(ARQCLI)

💡 Dicas

  • Ideal para aprender CICS

  • Pode alterar dados reais ⚠️

🥚 Easter egg:
CECI é o Postman do CICS — só que mais perigoso.


Comando CEDF

🔹 4️⃣ CEDF — CICS Execution Diagnostic Facility

O CEDF (CICS Execution Diagnostic Facility) é o comando de gerenciamento do CICS utilizado para depuração básica de programas em tempo de execução. Ao ser ativado, ele intercepta cada comando EXEC CICS, permitindo ao analista acompanhar passo a passo a execução da task, visualizar parâmetros e identificar erros lógicos. Criado antes das ferramentas modernas de debug, o CEDF foi por muito tempo o principal recurso de diagnóstico no CICS. Seu uso deve ser restrito a ambientes controlados, pois pode impactar desempenho e travar sessões se esquecido ativo. Ainda hoje, é valioso para aprendizado e análise detalhada.

🐞 O debugger raiz

📜 História

Antes de Xpediter, Debug Tool… só existia o CEDF.

🔧 Para que serve

  • Debug passo a passo

  • Interceptar EXEC CICS

🧪 Exemplo

CEDF ON

💡 Dicas

  • Use só em ambiente controlado

  • Pode afetar performance

🥚 Easter egg:
Todo mainframer já travou uma task esquecendo o CEDF ON.


Comando CESN


🔹 5️⃣ CESN — CICS Sign-On

O CESN (CICS Execute Sign-On) é o comando de gerenciamento do CICS responsável pelo processo de autenticação do usuário no ambiente transacional. Ele permite que o operador ou analista se identifique no CICS, integrando-se aos sistemas de segurança como RACF, ACF2 ou Top Secret. O CESN associa o usuário ao terminal, definindo permissões e controles de acesso às transações e recursos. Criado para garantir rastreabilidade e segurança, é o primeiro comando executado em muitos ambientes. Sem um sign-on válido, o usuário permanece com acesso restrito, impossibilitado de operar ou administrar o sistema.

🔐 Porta de entrada

📜 História

Integração direta com RACF/ACF2/TopSecret.

🔧 Para que serve

  • Login no CICS

🧪 Exemplo

CESN

💡 Dicas

  • Usuário ≠ terminal

  • Segurança manda

🥚 Easter egg:
Sem CESN, você é só mais um terminal mudo.


Comando CEOT


🔹 6️⃣ CEOT — CICS End Of Task

O CEOT (CICS End Of Task) é o comando de gerenciamento do CICS utilizado para encerrar e limpar o estado de uma sessão no terminal 3270. Ele finaliza a task corrente, libera recursos associados e redefine o terminal para um estado inicial seguro. O CEOT é muito usado quando uma transação fica presa, apresenta comportamento inesperado ou após testes e depuração. Criado como mecanismo simples de recuperação, funciona como um “reset” controlado do terminal, sem afetar outras tasks do sistema. É uma ferramenta básica, porém essencial, para manter estabilidade e disciplina operacional no ambiente CICS.

🧹 Limpeza de sessão

📜 História

Criado para encerrar tasks zumbis.

🔧 Para que serve

  • Resetar estado do terminal

  • Encerrar tarefas presas

🧪 Exemplo

CEOT

🥚 Easter egg:
O “Ctrl+Alt+Del” do CICS.


Comando CEST


🔹 7️⃣ CEST — CICS Start

O CEST (CICS Execute Start) é um comando de gerenciamento menos conhecido do CICS, utilizado para iniciar tarefas ou transações de forma controlada, principalmente em cenários de teste e diagnóstico. Ele permite disparar uma execução sem depender do fluxo normal de entrada do usuário, ajudando analistas a validar comportamentos específicos do sistema. Historicamente, o CEST surgiu como apoio a ambientes de desenvolvimento e verificação operacional, não sendo amplamente usado em produção moderna. Embora simples, seu uso exige cautela, pois iniciar tasks manualmente pode consumir recursos ou gerar efeitos colaterais inesperados. É um recurso auxiliar, mas útil para estudos e testes dirigidos.

🚀 Bootstrap manual

🔧 Para que serve

  • Iniciar transações manualmente

  • Testes controlados

🥚 Pouco usado, mas histórico.


Comando CEBR

🔹 8️⃣ CEBR — CICS Browse

O CEBR (CICS Execute Browse) é o comando de gerenciamento do CICS utilizado para consultar e navegar interativamente por arquivos VSAM diretamente no terminal 3270. Ele permite localizar registros por chave, avançar ou retroceder sequencialmente e visualizar o conteúdo dos dados, sendo muito útil para análise e diagnóstico. O CEBR é amplamente usado em ambientes de desenvolvimento e suporte para verificar dados sem escrever programas. Apesar de ser uma ferramenta de leitura, seu uso requer cuidado com permissões e contexto do arquivo. É um recurso clássico do CICS, simples, eficiente e valioso para entendimento dos dados em tempo real.

📂 Explorador de arquivos

🔧 Para que serve

  • Browse online de VSAM

  • Debug de dados

🥚 Easter egg:
O File Explorer mais antigo ainda em produção.


Comando CEVT


🔹 9️⃣ CEVT — Event Control

O CEVT (CICS Event Control) é um comando de gerenciamento do CICS usado para controlar e testar eventos temporizados dentro do ambiente transacional. Ele permite simular condições baseadas em tempo, como atrasos, timeouts e disparo de eventos, auxiliando no diagnóstico de comportamentos assíncronos. Historicamente, o CEVT foi criado para apoiar testes de aplicações que dependem de temporização e controle interno do CICS. Embora pouco utilizado em ambientes modernos, permanece disponível para cenários específicos de estudo e validação. Seu uso exige cautela, pois eventos mal configurados podem afetar o fluxo normal das tarefas e a previsibilidade do sistema.

⏱️ Timer interno

🔧 Para que serve

  • Testar eventos temporizados

Pouco usado hoje, mas ainda vivo.


CICS Command Line Functions

🧠 Resumo Bellacosa Mainframe

ComandoFunção
CEMTGoverno
CEDADefinição
CECITeste
CEDFDebug
CESNSegurança
CEOTReset
CEBRDados
CESTStart
CEVTEventos

🧙‍♂️ Conselho final ao Padawan

Aprender CICS não começa em COBOL.
Começa em CEMT.

🖥️ MAINFRAME MODE ON:
Quem domina os comandos de gerenciamento não pede acesso — controla o ambiente.

Para saber mais sobre CICS

https://eljefemidnightlunch.blogspot.com/2012/10/cics-command-level-para-padawans.html



segunda-feira, 4 de outubro de 2010

SMP/E for z/OS Workshop : LIST & REPORT Commands

 

Bellacosa Mainframe apresenta SMP/E List and Report Commands

SMP/E for z/OS Workshop

ACCEPT Processing – LIST & REPORT Commands

Quando olhar o CSI é tão importante quanto instalar o código

Instalar SYSMOD qualquer um instala.
Agora… saber exatamente o que está instalado, onde, por quê e com qual dependência
👉 isso separa operador de System Programmer.

É aqui que entram os comandos LIST e REPORT.


LIST Command

Abrindo o CSI como quem abre o capô do sistema

O comando LIST é o bisturi do SMP/E.
Ele não interpreta, não deduz, não opina.
Ele mostra os fatos gravados no CSI.

📌 O LIST pode extrair informações de:

  • Global Zone

  • Target Zone

  • Distribution Zone

  • SMPPTS

  • SMPLOG

  • SMPSCDS

💡 Easter egg #1

Se você confia mais na memória do que no LIST,
o CSI vai te humilhar em algum momento.


Boundary: o detalhe que separa sucesso de confusão

Antes de usar LIST, você define o boundary:

  • Global Zone → acesso a SMPPTS

  • Zona com DDDEF do SMPLOG

  • Target Zone associada ao SMPSCDS

  • Ou tudo de uma vez com:

ALLZONES

⚠️ ALLZONES lista tudo que existe, não tudo que você quer ver.

💡 Easter egg #2

ALLZONES às 3 da manhã
é como dar SELECT * em produção.


O que dá pra listar no Global Zone

Com LIST você pode ver:

  • OPTIONS

  • UTILITIES

  • DDDEFs

  • FMIDSETs

  • ZONESETs

  • SYSMOD entries

  • MCS entries do SMPPTS

  • HOLDDATA (++HOLD)

HOLDDATA com lupa

Você pode filtrar por:

  • HOLDERROR

  • HOLDSYSTEM

  • HOLDUSER

E ainda combinar com SYSMOD específico.

📌 Se combinar filtros demais, o SMP/E só lista
entradas que satisfaçam todos.


Filtros avançados (onde mora o poder)

LIST aceita os mesmos refinamentos do APPLY/ACCEPT:

  • SOURCEID

  • EXSRCID

  • FORFMID

  • XZLMOD

  • XZLMODP

  • XREF

👉 Ideal para:

  • Debug de dependência

  • Auditoria

  • Pós-migração

  • Comparação entre ambientes

💡 Easter egg #3

SOURCEID bem usado
vale mais que planilha paralela.


LIST em Target e Distribution Zones

Além do básico, você pode listar:

  • TARGETZONE definition

  • DLIBZONE definition

  • DDDEFs

  • ELEMENT entries:

    • MOD

    • MAC

    • SRC

    • JAR

    • HFS

  • LMOD entries

SYSMOD entries com status

Você pode filtrar por:

  • ERROR

  • SUP (superseded)

  • NOSUP

  • RESTORE

  • NOAPPLY

  • NOACCEPT

  • BYPASS

  • DELETE

📌 SUP e NOSUP são mutuamente exclusivos.

💡 Easter egg #4

SYSMOD em ERROR não é bug
é aviso ignorado.


LIST LOG e BACKUP

  • LIST LOG → conteúdo do SMPLOG

    • Total ou por intervalo de data

  • LIST BACKUP → conteúdo do SMPSCDS

    • Tudo ou por SYSMOD específico

👉 LIST é o comando ideal para auditoria forense do SMP/E.


LIST vs DIALOG QUERY

LIST = dados brutos
QUERY = visão amigável

Quando a coisa aperta…
LIST sempre vence.


REPORT Command

Quando você precisa que o SMP/E pense por você

Se o LIST mostra,
o REPORT analisa.

Ele cruza zonas, dependências, FMIDs, SOURCEIDs e HOLDs
e ainda gera comandos prontos.

📌 REPORT é o SMP/E dizendo:

“relaxa, eu faço a correlação.”


REPORT CROSSZONE

Dependência entre produtos e zonas

Usado para responder:

“Instalei isso aqui… quebrou quem?”

Requisitos:

  • ZONESET obrigatório

  • Pode limitar por:

    • FMID

    • ZONE

O relatório mostra:

  • Dependências cruzadas

  • SYSMODs faltantes

  • Se já foram RECEIVED

  • Quem causou a dependência

👉 E ainda gera comandos SMP/E no SMPPUNCH

NOPUNCH

se você não quiser os comandos.

💡 Easter egg #5

SMPPUNCH esquecido
vira APPLY acidental.


REPORT ERRSYSMODS

Quando o passado volta pra cobrar

Identifica SYSMODs que:

  • Já foram instalados

  • Mas agora estão em ERROR HOLD

Pode analisar:

  • Global Zone

  • Target Zone

  • Distribution Zone

Filtros:

  • Data inicial / final

  • FMID

O relatório mostra:

  • SYSMOD afetado

  • Reason ID

  • Quem resolve

  • ++HOLD completo

💡 Easter egg #6

ERROR HOLD não some
só muda de lugar.


REPORT SOURCEID

Quem veio de onde?

Descobre:

  • Quais SOURCEIDs existem

  • Quais SYSMODs usam cada um

Com ou sem filtro por SYSMOD.

👉 Excelente para:

  • FIXCAT

  • Hardware novo

  • Coexistência

  • Migração de release


REPORT SYSMODS

Comparação entre zonas

Usado para:

  • Validar ambientes

  • Comparar releases

  • Checar desvio de serviço

Parâmetros:

  • INZONE

  • COMPAREDTO

Resultado:

  • O que existe em uma zona

  • E não existe na outra

  • Com comandos prontos para corrigir

💡 Easter egg #7

Ambiente “igual” sem REPORT
é fé, não evidência.


REPORT MISSINGFIX (FIXCAT)

Adeus PSP Bucket manual

Disponível a partir do SMP/E 3.6.

Identifica:

  • APARs faltantes

  • Por categoria FIXCAT

  • Para hardware, software e coexistência

Mostra:

  • FIXCAT

  • APAR

  • PTF corretivo

  • Dependências

  • Problemas de HOLD

📌 Dois blocos:
1️⃣ Missing fixes
2️⃣ Resolving SYSMODs em erro

💡 Easter egg #8

FIXCAT bem usado
economiza fim de semana inteiro.


Bellacosa Summary – em poucas linhas

LIST mostra o que existe
REPORT explica o impacto
SMPPUNCH sugere a correção
Você decide se confia


Checklist Bellacosa – LIST & REPORT

✔ LIST antes de APPLY
✔ REPORT antes de migrar
✔ FIXCAT sempre atualizado
✔ SOURCEID bem definido
✔ SMPPUNCH revisado
✔ LOG nunca ignorado


Conclusão

Quem domina LIST e REPORT:

  • Não instala no escuro

  • Não depende de planilha

  • Não descobre erro em produção

  • Não briga com auditor

💡 Easter egg final

O SMP/E sempre soube a verdade.
Você só precisava perguntar direito.