Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

domingo, 4 de diciembre de 2011

Instructivo para Acceder al Servidor en Alemania



                                                                                                                                
Debido a los correos que he recibido de algunos de los lectores del blog, estoy publicando este e-book para facilitar el acceso del servidor en Alemania.

Los alemanes han puesto a disposición un servidor con distintas tarifas que van desde ningún pago (free/gratis) hasta el pago mas alto que incluye una serie de facilidades para corporaciones negocios o grupos de usuarios  para trabajar con un iseries vía remota. Este servicio alemán contribuye grandemente al proceso de desarrollo de proyectos en esta plataforma, ya que mediante acceso vía internet., los desarrolladores podemos acceder a cualquier hora y en cualquier lugar con conexión a Internet.

Instructivo Acceso Servidor ISERIES en Alemania





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


miércoles, 30 de noviembre de 2011

Cómo Nos Comunicamos Los Desarrolladores
















Este artículo no se trata de tips de programación, procesos o desarrollo de proyectos. En esta oportunidad, hago un alto en la tradicional redacción de artículos técnicos para hacer un  llamado de atención a la forma en que nos comunicamos cuando redactamos correos dentro de la organización en la que estamos trabajando.


Es alarmante la poca disposición que existe en general, en el mundo de los desarrolladores de cuidar la redacción de  correos en forma adecuada. Todo lo que escribimos es nuestra carta de presentación y deja un sello imborrable en la mente de quienes nos leen. No es suficiente con ser un excelente técnico cuando no nos damos a entender con claridad ante los otros entes de la organización. Por esta “insignificante diferencia”, muchas veces ascienden a alguien quizás menos preparado técnicamente que nosotros pero que sabe hacerse entender y que, de esta manera, se convierte en un líder natural que contribuye a agilizar la operativa organizacional.

Tips para redactar correos:

1.-La Estructura.

Un correo debe tener un saludo, un cuerpo y una despedida.   

  • Saludo: Buenas tardes, Estimados señores, etc.
  • Cuerpo: Comienza redactando, en un máximo de dos líneas, el objetivo de tu correo, es decir, para qué estas escribiendo ese correo.
  • Despedida: Saludos Cordiales, En espera de su repuesta, Atentamente, etc.

2.-Corto y directo. Utiliza la menor cantidad posible de palabras.

3.-No uses mayúsculas en todas las letras. ESTO DA LA IMPRESIÓN DE ESTAR ENOJADO Y GRITANDO.

4.-Cuida la ortografía. Da pena ver errores ortográficos en correos enviados por programadores. Existen correctores automáticos y en caso de duda, consulta con otras personas antes de enviar el correo.

5.-Ten presente quien va a leer tu correo.
Si te diriges a un gerente, recuerda que él (ella) no están al detalle de tus actividades. Haz un breve recuento de lo que estas haciendo y puntualiza dentro de ese contexto lo que quieres transmitir. Hay programadores que escriben como si los demás estuviesen en su cabeza omitiendo detalles importantes de su tarea diaria que harían mucho mas comprensible su mensaje al destinatario.

6.-Por favor no copies y pegues códigos enteros de programas o lista de fuentes. Es preferible colgar en tu correo,  un adjunto en Word o en Excel que tenga sus márgenes, títulos, y autoría. Hace algún tiempo un programador que conozco, entró por el STRPDM seleccionó con el Mouse la lista de fuentes en los que había trabajado y los pegó directamente en el correo.  El correo decía: Buenas tardes, y seguidamente la lista pegada de todos los fuentes a continuación tal y como la despliega el STRPDM. Luego no seguía ninguna explicación; sin despedida al final y sin especificar para qué había enviado eso ni el contexto dentro del cual estaba trabajando el programador. Más grave aún: el destinatario era un Gerente.

7.-Usemos el sentido común y dejemos la flojera.
Si nos detenemos unos minutos a leer lo que vamos a enviar, nos damos tiempo a corregir y ajustar cosas sencillas que saltan a la vista que están mal redactadas. NO es un favor que le hacemos a otros: es nuestra imagen profesional la que estamos vendiendo en cada correo.

8.-Evita hace Post Data. Esto resta claridad al correo y dispersa la atención del motivo principal de tu comunicación.

