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.

viernes, 7 de diciembre de 2012

Equivalencia SQL Vs. RPG






 
 
Orientado a aquellos programadores en RPG que deben lidiar con códigos en Sql con los que no están muy familiarizados.

En esta oportunidad hacemos una equivalencia entre el comando Fetch del Sql y las sentencias de lectura y posicionamiento del RPG, RPGLE.

Con los siguientes comandos es posible construir un programa que permita manipular el subfile en grupo de n filas y realizar el avance y retroceso de página adecuado, así como el posicionamiento y las búsquedas que sean requeridas.

Repasamos la función DECLARE en la cual debemos declarar un cursor dinámico para poder acceder a un posicionamiento “random” en el archivo.

Luego de declarar el cursor Scroll dinámico, con las condiciones de Select que hagan falta, realizamos el open del cursor y luego con un fetch before nos posicionamos al principio de la tabla. Esto seria el Setll del rpg, luego con un fetch next realizamos lo que sería un read en rpg. El “fin de archivo” lo hace el sqlcode <> 0.

Equivalencias SQL Vs RPG

Fetch prior = READP

Fetch After = Setgt  se coloca al final de la tabla resultado de la selección

Fetch Before = Setll se coloca al principio de la tabla resultado de la selección

Fetch relative ( +n, -n)  se posiciona n filas adelante o – n filas atrás de la ultima fila leída

Fetch first =  trae el primer registro de la tabla resultado de la selección

Fetch last = trae el ultimo registro de la tabla resultado de la selección

Fetch current = re-lee el registro que se acaba de leer

Fetch Next = read. Lee el siguiente

__________________________________________

Un ejemplo sencillo de lectura de N en N registros hacia adelante es:

exec sql declare c1    dynamic scroll cursor for     //esto se “declara una sola vez”  en

                                                                                            el programa, a menos que se

                                                                                           quiera modificar 
                                                                                           la sentencia select//

select *                       

from libreria/archivo                          

order by clave;                          

exec sql open c1;            

exec sql fetch before from c1;  //setll

exec sql fetch next from c1 into Dsdata  //read

Cuenta = 1

Dow sqlcode = 0 and cuenta < N;  

//instrucciones que hagan falta

Cuenta = cuenta +1;

exec sql fetch next from c1 Dsdata;   //read

enddo;         

Un ejemplo sencillo  de lectura de N en N registros hacia atrás es:

exec sql                                                      

exec sql declare c1    dynamic scroll cursor for     //esto se declara una sola vez en el pgm

select *                       

from libreria/archivo                          

order by clave;                          

Rrn    = N+1;                               

exec sql fetch prior from c1 into :Dsdata; //readp

Dow sqlcode  = 0 and cuenta  > 1 ;      

cuenta  -= 1;    

//instrucciones que hagan falta                        

exec sql fetch prior from c1 into :Dsdata;

Enddo;            

Estos comandos son particularmente útiles cuando queremos cargar un subfile de n en n registros haciendo retroceso y avance de página utilizando sentencias Sql que nos liberan de la necesidad de crear lógicos adicionales para posicionamiento u ordenamiento.

     

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
                 

lunes, 19 de noviembre de 2012

Cinco FAQS (Frequently Asked Questions)




·    













     ¿Qué significa: Error de correlación de datos en el miembro ARCHIVO?

Por ejemplo cuando hemos definido un campo tipo DATE en el archivo, y hemos grabado una serie de registros con formato dd.mm.aa (*eur) e intentamos grabar la fecha de un nuevo registro con un formato diferente por ejemplo  en aaaa-mm-dd (*iso) se produce un error de I/O.  Esto sucede porque al intentar grabar dos formatos de fecha distintos, el sistema operativo detecta la imposibilidad de generar índices de acceso de ordenamiento ya que no es posible determinar con distintos formatos el ordenamiento de las fechas

·         ¿Cómo declarar en la pantalla SDA, un campo tipo DATE?

Se declara el campo char pero lo referencias a un campo de una tabla o archivo que sea tipo date

Cuando se compila el programa compilar con la opción: CVTOPT  *datetime

Esto hace posible que variables alfabéticas puedan almacenar datos tipo fecha.

A la hora de actualizar el archivo se coloca, en el código del programa, sin necesidad de utilizar built-in functions ni procesos especiales de conversión lo siguiente:

Campo Fecha del archivo = variable fecha de pantalla;   (RPGLE –FREE)

Write archivo;

 

