z/OS from Windows: JES2, SDSF, RACF and batch

Qué vas a conseguir

Entender el entorno z/OS que te toca soportar sin ser programador de sistemas: qué es cada pieza y a qué se parece en Windows o Linux, dónde mirar la salida de un trabajo, qué significan los códigos de retorno, qué comandos de consola son de solo lectura y cuáles no, y cómo seguir un trabajo nocturno que no ha terminado hasta dar con quién lo está bloqueando.

Antes de empezar

Un usuario TSO con acceso a ISPF y SDSF (o a la interfaz web de z/OSMF) y, si te lo dan, autorización para emitir comandos de consola desde SDSF. Lo de esta guía es z/OS 3.1 o 3.2.
El runbook del centro: quién es el programador de sistemas de guardia, quién es el dueño de cada cadena batch y qué planificador se usa (IBM Z Workload Scheduler, Control-M u otro).
Una regla que no se negocia: en z/OS casi todo lo que no empieza por D (display) cambia algo. Ante la duda, solo comandos D y $D, y el resto con la aprobación del responsable.

1. El mapa: z/OS en términos de Windows

z/OS	Lo más parecido en Windows/Linux	Para qué lo vas a usar
LPAR	Una VM sobre un hipervisor (PR/SM, en el firmware de la máquina)	Cada LPAR es un sistema z/OS (o Linux) con su CPU, memoria y E/S
HMC	vCenter más iDRAC/iLO	Arrancar, parar y repartir capacidad entre LPAR; solo con permiso
IPL	El arranque del sistema	Cuando hay mantenimiento o un cambio que no es dinámico
JES2	El planificador de tareas más la cola de impresión	Recibe los trabajos batch, los ejecuta y guarda su salida en el spool
JCL	Un `.bat` que declara programa y ficheros	Describe cada paso de un trabajo
SDSF	El Visor de eventos más el Administrador de tareas	Ver trabajos, su salida y la consola
Dataset	Un fichero (con formato fijo)	Los datos de entrada y salida del batch
RACF	Active Directory más las ACL de NTFS	Usuarios, grupos y quién puede leer qué
CICS e IMS	Un servidor de aplicaciones (IIS, Tomcat)	Las transacciones en línea
SMF	El registro de eventos y los contadores de rendimiento	Rendimiento, auditoría y facturación
REXX	PowerShell	Pequeñas automatizaciones

2. LPAR, IPL y capacidad

Una máquina IBM Z se divide en LPAR. Varias LPAR z/OS suelen formar un Parallel Sysplex que comparte datos y carga, igual que un clúster: si una LPAR se para, las aplicaciones siguen en las otras.
El IPL (Initial Program Load) es el arranque. Se lanza desde la HMC con una dirección de carga (el disco del sistema) y un parámetro de carga que apunta al miembro LOADxx de configuración. Se planifica: después de aplicar mantenimiento (PTF) con SMP/E, para un cambio de parámetros que no se puede activar en caliente o por una ventana trimestral. En un sysplex se hace LPAR a LPAR (rolling IPL). Un IPL no planificado es un incidente grave y lo lleva el programador de sistemas.
Capacidad: la CPU se mide en MSU y el coste del software se calcula sobre ella (los informes SCRT salen de los registros SMF). Los pesos y los topes de cada LPAR se definen en la HMC; la capacidad temporal (On/Off Capacity on Demand, CBU para contingencia) se activa por contrato. Dentro de la LPAR, WLM reparte la CPU según la prioridad de cada carga. Para operaciones: un cambio de capacidad es un cambio planificado, nunca un ajuste para que un trabajo vaya más rápido.

D IPLINFO dice cuándo fue el último IPL y con qué parámetros; D M=CPU, los procesadores en línea.

Consola · último IPL

›D IPLINFOIEE254I 02.15.07 IPLINFO DISPLAY 418 SYSTEM IPLED AT 05.12.44 ON 10/05/2026 RELEASE z/OS 03.02.00    LICENSE = z/OS USED LOAD00 IN SYS0.IPLPARM ON 0A82 IEASYS LIST = (00,PR) (OP) IPL DEVICE: ORIGINAL(0A80) CURRENT(0A80) VOLUME(ZOS32A)

3. JES2, JCL y los trabajos batch

