JCL Básico IV: Sentencia DD (Parte I)

Sentencia que describe los ficheros con los que se va a trabajar (una sentencia DD por cada fichero). Identifica cada fichero lógico definido en la SELECT del programa con su fichero físico.
No puede existir mas de una sola DD identificada con el mismo nombre lógico.

//FICHERO1 DD DSN=xxxx.nombre.fichero
//            DISP=(NEW,CATLG,DELETE),VOL=SER=SYSWKl,
//            UNIT=3380,LABEL=3,SPACE=(TRK,(10,5),RLSE),
//            COPIES=4,DEST=RMT005,OUTLIM=1500,
//            RECFM=FB,LRECL=150,BLKSIZE=1500

La no especificación de nombre lógico en una ficha DD presupone la concatenación al fichero de la sentencia DD anterior. En ocasiones un paso puede precisar de mas de un fichero para una determinada entrada de datos y ello es posible por medio de la concatenación de DD.s. La forma en codificarse es:

//ENTRADA1 DD DSN=xxxx.nombre.fichero1,DISP=SHR
//         DD DSN=xxxx.nombre.fichero2,DISP=SHR
//SALIDA1  DD DSN=xxxx.nombre.fichero3,
//            DISP=(NEW,CATLG,DELETE),VOL=SER=SYSWKl,
//            UNIT=3380,LABEL=3,SPACE=(TRK,(10,5),RLSE),
//            COPIES=4,DEST=RMT005,OUTLIM=1500,
//            RECFM=FB,LRECL=150,BLKSIZE=1500

NOTA. En este caso ambos ficheros de entrada han de tener la misma longitud.

Anteriormente a este artículo he hablado de las líneas de la cabecera de un jcl y de las sentencias que ejecutan programas (EXEC). Podemos tener sentencias DD tanto en la cabecera como en cada uno de los pasos de nuestro jcl:

• Sentencias DD en la cabecera del jcl.
  Las únicas DD asociadas a la ficha JOB son aquellas destinadas a definir librerías de acceso a las que deberán acudir los trabajos en tiempo de ejecución. El nombre lógico que las identifica es:
  
  • JOBLIB --> La ejecución de un programa se inicia en la busca del objeto (código en lenguaje maquina) en las librerías estandars de la instalación (SYS1.LINKLIB) pero en según que casos puede sernos de utilidad el desplazar esa búsqueda a otras librerías.
    La especificación de una o varias librerías no evita en ultimo caso el acudir a las estandars de la instalación si no se encontrase en ninguna de las referidas.
    Ha de codificarse después de la ficha JOB y antes de cualquier paso EXEC.
    No puede utilizarse en procedimientos catalogados.
    La codificación de JOBLIB predispone a los pasos EXEC posteriores a que todos acudan a esas librerías para la obtención del objeto a ejecutar. Será excepción de lo dicho los pasos EXEC que dispongan de una DD STEPLIB en cuyo caso serán esas las librerías de captura.
  • JOBCAT --> La diferencia de la JOBCAT con la JOBLIB radica en que mientras la anterior buscaba el objeto a ejecutar, esta marca el camino a seguir para la búsqueda y obtención del catalogo de ficheros. sigue las mismas pautas y en ultimo extremo acude a las estancadas de la instalación.
    
    Ha de codificarse después de la ficha JOB y de la JOBLIB y antes de cualquier paso EXEC.
    La codificación de JOBCAT predispone a los pasos EXEC posteriores a que todos acudan a esas librerías para la obtención del catalogo de ficheros. Será excepción de lo dicho los pasos EXEC que dispongan de una DD STEPCAT en cuyo caso serán esas las librerías de catalogo.
  • SYSCHK --> Define el fichero de grabación de CHEKPOINTS (puntos de control) de un programa que se guardan para rearranque posterior.
    Debe ser anterior a cualquier paso EXEC de un JOB puesto que en rearranque y especificando la identificación del punto de control se deberá acudir a este fichero antes que al paso para obtener la información del programa que se pretende arrancar.

