RPG Versus SQLRPG

A medida que el RPG ha evolucionado y ha aceptado ser el anfitrión de otros lenguajes de programación se ha desarrollado recientemente una rivalidad entre las facilidades que ofrece el RPG “puro” versus el SQLRPG.

Las nuevas generaciones de programadores que se ven en la necesidad de programar RPG, porque sus lugares de trabajo así lo solicitan, prefieren desesperadamente el uso de SQL combinado con RPG porque está más acorde a su reciente formación académica. Los desarrolladores de la vieja escuela, más experimentados en RPG se muestran renuentes e incómodos con los cambios y prefieren aferrarse al RPG tradicional.

A continuación expongo algunas ventajas y desventajas de ambas tecnologías para tener en cuenta los beneficios que ofrece cada una a la hora de decidir cómo resolver un dilema en el proceso de desarrollo de un programa en el Iseries.

Ventajas de RPG.

•     El manejo de campos tipo Fecha en pantalla verde es sencillo y puede ser  directo. No requiere conversión de data.

•    Puede manejar “data decimal errors” a tiempo de compilación sin que signifique  la falla del programa.

•   Maneja sin problemas campos “empaquetados”.

•   Los archivos “planos” pueden definirse en el programa y visualizarse muy  rápidamente en su definición.

•   Los errores de compilación son mucho más sencillos de entender y detectar.

Desventajas de RPG

• Requiere más código de programación en procesos de búsqueda de data.

• NO maneja valores nulos, lo que dificulta a simple vista entender, por ejemplo,  si la data que tiene valor blanco (‘  ‘) en el archivo tiene ese valor porque el usuario la cargó así o porque es el valor por omisión que asigna el sistema. Con la palabra clave en la hoja ‘H’ (ALLNULL) podemos hacer que el programa tolere valores nulos pero las DDS sobre la cual se apoya tradicionalmente este tipo de programación no maneja el valor nulo

•  Requiere más lazos anidados para procesar varios archivos que se vinculan, lo que puede dificultar la estructuración del programa en segmentos más cortos para su comprensión y mantenimiento.

• Puede ser rígido en procesos de consulta que requieren navegación a través de varias pantallas. Consultar la disponibilidad de la data, cuantos registros tiene un archivo, que condiciones tiene o no un archivo para seguir o no con cierta secuencia, puede llevar a una cadena de CHAIN sobre la data que resulta laboriosa de programar.

•  Hay más posibilidades de presentar casos de registros “allocated”. Los CHAIN y lecturas entre procesos pueden provocar que  uno o varios trabajos entren en conflicto al compartir la data para actualizarla. El programador debe estar muy atento a esta secuencia de lecturas y accesos a la base de datos.

•   Revisar la consistencia de las bases de datos con programas de RPG no es práctico. Resulta largo, lento y depende de la experticia del programador. El manejo de la data tradicionalmente se realiza con definiciones DDS que no constituyen una base de datos sino un manejador de archivos.

• Peligro de inconsistencia en la Base de Datos por uso de DDS en lugar de DB2. El programador es quien tiene la responsabilidad de controlar por código de programación la consistencia e integridad de la data.

• 
  

Desventajas de SQLRPG

• Puede hacerse ininteligible en sentencias largas que involucran varios archivos y condiciones. Para otro programador puede resultar realmente una odisea modificar una sentencia larga, compleja e intrincada.

• Difícil o riesgoso el manejo de campos empaquetados

• Puede ser lento si se trabaja con muchas tablas de gran cantidad de datos. A veces lo lógicos son más eficientes en archivos de más de 50 millones de registros.

•   La compilación no es sencilla de entender. El programador a veces debe adivinar qué significa un mensaje del sistema.

• Tiene una tabla de errores que hay que consultar constantemente en la internet puesto que no es lo suficientemente detallado para explicar el problema con el log del job.

•  Generalmente no falla a tiempo de ejecución. Aunque una sentencia está mal construida o hay errores de data, el programa termina y no da aviso de fallas lo que puede hacer dudar al usuario sobre la culminación exitosa o no exitosa del proceso.

Ventajas de SQLRPG

• Los procesos de búsqueda de información son más sencillos, directos y rápidos de ejecutar.

• Trabaja con más velocidad con DB2 y genera una falla cuando detecta inconsistencia de data, lo que previene corrupción de la data.
• Maneja valores nulos.

• Es una solución efectiva en proceso de consulta que requiere varias pantallas de navegación

• Es versátil en la combinación de campos y en la generación de listados de auditoría para revisar la data.

• Es dinámico en la construcción de sentencias. Se puede utilizar el mismo programa en forma parametrizada para solucionar varios requerimientos dentro del mismo desarrollo sin generar código de programación adicional.
• 
  

Hay muchos más puntos de comparación entre ambas tendencias. 

En este artículo expongo los más relevantes en mi criterio.

Ambas tendencias tienen sus ventajas y desventajas y lo más inteligente sería tomar lo mejor de ambos mundos y desarrollar programas de mejor calidad aprovechando lo que ofrece la simbiosis de ambas tecnologías.

Si te pareció interesante, reenvíalo a un amigo haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo. 

Autor: Ing. Liliana Suárez