Lenguaje Rpg

Lenguaje RPG

RPG es un lenguaje de programacion de IBM orientado al desarrollo de aplicaciones empresariales, y que es muy usado en la plataforma de servidores intermedios de IBM. Ha sido la base de los antiguos sistemas S/32, S/34, S/36, S/38, AS/400, iSeries, System i, así como de la nueva plataforma Power 7. En el curso del tiempo ha tenido incontables mejoras continuas hasta convertirlo en lo que es hoy, un lenguaje muy poderoso para hacer aplicaciones de negocios. Es un lenguaje "propietario", inventado por IBM para facilitar la programación de tareas de negocio en las Empresas. La historia del lenguaje RPG está llena de continuas mejoras y versiones, y la realidad ahora es que es la base (junto con Cobol) de los programas que funcionan en muchas empresas. En los últimos años, IBM ha mejorado en mucho RPG, ahora llamado RPG IV o RPG ILE, dotándolo de muchas opciones y funciones (como rpg-free y %bifs), mejoras en el compilador y creando el entorno ILE para facilitar la programación más estructurada y la combinación de múltiples lenguajes, como Java, C++, etc. Un ejemplo de la flexibilidad y potencia de RPG es RpgForWeb, un entorno que facilita la creación de Aplicaciones Web usando RPG IV y el estándar de la Web; html y javascript. Las Aplicaciones se pueden desarrollar con muchos lenguajes, incluso puede ser bueno combinar varios lenguajes en una Aplicación, y en la mayoría de las ocasiones no importa tanto el lenguaje con el que está desarrollada una Aplicación como el conocimiento del medio y la inteligencia del programador.

tema del mes El ILE en acción

68 noviembre 1996

En los AS/400 CISC, la V3R1 ha demostrado que es estable y pronto será sustituida por la V3R2; en los AS/400 RISC, que iniciaron su andadura con la V3R6, pronto dispondrán de la nueva V3R7: Muchos de nosotros hemos instalado alguna de estas releases o lo haremos muy pronto. De hecho, la consultora Gartner Group opina que a nivel mundial, y antes de que finalice 1996, estarán en producción (no las que se habrán vendido) más de 100.000 copias de la V3R1/V3R2. Muchos programadores se hallan a punto de arremangarse para ponerse a trabajar con las nuevas funciones de la

Versión 3 (Release x). Y uno de sus retos más inmediatos será el entorno ILE de programación entender como aplicarlo con la suficiente astucia para conseguir el máximo partido posible del nuevo modelo de programación y de lo que éste ofrece. Si ya has jugado un poco con el ILE sabrás que no es fácil hacerse con él a la primera y que incluso resulta fustrante aprenderlo. Dada la abundancia de nuevos conceptos, la escasa documentación de IBM y los escasos ejemplos, incluso un veterano programador en RPG puede desmoralizarse. Afortunadamente, podemos separar las funciones del lenguaje ILE (RPG IV y su nueva sintaxis) de las características de la nueva arquitectura ILE (utilización de recursos como grupos de activación, llamadas estáticas...). Establecer esta división nos ayudará a aprender y utilizar este entorno con eficacia. En números anteriores de NEWS/400 ya se han tratado algunos aspectos del ILE y del RPG IV. Así, en abril del 94, anticipándonos a la salida de la V3, con el título de "El próximo ILE RPG IV" publicamos una avanzadilla sobre cómo evolucionaría el RPG en el futuro. Luego hemos publicado artículos generales como "Por fin, ILE para todos" y "Del RPG III al ILE RPG IV y al revés..." (Marzo 95, núm. 52), o más detallados, como "Los Grupos de Activación" (Mayo 95, núm. 54), "Las especificaciones tipo D del RPG IV" y dos partes del artículo sobre las "Operaciones de fecha/hora del RPG IV" (Junio y Septiembre 95, números 55 y 56, respectivamente). A partir de este número, además de los artículos Las funciones incorporadas y los Subprocedimientos en RPG IV que explican otras posibilidades añadidas al RPG, incluimos una Utilidad (CVTRPG) para convertir los campos definidos en cálculo a las nuevas especificaciones D y diez Trucos & Técnicas sobre el tratamiento de fechas, iniciamos una serie que, de forma práctica, pretende familiarizar al lector en el ILE. Así, para el próximo número tenemos previstos dos nuevos artículos, uno sobre cómo crear programas de servicio y otro sobre las nuevas operaciones de llamada y programación modular, dejando para el siguiente un repaso a los Grupos de Activación, el manejo de errores en ILE o el código de operación EVAL. Creemos que esta serie de artículos pueden ser una buena ayuda para el aprendizaje de ILE. Tanto para aquellos que ya habéis pasado a V3, porque podréis aprovechar su contenido de inmediato, como para los que todavía continuáis en V2, puesto que con ellos podréis valorar las posibilidades del ILE y prepararos convenientemente para el futuro. Mi consejo personal: si queréis poneros al día, no perdáis esta serie e intentad recuperar los números con lo que ya se ha publicado. Carlos Bell

