Desarrollando en Cobol y Natural sobre Plataforma Mainframe

lunes, 13 de junio de 2016

Ver campos Hexadecimales en QMF con HEX (y 2)

Hace algunas semanas comenzamos a revisar los pasos que hay que seguir para ver campos hexadecimales en QMF mediante la cláusula HEX. Aunque en su momento ya estuvimos viendo cómo hacer esto mismo con la ventana FORM, nunca viene mal tener formas alternativas de hacer esta decodificación. Recordad que, si no realizamos ningún tratamiento sobre los datos, el informe de QMF nos mostrará los campos hexadecimales en un formato no legible

En la primera parte del post ya estuvimos viendo los primeros puntos del procedimiento (acceder al post Ver campos Hexadecimales en QMF con HEX - 1). Hoy nos centraremos en finalizar el examen de los pasos a seguir, de manera que completemos la visión global de este método de decodificación. Si nos dedicamos al análisis de incidencias, esta alternativa nos resultará muy útil. Vamos con ello.

4º) Una vez codificada la query anterior, la ejecutamos desde QMF. De esta forma obtendremos el informe de la tabla DB2 con el listado de registros extraidos.







Como vemos en la imagen, ahora el informe ya no muestra datos hexadecimales. Por un lado, la cláusula HEX ha hecho que se nos presente la información en formato alfanumérico. Por otro lado, los comandos SUBSTR que hemos incluido nos han permitido dividir el campo hexadecimal en cada uno de los subelementos con significación propia.

                                           SITU    LOCA
ORCI         VERSIO  TJALON  SITU    LOCA   1       1 
-----------  ------  ------  ------  ----  ------  ----
00662341105  000     C2      990003  290   900001  002
01458141303  000     C2      990003  839   900001  002
02180781101  002     C2      990003  290   900001  002
03038681303  000     C2      990003  290   900001  002
03422721304  000     E3      990002  031   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03560631304  000     C2      990003  290   900001  002
03723801304  000     D2      990003  788   900001  002


Si nos centramos en un único registro, podremos apreciar con mayor claridad lo cómoda que resulta ahora la lectura de la información del antiguo campo hexadecimal. Parece que ha merecido la pena dedicar algo de tiempo a la codificación.

                                           SITU    LOCA
ORCI         VERSIO  TJALON  SITU    LOCA   1       1 
-----------  ------  ------  ------  ----  ------  ----
03560631304  000     C2      990003  290   900001  002


Fijaos que estos son los mismos datos que vimos en la alternativa anterior de decodificación. La única diferencia es que de este modo  son más fáciles de leer.

03560631304  000     C2      990003  290   900001  002

Creo que ahora ya entenderéis por qué os digo que, de esta forma, os va a resultar mucho más fácil analizar los registros DB2. Si os dedicáis al análisis de incidencias, como es el caso de muchos programadores Cobol, a largo plazo esto supondrá un gran ahorro de tiempo. Y si ahora no os dedicáis a ello, bueno, guardáos este post por ahí, porque en el mundo Host tarde o temprano tendréis que resolver incidencias...



¿Cuál de las dos alternativas es mejor?


Una vez vistas estas dos formas de traducir campos hexadecimales en QMF, nos podríamos hacer la pregunta: ¿cuál de las dos alternativas es mejor? Realmente no podemos decir que uno de los procedimentos sea mejor que el otro, cada uno tiene su aplicación específica. Va a ser cuestión nuestra decidir cuál de los dos métodos es el adecuado para la situación con la que nos estemos enfrentando.

-------------------------------------------------------------------------------------------------------------------------------
Tip: Aquí podéis ver diversas herramientas clave del entorno Host
-------------------------------------------------------------------------------------------------------------------------------

Por ejemplo, si únicamente queremos hacer una consulta rápida de un dato y no vamos a acceder a esta tabla DB2 nunca más, entonces la alternativa 1 será la mejor. Para un escenario de este tipo no tiene sentido invertir demasiado tiempo en la traducción del campo hexadecimal. Aquí va a primar la rapidez frente a la comodidad, ya que no se va a tratar de una extracción periódica.

En cambio, si lo que nos están pidiendo es algo que vamos a tener que consultar una vez cada semana (o cada mes), entonces yo me plantearía acometer la alternativa 2. En este caso sí que va a merecer la pena invertir un poco más de trabajo en desarrollar la query para mostrar los subcampos hexadecimales de la forma más legible posible. Posteriormente, eso nos supondrá un gran ahorro de tiempo a la hora de revisar los datos extraídos de forma periódica.


En cualquier caso, la idea del post es que dispongáis de un par de opciones para traducir los campos hexadecimales con los que os vayáis encontrando en vuestro día a día. En realidad, seleccionar una alternativa u otra es un problema secundario una vez que ya somos conscientes de que la información hexadecimal no es un obstáculo insalvable para nosotros. En última instancia, elegid la solución que os resulte más óptima en vuestra instalación.

Pues nada, eso es todo por lo que respecta a la visualización de campos hexadecimales en QMF. Espero que lo comentado en el texto os ayude a superar este tipo de problemas de formato. Cualquier duda que tengáis, ya sabéis, me la dejáis aquí abajo en los comentarios...

Saludos.

No hay comentarios:

Publicar un comentario en la entrada

Related Posts Plugin for WordPress, Blogger...