Utilidad JCL ICEMAN para realizar SORT (y 2)

Hace algunas semanas comenzamos a ver la funcionalidad de la utilidad JCL ICEMAN, herramienta empleada para la realización de SORT (ordenación) de registros de ficheros. Recordemos que, tal y como dijimos, se trata de la versión moderna de la utilidad clásica DFSORT.

En la primera parte del post estuvimos viendo algunas de las cláusulas que lleva asociadas la utilidad ICEMAN (ver post Utilidad JCL ICEMAN para realizar SORT - 1). Hoy completaremos la revisión de todas las tarjetas que deben acompañar a esta herramienta para que pueda ejecutar una correcta ordenación mediante el comando SORT. Son la siguientes:

4º) Card SYSIN: Aquí se incluirán las sentencias de control que la utilidad ICEMAN recibirá como entrada. Bajo esta tarjeta se tendrá que especificar la función que debe ser ejecutada por el programa: SORT (ordenar), COPY (copiar) o MERGE (unir).

//SYSIN    DD  *

5º) Comando SORT: A continuación, incluimos el comando SORT bajo la tarjeta SYSIN para indicarle a la utilidad ICEMAN que debe realizar la ordenación de los registros del fichero de entrada y dejar el resultado ordenado en el fichero de salida especificado.

  SORT FIELDS=(1,6,CH,A,8,25,CH,A),DYNALLOC=3390

Como vemos, la cláusula FIELDS del comando SORT viene acompañada de ocho parámetros entre paréntesis. En realidad, en este caso se trata de la información asociada a dos campos de los registros del fichero: (1,6,CH,A) y (8,25,CH,A). Cada uno de los campos que especifiquemos en un SORT tendrá que tener provisionados los siguientes cuatro parámetros.

- Parámetro 1 – Inicio del campo: La ordenación se realizará en función del campo clave que comienza en la posición del registro indicada en este parámetro.

- Parámetro 2 – Longitud del campo: Aquí indicamos la longitud del campo clave que se empleará para realizar la ordenación. Recordemos que dicho campo comenzaba en la posición del registro indicada en el parámetro 1.

- Parámetro 3 – Tipo de Dato: Especifica el tipo de dato (formato) del campo clave seleccionado. Podrá ser CH (Alfanumérico o Numérico no empaquetado), BI (Hexadecimal empaquetado COMP) o PD (Empaquetado COMP-3).

- Parámetro 4 – Tipo de Ordenación: Indica si la ordenación debe ser ascendente (A) o descendente (D).

 

Se puede realizar la ordenación por tantos campos como se desee, sin más que añadir los datos de un campo a continuación del anterior. Sin ir más lejos, en el ejemplo anterior estamos ordenando por el campo que comienza en 1 (de longitud 6 posiciones) y por el campo que empieza en 8 (de longitud 25 posiciones).

6º) Comando SUM: Finalmente, se incluye el comando SUM para indicarle a la utilidad ICEMAN que, en el fichero de salida, no deben aparecer registros duplicados. En realidad, lo que hace SUM es eliminar aquellos registros que tengan valores idénticos en los campos especificados en el SORT.

A continuación del SUM, en su cláusula FIELDS indicaremos el campo que deseamos que se vaya sumando para todos aquellos registros que estén repetidos. Si se indica NONE, entonces es que no se desea que se sume ningún campo del fichero.

SUM  FIELDS=NONE

Por tanto, en nuestro ejemplo le estamos solicitando a la utilidad ICEMAN que haga una ordenación (SORT) ascendente (A) en función del campo de longitud 6 que comienza en la posición 1 (1,6) y del campo de longitud 25 que comienza en la posición 8 (8,25), ambos con formato Numérico/Alfanumérico No Empaquetado (CH).

Ejecución del comando SORT de la utilidad ICEMAN

Una vez tengamos definidos los parámetros de nuestro SORT en el ICEMAN de nuestro JCL, se podrá proceder a su lanzamiento. Si hemos definido los tarjetas tal y como hemos comentado anteriormente, la ejecución del job no debería darnos ningún error.

En particular, he procedido a lanzar el JCL que estábamos utilizando de ejemplo y el proceso se ha completado correctamente. El retorno RC devuelto ha sido un CONDITION CODE 0000. A continuación, he comprobado que se ha generado el fichero de salida con denominación ATLASPR.UNLOAD.X0005X.POBL.SORT y con todos los registros ordenados. Su contenido es el siguiente.

***************************** Top of Data *****
000002-ALMERIA                  00001300     
000004-SANTANDER                00001500     
000005-TARRAGONA                00001600     
000006-BADAJOZ                  00001700     
000007-SALAMANCA                00001800     
000008-BURGOS                   00001900     
000010-SEGOVIA                  00001100     
000011-TOLEDO                   00001000     
000012-GRANADA                  00000900     
000014-CASTELLON                00000700     
000015-ZARAGOZA                 00000600     
000017-VALENCIA                 00000400     
000018-BARCELONA                00000300     
000019-CIUDAD REAL              00000200     
000020-MADRID                   00000100     
**************************** Bottom of Data ***

Como vemos, los registros ya no están desordenados como en el dataset origen y en este fichero de salida las ciudades aparecen ordenadas en función de su código asociado. Realmente, en este ejemplo nos hubiese bastado con ordenar por el campo 1 del SORT, ya que no hay códigos de población repetidos.

En líneas generales, esta sería la forma de trabajar con la utilidad ICEMAN. De todos modos, aunque sea algo más antigua, en la mayoría de los casos podremos seguir operando con total normalidad mediante la utilidad DFSORT, ya que los comandos básicos son los mismos. Eso sí, lo ideal sería que nuestra instalación dispusiera de ambas alternativas.

Y eso es todo. Esperamos que lo comentado en el texto os sirva para haceros una idea de cómo se puede operar con la utilidad ICEMAN para JCL. Como ya sabéis, todas vuestras dudas serán bienvenidas…

Saludos.