Hola: Lamento tus problemas y te doy la razón en cuanto a tus quejas y te recomiendo que si quieres quejarte lo mejor es hacerlo a través de internet (mediante páginas de tipo feedback, por ejemplo).
La SI21923 no aparece en la base de datos de PTFs, así que debe ser una PTF de pruebas ¿me equivoco? El problema que comentas no solo sucede en V5R3...... tambien sucede en V5R2 !!! tal como indica el APAR SE23522 de la PTF. Así que todavía el problema es más grave. Yo por el momento no tengo una respuesta, pero seguiré investigando el problema y si veo alguna novedad te la haré llegar. SAlu2 El 5/01/06, Santiago G Martí<[EMAIL PROTECTED]> escribió: > > > > > Hola a todos. > Este es un mensaje de frustración y de petición de ayuda. > Estamos teniendo problemas con la base de datos del AS/400 y no conseguimos > una solución definitiva de IBM. > Cada PTF que sacan arregla un problema y crea otro o varios, como si no se > tomaran la molestia de comprobar el código que producen. > Creo que no nos toman en serio porque no es un problema crítico, de hecho > tienen razón ya que podemos seguir trabajando. > De todas formas es desquiciante. > > Parece ser que no le dan más importancia porque no lo sufre ningún otro > cliente y nosotros no somos un cliente lo bastante importante. > Por eso os pido que intentéis reproducir el problema y si tenéis contrato > de soporte lo reportéis, a ver si al ser un problema de varios clientes se > lo toman más en serio. > > El problema comenzó el 1 de octubre de 2005, cuando migramos de un 820 a un > 520. > Estamos en V5R3. > Antes de la migración instalamos la ultima acumulativa de PTF, HIPER y Base > de Datos, que había en ese momento, y ahí comenzaron los problemas. > > Al restaurar los ficheros en el 520, a algunos se les cambiaba el > identificador de nivel de formato, y posteriormente los programas fallaban > por LEVELCHECK. > Probamos a compilar los ficheros en el 520 (CRTLF) y los generaba con el > nivel de formato de restauración del 520, no con el que tenían en el 820. > Probamos a compilar los programas que fallaban en el 520 y al fallar la > compilación descubrimos la causa del cambio de nivel de formato. > En el 520, los ficheros lógicos no permitían valores NULL en los campos que > en el físico y en el 820 sí lo hacía. > > Llamamos al CAS, y en un par de horas nos facilitaron una PTF (SI18753) que > solucionaba el problema. > > El 30 de Noviembre, descubrimos que al hacer CRTDUPOBJ de algunos ficheros > (join con campos ocultos), el nuevo fichero tenía distinto identificador de > nivel de formato y DISTINTA LONGITUD de registro. > > Después de unas investigaciones descubrimos que el causante era la PTF > SI18753. > Al eliminarla desaparecía el nuevo problema, pero reaparecía el detectado > el 1 de Octubre. > > Nos dijeron que esa PTF estaba sustituida por la SI21275. > La aplicamos y no sólo no se solucionaba el problema, sino que reaparecía > el de 1 de Octubre. > (Realmente no se qué problemas podía resolver esta PTF). > > Nos dijeron que lo estudiarían y que mientras tanto decidiéramos qué > problema era más importante, así que decidimos eliminar la SI21275 y > continuar con la SI18753. > > El 3 de Enero (hace 3 días) nos dijeron que la solución era la PTF SI21923. > La instalamos y parecía que se solucionaban los problemas, pero APARECIERON > OTROS AUN MAS GRAVES: > > 1. Al hacer CRTDUPOBJ de algunos ficheros, físicos y lógicos, no solo el > nivel de formato del nuevo fichero era diferente, sino que se CAMBIABA el > nivel de formato del fichero ORIGINAL, de forma que coincidía con el nuevo. > Nunca hubiera creído que al hacer una copia de un objeto el objeto original > resultase modificado. > > 2. Aunque parezca increíble, los programas que utilizaban el fichero > original, con LEVELCHECK *YES, y que, como se podía ver con DSPPGMREF > esperaban que el fichero tuviera el nivel de registro antiguo, NO FALLABAN > por LEVELCHECK. > Yo confiaba ciegamente en la protección que ofrece el LEVELCHECK. Ahora ya > no estoy tan seguro. > > 3. Al crear una tabla, a partir del mismo fuente, el nivel de formato es > diferente, según esté aplicada o no la PTF SI21923. > Yo creía que el nivel de formato dependía del nombre del registro y de los > campos, de su orden y tamaño y de la posibilidad de aceptar valores nulos o > no, pero bajo ningún concepto que dependiera de la versión o del nivel de > PTF. > > > Bueno, perdonad por el rollo. > Si alguien tiene tiempo y le apetece, doy algunos detalles: > > Con DSPOBJD OBJ(QSYS/QDBCRTFI) OBJTYPE(*PGM) DETAIL(*SERVICE), se puede ver > el nivel de PTF de ese programa. > Parece ser, aunque no lo hemos podido comprobar, que con SI16105, funciona > correctamente. > Con SI17641, tenemos el problema detectado el 1 de Octubre. > Con SI18753, el detectado el 30 de Noviembre. > Y con el último SI21923, las nuevas aportaciones del laboratorio a mi > maltrecha confianza. > > Para crear la tabla: > CREATE TABLE YSANTIAGO1/ZCMSCGP > (SUBCTA CHAR (13) NOT NULL WITH DEFAULT ' ', > CUENTA CHAR (3) NOT NULL WITH DEFAULT ' ', > DESSUBCTA CHAR (30) NOT NULL WITH DEFAULT ' ', > INDAUX CHAR (1) NOT NULL WITH DEFAULT 'N', > INDCTAPER CHAR (1) NOT NULL WITH DEFAULT 'N', > TIPCTAPER CHAR (3) DEFAULT NULL, > IDCEE CHAR (2) DEFAULT NULL, > IVACEE CHAR (12) DEFAULT NULL, > RELIVA CHAR (2) DEFAULT NULL, > LIBIVA CHAR (3) DEFAULT NULL, > INDCARPAG CHAR (1) NOT NULL WITH DEFAULT 'N', > INDADMMOV CHAR (1) NOT NULL WITH DEFAULT 'N', > INDMOVPAN CHAR (1) NOT NULL WITH DEFAULT 'N', > FHULMO TIMESTAMP NOT NULL WITH DEFAULT '0001-01-01-00.00.00.00000' > INDACTIVO CHAR (1) NOT NULL WITH DEFAULT 'S') > > Con SI18753, el ID de formato es: 41FD853B85D4A. > Si aplicamos SI21923, al crear la tabla, el ID es: 41FD854A65E38. > Si, teniendo aplicada SI21923, hacemos CRTDUPOBJ de la tabla creada cuando > no teníamos aplicada esta PTF, el ID de la tabla es 41FD854A65E38, y el de > la original, que era 41FD853B85D4A, cambia a 41FD854A65E38. > > Para crear el fichero lógico y comprobar si permite nulos, el fuente es: > A R ZCMSCGP PFILE(ZCMSCGP) > A SUBCTA > * > A DESSUBCTA > A INDAUX > A INDCTAPER > A INDCARPAG > A INDMOVPAN > A INDACTIVO > * > A K SUBCTA > Para este fichero lógico el ID correcto, permitiendo valores nulos, es: > 4BAF12810FB66. > Si hacemos CRTDUPOBJ del fichero lógico, teniendo aplicada SI21923, el ID > de ambos, original y duplicado cambian a: 4A8F12811E967, que es el que > obtenemos si hacemos CRTLF con esta PTF aplicada. > > Si alguien ha conseguido llegar hasta aquí, muchas gracias por su tiempo y > su comprensión. > > > Saludos, > --------------------------- > Santiago Martí > Dusen, S.A. > --------------------------- > > > __________________________________________________ > Forum.HELP400 es un servicio más de NEWS/400. > (c) 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 > -- Mi blog sobre as400 http://www.ajut400.com __________________________________________________ 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
