Al hilo de todo esto, ¿habeis probado a duplicarlo por SQL con un
CREATE TABLE ..... AS Select...? ¿Ocurre lo mismo?
Salu2
Fernando Martinez
Santiago G Martí 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.
© 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
|
