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