1 - Las funciones incorporadas del RPG IV Muchos lenguajes del AS/400, incluidas las CLs, tienen funciones

incorporadas (BIF o Built-In Function) desde hace bastante tiempo. Pero para el RPG, las funciones incorporadas son totalmente nuevas. Podemos pensar que las BIFs son códigos de operación que devuelven un valor sin necesidad de tener que colocar un campo de resultado. Hasta la llegada de la V3R1, realizaba alguna de estas funciones con códigos de operación (por ejemplo SUBST) metiendo a presión los argumentos en el primer o en el segundo factor, añadiendo el carácter ‘:’ para separarlos cuando era preciso. O directamente no soportaba la función y era necesario que uno mismo se creara las sentencias para realizar el trabajo. Con RPG IV se pueden utilizar las funciones incorporadas que son eficientes y fáciles de entender, e incluso pueden hacer tareas que previamente requerían de ciertos trucos de programación. Lo básico de las BIFs IBM ha añadido las BIFs con sólo unas cuantas operaciones básicas, pero se espera que expanda estas funciones en próximos releases. En la V3R1 el RPG IV soporta las siguientes funciones incorporadas:

%SUBST %TRIM, %TRIML, %TRIMR %SIZE %ELEM %ADDR, %PADDR En la V3R6, además, se ha añadido la función incorporada %PARMS.Cuando se utiliza una BIF se debe indicar los argumentos de la función de acuerdo con el siguiente formato: %funcion(argumento:argumento) . Los argumentos pueden ser variables, constantes, expresiones e incluso otras funciones incorporadas. Aunque normalmente se utilizan en los cálculos del programa, también están soportadas por las especificaciones D utilizando valores en tiempo de compilación. La función %SUBST La función incorporada %SUBST (subserie) extrae una parte de una serie de caracteres y expande las posibilidades del código de operación SUBST. Se debe especificar la serie de caracteres, la posición inicial desde la cual se extraerán los caracteres y la longitud, esta última es opcional. En el ejemplo A de la figura 1 la función %SUBST coloca el valor ABC en la variable Start, que son los primeros tres caracteres de la constante con nombre UpperCase. La variable Middle tendrá los caracteres LMNOP, cinco caracteres a partir de la posición 12. Finalmente la variable End tendrá los caracteres XYX, los tres últimos caracteres. Como en el último ejemplo no se ha especificado la longitud de la subserie a extraer, la función %SUBST extrae todos los

