Para finalizar el conjunto de artículos publicados en la revista en los meses de marzo y abril, donde exponía que se debía realizar una evolución en el diseño de las nuevas aplicaciones sobre AS/400, usando como herramientas de desarrollo CODE/400, RPG/IV y/o RPG/Free y WebFacing y luego hacía una introducción al Editor del CODE/400, (marzo de 2002), en el artículo siguiente hacía una introducción del Diseñador de Pantallas e Impresoras, que también es un componente del producto CODE/400, (abril de 2002), voy a finalizar exponiendo en este tercer artículo algunas mejoras y novedades del RPG/IV sobre el RPG/400, y haciendo comparaciones entre la forma de codificación en RPG/IV y RPG/400.

Dentro de las muchas mejoras existentes en RPG/IV sobre RPG/400 me voy a centrar fundamentalmente en dos, que hacen que los programas de RPG/IV sean mucho más legibles, fáciles de hacer y mantener.

Nueva especificación D:

En comparación con el RPG/400, el RPG/IV incorpora una nueva especificación, la D, que viene a sustituir en su totalidad a las especificaciones E y L del RPG/400, y en parte a la especificación I.

La especificación D, es el lugar para definir todos los campos, series, estructuras de datos y cualquier información que no pertenezca a las descripciones externas de los ficheros, la especificación I sólo sirve en RPG/IV para que refleje los campos de entrada de los ficheros descritos externamente en el programa (se supone que a estas alturas nadie debería estar trabajando con ficheros que no estuvieran descritos externamente).

La definición de campos en la especificación D (véase Figura 1A), permite definir los nombres de campo de hasta 255 caracteres, lo cual unido a que si los campos de los ficheros de base de datos, pantalla e impresora, ya los hemos definido de 10 caracteres, nos permiten una mucho mayor legibilidad en las operaciones que vamos a realizar con ellos en el programa.

Podremos definir campos numéricos, alfanuméricos, constantes, punteros, indicadores, de fecha, hora e indicación de la hora; etc, y además tenemos la opción de definir un campo en función de otro campo de la misma especificación D o de cualquier campo que pertenezca a algún fichero definido en el programa (palabra clave LIKE), dándole las mismas características que el campo, e incluso se le podrán incrementar o disminuir su longitud con respecto del campo tomado como referencia, también podremos inicializar un campo con un contenido inicial (palabra clave INZ); todas estas funciones, más la ventaja de poder ver rápidamente todos los campos de trabajo de nuestro programa, sus tipos y valores iniciales, nos hará mucho más legible nuestro programa.

La definición de las estructuras de datos en la especificación D (véase Figura 1B), permite una definición mucho más fácil de codificar y modificar que en la especificación I del RPG/400, admite la codificación antigua de campos, posición desde/hasta, pero es mucho mejor la codificación especificando solamente la longitud del campo, lo cual nos permite ver claramente la longitud de los subcampos y si es necesario insertar algún subcampo, solamente hay que introducir dicho campo y su longitud en el lugar que nos interese dentro de la DS, además como se puede ver en el ejemplo, los campos pueden ser indentados para una mayor legibilidad.

Otra opción interesante es la de poder redefinir campos, esto se consigue con la palabra clave OVERLAY, por ejemplo, el Campo2 de la estructura de datos DS2, su longitud es de 30 posiciones, las 15 primeras posiciones se redefinen como Campo21, que a su vez se redefinen en las 7 primeras posiciones como Campo211; el Campo22 contiene las 15 últimas posiciones del Campo2 (15 posiciones a partir de la posición 16 del Campo2), con lo cual la definición de esta estructura de datos sería mucho más fácil que con el método antiguo.

Hasta ahora un campo no podía pertenecer a más de una estructura de datos, pero a partir de la V5, dos o más estructuras de datos pueden tener los mismos campos, como se puede ver en la Figura1B, donde la DS3 y DS4 contendrán los mismos subcampos (Subcampo1 y Subcampo2), esto se consigue poniendo la palabra clave Qualified, en la estructura de datos de referencia y la palabra clave LikeDs en la estructura de datos que va a contener los mismos subcampos, incluso en la segunda estructura de datos se puede utilizar la palabra clave Inz(*LikeDs), para inicializarla con los mismos valores que la estructura original; esta codificación plantea el problema de diferenciar cuando nos referimos a cada subcampo, de qué estructura de datos es, problema que queda resuelto refiriéndonos a cada subcampo precedido de qué estructura es, tal como se puede ver en la Figura1C. 

