Migrando a V5R1M0 desde V4R4M0 o V4R5M0

[SAMUEL MOREIRA]

Para el forum.   He migrado el 10 de marzo, una maquina 720-208D, desde V4R4 a V5R1.   Las fallas encontradas van desde la no conversi�n de objetos tipo *FILE hasta el bloqueo en los stack de TCP.   Un sin numero de falla se presentaron y fuimos parchando a punta de PTF's sueltas, CUM y Grupos todo esto con gu�a de LAB-USA.   Hoy en d�a persisten tres fallas que no hemos podido superar y es por lo cual les env�o esta nota para intercambiar experiencias.   1.- Funciones de uso o administraci�n del objetos QEZJOBLOG tipo *OUTQ bloquean el objeto por largos periodos.  Dejando a los trabajos de usuario en estado LCKW.   Al visualizar la actividad de los job's de sistema WRKACTJOB JOB(*SYS), se aprecia que los trabajos QSPLMAIN y SCPF se mantienen en estado RUN o LCKW largos periodos. mientras esta condici�n se da nadie puede acceder al objeto en cuesti�n.   Esta misma situaci�n se da con la cola de salida definida en el valor de sistema  QPRTDEV la cual es usada como OUTQ default por los job's.     Para manejar este tema bajamos a cero los niveles de LOG de job's y planificamos para la noche los procesos de limpieza de SPOOL y Log's de anotaciones.  Ademas de cargar Parches espec�ficos para el manejo de colas.     2.- Bloqueos o Embargos.   Constantemente los job's de usuario logean el MSGID MCH3601 indicando que no pueden acceder a un objetos, ya sea Base de Datos, *OUTQ, etc.   Para esta falla aun no encontramos soluci�n.     3.-  Ca�da de Sesiones Telnet 5250.  Nuestros usuarios reportan que sus sesiones d CA/400 luego de estar funcionado quedan negras. Al validar en el sistema detectamos que su sesi�n aun permanece activa dentro del subsistema QINTER,  y validado en el NETSTAT op 3 vemos que su enlace TELNET-TCP esta activo. Chequeamos v�a PING de ida y vuelta al PC y el enlace esta OK.   Aun sin soluci�n.     Otras de las sintomatolog�a que estamos viviendo es que los job's una vez que entran en estado RUN quedan sin leer las bases de datos (*FILE)  por largos ciclos.  simplemente no leen.   Pensando que el problema era falta de recursos,  en un ambiente de test asignamos prioridad 15, timeslice 999999  y lo dejamos correr en una agrupaci�n (pool de memoria) de 2GB de memoria, ning�n otro trabajo bloqueando las tablas. Y para sorpresa el Jobs no lee. Luego de minutos el trabajo comienza su ciclo normal de ejecuci�n.   Hemos convertido los objetos , puesto parches para los archivos de referencias cruzadas, ejecutado RCLSTG *DBXREF.    Tenemos instalado el CUM C2036510   y estamos a la espera  del CUM C2071510. solo esta liberado para USA.   Esto en resumen a sido nuestra experiencia con V5R1M0.    Toda experiencia o informaci�n ser� bienvenida.     Samuel Moreira Ing.de Sistemas D&S. Santiago-Chile