·        Como se declara la dataara *LDA en rpgle?

 D LDA           E DS                  EXTNAME(VIFLDA)

 D                                          Dtaara(*LDA)  

 

En la hoja D, declaras la dataara. Puedes asociar una estructura de datos a la data área. Esta estructura de datos es un archivo externo con sus campos y longitudes definidas previamente. Tal como se ve en el ejemplo.

 

·        Como inicializar un bloque de indicadores en rpg-free?

En rpg-free no existe la operación MOVEA, pero la sustituimos por esta:

%subarr(*IN: 01: 05) = *off

En este ejemplo se inicializan los indicadores desde el *in01 hasta el *in05 en *off.

 La versión de RPG 400 sería:

Movea ‘00000’ *in(01) 

 

·         Cómo Buscar en batch una serie de caracteres en los programas fuentes de una librería:

 

Hacer sbmjob colocando este comando: FNDSTRPDM permite hacer búsqueda en de una cadena de caracteres en los archivos fuentes de una librería, mientras nos dedicamos a trabajar en otra cosa en nuestra estación de 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 noviembre de 2012

Una base de conocimiento para todos (primera parte)





 
 
 
 
 
 
 
 
 
 
 
En los procedimientos administrativos que se han establecido para el control del desarrollo de software en I-series Rpg y otras plataformas se han tomado en cuenta, en general, al menos estos factores:

                                     1.-Control de versiones de programas
                                     2.-Cumplimiento de cronogramas
                                     3.-Matrices de prueba
                                     4.-Certificación de pruebas
                                     5.-Puesta en producción.

El énfasis se ha puesto en el logro de los objetivos  y en la puesta en producción. Sin embargo, en cuanto a la medición de la gestión de los incidentes diarios la mayoría de las organizaciones se ha quedado corta. Cuando un usuario reporta un problema, el desarrollador a cargo de la aplicación  registra en un formato de control de incidente lo siguiente:
  • La descripción  del  incidente realizada por el usuario.
  • El tiempo en horas que se tomó para arreglarlo,
  • Los programas, archivos, objetos y fuentes que fueron alterados y  que hay que pasar  a producción 
  • El resultado de las pruebas y su certificación.
  • Un control de versiones estricto en el pase a producción. (Esto todavía no existe en muchas organizaciones)

 Cuando se mira esta lista de registro del incidente pareciera que es suficiente. Sin embargo, cuando otro desarrollador debe realizar las funciones del informático que estaba a cargo de la aplicación se encuentra con que no hay  una base de conocimiento que le permita acceder rápidamente a un registro histórico de los problemas iguales o similares que fueron resueltos anteriormente y las acciones concretas técnicas  que se tomaron en ese momento. Lo que está reflejado en esta documentación es escueto, con una mención a nivel de “titulo” sobre los objetos y fuentes alterados, una justificación del cambio y un tiempo de resolución. Nada que, sustancialmente aporte algo significativo a quien técnicamente debe remangarse la camisa y “hacer el trabajo sucio”.

El proceso para resolver el problema se resume en contactar telefónicamente a quien se fue de vacaciones o de la empresa, en revisar la documentación técnica que se tiene distribuida en una o varias carpetas, en revisar con el usuario los correos que ha recibido o enviado sobre el tema y finalmente en comenzar a ver el problema nuevamente desde el principio, si es que no se puede esperar a que el programador encargado regrese en algún momento.  

En medio de la confusión generalizada y del desconocimiento de lo que es el área de informática, se espera que el desarrollador que queda encargado se haga cargo de la situación rápidamente. Digamos que se trata al programador como al mecánico de turno que debe reemplazar la bujía o el carburador de un automóvil. Algo así como quien por saber desarrollar en una plataforma y en un lenguaje debe tener la cosmo-visión omnisciente y todopoderosa del desarrollo de un producto informático.


Considerando que el desarrollo informático es:

  • Un producto sujeto a un registro de propiedad intelectual.
  • Un diseño realizado bajo un esquema único e irrepetible
  • Adaptado a cada organización según sus necesidades de Parametrización y uso.

Debe entenderse que NO es posible para ningún desarrollador, cualquiera que sea la plataforma de su especialidad, resolver problema alguno sin el conocimiento previo técnico del sistema.