9.-Ponte a la orden al terminar el correo.
Si no tienes una firma automática con tu extensión telefónica, coloca al luego de tu despedida, la manera mas expedita que tiene el destinatario para comunicarse contigo en caso de que así lo requiera.

Ejemplo de  correo:
 _______________________________________________________
Buenas tardes Sr. Pérez.

En el adjunto, envío la lista de actividades realizadas en el periodo marzo-abril 2011. Estas actividades corresponden al desarrollo del proyecto “Comunicación”  en la Fase de Elaboración.

A la orden para cualquier duda o sugerencia.

Saludos Cordiales,

Ing. Pedro XXXXX
Extensión telefónica. 9887.
__________________________________________________

Puedes ver que:

-Hay un saludo: Buenas tardes Sr. Perez.

-En la primera linea se define rápidamente el objetivo del correo: Enviar la lista de actividades.

-Luego se contextualiza el envio: Corresponden al periodo X del proyecto Y en la fase Z

-Te pones a la orden 

-Te despides

-Colocas tu forma de contacto telefónico.


Es sencillo, ¿verdad?


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



domingo, 27 de noviembre de 2011

Procesos Síncronos, Asíncronos y algo mas…











Un proceso no es síncrono o asíncrono en si mismo sino en relación a otros procesos con los que se relaciona. ¿Qué quiere decir esto?

Cuando hablamos de procesos síncronos nos referimos a procesos que envían un mensaje a otro proceso esperando una confirmación de recepción de mensaje.

Aquellos procesos que envían un mensaje a otros y no esperan por mensaje de “acuse de recibo” son procesos asíncronos.

Un ejemplo de procesos asíncronos lo vemos todos los dias cuando entramos a la página Web de nuestro banco y pedimos el saldo de la cuenta o realizamos alguna operación en línea. Una vez que el banco nos envía la información que solicitamos, la pagina Web no se queda esperando por una respuesta nuestra. Seria totalmente inoperante y consumiría muchísimo tiempo del servidor del banco. Nosotros podemos en el ínterin de realizar nuestra operación bancaria, atender una visita, levantarnos a atender el teléfono, etc.
 Es decir, ningún proceso del banco se queda esperando un mensaje de confirmación de nuestra parte. Solo cuando hacemos click sobre alguna operación específica de la pagina Web entonces el servidor detecta nuestra solicitud, nos responde y luego el servidor se dispone a atender la solicitud de otros usuarios.

En iseries y refiriéndonos específicamente a los procesos que son ejecutados bajo el lenguaje rpgile, clp, hay mecanismos de control de procesos que no están explícitamente relacionados con la sincronicidad.  En forma explicita puede entrar en esta categoría de sincronismo, el uso SOCKETS para transmisión de data entre el  iseries y una Web o las transmisiones especificas vía FTP, que por razones de seguridad, dan un timeout (tiempo agotado de espera) cuando hay demora en la respuesta.

En algunas instalaciones del Iseries existe el comando WAITJOB (no todas las instalaciones tienen este comando en la librería TAATOOL que suministra IBM).

Algunos analistas han confundido este comando con una sincronización entre procesos. Este comando WAITJOB, permite a un CLP que se está ejecutando, esperar a que otro finalice para continuar.
 Por ejemplo si el programa CLP PGMA somete el JOB llamado JOBW, luego de someter el JOBW el programador puede aplicar el waitjob dentro del programa PGMA para forzarlo a esperar la culminación del job sometido JOBW y luego el programa PGMA continuará con la siguiente instrucción a ser ejecutada. Esto no es igual a la sincronización de procesos entre si. En este ejemplo del WAITJOB, el sistema operativo le avisa a un proceso que el otro proceso terminó, pero ninguno de los dos procesos espera por la respuesta de uno o del otro.

Por cierto es importante tener en las instalaciones  el último release de esta librería de utilidades TAATOOL actualizada puesto que hay comandos sumamente útiles para los desarrolladores en Iseries y para el control de la ejecución de procesos.

En este enlace http://taatool.com/    pueden conseguir mayor información sobre este set de herramientas de productividad para lo desarrolladores del Iseries: 

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

sábado, 5 de noviembre de 2011

Caja de Texto en SDA. ¿Que es eso?



Un truco muy útil para ahorrar tiempo de programación  a la hora de manejar variables en pantalla de longitud muy extensa. En este enlace puedes ver el video asociado a esta publicación:
http://iseriesvenezuela.blogspot.com/p/cursos-y-tutoriales.html

