Capitulo 1

P4
El computador mainframe comenzó su crecimiento en la década de 1960. En ese tiempo, los
mainframes eran los únicos
tipos de computadoras, y sólo algunos comercios o negocios podían aprovecharlos. Del pequeño
número vendidos en ese
momento, cada mainframe era adaptado de forma tal que pudiera encajar en la principal (y muchas
veces la única)
aplicación de negocios del cliente.

En 1964, sin embargo, las cosas cambiaron dramáticamente cuando los mainframes comenzaron a
estandarizarse el hardware
y software ofrecido a los clientes. Este cambio signado por el comienzo de la era de la computadora
de propósito general.
Con los mainframes estandarizados para poder ejecutar sus cargas de trabajo, los clientes podían,
sucesivamente,
codificar aplicaciones comerciales sin la necesidad de hardware o software especialisados. Además,
los clientes fueron
libres de migrar a nuevos y más poderosos procesadores sin preocuparse por problemas de
compatibilidad con sus
aplicaciones existentes. La primera ola de aplicaciones comerciales fueron en su mayoría escritas en
COBOL, FORTRAN o PL/1,
y muchos de estos viejos programas todavía están en uso.

En las décadas posteriores a 1960, los mainframes tuvieron un constante crecimiento para alcanzar
enormes capacidades de
procesamiento. Hoy en día los mainframes tienen una habilidad de servicio sin igual para aquellos
usuarios que manejan gran
cantidad de datos (llegando a valores múltiplos de petabytes), y las necesidades de reconfiguración
de recursos de hardware
y software. Todo desde un único punto de control.

P5
A pesar del predominio de los mainframes en el mundo de los negocios, estas máquinas son
invisibles al público
en general, la comunidad académica, y efectivamente a muchos experimentados profesionales de
IT.
En cambio, otras formas de computación atraen más la atención, por lo menos en términos de
visibilidad y conciencia pública.
Esto es algo que no debe sorprendernos, después de todo, quién de nosotros necesita acceso a un
mainframe?
Y, si fuera así, dónde podríamos encontrar uno?
En verdad, nosotros somos todos los usuarios de mainframe, nos demos cuenta o no.

P6
Actualmente, los fabricantes de computadoras no siempre usan el término mainframe. En su lugar,
muchos los llaman computador de uso comercial (grande o pequeño) o server, con el término
mainframe se hace referencia al mayor sever en uso de la actualidad. IBM, por ejemplo, ahora
referencia a sus mainframes como servidores zSeries. Usamos el término mainframe en este
manual para referirse a computadoras que pueden dar servicio a docenas de aplicaciones y
dispositivos de entrada/salida simultáneamente a miles de usuarios.
La presencia de un mainframe a menudo implica una forma centralizada de computación, más que
una forma distribuída. Teniendo los datos centralizados en un único repositorio en el mainframe, le
ahorra al cliente tener que administrar actualizaciones a varias copias de sus datos de negocio, e
incrementa la probabilidad de tener el dato actualizado.

P8
Reliability (Confiabilidad) Implica el uso de componentes de hardware y software
de alta calidad, y componentes de hardware con posibilidad de
auto-chequeo y auto-recuperación.
Availability (Disponibilidad) Es la habilidad del hardware para detectar y reemplazar
automáticamente elementos de hardware que fallen, y sistemas de software
para detectar, aislar y recuperar componentes que fallen.
Serviceability (Servicio) Mediante unidades de reemplazo bien definidas, tanto el hardware
como el software se pueden actualizar o reparar sin cortes (non-disruptive),
con poco o ningún impacto en el sistema.

Un sistema de computación seguro previene a los usuarios del acceso o modificación de

cualquier objeto en el sistema, incluyendo datos de usuario, excepto para el caso de imponer
reglas de autorización provistas por interfaces que vienen con el sistema. Los mainframes pueden
proveer un sistema muy seguro para el proceso de un número muy grande de aplicaciones
heterogéneas que deban acceder a datos críticos.

Por escalabilidad queremos referirnos a la habilidad del hardware, software o un sistema

distribuido,
para funcionar satisfactoriamente aún cambiando su volúmen o tamaño, por ejemplo,la habilidad de
mantener los niveles de rendimiento cuando agregamos procesadores, memoria y almacenamiento.

La necesidad de mantener ejecutando aplicaciones por años impone una estricta compatibilidad del
hardware y software del mainframe, el cual ha sido actualizado varias veces desde el primer sistema
360
instalado en 1964. Las aplicaciones deben seguir trabajando correctamente. De esta manera,
muchos de
los diseños de trabajo para nuevo hardware and software gira alrrededor de esta necesidad de
compatibilidad.

Cada nueva generación de mainframe agregó mejoras en una o más de las siguientes áreas:
Mayor cantidad y más rápidos procesadores
Más memoria física y mayor capacidad de direccionamiento de memoria
Capacidades dinámicas para actualizar hardware y software
Más hardware con capacidades de chequeo y recuperación de errores
Mejores dispositivos de entrada/salida (I/O), mayor cantidad de pasos (canales),
y más rápidos, entre el procesador y los dispositivos de I/O
Conexionado de I/O sofisticado, como adaptadores de LAN
Incrementar la habilidad de dividir los recursos de una máquina en múltiples sistemas,
lógicamente independientes y aislados, cada uno ejecutando su propio sistema operativo

P9
Un trabajo (o job) batch se envía al computador, lee y procesa datos agrupados, y produce una
salida.
Un trabajo batch puede durar horas.
Mientras el procesamiento batch es posible en sistema distribuídos, esto no es tan común
como en mainframes debido a que los sistemas distribuídos carecen de:
Suficiente memoria
Capacidad de procesamiento disponible o ciclos
Administración de recursos y programación de tareas (jobs) en sistemas interconectados (Sysplex)

Los mainframes atienden un vasto número de sistemas de procesamiento de transacciones en línea

(online transaction processing u OLTP). Estas son usualmente aplicaciones críticas, que son las
funciones
principales de las que dependen los negocios. Algunas industrias que usan sistemas en línea:
Bancos – ATMs, sistemas de cajeros para servicio al cliente
Seguros – Sistemas de agencias para el proceso de reclamos y administración de pólizas
Viajes y Transporte – Sistemas de reservas para las aerolíneas
Manufactura – Control de inventario, programación de la producción
Gobierno – Proceso de impuestos, emisión y administración de licencias

P10
Considere los siguientes elementos en el trabajo en el procesamiento batch programado:
A la noche, se procesan muchos jobs batch ejecutando programas y utilitarios. Estos jobs
consolidan los resultados de las transacciones en línea (online) ejecutadas durante el día.
2. Los jobs batch generan reportes de estadísticas de negocio.
3. Se realizan respaldo de archivos críticos y bases de datos, antes y después de la ventana batch.
4. Se envían reportes con las estadísticas de negocio a específicas áreas para su análisis durente el
día siguiente.
5. Se envían a las oficinas sucursales reportes con las excepciones.
6. Mensualmente se generan reportes con los balances de cuentas, y se envían a los clientes
bancarios.
7. Se envían reportes con los resúmenes de procesos a las compañías de tarjetas de crédito
asociadas.
8. Las compañías de tarjetas de crédito envían reportes con las transacciones de las tarjetas de los
clientes.
9. En el departamento de control de producción, el área de operaciones monitorea los mensajes de
la consola
del sistema y la ejecución de los jobs.
10. Jobs y transacciones leen o actualizan las bases de datos (la misma utilizada por transacciones
en línea)
y se graban varios archivos a cinta.

P11
Transacciones en línea comunes usando un mainframe:
Un cliente usa un ATM (cajero automático), que le muestra una interfaz amigable
para varias funciones: retiro, consulta de saldos, depósito, transferencia o delante de dinero desde
su cuenta.
2. En otro lugar, en la misma red probada, un empleado bancario en una sucursal realiza
operaciones como consultoría, aplicaciones de fondos, y órdenes de pago.
3. En la oficina central del banco, analistas de negocio modifican transacciones para mejorar el
desempeño.
Otro personal utiliza sistemas en línea especializados para automatización de la oficina para
realizar administración
de relaciones con clientes, planificación de presupuesto, y control de stock.
4. Todos los pedidos dirigidos al mainframe para procesamiento.
5. Programas que ejecutan en el mainframe realizan actualizaciones y consultas al sistema de
 base de datos (por ejemplo DB2, Oracle, etc).
6.

P12

Administradores de Sistemas realizan más tareas diarias relacionadas con el mantenimiento

de los datos de negocio críticos que residen en el mainframe, mientras que el
Programador de Sistemas se enfoca en el mantenimiento del sistema en si mismo.
Ejemplos de administradores de sistemas incluye a los adminstradores de base de datos y los de
seguridad.

Mientras el conocimiento del programador de sistemas radica principalmente en las áreas de

hardware y
software, los administradores de sistemas tienen más experiencia con las aplicaciones.

El Diseñador de Aplicaciones y el Programador de Aplicación (o desarrollador) diseñan, arman,

prueban y generan aplicaciones para los clientes y usuarios finales de la empresa. Basados en los
requerimientos
reunidos de los analistas y los usuarios finales, el diseñador crea unas especificaciones de diseño
desde las cuales
el programador genera una aplicación. El proceso incluye varias iteraciones, donde se modifican los
códigos y
se compilan, se crea la aplicación y se prueba.

El Operador de Sistema monitorea y controla la operación del mainframe, hardware y software. El