Es necesario construir una base de conocimientos compartida que esté automatizada que permita a un programador registrar rigurosamente la manera como el incidente fue resuelto. Esta base de conocimientos hace posible que

  • Se resuelva rápidamente el incidente por cualquier persona de informática.
  • Se mida la gestión de la gerencia de sistemas
  • Se mejoren los procesos de control y seguimiento
  • Se mejore la calidad de los sistemas
  • Se aumente la satisfacción del usuario
  • Se justifiquen los recursos del área de sistemas


Si diseñamos una plataforma automatizada que permita registrar incidentes basándose en un formato diseñado destinado al personal técnico en sistemas, es posible además, agregar elementos estadísticos para medir la efectividad de una gestión informática en un periodo de tiempo determinado.

Por ejemplo, si durante tres meses observamos el mismo incidente repitiéndose, es necesario tomar alguna acción que resuelva el problema de raíz. Esto indicaría además que quien resuelve el problema lo esta controlando temporalmente pero no lo resuelve en causas primarias por lo que el tiempo que utiliza en resolver una y otra vez el mismo problema podría ser empleado en la resolución de nuevos requerimientos o en la corrección  de otras fallas. Esto ampliaría el radio de acción del área de sistemas y alcanzaría mayores objetivos para mejorar la dinámica del negocio.

¿Cómo puede medirse una gestión sin llevar un registro automatizado de los incidentes?
¿Cómo puede mejorarse una gestión sin un control estadístico del comportamiento de los incidentes entre varios periodos?

En la segunda parte de este artículo continuaremos desarrollando este tema. Veremos el diseño y el prototipo de un formato automatizado para los técnicos en sistemas y el seguimiento de una gestión. Veremos los requisitos que debe cumplir una base de conocimientos automatizada para que sea una herramienta útil en el control, seguimiento y medición de la gestión del área de informática.


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 octubre de 2012

Sincronización Procesos AS/400 y Web










La mayoría de las organizaciones que mantiene sus procesos principales en as/400, utilizan aplicaciones  web para permitir a sus clientes la actualización de datos  a través de Internet.
Es necesario definir un proceso de sincronización de datos entre la base de datos web y la base de datos residente en el as/400.

El proceso de sincronización tiene como objetivo principal mantener ambos sistemas con la información actualizada en forma instantánea para que la consistencia de la data y la secuencia de los procedimientos no sean obstaculizadas. Por ejemplo, si un cliente solicita una extensión de su límite de crédito a través de la página web, esta solicitud debe ser “informada” al As/400 inmediatamente. Una vez aprobada la solicitud en el as/400 esta aprobación debe actualizar la página web de manera que cuando el cliente solicite un pedido con un margen de crédito mayor no sea rechazada su compra. Muchas veces notificamos al cliente vía correo o por vía telefónica que la ampliación de su crédito ha sido aprobada. Sin embargo, cuando ingresa a la página web, la data no está actualizada todavía y el cliente se comunica con la empresa manifestando su desconcierto. El asunto de la eficacia en la atención al cliente es sumamente importante. Debe analizarse la secuencia de procesos y procedimientos manuales y automatizados para no caer en estas deficiencias de atención en el servicio al cliente. Es preferible programar un proceso automático que luego de ampliar la línea de crédito del cliente, le envíe un e-mail o un mensaje de texto a su celular y/o notifique al departamento de ventas las actualizaciones que han sido realizadas y están disponibles para los clientes.  El cliente no debería pasar por estas situaciones incómodas. El que la transmisión de datos falló o que no ha sido ejecutada no es incumbencia ni interés del cliente. A veces damos como excusa: “el proceso no ha corrido” o peor aún se escuchan frases de respuesta al cliente como: “eso tiene que ver con sistemas no con nosotros”. Lo que genera una imagen de la empresa de cara al cliente francamente deplorable y mediocre.

Debe definirse sin ambigüedades en cual de los dos equipos se hace qué tipo de actualizaciones para evitar perdida de información por la superposición de una data sobre la otra o evitar duplicidad de la data.
Las operaciones “en tránsito” también son un tema importante. Si un cliente hace un pedido hace dos días y antes de que su pedido llegue efectúa un cambio de dirección. Este cambio puede representar un problema en la entrega del servicio.  Esto debe ser detectado por el sistema al momento que se realiza una actualización de datos y advertir al propio cliente y al departamento de ventas para asegurar que el pedido llegue a su destino. Si a esto agregamos que la dirección nueva está en la página web pero que el as/400 no se ha enterado del cambio por alguna falla del proceso o porque el tiempo de sincronización de ambas datas fue mal elegido, puede causar inconvenientes en el seguimiento del caso.