Un trabajo es un JCL con una tarjeta JOB, uno o varios pasos EXEC (el programa) y sus DD (los ficheros):

JCL · NOMDIA01

//NOMDIA01 JOB (CONT,NOM),'NOMINA DIARIA',CLASS=N,MSGCLASS=X//STEP010  EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSIN    DD DUMMY//SYSUT1   DD DSN=PROD.NOMINA.MAESTRO,DISP=SHR//SYSUT2   DD DSN=PROD.NOMINA.EXTRACTO(+1),DISP=(NEW,CATLG,DELETE),//            SPACE=(CYL,(5,5)),RECFM=FB,LRECL=200

CLASS=N decide qué iniciadores pueden ejecutarlo (un iniciador es un hueco de ejecución, como un trabajador de un grupo de procesos). Si ninguno sirve esa clase, el trabajo espera en cola.
DISP=SHR pide el dataset compartido; DISP=OLD o NEW, en exclusiva. Esa reserva (un ENQ) es la que hace esperar a otro trabajo que pide el mismo dataset.
El planificador lanza los trabajos en orden y con dependencias; JES2 solo los ejecuta. Los reinicios se hacen desde el planificador, no reenviando el JCL a mano.

4. SDSF: dónde se lee la salida

En SDSF, los comandos de panel:

ST: todos los trabajos (en cola, en ejecución y terminados). Filtra con PREFIX NOM* y OWNER *.
DA: lo que está activo ahora, con CPU y E/S. Un trabajo en DA con CPU al 0 % durante horas está esperando algo.
LOG: el SYSLOG, la consola del sistema con fecha y hora.
H y O: salida retenida y salida pendiente de imprimir; I, la cola de entrada.

Junto al trabajo, S abre toda la salida y ? la lista de ficheros: JESMSGLG (los mensajes de JES), JESJCL (el JCL tal como se interpretó) y JESYSMSG (lo que pasó en cada paso y con cada dataset). La columna Max-RC de ST resume el final:

Max-RC	Qué significa
`CC 0000`	Correcto
`CC 0004`	Aviso; según el programa, normal
`CC 0008` o más	Error del programa; mira el paso en JESYSMSG
`ABEND S0C4`	Fallo de sistema (acceso a memoria no válido), como un access violation
`ABEND S222`	Cancelado por un operador
`ABEND S322`	Superó el tiempo de CPU permitido
`ABEND U4038`	Fallo de usuario (de la aplicación o del runtime)
`JCL ERROR`	El JCL está mal o falta un dataset; no llegó a ejecutarse

Los códigos que empiezan por S son del sistema; los que empiezan por U, de la aplicación. Ninguno se arregla relanzando sin más: se pasa al dueño de la cadena con el paso y el mensaje.

5. Datasets, catálogo y RACF

Un dataset tiene un nombre de hasta 44 caracteres en partes de hasta 8 (PROD.NOMINA.MAESTRO). La primera parte (HLQ) suele indicar entorno y aplicación, y es la que protege RACF.
Tipos: secuencial (un fichero), PDS/PDSE (una carpeta de miembros, como SYS1.PARMLIB), VSAM (un fichero indexado, casi una tabla) y GDG (generaciones numeradas: (+1) es la nueva, (0) la última; como una rotación de logs).
El catálogo dice en qué volumen está cada dataset, como un DNS de ficheros. También existe z/OS UNIX con ficheros normales en zFS, donde viven Java, los certificados y muchas herramientas modernas.

RACF controla quién es quién y qué puede hacer. Lo administra el equipo de seguridad (atributo SPECIAL); operaciones suele poder consultar:

TSO · consultar un usuario y un perfil

›LISTUSER JPEREZUSER=JPEREZ  NAME=JUAN PEREZ          OWNER=NOMINA    CREATED=24.112 DEFAULT-GROUP=NOMLECT  PASSDATE=26.290 PASS-INTERVAL= 90 ATTRIBUTES=REVOKED›LISTDSD DATASET('PROD.NOMINA.**') GENERIC

ATTRIBUTES=REVOKED: la cuenta está revocada, normalmente por intentos fallidos. La reactiva seguridad con ALTUSER JPEREZ RESUME, previa verificación.
Los permisos se dan a grupos, no a personas: PERMIT 'PROD.NOMINA.**' ID(NOMLECT) ACCESS(READ) GENERIC y, si el perfil está en memoria, SETROPTS GENERIC(DATASET) REFRESH. Niveles de acceso, de menos a más: NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER.