El código fuente lo puedes descargar y ver del enlace que se te indica el e-book insertado a continuación:



Caja  de Texto en RPGLE/Iseries




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

miércoles, 12 de octubre de 2011

Cómo Ejecutar Comandos PC desde un RPGLE











      Cómo Ejecutar Comandos PC desde un RPGLE


En este enlace puedes ver el video explicativo de cómo ejecutar comandos PC desde un RPGLE.


Para que tengas una idea de los comandos PC que están a tu alcance en RPG, puedes ver en este enlace la lista de comandos más comunes.



A continuación puedes ver el código fuente del RPGLE y al final del documento encontrarás el enlace para descargarte el código.


PC Command desde RPGLE Program



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

domingo, 25 de septiembre de 2011

Utilidad para el Cálculo de Diferencia entre Horas





En esta oportunidad tienes acceso a una interesante utilidad para calcular la diferencia entre horas.





Para registrar procesos que no duren mas allá de 24 horas funciona perfectamente. No importa la fecha de inicio ni la fecha de finalización. Es suficiente enviar como parámetros de entrada las horas Inicial y Final para que funcione.


Cálculo de la diferencia entre horas en un período de 24 horas.




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














martes, 20 de septiembre de 2011

Algunos Consejos para Desarrollar Programas


                         

Algunos Consejos para Desarrollar Programas



                                       









1.-No escribas nada hasta que entiendas lo que tienes que hacer.

2.-Si tienes alguna duda técnica, investígala antes de comenzar a programar porque podría  cambiar  significativamente tu trabajo y quizás tendrías, a la larga,  que comenzar a hacer todo de nuevo.

3.-Básate en programas Prototipo. Si no tienes programas modelo, o la organización donde estás no te lo suministra, constrúyete uno y llévatelo dondequiera que vayas.

4.-Divide la programación en un desarrollo de varias etapas, muestra las pantallas o el modelo de salida en cada fase antes de continuar para asegurarte de que ese resultado es el que esperan de ti. Al final la certificación de tu trabajo se simplificará.

5.-Comparte tu proceso con los involucrados en el proyecto. Aún cuando ellos no entiendan de lo que están hablando, (y muchas veces es así) ellos certificarán tu trabajo.

6.-Prueba tu programación con otros que no conocen de lo que se trata el proceso. Estos últimos son los mejores: Presionan teclas donde antes no existían.

7.-Admite tu errores si fuese necesario. La gente respeta a los honestos. Si esta vez te equivocaste, cuando estés en lo acertado, se detendrán a escuchar tu opinión, porque saben que eres alguien que habla con honestidad.

8.-Pide ayuda a otros programadores si te sientes atascado. Eso no te hace menos.

9.-Busca lo simple. A veces en un arranque de virtuosismo técnico complicamos las cosas.

10.-Las cosas visualmente agradables son bien recibidas. Cuida la estética, la ortografía y tu presentación personal. Es necesario saber vender nuestro trabajo.





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

domingo, 11 de septiembre de 2011

Migraciones y Base de Datos.




Tradicionalmente el programador de RPG no trabaja con base de datos. Los archivos físicos son creados vía DDS y luego se crean los lógicos que constituyen, en la mayoría de los casos, índices de búsqueda y acceso pero no claves del archivo.
Cuando se va realizar migraciones desde archivos en plataforma AS400/Iseries que no han pasado por el manejador de Base de Datos DB2, podemos conseguir dificultades a la hora de migrar hacia plataformas como Oracle, MySQL, y otras.

Para no quedar fuera de las bases académicas y de la vanguardia tecnológica es importante que los programadores y analistas en RPG, retomen los conceptos de normalización de base de datos y desarrollen sistemas basados realmente en manejadores de base de datos relacionales que permiten en forma automática proteger y controlar la integridad  y consistencia de la data. Hacer el cambio desde archivos DDS hacia tablas basadas en DB2 es de importancia fundamental.