Desde el punto de vista técnico, es fundamental generar un log o registro de transmisión entre uno y otro sistema que establezca la cantidad de registros transmitidos (por el sistema que envía data) y las operaciones realizadas en la data en cada uno de ellos así como la cantidad de registros recibidos  por el sistema receptor.  Es importante elegir el servidor adecuado o la herramienta de intercambio de data mas confiable. Según la magnitud de la información y tamaño de la empresa, puede elegirse un servidor intermedio que sirva “de puente” entre el servidor web y el AS/400, puede utilizarse la utilidad “ODBC” u otras de mas avanzadas para extraer información desde el as/400 a otra plataforma o cualquier medio que garantice rapidez y capacidad de almacenamiento.

 He estado en  organizaciones en las que una vez puesto el sistema de sincronización en producción comienzan a aparecer situaciones imprevistas que afectan a varios clientes y que obligan a correr a los programadores para “remendar” la falta de análisis previo.  En otros casos le ha tocado a las empresas cargar manualmente la data que el cliente ya había ingresado y que se “perdió” por errores en los procedimientos de ejecución.

Es importante sobretodo para el equipo de desarrollo  del As/400 disponer de las nuevas herramientas metodológicas suministradas por las tecnologías de punta como el  estudio de los “Casos de Uso”.  A la mayoría de los desarrolladores del As/400 que se rigen por una forma tradicional de análisis, les fastidia “hacer muñequitos” y documentar formalmente los escenarios bajo este esquema. Sin embargo, este es un proceso imprescindible para asegurar la calidad de nuestro trabajo. Además, podemos solicitar apoyo del personal de Calidad y Procesos de la organización para definir conjuntamente estos escenarios, los casos de uso y las pruebas de los mismos. Esta manera de trabajar genera mejores oportunidades para fidelizar al cliente con la empresa porque prestamos un mejor servicio y logramos un cliente satisfecho.


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, 9 de septiembre de 2012

Uso de Arreglos (Arrays) o Estructuras Dimensionales.




Un tema viejo que vale la pena repasar.

He encontrado cuatro maneras básicas de utilizar arreglos en lo programas.

1.- Aquellos arreglos que son cargados a tiempo de compilación.
Esta modalidad se utilizaba en un principio para almacenar los dias de cada mes del año y validar de esta manera, las fechas que el usuario cargaba interactivamente. Luego que aparecieron funciones de validación de fecha como  TEST(DE), en la nuevas aplicaciones ya no se requiere de este uso. También se aplica para almacenar el nombre de los días de la semana,  el nombre de los meses del año, mensajes de error, títulos de los reportes y pantallas, comentarios y otros elementos fijos o de muy poca variación.
El inconveniente que tiene esta opción es la recompilación del programa cuando hay un cambio de los valores de las tablas internas. Sin embargo cuando se supone que los dias de la semana, los meses del año y los colores del arco iris van a  ser siempre iguales es una buena opción.

2.-Los arreglos que son cargados a tiempo de ejecución, también llamados “arreglos dinámicos”. Esta modalidad es particularmente útil para cargar tablas de data que tienen poca información y que son leídas muchas veces en el programa. Por ejemplo, si tienes un archivo de data que contiene las ciudades de un estado y el programa cuando tiene un lazo principal debe buscar una y otra vez la descripción de la ciudad entonces, podría cargarse este archivo en un arreglo del programa y evitarse los frecuente accesos a disco que enlentencen el tiempo de respuesta del programa. Con un lookup, puedes buscar en un par de  arreglos el código y el respectivo nombre de la ciudad que estas leyendo.

En cuanto a su definición tenemos arreglos numéricos, alfabéticos y multidimensionales. Podemos tener arreglos en los cuales cada elemento es una estructura de datos que a su vez contiene otros arreglos, números o textos. Esto se logra con el uso de la palabra clave Occur.

En estos artículos tienes información mas detallada de su uso:



3.-Redefinir estructuras de datos y campos de archivos en la hoja (D) a través de un arreglo para acceder a la información en forma indexada y simplificar la programación, evitando el uso de nombre de campos separados.

Remitirse al siguiente artículo para mas detalles:



4.- Para simular subfiles en pantalla.
En algunas instalaciones donde el uso del subfiles puede ser complicado por diversas razones, eso lo he visto particularmente en aplicaciones de conciliación bancaria donde el cruce automático de información entre el banco y la empresa deja “movimientos colgados” sin su pareja y el manejo del subfiles puede resultar engorroso por habilitar o deshabilitar campos o medias líneas del subfiles. La redefinición de campos de pantalla a través de arreglos ha simplificado el despliegue de información en pantalla en varias oportunidades.

