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:
- Decimal Data Errors (MCH1202):
Occur when trying to use uninitialized numeric data or assigning
non-numeric data to numeric variables.
- 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
- Variable Initialization:
Ensure that all numeric variables are properly initialized before use to avoid decimal data errors. - Input Data Validation:
Implement rigorous validations for incoming data, especially data interacting with the database. - 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:
- 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.
- 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
- 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.
- 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.
- 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!