6. CICS, IMS, SMF y REXX

CICS e IMS son gestores de transacciones: miles de operaciones cortas por segundo (consultar un saldo, registrar un pedido). Cada uno corre en una o varias regiones, que en SDSF ves como tareas arrancadas (en DA). Para saber si una región está viva: que aparezca en D A,L, su log en SDSF y, si te lo permiten, F CICSPRD1,CEMT I TASK para ver sus tareas. En IMS, /DIS A REG desde su terminal maestro o la consola con el carácter de comandos de ese IMS. Parar o reciclar una región lo decide el equipo de la aplicación.
SMF escribe registros numerados: el 30 (contabilidad de trabajos y pasos), del 70 al 79 (RMF, rendimiento), el 80 (RACF), el 110 (CICS) y el 89 (uso de producto, para la facturación). D SMF muestra dónde se están escribiendo.
REXX es el lenguaje de scripts de TSO. Con la interfaz REXX de SDSF se listan trabajos sin abrir paneles:

REXX · trabajos NOM* y su código de retorno

/* REXX */rc = isfcalls('ON')isfprefix = 'NOM*'isfowner = '*'Address SDSF "ISFEXEC ST"do i = 1 to JNAME.0  say JNAME.i JOBID.i QUEUE.i RETCODE.iendrc = isfcalls('OFF')

7. La consola y los comandos de operador

Desde SDSF se emiten con / delante (/D A,L) y la respuesta se ve en LOG o en ULOG. Los de consulta:

Comando	Qué muestra
`D A,L`	Trabajos, tareas arrancadas y usuarios TSO activos
`D IPLINFO`	El último IPL y sus parámetros
`D R,L`	Mensajes pendientes de respuesta (montajes de cinta, peticiones de operador)
`D GRS,C`	Recursos con contención: quién tiene un dataset y quién lo espera
`$D JOBQ,DELAY=YES,DELAY`	Trabajos en cola retrasados y el motivo
`$D I`	Iniciadores de JES2 y las clases que sirven

C (cancelar), $P, $C, V ... OFFLINE o una respuesta R nn,... cambian el sistema. Con la aprobación del dueño o del programador de sistemas, y anotados en el ticket.

8. El ticket: "el batch nocturno no ha terminado y no han salido los informes de la mañana"

7:45. Contabilidad no tiene los informes de nómina. En el planificador, NOMDIA01 aparece en ejecución desde las 02:10 y todo lo que depende de él está esperando.

Dónde está: en SDSF, PREFIX NOM* y ST. Si la cola es EXECUTION y en DA no consume CPU, está esperando algo. Si la cola es INPUT, nunca empezó (paso 4).
Qué espera: S sobre el trabajo y la salida JESYSMSG, o el LOG alrededor de las 02:10:

SDSF · LOG

IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO NOMDIA01IEF863I DSN = PROD.NOMINA.MAESTRO NOMDIA01 RC = 04*IEF099I JOB NOMDIA01 WAITING FOR DATA SETS

Quién tiene el dataset:

Consola · contención

›D GRS,CISG343I 07.48.12 GRS STATUS 233S=SYSTEMS SYSDSN   PROD.NOMINA.MAESTROSYSNAME  JOBNAME  ASID     TCBADDR   EXC/SHR    STATUSSYSA     JPEREZ   0087     008E5C10  EXCLUSIVE  OWNSYSA     NOMDIA01 0045     008FD0E8  SHARE      WAIT

Aquí es un usuario TSO que dejó el dataset abierto en edición por la tarde. Si el dueño es otro trabajo (una copia que se quedó colgada), la pista sigue igual: D A,L y su salida en SDSF.

Otras esperas habituales:

Cinta: D R,L muestra un IEF233A M ... pendiente; el trabajo espera a que se monte un volumen. Con cinta virtual, lo resuelve el equipo de almacenamiento.
Retenido o sin iniciador: $D JOBQ,DELAY=YES,DELAY devuelve DELAY=(HOLD) o DELAY=(JOBCLASS). Retenido se libera con $A J4711 cuando el dueño lo confirma; para la clase, $D I dice si algún iniciador sirve la clase N.

