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.

Comandos CL en Programas en RPG-Free

Bienvenidos a Iseries Venezuela!

En esta oportunidad vamos a mostrar como realizar comandos CL en programa en RPG Free.

En los programas desarrollados en RPG III es realmente tortuoso incorporar un comando CL dentro de un programa RPG. Se ejecuta una llamada aun programa llamado: 'QCMDEXEC.' suministrado por la plataforma del equipo. Con comandos simples como eliminar o reorganizar un archivo ejecutar este programa era relativamente sencillo de implementar. Sin embargo, cuando se trataba de enviar parámetros y de monitorear el resultado de ejecutar el comando, el tema se complicaba mucho mas. La mayoría de los programadores preferimos invocar un programa CLP que ejecutara el comando y  quitarnos ese dolor de cabeza de encima.

Con el avance de RPG podemos desarrollar un código estandard para control u monitoreo de errores y ejecución de comandos.

En el siguiente ejemplo:

1.-Se declara un procedure externo 'QCMDEXEC'
2.-Se declara la variable donde se va a almacenar el comando
3.-Se declara la estructura de datos de estatus del programa en forma estratégica
4.-Se construye el comando con parámetros
5.-Se monitorean los errores de ejecución.

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

     d*Declaración del procedure
     d@runsyscmd       pr                  extpgm('QCMDEXC')
     d cmd                          200a   options(*varsize) const
     d cmdlen                        15p 5 const
     d*Variable donde se almacenará el comando a ejecutar
     d  clpstm         s            180a
     d*Párametros que se enviaran en el comando
     d  Cliente        s              10a
     d  Pedido         s              10a
     
      * Program status data structure
     d                sds
     dPgmName                 1     10
     dCoderr                     40     46  -->  Código de error CPFXXXX
     dtxterr                      91    170   --> Capturar el texto del error
     dEstacion               244    253
     dusuario                 254    263
     djobdate                 270    275  0
     dFechajob              270    275  0
     ddiajob                   270    271  0
     dmesjob                 272    273  0
     danojob                  274    275  0
     dhorajob                282    287  0

            monitor;   //monitorear el error
                 clpstm =  //construcción del comando

              'SBMJOB CMD(CALL PGM(Facturar) parm(' +
               Cliente + ' ' + Pedido +  '))' +
              ' Job(' + 'FA' + %trim(%subst(Pedido:1:8)) + ')';

               @runsyscmd(clpstm : %size(clpstm));  //ejecuta el comando

               on-error;
                 //   Graba_Errores;
                 Errcod = coderr;
                 Errmsj = txterr;
                 nomusu = usuario;
                 nomjob = 'FA'+ %Trim(%subst(Pedido:1:8));
                 dispos = estacion;
                 hora = horajob;
                 fecha = fechajob;
                 write en archivo de errores
                 msj_sfl = 'Errores en el comando, revise Log';
               endmon;

-------------------------------------------------------------
En este código sometemos un programa llamado FACTURAR que se encargará de generar la factura para el cliente almacenado en la variable CLIENTE según el pedido guardado en la variable PEDIDO

En forma sencilla se puede ejecutar cualquier comando en CLP con o sin parámetros sin que represente una diferencia significativa en el desarrollo del código.  También podemos monitorear el resultado de la ejecución y grabarlo en algún archivo, grabando ademas el nombre del job fallido de manera de identificar el pedido que no pudo ser facturado. Con este procedimiento podemos hacer seguimiento o auditoria del proceso.

En este enlace puedes descarga el código fuente que ves en este artículo. Haz click aquí:

Descarga Código Fuente del Programa

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

La Importancia de tener un Máster Mind

Se define Máster Mind a un equipo de trabajo conformado por “Mentes Maestras” encargado de dar seguimiento y brindar asesoría a los ejecutivos de un proyecto.

Tradicionalmente el análisis de los requerimientos de un proyecto lo realiza un analista o un líder de proyecto en solitario,  quien se encarga de reunirse con el usuario y definir las solicitudes y objetivos que debe cumplir el desarrollo tecnológico a su cargo.

Se ha comprobado que el trabajo en equipo es más eficiente y dinámico a la hora de generar ideas creativas y novedosas que aportan mejores oportunidades operativas y  funcionales al desempeño de las operaciones del negocio.

El dicho que reza: “dos cabezas piensan más que una” tiene una gran dosis de sabiduría que debe tenerse en cuenta a la hora de definir un proyecto.

El  Máster Mind está idealmente conformado por integrantes de la organización y asesores externos que se encargaran de revisar cada cierto tiempo el desarrollo del proyecto.

La sinergia de un equipo de trabajo es incomparable e impredecible en cuanto al resultado óptimo y creativo de soluciones y creación de nuevos proyectos con visión de futuro y de proyección a nuevos nichos de mercado.

Es importante que quienes realicen la definición del proyecto no solo tengan una idea del funcionamiento del negocio sino de su adaptabilidad en el tiempo y de la captura de nuevos clientes potenciales al momento de definir el alcance del proyecto.

