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.

Friday, December 7, 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
                 

Monday, November 19, 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

Sunday, November 11, 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