Por ejemplo, un error común en el cual se incurre frecuentemente es en el caso clásico de dos archivos como son el encabezado y el detalle de facturas. Muchas veces se incurre en el error de “amarrar” el encabezado con sus detalles a través de un número de factura y decir que esa es la clave. Esa puede ser la clave para el encabezado pero no para los detalles de la factura puesto que no es posible distinguir un detalle de factura de otro detalle sólo con el Número de factura. Se requiere además un número consecutivo de detalle o el código de artículo o cualquier otro campo que unívocamente identifique un detalle de factura. Como la relación entre archivos no se maneja como una base de datos, entonces el programador dentro del código de su programa, lee todos los detalles, totaliza las cantidades o los ítems facturados y luego graba el encabezado con esta información. 

domingo, 21 de agosto de 2011

Otra Nota sobre el Trigger.










Un trigger es un atributo de un archivo físico que permite al manejador de Base de datos del AS400 ejecutar un programa en el mismo instante que se haga algún cambio sobre ese archivo. El comando para agregar un trigger a un archivo físico es: ADDPFTRG.

Podemos especificar que queremos que se ejecute un programa X (elaborado por nosotros) antes o después de añadir, eliminar o modificar un registro en el archivo físico sobre el cual estamos ejecutando el trigger. Este programa es desarrollado por nosotros como programadores del sistema, los parámetros de entrada se cargan automáticamente con los valores que el sistema operativo le transfiere. Nosotros no debemos hacer nada más que declarar el nombre del programa en el comando ADDPFTRG. No es necesario especificar los parámetros en este comando. El Sistema operativo, asume que el programa tiene DOS parámetros de entrada.

Importante: El programa que especificamos al incluir un trigger sobre un archivo físico debe tener declarados internamente, dos parámetros de entrada. Estos parámetros son definidos en detalle dentro de una DS (en la hoja E) dentro del programa que nosotros hacemos.
En estos parámetros de nuestro programa, el sistema operativo carga entre otras cosas: nombre del archivo que se ha modificado, Librería, longitud del registro, numero de campos, etc. El sistema operativo entrega en estos parámetros la data residente en el registro antes y después de haber sido alterado. Luego dentro del programa nos corresponde a nosotros como programadores hacer lo que nos interese con la información sobre la data alterada en el archivo.

La duda sobre el uso del trigger reside principalmente en conocer cómo son los parámetros de entrada que debemos declarar en el programa.

En este enlace:
http://www.tylogix.com/Articles/TriggerTechniquesRevisited.htm

Explican detalladamente como declarar la estructura de datos que “desglosa” las posiciones de los parámetros de entrada que entrega el sistema operativo al programa que hemos elaborado. También se explica como recuperar la data del registro modificado antes y después del cambio realizado.

En este blog iseriesvenezuela, también se publicó un artículo anteriormente donde hace referencia a otro enlace que también da su versión de la definición de los parámetros de entrada que debe declararse en el programa.

Este es el enlace dentro de este mismo blog:

http://iseriesvenezuela.blogspot.com/2009/07/que-es-un-trigger.html


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


domingo, 14 de agosto de 2011

Monitoreo de errores en programas CLP




Usualmente el comando MONMSG es utilizado por la mayoría de los programadores para colocar códigos de error conocidos y predecibles. Por ejemplo, en un programa CLP al agregar una librería en la lista de librería y la librería puede que ya exista en la lista, entonces monitoreamos el error CPF2103, para que el programa no se detenga y continúe el proceso.

Es posible la existencia de procesos cuyos errores no son predecibles a simple vista por el programdor y que pueden detener el programa, quedando a expensas de la acción del operador en ese momento. Una vez producido el error y abortado el programa, es necesario revisar el log del job que arroja el sistema operativo para descubrir cual fue el error. El proceso de búsqueda de errores puede volverse engorroso y largo y en algunos casos cuando el log del sistema o los listados del job son eliminados de un día para otro (en forma manual o automática) se pierde el rastro del error.

La siguiente rutina permite capturar el Identificador de mensaje y su descripción, para aquellos mensajes que emite el sistema operativo en caso de errores inesperados para el programador. Se está provocando un error a manera de ejemplo con el comando RMVM (remover miembro de un archivo) en una librería y archivos ficticios.
El Id del error y su texto son capturados en variables del programa y pueden ser grabado posteriormente en un archivo físico de log de errores creado por el programador para su posterior revisión.

Monitoreo de Mensajes de error


Autor: Ing. Liliana Suárez.


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


lunes, 25 de julio de 2011

Cambiar el color de los botones de pantalla en RPG










                                               (Haz Click en la imagen para agrandarla)