Las operaciones que podemos hacer sobre los arreglos son:
Xfoot, (suma los elementos de un arreglo)
 lookup,  y todas sus variaciones para buscar un valor específico.
movea, (mueve un valor a todos los elementos de un arreglo)
Sorta (ordena ascendentemente los elementos de un arreglo)
%elem() Devuelve el numero de elementos de un arreglo.


Cabe destacar que hay múltiples algoritmos de ordenamiento y búsqueda que pueden aplicarse sobre un arreglo. Estos procesos no retardan prácticamente nada los tiempos de respuestas ya que la información está en memoria y no es necesario acceder al disco una vez que se ha cargado el arreglo una primera vez.



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

viernes, 17 de agosto de 2012

Procesos de Búsqueda en Desarrollos Caóticos
















Las bases de datos, para almacenar direcciones de clientes, han sido diseñadas, tradicionalmente, con los siguientes campos básicos: dirección, ciudad, estado y país. Eventualmente se incluye el código postal y algún punto de referencia que facilita la ubicación del inmueble.

En Venezuela, con la nueva disposición gubernamental que ordena especificar en las direcciones de los clientes, la información relacionada con municipio, parroquia, sector/urbanización, casi todas las empresas se han visto en la necesidad de reorganizar las bases de datos, fragmentando o compactando información y creando nuevos archivos de datos y programas.

Esta reingeniería requiere el diseño de mejores buscadores de información. No es lo mismo cargar el pedido de un banco que contiene 300 sucursales (y además sucursales que pueden estar en la misma ciudad y avenida y que se pueden diferenciar solamente por el detalle de la ubicación) que cargar el pedido de un cliente que tiene dos sucursales. Los procesos de búsqueda de direcciones deben ser ágiles y parecidos a los buscadores de Google en cuanto a la localización rápida de los datos de un cliente. Estos cambios requieren más archivos, y más pantallas de navegación en cascada o listas desplegables que permiten seleccionar los datos faltantes de las direcciones.

Para aquellas empresas que trabajan con herramientas más actualizados como el SQLRPGLE, es sencillo generar buscadores:

Select * from librería/archivo where campo1 like ‘%Altamira%’ or campo2 like ‘%Altamira’

Si la información no está en un solo archivo es suficiente con hacer join con los archivos involucrados y aplicar la misma lógica.

Cabe destacar que, cuando un cliente tiene múltiples direcciones, es necesario asignar un campo clave de código de dirección (que puede ser un numero consecutivo) que permita diferenciar con éste código cada dirección registrada.

Aunque con el uso del SQL parecería sencillo este proceso, hay organizaciones que tienen sistemas caducos programados en Rpg 3 y quizás con algunos programas en rpg4 y cuya lógica engorrosa de programación de infinitos lazos anidados e indicadores, acumuladores y totalizadores de montos hacen de esta tarea un verdadero desafío.

¿Qué hacer en estos casos?

1.-Desarrollar programas para realizar cargas masivas de direcciones por cliente.

Independiente de los procesos que ya existen en la empresa, es necesario cargar manualmente o por procesos en batch de trasmisión remota las direcciones únicas o múltiples de cada cliente. Esto último aplica si las empresas logran establecer acuerdos con los clientes grandes y con corporaciones que envíen en un formato digital predeterminado, la información de sus direcciones bien sea en Excel o desde un iseries hacia otro iseries.

2.-Realizar programas de búsquedas o módulos que puedan ser invocados por los programas viejos y que devuelvan: o bien un arreglo con los códigos de direcciones que cumplen la condición de búsqueda o una lista desplegable interactiva donde el usuario seleccione la dirección que le interesa.

3.-Realizar la búsqueda en los subfiles y no en el archivo directamente.

Este último punto aplica principalmente a las instalaciones desactualizadas cuyo nivel de programación o experticia es insuficiente o cuando el despliegue del subfile se realiza luego de varios lazos anidados de lectura de archivos y no se desea cambiar la lógica del programa por la falta de tiempo, por el riesgo de errores o por la falta de recursos.

