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