En la modernización de las pantallas en RPGLE, el uso de botones es una de las maneras de agilizar el acceso a la información. A veces es necesario cambiar el color de un botón de acceso para marcarlo como “Seleccionado”, emulando lo que se hace en las ventanas y pantallas de Windows.
Para el caso del RPGLE, no es posible cambiar el color del botón directamente sino que debe hacerse a través del cambio de color del texto del botón.
En la imagen pueden ver tres ejemplos de cambio de color. Cuando es un botón de selección múltiple se ve perfectamente.  A continuación pueden descargarse el programa prototipo en código fuente. Cada programador puede hacer las adaptaciones necesarias según su conveniencia.

 Cambiar el color botones de selección RPGLE




Autor: Ing. Liliana Suárez.


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

sábado, 9 de julio de 2011

Dos utilidades Interesantes

                                                                                                              
En este artículo vamos a hacer referencia dos utilidades interesantes.  
    
 








Primera Utilidad:

La utilidad QCLSCAN nos permite realizar la búsqueda de un patrón en un string de caracteres dentro de un programa CL. No es necesario invocar un programa RPG para determinar si una secuencia de caracteres está presente en una variable alfabética. Esta herramienta se halla en la librería QSYS y viene con el release V5RX del iseries.

Pueden descargar código en CL con un ejemplo de uso del QCLSCAN, con sus parámetros correspondientes.

La segunda utilidad se refiere a la validación de cualquier formato de fecha que este almacenado en una variable o campo de ocho posiciones numéricas. Esto es particularmente útil para ciertos archivos y bases de datos  antiguos  y no utilizan campos de tipo fecha (tipo ‘D’).  Este programa consta de tres parámetros.
a.-) La fecha a ser validada
b.-) El formato de la fecha a ser validada
c.-) Indicador de Error en la validación

Dos Utilidades Interesantes



Autor: Ing. Liliana Suárez.


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

sábado, 18 de junio de 2011

Carta Estructurada de un Proyecto (o Sistema)














La Carta Estructurada del Proyecto consiste en un diagrama jerárquico modular basado en una metodología de desarrollo de sistemas TOP-DOWN. 

Top-Down, significa, partir de lo mas general hacia lo mas detallado. Es un proceso análogo al de armar un rompecabezas en el sentido de ver primero la imagen ver primero el concepto o la imagen general, y a partir de alli comenzar a detectar donde va cada pieza dentro de la imagen. La diferencia es el recorrido jerarquico y modular que se realiza en su elaboración.

Un Módulo es un subsistema que agrupa funcionalmente programas, objetos, herramientas y , bases de datos según su funcionalidad y objetivos vinculantes. Por ejemplo, el objetivo de un modulo de nomina es generar el pago a los empleados, el objetivo de un modulo de compras es proveer a a la empresa de material necesario para su funcionamiento y así sucesivamente.

En la imagen pueden ver un ejemplo sencillo de Carta Estructurada del Proyecto. Se refiere a la Carta Estructurada de un proyecto de Sistema de Control de Distribución para el manejo de Inventario. (Haz Click sobre la imagen para agrandarla)

La Carta estructurada del proyecto es denominada también “modelo del producto”. Es importante diseñar la carta estructurada del proyecto antes de comenzar el proceso de diseño de un sistema de software. El software que desarrollamos es un producto, al igual que cualquier otro producto comercializable que requiere un tiempo y proceso de elaboración.


Partiendo de un concepto general,  se van desglosando los módulos y submódulos relacionados hasta llegar a un nivel donde es posible diferenciar las actividades de trabajo. La carta estructurada del proyecto permite distribuir las actividades entre los analistas, desarrolladores, jefes y gerentes  involucrados en el desarrollo del proyecto. Esta carta estructurada precede a la elaboración de un Diagrama de Gantt.

La Carta estructurada  hace posible que cada participante entienda su función dentro de un contexto integral. Además, es sencillo reconocer las interrelaciones de los módulos y preveer el desarrollo de interfases entre los mismos, cuando se tiene claro el contingente de módulos, submódulos y jerarquías. La definición de las bases de datos puede hacerse con mayor claridad cuando tenemos que decidir si la misma entidad es compartida por varios módulos y solo hay que variar los valores de sus claves de acceso o si se trata de entidades separadas según su funcionalidad y la clase de información que contienen.

