Hola de nuevo: tal como te dije sigo pendiente de los movimientos de IBM y hoy mismo hay novedades sobre tu problema:
La PTF SI21923 ha sido sustituida por la SI22347 no he tenido tiempo de probar si el problema se soluciona te copio la URL al covver letter de la PTF http://www-912.ibm.com/a_dir/as4ptf.nsf/b3cb9d42f672b70f86256739004afa0f/26e96afe6c2f29c186257107005dd267?OpenDocument Salu2 El 16/01/06, Santiago G Martí<[EMAIL PROTECTED]> escribió: > > > > > Hola Alex: > > Gracias, pero no. > > Hasta donde nosotros hemos probado, la solución es la PTF SI21923. > > El problema, es cómo corregir la base de datos para que a partir de aquí no > empiece a dar errores cada vez que dupliquemos un fichero. > > Hemos consultado a IBM, y la sorprendente respuesta es que cambiemos los > ficheros a LVLCHK(*NO). Son unos genios. > > La solución, que tenemos prevista para el próximo sábado es: > - Salvar en cinta las tres bibliotecas involucradas. > - Borrar las Bibliotecas (DLTF). > - Aplicar la PTF. > - Restaurar las bibliotecas. > - Recompilar 661 programas. > > El problema es que la Base de Datos está formada por 191 tablas con 250 > restricciones FK y 1051 ficheros lógicos, y además todos las tablas tienen > montones de registros, así que salvar, restaurar y reconstruir vías de > acceso lleva un tiempo. > Lo que queremos es que tanto las tablas como los LF queden con los niveles > de formato correcto para evitar futuras sorpresas. > En principio no nos molesta recompilar los programas. Lo teníamos previsto. > La clave de la solución es la eliminación de los ficheros antes de la > restauración ya que, al contrario de lo que indica IBM, si se restaura un > fichero ya existente NO se arregla el nivel de formato, sino que conserva > el incorrecto y posteriormente lo "arregla" cuando menos te lo esperas. > > > Saludos, > --------------------------- > Santiago Martí > Dusen, S.A. > --------------------------- > > > El temor que tenemos es que surja un problema inesperado y nos quedemos al > aire. > > > > > > > > alex martinez > <[EMAIL PROTECTED] > m> Para > Enviado por: [email protected] > forum.help400-adm cc > [EMAIL PROTECTED] > Asunto > Re: Fallos en la Base de Datos. > 13/01/2006 17:42 > > > Por favor, > responda a > [EMAIL PROTECTED] > bios.es > > > > > > > Hola Santi: > > hoy ha salido esta PTF SI21271 para QDBCRTFI > > http://www-912.ibm.com/a_dir/as4ptf.nsf/b3cb9d42f672b70f86256739004afa0f/107b230f842325cf862570f50052a5e3?OpenDocument > > > no la he probado pero quizás algo se solucione > > El 11/01/06, Santiago G Martí<[EMAIL PROTECTED]> escribió: > > > > > > > > > > Hola Alex, gracias por tu aportación. > > He estado bastante ocupado investigando. > > > > La explicación, al menos en parte, está en el APAR SE22099 y PTF SI20165. > > > > Según parece, en algún momento no identificado del pasado se cometió un > > error, de forma que dos registros idénticos, conteniendo un campo > > timestamp, producían distintos niveles de formato, según fueran creados > con > > DDS o SQL - CREATE TABLE. > > > > Aparentemente el error estaba, o se consideró menos impactante, en la > forma > > SQL, de manera que con SI20165 y SI21923 se corrige. > > En la COVER LETTER de SI20165 sí que avisa que, a partir de ese momento, > la > > creación de tablas y ficheros lógicos puede producir niveles de formato > > diferentes de los esperados. > > > > Aunque contiene un error (it should not change on restore) ya que > depende, > > a veces cambia y a veces no. > > Si se restaura el fichero sobre uno existente, no cambia, pero si se > > elimina el fichero antes de la restauración entonces SÍ que cambia. > > > > Tampoco advierte que la utilización de CRTDUPOBJ puede producir el cambio > > de nivel de formato en el fichero original, ya que "como es sabido, > > los ficheros creados con CRTDUPOBJ comparten el formato". > > > > Perfecto que lo compartan, pero que compartan el existente, y no que > creen > > uno nuevo, sin previo aviso, y lo compartan retroactivamente. > > > > Puede resultar curioso que si, antes de aplicar estas PTF, tienes el > > fichero A, haces CRTDUPOBJ y obtienes el B y el C, posiblemente en otras > > bibliotecas, aplicas la PTF, y tiempo después haces CRTDUPOBJ del C, y > > automáticamente te cambia el nivel de registro del fichero A, aunque esté > > en otra biblioteca. > > > > También puede chocar que tengas una aplicación funcionando en una máquina > > sin la PTF, hagas una copia (SAVOBJ), la restaures en otra máquina con la > > PTF aplicada, y automáticamente empieces a recibir CPF4131. > > > > Bueno, las causas parecen claras. > > > > Una recomendación para los que tengan V5R3 y utilicen tablas SQL, (no se > > cómo puede afectar a otras releases): > > Con las debidas precauciones se debe aplicar la PTF SI21923, ya que > corrige > > varios problemas bastante serios de la base de datos. > > > > > > > > Saludos, > > --------------------------- > > Santiago Martí > > Dusen, S.A. > > --------------------------- > > > > > > > > > > > > > > > > alex martinez > > <[EMAIL PROTECTED] > > m> > Para > > Enviado por: [email protected] > > forum.help400-adm > cc > > [EMAIL PROTECTED] > > > Asunto > > Re: Fallos en la Base de Datos. > > 05/01/2006 18:27 > > > > > > Por favor, > > responda a > > [EMAIL PROTECTED] > > bios.es > > > > > > > > > > > > > > Te cuento lo que he probado en dos maquinas, una en V5R3 y otra en V5R2 > > > > En V5R3 con la PTF SI21923 aplicada: > > > > He creado el archivo y el nivel es el 41FD853B85D4A > > > > despues de un CRTDUPOBJ el original ha cambiado a 41FD854A65E38 y la > > copia tambien tiene el mismo identificador 41FD854A65E38. > > > > Y ahora lo que pasa en V5R2 (QUE ES CORRECTO) con el nivel de PTF de > > QDBCRTFI que tengo en V5R2 es el SI17006 y con el nivel siguiente, > > PTFs SI18066 y SI18068 > > al Crear el archivo el identificador es 41FD853B85D4A se mantiene > > despues del CRTDUPOBJ > > > > La equivalente para el APAR SE20036 en V5R3 es la SI18065 ¿has probado > > con este nivel de PTFs? Yo no puedo probarlo porque tengo aplicada > > permanentemente la SI21275 que es la que sustituye a la SI18065. :-( > > > > Resumiendo, parece/creo que con la SI18065 y SI18067 en V5R3 debe > > funcionarte bien. > > > > Y tal como has explicado a partir de la SI18753, SI21275 ó SI21923 > > (todas son niveles de servicio de QDBCRTFI) los niveles de archivos > > "son manipulados". > > > > Ninguna de todas estas PTFs de V5R3 están en ningun acumulativo ni > > siquiera en las listas de PTFs de base de datos..... lo que es otra > > pista de que el tema no lo tiene resuelto IBM. > > > > Salu2 > > > > El 5/01/06, alex martinez<[EMAIL PROTECTED]> escribió: > > > 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 > > > > > > > > > -- > > Mi blog sobre as400 > > http://www.ajut400.com > > > > __________________________________________________ > > 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 > > > > > > > > __________________________________________________ > > 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. > (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 > > > > __________________________________________________ > 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