Mientras cargas el subfile puedes construir, en un campo oculto tipo caracter, el resultado de la concatenación de los campos del archivo donde deseas realizar la búsqueda. Cuando el usuario coloque un texto para buscar información, recorres el subfile haciendo %scan (o scan)por este campo “largo” y reposicionas el cursor en el tope del subfile con el rrs de la línea donde se consiguió la data. (con la keyword: cursor *top del sda)

4.-Como el dicho reza: “cuando veas las barbas de tu vecino arder pon las tuyas a remojar”, de la experiencia de otros puede sacarse provecho. Los desarrolladores que van a diseñar bases de datos de direcciones de cliente o de direcciones en general, o con campos de textos ( o el caso de empresas de geocodificación cuyo negocio es la localización de direcciones en mapas o en otro medios digitales) es preferible hacer un diseño de base de datos de direcciones “fragmentado”, es decir, generar un campo para cada detalle de la dirección de un cliente: País, Estado/Provincia, Municipio, Parroquia, Sector, Avenida/calle, edificio/casa, Piso, Punto de referencia, código postal, etc.

Separando los campos se tiene una mayor ventaja y flexibilidad en los procesos de búsqueda y además en los procesos de validación.

Este mismo tipo de criterio debe aplicarse a empresas de seguro y centros de salud que deben describir el estado de un paciente en campos de texto. Jerarquizar la data creando campos que actúen como índices de enlace y acceso en la base de datos es más recomendable que aquellos campos largos que tienen mucho texto y terminan haciendo engorroso el acceso a la información.




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

















jueves, 19 de julio de 2012

Una Nueva Área en la Empresa: Gestión de la Demanda











Este artículo es distinto al perfil de redacción que he presentado hasta ahora. El artículo está vinculado a una experiencia personal que tuve recientemente cuando asistí a una entrevista de trabajo en la cual la se me ofrecía un puesto de analista de Gestión de la Demanda.

En Venezuela, esta área organizacional es relativamente nueva. Desde hace unos dos se ha comenzado oír algo de esto en el mundo de las organizaciones que exigen gran demanda de servicios tecnológicos para poder competir en el mercado.



Gestión de la Demanda se encarga, en líneas generales de lo siguiente:



1.-Determinar si el requerimiento del usuario al área de sistemas procede o no. Si la relación, costo-esfuerzo-tiempo vs rentabilidad no es atractiva, los analistas de Gestión de la Demanda pueden detener la solicitud de cambio.

Con la creación de esta área, el usuario no se comunica directamente con el personal de sistemas en la etapa inicial del proceso. Gestión de la demanda recibe la solicitud y la evalúa primero si procede o debe rechazarse. Aún cuando Gestión de la Demanda requiera reunirse con Sistemas, Procesos, Calidad, Organización y métodos. Recae en ellos la principal responsabilidad de decidir la viabilidad del proyecto.



2.-Detectar si el proyecto o requerimiento pone en riesgo la operativa del negocio y el impacto funcional y técnico que significaría atender esa solicitudes.


3.-Agilizar la solución de necesidades importantes para la operatividad o la estrategia del negocio


4.-Priorizar las solicitudes. Definir quien o que debe ser atendido en primer lugar.


5.-Hacer el seguimiento de cada proyecto desde su definición hasta su implantación.


6.-Levantar información y generar el documento de arranque del proyecto y cualquier otra información relevante para el mismo.


7.-Asistir a las fases del proyecto para detectar desviaciones o correcciones en cuanto a los objetivos de usuario y de negocio.


8.-Tener un conocimiento total del negocio y resguardar la información que documenta su funcionamiento.


La institución que visité maneja anualmente alrededor de 300 proyectos. El personal de Gestión de la demanda consta de 5 personas que deben hacerse cargo potencialmente de 60 proyectos al año que significan 5 proyectos al mes. Si un proyecto promedio toma 6 meses, esto significa que al cabo de seis meses, -si todos los proyectos fueron aprobados-, cada persona estaría manejando 30 proyectos, porque Gestión de la demanda no puede desligarse del proyecto sino debe llevar el control hasta su culminación. Si agregamos a este escenario: las vacaciones, renuncias, despidos o enfermedad de los otros analistas de Gestión de la demanda, el número de proyectos se incrementaría significativamente por la redistribución del trabajo.



sábado, 23 de junio de 2012

Mejores Prácticas en Programación RPG IV según Bryan Meyers

Tips y recomendaciones de estilo y estándares del reconocido autor Bryan  Meyers para aquellos que programamos en RPG IV.



Mejores Practicas en Programación RPG IV según Bryan Meyers