Resolver, con aprobación: se pide al usuario que salga de la edición; si no contesta, con el visto bueno del responsable, C U=JPEREZ para su sesión TSO. El trabajo continúa solo en cuanto se libera el dataset (IEF099I desaparece del log). Si la cadena ya no llega a tiempo, el dueño decide cancelar (C NOMDIA01) y relanzar desde el planificador en el paso que indique el runbook: reenviar a mano puede duplicar actualizaciones o crear una generación GDG de más.
Comprobar: NOMDIA01 termina con CC 0000, los dependientes arrancan y los informes salen.

En el ticket: hora de inicio, mensaje de espera, salida de D GRS,C, quién aprobó la acción, comando emitido y resultado final.

Siguientes pasos

La guía de VMware ESXi y vCenter es el equivalente x86 de las LPAR y la HMC.
La de iDRAC e iLO cubre la gestión fuera de banda, la misma idea que la HMC en un servidor normal.
Para practicar con los paneles sin tocar producción, IBM ofrece el entorno gratuito IBM Z Xplore.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.

What you'll get

Understanding the z/OS environment you have to support without being a systems programmer: what each piece is and what it resembles in Windows or Linux, where to read a job's output, what return codes mean, which console commands are read-only and which are not, and how to follow a nightly job that never finished until you find who is blocking it.

Before you start

A TSO user with access to ISPF and SDSF (or the z/OSMF web interface) and, if granted, authority to issue console commands from SDSF. This guide covers z/OS 3.1 or 3.2.
The site's runbook: who the on-call systems programmer is, who owns each batch chain and which scheduler is used (IBM Z Workload Scheduler, Control-M or another).
One non-negotiable rule: on z/OS almost everything that does not start with D (display) changes something. When in doubt, only D and $D commands, and the rest with the owner's approval.

1. The map: z/OS in Windows terms

