Pareto Principle in RPG Development: The 20% That Causes 80% of the Errors/Principio de Pareto en el Desarrollo RPG: el 20% que causa el 80% de los errores

 

 

Pareto Principle in RPG Development: The 20% That Causes 80% of the Errors

 

*You can read this article in Spanish more down below in this same publish. (Puedes leer este artículo en español más abajo en esta misma publicación)

 

"The distribution of effort is not uniform: a minority of causes produce the majority of effects."
— Vilfredo Pareto

 

What is the Pareto Theorem?

The Pareto Theorem, also called the 80/20 Principle, states that 80% of results come from 20% of the causes.
For example:

• 80% of sales may come from 20% of customers.
• 80% of errors in a program may originate from 20% of the code.
• 80% of problems can be solved by focusing on 20% of critical factors.

This principle is not always exactly 80/20, but it illustrates a natural imbalance that helps prioritize efforts intelligently.

In the world of software development, and specifically within the IBM i environment using RPGLE, it is essential to identify and address the most common errors to improve code quality and team efficiency.
Applying the Pareto Principle, which suggests that 80% of problems come from 20% of causes, allows us to focus our efforts on the areas that have the greatest impact.

 

Most Common Errors in RPGLE

Based on analysis of common errors in RPGLE, the following are identified as the most frequent:

1. Decimal Data Errors (MCH1202): Occur when trying to use uninitialized numeric data or assigning non-numeric data to numeric variables.
2. SQL Errors in RPGLE:
• SQLCODE -204: Object not defined.
• SQLCODE -803: Unique constraint violation.
• SQLCODE -305: Null value not allowed.

 

Error Distribution and the Pareto Principle

Although exact statistics are not available, observation in development projects suggests the following approximate distribution:

• Decimal data errors: 40%
• SQL errors: 35%
• Syntax and compilation errors: 15%
• Other errors: 10%

Applying the Pareto Principle, it is observed that 75% of errors come from decimal data and SQL errors, which represent about 20% of the total possible causes.

 

Strategies to Mitigate the Most Common Errors

1. Variable Initialization:
   Ensure that all numeric variables are properly initialized before use to avoid decimal data errors.
2. Input Data Validation:
   Implement rigorous validations for incoming data, especially data interacting with the database.
3. Proper SQL Error Handling:
   Use structures such as SQLCA to effectively capture and handle SQL errors.

 

3.1 Strategies to Mitigate Common Errors in SQLRPGLE

Based on field experience analysis, technical forums, and IBM publications, these are the most frequent errors:

Error	Description	Approximate % of Occurrence
SQLCODE -305	Attempt to insert NULL where not allowed	30%
SQLCODE -204	Object (table or view) not found	25%
SQLCODE -802	Arithmetic error (e.g., division by zero)	15%
Data conversion errors	Assigning between incompatible types (e.g., char to dec)	15%
Control flow logic errors	Misuse of fetch, open, or do while loops with cursors	15%

Result: 70% of errors come from just two types of issues: inserting NULL values incorrectly and using nonexistent or improperly defined objects.
Exactly the 20% of error types generating 80% of the headaches.

 

Applying the Pareto Theorem

 If we educate and reinforce best practices in handling NULLs and validating the existence of SQL objects before using them, we could prevent up to 70–80% of execution errors in SQLRPGLE.

 

Practical Recommendations

1. Control the use of NULLs from the design phase:

• Correctly declare columns with NOT NULL DEFAULT to avoid accidentally inserting NULL values.
• Use %NULLIND and IF :NAME_IND = -1 in RPGLE to validate null input.

2. Validate SQL object existence:

• Use SYSCOLUMNS or SYSTABLES before referencing a table/view.
• Handle SQLSTATE and SQLCODE after each EXEC SQL.

exec sql

   select count(*) into :quantity

   from qsys2.systables

   where table_name = 'CLIENTES';

 

if quantity = 0;

   // Create table or throw error message

endif;

3. Use error monitors:

exec sql

   insert into clientes (nombre) values (:name);

 

if sqlcode < 0;

   // log error

endif;

 

Conclusion

By focusing on the areas that generate most of the errors, we can significantly improve software quality and development team efficiency.
Applying the Pareto Principle in RPGLE development allows us to prioritize efforts and resources where they are most needed.

