Better Performance with the command TFRCTL/Mejor Performance con el comando TFRCTL

 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)

 El comando TFRCTL es utilizado en programas CLP y trabaja solamente en entorno OPM. No funciona en entorno ILE. 

TFRCTL es un comando poco conocido que puede ayudar a reducir el tiempo de respuesta en procesos que tienen una secuencia de llamadas entre varios CLP  y que no requieren un entorno ILE.

 Cuando se ejecuta un programa, el sistema destina un espacio de memoria. En este espacio se almacen la información necesaria para que  el código del programa sea ejecutado y ademas las direcciones necesarias para que el programa "hijo" pueda devolver el control al programa "padre" una vez finalizada la ejecución del programa "hijo". 

En el ejemplo a continuación, el programa CLPB transfiere el control al programa CLPC utilizando el comando TFRCTL

A continuación vamos a descifrar que significa todo esto.

El comando TFRCTL se construye de la siguiente manera: 

TFRCTL PGM(library-name/program-name) PARM(CL-variable)

La siguiente gráfica puede ser ampliada haciendo click sobre ella.

 

Se puede apreciar en la secuencia de llamadas que el programa CLPC no retorna a su  programa "padre" CLPB,  sino que regresa al programa "abuelo" CLPA.

Pointers (Apuntadores) en RPGLE ¿Que son y para que sirven?

                       

Un apuntador o "pointer" es una variable que contiene la direccion de almacenamiento en memoria de otra variable o de un procedure. En la siguiente imagen tenemos un ejemplo hipotético de almacenamiento en memoria.

 

 

 

Supongamos que tenemos una variable tipo char declarada de 70 posiciones.

 A esa variable la llamaremos: mitexto char(70)

mitexto, según la siguiente imagen, comienza en la dirección de memoria:0000

Aunque en nuestro código de programación podemos manipular la varible mitexto, en realidad no sabemos en cual dirección de memoria es almacenada la data que contiene y, a decir verdad, a nadie le interesa saberlo a menos que, conocer su dirección en memoria y manipularla tuviese alguna utilidad.

En Rpgle Free la variable apuntador se declara asi: dcl-s Apuntador pointer;

En Rpg No free:  D    Apuntador  S      *  //el asterisco indica que es tipo apuntador

Una variable tipo pointer puede contener la dirección en memoria de una variable o de un procedure. 

Para declarar un apuntador que apunta a un procedure: 

RPGLE NO Free: se agrega en la declaracion de la variable tipo apuntador la palabra clave PROCPTR

RPGLE FREE: se agrega la palabra clave POINTER(*PROC) en lugar de pointer

Un  apuntador que es utilizado para "apuntar a la dirección" de  una variable,  una estructura de datos o a un arreglo se denomina "Basing Pointer". 

 Veamos algunos de los beneficios que aporta utilizar apuntadores:

JSON para desarrolladores en RPGLE IBM, Iseries/JSON for RPGLE Developers

                         

JSON son las siglas de Java Script Object Notation

 Se trata de un Standard internacional para dar formato al envío de la data entre dos plataforma o entre dos lenguajes de programación.

 A partir del 2015 se popularizó este formato superando con creces al formato estandard XML que hasta ese entonces reinaba sin competencia alguna.

Algunos expertos coincide en que JSON ocupa menos espacio y es mas sencillo de interpretar que XML.

JSON soporta los siguiente tipos de data:

• Numerico
• String
• Arreglos (Array)
• Objetos (Ds= Data Structure, en el caso de RPGLE IBM)
• Boleanos = true/false
• Nulos = null       
  

Para identificar las estructuras de data la sintaxis es la siguiente:

•  Inicio y fin de data structure (DS): { }  Llave que abre y cierra respectivamente
•  Inicio y fin de un arreglo : [ ]  Corchete que abre y cierra respectivamente

Para identificar los elementos simples dentro de las estructuras:

•    "Nombre del elemento": valor del elemento
•     Los elementos se separan con coma. (,)

El stream de envio siempre comienza con { y termina con }

Veamos el siguiente ejemplo:

Supongamos que queremos enviar en formato JSON los datos contenidos en la siguiente estructura de RPG. DS = Data Structure

 

 Pasos a seguir:

1.-Entender el significado de la estructura que vamos a enviar. En este caso, vamos a enviar el saldo final y el saldo promedio de la cuenta de un cliente de los ultimos tres meses del año 2022 y 2021. Primero el año 2022 y luego el año 2021.

2.-Interpretar la estructura correctamente. Muy Importante!!!

 Se trata de enviar una estructura que contiene 

• Un elemento simple:  ClientId 
• Un arreglo de dos elementos: DS_Account. 

       Los elementos del arreglo DS_Account son a su vez, DS.