z/OS	Closest thing in Windows/Linux	What you will use it for
LPAR	A VM on a hypervisor (PR/SM, in the machine's firmware)	Each LPAR is a z/OS (or Linux) system with its own CPU, memory and I/O
HMC	vCenter plus iDRAC/iLO	Start, stop and share capacity between LPARs; only with permission
IPL	Booting the system	When there is maintenance or a change that is not dynamic
JES2	Task Scheduler plus the print queue	Receives batch jobs, runs them and keeps their output on the spool
JCL	A `.bat` that declares program and files	Describes each step of a job
SDSF	Event Viewer plus Task Manager	View jobs, their output and the console
Dataset	A file (with a fixed format)	The batch input and output data
RACF	Active Directory plus NTFS ACLs	Users, groups and who can read what
CICS and IMS	An application server (IIS, Tomcat)	Online transactions
SMF	The event log and performance counters	Performance, audit and billing
REXX	PowerShell	Small automations

2. LPARs, IPL and capacity

An IBM Z machine is split into LPARs. Several z/OS LPARs usually form a Parallel Sysplex that shares data and workload, just like a cluster: if one LPAR stops, applications carry on in the others.
The IPL (Initial Program Load) is the boot. It is started from the HMC with a load address (the system disk) and a load parameter pointing at the LOADxx configuration member. It is planned: after applying maintenance (PTFs) with SMP/E, for a parameter change that cannot be activated live, or in a quarterly window. In a sysplex it is done one LPAR at a time (rolling IPL). An unplanned IPL is a major incident and the systems programmer leads it.
Capacity: CPU is measured in MSUs and software cost is calculated on it (the SCRT reports come from SMF records). Each LPAR's weights and caps are defined in the HMC; temporary capacity (On/Off Capacity on Demand, CBU for disaster recovery) is activated under contract. Inside the LPAR, WLM shares CPU according to each workload's priority. For operations: a capacity change is a planned change, never a tweak to make a job run faster.

D IPLINFO shows when the last IPL was and with which parameters; D M=CPU, the processors online.

Console · last IPL

›D IPLINFOIEE254I 02.15.07 IPLINFO DISPLAY 418 SYSTEM IPLED AT 05.12.44 ON 10/05/2026 RELEASE z/OS 03.02.00    LICENSE = z/OS USED LOAD00 IN SYS0.IPLPARM ON 0A82 IEASYS LIST = (00,PR) (OP) IPL DEVICE: ORIGINAL(0A80) CURRENT(0A80) VOLUME(ZOS32A)

3. JES2, JCL and batch jobs

A job is JCL with a JOB card, one or more EXEC steps (the program) and their DD statements (the files):

JCL · NOMDIA01

//NOMDIA01 JOB (CONT,NOM),'NOMINA DIARIA',CLASS=N,MSGCLASS=X//STEP010  EXEC PGM=IEBGENER//SYSPRINT DD SYSOUT=*//SYSIN    DD DUMMY//SYSUT1   DD DSN=PROD.NOMINA.MAESTRO,DISP=SHR//SYSUT2   DD DSN=PROD.NOMINA.EXTRACTO(+1),DISP=(NEW,CATLG,DELETE),//            SPACE=(CYL,(5,5)),RECFM=FB,LRECL=200

CLASS=N decides which initiators can run it (an initiator is an execution slot, like a worker in a process pool). If none serves that class, the job waits in the queue.
DISP=SHR asks for the dataset shared; DISP=OLD or NEW, exclusively. That reservation (an ENQ) is what makes another job wait when it asks for the same dataset.
The scheduler launches jobs in order and with dependencies; JES2 only runs them. Restarts are done from the scheduler, not by resubmitting the JCL by hand.

4. SDSF: where to read the output

In SDSF, the panel commands:

ST: all jobs (queued, running and finished). Filter with PREFIX NOM* and OWNER *.
DA: what is active now, with CPU and I/O. A job in DA at 0% CPU for hours is waiting for something.
LOG: the SYSLOG, the system console with date and time.
H and O: held output and output waiting to print; I, the input queue.

Next to the job, S opens all its output and ? the list of files: JESMSGLG (JES messages), JESJCL (the JCL as interpreted) and JESYSMSG (what happened in each step and with each dataset). The Max-RC column in ST sums up the end:

Max-RC	What it means
`CC 0000`	Success
`CC 0004`	Warning; depending on the program, normal
`CC 0008` or higher	Program error; check the step in JESYSMSG
`ABEND S0C4`	System abend (invalid memory access), like an access violation
`ABEND S222`	Cancelled by an operator
`ABEND S322`	Exceeded its allowed CPU time
`ABEND U4038`	User abend (from the application or its runtime)
`JCL ERROR`	The JCL is wrong or a dataset is missing; it never ran

Codes starting with S come from the system; those starting with U, from the application. None is fixed by simply rerunning: it goes to the chain's owner with the step and the message.

5. Datasets, the catalog and RACF

A dataset has a name of up to 44 characters in qualifiers of up to 8 (PROD.NOMINA.MAESTRO). The first qualifier (HLQ) usually indicates environment and application, and it is what RACF protects.
Types: sequential (one file), PDS/PDSE (a folder of members, such as SYS1.PARMLIB), VSAM (an indexed file, almost a table) and GDG (numbered generations: (+1) is the new one, (0) the latest; like log rotation).
The catalog says which volume each dataset is on, like a DNS for files. There is also z/OS UNIX with normal files in zFS, where Java, certificates and many modern tools live.

RACF controls who is who and what they can do. The security team administers it (SPECIAL attribute); operations can usually query:

TSO · query a user and a profile

›LISTUSER JPEREZUSER=JPEREZ  NAME=JUAN PEREZ          OWNER=NOMINA    CREATED=24.112 DEFAULT-GROUP=NOMLECT  PASSDATE=26.290 PASS-INTERVAL= 90 ATTRIBUTES=REVOKED›LISTDSD DATASET('PROD.NOMINA.**') GENERIC

ATTRIBUTES=REVOKED: the account is revoked, usually after failed attempts. Security reinstates it with ALTUSER JPEREZ RESUME, after verification.
Permissions go to groups, not people: PERMIT 'PROD.NOMINA.**' ID(NOMLECT) ACCESS(READ) GENERIC and, if the profile is held in memory, SETROPTS GENERIC(DATASET) REFRESH. Access levels, from least to most: NONE, EXECUTE, READ, UPDATE, CONTROL, ALTER.

6. CICS, IMS, SMF and REXX

CICS and IMS are transaction managers: thousands of short operations per second (checking a balance, recording an order). Each runs in one or more regions, which you see in SDSF as started tasks (in DA). To check a region is alive: it appears in D A,L, its log in SDSF and, if allowed, F CICSPRD1,CEMT I TASK to see its tasks. In IMS, /DIS A REG from its master terminal or the console with that IMS's command recognition character. Stopping or recycling a region is the application team's decision.
SMF writes numbered records: type 30 (job and step accounting), 70 to 79 (RMF, performance), 80 (RACF), 110 (CICS) and 89 (product usage, for billing). D SMF shows where they are being written.
REXX is TSO's scripting language. With SDSF's REXX interface you list jobs without opening panels:

REXX · NOM* jobs and their return code

/* REXX */rc = isfcalls('ON')isfprefix = 'NOM*'isfowner = '*'Address SDSF "ISFEXEC ST"do i = 1 to JNAME.0  say JNAME.i JOBID.i QUEUE.i RETCODE.iendrc = isfcalls('OFF')

7. The console and operator commands

From SDSF they are issued with a leading / (/D A,L) and the response shows in LOG or ULOG. The query ones:

Command	What it shows
`D A,L`	Active jobs, started tasks and TSO users
`D IPLINFO`	The last IPL and its parameters
`D R,L`	Messages awaiting a reply (tape mounts, operator requests)
`D GRS,C`	Resources in contention: who holds a dataset and who waits for it
`$D JOBQ,DELAY=YES,DELAY`	Delayed queued jobs and the reason
`$D I`	JES2 initiators and the classes they serve

C (cancel), $P, $C, V ... OFFLINE or an R nn,... reply change the system. With the approval of the owner or the systems programmer, and recorded in the ticket.

8. The ticket: "the nightly batch never finished and the morning reports are missing"

7:45. Accounting has no payroll reports. In the scheduler, NOMDIA01 shows as running since 02:10 and everything that depends on it is waiting.

Where it is: in SDSF, PREFIX NOM* and ST. If the queue is EXECUTION and in DA it uses no CPU, it is waiting for something. If the queue is INPUT, it never started (step 4).
What it waits for: S on the job and the JESYSMSG output, or the LOG around 02:10:

SDSF · LOG

IEF861I FOLLOWING RESERVED DATA SET NAMES UNAVAILABLE TO NOMDIA01IEF863I DSN = PROD.NOMINA.MAESTRO NOMDIA01 RC = 04*IEF099I JOB NOMDIA01 WAITING FOR DATA SETS

Who holds the dataset:

Console · contention

›D GRS,CISG343I 07.48.12 GRS STATUS 233S=SYSTEMS SYSDSN   PROD.NOMINA.MAESTROSYSNAME  JOBNAME  ASID     TCBADDR   EXC/SHR    STATUSSYSA     JPEREZ   0087     008E5C10  EXCLUSIVE  OWNSYSA     NOMDIA01 0045     008FD0E8  SHARE      WAIT

Here it is a TSO user who left the dataset open in edit in the afternoon. If the owner is another job (a backup that hung), the trail is the same: D A,L and its output in SDSF.

Other common waits:

Tape: D R,L shows a pending IEF233A M ...; the job is waiting for a volume to be mounted. With virtual tape, the storage team resolves it.
Held or no initiator: $D JOBQ,DELAY=YES,DELAY returns DELAY=(HOLD) or DELAY=(JOBCLASS). A held job is released with $A J4711 once the owner confirms; for the class, $D I tells you whether any initiator serves class N.

Resolve, with approval: ask the user to leave the edit session; if there is no answer, with the manager's go-ahead, C U=JPEREZ for their TSO session. The job carries on by itself as soon as the dataset is released (IEF099I disappears from the log). If the chain can no longer make it in time, the owner decides to cancel (C NOMDIA01) and restart from the scheduler at the step the runbook names: resubmitting by hand can duplicate updates or create one GDG generation too many.
Check: NOMDIA01 ends with CC 0000, the dependants start and the reports come out.

In the ticket: start time, wait message, D GRS,C output, who approved the action, command issued and final result.

Next steps

The VMware ESXi and vCenter guide is the x86 equivalent of LPARs and the HMC.
The iDRAC and iLO one covers out-of-band management, the same idea as the HMC on an ordinary server.
To practise with the panels without touching production, IBM offers the free IBM Z Xplore environment.

Is something missing, or different in your environment? Get in touch and I'll fix it.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →