Hemos tenido problemas recurrentes cuando se utiliza llamados a STOREDPROCEDURES en el ISERIES, sobre todo el problema se agudiza cuando se llega al limite de almacenamiento, lo recomendable es modificar el porcetanje MINIMO DE ALMACENAMIENTO para que puedan ejecutarse los SP.
El momento en que se modfica automaticamente empiezan a funcionar los SP.
En este caso tenemos unos servicios web generados con Java de Sun en Tomcat .
viernes, febrero 19, 2010
miércoles, febrero 10, 2010
GlassFish y Tomcat
Tomado de:
http://mx.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html?cid=e7959f
Si valora el rendimiento, la facilidad de uso y la agilidad de sus aplicaciones, considere detenidamente los detalles
El CEO siempre hace preguntas muy sencillas a la dirección de TI. ¿Por qué se quejan los clientes del nuevo sistema de pedidos en línea? ¿Por qué llevamos ocho meses intentando desplegar ese nuevo servicio Web? ¿Por qué falló esta mañana mi aplicación de informes financieros?
Lo que el CEO no suele preguntar es qué tecnología de servidor de aplicaciones utiliza la empresa. Pero en muchos casos, esa es la pregunta importante, porque hay una relación directa entre el servidor de aplicaciones utilizado por los equipos de desarrollo y el rendimiento y agilidad de las aplicaciones corporativas.
En concreto, la tecnología del contenedor Web utilizado en el servidor de aplicaciones puede ser un factor determinante para la calidad de las aplicaciones y la productividad de los desarrolladores. Con una tecnología de contenedor Web adecuada, los equipos de desarrollo abarcan más trabajo y las aplicaciones se desarrollan en menos tiempo y funcionan mejor. Una elección equivocada puede dar lugar a dolores de cabeza en el presente y en el futuro.
Si su negocio son las aplicaciones, merece la pena examinar detenidamente las entrañas del servidor de aplicaciones y la tecnología del contenedor Web y analizar su impacto en los equipos de desarrollo. En este artículo se comparan dos de las opciones de código abierto más populares: GlassFish y Tomcat.
Dos opciones populares, muchas diferencias importantes
GlassFish es el servidor de aplicaciones de código abierto creado por la comunidad GlassFish, lanzado por Sun en 2005, y que ha demostrado gozar de gran popularidad entre los desarrolladores. Actualmente, existen dos versiones principales: GlassFish v2 y la reciente Glassfish v3 Prelude. Hasta la fecha, se han descargado cerca de 9,000000 de copias de GlassFish v2, con 300,000 productos registrados sólo en 2009. GlassFish v3 Prelude ofrece nuevas características y mejoras. Es una excelente plataforma para desplegar aplicaciones de Internet con Java y lenguajes dinámicos como jRuby.
Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish.
El servidor de aplicaciones Tomcat fue promovido por Apache y un grupo que incluía a desarrolladores de Sun y JServ. El código inicial procedía de Sun. Tomcat fue fundamental para la adopción de Java en servidores, se ofrecía con una licencia de código abierto y contribuyó decisivamente a la implantación del software de código abierto en las grandes empresas.
En general, las aplicaciones que funcionan en Tomcat lo harán sin necesidad de cambios en GlassFish. Sin embargo, hay diferencias importantes que afectan al rendimiento, la escalabilidad y la facilidad de uso de las aplicaciones, así como a la productividad de los desarrolladores.
Para comprender estas diferencias, es importante examinar la tecnología del contenedor Web subyacente. El contenedor Web es la parte de un servidor de aplicaciones que se encarga de manejar los servlets, las páginas JavaServer Pages (JSP) y otros componentes del nivel Web.
Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish:
Ruta de migración más sencilla. Con GlassFish v2 hay una forma clara y sencilla de aprovechar tecnologías tales como Enterprise Java Beans (EJBs), Java Persistence API (JPA) y Java Message Service (JMS), entre otras. Con Tomcat, estas tecnologías deben agregarse poco a poco, una a una. El desarrollador es responsable de implementar las capacidades y de asegurarse de que todo el conjunto funcione.
Preparado para entornos de clustering con failover. GlassFish v2 ofrece capacidad de clustering y sofisticadas funciones de alta velocidad para que las aplicaciones puedan cumplir los exigentes acuerdos de nivel de servicio (SLA) de tipo empresarial. GlassFish v3 Prelude admite clustering a través de un equilibrador de carga, aunque todavía no tiene un perfil de clustering.
Superioridad en la administración y la supervisión. GlassFish v2 y v3 Prelude permiten la administración centralizada a través de una consola de administración y de una interfaz de línea de comandos (CLI). GlassFish v2 ofrece supervisión Callflow, que permite a un desarrollador de aplicaciones o un administrador de servidores determinar a qué dedica la aplicación la mayor parte de su tiempo. Esta característica también estará disponible en GlassFish v3. Además, otros proveedores pueden ofrecer su software a través de GlassFish Update Center para facilitar la instalación en GlassFish. Con Tomcat, el software nuevo se configura de forma poco sistemática. Update Center también proporciona acceso en primicia a las nuevas versiones de tecnologías tales como EJB 3.1, que permite empaquetar EJB en un WAR en lugar de empaquetar la aplicación en un archivo EAR.
Compatibilidad con lenguajes de script. GlassFish admite, o lo hará en breve, Ruby/JRuby, Python/Jython, Groovy, PHP, JavaScript/Phobos y Scala, entre otros lenguajes.
Lo esencial: diferencias adicionales entre los contenedores Web
Además de las ventajas generales mencionadas, GlassFish se diferencia de Tomcat por las posibilidades que ofrece su contenedor Web. Le ofrecemos algunos ejemplos:
La capacidad de retener sesiones entre distintos despliegues de aplicaciones (v3 Prelude) supone un importante ahorro de tiempo para los desarrolladores que crean aplicaciones Web Java.
GGlassFish v2 y v3 Prelude facilita la reconfiguración dinámica de servidores virtuales y Listeners HTTP sin necesidad de reiniciar el servidor. Con Tomcat, cuando se modifica una fuente de recursos, suele ser necesario reiniciar el servidor de aplicaciones.
En v2 y v3 Prelude, el entorno Grizzly de alto rendimiento y alta escalabilidad mejora los tiempos de solicitud/respuesta. Las capas inferiores del nivel Web de GlassFish se implementan a través de Grizzly Framework. Este entorno está escrito en Java y aprovecha las APIs NIO (red escalable y E/S de archivos) para proporcionar escalabilidad y es altamente personalizable.
GlassFish v2 y v3 Prelude incluyen varias optimizaciones de rendimiento, como “flattened valve invocation”, una modificación de la arquitectura de válvula que racionaliza la forma de llamar a cada válvula, reduciendo así la profundidad de la pila y mejorando el rendimiento. GlassFish v3 Prelude también admite válvulas de estilo Tomcat.
Sun ha realizado pruebas exhaustivas de escalabilidad para comparar los conectores NIO de Tomcat y Glassfish. Estas pruebas utilizan un servlet simple para minimizar el tiempo dedicado en el contenedor y medir cuántas operaciones por segundo admiten los distintos contenedores para incrementar el número de usuarios. Por ejemplo, con 16,000 usuarios, el benchmark arroja los siguientes resultados:
GLASSFISH TOMCAT
Operaciones/segundo 6988,9 6615,3
Tiempo medio respuesta 0,242 0,358
Tiempo máx. respuesta 1,519 3,693
90% tiempo respuesta 0,6 0,75
Consiga todos los detalles y tome la decisión adecuada
La selección de un servidor de aplicaciones afecta a muchos aspectos de las operaciones de la empresa, no sólo a los equipos de desarrollo. Se trata de una decisión con gran carga estratégica para el negocio. Sun afirma que GlassFish ha demostrado ser una opción superior para los desarrolladores de la nueva generación. Pero le animamos a documentarse en profundidad y a sopesar detenidamente sus alternativas. Encontrará información adicional y estudios comparativos de GlassFish y Tomcat en nuestro informe técnico.
http://mx.sun.com/emrkt/innercircle/newsletter/0209/feature-itm.html?cid=e7959f
Si valora el rendimiento, la facilidad de uso y la agilidad de sus aplicaciones, considere detenidamente los detalles
El CEO siempre hace preguntas muy sencillas a la dirección de TI. ¿Por qué se quejan los clientes del nuevo sistema de pedidos en línea? ¿Por qué llevamos ocho meses intentando desplegar ese nuevo servicio Web? ¿Por qué falló esta mañana mi aplicación de informes financieros?
Lo que el CEO no suele preguntar es qué tecnología de servidor de aplicaciones utiliza la empresa. Pero en muchos casos, esa es la pregunta importante, porque hay una relación directa entre el servidor de aplicaciones utilizado por los equipos de desarrollo y el rendimiento y agilidad de las aplicaciones corporativas.
En concreto, la tecnología del contenedor Web utilizado en el servidor de aplicaciones puede ser un factor determinante para la calidad de las aplicaciones y la productividad de los desarrolladores. Con una tecnología de contenedor Web adecuada, los equipos de desarrollo abarcan más trabajo y las aplicaciones se desarrollan en menos tiempo y funcionan mejor. Una elección equivocada puede dar lugar a dolores de cabeza en el presente y en el futuro.
Si su negocio son las aplicaciones, merece la pena examinar detenidamente las entrañas del servidor de aplicaciones y la tecnología del contenedor Web y analizar su impacto en los equipos de desarrollo. En este artículo se comparan dos de las opciones de código abierto más populares: GlassFish y Tomcat.
Dos opciones populares, muchas diferencias importantes
GlassFish es el servidor de aplicaciones de código abierto creado por la comunidad GlassFish, lanzado por Sun en 2005, y que ha demostrado gozar de gran popularidad entre los desarrolladores. Actualmente, existen dos versiones principales: GlassFish v2 y la reciente Glassfish v3 Prelude. Hasta la fecha, se han descargado cerca de 9,000000 de copias de GlassFish v2, con 300,000 productos registrados sólo en 2009. GlassFish v3 Prelude ofrece nuevas características y mejoras. Es una excelente plataforma para desplegar aplicaciones de Internet con Java y lenguajes dinámicos como jRuby.
Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish.
El servidor de aplicaciones Tomcat fue promovido por Apache y un grupo que incluía a desarrolladores de Sun y JServ. El código inicial procedía de Sun. Tomcat fue fundamental para la adopción de Java en servidores, se ofrecía con una licencia de código abierto y contribuyó decisivamente a la implantación del software de código abierto en las grandes empresas.
En general, las aplicaciones que funcionan en Tomcat lo harán sin necesidad de cambios en GlassFish. Sin embargo, hay diferencias importantes que afectan al rendimiento, la escalabilidad y la facilidad de uso de las aplicaciones, así como a la productividad de los desarrolladores.
Para comprender estas diferencias, es importante examinar la tecnología del contenedor Web subyacente. El contenedor Web es la parte de un servidor de aplicaciones que se encarga de manejar los servlets, las páginas JavaServer Pages (JSP) y otros componentes del nivel Web.
Mientras que GlassFish es un conjunto de contenedores Java EE, uno de los cuales es un contenedor Web, Tomcat es sólo un contenedor Web. Esta diferencia fundamental se traduce en una serie de ventajas importantes para GlassFish:
Ruta de migración más sencilla. Con GlassFish v2 hay una forma clara y sencilla de aprovechar tecnologías tales como Enterprise Java Beans (EJBs), Java Persistence API (JPA) y Java Message Service (JMS), entre otras. Con Tomcat, estas tecnologías deben agregarse poco a poco, una a una. El desarrollador es responsable de implementar las capacidades y de asegurarse de que todo el conjunto funcione.
Preparado para entornos de clustering con failover. GlassFish v2 ofrece capacidad de clustering y sofisticadas funciones de alta velocidad para que las aplicaciones puedan cumplir los exigentes acuerdos de nivel de servicio (SLA) de tipo empresarial. GlassFish v3 Prelude admite clustering a través de un equilibrador de carga, aunque todavía no tiene un perfil de clustering.
Superioridad en la administración y la supervisión. GlassFish v2 y v3 Prelude permiten la administración centralizada a través de una consola de administración y de una interfaz de línea de comandos (CLI). GlassFish v2 ofrece supervisión Callflow, que permite a un desarrollador de aplicaciones o un administrador de servidores determinar a qué dedica la aplicación la mayor parte de su tiempo. Esta característica también estará disponible en GlassFish v3. Además, otros proveedores pueden ofrecer su software a través de GlassFish Update Center para facilitar la instalación en GlassFish. Con Tomcat, el software nuevo se configura de forma poco sistemática. Update Center también proporciona acceso en primicia a las nuevas versiones de tecnologías tales como EJB 3.1, que permite empaquetar EJB en un WAR en lugar de empaquetar la aplicación en un archivo EAR.
Compatibilidad con lenguajes de script. GlassFish admite, o lo hará en breve, Ruby/JRuby, Python/Jython, Groovy, PHP, JavaScript/Phobos y Scala, entre otros lenguajes.
Lo esencial: diferencias adicionales entre los contenedores Web
Además de las ventajas generales mencionadas, GlassFish se diferencia de Tomcat por las posibilidades que ofrece su contenedor Web. Le ofrecemos algunos ejemplos:
La capacidad de retener sesiones entre distintos despliegues de aplicaciones (v3 Prelude) supone un importante ahorro de tiempo para los desarrolladores que crean aplicaciones Web Java.
GGlassFish v2 y v3 Prelude facilita la reconfiguración dinámica de servidores virtuales y Listeners HTTP sin necesidad de reiniciar el servidor. Con Tomcat, cuando se modifica una fuente de recursos, suele ser necesario reiniciar el servidor de aplicaciones.
En v2 y v3 Prelude, el entorno Grizzly de alto rendimiento y alta escalabilidad mejora los tiempos de solicitud/respuesta. Las capas inferiores del nivel Web de GlassFish se implementan a través de Grizzly Framework. Este entorno está escrito en Java y aprovecha las APIs NIO (red escalable y E/S de archivos) para proporcionar escalabilidad y es altamente personalizable.
GlassFish v2 y v3 Prelude incluyen varias optimizaciones de rendimiento, como “flattened valve invocation”, una modificación de la arquitectura de válvula que racionaliza la forma de llamar a cada válvula, reduciendo así la profundidad de la pila y mejorando el rendimiento. GlassFish v3 Prelude también admite válvulas de estilo Tomcat.
Sun ha realizado pruebas exhaustivas de escalabilidad para comparar los conectores NIO de Tomcat y Glassfish. Estas pruebas utilizan un servlet simple para minimizar el tiempo dedicado en el contenedor y medir cuántas operaciones por segundo admiten los distintos contenedores para incrementar el número de usuarios. Por ejemplo, con 16,000 usuarios, el benchmark arroja los siguientes resultados:
GLASSFISH TOMCAT
Operaciones/segundo 6988,9 6615,3
Tiempo medio respuesta 0,242 0,358
Tiempo máx. respuesta 1,519 3,693
90% tiempo respuesta 0,6 0,75
Consiga todos los detalles y tome la decisión adecuada
La selección de un servidor de aplicaciones afecta a muchos aspectos de las operaciones de la empresa, no sólo a los equipos de desarrollo. Se trata de una decisión con gran carga estratégica para el negocio. Sun afirma que GlassFish ha demostrado ser una opción superior para los desarrolladores de la nueva generación. Pero le animamos a documentarse en profundidad y a sopesar detenidamente sus alternativas. Encontrará información adicional y estudios comparativos de GlassFish y Tomcat en nuestro informe técnico.
Configurando Glassfish en Windows
Tomado de:
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=InstalacionConfiguracionGlassfish
Fecha de creación del tutorial: 2009-11-11
INSTALACIÓN DE GLASSFISH 2.1
Sitio donde descargar Glassfish:
https://glassfish.dev.java.net/downloads/v2.1-b60e.html
En este tutorial nos veremos cómo instalar el servidor de aplicaciones GlassFish. Además veremos los primeros pasos, como entrar en la consola de administración del servidor, y desplegar una aplicación EAR (Enterprise Application).
DESCARGA E INSTALACIÓN DE GLASSFISH
Para empezar sigamos los siguientes pasos para descargar e instalar el servidor.
1. Descargar el contenido de https://glassfish.dev.java.net/downloads/v2.1-b60e.html, elegir nuestra plataforma de manera adecuada.
2. Copiar dicho contenido el directorio donde lo queramos instalar, en este caso en el disco raíz.
3. Ejecutar el comando “java -Xmx256m -jar filename.jar” donde filename.jar es el nombre del archivo que hemos descargado.
4. En este momento se ejecuta la instalación de Glassfish 2.1. En la siguiente ventana leemos las condiciones de uso y pulsamos Accept
5. Comienza el proceso de instalación, al finalizar nos muestra el mensaje “Installataion Complete”
6. A continuación nos disponemos a configurar el servidor mediante la ejecución del archivo “setup.xml”. Para ello hacemos uso del compilador ANT, en caso de no tenerlo en nuestra máquina, el mismo Glassfish trae una distribución incluida. Ejecutamos el comando:
“lib\ant\bin\ant -f setup.xml”
Comienza el proceso y en la siguiente pantalla veremos que el build ha ido bien:
Si deseamos tener un Glassfish como cluster, en vez del anterior comando, ejecutamos “lib\ant\bin\ant -f setup-cluster.xml”
Si observamos el contenido del archivo setup.xml podemos ver que se trata de opciones de configuración de nuestro servidor (puerto de acceso, clave y usuario inicial...) y de ciertas tareas que se realizan en función del sistema operativo donde estemos instalando (linux, windows, solaris...)
PRIMEROS PASOS
Para iniciar nuestro servidor, desde la consola de comandos y desde el directorio de Glassfish\bin, ejecutamos el comando “asadmin start-domain domain1”. Cuando se inicia el servicio veremos la siguiente ventana:
Una vez iniciado el servidor, podemos acceder a la consola a través del navegador, concretamente a través del puerto por defecto 4848.
Como veíamos en el contenido de setup.xml, el user por defecto era “admin” y el password “adminadmin”.
Para detener nuestro servidor, desde la consola de comandos y desde el directorio de Glassfish\bin, ejecutamos el comando “asadmin stop-domain domain1”.
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=InstalacionConfiguracionGlassfish
Fecha de creación del tutorial: 2009-11-11
INSTALACIÓN DE GLASSFISH 2.1
Sitio donde descargar Glassfish:
https://glassfish.dev.java.net/downloads/v2.1-b60e.html
En este tutorial nos veremos cómo instalar el servidor de aplicaciones GlassFish. Además veremos los primeros pasos, como entrar en la consola de administración del servidor, y desplegar una aplicación EAR (Enterprise Application).
DESCARGA E INSTALACIÓN DE GLASSFISH
Para empezar sigamos los siguientes pasos para descargar e instalar el servidor.
1. Descargar el contenido de https://glassfish.dev.java.net/downloads/v2.1-b60e.html, elegir nuestra plataforma de manera adecuada.
2. Copiar dicho contenido el directorio donde lo queramos instalar, en este caso en el disco raíz.
3. Ejecutar el comando “java -Xmx256m -jar filename.jar” donde filename.jar es el nombre del archivo que hemos descargado.
4. En este momento se ejecuta la instalación de Glassfish 2.1. En la siguiente ventana leemos las condiciones de uso y pulsamos Accept
5. Comienza el proceso de instalación, al finalizar nos muestra el mensaje “Installataion Complete”
6. A continuación nos disponemos a configurar el servidor mediante la ejecución del archivo “setup.xml”. Para ello hacemos uso del compilador ANT, en caso de no tenerlo en nuestra máquina, el mismo Glassfish trae una distribución incluida. Ejecutamos el comando:
“lib\ant\bin\ant -f setup.xml”
Comienza el proceso y en la siguiente pantalla veremos que el build ha ido bien:
Si deseamos tener un Glassfish como cluster, en vez del anterior comando, ejecutamos “lib\ant\bin\ant -f setup-cluster.xml”
Si observamos el contenido del archivo setup.xml podemos ver que se trata de opciones de configuración de nuestro servidor (puerto de acceso, clave y usuario inicial...) y de ciertas tareas que se realizan en función del sistema operativo donde estemos instalando (linux, windows, solaris...)
PRIMEROS PASOS
Para iniciar nuestro servidor, desde la consola de comandos y desde el directorio de Glassfish\bin, ejecutamos el comando “asadmin start-domain domain1”. Cuando se inicia el servicio veremos la siguiente ventana:
Una vez iniciado el servidor, podemos acceder a la consola a través del navegador, concretamente a través del puerto por defecto 4848.
Como veíamos en el contenido de setup.xml, el user por defecto era “admin” y el password “adminadmin”.
Para detener nuestro servidor, desde la consola de comandos y desde el directorio de Glassfish\bin, ejecutamos el comando “asadmin stop-domain domain1”.
viernes, febrero 05, 2010
Como Arrancar el Servidor de Acceso en el ISERIES
Tomado de:
http://www-03.ibm.com/systems/i/software/access/linux/guide/cwbcoer.html#StartHostServer
To start all of the host socket servers on the AS/400 system, type the following command at the AS/400 command prompt:
STRHOSTSVR SERVER(*ALL)
To start just the signon server on the AS/400 system, type:
STRHOSTSVR SERVER(*SIGNON *SVRMAP)
To use the socket servers, the QUSER profile on the AS/400 system must be enabled and the password must not be expired. One way to make sure that the QUSER profile is always enabled is to set the password with no expiration time value. To do this, type the following command at the AS/400 prompt:
CHGUSRPRF USRPRF(QUSER) PASSWORD(*NONE) PWDEXP(*NO) STATUS(*ENABLED) PWDEXPITV(*NOMAX)
If you are having trouble starting the host socket servers, try the following:
1. Type STRHOSTSVR SERVER(*ALL) at the AS/400 command prompt.
2. If step 1 does not work, type ENDHOSTSVR SERVER(*ALL) to end the host socket servers, then try step 1 again.
3. If step 2 does not work, type NETSTAT at the AS/400 command prompt. Then select option 3. Work with TCP/IP connection status. Look for any jobs with TCP addresses beside them. End those jobs with option 4, then try step 1 again.
The various servers on the AS/400 system have different timeout values that come into play when the PC goes down before the connection is disconnected. For example, in the case where your PC goes into a hang condition before you can disconnect all of your host server connections and data queues, you will have server jobs active on the AS/400 system until they timeout. This timeout could be minutes, hours, or days, depending on the server.
Ending the host servers does not clean up the jobs running on the AS/400 when the ENDHOSTSVR command is run on the AS/400. The good thing about not cleaning up jobs is that your host server connections and data queues will continue to work after the ENDHOSTSVR command is run. The downside to not cleaning up server jobs on the AS/400 is that jobs that are still active prevent the server from starting when the STRHOSTSVR command is run on the AS/400.
When ending and restarting host servers on the AS/400, you should use the CWBPING command from a Client Access Express workstation to make sure the host servers actually start back up. If they do not start back up, use the NETSTAT command and end any active jobs with TCP/IP addresses next to them.
http://www-03.ibm.com/systems/i/software/access/linux/guide/cwbcoer.html#StartHostServer
To start all of the host socket servers on the AS/400 system, type the following command at the AS/400 command prompt:
STRHOSTSVR SERVER(*ALL)
To start just the signon server on the AS/400 system, type:
STRHOSTSVR SERVER(*SIGNON *SVRMAP)
To use the socket servers, the QUSER profile on the AS/400 system must be enabled and the password must not be expired. One way to make sure that the QUSER profile is always enabled is to set the password with no expiration time value. To do this, type the following command at the AS/400 prompt:
CHGUSRPRF USRPRF(QUSER) PASSWORD(*NONE) PWDEXP(*NO) STATUS(*ENABLED) PWDEXPITV(*NOMAX)
If you are having trouble starting the host socket servers, try the following:
1. Type STRHOSTSVR SERVER(*ALL) at the AS/400 command prompt.
2. If step 1 does not work, type ENDHOSTSVR SERVER(*ALL) to end the host socket servers, then try step 1 again.
3. If step 2 does not work, type NETSTAT at the AS/400 command prompt. Then select option 3. Work with TCP/IP connection status. Look for any jobs with TCP addresses beside them. End those jobs with option 4, then try step 1 again.
The various servers on the AS/400 system have different timeout values that come into play when the PC goes down before the connection is disconnected. For example, in the case where your PC goes into a hang condition before you can disconnect all of your host server connections and data queues, you will have server jobs active on the AS/400 system until they timeout. This timeout could be minutes, hours, or days, depending on the server.
Ending the host servers does not clean up the jobs running on the AS/400 when the ENDHOSTSVR command is run on the AS/400. The good thing about not cleaning up jobs is that your host server connections and data queues will continue to work after the ENDHOSTSVR command is run. The downside to not cleaning up server jobs on the AS/400 is that jobs that are still active prevent the server from starting when the STRHOSTSVR command is run on the AS/400.
When ending and restarting host servers on the AS/400, you should use the CWBPING command from a Client Access Express workstation to make sure the host servers actually start back up. If they do not start back up, use the NETSTAT command and end any active jobs with TCP/IP addresses next to them.
Suscribirse a:
Entradas (Atom)