Albert Blanch, autor y fundador de la revista ServerNews me aclara que ellos hicieron la publicación de este documento por primera vez en la edición 155. Lo obtuve con la gente de Scribd por lo que no tenía idea de la publicación inicial. Valga la aclaratoria y honor a quien honor merece. Gracias al equipo de ServerNews.

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: Bryan Meyers
Publicado por: Ing. Liliana Suárez



viernes, 22 de junio de 2012

Códigos Maliciosos en RPG.
















Si repasamos la definición de código malicioso, distinguimos que está orientado principalmente a programación de última generación  y a plataformas Windows en computadores personales y en ambiente web.

Wikipedia dice:

Malware (del inglés malicious software), también llamado badware, código maligno, software malicioso o software malintencionado, es un tipo de software que tiene como objetivo infiltrarse o dañar una computadora sin el consentimiento de su propietario. El término malware es muy utilizado por profesionales de la informática para referirse a una variedad de software hostil, intrusivo o molesto.1 El término virus informático suele aplicarse de forma incorrecta para referirse a todos los tipos de malware, incluidos los virus verdaderos.

Pensamos que el As/400, el Iseries y toda plataforma derivada son invulnerables, lo que, ciertamente ha contribuido a que permanezca en el mercado tecnológico. (Gracias a Dios!)

Para nuestro entorno tecnológico laboral del ISeries transformaremos el sentido de código malicioso a “Código Fraudulento”. Es posible que programadores sin escrúpulos desarrollen programas para su beneficio personal. Se ha visto casos de informáticos que trabajan en la compañía de teléfonos o en la compañía de suministro de energía eléctrica y colocan su número de teléfono o su número de cuenta dentro de la base de datos con un estatus: “exento de pago” ó en  el mismo código de programa en forma “encriptada” llevan a cero el saldo de sus cuentas todos los meses.

Ø      Es importante revisar si los programas tienen Código Duro o Hard-Code en su código fuente y determinar si lo valores introducidos en la programación corresponden a valores de campos en la base de datos.

Hay varios mecanismos que no son obvios pero que funcionan para cometer fraudes en RPG –queriendo o sin querer- durante el desarrollo del programa.

Hace algún tiempo, en una entidad bancaria, el programador generó sin darse cuenta un lazo o bucle (Do-while) que se volvió infinito bajo ciertas condiciones de programación y de data, al punto de inhabilitar durante un día la sucursal bancaria que tuvo que remitir a sus clientes a otras sucursales. Este error hizo que el job se consumiera el tiempo de CPU y acaparó la máquina para si mismo sin dejar ejecutar nada mas.

En este caso fue un error no intencionado que, sin embargo, dejó sin trabajo a su programador.

Un lazo de ejecución sin probarse en todos sus escenarios posibles y en contraste con los valores de la data contenida en la base de datos, puede ocasionar este caos.

Ø      Revisar la condición de terminación de los lazos es una tarea muy importante para evitar estos eventos que impactan la operatividad el negocio.



En muchas instalaciones el personal de auditoría se remite a la parte funcional de las aplicaciones y en pocas oportunidades a la revisión del software ya que, generalmente no son programadores o desarrolladores.

Existen muchos otros mecanismos para cometer fraude basado en errores en las pruebas, en inexperiencia del programador o en la altísima experiencia del programador.

 ¡ATENCION!. La intención no es enseñarles a cometer fraude sino a aprender a detectarlos. Queda en la ética de  cada quién utilizar los recursos y la información que llega a sus manos para el bien o para el mal. Recordemos que, como adultos responsables debemos atenernos a las consecuencias de nuestros actos.


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.


Publicado por: Ing. Liliana Suárez




jueves, 31 de mayo de 2012

Monitoreando Errores en Acceso a Archivos. Segunda Parte




 







Al actualizar un archivo, el registro actualizado es  desbloqueado (deallocated) y cualquier otro programa o proceso puede accederlo y modificarlo sin problemas.

Cuando trabajamos con subfiles, es necesario recargar el subfile cada vez que  la data ha sido actualizada en el programa a fin de mostrar la información actualizada.
Al leer un archivo para cargar el subfile y  evitar bloqueos innecesarios de un registro se deben realizar los read o chain sin bloqueos.
 Luego, una vez que el usuario ha confirmado su petición de grabar la información, realiza nuevamente, un chain pero con Bloqueo de registro y actualiza inmediatamente para permitir que otros procesos que están ejecutándose paralelamente al tuyo puedan acceder a la información y actualizarla en caso de ser necesario.