Have you identified similar patterns in your projects?
Share your experiences and strategies for mitigating common errors in RPGLE and SQLRPGLE development!

 

If you find it interesting, share it or forward it to a friend. Knowledge is valuable, Share it!

Share your experience in the comments!

Until Next time!

_________________________________________________

Principio de Pareto en el Desarrollo RPG: el 20% que causa el 80% de los errores

 

"La distribución del esfuerzo no es uniforme: una minoría de causas produce la mayoría de los efectos."
— Vilfredo Pareto

 

¿Qué es el Teorema de Pareto?

El Teorema de Pareto, también llamado Principio 80/20, establece que el 80% de los resultados proviene del 20% de las causas.
Por ejemplo:

• El 80% de las ventas puede venir del 20% de los clientes.
• El 80% de los errores en un programa puede originarse en el 20% del código.
• El 80% de los problemas puede solucionarse enfocándose en el 20% de los factores críticos.

Este principio no siempre es exactamente 80/20, pero ilustra una desigualdad natural que ayuda a priorizar esfuerzos de forma inteligente.

 

En el mundo del desarrollo de software, y específicamente en el entorno IBM i con RPGLE, es esencial identificar y abordar los errores más comunes para mejorar la calidad del código y la eficiencia del equipo. Aplicando el Principio de Pareto, que sugiere que el 80% de los problemas provienen del 20% de las causas, podemos focalizar nuestros esfuerzos en las áreas que más impacto tienen.

 

Errores más frecuentes en RPGLE

Basándonos en análisis de errores comunes en RPGLE, se identifican los siguientes como los más recurrentes:

1. Errores de datos decimales (MCH1202): Ocurren cuando se intenta utilizar datos numéricos no inicializados o se asignan datos no numéricos a variables numéricas.
2. Errores de SQL en RPGLE:
• SQLCODE -204: Objeto no definido.
• SQLCODE -803: Violación de restricción única.
• SQLCODE -305: Valor nulo no permitido.

 

Distribución de errores y el Principio de Pareto

Aunque no se dispone de estadísticas exactas, la observación en proyectos de desarrollo sugiere la siguiente distribución aproximada:

• Errores de datos decimales: 40%
• Errores de SQL: 35%
• Errores de sintaxis y compilación: 15%
• Otros errores: 10%

Aplicando el Principio de Pareto, se observa que el 75% de los errores provienen de los errores de datos decimales y de SQL, que representan aproximadamente el 20% del total de posibles causas de errores.

 

Estrategias para mitigar los errores más comunes

1. Inicialización de variables: Asegurarse de que todas las variables numéricas estén correctamente inicializadas antes de su uso para evitar errores de datos decimales.
2. Validación de datos de entrada: Implementar validaciones rigurosas para los datos que ingresan al sistema, especialmente aquellos que interactúan con la base de datos.
3. Manejo adecuado de errores SQL: Utilizar estructuras como SQLCA para capturar y manejar errores de SQL de manera efectiva.

 

3.1 Estrategias para mitigar los errores comunes en SQLRPGLE

Basado en análisis de experiencias en campo, foros técnicos y publicaciones de IBM, estos son los errores más frecuentes:

Error	Descripción	Aproximado % de incidencia
SQLCODE -305	Intento de insertar NULL donde no se permite	30%
SQLCODE -204	Objeto (tabla o vista) no encontrado	25%
SQLCODE -802	Error de aritmética (por ej. división por cero)	15%
Errores de conversión de datos	Asignación entre tipos incompatibles (ej. char a dec)	15%
Errores de lógica de control de flujo	Mal uso de fetch, open o bucles do while con cursores	15%

Resultado: 70% de los errores provienen solo de dos tipos de fallos: inserción de datos NULL incorrectamente, y uso de objetos inexistentes o mal definidos. Exactamente el 20% del tipo de errores, generando el 80% de los dolores de cabeza.

 

Aplicando el Teorema de Pareto

🔧 Si educamos y reforzamos buenas prácticas en el tratamiento de NULL y en la validación de existencia de objetos SQL antes de usarlos, podríamos prevenir hasta el 70–80% de los errores de ejecución en SQLRPGLE.

 

Recomendaciones prácticas

1. Controla el uso de NULLs desde el diseño:

• Declara correctamente columnas con NOT NULL DEFAULT para evitar insertar valores nulos accidentalmente.
• Usa %NULLIND y IF :NOMBRE_IND = -1 en RPGLE para validar entrada nula.

 2. Verifica existencia de objetos SQL:

• Usa SYSCOLUMNS o SYSTABLES antes de referenciar una tabla/vista.
• Maneja SQLSTATE y SQLCODE luego de cada EXEC SQL.

exec sql

   select count(*) into :cantidad

   from qsys2.systables

   where table_name = 'CLIENTES';

 

if cantidad = 0;

   // Crear tabla o lanzar mensaje

endif;

 3. Usa monitores de error.

exec sql

   insert into clientes (nombre) values (:nombre);

if sqlcode < 0;

   // log de error

endif;

 

Conclusión

Al enfocarnos en las áreas que generan la mayoría de los errores, podemos mejorar significativamente la calidad del software y la eficiencia del equipo de desarrollo. Aplicar el Principio de Pareto en el desarrollo de RPGLE nos permite priorizar esfuerzos y recursos en las áreas que más lo necesitan.

¿Has identificado patrones similares en tus proyectos? Comparte tu experiencia y estrategias para mitigar errores comunes en el desarrollo de RPGLE y en SQLRPGLE.

Si te pareció interesante, compártelo o reenvíalo a un amigo. El conocimiento es valioso, compártelo. 

¡Comparte tu experiencia en los comentarios!

¡Hasta la próxima!

 

 

 

The most common IBM i (RPGLE/SQLRPGLE) nightly batch errors/Los errores más comunes en cierres nocturnos de IBM i (RPGLE/SQLRPGLE) que pueden costarte caro

 

 You can read this post in any language by clicking on this gadget  =======>

  (Puedes leer esta publicacion en cualquier idioma haciendo click en esta aplicación)

*You can read this article in Spanish more down below in this same publish. (Puedes leer este artículo en español más abajo en esta misma publicación)

  The most common IBM i (RPGLE/SQLRPGLE) nightly batch errors that can cost you… and how to prevent them

Nightly batch processes in IBM i (AS400) are critical as they consolidate transactions, update reports, and prepare data for the next business day. However, execution issues can impact system performance and stability. Here are the most frequent problems and their solutions.

 

1️-Record and File Locks (Record Locks & File Locks)

 Issue:

• A job locks a record or file, preventing other processes from accessing the data.
• SQLRPGLE programs using commit/rollback may leave records locked if the transaction doesn’t complete correctly.

Solution:

 Use WITH NC (No Commit) in SQL queries when transactions are unnecessary.
Release locks using STRDBMON to identify problematic sessions.
 Implement automatic retry mechanisms (MONITOR/ON-ERROR) for locked records.

Example of SQL without unnecessary locks:

SELECT * FROM customers WITH NC;

 

2️-Poor SQL and RPGLE Performance

Issue:

• SQL queries scanning large datasets without proper indexing.
• RPGLE programs using inefficient loops over large files.
• Jobs loading excessive data into memory.

Solution:
Analyze the execution plan (EXPLAIN PLAN) and add indexes to key tables.

===============
Example: Using EXPLAIN PLAN in IBM i (SQLRPGLE) for Performance Optimization

A-Creating a Temporary Table to Store Execution Plans

Before using EXPLAIN PLAN, we need a table to store the analysis results. If you don’t have one, create it like this:

CREATE TABLE QTEMP.EXPLAIN_PLAN (

    QUERYNO INT,

    SEQNO INT,

    OPERATION CHAR(20),

    OBJECT_NAME CHAR(30),

    INDEX_NAME CHAR(30),

    ESTIMATED_COST DECIMAL(10,2)

);

 

B.-Generating the Execution Plan for a Query

Let’s analyze a query that retrieves recent orders:

EXPLAIN PLAN SET STATEMENT_ID = 'PLAN1'

FOR 

SELECT * FROM orders WHERE date >= CURRENT DATE - 30 DAYS;

 

C.-Viewing the Execution Plan Results

After running EXPLAIN PLAN, we can examine its output:

SELECT * FROM TABLE(QSYS2.EXPLAIN_FORMAT('PLAN1')) ORDER BY SEQNO;

 Key Insights from the Results:

• Operation: Whether an INDEX SCAN or TABLE SCAN was used.
• Object Name: The table being analyzed.
• Index Name: Shows if an index was applied.
• Estimated Cost: The estimated resource usage.

 

D-Optimization: Adding an Index to Improve Query Performance

If EXPLAIN PLAN shows a TABLE SCAN, we can optimize the query by creating an index on the date column:

CREATE INDEX idx_orders_date ON orders (date);

Then, we rerun the query and EXPLAIN PLAN to check if it now uses INDEX SCAN.

 

Conclusion

 EXPLAIN PLAN helps detect slow queries and improve performance by adding indexes or restructuring SQL.
Minimizing TABLE SCAN with proper indexing significantly enhances execution speed on IBM i.

================

 

3.-Use OPTIMIZE FOR n ROWS to limit the number of fetched rows.
Process data in small batches instead of handling large volumes in memory.

Optimized SQL Example:

SELECT * FROM transactions WHERE date >= CURRENT DATE - 1 DAY OPTIMIZE FOR 100 ROWS;

 

4-Insufficient Disk Space (ASP Usage High)

Issue:

• Large temporary data volumes consume disk space (ASP - Auxiliary Storage Pool).
• Work files or logs are not cleaned up after use.
• Jobs generating uncontrolled output files.

 Solution:
Use SQL DELETE with commit to clean up old data in batches.
Automate log cleanup using CLP (RMVLNK or DLTF).
Monitor disk space (WRKSYSSTS or DSPSYSSTS) before batch execution.

Example of automatic log cleanup:

DELETE FROM logs WHERE date < CURRENT DATE - 30 DAYS;

 

5-Concurrency Issues (Multiple Jobs Updating the Same Data)

Issue:

• Multiple jobs updating the same records simultaneously.
• Data inconsistencies due to update conflicts.

Solution:
Sequence job execution based on priority.
Implement exclusive locks (LOCK TABLE or CHGOBJ) when needed.
Use temporary files (QTEMP) to minimize impact on production tables.

Concurrency Control Example:

LOCK TABLE inventory IN EXCLUSIVE MODE;

UPDATE inventory SET stock = stock - 1 WHERE product_id = 123;

COMMIT;

UNLOCK TABLE inventory;

 

 6-Jobs Stuck in MSGW (Message Waiting) State

Issue:

• A job waits for manual intervention (*MSGW), halting the entire process.
• SQL or RPGLE errors generate messages that block execution.

Solution:
Configure error handling (MONITOR/ON-ERROR) in RPGLE to prevent manual stops.
Use QSYSOPR to capture and auto-respond to messages (QCMDCHK).
Monitor jobs using QZRCSRVS or WRKACTJOB to avoid long-running stuck processes.

Error Handling in RPGLE Example:

Monitor; 

   Exec SQL UPDATE orders SET status = 'CLOSED' WHERE date < CURRENT DATE - 1 DAY;

On-Error; 

   Dsply 'Error in order closure'; 

EndMon;

 

Conclusion: Implementing Best Practices to Avoid Failures

To minimize risks in IBM i nightly processes, follow these best practices:

Optimize SQL with indexes and OPTIMIZE FOR.
Avoid locks with WITH NC and controlled commits.
Monitor disk space and remove unnecessary files.
Ensure concurrency control with LOCK TABLE when required.
Automate error handling to prevent manual interventions.

Expected Outcome: Fewer failures, reduced execution time, and greater system stability.

 

 

If you find it interesting, share it or forward it to a friend. Knowledge is valuable, Share it!

Share your experience in the comments!

 

Until Next time!

 

---------------

Los errores más comunes en cierres nocturnos de IBM i (RPGLE/SQLRPGLE) que pueden costarte caro… y cómo prevenirlos

Los procesos de cierre nocturno en sistemas IBM i (AS400) suelen ser críticos, ya que consolidan transacciones, actualizan reportes y preparan datos para el siguiente día. Sin embargo, pueden presentar problemas de ejecución que afectan la operatividad del negocio. A continuación, te detallo los errores más comunes y cómo prevenirlos.

 

1️-Bloqueos de Registros y Archivos (Record Locks & File Locks)

Problema:

• Un trabajo mantiene bloqueado un registro o archivo, impidiendo que otros procesos accedan a los datos.
• Los programas SQLRPGLE que usan commit/rollback pueden dejar registros bloqueados si la transacción no finaliza correctamente.

Solución:
 Usar WITH NC (No Commit) en consultas SQL cuando no se requiera transaccionar.
Liberar bloqueos con STRDBMON para detectar sesiones problemáticas.
Implementar reintentos automáticos (MONITOR/ON-ERROR) si un registro está bloqueado.

    Ejemplo de SQL sin bloqueos innecesarios:

SELECT * FROM clientes WITH NC;

 

2️-Bajo Rendimiento en Consultas SQL y Procesos RPGLE

 Problema:

• Consultas SQL que recorren grandes volúmenes de datos sin índices adecuados.
• RPGLE con bucles innecesarios que procesan millones de registros.
• Procesos que cargan demasiada información en memoria.

Solución:
1.-Revisar el plan de ejecución (EXPLAIN PLAN) y agregar índices en tablas críticas.

Ejemplo práctico de cómo usar EXPLAIN PLAN en IBM i (AS400) para analizar el rendimiento de una consulta SQL y optimizarla si es necesario.

 

==============

Ejemplo: Uso de EXPLAIN PLAN en IBM i (SQLRPGLE)

A-Crear una Tabla Temporal para Almacenar el Plan de Ejecución

Antes de ejecutar EXPLAIN PLAN, es necesario tener una tabla donde se guardará la información del análisis. Si no tienes una, puedes crearla así:

CREATE TABLE QTEMP.EXPLAIN_PLAN (

    QUERYNO INT,

    SEQNO INT,

    OPERATION CHAR(20),

    OBJECT_NAME CHAR(30),

    INDEX_NAME CHAR(30),

    ESTIMATED_COST DECIMAL(10,2)

);

 

B-Generar el Plan de Ejecución de una Consulta

Supongamos que queremos analizar una consulta que obtiene pedidos recientes:

EXPLAIN PLAN SET STATEMENT_ID = 'PLAN1'

FOR 

SELECT * FROM pedidos WHERE fecha >= CURRENT DATE - 30 DAYS;

---

C-Consultar el Plan de Ejecución Generado

Después de ejecutar EXPLAIN PLAN, podemos analizar su resultado con esta consulta:

SELECT * FROM TABLE(QSYS2.EXPLAIN_FORMAT('PLAN1')) ORDER BY SEQNO;

Qué buscar en los resultados:

• Operation: Indica si se usó un índice (INDEX SCAN) o un recorrido completo (TABLE SCAN).
• Object Name: Muestra la tabla analizada.
• Index Name: Si hay un índice en uso, se muestra aquí.
• Estimated Cost: Costo estimado en términos de recursos del sistema.

 

D-Optimización: Agregar un Índice para Mejorar Rendimiento

Si EXPLAIN PLAN indica que se está haciendo un TABLE SCAN, podemos optimizar la consulta creando un índice en la columna fecha:

CREATE INDEX idx_pedidos_fecha ON pedidos (fecha);

Y luego, volvemos a ejecutar la consulta y EXPLAIN PLAN para verificar si ahora usa el índice (INDEX SCAN).

 

 Conclusión

EXPLAIN PLAN ayuda a detectar consultas lentas y a mejorar su rendimiento mediante la creación de índices o reescritura de SQL.
Reducir TABLE SCAN usando índices optimizados acelera la ejecución de procesos en IBM i. 🚀

 

=================

3.-Usar OPTIMIZE FOR n ROWS en SQL para limitar la cantidad de datos recuperados.
Procesar datos en bloques pequeños en lugar de manejar grandes volúmenes en memoria.

Ejemplo de SQL optimizado:

SELECT * FROM transacciones WHERE fecha >= CURRENT DATE - 1 DAY OPTIMIZE FOR 100 ROWS;

 

4-Falta de Espacio en Disco (ASP Usage High)

Problema:

• Grandes volúmenes de datos temporales ocupan espacio en el disco (ASP - Auxiliary Storage Pool).
• Archivos de trabajo o logs no se eliminan después de usarse.
• Jobs que generan archivos de salida sin control de crecimiento.