operador arranca
y para tareas del sistema, monitorea consolas del sistema para condiciones inusuales, y trabaja junto
con los
programadores de sistemas y el soporte de control de producción para asegurar la normal operación
de los sistemas.

El Analista de Control de Producción es responsable de asegurar que la carga de trabajo batch

ejecute completa,
sin errores ni demoras.

P13

z/Virtual Machine (z/VM) tiene dos componentes básicos: Un control program (CP) y un sistema
operativo para usuario-único (single-user) o CMS.

Como un programa de control, el z/VM es un hiper-supervisor ya que ejecuta otros sistemas

operativos en la máquinas virtuales que crea. El programa de control crea artificialmente múltiples
máquinas virtuales usando los recursos reales de hardware. El usuario tiene la sensación que tiene
uso dedicado de los recursos reales. Los recursos reales compartidos incluye impresoras, discos y
CPU. El programa de control asegura la seguridad de los datos y las aplicaciones dentro de la
máquina virtual, llamado sistema guest (guest systems). El hardware real se puede compartir entre
los “gests” o dedicarse a un único “guest” por razanes de performance. El segundo componente
importante del z/VM es el CMS o Conversational Monitor System. Este componente del z/VM
ejecuta en una máquina virtual y provee interfaz para un usuario final interactivo, e interfaz de
programación de aplicaciones z/VM.

Comparado con el z/OS, el sistema operativo VSE provee una base menos compleja para
procesamiento batch y de transacciones. La estructura de diseño y de administración del VSE es
excelente para ejecutar cargas de trabajo productivas de múltiples jobs (ejecutando en paralelo), y
procesos de transacciones tradicionales.

Varias distribuciones Linux se pueden ejecutar en un mainframe.

El sistema operativo z/Transaction Processing Facility (z/TPF) es un sistema de propósito especial

utilizado por compañías que necesitan una cantidad muy alta de transacciones, como trajetas de
crédito y sistemas de reservas de aerolíneas. z/TPF se conoció alguna vez con el nombre de Airline
Control Program, fué y sigue siendo usado para las reservas de pasajes de avión, extendiéndose a
otros sistemas de reservas de muy alto volúmen y grandes necesidades de procesamiento.

Capitulo 2

Capitulo 3

P4
El sistema operativo que discutiremos en este curso es el z/OS, el sistema operativo
mainframe más usado. El z/OS está diseñado para ofrecer un ambiente estable, seguro
y de continua disponibilidad para aplicaciones ejecutando en el mainframe.

Para comprender cómo y porqué las funciones del z/OS lo hacen, en importante entender
el ambiente de esas funciones, esas funciones que hacen al z/OS único, reflejan los ambientes
de computación que maneja.

El z/OS realiza su trabajo dividiéndolo en piezas, y dando porciones del job a los distintos
componentes del sistema y subsistemas que trabajan en forma interdependiente. En cualquier
momento, un componente u otro toma el control del procesador, realiza su función,
y luego pasa el control a otro programa de usuario o a otro componente.

P5
El hardware del mainframe consiste de procesadores y múltiples dispositivos periféricos como
discos
(llamados dispositivos de almacenamiento de acceso directo, o direct access storage devices o
DASD ),
unidades de cintas magnéticas (TAPE ), y varios tipos de consolas de usuario. Se usan cintas y
discos
para funciones del sistema y programas de usuario ejecutados por el z/OS.

Aquí no se muestran otros dispositivos, por ejemplo unidades de control de dispositivos, como el
director,
que conecta el mainframe a las unidades de cintas, discos y consolas.

P6
Un grupo de instrucciones relacionadas se la denomina una rutina o módulo. Un conjunto de
módulos que realizan algo en particular se llama componente del sistema.

Una secuencia de instrucciones que realizan funciones del sistema de uso frecuente
Se pueden invocar mediante una macros. Existen macros de z/OS para funciones tales como
abrir y cerrar archivos de datos, carga de programas en memoria, y envío de mensajes al operador.
La “program status word (PSW)” es un área de datos de 64 bits en el procesador, que junto con
registros de control, registros de tiempos y prefijos, proveen datos necesarios para el hardware
y software. Además, la PSW incluye la dirección de la siguiente intrucción del programa e
información de control sobre el programa en ejecución. Cada procesador tiene una sóla PSW
corriente. De esta manera sólo una tarea se puede ejecutar en un procesador por vez.

El z/OS es capaz de multiprogramación (multiprogramming) o ejecutar varios programas

concurrentemente. En multiprogramación, cuando una tarea no usa el procesador, el sistema
la suspende o interrumpe (interrupt), la tarea libera el procesador para que trabaje otra tarea.
El z/OS también puede realizar multiprocesamiento (multiprocessing), que es la operación
simultánea de dos o más procesadores que comparten varios recursos de hardware, como
memoria y discos.

Como las instrucciones ejecutan el trabajo del computador del sistema, mantiene información
sobre este trabajo en áreas de almacenamiento conocidas como control blocks.
Hay tres tipos de bloques de control en z/OS:
Relacionados al sistema
Reñacionados a recursos
Relacionados a tareas

Cada bloque de control del sistema representa un sistema z/OS y contiene información detallada
del sistema, como por ejemplo cuántos procesadores están en uso. Cada bloque de control de
recursos representa por ejemplo un procesador o disco. Cada bloque de control de tarea
representa una unidad de trabajo.

Conceptualmente, los mainframes y todas las otras computadoras tienen dos tipos de
almacenamiento
físico o memoria:
El almacenamiento físico localizado en el propio procesador mainframe. Llamado memoria del
procesador o real
El almacenamiento físico externo al mainframe, incluyendo al almacenamiento en discos y cintas,
llamado auxiliar.

P7
Memoria Virtual significa que cada programa en ejecución puede asumir que tiene acceso a
todo la memoria real definida por el esquema de direccionamiento dada por la arquitectura.
El único límite es el número de bits en la dirección de memoria.

Para permitir a cada usuario actuar de esta manera, suficiente memoria real existe en el computador,
pero el z/OS sólo mantiene porciones activas de cada programa en memoria real. El z/OS mantiene
el resto del código y datos en archivos especiales en almacenamiento (o memoria) auxiliary,
que usualmente consiste en un número de discos de alta velocidad o acceso (DASDs).

Un address space es un área de direcciones virtuales disponibles para la ejecución de instrucciones

y almacenar datos. El rango de direcciones virtuales en un address space comienza en cero y puede
extenderse a la dirección más alta permitida por la arquitectura del sistema operativo.

El z/OS provee a cada usuario con un único address space y mantiene la diferencia entre los
programas y datos pertenecientes a cada address space.

P8
Con el release de los mainframes zSeries en el 2000, IBM extendió el direccionamiento de la
arquitectura a 64 bits. Con estos 64 bits de direccionamiento, el tamaño potencial de un address
space de z/OS expande tanto su tamaño que necesitamos nuevos términos para describirlo.
En cada address space, llamado address space de 64 bits, es de un tamaño de 16 axabytes (EB),
que es un poco más que mil millones de gigabytes. El nuevo address space tiene lógicamente
264 direcciones. Esto es 8 mil millones de veces el tamaño de un address space de 2 GB.
El número es 16 seguido de 18 ceros: 16,000,000,000,000,000,000 bytes, o 16 EB.

Decimos que el tamaño potencial es 16 EB debido a que el z/OS, por default, continúa creando
address spaces de 2 GB. El address space execede este límite sólo si el programa ejecutando
en él asigna (allocate) por arriba de la dirección de 2 GB. Si es así, el sistema operativo z/OS
incrementa la memoria disponible al usuario de 2 GB a 16 EB.

La dirección de 16 MB proviene del punto de divición de dos arquitecturas (direccionamiento de

24 bits con MVS/370 y la de 31 bits introducida en el sistema operativo MVS Extended
Architecture
o MVS/XA), y se la llama usualmente línea (line). El área que separa la memoria virtual por debajo
de la dirección de 2 GB del área privada del usuario se la llama barrera (bar).

P9
Para que un procesador ejecute una instrucción de programa, la instrucción y el dato referenciado
debe estar en memoria real. La convención de los primeros sistemas operativos fue la de tener todo
el programa residente en memoria real cuando sus instrucciones se ejecutan. Sin embargo, no es
necesario que todo el programa esté en memoria real cuando se ejecutan instrucciones. Por el
contrario,
tener piezas del programa en memoria real sólo cuando el procesador esté listo para ejecutarlas,
moviéndolas a memoria auxiliar cuando no sean necesarias, de esta manera un sistema operativo
podría ejecutar más y mayores programas concurrentemente.

El sistema operativo puede dividir un programa en piezas asignadas cada una a un único address
space.
Este arreglo permite que al sistema operativo mantener la pista de esas piezas. En el z/OS las piezas
de programas se llaman páginas (pages)

El z/OS usa tablas para determinar si una página está en memoria real o auxiliar, y dónde.
Para encontrar una página de un programa, el z/OS chequea la tabla por la dirección virtual de la
página,
en lugar de buscar por todos los discos físicos. El z/OS entonces transfiere la página a memoria real
o
enviándola a memoria auxiliar, según sea el caso. El movimiento de páginas entre slots de memoria
auxiliar y frames de memoria real se llama paginado (paging). Paging es clave para entender el uso
de la memoria virtual en z/OS.

Dynamic address translation, o DAT, es el proceso de traducción de una dirección virtual durante
una
referencia de memoria a su correspondiente dirección real.

El almacenamiento físico está dividido en áreas, del mismo tamaño y accesible por una única
dirección.
En memoria real se llama frames, en auxiliar slots.