• Sentencias DD en cada paso (EXEC) del jcl.
  Destinadas a definir librerías de acceso a las que deberán acudir los pasos de un trabajos en tiempo de ejecución. El nombre lógico que las identifica es:
  
  • STEPLIB --> La ejecución de un programa se inicia en la busca del objeto (código en lenguaje maquina) en las librerías estándar de la instalación (SYS1.LINKLIB) pero en según que casos puede sernos de utilidad el desplazar esa búsqueda a otras librerías.
    La especificación de una o varias librerías no evita en ultimo caso el acudir a las stándar de la instalación si no se encontrase en ninguna de las referidas.
    Ha de codificarse después de la ficha EXEC aunque no tiene porque ser la primera DD
    A diferencia de la JOBLIB puede utilizarse en procedimientos catalogados.
    
    En el siguiente ejemplo, cuando se lance el job, éste buscará el ejecutable del programa PROGRAMA1 en la libreria1 y si no lo encuentra lo buscará en la librería2:
    
    //PASO01 EXEC PGM=PROGRAMA1
    //STEPLIB DD DSN=xxxx.nombre.libreria1,DISP=SHR
    //        DD DSN=xxxx.nombre.libreria2,DISP=SHR
    ...
    ...
    
    ¿Para que puede servir la STEPLIB? Son muchas las utilidades que tiene:
    Pongo un ejemplo:
    - Para pruebas en el entorno de explotación, imagina que quieres hacer una prueba de un programa que has creado pero que todavía no está subido al entorno de explotación, pero el cliente insiste en probarlo bien y no te queda otra que hacerlo con datos de explotación.
    SOLUCIÓN: Lo que debes hacer es dejar la compilación de tu programa en una librería a la que tengas acceso en el entorno de producción (una librería que hayas creado tú o alguna puente o de intercambio que exista, en muchas plataformas existe una librería preparada para este fin). Una vez copiado tu ejecutable en dicha librería, únicamente tienes que indicar en tu paso de jcl donde se ejecuta el programa, la STEPLIB del siguiente modo:
    
    //PASO01 EXEC PGM=MIPROGRAMA
    //STEPLIB DD DSN=xxxx.nombre.libreria1,DISP=SHR
    ...
    
    Cuando se ejecute el jcl, el programa "tirará" de la librería indicada en la STEPLIB.
    
    Pongo otro ejemplo:
    - Imagina que puntualmente se necesita modificar un programa durante un periodo en concreto. Por ejemplo, tienes un programa con información acerca de la velocidad máxima en las autovías (120 km/h). Pero resulta que de la noche a la mañana lo que creías que no iba a ocurrir ocurre, y es que la velocidad ha de ser bajada a 110 km/h durante un plazo determinado. Bien, lo normal sería modificar tu programa, implantarlo, y esperar a que dentro de X meses tengas que volver a modificar el programa para devolverlo a su estado original(120 km/h), con todo lo que eso conlleva, volver a bajar el programa, modificar, probar, implantar, etc....
    SOLUCIÓN: Modificas el programa para que admita los 110 km/h pero no lo implantas en producción sino que copias el ejecutable en una librería auxiliar(temporal, puente o como quieras llamarla). Luego, en el jcl que ejecuta tu programa, lo único que haces es añadir al paso una línea de STEPLIB donde indicas esa librería puente donde has dejado la compilación. De este modo durante los próximos meses tu jcl ejecutará la versión del programa que está preparada para los 110 km/h. Cuando la norma cambie y volvamos a poder "correr" en las carreteras a 120, únicamente has de quitar la línea del jcl, o bien borrar el programa modificado de la librería auxiliar (si el jcl no encuentra el programa en la librería indicada en la STEPLIB irá a buscarlo a la librería original).
  • STEPCAT --> La diferencia de la STEPCAT con la STEPLIB radica en que mientras la anterior buscaba el objeto a ejecutar, esta marca el camino a seguir para la búsqueda y obtención del catalogo de ficheros. sigue las mismas pautas y en ultimo extremo acude a las stándar de la instalación.
    
    Ha de codificarse después de la ficha EXEC aun que no tiene porque ser la primera DD.
    La sentencia STEPCAT solo puede referirse a catálogos de usuario del tipo VSAM.
  • SYSABEND --> Determina el fichero donde el sistema efectuara el vuelco de memoria por terminación anormal ABENDED. La información que aporta hace referencia a:
    Núcleo del sistema
    Área del programa problema
    Tabla de Trace
  • SYSUDUMP --> Determina el fichero donde el sistema efectuara el vuelco de memoria por terminación anormal ABENDED. A diferencia de la anterior tan solo facilita información del área del programa.
  • DUMMY --> representa un fichero ficticio, el programa lo abrirá, efectuará operaciones de E/S sobre el (ficticias), pero el sistema no dará error. Muy útil cuando no queremos que, por lo que sea, no queremos obtener el fichero de salida de un programa, ponemos el fichero a DUMMY y la ejecución será exactamente igual que si lo tuviéramos pero sin escribir nada en la salida.

La sentencia DD es bastante amplia, por lo tanto, continuaré con ella en el próximo artículo...(JCL Básico IV: Sentencia DD (Parte II)