caracteres hasta el final de la serie. Si es necesario, el código de operación EVAL mueve la subserie a la izquierda del campo de resultado, blanquea los bytes de la derecha no rellenados por %SUBST y trunca la serie si el campo de resultado es demasiado pequeño. Los argumentos de %SUBST también pueden ser expresiones, tal como se ve en el ejemplo B de la figura 1. Las sentencias del ejemplo extraen el nombre y el apellido de una serie que contiene el nombre completo con un signo "/" como separador. Por ejemplo si el contenido del campo LastFirst es SMITH/JOHN, las sentencias del ejemplo extraen SMITH y lo colocan en el campo Last y hacen lo mismo con JOHN en el campo First. Cuando se utilizan expresiones como argumentos de las funciones incorporadas es necesario asegurar que los argumentos y que los valores devueltos por la BIF son correctos o el programa dará un error durante la ejecución. Además de utilizar %SUBST para extraer una serie de caracteres, también se puede utilizar como resultado de una asignación, o sea para cambiar una parte de una serie de caracteres. En el ejemplo C cambia el contenido de la variable Swine a "PigPigPigPearlsPigPig" al especificar la función %SUBST a la izquierda del signo igual de la operación EVAL. Probablemente es más practico utilizar %SUBST para insertar el valor de una variable (en lugar de un literal) en una serie de caracteres, tal como muestra el ejemplo D. En este ejemplo, la variable BarGraph contiene el valor hexadecimal ‘20’, que las pantallas del AS/400 identifican como final de campo. La sentencia EVAL cambia el valor de BarGraph de forma que la regla aparece por el lado izquierdo del campo y muestra el número de caracteres indicado por la variable Percent. Quitar caracteres en blanco con las BIFs de ajuste de blancos Las tres funciones %TRIM x devuelven una serie de caracteres a la que se le han recortado los blancos del comienzo y/o del final. La función %TRIM recorta los blancos del comienzo y del final, %TRIML sólo recorta los blancos del comienzo (izquierda) y %TRIMR sólo recorta los blancos del final (derecha). Las funciones %TRIM x reducen las sentencias necesarias para concatenar campos cuando es necesario eliminar los blancos intermedios. El RPG III necesita bastantes sentencias con operaciones SCAN, CHECK, CHEKR y CAT para hacer lo mismo que una sentencia EVAL de RPG IV con una o más funciones %TRIM x . El único argumento de las funciones %TRIM x es la serie de caracteres que será ajustada. Este argumento puede ser una variable, un literal o una constante. El tamaño del campo La función incorporada %SIZE da al RPG una función totalmente

nueva: devuelve el número de bytes que tiene un campo, un literal, una estructura de datos o una constante con nombre. Los ejemplos A y B de la figura 3 combinan las funciones %SIZE y %TRIM para determinar si la línea a imprimir supera los 35 caracteres de longitud. Es importante destacar que en el ejemplo B el argumento de una de las funciones incorpora otras funciones, lo que permite eliminar sentencias y campos intermedios de trabajo. Cuando se utiliza una serie o una tabla, o una estructura de datos de múltiples ocurrencias como argumento de la función %SIZE, esta devuelve el tamaño de un elemento o una ocurrencia. Para recuperar el tamaño de toda la serie, tabla o estructura de datos de apariciones múltiples se debe incluir *ALL como segundo argumento. Es importante recordar que la función %SIZE devuelve el número de bytes. Cuando se utiliza para determinar el tamaño de un campo empaquetado o binario no devuelve el número de dígitos del campo. La función %ELEM Esta función devuelve el número de elementos de una serie, una tabla o el número de ocurrencias de una estructura de datos de apariciones múltiples. Se puede utilizar esta función para que sea más sencillo mantener el programa. Por ejemplo, en la figura 4 la serie WeeklySIs contiene las ventas por semana y tiene 53 elementos que es el máximo número de semanas que puede tener un año. La serie WeeklyComm, que contiene las comisiones por semana y está definida como asociada a la serie WeeklySIs, tiene los mismos atributos. También tiene el mismo número de elementos que WeeklySIs, ya que la sentencia con la palabra clave DIM utiliza la función %ELEM(WeeklySIs). Con esta definición, si se cambia el número de elementos de WeeklySIs también se ajustará automáticamente el número de elementos de WeeklyComm cuando se vuelva a compilar el programa. Es necesario recordar que las BIFs se pueden resolver durante la compilación lo que permite utilizarlas en las especificaciones D. Otro ejemplo que mejora la claridad del programa, y por lo tanto hace más fácil posteriores modificaciones, se puede ver en la figura 5. La estructura de datos contiene un campo de trabajo que además es contenido por una serie con elementos de 1 byte de longitud. La función %ELEM coloca el número de elementos de la serie en el campo ArrayLimit. Si la longitud del campo CustName, en el que se basan todas las definiciones, cambia, sólo es necesario recompilar el programa y se ajustarán todos los valores y tamaños de las variables que dependen de él. También se puede utilizar la función %ELEM en los cálculos, tal como se muestra en el ejemplo B. En este ejemplo se limita el número de veces que se ejecuta el DOU con el número de elementos de la serie WeeklySIS. De esta forma, no es necesario modificar ninguna sentencia si cambia el número de elementos de la serie. Además,

