Hola Carlos,
En cuanto al rendimiento, no estoy de acuerdo.
Lo que puede degradar el rendimiento es el número de vías de acceso
(índices), no el número de ficheros lógicos (vistas).
Si sólo tienes una vía de acceso, el rendimiento es el mismo sin ficheros
lógicos, con 1 fichero lógico y con 3.000 ficheros lógicos.
Acepto que al utilizar muchos lógicos se pueden crear inadvertidamente vías
de acceso innecesarias, pero siendo riguroso las mantienes a raya.
Si te preocupa el rendimiento, dos consideraciones que sólo se pueden medir
con grandes números de accesos de lectura:
Utilizar un lógico con sólo 4 campos es mucho más rápido que utilizar el
físico con 40 campos.
Los ficheros creados con SQL son mucho más eficientes que los creados
con DDS, aunque se utilicen con accesos tradicionales de CHAIN y READ.
Respecto a los problemas de utilizar LVLCHK(*NO):
Posibilidad de cometer errores, como por ejemplo si el campo no se añade
al final del fichero o si, al mismo tiempo, se modifica la longitud de
otro campo, o si más adelante se hace otro cambio y se olvida de
compilar algún programa.
Programando con un poco de precaución, los errores que se producen por
LVLCHK(*YES) son fáciles de solucionar, y el tratamiento inadecuado de
un fichero por LVLCHK(*NO) puede resultar una pesadilla.
Algunas veces el sistema operativo falla, por eso hay PTF, o quizá falla
porque hay PTF... Bueno ese es otro tema.
Nosotros hemos sufrido casos en los cuales, por fallo del sistema
operativo, al restaurar un fichero desde cinta, al crear una copia de
fichero (CRTDUPOBJ), e incluso al recompilar el fichero a partir del
mismo fuente, el fichero se creaba con longitud de registro diferente,
con valores por defecto diferentes, etc.
Afortunadamente, los ficheros restaurados y/o creados tenían ID de
niveles de formato distintos de los originales, y los programas daban
error antes de que el error se convirtiera en desastre.
El caso más llamativo fue cuando al hacer un CRTDUPOBJ del fichero A, en
el fichero B, cambiaba el ID de formato, no sólo del fichero B sino
también del A, e incluso del C, que aparentemente no pintaba nada en
esta fiesta.
Afortunadamente, estos fallos son poco frecuentes, pero son
imprevisibles y a nosotros nos ha ocurrido 4 veces, en cambios de
Release, al aplicar PTF acumulativas, al aplicar PTF que solucionaban un
problema y creaban dos...
No hay que olvidar a Murphy.
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 17:42 ¿o no?
Por favor,
responda a
[EMAIL PROTECTED]
bios.es
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
__________________________________________________
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