Hay una herramienta CASE que se llama Visible Analyst que permite modelar análisis estructurado y orientado a objetos. Funciona bajo la plataforma Windows y es muy útil para apoyar la labor de los analistas de sistemas. Pueden descargarla por Internet.


Autor: Ing. Liliana Suárez.


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


viernes, 27 de mayo de 2011

Actualizando las Pantallas Verdes: O cambiamos o nos cambian












A medida que van surgieron nuevas versiones (release) del As/400 para los que programamos en RPG y sus utilidades, hemos visto como ha ido evolucionando el despliegue de pantallas y sus facilidades de navegación a través de las distintas opciones. Aparecen los pulldown  menús que permiten imitar el comportamiento de los menús en la barra superior de Windows. Aparecen los botones, el uso del Mouse, la barra de desplazamiento lateral a la derecha del subfile, posibilidad de acomodar las ventanas de consulta que tradicionalmente eran fijas y una cantidad de facilidades de color, graficación e interactividad con el usuario.

Los desarrolladores debemos adaptarnos al cambio, y dejar de lado en los nuevos desarrollos las tradicionales teclas FX (F3, F6, F5) para procesamiento de data e incorporarnos al uso de las nuevas funcionalidades del SDA en las nuevas aplicaciones.

Es importante no quedarse atrás, mas temprano que tarde llegan a nuestras manos aplicaciones desarrolladas por las nuevas generaciones y aplicaciones de tecnologías mas avanzadas que utilizan técnicas mas efectivas y ágiles de interactividad con el usuario.

Considero que estamos en un momento de transición muy importante en el cual “O cambiamos o nos cambian”.

Pueden ver ahora botones que sustituyen el F6, utilizado tradicionalmente para Agregar data,  y el Enter o F5 utilizado para grabar información y el F3 utilizado tradicionalmente para salir del programa.


Como hecho curioso o simpático, recientemente me tocó trabajar con alguien que estaba comenzando a incursionar en el uso de botones en el AS/400. Este desarrollador coloco como texto del botón: F3=Salir en lugar de colocar directamente: SALIR. Los momentos de transición son así, temporalmente tendemos a unir los viejo con lo nuevo. Lo importante es estar dispuestos a cambiar y seguir hacia adelante.



Autor: Ing. Liliana Suárez.


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

domingo, 15 de mayo de 2011

Seguridad de Acceso al AS/400











Existen aplicaciones desarrolladas en el As/400 que crean su propio sistema de seguridad. Estas aplicaciones crean sus propias tablas de usuario, sus claves de acceso y, en base a su propia definición de usuario permiten o restringen el acceso a opciones de menú o incluso a opciones de actualización de data una vez ingresado el usuario dentro de la aplicación.

Si el usuario deja su pantalla abierta para tomarse un café retirándose de su puesto de trabajo, cualquier persona que haya tenido acceso a las tablas de la aplicación puede ingresar a la pantalla del usuario y alterar la información sin dejar rastro. Es decir, deja rastro en cuanto a que el usuario que dejó su pantalla abierta queda registrado en la base de datos de la aplicación pero  en realidad se achaca a un usuario  “inocente” la realización del cambio. Coloco “inocente” porque es responsabilidad del usuario bloquear el acceso a su equipo cada vez que abandona su puesto de trabajo.


El AS/400 tiene el siguiente comando CHKPWD. Este comando es muy valioso y puede sustituir la necesidad de desarrollar sistemas de seguridad en las aplicaciones. Cuando un usuario va a ingresar al sistema AS/400 lo hace con su usuario y clave asignados según el departamento de Seguridad de Datos de la empresa. Una vez dentro de una aplicación (Cuentas por cobrar, Facturación etc.).  La aplicación puede solicitar a través de una pantalla que el usuario ingrese su clave de acceso al AS/400 para permitirle acceder  o no a las opciones del menú de una aplicación.

Se declara el campo en pantalla tipo “password” y se monitorea el error que da el comando CHKPWD cuando la clave no es válida.

Por ejemplo:
CHKPWD   PASSWORD(MAYDAY1)
Este comando verifica si la clave del usuario actual es MAYDAY1.
Se monitorean los siguientes errores:
CPF2362
Password not correct.  (Clave incorrecta)
CPF2363
Only 1 attempt left to check password. (Queda solo un intento para verificar clave)
CPF2364
Maximum number of attempts to check password reached. (Se alcanzó el máximo numero de intentos permitidos)