P10
Una dirección es un identificador de una necesaria parte de información, pero no una descripción
de dónde está en memoria real. Esto permite que el tamaño de un address space (esto es, todas
las direcciones disponibles de un programa) exceda la cantidad de memoria real disponible.

Todas las referencias de memoria real se hacen en términos de direcciones de memoria virtual.

Se usa un mecanismo de hardware para mapear la dirección de memoria virtual a una ubicación
de memoria real. Como se muestra, la dirección virtual 10254000 puede existir más de una vez,
debido a que cada dirección virtual mapea a una dirección diferente en memoria real.

Cuando una dada dirección no está en memoria real, una interrupción de hardware se le indica al
z/OS y el

P12
Aquí se muestra al z/OS realizando el paginado de un programa ejecutando en memoria virtual.
Los boxes con letras representan partes del programa. A simple vista, las partes A, E, F y H del
programa están activas y ejecutando en frames de memoria real, mientras que las partes
B, C, D y G están inactivas y se movieron a slots de memoria auxiliar. Todas las partes del
programa,
sin embargo, residen en memoria virtual y tienen direcciones de memoria virtual

P14
“Working set” es el número de páginas activas de una aplicación. Las páginas inactivas se les hace
“page out”,
dejando las páginas activas en memoria.
Cuando una aplicación entera se mueve a memoria auxiliar se lo llama “swapped out”. Esto
quiere decir que todas las páginas
(incluyendo el working set) se mueven a un data set de swap separado. Cuando los recursos se
liberan, la aplicación es vuelta a memoria.

P17
La dirección de 16 MB proviene del punto de división entre las dos arquitecturas previas
(direccionamiento de 24 bits introducida con el
MVS/370 y el direccionamiento de 31 bits del sistema MVS Extended Architecture o MVS/XA), y
a veces llamado ‘la línea’. El área que
separa al almacenamiento virtual por debajo de la dirección de 2 GB del área del usuario se lo
denomina ‘la barra’.

Con las versiones (o releases) de mainframe zSeries en el 2000, IBM extendió más aún el
direccionamiento de la arquitectura de 64 bits.
Con 64 bits de direccionamiento, el tamaño potencial de un address space se expandió a un valor
tan vasto que necesitamos nuevos
términos para describirlo. Cada address space, llamado de 64 bits, tiene un tamaño de 16 exabytes
(EB); un exabyte es ligeramente
más que un mil millones de gigabytes. El nuevo address space tiene 264 direcciones lógicas. Esto
es 8 mil millones de veces el tamaño
del anterior address space de 2 GB. El número es 16 seguido de 18 ceros:
16,000,000,000,000,000,000 bytes, o 16 EB.

P19
0 to 231 La distribución es la misma.
231 - 232 De 2 GB a 4 GB se considera la barrera. Por debajo de la barrera se puede
 direccionar con una dirección de 31 bits. Por arriba de la barrera requiere
una dirección de 64 bits.
232 - 241 El área baja no compartida (área privada de usuario) comienza en los 4 GB
y se extiende a 241 .
241 - 250 Area compartida (para memoria compartida) comeinza en 241 y se extiende
a 250 o mayor, si es requerido.
250 - 264 Area alta no compartida (área privada del usuario) comienza en 250 o
donde el área compartida termine y llega a 264 .

P21

En un sistema operativo, la administración del almacenamiento involucra la asignación

(allocation),
ubicación , monitoreo, migración, respaldo (backup), recupero (restore) y el borrado de archivos.
Estas actividades se pueden hacer manualmente o mediante el uso de procesos automatizados.
Cuando se automatiza, el sistema determina la ubicación del objeto y automáticamente administra
el
respaldo, movimiento, espacio y seguridad. Un sistema z/OS productivo típico incluye ambos
procesos.

Dependiendo como se configuran el z/OS y sus dispositivos de almacenamiento, un usuario o

programa puede controlar directamente muchos aspectos del uso de almacenamiento, y en los
primeros tiempos de los sistemas operativos, los usuarios debían hacerlo. Ahora se definen
especificaciones de la instalación para datos y administración de recursos, y se agregaron productos
de administración para automatizar el uso del almacenamiento, el principal es el DFSMS, ver
Capítulo 4.

P24
El uso de address spaces en z/OS tiene varias ventajas: Aislación de áreas privadas en
diferentes address spaces provee seguridad de sistema, manteniendo en cada address
space un área común accesible por todos los address spaces.
Asegura la integridad de datos independientemente de la cantidad de usuarios. El z/OS
previene a usuarios el acceso o cambio de cualquier objeto del sistema, incluyendo datos
de usuario, excepto aquellos autorizados mediante reglas manejadas por interfaces del sistema.
El sistema está diseñado para manejar un gran número de jobs batch concurrentemente,
sin necesitar por parte del usuario de administrar en forma externa los problemas del balanceo
de la carga o de integridad.
El diseño de seguridad se extiende a funciones del sistema como así también a un simple archivo.
Permite múltiples subsistemas de comunicación al mismo tiempo, permitiendo la inusual
flexibilidad
en ejecutar diferentes aplicaciones orientadas a comunicaciones (mezcla de prueba, producción y
versiones de vuelta a tras) al mismo tiempo. Por ejemplo, múltiples stacks TCP/IP operativas al
mismo
tiempo, cada una con diferente direcciones IP y dando servicio a distintas aplicaciones.
Provee recupero extensivo, haciendo que los reinicios no planeados del sistema sean muy poco
frecuentes.
Interfaces del sistema permiten programas aplicativos con sus propios niveles de recupero,
normalmente
usado por mayor cantidad de aplicaciones.
Puede manejar cargas de trabajo mixtas, con balance automático de recursos para asegurar los
requerimientos de producción establecidos por el administrador del sistema.
La interfaz del operador es una función crítica del z/OS. Provee información de estado (status),
mensajes ante situaciones de excepción, control del flujo de jobs, control de periféricos, y permite
al operador manejar situaciones de recupero inusuales.

P25
No trataremos de listar todos los programas producto de z/OS (existen cientos), de los más comúnes
incluye:
Un sistema de seguridad
z/OS provee una estructura a los clientes para agregar seguridad mediante el un producto de
administración
de seguridadadd (el productto de IBM es el Resource Access Control Facility o RACF®).
Hay otros productos no IBM disponibles.
Compiladores
z/OS incluye assembler y compilador C. Otros sería el COBOL, ofrecido también por separado.
Facilidades de proceso de transacciones, IBM ofrece varios, incluyendo:
– Customer Information Control System (CICS)
– Information Management System (IMS)
– WebSphere
Un programa de clasificación (Sort)
Una gran variedad de programas utilitarios
Por ejemplo, el System Display and Search Facility (SDSF) que hace más fácil el uso del TSO.
P26
Un producto middleware suele incluir un “application programming interface” (API).

Algunos casos de middleware API’s en mainframe incluye:

El conjunto de productos WebSphere, que provee un API completo que es portable a través de
múltiples sistema operativos.
WebSphere MQ provee APIs cross-platform y mensajería inter-platform.
Producto de administración de base de datos DB2, que provee un API (en lenguaje SQL) usado con
muchas aplicaciones y lenguajes diferentes,
otro sería Oracle.

P28
Un sistema operativo es un conjunto de programas que manejan el trabajo interno de un
computador.

El uso del sistema operativo z/OS de la multiprogramación y multiprocesamiento, junto con la

habilidad
de accesar y administrar cantidades enormes de operaciones de memoria y I/O, lo hace ideal para
cargas
de trabajo en mainframe.

El concepto de memoria virtual es algo central al z/OS. Es una ilusión creada por la arquitectura,
donde
el sistema cree tener más memoria de la que realmente tiene. La memoria virtual se crea mediante el
uso de tablas para mapear las páginas virtuales a páginas reales o slots de memoria auxiliar. Sólo las
porciones necesarias de un programa se cargan en memoria real. El z/OS mantiene las partes del
address space en memoria auxiliar.

Cada usuario de z/OS tiene un address space conteniendo los mismos rangos de direcciones de
memoria.
El uso de address spaces en z/OS permite aislar áreas privadas en diferentes address spaces para
seguridad del sistema, permitiendo compartir programas y datos entre address spaces, mediante
un área común accesible por cada address space.

Programas ejecutando en z/OS y mainframes zSeries pueden ejecutar usando direccionamiento

de 24, 31 o 64 bits (y pueden cambiar entre ellos de ser necesario). Y pueden usar una mezcla
de instrucciones con operandos de distintos bits.

Capitulo 4

P1
Habíamos mencionado que el z/OS es ideal para procesamiento de jobs batch – carga de trabajo
que ejecuta en ‘ background’ con mínima interacción
humana si fuera necesaria. Sin embargo, z/OS es tanto un sistema operativo interactivo como para
procesos batch. Por interactivo significa que usuarios
finales (a veces decenas de miles de usuarios simultáneos, en el caso de z/OS) usando el sistema en
tiempo real mediante la interacción directa,
tales como comandos e interfaces de menúes.
Todo aquel que trabaje con z/OS necesita conocer sus interfaces para usuarios finales.
Principalmente mediante el uso del TSO/E y su interfaz
mediante el uso de menúes, llamada ISPF. Estos programas le permiten conectarse al sistema,
ejecutar programas y trabajar con archivos de datos.
Además, necesita conocer las facilidades interactivas de la implementación en z/OS de interfaces
UNIX, conocidas en conjunto como z/OS UNIX System Services, o “z/OS UNIX”.

