TCP/IP

Las características del protocolo TCP

TCP (que significa Protocolo de Control de Transmisión) es uno de los principales protocolos de la capa de transporte del modelo TCP/IP. En el nivel de aplicación, posibilita la administración de datos que vienen del nivel más bajo del modelo, o van hacia él, (es decir, el protocolo IP). Cuando se proporcionan los datos al protocolo IP, los agrupa en datagramas IP, fijando el campo del protocolo en 6 (para que sepa con anticipación que el protocolo es TCP). TCP es un protocolo orientado a conexión, es decir, que permite que dos máquinas que están comunicadas controlen el estado de la transmisión.
Las principales características del protocolo TCP son las siguientes:

TCP permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP.
TCP permite que el monitoreo del flujo de los datos y así evita la saturación de la red.
TCP permite que los datos se formen en segmentos de longitud variada para "entregarlos" al protocolo IP.
TCP permite multiplexar los datos, es decir, que la información que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma línea pueda circular simultáneamente.
Por último, TCP permite comenzar y finalizar la comunicación amablemente.

El objetivo de TCP

Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores. Esto significa que los routers (que funcionan en la capa de Internet) sólo tienen que enviar los datos en forma de datagramas, sin preocuparse con el monitoreo de datos porque esta función la cumple la capa de transporte (o más específicamente el protocolo TCP).

Durante una comunicación usando el protocolo TCP, las dos máquinas deben establecer una conexión. La máquina emisora (la que solicita la conexión) se llama cliente, y la máquina receptora se llama servidor. Por eso es que decimos que estamos en un entorno Cliente-Servidor.
Las máquinas de dicho entorno se comunican en modo en línea, es decir, que la comunicación se realiza en ambas direcciones.

Para posibilitar la comunicación y que funcionen bien todos los controles que la acompañan, los datos se agrupan; es decir, que se agrega un encabezado a los paquetes de datos que permitirán sincronizar las transmisiones y garantizar su recepción.

Otra función del TCP es la capacidad de controlar la velocidad de los datos usando su capacidad para emitir mensajes de tamaño variable. Estos mensajes se llaman segmentos.

La función multiplexión

TCP posibilita la realización de una tarea importante: multiplexar/demultiplexar; es decir transmitir datos desde diversas aplicaciones en la misma línea o, en otras palabras, ordenar la información que llega en paralelo.

Estas operaciones se realizan empleando el concepto de puertos (o conexiones), es decir, un número vinculado a un tipo de aplicación que, cuando se combina con una dirección de IP, permite determinar en forma exclusiva una aplicación que se ejecuta en una máquina determinad

Confiabilidad de las transferencias

El protocolo TCP permite garantizar la transferencia de datos confiable, a pesar de que usa el protocolo IP, que no incluye ningún monitoreo de la entrega de datagramas.

De hecho, el protocolo TCP tiene un sistema de acuse de recibo que permite al cliente y al servidor garantizar la recepción mutua de datos.
Cuando se emite un segmento, se lo vincula a un número de secuencia. Con la recepción de un segmento de datos, la máquina receptora devolverá un segmento de datos donde el indicador ACK esté fijado en 1 (para poder indicar que es un acuse de recibo) acompañado por un número de acuse de recibo que equivale al número de secuencia anterior.

Además, usando un temporizador que comienza con la recepción del segmento en el nivel de la máquina originadora, el segmento se reenvía cuando ha transcurrido el tiempo permitido, ya que en este caso la máquina originadora considera que el segmento está perdido.

Sin embargo, si el segmento no está perdido y llega a destino, la máquina receptora lo sabrá, gracias al número de secuencia, que es un duplicado, y sólo retendrá el último segmento que llegó a destino.

Cómo establecer una conexión

Considerando que este proceso de comunicación, que se produce con la transmisión y el acuse de recibo de datos, se basa en un número de secuencia, las máquinas originadora y receptora (cliente y servidor) deben conocer el número de secuencia inicial de la otra máquina.

La conexión establecida entre las dos aplicaciones a menudo se realiza siguiendo el siguiente esquema:

Los puertos TCP deben estar abiertos.
La aplicación en el servidor es pasiva, es decir, que la aplicación escucha y espera una conexión.
La aplicación del cliente realiza un pedido de conexión al servidor en el lugar donde la aplicación es abierta pasiva. La aplicación del cliente se considera "abierta activa".

Las dos máquinas deben sincronizar sus secuencias usando un mecanismo comúnmente llamado negociación en tres pasos que también se encuentra durante el cierre de la sesión.

Este diálogo posibilita el inicio de la comunicación porque se realiza en tres etapas, como su nombre lo indica:

En la primera etapa, la máquina originadora (el cliente) transmite un segmento donde el indicador SYN está fijado en 1 (para indicar que es un segmento de sincronización), con número de secuencia N llamado número de secuencia inicial del cliente.
En la segunda etapa, la máquina receptora (el servidor) recibe el segmento inicial que viene del cliente y luego le envía un acuse de recibo, que es un segmento en el que el indicador ACK está fijado en 1 y el indicador SYN está fijado en 1 (porque es nuevamente una sincronización). Este segmento incluye el número de secuencia de esta máquina (el servidor), que es el número de secuencia inicial para el cliente. El campo más importante en este segmento es el de acuse de recibo que contiene el número de secuencia inicial del cliente incrementado en 1.
Por último, el cliente transmite un acuse de recibo, que es un segmento en el que el indicador ACK está fijado en 1 y el indicador SYN está fijado en 0 (ya no es un segmento de sincronización). Su número de secuencia está incrementado y el acuse de recibo representa el número de secuencia inicial del servidor incrementado en 1.

Después de esta secuencia con tres intercambios, las dos máquinas están sincronizadas y la comunicación puede comenzar.

Existe una técnica de piratería llamada falsificación de IP, que permite corromper este enlace de aprobación con fines maliciosos.

Método de ventana corrediza

En muchos casos, es posible limitar la cantidad de acuses de recibo con el fin de aliviar el tráfico en la red. Esto se logra fijando un número de secuencia después del cual se requiera un acuse de recibo. Este número en realidad se guarda en el campo ventana del encabezado TCP/IP.

Este método se llama efectivamente el "el método de la ventana corrediza" porque, en cierta medida, se define una serie de secuencias que no necesitan acuses de recibo y que se desplaza a medida que se reciben los acuses de recibo.

Además, el tamaño de esta ventana no es fijo. De hecho, el servidor puede incluir el tamaño de la ventana que considera más apropiado en sus acuses de recibo guardándolo en el campo ventana. De este modo, cuando el acuse de recibo indica un pedido para aumentar la ventana, el cliente se desplazará al borde derecho de la ventana.

Por el contrario, en el caso de una reducción, el cliente no desplazará el borde derecho de la ventana hacia la izquierda sino que esperará que avance el borde izquierdo (al llegar los acuses de recibo).

Cómo terminar una conexión

El cliente puede pedir que se termine una conexión del mismo modo que el servidor.
Para terminar una conexión se procede de la siguiente manera:

Una de las máquinas envía un segmento con el indicador FIN fijado en 1, y la aplicación se autocoloca en estado de espera, es decir que deja de recibir el segmento actual e ignora los siguientes.
Después de recibir este segmento, la otra máquina envía un acuse de recibo con el indicador FIN fijado en 1 y sigue enviando los segmentos en curso. Después de esto, la máquina informa a la aplicación que se ha recibido un segmento FIN y luego envía un segmento FIN a la otra máquina, que cierra la conexión.
Identifique los trabajos servidores TCP/IP y de iSeries Access ejecutándose en su sistema AS/400.

TCP/IP e iseries Access for Windows ofrecen una amplia gama de servicios basada en un importante conjunto de trabajos servidores. Estos trabajos permiten que un usuario pueda iniciar una emulación de pantalla, realizar una transferencia de archivos, acceder a través de ODBC a una base de datos, realizar tareas de administración utilizando iSeries Navigator, entre muchas otras posibilidades. Los trabajos involucrados en este tipo de tareas se encuentran distribuidos en distintos subsistemas y frecuentemente es difícil identificarlos por nombre y determinar cuál es el servicio que ofrecen. Teniendo en cuenta que la identificación de un trabajo en particular es un prerrequisito para el análisis de problemas y la posibilidad de determinar de qué manera estos trabajos influyen en la performance, el objetivo del presente tip es proporcionar algunas herramientas que ayuden a identificar los principales trabajos servidores, tanto de iseries Access como de TCP/IP. Estas posibilidades incluyen formas de reconocimiento desde “pantalla verde” con comandos de manejos de jobs, y también desde iSeries Navigator, por medio de los componentes apropiados.
Queda fuera del alcance de este tip el detalle de la configuración de TCP/IP y la explicación de las aplicaciones.

Trabajos servidores de TCP/IP

El soporte de comunicaciones TCP/IP requiere que el programa servidor de una aplicación esté ejecutando ( y “esperando”), antes que cualquier requerimiento de ese servicio pueda ser atendido y resuelto por ese servidor. Por ejemplo, antes de poder establecer una sesión Telnet, el programa servidor Telnet en AS/400 debe estar activo y “escuchando” en un puerto determinado.

En AS/400 los trabajos que constituyen el soporte de TCP/IP, son similares a cualquier otro trabajo que corre en el AS/400. Como todo trabajo, los trabajos servidores de TCP/IP tienen un nombre y “corren” en algún subsistema. En el caso de los trabajos servidores de TCP/IP, el subsistema por default es QSYSWRK.
Los trabajos del TCP/IP correspondientes al servicio de Web (HTTP Server), que atiende requerimientos solicitados desde un Web Browser, desde la V4R3 del OS/400 corren en un subsistema independiente denominado QHTTPSVR.

Es posible visualizar los trabajos servidores de las distintas aplicaciones o servicios de TCP/IP que están activos, mediante la línea de comandos en “pantalla verde” o utilizando iSeries Navigator.

Si se tiene en cuenta que los trabajos servidores de TCP/IP corren por default en el subsistema QSYSWRK, para visualizar desde “pantalla verde” todos los trabajos servidores activos, se puede utilizar el comando WRKACTJOB o directamente WRKSBSJOB (Work with Subsystem Jobs) sobre el subsistema QSYSWRK. La salida obtenida al ejecutar cualquiera de los comandos anteriores va a depender de si se especificó o no que arranquen los servicios de TCP/IP en el IPL. Se puede establecer qué servicios del TCP/IP arrancan en el IPL o decidir arrancarlos manualmente con el comando STRTCPSVR.
Si se desea operar desde la interfaz de iSeries Navigator, la siguiente ventana muestra los trabajos servidores de TCP/IP que están iniciados y los que aún están detenidos:

Como mencionáramos anteriormente, los trabajos servidores de TCP/IP pueden ser arrancados automáticamente en el IPL. Si no se estableció ese tipo de arranque, se los puede arrancar (y deterner) manualmente desde “pantalla verde” (por medio del comando STRTCPSVR y ENDTCPSVR, respectivamente), o utilizando la interfaz gráfica iSeries Navigator, como muestra la ventana de arriba. En este último caso, sobre un servidor determinado, las opciones del menú de contexto (botón derecho del mouse) sobre el mismo, permite iniciarlo o detenerlo. Dentro del mismo menú contextual, se pueden visualizar los trabajos servidores relacionados específicamente con este servicio y además, acceder a Propiedades de configuración.
La siguiente tabla muestra la lista de servidores de TCP/IP y su propósito. Si están activos, pueden visualizarse estos trabajos en el subsistema QSYSWRK:

Consideraciones sobre trabajos servidores de TCP/IP
Los trabajos servidores de TCP/IP en QSYSWRK corren bajo el perfil de usuario QTCP, con algunas excepciones: el servidor “Pasarela de estación de trabajo (“Workstation Gateway”) que corre bajo el usuario QTMTWSG, el Servidor Trivial FTP, que lo hace con el usuario QTFTP y el servidor de Directorios LDAP, que utiliza el perfil de usuario QDIRSRV.

El servidor de Directorios LDAP arranca varios trabajos con nombre QSQSRVR. Los trabajos con esta denominación realizan funciones SQL para el el servidor LDAP. Además, los trabajos QSQSRVR son usados, por ejemplo por Management Central y típicamente por aplicaciones basadas en Java que ejecutan SQL .

El string “xxxxx” al final de algunos nombres de trabajos en la tabla anterior, indica que varios procesos de este tipo pueden estar corriendo en el subsistema. OS/400 asigna automáticamente un número detrás del nombre del trabajo cuando se arranca un nuevo proceso del servidor. El número de procesos del servidor que se ejecutan concurrentemente depende: del número de procesos que arrancan automáticamente (especificado en los atributos del servidor), del número de procesos arrancados manualmente con el comando STRTCPSVR, y además del número de procesos arrancados por el OS/400 para acomodar los requerimientos que ingresan al sistema de acuerdo a la carga del sistema.

Finalizar trabajos con nombre QTVDEVICE no afecta las sesiones corrientes activas sobre el sistema. Sin embargo, si se finalizan todos los trabajos con nombre QTVDEVICE, no se podrá arrancar ninguna sesión de dispositivo o finalizar apropiadamente las sesiones corrientes activas. En términos generales, va a existir el mismo número de trabajos con nombre QTVTELNET que con nombre QTVDEVICE.
Los trabajos QTVDEVICE son usados para la asignación de dispositivos de los trabajos Telnet. Finalizar el o los trabajos del servidor Telnet no finalizará los trabajos con nombre QTVDEVICE.

Es importante indicar que, además de los trabajos servidores mencionados en la tabla anterior, pueden existir otros trabajos servidores de TCP/IP activos dependiendo de si el servicio correspondiente está arrancado o no.

Como ejemplo de otros servidores, es posible encontrar dentro del subsistema QSYSWRK trabajos servidores con nombre QYPSJSVR y QYPSSRV realcionados con el Servicio de Management Central (componente del iSeries Navigator), o en el caso de que esté activo el servidor de Webfacing, los trabajos QQFVTSVR y QQFWFSVR, entre otros tipos de servicios, los cuales pueden ser arrancados o finalizados de la misma manera que cualquier otro servicio de TCP/IP.

Se puede notar en la tabla de arriba que la mayoría de los trabajos servidores de TCP/IP corren en el subsistema QSYSWRK. Sin embargo, es importante destacar que los trabajos de TCP/IP relacionados con la disponibilidad de Web Server del AS/400 (HTTP Server), no corren en este susbsistema sino en el subsistema QHTTPSVR. Además, de estar arrancado el servicio de Administración de Servidores Web del OS/400, se podrán visualizar en este subsistema varios trabajos con nombre ADMIN, entre los distintos nombres de trabajos correspondientes a servidores Web que se hayan configurado y activado dentro del sistema.

Trabajos servidores de iseries Access for Windows

Los Host Servers de OS/400 actúan como el servicio de back-end para iSeries Access. Este conjunto de programas servidores controla funciones tales como acceso a base de datos utilizando ODBC o verificación de usuario y contraseña para los distintos servicios que lo requieran. Los Host Servers se comunican con iseries Access vía sockets de TCP/IP. Los sockets son medios en la comunicación que permiten a las aplicaciones enviar y recibir datos sobre redes TCP/IP. Un número de port asignado a la aplicación server es contactado desde la aplicación y utilizado para enviar datos hacia y desde aquella aplicación.

Existen nueve Host Servers, cada uno de los cuales controla una determinada tarea del lado del servidor. La siguiente ventana muestra los Host Servers de iseries Access desde iSeries Navigator:

La siguiente es la lista de servidores de iseries Access for Windows y su función. Lo expresado entre paréntesis indica el nombre del trabajo “demonio” que lo identifica:

Central Server (QZSCSRVSD): es usado para la gestión del sistema cliente. Maneja funciones tales como la gestión de licencias del Client Access, para aquellos componentes que lo requieren, como PC5250 y transferencia de datos. Además, este server es el encargado de realizar las conversiones necesarias de EBCDIC a ASCII y a la inversa en aquellos procedimientos que lo requieran.
Data Base Server (QZDASRVSD): maneja todas las comunicaciones de datos incluyendo ODBC, transferencia de datos y accesos OLE DB, soporte de SQL remoto, funciones de base de datos (crear y suprimir archivos, agregar y remover miembros), entre las funciones más importantes. El control de este servidor puede ser útil cuando se desea inhabilitar los accesos ODBC u OLE DB a la base de datos de AS/400. Para realizar esta tarea, sólo se necesita finalizar este servidor, y todos los accesos a base de datos remotos no podrán ser resueltos.
Data Queue Server (QZHQSRVD): permite a las aplicaciones que corren en PC tener acceso a las colas de datos de AS/400. También está involucrado en la algunas de las funcionalidades de OLE DB.
File Server (QPWFSERVSD): ofrece la funcionalidad de carpetas compartidas. Es usado para almacenar y acceder a cualquiera de los “file systems” soportados por el IFS (Integrated File System) del AS/400. Para ampliar conceptos sobre IFS, referirse Qué es el IFS y como accederlo.
Network Print Server (QNPSERVD): habilita la impresión de red a través del AS/400. Ofrece las funciones de impresora virtual de las viejas versiones de Client Access, sólo que con más capacidades para el manejo de impresión.
Remote Command Server (QZRCSRVSD): (también Program Call Server). Permite que las aplicaciones que corren en PC invoquen a programas y ejecuten comandos sobre el AS/400 y devuelvan valores a la aplicación cliente.
Signon Server (QZSOSGND): es utilizado para funciones de gestión de password para los jobs que se comunican con el AS/400 a través de Host Servers. Además se utiliza para cambios de password a través de Client Access.
Server Port Mapper (QZSOSMAPD): permite que un cliente encuentre el puerto para trabajar con un Host Server en particular.

Desde la interfaz iSeries Navigator, para cada servidor, el menú de contexto ofrece opciones para arrancar y detener el servidor, ver y modificar propiedades, y visualizar los trabajos demonios y de prearranque que lo “representan”. Esta información permitiría identificar los nombres de los usuarios que están haciendo uso de los servicios del servidor en cuestión. Por ejemplo, para conocer quiénes están utilizando accesos a bases de datos vía ODBC, sobre el servidor de Base de Datos realizar los siguientes pasos: Red → Servidores → iSeries Access → Base de datos → menú de contexto (botón derecho del mouse) → Trabajos servidores. Se visualizará la siguiente ventana:

La columna “Usuario actual” indica los nombres de los usuarios que están utilizando los servicios de accesos ODBC.

Este mismo “mecanismo” pero aplicado sobre el servidor de Mandato Remoto permite conocer los nombres de los usuarios que están utilizando otras opciones de iSeries Navigator.

Nota: las columnas que se observan en la ventana anterior fueron seleccionadas utilizando la opción “Opciones” de la barra de herramientas y luego “Columnas”. Desde allí se pueden incluir u omitir las columnas deseadas.

Desde V5R1, para los trabajos servidores es posible analizar sus propiedades, ver la descripción del servidor y la dirección IP del cliente para el cual el servidor está trabajando.

Convenciones para los nombres de los trabajos servidores

Es bien sabido que el nombre de un trabajo usado en iSeries consiste de tres partes: el nombre del trabajo, el nombre del perfil de usuario y el número de job (en orden ascendente).

Para el caso de los trabajos servidores, los nombres de los mismos siguen determinadas convenciones :

El nombre del trabajo servidor
- Para cualquier trabajo que no sea de prearranque, el nombre del trabajo servidor es el nombre del programa servidor.

Los trabajos de prearranque usan el nombre que está definido en la entrada de trabajos de prearranque.
Los trabajos que son arrancados por los servidores usan el nombre de la descripción del job o un nombre determinado si se trata de trabajos batch .
Es siempre QUSER, sin tener en cuenta si se usan o no los trabajos de prearranque.

El nombre del Perfil de usuario

- Las anotaciones del trabajo (job log) muestra cuáles usuarios han usado o están usando el trabajo.
El número del trabajo es creado por el Work Management.

Subsistemas utilizados por los trabajos servidores

Los Host Servers están configurados para correr en diferentes subsistemas, según sus funciones. Cada uno de estos Host Servers está representado por un trabajo “demonio o daemon” que manejan la comunicación inicial con el cliente. Estos trabajos “daemons” son los encargados de arrancar uno o varios trabajos servidores que se ocuparán de recibir y resolver cada uno de los requerimientos de los clientes, de acuerdo al tipo de operación solicitada. Una vez que el cliente establece las comunicaciones con el trabajo servidor, no existe más la asociación entre el cliente y el “server daemon” mientras dure la ejecución del trabajo servidor.

Como ejemplo: cuando una aplicación requiere una conexión ODBC a un archivo de base de datos de AS/400, el driver ODBC correspondiente inicia la comunicación que es recibida por el demonio Database Server (QZDASRVSD, uno de los Host Servers disponibles). Este trabajo servidor, luego somete un trabajo de prearranque Database Server QZDASOINIT. Una instancia de este trabajo de prearranque QZDASOINIT se arrancará por cada cliente que solicite una conexión. Este último job será el que realmente devuelve los registros al driver ODBC. De la misma manera que en el ejemplo anterior, para cada uno de los restantes servidores existe un demonio que recibe la petición inicial, que luego somete un trabajo de prearranque que será el que, de ahí en adelante, interactuará con el cliente. Una vez que el cliente establece comunicaciones con el trabajo servidor, no existe de alí en adelante ninguna asociación entre el cliente y el servidor “daemon” mientras dure la ejecución de ese trabajo servidor.