Solución:
Usar SQL DELETE con commit para limpiar datos innecesarios en lotes.
Automatizar eliminación de logs antiguos con un programa CLP (RMVLNK o DLTF).
Monitorear espacio en disco (WRKSYSSTS o DSPSYSSTS) antes del cierre nocturno.

Ejemplo de eliminación automática de archivos viejos:

DELETE FROM logs WHERE fecha < CURRENT DATE - 30 DAYS;

 

 5-Problemas de Concurrencia (Multiple Jobs Affecting the Same Data)

Problema:

• Varios trabajos nocturnos intentan actualizar los mismos registros al mismo tiempo.
• Se generan inconsistencias en los datos por conflictos de actualización.

Solución:
Secuenciar la ejecución de procesos según prioridad.
Implementar bloqueos exclusivos (LOCK TABLE o CHGOBJ) si es necesario.
Usar archivos temporales (QTEMP) para minimizar impacto en tablas principales.

Ejemplo de control de concurrencia en SQL:

LOCK TABLE inventario IN EXCLUSIVE MODE;

UPDATE inventario SET stock = stock - 1 WHERE producto_id = 123;

COMMIT;

UNLOCK TABLE inventario;

 

6-Jobs que No Terminan o Quedan en Estado MSGW (Message Waiting)

Problema:

• Un trabajo espera una respuesta manual (*MSGW), deteniendo el proceso nocturno.
• Errores en SQL o en RPGLE lanzan mensajes de error que bloquean la ejecución.

Solución:

 Configurar manejo de errores (MONITOR/ON-ERROR) en RPGLE para evitar interrupciones.
Usar QSYSOPR para capturar mensajes y responder automáticamente (QCMDCHK).
Monitorear procesos con QZRCSRVS o WRKACTJOB para evitar jobs colgados.

Ejemplo de manejo de errores en RPGLE:

Monitor; 

   Exec SQL UPDATE pedidos SET estado = 'CERRADO' WHERE fecha < CURRENT DATE - 1 DAY;

On-Error; 

   Dsply 'Error en cierre de pedidos'; 

EndMon;

 

Conclusión: Implementar Buenas Prácticas para Evitar Fallos

Para minimizar riesgos en los procesos nocturnos en IBM i, sigue estas prácticas:

Optimiza SQL con índices y OPTIMIZE FOR.
Evita bloqueos con WITH NC y commits controlados.
Monitorea espacio en disco y elimina archivos temporales.
Asegura la concurrencia con LOCK TABLE cuando sea necesario.
Automatiza manejo de errores para evitar interrupciones manuales.

Resultado esperado: Menos fallos en cierre nocturno, reducción de tiempo de ejecución y mayor estabilidad del sistema.

 

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

¡Comparte tu experiencia en los comentarios!

¡Hasta la próxima!

 

    Autor: Ing. Liliana Suárez

 

You can read this post in any language by clicking on this gadget  =======>

  (Puedes leer esta publicacion en cualquier idioma haciendo click en esta aplicación)

Can we trust the programmers? / ¿Podemos Confiar en los Programadores?

*You can read this article in Spanish more down below in this same publish. (Puedes leer este artículo en español más abajo en esta misma publicación)

 

"The biggest fraud in code is not just a malicious line, but the blind trust that 'it will never happen here.' Code without controls is an open invitation to disaster."

Efforts to prevent fraud in access to information in the As400 ibm have been concentrated on using mechanisms such as double validation (use of a token), authority levels, role assignment, group profiles, among others.

It should be noted that once inside the system, the danger has not ceased. It is important to direct our gaze to the programming code developed by programmers.

There may be very sensitive information embedded in the source code of programs that escapes the naked eye.

In my experience, the use of hard code in programs can be very risky if you do not have efficient audit mechanisms to detect a fraud situation in time.

I heard of a developer who didn't pay his phone bill for six months because he had hard-coded the program with a zero balance to pay each time the read cycle read his phone number. Six months later he was discovered and fired. The developer had been assigned to the bank's direct debit payment system.

Direct debit payment systems generate automatic charges against customer accounts for any of the following services or recurring agreements that the customer wishes to pay automatically: telephone, electricity, apartment rental, gas, subscriptions.

You might be wondering at this point: does anyone still use hardcoding in programs?

Of course, hard code is used in those variables or constants that range between two or three values ​​and beyond that it is not worth creating tables for those cases.  A typical example refers to the status of a data: Active/Inactive. This is obviously harmless.