-------------------------
En este punto hago un paréntesis:
Cuando se realiza el segundo CHAIN o READ para grabar la información, tradicionalmente se usaba el “pool” de variables auxiliares declaradas para guardar los valores nuevos de los campos del archivo y que no se perdieran al hacer el Chain de actualización.
 Recuerda que utilizando el OCCUR puedes ahorrarte este inconveniente y ahorrar espacio y tiempo de programación. 
Puedes consultar este tema en un artículo anterior de este mismo blog:

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


Para cargar el subfile utiliza: la (N) permite hacer lecturas sin bloqueo de registro

KeyField       Chain (N)  FileName

O también:

               Read  (N)  FileName


Para actualizar un registro utiliza:

KeyField       Chain   FileName

En general, los desarrolladores no acostumbran realizar pruebas de la aplicación en un ambiente multiusuario. Para evitar errores innecesarios en el ambiente de producción solicita a varios programadores entrar a tu aplicación al mismo tiempo y te sorprenderás de cuantos se quedan “colgados” en alguna parte del proceso.


Otro error frecuente en la actualización de archivos es el de “CLAVE DUPLICADA”

Con estas instrucciones puedes monitorear el error y dar el mensaje sin producir esa fea caida de la pantalla que da muy mala impresiòn:

Chequear que se va a grabar clave duplicada:

C          Monitor
C          WRITE(E) FILENAME
C          On-Error 01021
C          CALL      PROGX
C          EndMon



Si te pareció interesante, reenvialo 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

jueves, 17 de mayo de 2012

Monitoreando Errores de Acceso a Archivos -Primera Parte.













Cuando realizamos una operación sobre un archivo de datos que requiere “bloquear” un registro, por ejemplo cuando hacemos un CHAIN (en un programa donde el archivo se ha declarado de UPDATE), puede suceder que ocurra un error de I/O porque otro job tiene bloqueado (allocated) el acceso al registro y el tiempo límite de espera para acceder el registro ha expirado. Esto puede acarrear que nuestro programa falle y se detenga la ejecución del mismo.

Generalmente no es obvio  extraer la información sobre el  otro job que no nos está dejando acceder al registro. Otras veces es nuestra propia programación que ha realizado una lectura previa del registro y  en la segunda vuelta de ejecución se encuentra el registro bloqueado.

Cuando el registro esta bloqueado, el archivo se coloca en Status de Error 1218. Podemos obtener la información básica sobre lo que sucede examinando los subcampos de la estructura de datos PSDS en las posiciones comprendidas desde la 91 hasta la 170. Con el Status de Archivo en 1218 este subcampo puede contener un mensaje de primer nivel como este:

Record 3 in use by job 029617/QPGMR/QPADEV0005.

El texto del subcampo puede contener el mensaje de error del Código de error CPF5027 cuando otro job está bloqueando el registro o puede contener el mensaje del código de Error CPF5032 cuando es nuestro propio job quien bloquea el acceso al registro.

Para mayor información de cómo se declara la estructura de datos de SDS (Status Data Structured) puedes consultar el siguiente enlace:


Para monitorear errores de lectura por bloqueo de registro este código puede ser de utilidad:

key  chain(E) file

select
when not %error

... Procesamiento Normal

when %error and %status = 01218


... Mensaje: “Registro Retenido por otro Usuario”
     En este punto puedes desplegar el contenido del campo 91-170
     De la SDS declarada en la hoja D de tu programa.

endsl


ALGO MÁS…

Cuando creamos un archivo, o definimos una descripción de trabajo (JOBD) generalmente tomamos  los valores por omisión en cuanto al tiempo de espera por el acceso a un registro (palabras claves: WAITRCD/WAITFILE).

Esto significa que nuestros Jobs van a esperar ese tiempo máximo definido en el archivo físico o en el job hasta que nuestro programa falle. Esto puede ser un tiempo de espera innecesario para procesos nocturnos o procesos diarios de cierre que requieren optimizar al máximo los tiempos de respuesta. Podemos, a través de este comando que realizamos sobre el archivo:

Ovrdbf waitrcd(*immed)

Hacer que nuestro job no espere nada. Es decir, inmediatamente detecta que el registro está bloqueado y nuestro monitoreo del mensaje de error puede mandar el mensaje  al operador o usuario del proceso para aplicar las medidas correctivas que se requieran en forma mas expedita.


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.


Publicado por: Ing. Liliana Suárez