como regalo, si se escribe de esta forma la sentencia DOU, queda documentado el motivo del bucle: para procesar cada elemento de la serie. Apuntando a %ADDR y %PADDR Las funciones %ADDR (Dirección) y %PADDR (Dirección de Procedimiento) son dos formas de dar soporte de punteros al RPG. Aunque trataremos más ampliamente el tema de punteros en próximos números, en este artículo daremos una visión rápida para estas dos BIFs. Los punteros son variables que contienen las direcciones de otras variables (o procedimientos) de un programa en lugar de contener el valor de las variables. La función %ADDR coloca la dirección de una variable, un elemento de una serie o una expresión en un puntero. El resultado es una variable (del nuevo tipo de datos puntero) con la dirección de la variable especificada. En A en la figura 6 se ha definido DayPtr con el tipo de datos *, lo que indica que el campo es un puntero. Se ha utilizado la palabra clave INZ junto con la palabra clave %ADDR para inicializar este puntero con la dirección de la serie DayOfWeeks. Se puede cambiar el valor de la dirección del puntero asignándole un nuevo valor en las sentencias de cálculo, tal como se puede ver en el ejemplo B. En este caso se ha incluido la función %ADDR en una sentencia EVAL para asignarle a DayPtr la dirección del cuarto elemento de la serie DaysOfWeek. La función %PADDR devuelve la dirección del punto de entrada de un procedimiento (programa). La variable que recibe la dirección debe ser del tipo de datos puntero. Se pueden utilizar los punteros de procedimientos con el código de operación CALLB (Llamar a un procedimiento enlazado) para enlazar estáticamente una llamada a un procedimiento. En el ejemplo C de la figura 6 se define un puntero de procedimiento (tipo de datos *) con la palabra clave PROCPTR. Luego se inicializa el puntero con la dirección del procedimiento ADDCUST utilizando la función %PADDR en la palabra clave INZ. Después, en las especificaciones de cálculo, se llama al procedimiento ADDCUST mediante la operación CALLB. Normalmente, se ejecuta más rápidamente la llamada a un procedimiento por su dirección que si se utiliza un literal o una constante con nombre en el segundo factor. La función incorporada más reciente En la V3R6 se ha incorporado la función %PARMS. Esta BIF devuelve el número de parámetros que se han pasado al procedimiento donde se está utilizando la función %PARMS. Para el procedimiento principal la función %PARMS es equivalente a la palabra especial *PARMS de la estructura de datos del programa. Puede obtener más información sobre procedimientos, procedimiento principal y subprocedimientos

en el artículo "Subprocedimientos en RPG IV" en este mismo número. Si el número de parámetros es desconocido el valor devuelto es -1. El valor devuelto por %PARMS no está disponible si al programa o procedimiento que llama al procedimiento que ejecuta la función %PARMS no envía un mínimo de información de la descripción operacional. El ILE RPG/400 siempre pasa esta descripción operacional pero otros lenguajes no pasan ninguna. ¿Algo más sobre las BIFs? Ahora que conoce las funciones incorporadas puede comenzar a utilizar estas nueve BIFs que IBM ha incorporado en el RPG. Puede mirar otros lenguajes como C, CLs o Basic para ver algunas de las posibilidades que las funciones incorporadas al ILE RPG IV ofrecen al programador. Examine sus aplicaciones e intente ver dónde puede utilizar las BIFs (conjuntamente con las demás novedades del RPG IV) para conseguir que sus programas RPG sean más fáciles de mantener, más fiables, más entendibles, más eficiente y, en general, mejores. Bryan Meyers, es director de los servicios de información de KOA y miembro del equipo de redactores técnicos internacionales de NEWS/400.

2 - Subprocedimientos en RPG IV La introducción e implementación del RPG IV ha tenido muchas controversias, compromisos y concesiones. A pesar de que la nueva sintaxis del lenguaje añade muchas funciones, en la primera release no se encontraban algunas de las más esperadas. En la parte superior de esa hipotética lista se encontraba poder pasar parámetros a las subrutinas. Y un poco después, la posibilidad de definir variables locales en una subrutina, de forma que cambiar alguna de ellas no afectara al resto del programa. Después de un año y pico de la presentación del RPG IV, IBM ha empezado a atender esta lista de deseos y está añadiendo nuevas funciones. Para comenzar, ha añadido los subprocedimiento y las variables locales, que probablemente sean dos de las funciones más deseadas/necesarias. La finalidad de los subprocedimientos es muy similar a la de las subrutinas, pero existen diferencias. Las mayores diferencias entre ambas son las siguientes: • Se pueden pasar parámetros a los subprocedimientos. • Con subprocedimientos se pueden definir datos y variables locales. • Los subprocedimientos pueden devolver un valor. • Los subprocedimientos se pueden utilizar directamente en expresiones. Los subprocedimientos ayudan a crear código fuente modular y crear "funciones incorporadas" (built-in-functions, BIF) propias para las