P2
z/OS provee un número de facilidades que permite a los usuarios interactuar directamente con el
sistema operativo. Este capítulo provee
una visión general de cada facilidad. Habrá ejercicios prácticos para ayudar a ldesarrollar su
comprensión de estas importantes facilidades.

P3
3270 refiere a un dispositivo terminal o consola, pero a veces este ‘display’ se emula mediante el
programa emulador 3270.
En un archivo z/OS (data set), cada línea de texto se conoce como registro (record) .
TSO es lo que hace interactivo al sistema operativo z/OS (no solo orientado al batch).

P4
z/OS provee un número de facilidades que permite a los usuarios interactuar directamente con el
sistema.
En este módulo veremos brevemente cada una de estas facilidades. Al final trabajaremos con
algunos simples ejercicios
para que el estudiante tenga alguna experiencia práctica con el z/OS

P5
Muchos usuarios de z/OS se refieren al TSO/E simplemente como “TSO,” y es como a veces
aparecerá en este capítulo. También podremos usar
“usuario o user” al referirse a un “usuario final o end user.”

Qué es TSO? Es lo que le permite a los usuarios crear una sesión interactiva con el sistema z/OS.
TSO provee una única capacidad de
conexión (logon) del usuario, y tener una interfaz de comandos con el z/OS.
La mayoría de los usuarios de TSO usan el ISPF. Es una colección de menúes y paneles que
ofrecen un amplio rango de funciones para
asistir a los usuarios para trabajar con archivos del sistema. Dentro de los usuarios de ISPF incluye
a los programadores de sistemas
y aplicaciones, administradores, y otros que acceden al z/OS. Independientemente de la
experiencia de los usuarios, TSO y ISPF hace
más fácil el trabajo de interactuar con el sistema z/OS.

P6
En un sistema z/OS, a cada usuario se le asigna una identificación (userid) y clave (password),
autorizado para conectarse (logon) a TSO.
Requiere una terminal 3270 o, más común, una emulación TN3270 en la PC. El logon tiene el
mismo propósito que un panel de logon de Windows.

P7
El procedimiento de ‘logon’ dispone (allocate) los data sets que necesita el usuario, los recursos
que puede acceder (via RACF, programa de seguridad en z/OS),
el tamaño de memoria (region) para su address space.

Se usa la opción ‘reconnect’ si se perdió la conexión, en ese caso ingresar una S.

Note las teclas clave ( PF Keys). Su uso simplifica mucho la tarea del usuario, asignando distintos
valores a cada una de la PF dependiendo de las necesidades.
Más adelante veremos las definiciones usadas para este curso.

P8
Muchas instalaciones prefieren tener sesiones de usuarios de TSO que automáticamente usen la
interfaz ISPF después del ‘logon’.
Discutiremos el conjunto disponible de comandos básicos de TSO, independientes de otros
programas complementarios, como el ISPF.

P11
El ‘READY prompt’ acepta comandos de línea de TSO como por ejemplo HELP, RENAME,
ALLOCATE y CALL.

P14
Con TSO nativo, se puede agrupar un conjunto de comandos en un archivo, llamado un ‘command
list o CLIST’, y ejecutarlo como si fuera
un solo comando. Cuando se invoque un CLIST, éste emite los comandos TSO/E en secuencia.
Se utilizan CLISTs para realizar tareas rutinarias, hacen más eficiente el trabajo del usuario con el
TSO.

Los usuarios de TSO crean CLISTs con el lenguaje de comandos CLIST. Otro lenguaje de
comandos usado con TSO se llama Restructured Extended Executor o REXX .

P16
Otro lenguaje de comandos usado con TSO se llama Restructured Extended Executor o REXX .
Ambos, CLIST y REXX ofrecen procesamiento
tipo shell script. Estos son lenguajes interpretativos , en oposición a los lenguajes compilados
(aunque los REXX también se pueden compilar).

Algunos usuarios de TSO escriben funciones directamente como CLIST o programas REXX, pero
es más común verlos implementados como
funciones ISPF, o por otros programas producto. La programación CLIST es única para z/OS,
mientras que REXX se utiliza en otras plataformas.

P19
Después de conectarse a TSO (logon), típicamente los usuarios acceden al menú ISPF. En efecto,
muchos usan exclusivamente ISPF para
realizar sus tareas en z/OS. ISPF es una aplicación mediante paneles que se navegan mediante el
teclado.

P21
Como se puede ver, ISPF tiene una estructura tipo árbol.

El menú primario de opciones está en la cima del árbol. Este panel lo puede modificar el system
programmer con opciones adicionales.
De esta manera, puede variar en características y contenido de instalación a instalación.

P21
Opción cero (0) permite modificar las definiciones o seteos del ISPF. Por ejemplo, la línea de
ingreso de comandos puede aparecer al final
de la pantalla de la sesión de ISPF, mientras que el instructor puede usarlo al tope. Esta es una
preferencia personal, usualmense se ubica el tope del panel.
Si quiere que aparezca al tope, haga lo siguiente:
Vaya al menú de la opción primaria de ISPF.
Seleccione opción 0 para ver menú Settings.
En la lista Options, remueva la barra “/” en la línea que dice “Command line at bottom”.

P22
Opción cero (0) permite modificar las definiciones o seteos del ISPF. Por ejemplo, la línea de
ingreso de comandos puede aparecer al final
de la pantalla de la sesión de ISPF, mientras que el instructor puede usarlo al tope. Esta es una
preferencia personal, usualmense se ubica el tope del panel.
Si quiere que aparezca al tope, haga lo siguiente:
Vaya al menú de la opción primaria de ISPF.
Seleccione opción 0 para ver menú Settings.
En la lista Options, remueva la barra “/” en la línea que dice “Command line at bottom”.

P24
Muchos de los paneles en los ejemplos usados en este curso muestran los valores de las teclas de
función (PF) al final del panel.
Es normal que cada instalación utilice los valores que más se adecúan a sus necesidades.

Aquí se muestran algunos de los valores de PF más usados, con su correspondiente clave.
P34
Desde el ISPF se puede ver el contenido de un data set (v para ver o view) o editarlo (e o edit).

Cuando se edita un data set, se usan comandos de línea para trabajar con el contenido del archivo,
como se ve aquí.
Por ejemplo:
Para editar el contenido del data set, mover el cursor al área del registro a ser modificado y escriba
sobre el texto existente.
Para encontrar o cambiar texto, debe ingresar el comando en la línea de comandos del editor.
Para agregar (insert), copiar (copy), borrar (delete), o mover (move) texto, ingrese estos comandos
directamente en la línea de
números en el lugar donde la acción deba ocurrir.

Para confirmar sus cambios, use PF3 o save. Para salir de la edición del data set sin guardar los
cambios, entre Cancel en la línea de comandos.

P35
Desde el ISPF se puede ver el contenido de un data set (v para ver o view) o editarlo (e o edit).

Cuando se edita un data set, se usan comandos de línea para trabajar con el contenido del archivo,
como se ve aquí.
Por ejemplo:
Para editar el contenido del data set, mover el cursor al área del registro a ser modificado y escriba
sobre el texto existente.
Para encontrar o cambiar texto, debe ingresar el comando en la línea de comandos del editor.
Para agregar (insert), copiar (copy), borrar (delete), o mover (move) texto, ingrese estos comandos
directamente en la línea de
números en el lugar donde la acción deba ocurrir.

Para confirmar sus cambios, use PF3 o save. Para salir de la edición del data set sin guardar los
cambios, entre Cancel en la línea de comandos.

P36
Aquí se muestra el contenido de un data set abierto en modo edición. El hecho de ingresar I5 es
para insertar 5 líneas en blanco después del primer registro.

Note la línea de números, el área de texto y la línea de comandos. Los comandos de línea se
escriben en la línea de números, y hay tres formas distintas
para modificar en contenido de un data set. Los números de línea se incrementan de a 10 con el
editor ISPF, y el usuario puede insertar nueve líneas más
entre cada una de las actuales, sin tener que renumerar via programa.

P47

El shell de z/OS UNIX está basado en el shell UNIX System V, y tiene algunas características del
shell UNIX Korn.

El POSIX standard distingue entre un comando, que lo direcciona al shell para realizar una tarea
específica, y un utilitario,
que es el nombre del programa por dentro del shell. Para el usuario no hay diferencia entre un
comando y un utilitario.

El shell z/OS UNIX provee el ambiente que tiene la mayoría de las funciones y capacidades. Se
pueden combinar comandos Shell
fácilmente en pipes o shell scripts, y de este modo convierte a nuevas funciones más poderosas.
Una secuencia de comandos shell se puede almacenar en un archivo de texto que puede ser
ejecutado. A esto se lo denomina
una shell script. El shell soporta varios de los features de un lenguaje tradicional de programación.

P52
OMVS para comandos de línea, ISHELL para menúes tipo ISPF. Los comandos TSO usados con
z/OS UNIX son: ISHELL y OMVS.

El comando ISHELL invoca el shell ISPF. ISHELL es un buen punto de partida para usuarios
familiarizados con TSO e ISPF que quieren
o necesitan usar en z/OS UNIX. ISHELL provee paneles donde los usuarios pueden trabajar con el
hierarchical file system.
También hay paneles para montaye (mounting) y desmontaje (unmounting) de file systems y
realizar alguna administración de z/OS UNIX.

El comando OMVS se usa para invocar el shell z/OS UNIX.

