Hola Santiago, efectivamente tienes mucha razón, pero en este caso no puedo cambiar el nombre de mis archivos por un tema de estandares de denominación. Por otro lado tener un número excesivo de archivos lógicos podría degradar el rendimiento de nuestras aplicaciones y por no mencionar el tema de espacio. Bueno esta es una de las recomendaciones que recogí de alguna gente de IBM. Una duda que todavía me queda, te entiendo que LVLCHK(*NO) se debe utilizar únicamente en casos extremos y como solución transitoria, nunca como solución definitiva. Yo había pensado que una alternativa muy práctica podría ser cambiar a LVLCHK(*NO) y solo compilar los programas que usan el nuevo campo, los demás programas no verían dicho campo. Pero tu me dices que podrían ocurrir problemas propios e incluso errores del sistema. ¿Cuáles serían o en que circunstancias podría presentarse estos ?
Muchas gracias por tu respuesta
Saludos

Carlos Augusto Correa García

Santiago G Martí escribió:



Hola Carlos, parece que llego tarde y ya has dado por cerrado el tema.

Sin embargo no me resisto a darte mi punto de vista basado en la
experiencia de muchos años (anterior al AS/400).

En primer lugar, utilizar un campo con un nombre confuso o para un fin
distinto al previsto es apostar por problemas a medio plazo.
En segundo, una de las mejores protecciones que aporta AS/400 frente a
otras bases de datos es la comprobación de nivel, por lo que indicar que no
compruebe el formato de registro es anular una maravillosa característica
de la base de datos que te protege de errores propios e incluso de errores
del sistema (lo hemos sufrido).
Puedo asegurar, y así lo entiende IBM, que LVLCHK(*NO) se debe utilizar
únicamente en casos extremos y como solución transitoria, nunca como
solución definitiva.

Nosotros nunca trabajamos directamente con los ficheros físicos, sino con
ficheros lógicos.
De esta forma, añadir un campo al fichero físico no implica recompilar
ningún programa que no necesite ese campo.
De hecho, sobre cada fichero físico creamos gran cantidad de lógicos, de
forma que cada programa sólo vea los campos que necesita.
Llevado al límite, sería casi como tener un fichero lógico para cada
programa.

Para el caso que planteas, sobre un fichero que ya existe, y dejando aparte
las implicaciones de restricciones etc., hay todavía otra solución:
  cambias el nombre del fichero físico.
  creas sobre él un fichero lógico, con el nombre del antiguo fichero
  físico, con su nombre de registro y enumerando todos los campos.
  Este fichero lógico tendrá el nombre del fichero físico y su
  identificador de Nivel de Formato, por lo que no será necesario
  recompilar ningún programa y seguirás estando protegido.
  al fichero físico, ya sea por ALTER TABLE o CHGPF le añades el nuevo
  campo.
  En los programas que necesites ese nuevo campo puedes utilizar el nuevo
  fichero físico, o crear un fichero lógico que lo incluya.
  (Te recomiendo que en los ficheros lógicos siempre enumeres los campos).

Por supuesto, esta solución no es viable si se trata de un ERP externo.
También adolece del cambio de nombre del físico real, que puede confundir a
más de uno.
Pero evitas la compilación, sigues protegido y utilizas los campos con
nombres y características adecuadas.



Saludos,
                 ---------------------------
                   Santiago Martí
                      Dusen, S.A.
                 ---------------------------



Carlos Augusto Correa García <[EMAIL PROTECTED] Para om.pe> [email protected] Enviado por: cc forum.help400-adm [EMAIL PROTECTED] Asunto Re: Consulta filosofal a los programadores (Cerrando el tema) 22/02/2006 01:55 Por favor, responda a [EMAIL PROTECTED] bios.es



Amigos del foro, lo positivo de esto es recoger las conlusiones y es
justo para ello he planteado la pregunta.  Esta pregunta la planteo
pues  necesito  definir los estandares de  desarrollo de sistemas  en la
empresa en la  que trabajo ; es por ello que lo que parece una consulta
muy simple encierra mucho significado. No es que me haga problemas, sino
lo que trato es de  aliviarme los del futuro.
En resumen tenemos las siguientes alternativas.

  1. Usar el campo que no se utiliza, sin nungun cambio en la tabla
     (solución simple - de corto plazo)
  2. Agrego el nuevo campo con un nombre memonico adecuado, asumiendo
     el trabajo que implica recompilar más de 1500 objetos. (solución
     complicada - acádemicamente la más adecuada - a largo plazo)
  3. Agregar un archivo anexo al mencionado (solución semi-simple)
  4. Añadir el campo, compilar el archivo pero diciéndole que no
     compruebe el formato de registro FMTCHK(*NO). Con lo que sólo se
     tendrá que compilar aquellos programas donde se quiera que el
     nuevo campo sea "visible". Los programas que no se complien no
     emitirán una excepción de ejecución pero tampoco tendrán "visible"
     el nuevo campo. (solución práctica)
  5. Cambiar en el fuente DDS (en este caso es DDS) la descripciòn del
     campo y recompilarlo conservando data (backup/restore). Ahi no hay
     necesidad de cambiar programas, ni nada, no darìa error de nivel,
     porque solo se cambia la descripcion del campo a nivel de fuente DDS.

Conclusiones
Desde mi punto de vista personal habría que evaluar los escenarios
(parece una respuesta muy triada); sin embargo creo que se debe apuntar
a un buen diseño de la base de datos,  por lo que personalmente
recomiendo alternativas como la 2 o como la 4, lo que nos garantizará un
tiempo de vida mayor de nuestras aplicaciones y por ende contribuirá a
que la plataforma iSeries AS/400 tenga una mayor permanencia en este
mercado tan competitivo.

Saludos cordiales y gracias por sus respuestas

Carlos Augusto Correa García

Pedro Molina escribió:

Mira, en mi modesta opiniòn, yo lo que harìa serìa lo siguiente:

Si tienes DDS's para ese archivo, pues saca copia de este en otro
archivo, y cambias en las DDS la descripciòn del campo y lo creas de
nuevo.

Seguidamente inserta en el archivo que recien creaste, la copia que
sacaste anteriormente y asunto arreglado, no tienes que cambiar
programas , ni nada, no te darìa error de nivel, porque solo cambiaste
la descripcion del campo a nives de DDS.

No te enrolles !!

Saludos !!





------------------------------------------------------------------------
       From:  /Carlos Augusto Correa García <[EMAIL PROTECTED]>/
       Reply-To:  /[email protected]/
       To:  /[email protected]/
       Subject:  /Consulta filosofal a los programadores/
       Date:  /Tue, 21 Feb 2006 13:33:03 -0500/
       >Saludos amigos del foro,
       >tengo una consultilla de la cual espero recibir algunas
       opiniones a
       >mis amigos programadores, logicamente cada uno puede tener
       puntos de
       >vista diferentes. Resulta que tengo un archivo en el cual se
       graba
       >data muy importante del negocio y necesito agregarle un campo
       más;
       >sin embargo tengo otro campo sin usar que tiene un nombre
       >completamente diferente, que no tendría nada que ver con el
       >significado del valor que pretendo agregar pero tiene el
       mismo tipo
       >de dato que necesito. La idea es que si agrego el campo
       implica que
       >tengo que recompilar por lo menos 1,500 programas entre
       RPG's, CL's
       >y otros, y si uso el campo que no se usa me evito todo ese
       trabajo;
       >pero los programadores y usuarios especializados que acceden
       a la
       >base de datos, cuando necesiten usar dicha información en el
       futuro
       >(primero encontrarla) probablemente no me lo van a agardecer.
       >En resumen tengo dos y hasta tres alternativas:
       >1) Uso el campo que no está siendo usado (solucion simple)
       >2) Agrego el campo nuevo con su significado real y denominación
       >nemotecnica adecuada, trabajo complicado)
       >3) Agregar un archivo anexo al mencionado (solución semi-simple)
       >Denme ideas... (...por cierto mi jefe opina que no me
       problemas y
       >que opte por la 1.. pero la teoría de BD me dice que opte por
       la 2..
       >ya es un tema de conciencia).
       >Que opinan los programadores y no programadores??? Que haría un
       >developer de SAP o JD'Edwars??
       >Nota: La pregunta parece muy simple pero encierra mucho
       significado
       >en el "largo plazo" de la vida de nuestros sistemas
       >;-)
       >Saludos
       >
       >Carlos Augusto Correa García
       >CMAC PIURA S.A.C.
       >__________________________________________________
       >Forum.HELP400 es un servicio más de NEWS/400.
       >© Publicaciones Help400, S.L. - Todos los derechos reservados
       >http://www.help400.es
       >_____________________________________________________
       >
       >Para darte de baja visita la siguente URL:
       >http://coyote.combios.es/mailman/listinfo/forum.help400


------------------------------------------------------------------------
MSN Amor Busca tu ½ naranja <http://g.msn.com/8HMBES/2752??PS=47575>
__________________________________________________ Forum.HELP400 es un
servicio más de NEWS/400. © Publicaciones Help400, S.L. - Todos los
derechos reservados http://www.help400.es
_____________________________________________________ Para darte de
baja visita la siguente URL:
http://coyote.combios.es/mailman/listinfo/forum.help400

__________________________________________________
Forum.HELP400 es un servicio más de NEWS/400.
© Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________

Para darte de baja visita la siguente URL:
http://coyote.combios.es/mailman/listinfo/forum.help400



__________________________________________________
Forum.HELP400 es un servicio más de NEWS/400.
© Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________

Para darte de baja visita la siguente URL:
http://coyote.combios.es/mailman/listinfo/forum.help400

__________________________________________________
Forum.HELP400 es un servicio más de NEWS/400.
© Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________

Para darte de baja visita la siguente URL:
http://coyote.combios.es/mailman/listinfo/forum.help400

Responder a