aplicaciones RPG. Oficialmente los subprocedimientos son una mejora añadida al RPG IV en la V3R6, pero también estarán disponibles en la V3R2 para los modelos CISC, por lo tanto no es necesario que se compre un nuevo AS/400 RISC para poder utilizarlos. Procedimientos dentro de un procedimiento Hasta ahora, los programas RPG eran programas con un sólo procedimiento, con un sólo punto de entrada al programa. Esto significa que solamente se podía llamar a "todo" el programa, pero no se podía ejecutar una sola subrutina del programa. Con el nuevo soporte de subprocedimientos, se pueden escribir programas RPG que tengan un procedimiento principal y, opcionalmente, que tengan uno o más subprocedimientos. A éstos se les pueden pasar parámetros y pueden tener sus propias variables locales que no interfieren con el resto de variables del programa. Se pueden incluir todas las sentencias del procedimiento principal y de cada uno de los subprocedimientos en el mismo miembro fuente o se puede tener el código correspondiente a los subprocedimientos en otro, u otros, miembros fuentes que se compilará, o compilarán, por separado. Desde el procedimiento principal se pueden llamar a los subprocedimientos utilizando una sintaxis similar a la utilizada para ejecutar las funciones incorporadas (BIF) del RPG IV. Por ejemplo para llamar al subprocedimiento DayOfWeek puede escribir la siguiente sentencia: EVAL O

puede

WeekDay utilizar

el

= subprocedimiento

DayOfWeek(TodaysDate) en

una

sentencia

IF:

IF DayOfWeek(TodaysDate) > 1 Normalmente, un subprocedimiento devuelve un valor al procedimiento principal. En el ejemplo anterior, el valor devuelto será el número que le corresponde al día de la semana. Una función de un subprocedimiento, sin embargo, puede actualizar una variable global o posicionar el puntero de un archivo.Para poder entender mejor los subprocedimientos y en qué casos se pueden utilizar, veamos un ejemplo que convierte una subrutina RPG IV en un subprocedimiento. La metamorfosis Nuestra subrutina ejemplo convierte una fecha en el día de la semana correspondiente. La figura 1 muestra esta subrutina dentro de una parte de un programa RPG IV y se ha seleccionado de un ejemplo del artículo "Trucos de fechas en RPG IV", publicado en este mismo número. Para ejecutarla sólo es necesario escribir una sentencia con el código de operación EXSR y el nombre de la subrutina. La figura 2 muestra la misma subrutina escrita como un subprocedimiento que devuelve un valor numérico que representa el día de la semana (1=Domingo, 2=Lunes, etc.). Para ejecutar este subprocedimiento debe utilizarse el mismo tipo de llamada que se utiliza con las nuevas BIF (funciones incorporadas o built-in-

functions). A primera vista, las sentencias de la figura 2 parecen ser las de un programa normal en RPG IV, sin embargo, cuando se mira con profundidad aparecen las diferencias entre la subrutina y el subprocedimiento. Para empezar, aparece la nueva especificación tipo "P" (de procedimiento) que define el comienzo y el final del subprocedimiento. La especificación P contiene sólo el nombre del procedimiento y una letra B si se está definiendo el inicio del procedimiento o una E si se define el final. Digamos que la sentencia que contiene la B es equivalente al código de operación BEGSR en la subrutina y la que contiene la E es equivalente a ENDSR. Después de la especificación P se define la interfase de procedimiento (PI), que es similar a la lista de parámetros *ENTRY. Para definir el PI se utilizan las especificaciones D y se debe indicar PI como tipo de estructura en las columnas 24 y 25. En la misma línea también se puede definir la longitud, el tipo de datos y las posiciones decimales del valor que será devuelto, en este ejemplo el campo es de un dígito empaquetado con cero posiciones decimales. Los campos siguientes definen los parámetros que son pasados al procedimiento, en el ejemplo de la figura 2 el campo pasado es DateIn. A continuación se colocan las especificaciones D que definen las variables locales que necesita el subprocedimiento. Como estas variables son definidas dentro de los limites del subprocedimiento, son variables locales especificas para él. Si otro procedimiento en el programa (incluido el procedimiento principal) define un campo con el mismo nombre, por ejemplo el campo DayNbr, ambos campos representarán variables distintas. El sistema no conserva los valores de las variables locales en las distintas llamadas a un procedimiento. Si esto ocurre varias veces, los valores de las variables locales de una llamada anterior, no se conservan en la siguiente llamada. Las sentencias C de la figura 2 son concisas. Es importante señalar que se ha incluido el código de operación RETURN con una nueva función. No solamente es una forma de finalizar el subprocedimiento sino que también indica el nombre de la variable cuyo valor será devuelto al programa que ha llamado al subprocedimiento. En este caso, se devuelve el valor de DayNbr. El código de operación RETURN puede devolver el valor de una variable (como en la figura 2) y también el resultado de una expresión de formato libre (como por ejemplo, DayNbr + 2). Un subprocedimiento puede tener más de un código de operación RETURN, pero sólo se puede devolver un valor. Por lo tanto, las sentencias de la figura 2 se pueden escribir de la siguiente forma: IF DayNbr < 1 RETURN DayNbr + 7 ELSE

