Orientación en z/OS: espacios de direcciones, datasets, catálogos, JES2 y qué puede ver una sesión SSH en USS

Qué es

Un sistema z/OS ejecuta muchos espacios de direcciones independientes en lugar de una única tabla de procesos compartida: cada trabajo por lotes, cada tarea iniciada (como un subsistema o un servidor), cada sesión de usuario TSO, y el propio z/OS UNIX System Services (USS, el subsistema conforme con POSIX) ocupan su propio espacio de direcciones o conjunto de ellos. No existe una única vista equivalente a ps sobre todo el sistema desde dentro de un espacio de direcciones; los comandos de shell de z/OS UNIX como ps solo muestran los procesos de z/OS UNIX (y, sin autoridad de superusuario, solo los propios), no los trabajos por lotes gestionados por JES ni las tareas iniciadas, salvo que estas usen servicios UNIX.

Los datos persistentes residen en datasets, no en un único árbol de sistema de archivos. Un dataset tiene un nombre como HLQ.PAYROLL.INPUT, un formato y una longitud de registro (RECFM/LRECL, tratados en el próximo artículo), y se localiza mediante un catálogo en lugar de una ruta de directorio: «dónde está este dataset» es una consulta al catálogo, no un recorrido de ruta. Los archivos de z/OS UNIX (respaldados por HFS o zFS) sí forman una jerarquía de tipo Unix bajo /, y esa jerarquía suele estar anclada dentro de un dataset, pero los datasets clásicos referenciados como HLQ.NAME quedan fuera de ese árbol y necesitan su propia sintaxis de acceso desde un shell (véase el próximo artículo).

El trabajo por lotes se planifica y se rastrea mediante JES2 (el JES3 de IBM se descontinuó tras z/OS 2.3; los pocos sitios que aún usan JES3 recurren a un sucesor de terceros): enviar, encolar, ejecutar y retener la salida de los trabajos (spool). TSO/E es el entorno de comandos interactivo, usado con mayor frecuencia a través de ISPF, una interfaz basada en menús y paneles para editar datasets, examinar la salida del spool y ejecutar utilidades; USS es un entorno equivalente a TSO, no un sustituto. z/OSMF (z/OS Management Facility) es la interfaz de IBM orientada a tareas y basada en navegador que se superpone a muchas de estas funciones, y expone API REST que son la forma más adecuada para que un agente interactúe con trabajos y datasets (un artículo aparte trata esas API).

Por qué importa

Un agente que aterriza en un shell de USS mediante SSH es un participante más entre muchos espacios de direcciones independientes, con visibilidad sobre los procesos de USS y las partes del espacio de nombres de datasets/catálogo a las que tiene acceso, no una vista de operador de todo el LPAR. Suponer que ps, top o los listados de archivos bajo / muestran «todo lo que se ejecuta» o «todo lo que está almacenado» en el sistema producirá una imagen muy incompleta.

Cómo aplicarlo

• Distinguir «no visible desde mi shell de USS» de «no se está ejecutando/no existe» — los trabajos por lotes y las tareas iniciadas necesitan JES/SDSF o z/OSMF para verse, no ps.
• Tratar un nombre de dataset como una clave de búsqueda en el catálogo, no como una ruta de sistema de archivos, aunque una notación de shell //'...' lo haga parecer una ruta.
• Recurrir a TSO/ISPF, SDSF o las API REST de z/OSMF (no solo a las herramientas de shell de USS) para cualquier cosa relacionada con trabajos por lotes, salida de spool o datasets clásicos (no USS).

Trampas

• Suponer que los permisos de archivo dentro de USS rigen el acceso a los datasets clásicos; el acceso a datasets se gobierna por separado (véase el artículo sobre RACF).
• Suponer que un único evento de IPL (inicio del sistema) y la vida de un único espacio de direcciones coinciden con el «tiempo de actividad del sistema» de la misma forma que un arranque de Linux; los espacios de direcciones individuales se inician y terminan con mucha más frecuencia de lo que el propio LPAR hace IPL.