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