RETURN DayNbr ENDIF Cuando se ejecuta una operación RETURN el subprocedimiento finaliza, tanto si devuelve el valor de una variable como si devuelve el resultado de un cálculo. Esto es prototípico Antes de que pueda utilizar un subprocedimiento en un programa hay un concepto más que debe entender: la definición prototipo . Una definición prototipo es una lista de los parámetros de los subprocedimientos en orden, describiendo el tipo de datos del valor devuelto y el tipo de datos de los parámetros que se envían. Los prototipos suministran una verificación de seguridad entre procedimientos y subprocedimientos, permitiendo que el compilador compruebe si la llamada al subprocedimiento es correcta. Sin la definición prototipo podrían crearse misteriosos errores de programas causados por pasar datos inválidos a un subprocedimiento o asumiendo tipos de datos devueltos incorrectamente. Los prototipos aparecen, normalmente, en el procedimiento principal de un programa que utiliza subprocedimientos. Cada procedimiento utilizado por un programa tiene su propia definición prototipo que tiene, usualmente, el mismo formato que el PI. La figura 3 muestra la definición prototipo para el subprocedimiento DayofWeek del ejemplo. Se puede ver que el tipo de estructura, en las columnas 24 y 25, es PR y aparece junto con el nombre del subprocedimiento en la primera línea de la definición prototipo. La definición de la figura 3 también indica que cada vez que el programa llame al subprocedimiento DayofWeek, el programa debe pasar una variable de fecha y debe esperar que la devolución de un número empaquetado de 1 byte. A pesar de que es una practica habitual en muchos lenguajes utilizar el mismo nombre de variable que utiliza el subprocedimiento, no es algo obligatorio. Los nombres de variables aparecen en la lista de parámetros del prototipo pero se puede utilizar cualquier nombre de variable e incluso no utilizar ninguno. Normalmente se copia la definición prototipo en el programa que utiliza el subprocedimiento. De hecho se pueden agrupar todas las definiciones prototipo de todos los subprocedimientos en un miembro fuente y luego copiar el miembro en los programas. El compilador pasa por alto los prototipos no referenciados en el código. Para no tener que escribirlas varias veces en distintos programas, y evitar los posibles errores, se puede utilizar /COPY para copiar las diferentes definiciones prototipo. Además de copiar el prototipo en los programas que llaman a los subprocedimientos, debería incluir el prototipo en el fuente que contiene los subprocedimientos. Esto permite al compilador asegurar