3.-Colocar la sintaxis correspondiente.

     Enviar un objeto (DS) que tiene:

 {  "Ds_client": {

       A.- Un campo simple (Clientid)  "ClientId": "EX-8976531234" 

       B.- Un arreglo: DS-Account   [

          Cada elemento del arreglo es una DS: {

           B.1-Account_number.  "Account_number":89712345,

           B.2-Year. "Year":2022,

           B.3-Un arreglo Ds-balance de tres elementos. [

           Cada elemento del arreglo es a su vez una DS. {

                  La DS contiene dos elementos simples

                   B.3.1- Balance "Balance": 146.34,

                   B.3.2  Average  "Average": 125.78

         Fin de la DS del primer elemento del arreglo interno  },

          //Segundo elemento del arreglo interno

                   {
                       "Balance": 288.50,
                       "Average": 145.98  
                    },

          //Tercer elemento del arreglo interno

                   {
                           "Balance": 426.80,
                           "Average": 375.95
                   }  

                   ]  //cierra arreglo Ds-balance
               },     //cierra primer elemento del arreglo DS-Account

                .......

                .......

                .......

               Repetimos el proceso para el año 2021, que sería el segundo elemento 

               del arreglo Ds-Account

           A continuación generamos el formato completo de la DS en JSON:

          

EDI- Intercambio Electrónico de Datos

                           

EDI son las siglas que se refieren al envío de datos por vía electrónica que sustituye el envío de papel por el envío de rafagas de datos entre empresas o plataformas tecnológicas.

Para que el emisor y el receptor de la data se entiendan es necesario establecer el formato que permitirá al receptor decofidicar la data que recibe.

Existen varias alternativas para dar formato a la data en un proceso de transmisión electrónica de información.

 

En algunas instalaciones se nos pide a los desarrolladores de IBM I en lenguaje RPG o en otros lenguajes tener conocimientos de EDI. Sin embargo un intercambio de data entre distintas plataformas puede realizarse con distintos formatos. Algunos de esos formatos son: XML, JSON, EDIFACT, X12.

 En esta oportunidad me voy a referir a EDI X12 como uno de los formatos que se utiliza para realizar la transmision de data.

En este artículo daré una idea general de cómo usar este formato y al final, los remitiré a algunos enlaces que, a mi criterio, son bastante completos en cuanto a la explicación del uso de EDI X12. El objetivo de este artículo es presentar en forma clara y sencilla los conceptos fundamentales que les permita seleccionar el formato X12 que necesitan aplicar para la aplicación que estan desarrollando.

Conceptos Clave:

Transacción: Se refiere a un documento ( orden de pago, factura, cheque, operación bancaria, etc)

ANSI: American National Standar Institute. Esta Institución se encarga de generar los estandares internacionales para codificación de data. La institución tiene una división en ella denominada X12 que se encargó de generar el standard de su mismo nombre.

Para una cadena de tiendas por departamento que tiene varias sucursales, un ejemplo gráfico del standard EDI X12 para el envío de las facturas generadas durante el día sería el siguiente:

Algunos autores comparan esta estructura con la "Matrioska". Esto se refiere a las muñecas rusas que se encapsulan una dentro de otra desde la mas grande hasta la mas pequeña y última de la serie. Veamos un ejemplo a continuación:

Recordando Un Viejo Truco. Desarrollo RPGLE. AS400

                           

Vamos a recordar un viejo truco para utilizarlo cuando estamos desarrollando un programa que permita al usuario modificar la data por pantalla.

 Supongamos que tenemos un archivo llamdo MovCuentas conformado por cuatro campos:

• Fecha  (Key)
  
• Cuenta (Key)
  
• Monto
• Moneda
  

 Luego de mostrar la pantalla al usuario, ejecutando en el programa un EXFMT, debemos validar la data ingresada. Generalmente declaramos los campos en pantalla con nombres distintos a los campos del archivo para no perder los cambios introducidos por el usuario. 

La Secuencia de instrucciones sería algo como esto:

1.-Chain (fecha:Cuenta) MovCuentas

2.-Si el registro existe:

          Movemos los campos del archivo a los campos de pantalla.

     sino

          Mensaje de error

     Endif

3.- El usuario ingresa la data

4.- Chain (fecha:Cuenta) MovCuentas

5.- Movemos los campos de la pantalla al archivo.

6.- Update Movcuentas

El ejemplo anterior es sencillo porque tenemos cuatro campos en pantalla. Sin embargo podemos tener 15 campos o muchos mas. Se vuelve realmente pesado mover los campos de la pantalla al archivo y del archivo a la pantalla y ademas, se genera mucho mas código en el programa del que realmente es necesario.

Para ahorrar código y agilizar nuestro desarrollo podemos hacer lo siguiente:

 

Mejores Prácticas para mejorar el performance -I-

                            

En este oportunidad, tres sencillos tips para mejorar el performance del programa Rpg

 

 

 

 

1.-Subrutinas versus Subprocedures.

El uso de Subprocedure ofrece las siguiente facilidades:

• Uso de variables locales
• Pase de parámetros
• Puede ejecutarse como funciones (Built-in)
• Puede ser exportado a otros programas.

Si no es necesario utilizar las facilidades que brinda el uso de subprocedures es preferible utlizar subrutinas. 

En general el EXSR se ejecuta más rapidamente que la invocación a un subprocedure.

 

 2.-El uso de SETLL en lugar de CHAIN.

  SETTL y %Equal responde más rapidamente que CHAIN.

Si solamente se  requiere determinar si un registro con cierta clave existe o no existe, es preferible utilizar el settl.

Algunos autores esgrimen que la diferencia es insignificante, sin embargo cuando se trabaja con millones o billones de registros puede ser significativo ahorrar tiempo tanto como sea posible.

3.-Registros Retenidos (Allocated)

Aunque este punto no es una mejora del performance de por sí, es conveniente prestar atención a esto para evitar fallas y retrasos a tiempo de ejecución.

Supongamos que tenemos un archivo declarado update y realizamos la siguiente operación:

        chain (clave1: clave2)  archivo;

        If campo1 = 'Y';

          campo2 = '001';

          update archivo;

       Endif;

 Esta secuencia de instrucciones aparentemente inofensivas puede dejar "allocated" un registro si la condición CAMPO1 = 'Y' no se cumple ya que no hay un ELSE que libere (unlock) el registro retenido con el chain.

      

 

        

     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