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. © 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