P56
Los comandos Shell suelen tener opciones (también llamados flags) que se pueden especificar, y
que usualmente tienen un argumento,
como el nombre del archivo o el directorio. El formato para especificar el comando comienza con
un nombre de comando, luego la/s opcion/es,
y finalmente el argumento, si lo hubiera.

Por ejemplo, en el siguiente comando: ls -al /u/rogers

ls es el nombre del comando, y -al son las opciones.

Este comando lista los archivos y directorios del usuario. Si el ‘pathname’ es un archivo, ls muestra
información en el archivo de acuerdo
a las opciones requeridas. Si es un directorio, ls muestra información en los archivos y
subdirectorios. Se puede pedir información de
un directorio en sí mismo usando la opción -d.

Si no se especifica ninguna opción, ls muestra sólo los nombres de los archivos. Cuando ls envía la
salida a un ‘pipe’ o archivo,
graba un nombre por línea; cuando envía la salida a la terminal, usa el formato -C (multi-column).

P61
Hay algunas diferencias entre el soporte de terminales asincrónicas (logon directo al shell) y el
soporte de una terminal 3270 (comando OMVS):

No puede hacer switch a TSO/E. Sin embargo, puede usar el comando TSO SHELL para ejecutar
un comando de TSO/E desde su sesión shell.
No puede usar el editor de ISPF (esto incluye el comando oedit, que invoca al editor ISPF).

Capitulo 5

P9
Para usar un data set, primero hay que alocarlo (o establecer una conexión con este), luego acceder
a los datos usando
macros para el método de acceso que se haya elegido.

La allocation de un data set significa alguna o ambas de las siguientes definiciones:

Crear el espacio para un nuevo data set en un disco.
Establecer una conexión lógica entre el job step y algún data set .

P10
Podemos especificar el espacio requerido en bloques (blocks), registros (records), pistas (tracks) , o
cilindros (cylinders).
Cuando creamos un data set en DASD, especificamos una cantidad de espacio necesario en forma
explicita (usando el
parámetro SPACE), o implícitamente (por el uso de la información disponible en la Data Class).

El sistema puede usar un data class si el SMS esta activo, incluso si los data set no están bajo SMS.
Para el sistema de manejo de data sets, el sistema selecciona los volúmenes, ahorrándonos de
tener que especificar el volumen cuando alocamos un data set.

Si especificamos la cantidad de espacio por el promedio de longitud de registro, la alocación

de espacio es independiente del tipo de dispositivo. La independencia de dispositivos es
especialmente
importante para el sistema de manejo de almacenamiento.

Un registro lógico (LRECL) es una unidad de información sobre una unidad de procesamiento (por
ejemplo, un cliente, una cuenta, una nómina de pago de empleados, etc). Esta es la mínima cantidad
de datos a ser procesada, y esto abarca los campos que contengan información reconocida por el
procesamiento de la aplicación.

Cuando los registros lógicos esta localizados en DASD, cintas, o dispositivos ópticos, estos están
agrupados
en registros físicos llamados bloque (BLKSIZE). Cada bloque de datos sobre un volumen DASD
tiene una localización
diferente y una dirección (address), así permite encontrar un bloque sin hacer una búsqueda extensa.
Los registros lógicos se pueden almacenar y recuperar directamente o secuencialmente.

La longitud máxima de un registro lógico (logical record - LRECL) está limitada por el tamaño
físico del
dispositivo usado.

El espacio para datos en disco es asignado en extents. Un extent es un numero contiguo de pistas
(tracks)
o cilindros (cylinders). Los data sets se pueden incrementar usando las extensiones. Los tipos de
data sets
mas viejos pueden tener hasta 16 extensiones por volumen. Los tipos de data sets más nuevos
pueden
tener de 128 a 255 extensiones.

En z/OS, la organización para un data sets basado en extensiones se usa para maximizar el
rendimiento
del disco. Las lectura y escrituras de pistas (tracks) contiguas es más rápido que leer o escribir pistas
dispersas sobre el disco, como podría ser cuando las pistas son asignadas en forma dinámica.

P11
El data set z/OS tradicional está orientado al registro. Usualmente no hay archivos grupos de bytes
como encontramos en sistemas PC y UNIX.
Estos no se consideran data sets tradicionales.

En z/OS, no hay caracteres para una nueva línea (NL) o que denoten el fin de un registro (CR+LF).
Los registros son de longitud fija o variable en un dado data set.
Cuando editamos con ISPF cada línea es un registro.

Los data sets tradicionales de z/OS son uno de cinco formatos posibles, que se muestran en la
imágen. Haremos énfasis en las diferencias entre
un bloque y un registro. En esta discusión, un bloque es lo que grabamos en disco, mientras que un
registro es una entidad lógica del programa en ejecución.

F – Fijo Esto implica que un bloque físico en disco es un registro lógico, y todos los
bloques/registros tienen el mismo tamaño. Este formato rara vez se usa.

FB – Fijo Bloqueado Quiere decir que varios registros lógicos se combinan en un bloque físico.
Esto provee uso eficiente del espacio y de la operación.
Se usa para registros de longitud fija.

V – Variable Este formato tiene un registro lógico como un bloque físico. La aplicación debe
insertar un campo de cuatro dígitos al comienzo del registro, Record Descriptor
Word (RDW). El RDW contiene la longitud del registro más los cuatro bytes para el propio RDW:
Se usa poco.

VB – Variable Bloqueado Aquí se ubican varios registros lógicos de longitud variable (cada uno
con un RDW) en un bloque físico. El software debe colocar un campo adicional, al comienzo del
bloque, Block Descriptor Word (BDW), con la longitud total del bloque.

U – Indefinido (Undefined) Consiste de registros/bloques físicos de longitud variable sin estructura

predeterminada. Aunque este formato puede aparecer atractivo para varias aplicaciones inusuales,
normalmente sólo lo usan módulos ejecutables.

P12
La más simple estructura en un sistema z/OS es un data set secuencial. Consiste de uno o más
registros que se almacenan en orden físico y procesados en secuencia. Nuevos registros se agregan
al final del data set.

Un ejemplo de un data set secuencial podría ser un data set de salida para una impresora de línea o
un lote de tarjetas perforadas.

Un usuario z/OS define data sets secuenciales a través de job control language (JCL) con una
organización de data set PS (DSORG=PS), que se colocan en secuencia física. En otras palabras, los
registros en el data set se ordenan uno después del otro.

Un data set particionado agrega un nivel de organización a la simple estructura de data sets
secuenciales. Un PDS es una colección de data sets secuenciales, llamados miembros. Cada
miembro es como un data set secuencial y tiene un nombre simple, que puede ser de hasta ocho
caracteres de longitud.

Un PDS también contiene un directorio. El directorio contiene una entrada para cada miembro en el
PDS con una referencia (o apuntador) al miembro. Los nombres de los miembros están en el
directorio en orden alfabético, aunque aparezcan en cualquier orden dentro de la librería. El
directorio permite al sistema recuperar un miembro determinado en el data set.

Un data set particionado usualmente se lo llama librería.

Un PDSE es un data set particionado extendido. Consiste de un directorio y cero o más miembros,
como un PDS. Y como éstos, se pueden crear mediante JCL, TSO/E o ISPF. PDSE se almacenan
sólo en discos, no en cintas.

P14
Un data set PDS ofrece una forma simple y eficiente para organizar grupos relacionados de archivos
secuenciales. Un PDS tiene las siguientes ventajas para los usuarios z/OS:
Agrupación de data sets relacionados bajo un único nombre hace una administración de datos más
fácil en z/OS. Archivos almacenados como miembros de un PDS pueden ser procesados ya sea en
forma individual o todos los miembros como una sola unidad.
Debido a que el espacio asignado para data sets en z/OS siempre empiezan en límites de pistas
(tracks) en disco, usando un PDS es la forma de almacenar más de un pequeño data set en una pista.
Esto ahorra espacio en disco si se tienen muchos data sets chicos. Una pista en un dispositivo de
disco tipo 3390 tiene un tamaño de 56.6664 bytes.
Miembros de un PDS se pueden usar como data sets secuenciales, y pueden añadirse (o
concatenarse) a data sets secuenciales.
Múltiples data sets PDS se pueden concatenar para formar grandes librerías.
Los PDS son fáciles de crear con JCL o ISPF, y fáciles de manipular con utilitarios de ISPF o
comandos de TSO.

Sin embargo, algunos aspectos del diseño del PDS afectan la performance y el uso eficiente del
disco, como los siguientes:
Desperdicio de Espacio. Cuando un miembro en un PDS se reemplaza, la nueva área de datos se
graba a una nueva sección dentro del espacio alocado al PDS. Cuando un miembro es borrado, su
apuntador también se borra, no hay mecanismo para reusar su espacio.
Tamaño Limitado de Directorio. El tamaño del directorio del PDS se establece al momento de
alocación. A medida que el data set crece, va adquiriendo más espacio en unidades especificadas
como espacio secundario. Estas unidades extra se llaman extensiones secundarias (secondary
extents).

Sin embargo, sólo se puede almacenar un número fijo de entradas de miembros en el directorio del
PDS debido a que su tamaño es fijo, cuando se aloca en data set. Si necesita agregar más entradas
que las pueden caber, se debe alocar un nuevo PDS con más bloques de directorio y copiar los
miembros desde el viejo data set al nuevo.

Búsquedas prolongadas de directorio. Las entradas se buscan en forma secuencial en orden

alfabético. Si el directorio es muy grande y los miembros pequeños, esto podría hacer que la
búsqueda en el directorio más larga que la recuperación del miembro cuando se lo encuentra.