El comando CHKPWD permite verificar si la clave cargada en la pantalla de la aplicación corresponde a la clave del usuario en AS/400. Si no es así el comando arroja un error y, monitoreando este error, la aplicación puede detectar que el usuario que intenta acceder a la aplicación no es el mismo que ingresó inicialmente al As/400 con la seguridad que provee el sistema operativo del equipo. Puede enviarse un mensaje de alerta al realizar varios intentos no validos. En ese momento, monitorear el mensaje CPF2364 y enviar un mensaje automatizado al personal de seguridad de la información puede facilitar que se capture en el sitio al intruso que trata de ingresar al sistema.




Autor: Ing. Liliana Suárez.


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

domingo, 17 de abril de 2011

Optimizando el uso del espacio y el tiempo de Respuesta. Member Files.












Tanto quienes emplean DB2 para crear archivos como quienes se manejan a través de DDS, utilizan los valores por omisión para crear archivos físicos. En los valores por omisión el sistema operativo establece que el archivo va a tener un solo miembro.
Los archivos lógicos que son creados posteriormente, “apuntan” a ese miembro.

Un miembro es un espacio del archivo físico, al cual se le asigna un nombre para guardar información relacionada entre si. Por ejemplo, si deseo guardar la información contable del mes de ENERO, realizo un ADDPFM  (añadir miembro) y lo llamo enero. Entonces el archivo físico tendrá un “sector lógico” asignado al mes de enero.  Cuando ejecuto un programa que graba sobre ese archivo, dependiendo de la fecha de la data, puedo realizar  un ovrdbf sobre el miembro ENERO y todos los write/update van a grabar en ese “sector” del archivo físico.

A medida  que pasan los años, la data va creciendo y se va almacenando en el archivo, información de hace 3,5,8,10 y mas años.

Los procesos nocturnos generalmente requieren o lo registros del día o del mes. En casos excepcionales o en cierres anuales se necesita la información de todo un año.

Los procesos nocturnos se hacen cada vez mas lentos, y  comandos como Reorganizar archivo RGZPFM, para reutilizar el espacio dejado por registros eliminados  y CHGPF con reuse = *yes van perdiendo efecto. La reacción inmediata de los líderes de proyectos y analistas de desarrollo es impedir o limitar la creación de archivos lógicos. Se ejecutan entonces sentencias SQL y Queries, tratando de no incrementar los tiempos de respuesta. Mientras tanto los archivos siguen creciendo a medida que el tiempo pasa y eventualmente todas las curas provisionales que hemos colocado nos dejan igual que hace un año cuando se pudo “contener” el problema sin resolverlo en realidad.


En varias organizaciones donde los sistemas tienen varios años funcionando, se ha optado por trabajar con más de un miembro en un  archivo. Cada miembro almacena data de un intervalo de años definido por la gerencia.

Este método de utilizar miembros agilizaría los procesos diarios que requieren un tiempo de respuesta rápido. En lugar de direccionar los lógicos a un miembro que contiene data de hace 15 años, se direcciona  el lógico a un miembro que contiene data del año en curso. El tiempo de respuesta se acelera dramáticamente.

Puede ser que, en los procesos de apertura del nuevo año, se debe incorporar, para los archivos de data que están en esta modalidad, una evaluación automatizada que añada  el miembro que sea necesario si se da el caso. Por supuesto, con un sistema parametrizado, no sería necesario recompilar todos los programas RPG, CLP e ILE RPG involucrados.

No habría que modificar programas de consulta, mantenimientos ni reportes en RPG habría que agregar mas bien rutinas modulares utilizables por cualquier programa que sean capaces de realizar el ovrdbr al miembro que se necesita según la información solicitada por el usuario. Con este sistema, se tiene en disco la data activa y puede cumplirse con normas gubernamentales rápidamente sin tener que bajar y subir backups.


Autor: Ing. Liliana Suárez.


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

jueves, 31 de marzo de 2011

Como Saber si un Programa en RPG fue compilado con Ignore Data Decimal Error = *Yes

Utility Ignore Data Decimal Error

martes, 25 de enero de 2011

Ejemplos optimizando programas en RPG

OptimizacionProgramasRPGIseries