|
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 >>> [EMAIL PROTECTED] 05-04-2002 >>> Hola a todos �Alguien me puede enviar un ejemplo basico de como controlar el TIMEOUT de la funcion CONNECT() de los sockets? Un saludo Fernando Martinez _____________________________________________________ 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, env�a el mensaje resultante de pulsar mailto:[EMAIL PROTECTED]?body=LEAVE |