Más claridad y productividad en cálculo:

Algunos de los grandes inconvenientes que tiene la codificación de la especificación C en RPG/400, es la mala legibilidad que proporcionan los encolumnados del factor 1 y 2, código de operación y campo de resultado, a lo cual hay que unir que los nombres de campos usados son de 6 posiciones como máximo, lo cual aún hace peor su seguimiento.

Otro factor negativo es que para realizar cada operación (por ejemplo, sumar, restar, multiplicar, etc), se necesita una línea de fuente, además hay códigos de operación cuya abreviatura se queda pobre, debido a que el código de operación sólo admite 5 caracteres (por ejemplo, RETRN, REDPE, WH, DEFN, etc), en la Figura2A, se puede ver una codificación típica y sencilla de varias operaciones dentro de un código de operación SELEC, con sus WH y OTHER.

Todos los inconvenientes apuntados anteriormente quedan resueltos con el RPG/IV y/o RPG/Free, ver Figura2B y Figura2C, en RPG/IV tenemos el Factor 2 ampliado con lo cual podemos realizar todos los cálculos en una o varias líneas empleando el código de operación EVAL, en RPG/Free no tenemos ningún tipo de encolumnado y podemos usar una o varias líneas para realizar todos los cálculos, en ambos podremos utilizar nombres de campos mucho más significativos porque ya no tenemos la limitación de 6 caracteres como nombre de campo, además en ambos ya podemos usar códigos de operación de hasta 10 posiciones, los ejemplos antes puestos con limitación del nombre del código de operación, ahora son RETURN, READPE, WHEN, DEFINE, con lo cual éstos, el resto de códigos de operación y todo el programa es mucho más claro, legible y fácil de realizar y mantener. 

RPG/IV sigue creciendo.

Además de lo expuesto anteriormente, hay otras muchas cosas que se pueden realizar en RPG/IV y que no se pueden realizar en RPG/400, por citar algunas de las más importantes:

Tratamiento de fechas, definición y tratamiento de campos de fecha, hora e indicación de la hora, podemos almacenar campos de fecha, hora e indicación de la hora en ficheros de base de datos y podemos calcular duraciones, por ejemplo, número de días, meses y años transcurridos entre dos fechas, o sumar un número de días, meses o años a un campo de fecha y obtener una nueva fecha.

Trabajar con Funciones Incorporadas, que son como códigos de operación, pero con más posibilidades que un código de operación no nos puede proporcionar y además estas funciones incorporadas están en continua evolución, sólo en V5 se han añadido 23 nuevas funciones incorporadas al RPG/IV.

Generar objetos *MODULE y *SRVPGM, a partir de miembros fuente para lograr una mayor modularidad y reutilización de nuestro software.

Codificar Procedimientos, que se podrían considerar como subrutinas, pero a las que les podemos pasar parámetros y se parecen a otras formas de programar en otros lenguajes, como por ejemplo, un método de Java.

Llamar a métodos del lenguaje Java, siempre que tengamos la nueva V5 del OS/400, con lo cual nuestro RPG/IV podrá acceder a gran parte de las clases creadas para este lenguaje de programación.

RPG/400 tocado y hundido.

Esto es sólo una pequeña muestra de las ventajas que nos proporciona el RPG/IV sobre el RPG/400, además debemos tener en cuenta que todas las mejoras que IBM realiza para el RPG, sólo se implantan en el RPG/IV, la elección de abandonar el uso del RPG/400 a favor del RPG/IV para realizar cualquier programa nuevo, es totalmente evidente, además cualquier cambio o mejora en programas antiguos realizados en RPG/400, se debería optar por realizar la conversión a RPG/IV (que se puede hacer mediante el mandato CVTRPGSRC o desde el CODE/400), y realizaríamos ya el cambio en un programa RPG/IV.

En un próximo artículo explicaré como pasar una aplicación de “pantalla verde” a entorno visual tipo web, mediante el uso de la herramienta WebFacing, que nos permite transformar nuestros ficheros de pantalla (DSPF) en páginas HTML y seguir ejecutando nuestros programas RPG, pero una vez convertida la aplicación visualizaremos las páginas HTML transformadas en lugar de nuestros formatos de registro de los ficheros WORKSTN.

Fco. Antonio Jabal
Consultor y profesor de Bit Formación Informática en AS/400
sistemas@bit.es

Barcelona, mayo 2002

Artículo anterior - Calendario de cursos

© Bit, s.a. Todos los derechos reservados - bit@bit.es - www.bit.es