It is important to check if the source code exists:

-Variable names that do not represent the data they contain.

Many times we take more care of the forms than the content. They start with a certain letter that may or may not have more or fewer characters, but we don't pay attention to whether the name represents the data it contains.

Arrangements preloaded in the source.

These are arrays whose contents are loaded at compile time.(Time-compile Arrays)

It is necessary to check if data of this type is inserted in these “pre-loaded” arrangements:

• Local telephone area codes

• Gas, electricity contract numbers

• Accounting accounts.

• Identification cards or documents

Concatenation or separation of characters.

You can hide hard code by combining characters like:

Currency-country = 'U' + 'S' + 'D'

 

In general, code review should be delegated to the technical leader.

Although each facility may purchase or develop certain home-grown tools to review code and generate alerts, these tools are not a substitute for human review whose vision is interpretive and not mechanical.

Developing in Rpgle on an Ibm-i platform presents very interesting challenges. In the next post we will review other topics about RPGLE Ibm-I development

Until next time!

¿Podemos Confiar en los Programadores?

 

"El mayor fraude en el código no es solo una línea maliciosa, sino la confianza ciega en que ‘aquí nunca pasará’. Un código sin controles es una invitación abierta al desastre."

Se han concentrado los esfuerzos para prevenir el fraude en el acceso a la información en el As400 ibm en utilizar mecanismos como la doble validación (uso de un token), niveles de autoridad, asignación de roles, perfiles de grupo, entre otras.

Cabe destacar que una vez dentro del sistema, el peligro no ha cesado. Es importante dirigir nuestra mirada al código de programación desarrollado por los programadores.

Puede haber información muy sensible inmersa en el código fuente de los programas que se escapa a simple vista.

En mi experiencia, el uso de código duro en los programas puede ser muy riesgoso si no se tienen los mecanismos de auditoria eficientes para detectar a tiempo una situación de fraude.

Conocí el caso de un desarrollador que no pago su factura de teléfono durante seis meses porque había colocado en el programa en código duro un saldo cero a pagar cada vez que el ciclo de lectura leía su número de teléfono. Seis meses después fue descubierto y despedido. El desarrollador había sido asignado al sistema de domiciliación de pagos de la entidad bancaria.

 

Los sistemas de domiciliación de pagos generan cargos automáticos contra las cuentas de los clientes por alguno de los siguientes servicios o convenios recurrentes que el cliente desea pagar de manera automática: teléfono, electricidad, alquiler de apartamento, gas, suscripciones.

Se preguntarán en este momento: ¿todavía alguien usa código duro en los programas?

Por supuesto que se usa código duro en aquellas variables o constantes que oscilan entre dos o tres valores y más allá de eso no vale la pena crear tablas para esos casos.  Un ejemplo típico se refiere al estatus de una data: Activo/Inactivo. Esto es obviamente inofensivo.

Es importante revisar si en el código fuente existen:

-Nombres de variables que no representan la data que contienen.

Muchas veces cuidamos mas las formas que el contenido. Que comiencen con cierta letra que tengan o no más o menos caracteres, pero no prestamos atención si el nombre representa la data que contiene.

-Arreglos precargados en el fuente.

Estos son arreglos cuyo contenido se carga a tiempo de compilación.

 

Es necesario revisar si en estos arreglos “pre-cargados” esta insertada data de este tipo:

·       Códigos de área de teléfonos locales

·       Números de contrato de gas, electricidad

·       Cuentas contables.

·       Cédulas o documentos de identidad

 

-Concatenacion o separación de caracteres.

Se puede esconder código duro concantenando caracteres como:

Moneda-pais = ‘U’ + ‘S’ + ‘D’

En general se debe delegar en el líder técnico la revisión del código.

Aunque cada instalación puede comprar o desarrollar ciertas herramientas caseras para revisar el código y generar alertas, estas herramientas no sustituyen la revisión por parte del ser humano cuya visión es interpretativa y no mecánica.

Desarrollar en Rpgle en una plataforma Ibm-i presenta retos muy interesantes. En la próxima entrega revisaremos otros tópicos sobre el desarrollo en RPGLE Ibm-I

 

¡Hasta la próxima!

 

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

    Autor: Ing. Liliana Suárez