Desde iSeries Navigator pueden visualizarse los trabajos contenidos en cada uno de estos subsistemas:

QSYSWRK: todos los “demonios” (con excepción del “file server” y del “database server”) corren en este subsistema. Los demonios file server y database server corren en el subsistema QSERVER.

QSERVER: el job demonio correspondiente al database server, el demonio del file server y el trabajo de prearranque del file server deben correr en este subsistema. Si este subsistema no está activo, los pedidos para establecer una conexión al file server o al database server, fallarán.

QUSRWRK: aquí se ejecutan los trabajos de prearranque sometidos por los todos los trabajos demonios que corren en los subsistemas anteriores: Network Print, Remote Command/Program Call, Central, Data Queue, Signon y Database.

De la misma manera que en la imagen anterior se muestran los trabajos del subsistema QSYSWRK, se pueden visualizar los trabajos demonios o de prearranque de los subsistemas QSERVER y QUSRWRK.

Sobre cada uno de los trabajos que se visualizan en la ventana anterior, desde el menú de contexto, se puede operar con los trabajos servidores de la misma manera que con cualquier otro tipo de trabajo: ver joblog, analizar propiedades, trabajar con salida impresa, retenerlo, finalizarlo, entre otras posibilidades. Es conveniente, en caso de necesitar detener el servidor y rearrancarlo, operar desde Red à Servidores à Client Access. Luego ubicar el servidor necesario y desde el menú de contexto detener y arrancar nuevamente.

Nombres de los trabajos servidores demonios y trabajos de prearranque:

La siguiente tabla muestra los nombres de los trabajos servidores demonios y sus trabajos de prearranque asociados. Esta información puede resultar particularmente útil para identificar los trabajos y sus funciones cuando se los analiza desde WRKACTJOB.

Para tener en cuenta...

Las aplicaciones o servicios de TCP/IP operan sobre puertos standard dentro del soporte de comunicaciones de TCP/IP. Los servicios más comunes de TCP/IP utilizan un número de puerto en el rango de 1 a 1023. Se los denomina “well- known ports”. Por ejemplo, el puerto 23 es el puerto “well-known” para el servicio Telnet de TCP/IP.
El comando DSPLOG (Visualizar anotaciones históricas) puede ser usado para identificar qué trabajo está asociado con un usuario cliente en particular (se lo identifica por la dirección IP del cliente). Para ubicar más fácilmente estos tipos de trabajos buscar por los Identificadores de mensaje CPIAD0B (para mensajes de sign-on server ) y CPIAD09 (para mensajes relacionados con los servidores restantes).

Se pueden configurar atributos de cada servidor de TCP/IP desde “pantalla verde” a través del menú CFGTCP o desde iSeries Navigator : Red → Servidores → TCP/IP y luego botón derecho sobre el servidor con el que se desea trabajar.

Los trabajos servidores de Web (HTTP server) en el subsistema QHTTPSVR corren bajo el perfil de usuario QTMHHTTP.

Los Host Servers de iseries Access for Windows están representados como producto bajo licencia con la opción 12 del sistema operativo: 5722SS1 Host Servers.
Un trabajo “daemon” o “demonio” es un trabajo batch asociado con un tipo de servidor particular. Existe sólo un “server daemon” para cada tipo de servidor (por ej. un daemon para database, otro para network print, otro para signon, etc). Cada tipo de servidor tiene una relación una a muchos entre su “server daemon” y los trabajos del servidor reales; un “server daemon” tiene potencialmente muchos trabajos servidores asociados.
El subsistema QSYSWRK arranca automáticamente en el IPL, independientemente del valor especificado en el subsistema de control.
Si se utiliza el programa startup por default provisto con el sistema, los subsistemas QSERVER y QSYSWRK arrancan automáticamente en el IPL. El programa de startup del sistema está definido en el valor del sistema QSTRUPPGM, y el valor por default es QSTRUP en QSYS.

Las distintas vistas obtenidas y mostradas desde pantallas de iSeries Navigator en el presente artículo, pueden variar dependiendo de las “Columnas” seleccionadas en la lengüeta “Opciones” de la Barra de Herramientas de iSeries Navigator. Esto permite elegir qué tipo de información visualizar en un momento dado. Cada componente de iSeries Navigator habilita un grupo de Columnas en particular.