En muchas formas, un PDSE es similar a un PDS. Cada nombre de miembro puede ser de ocho
bytes de longitud. Sin embargo, los PDSE tienen un formato interno diferente, que les da un
incremento en su uso. Puede usar un PDSE en lugar de un PDS para grabar datos o programas en
formato de objetos (program object). Éste es similar a un módulo de carga en un PDS. Un módulo
de carga no puede residir en un PDSE. Un PDSE no puede contener una mezcla de objetos y datos.

La principal ventaja del uso de un PDSE por sobre un PDS es que el PDSE automáticamente reusa
el espacio entre data set sin la necesidad de reorganizarlo periódicamente.

Además, el tamaño del directorio de un PDSE es flexible y se expande para almacenar más
miembros. El sistema reclama el espacio automáticamente cuando un miembro se borra o
reemplaza, y devuelve ese espacio a un pool disponible para alocación de otros miembros del
mismo PDSE. Esto se hace sin hacer ningún compress de IEBCOPY.
P15

Un data set es una colección de datos relacionados lógicamente; puede tratarse de un programa
fuente, una librería de programas o un archivo de datos usado por un programa en ejecución. Los
registros de datos son la unidad básica de información usada por el programa en ejecución.

Los data sets en z/OS son alocados en extensiones contiguas en disco para mejorar la performance.
Los usuarios deben definir la cantidad de espacio a ser alocado para un data set (antes de usarlo).
Un data set puede ocupar más de una extensión y se puede extender automáticamente.

Casi todos los procesos de datos en z/OS son ‘orientado a registro’. No hay archivos de grupo de
datos presentes en el procesamiento tradicional, aunque hay una parte estándar del z/OS UNIX. Los
registros de z/OS (y los bloques físicos) tienen uno de varios formatos específicos. La mayoría de
los data sets tienen atributos DCB que incluyen el formato delregistro (RECFM: F, FB, V, VB o U),
el tamaño máximo del registro lógico (LRECL) y el tamaño máximo de bloque (BLKSIZE).

Cuando un miembro en un PDS se reemplaza, la nueva área de datos se graba a una nueva sección
dentro del espacio alocado al PDS. Cuando un miembro se borra, su apuntador (pointer) se borra
también, pero no hay mecanismo para reusar el espacio. Este desperdicio de espacio debe
removerse periódicamente reorganizando el PDS, por ejemplo usando el utilitario IEBCOPY para
comprimirlo.

P19
Un data set puede tener un solo segmento de nombre o una serie de segmentos unidos. Cada
segmento de nombre representa un nivel de calificación.
Por ejemplo, el nombre del data set VERA.LUZ.DATA está compuesto por tres segmentos. El
primero a la izquierda se lo llama mayor nivel (HLQ)
y el último de la derecha de menor nivel (LLQ).

P23

