 |
| Bellacosa Mainframe e os 10 comandos windows |
☕ Um Café no Bellacosa Mainframe
🐈⬛ GATO FÉLIX E AS 10 PORTAS SECRETAS DO WINDOWS
CMD, PowerShell, MSConfig, Services, Registry, System Properties, Network Connections, MSInfo32, Disk Cleanup, TEMP — e o dia em que um programador COBOL descobriu que o Windows também tinha seus próprios corredores de serviço.
Sob a tutela do Gato Félix, aquele sujeito que atravessava mundos impossíveis carregando uma bolsa de truques que sempre parecia conter exatamente a ferramenta necessária.
🎬 PRÓLOGO — O PROGRAMADOR COBOL ENCONTROU UMA JANELA
Eram 03:17.
Sim, 03:17.
Porque todo incidente verdadeiramente educativo parece escolher um horário em que não existe café suficiente no planeta.
Nosso jovem programador COBOL estava diante do computador.
Na tela, um programa havia parado de funcionar.
Ele fez aquilo que gerações de profissionais de informática aprenderam como primeiro procedimento técnico universal:
reiniciou o computador.
Nada.
Reiniciou novamente.
Nada.
Então apareceu sobre a mesa uma criatura preta e branca, com olhos enormes e um sorriso que demonstrava experiência demais com sistemas legados.
Era o Gato Félix.
— Você sabe qual é o problema?
— Não.
— Excelente! Então finalmente podemos começar a investigar.
Félix abriu sua famosa bolsa de truques.
Mas, em vez de martelos, escadas e balões, retirou dez pequenos cartões:
cmd
powershell
msconfig
services.msc
regedit
sysdm.cpl
ncpa.cpl
msinfo32
cleanmgr
%temp%
O programador olhou para aquilo.
— São comandos?
Félix sorriu.
— Alguns.
— Programas?
— Alguns.
— Painéis?
— Também.
— Então o que são?
— Portas.
E nossa viagem começa aqui.
🪟 CAPÍTULO 1 — WIN + R: O PEQUENO EXECUTAR QUE ABRE UM MUNDO
Pressione:
Windows + R
Aparece uma pequena janela chamada Executar.
Ela parece insignificante.
Mas é uma espécie de recepcionista do Windows.
Você entrega alguma coisa:
cmd
e o Windows tenta descobrir o que aquilo significa.
Pode ser um executável.
Pode ser um console administrativo.
Pode ser um applet clássico do Painel de Controle.
Pode ser um caminho.
Pode até conter uma variável de ambiente.
É por isso que a popular lista dos “10 comandos do Windows” é útil, mas tecnicamente simplificada demais.
Observe:
| Entrada | O que realmente é |
|---|
cmd | interpretador de comandos |
powershell | shell e plataforma de automação |
msconfig | utilitário de configuração |
services.msc | console MMC |
regedit | editor do Registro |
sysdm.cpl | applet clássico do sistema |
ncpa.cpl | applet de conexões de rede |
msinfo32 | ferramenta de informações do sistema |
cleanmgr | utilitário de limpeza |
%temp% | variável de ambiente expandida para um diretório |
Primeira lição de Félix:
Não decore apenas o nome da ferramenta. Entenda qual camada do sistema ela permite observar ou administrar.
Isso será importante mais adiante.
🐾 CAPÍTULO 2 — CMD: O VELHO GATO AINDA CAÇA
Digite:
cmd
O Prompt de Comando aparece.
Para alguém chegando agora ao Windows, aquela tela preta pode parecer antiquada.
Para um programador COBOL, porém, ela quase diz:
“Bem-vindo. Aqui você não precisa clicar em tudo.”
O CMD carrega décadas de compatibilidade.
Experimente:
hostname
para descobrir o nome da máquina.
Depois:
whoami
para descobrir sob qual identidade está executando.
Agora:
ipconfig /all
para visualizar informações detalhadas das interfaces de rede.
Também temos:
tasklist
para processos.
E:
netstat -ano
para observar conexões e seus respectivos PIDs.
Imagine encontrar:
TCP 192.168.0.20:52100 203.0.113.10:443 ESTABLISHED 8740
O número final é o PID.
Então podemos investigar:
tasklist | findstr 8740
Agora temos uma relação:
conexão
↓
PID
↓
processo
Veja como mudou a pergunta.
Antes:
“Tem alguma coisa estranha na rede.”
Agora:
“Qual processo está associado a determinada conexão?”
Isso é troubleshooting orientado por evidência.
No mainframe fazemos exatamente esse tipo de decomposição.
O segredo não está no comando.
Está na pergunta feita antes do comando.
⚡ CAPÍTULO 3 — POWERSHELL: A BOLSA MÁGICA FICOU PROGRAMÁVEL
Félix retira outra ferramenta:
powershell
Nosso programador pensa:
— CMD azul?
Não.
Essa interpretação perde justamente a característica mais interessante.
No CMD, boa parte do universo é apresentada como texto.
No PowerShell, os comandos trabalham intensamente com objetos.
Execute:
Get-Process
Não estamos simplesmente imprimindo uma lista bonita.
Estamos manipulando objetos representando processos.
Por isso podemos fazer:
Get-Process | Sort-Object CPU
Ou:
Get-Service
E depois:
Get-Service | Where-Object Status -eq "Running"
O símbolo:
|
é o famoso pipe.
Conceitualmente:
Get-Service
|
v
objetos
|
v
Where-Object
|
v
somente os desejados
Para o programador COBOL, pense em uma sequência de processamento:
INPUT
↓
SELEÇÃO
↓
TRANSFORMAÇÃO
↓
OUTPUT
Mas PowerShell pode continuar encadeando operações de maneira extremamente poderosa.
💡 Curiosidade
É comum um iniciante pensar:
“Se existe PowerShell, CMD morreu.”
Não.
Compatibilidade importa.
Existem .bat, .cmd, instaladores, rotinas administrativas e procedimentos construídos durante décadas.
Programador de mainframe deveria reconhecer imediatamente essa filosofia.
Modernização não é sinônimo de destruição daquilo que continua funcionando.
Félix aprovaria.
🚦 CAPÍTULO 4 — MSCONFIG: NÃO ARRANQUE FIOS PARA DESCOBRIR QUAL LÂMPADA APAGOU
Digite:
msconfig
Entramos no System Configuration.
Ali encontramos áreas relacionadas a inicialização, boot, serviços e ferramentas.
O propósito interessante do MSConfig não é transformar qualquer pessoa em “otimizador de Windows”.
É diagnóstico.
Suponha:
Windows inicia
↓
problema aparece
Podemos investigar se componentes e serviços carregados durante a inicialização estão relacionados ao comportamento.
O erro clássico da internet é:
“DESATIVE ESTES 28 SERVIÇOS SECRETOS E GANHE 500% DE PERFORMANCE!”
Félix imediatamente fecha o navegador.
Desativar componentes aleatoriamente produz algo pior do que um sistema lento:
um sistema alterado sem documentação.
Você corrige um sintoma hoje e cria três mistérios para daqui a seis meses.
Regra Bellacosa:
ANTES
estado original
ALTERAÇÃO
o que mudou
MOTIVO
por que mudou
RESULTADO
o que aconteceu
ROLLBACK
como retornar
Isso é praticamente change management aplicado ao desktop.
⚙️ CAPÍTULO 5 — SERVICES.MSC: OS TRABALHADORES QUE VOCÊ NÃO VÊ
Digite:
services.msc
Aparece o gerenciador de serviços.
Aqui encontramos processos e componentes executados em background para sustentar funcionalidades do sistema e aplicações.
Podemos observar:
Nome
Descrição
Status
Tipo de inicialização
Conta utilizada
E estados como:
Running
Stopped
Paused
Um serviço também pode possuir diferentes comportamentos de inicialização:
Automatic
Automatic (Delayed Start)
Manual
Disabled
E aqui existe uma pegadinha importante:
Manual não significa defeituoso.
Alguns serviços simplesmente não precisam permanecer ativos continuamente.
Pense no mainframe.
Uma Started Task não existe simplesmente para “encher o SDSF”.
Existe porque algum subsistema ou função precisa dela.
No Windows, o raciocínio também deve ser:
“Qual função depende deste serviço?”
Não:
“Nunca ouvi falar dele. Vou desabilitar.”
🖨️ Exemplo
A impressão parou.
Podemos investigar o subsistema relacionado ao spooler.
A sequência mental seria:
Usuário não imprime
↓
impressora?
↓
fila?
↓
serviço?
↓
driver?
↓
rede?
↓
permissão?
Isso é investigação.
🗝️ CAPÍTULO 6 — REGEDIT: FÉLIX ENTRA NA SALA DAS MÁQUINAS
Então aparece:
regedit
Félix fica sério.
— Aqui não é lugar para experimentar receita de TikTok.
O Windows Registry é uma estrutura hierárquica utilizada pelo Windows e por aplicações para armazenar grande quantidade de configurações.
Encontramos raízes como:
HKEY_CLASSES_ROOT
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS
HKEY_CURRENT_CONFIG
Visualmente:
REGISTRY
│
├── HKEY_CURRENT_USER
│ └── configurações associadas ao usuário
│
├── HKEY_LOCAL_MACHINE
│ └── configurações da máquina
│
└── ...
Para alguém que trabalhou com estruturas hierárquicas, a árvore imediatamente faz sentido.
Mas existe um perigo.
O Registry Editor permite alterações que podem afetar profundamente o sistema.
Portanto:
“achei esta chave”
não significa:
“devo alterar esta chave”
Antes de uma mudança séria, registre:
chave
valor anterior
novo valor
motivo
data
resultado esperado
rollback
🐈 Easter egg
Félix encontra uma chave misteriosa:
HKEY_LOCAL_MACHINE
\SOFTWARE
\BELLACOSA
\INCIDENT
Dentro dela:
LastIncident = 03:17
Ele olha para o relógio.
03:17.
O jovem COBOL decide que talvez seja melhor não abrir a próxima chave.
🧬 CAPÍTULO 7 — SYSDM.CPL: O DNA DA MÁQUINA
Digite:
sysdm.cpl
As propriedades clássicas do sistema aparecem.
Aqui encontramos áreas relacionadas a:
Computer Name
Hardware
Advanced
System Protection
Remote
Em opções avançadas encontramos elementos importantes como desempenho, perfis, inicialização e variáveis de ambiente.
Uma das mais famosas é:
PATH
Imagine digitar:
java
Como o Windows encontra java.exe?
Uma das peças dessa resolução é justamente o PATH.
Conceitualmente:
java
↓
Windows procura nos locais apropriados
↓
PATH contém vários diretórios
↓
executável encontrado
↓
execução
Também encontramos variáveis como:
TEMP
TMP
JAVA_HOME
E isso nos prepara para uma das últimas portas de Félix.
🌐 CAPÍTULO 8 — NCPA.CPL: “A INTERNET CAIU” NÃO É DIAGNÓSTICO
Digite:
ncpa.cpl
Você chega às conexões de rede clássicas.
Ali podem aparecer:
Ethernet
Wi-Fi
VPN
Bluetooth
adaptadores virtuais
Aqui começamos a enxergar aquilo que o usuário simplesmente chama de:
“Internet.”
Mas “internet não funciona” pode significar dezenas de coisas.
Faça perguntas:
Adaptador está ativo?
↓
Recebeu endereço IP?
↓
Existe gateway?
↓
Gateway responde?
↓
DNS funciona?
↓
Existe conectividade externa?
↓
Somente determinada aplicação falha?
Podemos combinar:
ipconfig /all
com outros testes de rede.
Isso é importantíssimo.
Se conseguimos alcançar um endereço IP externo, mas nomes não são resolvidos, por exemplo, a investigação começa a apontar para DNS em vez de simplesmente declarar:
“A internet caiu.”
No mainframe ocorre a mesma coisa.
“CICS está lento” também não é diagnóstico.
É sintoma.
🔬 CAPÍTULO 9 — MSINFO32: A RADIOGRAFIA DO COMPUTADOR
Digite:
msinfo32
Temos uma extraordinária ferramenta de inventário e diagnóstico.
Ela permite observar informações sobre:
Sistema operacional
versão
fabricante
modelo
processador
memória
BIOS/UEFI
hardware
componentes
drivers
ambiente de software
Em vez de perguntar ao usuário:
“Qual computador você tem?”
e receber:
“Um preto.”
podemos coletar evidências.
Existe inclusive possibilidade de produzir relatório por linha de comando, por exemplo:
msinfo32 /report relatorio.txt
Agora o suporte deixa de depender apenas da memória do usuário.
Temos um artefato.
Isso é muito próximo da mentalidade mainframe:
não suponha
↓
colete
↓
correlacione
↓
compare
↓
conclua
🧹 CAPÍTULO 10 — CLEANMGR: NÃO CONFUNDA LIMPEZA COM EXORCISMO
Digite:
cleanmgr
O clássico Disk Cleanup aparece.
Ele pode ajudar a remover categorias de arquivos que não precisam permanecer ocupando armazenamento.
Mas existe uma lição maior.
Limpeza de disco não é cura universal de performance.
Um computador lento pode estar sofrendo por:
CPU
memória
I/O
processos
drivers
serviços
rede
storage
malware
aplicação
configuração
Ter arquivos temporários não significa automaticamente que encontramos a causa.
No Windows moderno também existe Storage Sense, proporcionando mecanismos mais atuais e automatizados de gerenciamento de espaço.
O cleanmgr representa perfeitamente uma característica que programadores COBOL conhecem muito bem:
Uma ferramenta pode ser antiga sem ser inútil.
📦 CAPÍTULO 11 — %TEMP% NÃO É UM COMANDO
Chegamos à décima entrada:
%temp%
Aqui a famosa imagem de “10 comandos” comete sua simplificação mais interessante.
%temp% é uma variável de ambiente.
Quando digitamos:
%temp%
o Windows expande o valor.
Algo conceitualmente parecido com:
%temp%
↓
C:\Users\USUARIO\AppData\Local\Temp
e abre esse diretório.
Portanto, a sequência real é aproximadamente:
variável
↓
expansão
↓
caminho
↓
Explorer
Outro mito precisa morrer:
“Tudo em TEMP é lixo e pode ser apagado cegamente.”
Não necessariamente.
Programas ativos podem utilizar arquivos temporários. Alguns estarão bloqueados justamente porque estão sendo usados.
A postura correta continua sendo compreender o que estamos removendo e por quê.
🧰 CAPÍTULO 12 — FÉLIX DESCOBRE QUE A BOLSA TEM MAIS DE 10 FERRAMENTAS
Nossa lista original é apenas o começo.
Eu acrescentaria ao kit do aprendiz:
eventvwr.msc
devmgmt.msc
taskmgr
diskmgmt.msc
compmgmt.msc
perfmon
resmon
control
appwiz.cpl
E um merece destaque especial:
eventvwr.msc
O Event Viewer.
Agora entramos no terreno da evidência histórica.
Compare:
“O sistema deu erro ontem.”
com:
“Às 03:17 ocorreu determinado evento, envolvendo determinado componente, depois da inicialização de determinado serviço.”
Isso muda tudo.
É a diferença entre história oral e telemetria.
🏛️ CAPÍTULO 13 — O PROGRAMADOR COBOL DESCOBRE UM PEQUENO MAINFRAME DENTRO DO WINDOWS
Félix espalha os cartões sobre a mesa.
Nosso programador percebe um padrão.
Podemos construir algumas analogias didáticas, tomando cuidado para não tratá-las como equivalências técnicas:
| Windows | Ponte mental para z/OS |
|---|
| Event Viewer | logs/SMF |
| Performance Monitor | RMF e ferramentas de performance |
| Services | Started Tasks |
| PowerShell | automação/REXX, em sentido amplo |
| identidade/permissões | RACF |
| CMD | ambiente de comandos, analogia distante com TSO |
| processos | visão operacional lembrando algumas funções do SDSF |
| configurações de rede | TCP/IP stack e ferramentas relacionadas |
Não são equivalentes.
SMF não é “o Event Viewer do mainframe”.
SDSF não é “Task Manager do z/OS”.
RACF não é simplesmente “usuários do Windows”.
A analogia serve apenas para construir a primeira ponte cognitiva.
Depois atravessamos a ponte e estudamos cada tecnologia corretamente.
🕵️ CAPÍTULO 14 — A VERDADEIRA FERRAMENTA ESTAVA NA CABEÇA DE FÉLIX
O jovem programador finalmente pergunta:
— Qual desses comandos eu preciso decorar?
Félix coloca todos de volta na bolsa.
— Nenhum deles é o principal.
— Então qual é?
Ele escreve:
SINTOMA
↓
HIPÓTESE
↓
EVIDÊNCIA
↓
TESTE
↓
RESULTADO
↓
NOVA HIPÓTESE
↓
CAUSA
↓
CORREÇÃO
↓
VALIDAÇÃO
Essa é a ferramenta.
Imagine:
“Meu Windows está lento.”
Não execute cleanmgr automaticamente.
Pergunte:
Lento como?
Inicialização?
Aplicação?
Rede?
Disco?
Resposta da interface?
Depois:
WINDOWS LENTO
│
├── CPU?
│
├── memória?
│
├── disco?
│
├── rede?
│
├── processo?
│
├── serviço?
│
├── driver?
│
└── aplicação?
Agora escolhemos ferramentas de acordo com a hipótese.
Essa mudança parece pequena.
É gigantesca.
🔭 CAPÍTULO 15 — OBSERVABILIDADE ANTES DA CHAVE DE FENDA
Existe uma tentação permanente na informática:
mexer primeiro e investigar depois.
Félix ensina o contrário.
Antes de reiniciar um serviço, talvez seja útil observar seu estado.
Antes de matar um processo, descubra o que ele está fazendo.
Antes de alterar o Registry, registre o valor existente.
Antes de limpar arquivos, determine se armazenamento realmente é o problema.
Antes de alterar rede, capture a configuração.
Em outras palavras:
ANTES DA MUDANÇA
↓
COLETE EVIDÊNCIA
↓
FAÇA UMA ALTERAÇÃO CONTROLADA
↓
OBSERVE
↓
COMPARE
Isso vale para um notebook Windows.
Vale para um servidor.
Vale para CICS.
Vale para Db2.
Vale para MQ.
E certamente vale para z/OS.
🧙 CAPÍTULO 16 — O SEGREDO DA BOLSA MÁGICA
Existe uma razão pela qual escolhemos o Gato Félix para essa viagem.
A famosa bolsa de truques sempre oferecia uma ferramenta apropriada à situação.
Mas um profissional de infraestrutura precisa aprender justamente o contrário da interpretação infantil da bolsa:
não escolha primeiro a ferramenta.
Escolha primeiro a pergunta.
Depois procure a ferramenta adequada.
O mau troubleshooting funciona assim:
Tenho PowerShell!
↓
O que posso fazer com ele?
O bom troubleshooting:
Tenho um problema.
↓
O que preciso descobrir?
↓
Que evidência responderia?
↓
Qual ferramenta consegue obtê-la?
Essa inversão transforma completamente o profissional.
☕ EPÍLOGO — NÃO ERA SOBRE DEZ COMANDOS
Já estava amanhecendo.
Nosso programador olhou novamente para a imagem original:
1 cmd
2 powershell
3 msconfig
4 services.msc
5 regedit
6 sysdm.cpl
7 ncpa.cpl
8 msinfo32
9 cleanmgr
10 %temp%
No começo da noite ele enxergava dez comandos.
Agora enxergava:
Shell
Automação
Boot
Serviços
Configuração
Sistema
Rede
Inventário
Storage
Ambiente
E, por trás deles:
Aplicação
↓
Sistema operacional
↓
Serviços
↓
Rede
↓
Segurança
↓
Storage
↓
Hardware
Félix colocou a bolsa no ombro.
— Então agora você sabe consertar Windows?
O programador respondeu:
— Não.
Félix abriu um enorme sorriso.
— Ótimo.
Porque finalmente ele havia entendido a diferença entre saber alguns truques e saber investigar.
Um profissional experiente raramente começa dizendo:
“Eu sei qual é o problema.”
Ele começa perguntando:
“Que evidências temos?”
Essa pergunta atravessa gerações de tecnologia.
Do cartão perfurado ao PowerShell.
Do JCL ao Git.
Do TSO ao terminal moderno.
Do RMF à observabilidade distribuída.
Do COBOL de milhões de linhas ao pequeno notebook sobre nossa mesa.
Ferramentas mudam.
Interfaces mudam.
Nomes mudam.
Mas o método permanece:
observar, decompor, medir, correlacionar, testar, corrigir e validar.
Às 03:17, o programa voltou a funcionar.
Nosso jovem COBOL virou-se para agradecer.
Félix já havia desaparecido.
Sobre a mesa restava apenas um pequeno cartão preto:
//FELIXJOB JOB ...
//STEP01 EXEC PGM=CURIOSITY
//SYSOUT DD SYSOUT=*
//*
//* NEVER TRUST A GREEN DASHBOARD
//* WITHOUT LOOKING AT THE EVIDENCE.
//*
No verso, escrito a lápis:
“A melhor ferramenta da bolsa não resolve o incidente. Ela ajuda você a fazer a pergunta certa.”
E, em algum lugar entre uma LPAR, um notebook Windows e uma velha fita esquecida no datacenter, alguém abriu o eventvwr.msc.
Havia um evento registrado exatamente às 03:17.
🐈⬛ Fim? Não. Apenas mais uma madrugada no Bellacosa Mainframe.