Debe incluirse como parte integrante de este equipo Máster Mind estrategas del negocio que tengan una visión clara del movimiento tecnológico del mercado y del posicionamiento de la competencia.

Cabe destacar que, cada reunión debe culminar con un conjunto de acciones concretas que tengan un límite de tiempo y que sean visibles, tangibles y evaluables. Esto para evitar reuniones inútiles sin resultados concretos. Este modelo de trabajo aunque ha sido exitoso en otras latitudes, debe ser implementado con estricto control en nuestros países latinos. Los latinoamericanos somos expertos en

El Peor Escenario

Hola! Bienvenidos a Iseries Venezuela. 

Que sea un año  venturoso y lleno de dicha y progreso para todos!

En esta oportunidad veremos maneras de proteger nuestro esfuerzo y trabajo como Gerentes de Sistemas, comenzando un nuevo año con buen pie!.

Muchos millonarios una vez que han acumulado una gran masa de dinero deben pensar en alternativas para proteger y salvaguardar sus bienes. Una mala inversión puede ser desastrosa como ha ocurrido con Donald Trump. Aprendida la lección, muchos de ellos utilizan la técnica de  imaginar el peor escenario que puede ocurrir y tomar medidas preventivas contra eso. Una vez cubiertas todas las bases que comprenden el peor escenario, la operativa de los negocios continúa sin mayores riesgos financieros.

Desde el punto de vista de desarrollo de software podemos imaginar el peor escenario y protegernos contra eso.

Factores que, en mi opinión,  deben ser considerados en el Peor Escenario.

1.-Perdida, corrupción o inconsistencia de la data.

Acciones preventivas:

• ·        Revisar Periodicidad de los Backups.
• ·        Reprocesamientos recurrentes.
• ·        Revisar memoria y discos.
• ·        Definición de Journals/diarios de los archivos.
• ·        Auditoría regular de la data.

2.-Pérdida de Archivos Fuentes.

Acciones preventivas:

•  Compilar los fuentes de ILE dbgview(*ALL) o dbgview(*LIST) estos valores permiten recuperar un fuente RPGLE o SQLRPGLE. En este enlace pueden descargar las utilidades para recuperar fuentes y muchas otras utilidades más. 

Recuperación de Fuentes y otras Utilidades

3.-Reprocesamiento

Acciones preventivas:

• Mantener una estadística de procesos que fallan repetidamente y tomar las medidas correctivas lo antes posible. Un proceso inestable es una fuente de riesgo importante para la operatividad del negocio

4.-Seguridad de Acceso.

Acciones preventivas:

•  Revisar regularmente quién hace qué.

Hay empleados que se han retirado de la empresa y sin embargo, pasado cierto tiempo conservan sus claves y usuarios de acceso, así como los objetos ejecutables que dejaron en disco. Otros empleados son trasladados a distintas sucursales del negocio o a distintos puestos de trabajo con otras funciones diferentes a las que estaban haciendo anteriormente y sin embargo conservan el acceso al sistema con el cargo anterior mas la nueva clave o usuario del cargo actual.

5.-Actualización de Licencias.

Acciones preventivas:

• ·        Revisar el vencimiento de las licencias oportunamente.

Justamente al momento de realizar una entrega con carácter de urgencia aparece el mensaje de Ibm advirtiéndonos de que ciertas funciones o comandos no se pueden ejecutar. Para evitar este inconveniente, tener un calendario de vencimiento de licencia por equipo y producto instalado para renovar la licencia a tiempo.

• ·        Revisar si es necesario ampliar el número de licencias por expansión del negocio.

Nos acostumbramos a que fulano tenga acceso al uso de x producto y vamos pasándonos la clave de unos a otros, porque la tarea debe realizarse con los recursos que se tiene y “como sea”. Esto representa un riesgo innecesario de seguridad. Empleados con menos jerarquía de acceso pueden obtener información confidencial del negocio.

6.-Fraudes.

Acciones preventivas:

• ·        Monitorear los horarios de accesos del personal a los sistemas y evaluar el perfil estadístico para detectar cual acceso se ha salido del comportamiento normal.
• ·        Adquirir software especializado para detección de fraude.
• ·        Atomizar los procesos al asignarlos a los empleados de informática.

Esta “solución” tiene detractores y fanáticos. Sin embargo, la expongo aquí porque existe como opción y está siendo aplicada en varias organizaciones. Hay instituciones que fragmentan el conocimiento de un proceso en partes muy específicas a fin de que los analistas de sistemas solo vean sub-módulos o programas de distintas áreas del negocio sin conexión lógica entre sí.

Este procedimiento procura evitar el fraude interno pero tiene el inconveniente de que a la hora de resolver un problema por falla o caída del sistema,  no se cuenta con un profesional capaz de hacer frente a la situación dado el desconocimiento integral del proceso o los procesos involucrados en el problema.

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