que el prototipo que utilizará en sus programas coincide con el subprocedimiento que está definiendo. Cuando se compila el subprocedimiento, el compilador indicará cualquier diferencia en las longitudes y los tipos de datos. Se puede utilizar esta capacidad de los prototipos para asegurar que son correctos la cantidad y tipo de parámetros pasados cuando se utiliza RPG para llamar un programa o un subprocedimiento hecho en cualquier lenguaje ILE, esto incluye todas las APIs para ILE (con la condición de que el RPG soporte los mismo tipos de datos que utiliza la API). Si se utiliza un prototipo para definir los parámetros, se puede llamar al programa (o a la API) con la misma sintaxis que se utiliza para ejecutar las funciones incorporadas. También se pueden utilizar los prototipos con el nuevo código de operación CALLP (Llamar subprocedimiento), en lugar de utilizar el subprocedimiento en una sentencia EVAL o IF, para llamar a subprocedimientos o subprogramas que no devuelven un valor. La operación CALLP permite especificar los parámetros en formato libre y tiene la siguiente sintaxis: CALLP Prototype(Parm1:Parm2: ... :ParmN) La última palabra en subprocedimientos Probablemente ya estará pensando en las diferentes formas de incorporar subprocedimientos en sus programas. Puede utilizarlos para crear su propio conjunto de herramientas y luego las podrá incluir en sus aplicaciones fácilmente, sin tener que preocuparse de posibles conflictos con los nombres de campo o con los indicadores. Y por supuesto, también puede utilizarlos para crear funciones que se salgan del estándar suministrado por IBM en el RPG. Los subprocedimientos pueden crear una industria totalmente nueva en el mundo del RPG: podrán suministrar juegos de herramientas especializados para que aquellas instalaciones de AS/400 con pocos medios técnicos, puedan armar en aplicaciones completas. Aunque esta industria nunca pueda competir con el mercado de custom controls VBX del Visual Basic, los componentes pueden ser un buen negocio para muchos suministradores de software y cambiar la forma en que se compran las aplicaciones para el AS/400. Bryan Meyers , es director de los servicios de información de KOA y miembro del equipo de redactores técnicos internacionales de NEWS/400. Jon Paris, con más de 20 años de experiencia en proceso de datos, actualmente es asesor de desarrollos en los Laboratorios de IBM Toronto.

©

Publicaciones

HELP400,

S.L.

(Todos

los

derechos

reservados)

help400.es Información técnica y de gestión para IBM i - AS/400

Acceda al Sumario de cualquier número

Número (y pulse INTRO)

Actualizado el 31 Julio 2011 1024 x 768 de resolución

MENU de OPCIONES

RPG IV %BIFs

funciones incorporadas en Lenguaje IBM RPG IV información provisional

RPG es un Lenguaje de Programación de IBM, principalmente usado en su plataforma intermedia, y con una historia de 40 años, en los cuales ha tenido incontables mejoras sucesivas hasta alcanzar hoy dia la version RPG IV (tambien llamado ILE), que incluye un formato de escritura libre denominado rpg-free y contando con un montón de funciones incorporadas denominadas %bif. En la página RPG hay algunos enlaces interesantes de IBM Los %bif son funciones incorporadas dentro del lenguaje para hacerlo más poderoso. Por ejemplo:   

Alfa = %trim(PgmName); la funcion %trim elimina los blancos Alfa = %edit(Saldo:'J'); edita el campo Saldo con el codigo de edicion J Alfa = %trim(%edit(Saldo:'J')); ya que al editar un campo quizá queden espacios en blanco, la %trim anidada los quita

Hay un montón de funciones %bif, creciendo con cada versión del Operativo y del Lenguaje... %mseconds, %seconds, %minutes, %hours, %days, %months y %years %DIFF, para restar un valor de fecha, hora o indicación de la hora de otro Funciones para convertir una serie de caracteres (o fecha o indicación de la hora) en una fecha, hora o indicación de la hora: %DATE, %TIME y %TIMESTAMP. La función %SUBDT, para extraer un subconjunto de una fecha, hora o indicación de la hora – Funciones para asignar o reasignar almacenamiento: %ALLOC y %REALLOC. – Funciones para buscar un elemento en una matriz: %LOOKUP, %LOOKUPGT, %LOOKUPGE, %LOOKUPLT y %LOOKUPLE. – Funciones para buscar un elemento en una tabla: %TLOOKUP, %TLOOKUPGT, %TLOOKUPGE, %TLOOKUPLT y %TLOOKUPLE.

– Funciones para verificar que una serie contenga sólo los caracteres especificados (o buscar la primera o última excepción a esta norma): %CHECK y %CHECKR – La función %XLATE, para convertir una serie a partir de una lista de caracteres origen en caracteres destino. – La función %OCCUR, para obtener o establecer la aparición actual de una estructura de datos de apariciones múltiples. – La función %SHTDN, para determinar si el operador ha solicitado la conclusión. – La función %SQRT, para calcular la raíz cuadrada de un número. %SCAN La función incorporada %PADDR ahora puede tomar un nombre de prototipo o un nombre de punto de entrada como argumento Direct conversion of date/time/timestamp to numeric, using %DEC: %DEC is enhanced (v5r3) to allow the first parameter to be a date, time or timestamp, and the optional second parameter to specify the format of the resulting numeric value. Example: D numDdMmYy s 6p 0 D date s d datfmt(*jul) date = D'2003-08-21'; numDdMmYy = %dec(date : *dmy); // now numDdMmYy = 210803 Conversion from character to numeric Built-in functions %DEC, %DECH, %INT, %INTH, %UNS, %UNSH and %FLOAT are enhanced to allow character parameters. For example, %DEC('-12345.67' : 7 : 2) returns the numeric value -12345.67. --New assignment operators