El registro 1 de la primera pista (track) del primer cilindro (cylinder) provee el rótulo (label) del
disco. Contiene los 6 caracteres del número de serie del volumen (volser) y un apuntador a la tabla
de contenido del volumen (Volume Table Of Contents (VTOC), que puede estar ubicada en
cualquier lugar del disco.

La VTOC contiene la lista de los data sets que residen en el volumen, junto con información sobre
la ubicación y tamaño de cada data set, y otros atributos del data set. Un utilitario estándar del
z/OS, el ICKDSF, se usa para crear el rótulo y la VTOC.

Cuando un volumen de disco se inicializa con ICKDSF, el dueño (owner) puede especificar la
ubicación y tamaño de la VTOC. El tamaño puede ser muy variable, en un rango desde unas pocas
pistas hasta 100 pistas (tracks), dependiendo del uso que se va a dar al volumen. Más data sets en el
disco necesitarán de más espacio en la VTOC.

La VTOC además tiene entradas para todo el espacio libre en el volumen. Cuando se asigna
(allocate) espacio para un data set, esto causa que rutinas del sistema examinen los registros de
espacio libre, los actualizan, y crean una nueva entrada en la VTOC. Los data sets siempre tienen
un número entero de pistas (tracks) o cilindros, y comienzan al comienzo de una pista o cilindro.

P24
Un catálogo describe los atributos de un data set e indica el volumen o los volúmenes (si esta
particionado en varios) donde se encuentra . Los data sets pueden ser catalogados, descatalogados,
o recatalogados. Todos los data sets en disco (DASD) se pueden catalogar automáticamente en un
catálogo. Catalogar data sets en cinta no es necesario pero usualmente simplifica el trabajo del
usuario.

En z/OS el catálogo maestro y los catálogos de usuario almacenan la ubicación de los data sets por
nombre. Esto significa que los nombres de data set debe ser único. Se pueden catalogar data sets en
disco o cinta.

Para encontrar un data set que usted requiere, el z/OS debe conocer tres datos importantes:
Nombre del data set
Nombre del volumen
Unidad (tipo de dispositivo, como por ejemplo disco 3390 o cinta 3590)

Usted puede especificar estos tres valores en paneles del ISPF o en su JCL. Sin embargo, la unidad
de dispositivo y volumen usualmente no son tan relevantes para el usuario final o programa de
aplicación.

P25
Un sistema z/OS siempre tiene por lo menos un catalogo maestro. Si tiene sólo un único catálogo,
éste es el catálogo maestro y todas las entradas para todos los data sets deben estar almacenadas en
él. Este no es muy eficiente ni flexible, típicamente el sistema z/OS usa un catálogo maestro y
varios catálogos de usuario conectados a él, como se muestra en el gráfico.

Un catálogo de usuario almacena el nombre y ubicación de un data set (dsn/volumen/unidad). El

catálogo maestro suele guardar sólo el calificado de mayor nivel (HLQ) con el nombre del catálogo
de usuario, el cual contiene todos los datos de los data sets con prefijo igual a ese HLQ, llamado
alias.

En el gráfico, el nombre de data set del catálogo maestro es SYSTEM.MASTER.CATALOG. Este

guarda los nombres y ubicaciones de todos los data sets con un prefijo SYS1 como por ejemplo
SYS1.A1. Dos entradas HLQ (alias) se definieron en el catálogo maestro.

Cuando SYS1.A1 es requerido, el catálogo maestro devuelve la información de ubicación, volumen

(WRK001) y unidad (3390). Cuando se necesite usar IBMUSER.A1, el catálogo maestro
redirecciona el pedido al catálogo de usuario USERCAT.IBM, y éste devuelve la información.

P32
En un sistema z/OS, manejo de datos involucra asignación (allocation), ubicación, monitoreo,
migración, respaldo (backup), recall, recupero y borrado. Estas actividades se pueden hacer
manualmente o mediante el uso de procesos automáticos. Cuando la administración de datos se
automatiza, el sistema operativo determina dónde ubicar el objeto, y automáticamente maneja el
backup, movimiento, espacio y seguridad del objeto. Un sistema típico de producción de z/OS
incluye procesos manuales y automáticos para manejo de data sets.

Administración de datos incluye las siguientes tareas principales:

Asignar (allocate) espacio en volúmenes de disco (DASD)
Recupero automático de data sets catalogados por su nombre
Montaje de volúmenes de cinta magnéticas en la unidad
Establecer una conexión lógica entre el programa de aplicación y el medio magnético
Controlar el acceso a los datos
Transferir datos entre programa de aplicación y el medio magnético
El DFSMS realiza las funciones esenciales del sistema para datos, almacenamiento (storage),
programa y manejo de dispositivos. Es un conjunto de productos, uno de ellos es el DFSMSdfp,
necesario para la ejecución del z/OS. DFSMS junto con los productos de hardware y definiciones
específicas de cada instalación sobre datos y manejo de recursos, proveen almacenamiento
administrado por el sistema en un ambiente z/OS:

El corazón del DFSMS es el Storage Management Subsystem (SMS). Usando SMS, el programador
de sistema o el administrador de almacenamiento, definen políticas que automatizan la
administración de storage y dispositivos de hardware. Estas políticas describen características de
asignación de datos , objetivos de performance y disponibilidad, requerimientos de backup y
retención, y requerimientos de storage para el sistema. SMS gobierna estas políticas el sistema y el
Interactive Storage Management Facility (ISMF) provee las interfaces para las definiciones y
mantenimiento de las políticas.

Los data sets asignados (allocate) a través del SMS se denominan data sets manejados por el
sistema o por el SMS.

P34
El término Virtual Storage Access Method (VSAM) aplica tanto a tipos de data sets como al
método de acceso para administrar distintos tipos de datos.

Como método de acceso, VSAM provee funciones mucho más complejas que otros métodos
de acceso a disco. VSAM mantiene los registros en disco en un formato único que
no es entendido por otros métodos de acceso.

VSAM principalmente es para aplicaciones. No se usa para programas fuente, JCL, o módulos
ejecutables. Los archivos VSAM no se pueden editar. Se puede usar VSAM para reorganizar
registros en cuatro tipos de data sets: key-sequenced, entry-sequenced, linear, o relative record.
La diferencia básica entre estos tipos de data sets es la forma como los registros se almacenan y
acceden.

P36

VSAM trabaja con un área lógica de datos llamada Control Interval (CI) que aparece en el
diagrama.
El tamaño default del CI es 4KB, pero puede llegar hasta 32KB. El CI contiene datos, espacio no
usado,
y campos de control, Record Descriptor Fields (RDF) y CI Descriptor Field.

Un control interval puede ser construído desde pequeños bloques en disco, pero este nivel de
detalle
es interno al VSAM. Múltiples control intervals su agrupan en una Control Area (CA). Un data set
VSAM
consiste de áreas de control y registros índice. Una forma de registro índice es el sequence set,
que es el nivel de índices más bajo, que apunta a los control intervals.

El uso típico del VSAM le permite a una aplicación la inserción de nuevos registros en un data set.

P43
z/OS UNIX System Services (z/OS UNIX) permite al z/OS acceder a archivos UNIX. Aplicaciones
UNIX también pueden acceder a data sets z/OS. Se pueden usar hierarchical file system (HFS),
z/OS Network File System (z/OS NFS), zSeries File System (zFS), y temporary file system (TFS)
con z/OS UNIX.

Un file system de z/OS UNIX es jerárquico y byte-oriented. Encontrar un archivo en un file system
mediante la búsqueda de un directorio o conjunto de directorios (ver siguiente diapositiva).
No hay directorios z/OS que apunten directamente a un archivo.

P45
Un nombre de paso (path) identifica un archivo y consiste de nombres de directorio y nombre de
archivo.
Un nombre de archivo que use todos los calificadores, que consiste del nombre de cada directorio
en el
path a un archivo mas el nombre del archivo propiamente dicho, puede llegar a 1023 bytes de
longitud.
El HFS permite nombres de archivos (file name) en un mix posible de mayúsculas y minúsculas.

El nombre de paso se construye con nombres individuales de directorio y un nombre de archivo

separado
por una barra, por ejemplo:
/dir1/dir2/dir3/myfile

Como UNIX, el z/OS UNIX es sensitivo a mayúsculas y minúsculas para nombres de archivos y
directorios.
Por ejemplo, en el mismo directorio del archivo MYFILE es diferente al archivo myfile.

Los archivos en el HFS son secuenciales, y se acceden como byte streams. El concepto de registro
no existe
con estos archivos mas que la estructura definida por la aplicación.

El data set hierarchical file system (HFS) es un tipo de data set z/OS.

Data sets HFS y de z/OS pueden residir en el mismo volume en disco.

Capitulo 6

P4
Los detalles del JCL pueden ser complicados, pero los conceptos básicos son muy
simples. Además, un conjunto pequeño de
sentencias de control (JCL) son suficientes en casi el 90% de los casos.
Este capítulo discute algunas seleccionadas opciones de JCL.

Mientras los programadores de aplicaciones necesitan algún conocimiento de JCL, el

analista responsable del control de la
producción debe ser muy competente con el JCL, para su creación, monitoreo,
corrección y re-ejecución de la carga de trabajo
batch diaria de la compañía.

P5
Hay tres sentencias de control básicas:
JOB Provee un nombre para esta carga batch. Opcionalmente puede incluir
información de contabilidad y otros pocos parámetros para el job.

EXEC Provee el nombre del programa a ser ejecutado. Pueden haber varias
sentencias EXEC en un job, mínimo una.
Cada sentencia EXEC dentro del job se denomina paso de job (job step) .

DD La Definición de Datos provee entrada y salida para ejecución del

programa identificado en la EXEC. Esta sentencia identifica un data set,
un dispositivo de I/O o una función a una DDNAME codificada dentro del programa. Las
sentencias DD se asocian con un paso de job particular.

P6
En el Capítulo 3, “TSO/E, ISPF, y UNIX: Facilidades Interactivas de z/OS” , ejecutamos
la misma rutina desde un panel de TSO READY.
Cada sentencia DD de JCL es equivalente al comando de TSO ALLOCATE. Ambos se
usan asociados a un data set z/OS con un “ddname”,
el cual es reconocido por el programa como entrada o salida.
La diferencia en el método de ejecución es que TSO ejecuta el sort en foreground
mientras que el JCL se usa para ejecución en background (o batch) .

P7
Cuando se envía para ejecución:
MYJOB Es un nombre de job que el sistema asocia con esta carga.
MYSORT Es el nombre de paso, que instruye al sistema a ejecutar el programa SORT.
SORTIN En la sentencia DD, es la “ddname”. La ddname SORTIN se codifica en el
programa SORT como una entrada de programa.
El nombre de data set (DSN) en esta sentencia DD es ZPROF.AREA.CODES. El data set puede ser
compartido (DISP=SHR) con otros
procesos en el sistema. El contenido de datos del data set ZPROF.AREA.CODES es la entrada al
programa SORT.
SORTOUT Esta ddname es la salida del programa SORT.
SYSOUT SYSOUT=* especifica que los mensajes de salida del sistema deben ser enviados
al área de salida de impresión del
Job Entry Subsystem (JES). Se puede también enviar la salida a un data set.
SYSIN DD * es otra sentencia de entrada. Especifica que lo que sigue a continuación
son datos o sentencias de control. En este caso,
son las instrucciones de clasificación para el programa SORT, donde los campos de los registros de datos
de SORTIN van a ser ordenados.

Usamos el término sentencia de JCL en este texto; algunos usuarios de z/OS usan también tarjeta
de JCL, aunque el JCL resida en una librería en disco.

P8
Ejemplo:
//MIRIAM2 JOB 19,NOTIFY=&SYSUID,REGION=6M

La sentencia de JCL JOB ‘//MIRIAM2 JOB 19’ es una tarjeta JOB con nombre MIRIAM2.
El 19 es un campo de contabilidad de la tarjeta JOB
que puede estar sujeta a la verificación por parte de rutinas exits del sistema, éstas
pueden usarse para hacer una imputación de costos a los usuarios del
sistema.
Similares operandos de la tarjeta JOB que pueden incluirse:

REGION= Valor de recurso específico de memoria solicitado para este job

NOTIFY= Mensaje que puede enviarse a un usuario de TSO cuando termina
el job
USER= El Job asumirá la autoridad del usuario de TSO especificado aquí
TYPRUN= Se puede enviar un job retenido (en HOLD), y liberarlo más tarde
CLASS= Identifica una cola específica de entrada de jobs, definida por la
instalación
MSGCLASS= Direcciona la salida del job a una cola específica de salida, definida por
la instalación
MSGLEVEL= Controla la cantidad de mensajes del sistema a generar

P9
Ejemplo:
//MYSTEP EXEC PGM=SORT

La sentencia de JCL EXEC ‘//MYSTEP EXEC’ tiene un nombre de paso (stepname) MYSTEP. Siguiendo
la EXEC se codifica
ya sea PGM=(nombre de programa ejecutable) o un nombre de PROC (procedimiento).
Cuando está presente un PROC, los operandos podrían tener las sustituciones de variables necesarios
pare ese mismo PROC.
Los operandos que podemos encontrar en la sentencia EXEC PGM= son:

PARM= Parámetros conocidos por y pasados al programa.

COND= Lógica de Boole para controlar la ejecución de otros pasos de EXEC en el mismo
job.... IF, THEN, ELSE, son
sentencias de JCL existentes superiores cuando uso COND, sin embargo, puede haber viejos JCL’s en
ambiente productivo usando esta sentencia.
TIME= Limita el tiempo de ejecución del paso.

P10
La sentencia de JCL DD //MYDATA DD tiene un ddname de MYDATA.

DD, la sentencia de Definición de Datos, tiene una cantidad significativamente mayor de operandos que las sentencias JOB o EXEC.
La sentencia de JCL DD puede estar involucrada con muchos aspectos de la definición, o describiendo atributos de la entrada y
salida
de datos de programas.

Algunos de los operandos más usados son:

DSN= Nombre del data set; puede incluir data sets nuevos, temporarios, o referenciar un data set
anteriormente usado en el mismo job.
DISP= Disposición del data set en el momento del comienzo del paso (new, shr, old, mod), a la finalización
del paso (catlg, keep, delete, pass) y si el paso termina en forma anormal o abend (catlg, keep, delete, pass).
SPACE= Cantidad de espacio en disco solicitada para un nuevo data set.
SYSOUT= Define un dispositivo tipo impresora (cola de salida, o un data set).
VOL=SER= Nombre de un Volumen, residente en disco o cinta.
UNIT= Disco del sistema, cinta, dispositivo especial, o esotérico (nombre local).
DEST= Rutea salida a destino remoto.
DCB= Data set control block, varios sub-operandos.
Sub-operandos más comunes de DCB:
LRECL= Longitud del registro lógico. Cantidad de bytes o caracteres en cada registro.
RECFM= Formato del registro: fijo, blockeado, variable, etc.
BLOCKSIZE= Tamaño de bloque, típicamente un múltiplo de LRECL. Un valor de 0 le dirá al sistema que estime el mejor valor.
DSORG= Organización del data set: secuencial, particionado, etc.
LABEL= Rótulo de cinta (No Label o Standard Label, seguido por la ubicación del data set).
Una cinta puede almacenar múltiples data sets, cada data set en la cinta está en una
posición. El primer data set en la cinta es el archivo (file) 1.

DUMMY Resulta en un entrada nula o descartar los registros grabados en este ddname.
* Datos de entrada o sentencias de control, un método de pasar datos a un programa
desde el JCL.
*,DLM= Todo lo que sigue es dato de entrada (aún //) hasta que dos caracteres alfanuméricos o especiales se
hayan codificado en columnas 1.

P12
Todos los parámetros de JCL son importantes, pero la función DISP es una de las más importantes para las sentencias DD.
Los parámetros completos de estos campos son:
DISP= (status,normal end,abnormal end)
DISP= (status,normal end)
DISP= status

Donde status puede ser NEW, OLD, SHR, o MOD:

NEW Indica que se va a crear un nuevo data set. El programa tendrá acceso exclusivo al data set mientras
ejecute. El data set no debe existir.
OLD Indica que el data set ya existe y que el programa tendrá acceso exclusivo
mientras esté ejecutando.
SHR Indica que el data set ya existe y que varios jobs pueden acceder en forma
simultánea mientras estén ejecutando. Todos esos jobs concurrentes deben codificar SHR.
MOD Indica que el data set ya existe y que el job va a tener acceso exclusivo mientras
esté ejecutando. Si este job abre el data set para salida (grabación),
la salida que genere será agregada el final de los datos que ya existen en el data set.

El parámetro “normal end” indica que hacer con el data set (la disposition) si el paso de job termina en forma normal.
Asimismo, el parámetro “abnormal end “ indica qué hacer con el data set si el paso de job termina en forma anormal
(abend).

Las opciones son las mismas en ambos parámetros:

DELETE Significa borrar (y descatalogar) el data set al final del paso de job.
KEEP Significa mantener (pero no catalogar) el data set al final del paso de job.
CATLG Significa mantener y catalogar el data set al final del paso de job.
UNCATLG Significa mantener el data set pero descatalogarlo al final del paso de job.
PASS Significa que se permite su uso a un paso de job posterior, el cual especificará
luego la disposición final.

Los valores por defecto (default) de los parámetros de disposición (para finalización normal y anormal) es la de mantener el data set
tal como estaba antes de la ejecución del paso de job (la función de catalogación fue descripta anteriormente).

El propósito principal del parámetro DISP es el de indicar al sistema sobre las necesidad de encolamiento de data sets de un job,
de manera de prevenir conflictos cuando se esté usando por otros jobs.

P13
Si el parámetro DISP para un data set es NEW, hay que suministrar información adicional. Esta incluye:
Un nombre de data set.
El tipo de dispositivo donde residirá el data set.
Un rótulo (volser), si es un disco o cinta rotulada.

Si se usa un disco, se debe indicar la cantidad de espacio a ser definido para extención primaria.

Si es un data set particionado, indicar el tamaño del directorio.

Opcionamente, se pueden especificar parámetros DCB. Alternativamente, el programa que grabará el data set puede proveer estos
parámetros.

El parámetro DISP y los nombres de data set names ya han sido descriptos. Brevemente, otros parámetros son:
Volser El formato de éste en una sentencia DD es VOL=SER=xxxxxx, donde xxxxxx es el
rótulo (volser). El parámetro VOL puede especificar otros detalles.
Device type Hay varias formas de hacer esto, pero UNIT=xxxx es la más común. El valor xxxx puede ser un tipo
de dispositivo (como un disco 3390), o una dirección específica de dispositivo (como 300), o un “nombre esotérico”
definido por la instalación (como por ejemplo SYSDA). SYSDA usa una convención para representar cualquier volúmen
de disco disponible.
Member name Recuerde que un miembro de una librería (o data set particionado, PDS) puede ser tratado como un
data set por varias aplicaciones y utilitarios. Para referenciar un miembro específico se usa el formato
DSNAME=ZPROF.LIB.CNTL(TEST). Si la aplicación o el programa utilitario espera un data set secuencial, se debe
especificar un data set secuencial o un miembro de una librería. Se puede usar el nombre completo de la librería (sin
un nombre de miembro especifico) sólo si el programa o utilitario esperan el nombre de la librería.

Space El parámetro SPACE se necesita para definir data sets en disco (DASD). Indica el
espacio requerido. Antes que el data set se pueda crear en disco, el sistema debe conocer cuánto espacio necesita y
cómo ese espacio se cuantifica. En el caso más básico, SPACE tiene dos parámetros. Estos son la unidad de medición
(pistas, cilindros o tamaño promedio de bloque) y la cantidad de espacio.

P14
Como una consecuencia de la limitación en el número de caracteres que pueden
codificarse en
una única tarjeta perforada de 80 columnas usada en anteriores sietemas, z/OS
introduce los
conceptos de continuación y concatenación. Por este motivo, z/OS mantiene esas
convenciones de
manera de minimizar el impacto en aplicaciones y operaciones previas.

P15
La sintaxis de la continuación de JCL involucra una coma (,) al final del último operando completo.
La siguiente línea de JCL debe incluir // seguido por lo menos de un espacio, luego el operando adicional.
Sintaxis del operando de JCL en una línea de continuación debe comenzar en o antes de columna 16.

//JOBCARD JOB 1,REGION=8M,NOTIFY=ZPROF

Una importante facilidad de la sentencia DD es el hecho que una única “ddname” puede tener múltiples
sentencias DD. Esto se llama “concatenación”.

El JCL siguiente indica que los data sets están concatenados:

//DATAIN DD DISP=OLD,DSN=MY.INPUT1
// DD DISP=OLD,DSN=MY.INPUT2
// DD DISP=SHR,DSN=YOUR.DATA

Concatenación aplica sólo a data sets de entrada. Los data sets se procesan automáticamente en
secuencia. En el ejemplo, cuando el programa lee el final de MY.INPUT1, el sistema abre
automáticamente MY.INPUT2 y comienza a leerlo. El programa no se da cuenta que ahora está
leyendo un segundo data set. Continúa hasta leer el último dato de la concatenación; en ese
momento la aplicación recibe la indicación de fin-de-archivo.

P16
Algunos programas y tareas necesitan una mayor cantidad de JCL que un usuario
pueda entrar fácilmente.
JCL para estas funciones se pueden guardar en librerías de procedimientos. Un
miembro de una librería de procedimientos contiene “parte” del JCL para una
tarea dada – usualmente fija, parte de JCL sin cambio.
El usuario del procedimiento suministra la parte variable del JCL para un job específico.
A veces se lo denomina “procedimiento catalogado” y no está relacionado a un
catálogo del sistema.

Muchos de estos JCL ya los hemos visto. Nuevas funciones de JCL presentes ahora
incluye:
Parámetros PROC y PEND son únicos para procedimientos. Se usan para
identificar el comienzo y fin del JCL de un procedimiento.
El PROC está precedido de un rótulo o nombre; en nuestro ejemplo el nombre es
MYPROC.
La sentencia PROC en un procedimiento también se usa para la sustitución de
variables simbólicas. &SORTDSN es la única variable en nuestro ejemplo.

P17
En este ejemplo, incluímos un procedimiento “inline” codificado en el mismo job stream.

Cuando MYJOB se envía a ejecución (submit), el JCL de nuestro ejemplo se sustituye

para la sentencia EXEC MYPROC. El valor para &SORTDSN debe ser provisto.
SORTDSN y su valor se codifican a continuación de la sentencia EXEC MYPROC,
separado por una coma.
//SYSIN DD * seguido por las sentencias de control del SORT se agregan al JCL
substituido.

P18
Cuando una sentencia de JCL PROC entera debe ser reemplazada, entonces se puede
usar una sentencia con el siguiente formato:
//stepname.ddname DD ...

Este ejemplo muestra la modificación de la sentencia DD SORTOUT en MYPROC,

donde definimos SORTOUT directamente a un nuevo data set secuencial en
disco.

P19
SDSF es un software cuyo propósito principal es el de poder ver salidas impresas de
jobs retenidas en el área de spool del JES. Muchas veces esas salidas nunca se
imprimen, pero mediante el SDSF se pueden ver y luego borrar o imprimir a
pedido.

P25
Este es el menu primario de opciones de SDSF. Algunas de las opciones son:

DA El panel “Display Active” muestra información sobre

los address spaces de MVS (jobs, started tasks, y ususarios de TSO) que están
ejecutando.
I El panel “Input Queue” información sobre jobs, started
tasks, y usuarios de TSO en la cola de entrada o ejecutando.
O El panel “Output Queue” muestra información sobre
datos de data sets de SYSOUT de jobs,
started tasks, y usuarios de TSO en cualquier clase de JES2
no retenidas (nonheld) .
H El panel “Held Output” muestra información sobre
datos de data sets de SYSOUT de jobs,
started tasks, y usuarios de TSO en cualquier clase de JES2
retenidas (held) .
ST El panel “Status” muestra información sobre jobs,
started tasks, y usuarios de TSO en las colas de JES2.

LOG El panel “System Log” muestra el log y le permite

buscar en él.
PS El panel “Processes” muestra información sobre
procesos de servicios del sitema z/OS UNIX.
PR El panel “Printers” muestra información sobre
impresiones en JES2 de salidas de jobs, started task, y usuarios de TSO.

P27
La primera pantalla al tope de esta diapositiva muestra una lista de jobs enviados a
ejecutar y la salida la hemos direccionado a una cola de retención (HELD)
clase T, identificada en el parámetro MSGCLASS=T en la sentencia JOB. En
nuestro caso sólo un job enviamos y se ejecutó.

Tenemos un solo job en la cola de retención (Held).

Mediante el comando ? En la columna NP, se muestran los archivos de salida

generados por el job
La segunda pantalla muestra tres ddnames: el archivo de mensajes de log del JES2 y el
archivo de mensajes del sistema de JES2. Esta opción es útil cuando está
viendo jobs con varios archivos dirigidos a SYSOUT y quiere ver uno asociado
con un paso específico. Puede emitir el comando S en la columna NP para
seleccionar el archivo que quiere.

Para ver todos los archivos, en lugar de un ?, ponga S en la columna NP.

P41
Estas librerías son data sets PDS estandares y se encuentran en volumenes de disco
del sistema.