Hola Fernando:
Lo mismo, y diferente.
Fíjate que el problema está en el identificador de nivel de formato, por lo
que al hacer CREATE TABLE se debe emplear el mismo nombre, ya sea en otra
biblioteca o renombrando la tabla original.
Si la tabla resultante contiene un campo TIME STAMP, efectivamente el nivel
de formato resultante es el mismo que con CRTDUPOBJ.
Es diferente en cuanto a que el nivel de formato en la tabla original NO
cambia, cosa que sí sucede con DRTDUPOBJ.
Saludos,
---------------------------
Santiago Martí
Dusen, S.A.
---------------------------
Fernando Martínez
<[EMAIL PROTECTED]
sistemas.net> Para
Enviado por: [email protected]
forum.help400-adm cc
[EMAIL PROTECTED]
Asunto
Re: Fallos en la Base de Datos.
16/01/2006 16:22
Por favor,
responda a
[EMAIL PROTECTED]
bios.es
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
__________________________________________________
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