The new assignment operators +=, -=, *=, /=, **= allow a variable to be modified based on its old value in a more concise manner. Example: totals(current_customer) += count; This statement adds "count" to the value currently in "totals(current_customer)" without having to code "totals(current_customer)" twice ---%KDS(data structure) Used in free-form keyed operation codes CHAIN, SETLL, SETGT, READE and READPE, to indicate that the keys for the operation are in the data structure. Functions for verifying that a string contains only specified characters (or finding the first or last exception to this rule): %CHECK and %CHECKR The %XLATE function, for translating a string based on a list of from-characters and to-characters. The %OCCUR function, for getting or setting the current occurrence in a multipleoccurrence data structure. The %SHTDN function, for determining if the operator has requested shutdown %XFOOT built-in function sums all elements of a specified array expression EVALR operation code evaluates expressions and assigns the result to a fixedlength character or graphic result. The assignment right-adjusts the data within the result. The new FOR operation code performs an iterative loop and allows free-form expressions for the initial, increment, and limit values. The new LEAVESR operation code can be used to exit from any point within a subroutine. The new *NEXT parameter on the OVERLAY(name:*NEXT) keyword indicates that a subfield overlays another subfield at the next available position. The new *START and *END values for the SETLL operation code position to the beginning or end of the file. Built-in functions %EOF, %EQUAL, %FOUND, and %OPEN have been added to query the results of input/output operations. Built-in functions %ERROR and

%STATUS, and the operation code extender 'E' have been added for error handling. Built-in functions %CHAR and %REPLACE have been added to make string manipulation easier New support for externally defined *CMDY, *CDMY, and *LONGJUL date data formats Built-in functions %CHAR(graphic, date, time or timestamp expression) Returns the value in a character data type. %EOF{file name} Returns '1' if the most recent file input operation or write to a subfile (for a particular file, if specified) ended in an end-of-file or beginning-of-file condition; otherwise, it returns '0'. %EQUAL{file name} Returns '1' if the most recent SETLL (for a particular file, if specified) or LOOKUP operation found an exact match; otherwise, it returns '0'. %ERROR Returns '1' if the most recent operation code with extender 'E' specified resulted in an error; otherwise, it returns '0'. %FOUND{file name} Returns '1' if the most recent relevant operation (for a particular file, if specified) found a record (CHAIN, DELETE, SETGT, SETLL), an element (LOOKUP), or a match (CHECK, CHECKR and SCAN); otherwise, it returns '0'. %OPEN(file name) Returns '1' if the specified file is open and '0' if the specified file is closed. %REPLACE(replacement string: source string {:start position {:source length to replace}}) Returns the string produced by inserting a replacement string into a source string, starting at the start position and replacing the specified number of characters. %STATUS{file name} If no program or file error occurred since the most recent operation code with extender 'E' specified, it returns 0. If an error occurred, it returns the most recent value set for any program or file status. If a file is specified, the value returned is the most recent status for that file. Operation code Extender E Allows for error handling using the %ERROR and %STATUS built-in functions on the CALLP operation and all operations that allow error indicators.

New century formats *CMDY (cmm/dd/yy) To be used by the MOVE, MOVEL, and TEST operations. *CDMY (cdd/mm/yy) To be used by the MOVE, MOVEL, and TEST operations. New 4-digit year format *LONGJUL (yyyy/ddd) To be used by the MOVE, MOVEL, and TEST operations. editing (%EDITW, %EDITC, %EDITFLT) scanning strings (%SCAN) type conversions (%INT, %FLOAT, %DEC, %UNS) type conversions with half-adjust (%INTH, %DECH, %UNSH) precision of intermediate results for decimal expressions (%DEC) length and decimals of variables and expressions (%LEN, %DECPOS) absolute value (%ABS) set and test null-capable fields (%NULLIND) handle null terminated strings (%STR)