Radioclub Castelló Costa de Azahar

Apartado 165, E-12080 Castelló E-Mail: ea5fmc@ure.es



Seccion 2 Temas del Operador del Sistema

Este capítulo explica todo lo necesario para conseguir instalar y ejecutar el PacketCluster. El operador del sistema, dispone de un conjunto de comandos propios, ademas de los del usuario normal, lo que le permite controlar perfectamente el PacketCluster.

El software del PacketCluster permite al sysop poder operar tambien el PacketCluster, como un usuario normal. Esto significa que se pueden introducir nuevos DX, ver los anuncios de los demas, y todas las demas funciones del PacketCluster al mismo tiempo que estan conectandose y usandolo los usuarios normales..El operador del sistema, tiene por supuesto,un control total del PacketCluster local, y puede controlar la actividad en todos los canales, para asegurar que las cosas funcionan correctamente en el NODO del PacketCluster local.

Debido a que el software es capaz de vincular el PacketCluster a una red de multiples NODOS, usted, como operador de sistema, tiene control primario sobre su sistema local. Sin embargo, mediante el uso de los comandos remotos de sysop, usted será capaz ejecutar muchos (pero no todos) comandos de sysop sobre los NODOS conectados a la red. De esta manera, usted tendra algun tipo de control sobre toda la red . A lo largo del resto de este manual, el término "PacketCluster" se usa para designar el el sistema local de PacketCluster, y no la red multi - NODO de PacketCluster excepto en los casos que asi se indique claramente.

Configuración

Usted debe saber que a 1200 baudios , la anchura de banda disponible del canal es relativamente pequeña. Si se generan varios anuncios de DX a la vez, puede suceder que la TNC no sea capaz de mantener el ritmo del sistema. Si usted usa una TNC Kantronics , el control de flujo se gobierna en ambos sentidos tanto por el Pc como por la TNC. El control de flujo en el PacketCluster se realiza por el XON/XOFF o bien por el protocolo del propio hardware del equipo.

Nota: cuando la TNC se satura se para su salida hacia el PC, hasta que la TNC informa que ya esta en condiciones otra vez.para suministrar más información. Con la tarjeta TNC DRSI , las colas de salida se almacenan en los buffers de memoria del PC encolandose hasta que lal TNC esté lista para su transmision. Usted, como sysop, debe mentalizar a los usuarios de que la anchura de banda no es ilimitada, y de como funciona el control del canal, de forma que no se impacienten en exceso cuando vean que la respuesta sus demandas no es inmediata.

La TNC es el medio por el cual los usuarios locales del NODO de PacketCluster reciben toda la informacion que circula por la red de PacketCluster. Este nexo vital es muy dependiente de los parametros de configuracion (Setting de la TNC) la situacion geografica y la inteligente utilizacion del canal por los usuarios del PacketCluster.

Tener en cuenta que una vez que el software de packetCluster ha enviado una informacion a la TNC, es esta y solo esta la que se encarga de su entrega a la estacion remota. La mayoria de los problemas que nos pueda plantear la TNC, pueden resolverse mediante la experimentacion con sus parametros de configuracion, hasta encontrar los adecuados, ya que estos problemas no los puede resolver el software del PacketCluster.

INSTALACION

El Programa del PacketCluster se distribue en dos disketes de 360K, el primer disco contiene el fichero siguiente:

Fichero imagen del PacketCluster PCV50.EXE

Comprimidos dentro de este fichero, estan los siguientes:

Programa del PacketCluster PACKCLUS.EXE

Fichero de Mensajes del Sistema MESSAGES.DAT

Ficheros de Ayuda *.HLP

Fichero de Datos del SYSOP SYSOP.TMP

Fichero de localizacion de Prefijos WPXLOC.RAW

Procesador de localizacion de Prefijos POPULATE.EXE

Procesador de carga de Bases de Datos RELOAD.EXE

Utilidad para Indexacion de Bases de Datos MAKELDX.EXE

Procesador de Descarga de bases de Datos UNLOAD.EXE

Fichero de Configuracion del Sistema CONFIG.SYS

Driver para la TNC DRSI TNCTSR-L EXE

Utilidad de SEtup para la DRSI TAILOR21 EXE

Utilidad para pantalla VGA VGA28.COM

Ejemplo de Ficheros de Oblast OBL.FUL

OBL.LIS

Convertidos de CT a PacketCluster P2C.EXE

Fichero de Direcciones de Boletines BULLETIN.LST

Bandas y Frecuencias BANDS.DAT

Fichero bloqueado con plantillas de Base de Datos FILELOCK.TMP

La utilidad VGA28.COM se incluye, por si usamos un monitor VGA y queremos colocarlo a 28 lineas, ejecutar VGA28 desde DOS antes de arrancar el Cluster.

La utilidad DBSTRIP.EXE, quita cualquier registro borrado de las bases de datos de DX, WWV, WX y Anuncios. Los registros pueden borrarse usando el comando EDIT. La sintaxis es:

DBSTRIP DX DBSTRIP WWV

DBSTRIP WX DBSTRIP ANNOUNCE

Nota: El programa P2C.EXE se incluye como un servicio.Este programa convierte los ficheros DX.DAT a los ficheros PACKCLUS.BIN de forma que puedan leerse desde el programa CT, programa de concursos escrito por K1EA, CT es un programa registrado (1988-1991) por Ken Wolff, K1EA.

El segundo disco, disco de instalación, contiene los ficheros siguientes:

Procedimiento de instalación INSTALL.EXE

Fichero LEAME README

Actualizaciones del Manual MANUAL.UPD

Hacer una copia de los dos discos y guardarla en lugar seguro, antes de iniciar el proceso de instalacion del software del packetCluster


En caso de que no sea una instalacion nueva, o sea que estemos actualizando la version, es muy conveniente antes de empezar hacer una copia de nuestro directorio \PACKLUS y sus subdirectorios asociados. Hechas estas dos cosas, podemos iniciar la INSTALACION:

Paso 1 Asegurarse de tener los suficientes recursos del sistema, en el fichero de configuracion CONFIG.SYS ubicado en el directorio raiz del disco duro (c:\config.sys). Si no existe este fichero (nota:existe siempre) copiarlo desde el disco flexible. Debe contener, al menos las dos lineas siguientes:

FILES=40

BUFFERS=40

Estos valores son el MINIMO, si tenemos unos mayores no modificarlos. Es conveniente hacer una copia de este fichero en el directorio del \PACKLUS despues de acabar el procedimiento de instalacion. A continuacion resetear el PC.

Paso 2 Ponen el disco de instalación en la disketera A e ir a dicho disco mediante el comando:

A: (Enter)

Paso 3 Ejecutar el procedimiento de instalacion del software del PacketClustere introduciendo el comando:

INSTALL (Enter)

Este procedimiento crea los directorios necesarios y copia los ficheros desde el disco flexible hacia los correspondientes subdirectorios en la unidad de disco duro.

Los directorios que se crean son los siguientes:

\PACKLUS Directorio principal

\PACKLUS\MSG Mensajes de Correo

\PACKLUS\FILE Ficheros Normales cargados.

\PACKLUS\BULLETIN Ficheros de Boletin cargados.

\PACKLUS\TEMP Area temporal de carga.

\PACKLUS\ARCHIVE Ficheros

\PACKLUS\HELP Ficheros de Ayuda.

\PACKLUS\DB Ficheros de Base de Datos.

\PACKLUS\CMD Ficheros de Comandos.

\PACKLUS\CONNECTS Ficheros configuracion Conexiones.

\PACKLUS\DISTRO Listas de Distribucion del Correo.

\PACKLUS\USERCMD Ficheros de Comandos de los Usuarios.

\PACKCLUS\UTILS Programas Auxiliares

Si es una instalacion nueva, cuando se complete esto ir al paso 4.

Si el procedimiento de instalacion detecta que ya existe el directorio \PACKLUS, asume que se trata de una ACTUALIZACION de una version anterior y crea los ficheros nuevos en un subdirectorio de trabajo temporal y a continuacion los MUEVE a sus correspondientes subdirectorios de trabajo. Todos los ficheros .EXE reemplazan a sus anteriores versiones, cualquier otros ficheros que hayan podido ser manipulado por el SYSOP (WPCLOC.RAW y.*.HLP) son renombrados con una extension .V4.

El fichero WPXLOC.RAW tiene un formato ,nuevo por lo que, cualquier modificacion que se le haya hecho debe entrarse de nuevo. El fichero WPXLOC.RAW tal y como es ahora es mantenido por NB9C. Las versiones previas de SYSOP.DAT y DOS.BAT no son sobreescritas. Continuar con el Paso 12.

Paso 4 Una vez ejecutado el procedimiento de instalación; El PacketCluster debería existir sobre su disco duro. Puede editar el fichero de datos del operador del sistema (SYSOP.DAT) para su PacketCluster. Este archivo puede contener cualquier operador valido de sistema y/o los comandos generales de usuario, y es ejecutado cada vez que se rearranca el PacketCluster. Pueden añadirse lineas de comentarios, iniciandolas con (!). Usted puede usar este archivo para permitir/inutilizar cierto comandos del PacketCluster , establecer sus comandos particulares de SHOW, predefinir teclas de funcion.propias y establecer áreas específicas de ficheros para sus usuarios.

El archivo que se incluye en los discos del PacketCluster, tiene losl siguientes comandos:

Linea de texto con la Bienvenida al Cluster.

SET/LOGON Bienvenido a mi PacketCluster.

Configuracion de la primera TNC.

SET/TNC1 DRSI 32 1200 / 1200

Contraseña, para los ususrios Privilegiados .(Procurad que sea larga y aleatoria)

SET/PASSWORD MadridCerveza123,URE

Si se desea, se define el comando OBLAST

SET/COMMAND OBLAST OBL.LIS OBL.FUL / OBL.IDX * * *

El indicativo viene incorporado en el programa y por lo tanto, no hay ningun comando que nos permita cambiarlo o introducirlo. Si se actualiza el PacketCluster o bien se cambia de indicativo, hay que ponerse en contacto con Pavillion Software para conseguir una version nueva del software.Se puede, no obstante, agregar una SSID al indicativo del NODO, usando el comando SET/SSID, recordando que para que sea efectivo debe hacerse antes del comando SET/TNC.

Paso 5 Antes de de iniciar el PacketCluster, verificar que la hora del PC es la hora UTC.

Si se usa el adaptador de Packet DRSI, hay que cargar su correspondiente driver,TNCTSR-LEXE. Antes de de cargarlo, asegurarse de que los parámetros definidos en la imagen son correctos para su instalación. Ver la seccion de configuracion de TNC en este capitulo, para mas informacion sobre los parametros. Los parametros del driver pueden modificarse usando la utilidad TAILOR21 con el siguiente formato:

TAILOR21 TNCTSR-L.EXE

Una vez se este de acuerdo con los parametros a cargar en el driver, hay que cargarlo en la memoria ejecutandodesde el DOS el siguiente comando:

TNCTSR-L


Esto carga el driver del DRSI y permite su uso por el software del PacketCluster.

Paso 6 Ahora que ya se han copiado todos los ficheros en el disco duro y editado SYSOP.DAT para reflejar su información particular, estamos listos para comenzar el PacketCluster. Coloque su directorio actual a \ PACKCLUS y ejecutar el programa PacketCluster.

CD \PACKCLUS (Enter)

PACKCLUS(Enter)

Si no se incluye ningun parámetro en la linea de comando del PACKLUS, el software presupone que disponemos de un Monitor monocromo. Si tenemos un monitor de color, el comando anterior se modificaria tal y como se indica:

PACKCLUS COLOR (Enter)

En este punto, veremos como el PacketCluster inicia sus ventanas, seguido por la ejecucion de los los comandos que se encontró en SYSOP.DAT. Cuando esto se completa, aparece el mensaje "Press ENTER to Continue" ("Pulsar ENTER para continuar"). Después de pulsar la tecla ENTER, el PacketCluster está listo para su uso. Tener en cuenta que no se recibirá ninguna indicacion de que el sistema está listo mientras se este usando el terminal de consola. Los usuarios conectados al PacketCluster, por otra parte, reciben una linea de comando cada vez que que el PacketCluster esté listo para aceptar otro comando suyo.

Si usted escribe:

SHOW/USERS

vemos que somos la unica estación conectada al sistema

Paso 7 Los pasos siguientes solo son necesarios si usamos una TNC Kantronics en caso de usar una DRSI ir al paso 12.

Para proceder a la correcta configuracion (Setup) de la TNC conectada al puerto COM1. Uno de los comandos de Sysop permite conectarse directamente a la TNC atraves del puerto, dicho comando se escribe:

TNC

Tras esto, todos los caracteres que escribamos, se remitiran al puerto y desde alli a la TNC. Para volver al PacketCluster, hay que pulsar la tecla F1..

No es objeto de este manual, describir como se conecta la TNC con el PC. Ver el manual de la TNC para estos detalles. Se asume que la TNC esta correctamente conectada al PC y que por medio del Comando anterior TNC ha sido posible configurarla con los parametros adecuados.


Paso 8 Configurar los parametros de la TNC. Ver en este mismo capitulo los parametros adecuados, segun la TNC usada.

Paso 9 Si se usa una TNC Kantronics, se deben almacenar los parametros en la memoria RAM mediante el comando PERM, recordar que dicha memoria se borra al apagar la TNC. El comando es como sigue:

PERM

Paso 10 Para volver al PacketCluster pulsar la tecla F1.

Paso 11 Si disponemos de una segunda TNC, debemos proceder ahora a su configuracion, de la misma forma que hemos hecho con la primera TNC, pero con el siguiente comando:

TNC/2

Paso 12 El programa de PacketCluster esta preparado para su uso.

Variables de Entorno

El sistema operativo del PC (DOS) reserva un area de su memoria para un tipo de variables que se llaman de "Entorno", dichas variables se crean cada vez que rearrancamos el sistema DOS, bien porque encendemos nuestro PC, bien porque pulsamos la tecla Reset o bien porque pulsamos CTRL+ALT+SUP. Dichas variables se definen el el fichero AUTOEXEC.BAT, mediante el comando de DOS "SET" El PacketCluster reconoce varias de estas variables de entorno, tal y como vamos a explicar a continuacion:.

PCMSGEMM El PacketCluster usara la memoria expandida para almacenar mensajes procedentes de MESSAGES:DAT. Esto usara aproximadamente unos 30 Kb adicionales de memoria convencional. Si no queremos que el PacketCluster use la memoria EMM poner la siguiente instruccion, en el autoexec.bat:

SET PCMSGEMM=0

PACKCLUS Si ponemos esta variable de entorno, nos indicara cual es el directorio raiz del software del PacketrCluster. Por tanto si el software del PacketCluster esta en un directorio llamado \PC en vez del \PAKCLUS deberiamos indicarlo mediante la siguiente linea el el autoexec.bat:

SET PACKLUS=PC

PCNOEMS Cuando desde el PacketCluster usamos el comando DOS, el programa vuelca y guarda una gran parte de el mismo en la memoria del PC, para que tengamos mas espacio para usar los comandos del DOS. Por defecto, si dispomenos de un area de memoria EMS, lo hace alli. Sin embargo si no queremos que dicha memoria se use para esto, hay que definir la siguiente variable de entorno:

SET PCNOEMS = 1

PCSAVMEM Cuando desde el PacketCluster usamos el comando DOS, el programa vuelca y guarda gran parte del mismo en la memoria del PC, por defecto se vuelca la cantidad necesaria para dejar libres unos 200 KB de memoria. Si se necesita mas o menos se puede indicar con la variable de entorno PCSAVMEM, en caso de poner 0 toma toda la memoria disponible:

SET PCSAVMEM = 0

Configuracion de las TNC - Serie KPC de Kantronics

El programa del PacketCluster soporta actualmente la TNC KPC-2 y el KPC4 de Kantronics. Pueden conectarse hasta 2 TNC con un numero total de usuarios conectados de 64.

La KPC-2 soporta un maximo de 26 usuarios, mientras que la KPC-4 soporta un maximo de 52 usuarios, 26 por cada port de radio en la TNC.Si conectamos al NODO de PacketCluster dos TNC tipo KPC-4, podemos conseguir un maximo de 64 usuarios conectados al mismo. Por ejemplo: se podrian soportar 26 sobre el puerto 1 de la TNC 1 , 3 sobre el puerto 2 de la TNC1, 20 sobre el puerto 1 de la tnc 2 y 15 sobre el puerto 2 de la TNC2. Puede elregirse cualquier configuracian en base a una adecuada programacion de los valores de los parametros USERS y MAXUSER almacenados en las memorias de las TNC.

Setup

Para configurar las TNC tanto la KPC-2 como la KPC-4 lo primero que hay que hacer es darles tension. Asumiendo que se ha ejecutado el comando del PacketCluster TNC o TNC/2 que nos conecta directamente con los puertos de comunicacion, se podran ver algunos caracteres aleatorios inpresos sobre la pantalla (Si hemos colocado el ABAUD a 0). Esta es parte de la secuencia para la consecucion de que la velocidad de transferencia entre la TNC y el Puerto sea correcta. Si, no obstante hemos colocado antes el ABAUD a una velocidad determinada, y hemos especificado tambien el comando SET/TNCx, veriamos por pantalla las salidas iniciales de la TNC.

Una vez que se ha conseguido el introductor "cmd:", se deberian introducir los siguienter parametros:

AUTOLF ON NEWMODE OFF *

AX25L2V2 ON * PACLEN 255

CHECK 0* PARITY 4

CONMODE CONVERS RELINK OFF

CSTAMP SOBRE RNRTIME 10

ECHO OFF SCREENL 255

ESCAPE OFF SENDPAC $0D

FILTER OFF START $11

FLOW ON STATSHRT OFF

FULLDUP OFF STOP $13

HEADERLN OFF STREAMSW $7C *

LCOK ON STREAMCA OFF

LFADD OFF STREAMDB OFF

MAXUSERS 26 * STREAMEV ON

MONITOR OFF * UNPROTO NONE

MYCALL Su Indicativo USERS 26 *

Los parámetros marcados con un asterisco (*)deben especificarse para ambos puertos si usando la TNC KPC4. Además, el parametro STREAMSW debería colocarse a $7C/$40 (l/@) para el KPC4, valores por defecto. Si usted desea modificar los caracteres de switch, recordar también modificarlos sobre el comando SET/TNC en el fichero SYSOP.DAT.

NOTA: Se recomienda el cambio de los caracteres de switch a algunos no imprimibles (tal como $90 y $91), para que las entradas de usuario no ocasionen un bloqueo en la TNC.

Si usted usa el control de flujo XON / XOFF (vea el comando SET/XON_XOFF), usted debe coloque el parámetro siguiente:

XFLOW ON

Si usted usa un equipo con protocolo de dialogo, se debe colocar el parámetro siguiente:

XFLOW OFF

Configuracion de las TNC - Tarjeta DRSI

El programa del PacketClustera admite el uso del adaptador de TNC DRSI. Esta TNC utiliza memoria del PC para almacenar los paquetes entrantes y salientes, hasta un maximo de 32 usuarios, distribuidos a través de un máximo de cuatro puertos de radio. Nota: A diferencia de los otros tipos de TNC, la placa DRSI no se conecta a un puerto serie, si no al Bus del Ordenador. Esto permite usar los puertos COMM para otros dispositivos. El PacketCluster comunica con la placa DRSI mediante el uso de una programa residente (TSR), dicho programa se suministra con la propia tarjeta.

Setup

La TNC DRSI tiene muy pocos parametros disponibles, el PacketCluster no modifica los parámetros que han sido anterioramente introducidos mediante el programa TNCTSR-L El sysop, puede usar el programa de configuracion TAILOR21 EXE para modificar cualquier parametro del adaptador de Packet. Cuando se recibe la tarjeta, los parametros tienen los siguientes valores por defecto.

Digipeating 0

Keyup P- Umbral de persistencia 64

Keyup tiempo de ranura 10

Link T1 timeout (FRACK) 4

Link Ventana tx (MAXFRAME) 4/4

Link maximo de vinculos 10

Link T2 timeout 100

Link T3 timeout 18000

Keyup demora (DELAY) 40

HDLC Velocidad de transmisión en baudios 2

Multiples Tarjetas:

El PacketCluster, soporta un maximo de cuatro tarjetas DRSI. Este soporte se realiza de dos maneras. La comunicación con la TNC DRSI se realiza por medio de un programa residente (TRS) llamado TNCTRS. El driver de dicho programa puede soportar hasta dos tarjetas DRSI (4 Ports de Radio) con 32 conexiones a traves de los 4 puertos. Se puede instalar tambien, un segundo programa residente que a su vez permite soportar otras dos tarjetas DRSI. Hay varias versiones del programa TNCTSR ; para el PacketCluster, se debe usar la version TNCTSR-L. Este programa se suministra con el paquete de software del PacketCluster. Para instalar este programa, simplemente ejecutar desde el DOS el siguiente comrnando:

TNCTSR-L

La comunicación con la primera tarjeta DRSI es automatica si disponemos de software d adecuado bien de Pavillion bien de DRSI.. Es conveniente, no obstante, usar el programa de utilidad TAYLOR21 para personalizar adecuadamente el programa residente TNCTSR para su PC en cuanto a la direccion de IRQ (Interrupt Request Queue). Las IRQ no deben compartirse con otras tarjetas,deben ser unicas, por tanto hay que encontrar una que este libre para asignarsela. En caso de usar dos tarjetas DRSI con una IRQ comun, debemos especificarlo usando el TAYLOR21. Nota la direccion base de cada tarjeta debe ser unica. Consultar la documentacion de la tarjeta DRSI para mas informacion sobre las IRQ y Direcciones Base.

En caso de usar dos tarjetas DRSI, debemos seguir el procedimiento siguiente:

Copiar TNCTSR-L.EXE a otro archivo (p. ej. TNCTSR2.EXE).

Usando TAILOR21 sobre el archivo nuevo (p. ej. TNCTSR2.EXE), modificar la interrupcion de software a 0xFE, el valor del IRQ a algun otro distinto del utilizado para la primera placa, y una Direccion Base diferente (p. ej. 310). Nota: Los interruptores que hay en la tarjeta DRSI deben colocarse en la IRQ y Direccion Base que pongamos.

Instalar el segundo controlador (Driver) asi como también el primero:


Red Multi NODO

Uno entre los muchos aspectos únicos de PacketCluster es su capacidad para establecer una red de PacketCluster múlti NODOS. Esta se realiza mediante el uso de mensajes protocolares especiales que los NODOS cambian. El protocolo del PacketCluster se inicia con el comando CONNECT. Una vez se establece una conexion, toda la comunicación adicional sobre el canal se soporta mediante mensajes protocolares que soportan las listas de DX, las charlas, las conferencias y otras funciones del PacketCluster.

Un multi-NODO PacketCluster parece ser el mismo para todos los usuarios de la red, sin considerar a qué NODO particular estan conectados. Por ejemplo, si pedimos el comando SHOW/USERS nos mostrara todas las estaciones conectadas a todos los NODOS del Cluster. Igualmente, las funciones de charla (Talk) funcionan igual entre usuarios sobre NODOS diferentes, como cuando dichos usuarios estan sobre el mismo NODO.

Ejemplo

El ejemplo siguiente demuestra como trabaja un multi - NODO de PacketCluster. Suponemos que disponemos de dos NODOS de PacketCluster, de momento no conectados el uno al otro:

NODO-l NODO-2

Usuario-A Usuario-D

Usuario-B Usuario-E

Usuario-C Usuario-F

El operador del sistema del NODO-1 emite el comando CONNECT para establecer un nexo al NODO-2.

CONNECT NODE-2

También suponemos que con anterioridad, el operador del sistema sobre el NODO-2 ha ejecutado el siguiente comando:

SET/NODE NODE-1

Cuando la conexión se detecta en el NODO-2,se busca en el fichero NODE.DAT la dualidad NODE-1 Indicativo. Este dato se ha introducido anteriormente con el comando SET/NODE , para que el NODO-2 comprenda que es una conexión con un NODO remoto de PacketCluster. En este punto, el NODO-2 inicia el siguiente protocolo.

Sobre el NODO-1, apareceran los siguientes mensajes:

Attemting PacketCluster node conection to Node-2

Node Node-2 joining the cluster

Transmitting local configuration information to Node-2

Local initialization complete to Node-2

Adding remote user User-D on Node-2

Adding remote user User-E on Node-2

Adding remote user User-F on Node-2

Initialization sequence complete with Node-2

Sobre el NODO-2, aparecen los siguientes mensajes:

Node Node-1 joining the cluster

Adding remote user User-A on Node-1

Adding remote user User-B on Node-1

Adding remote user User-C on Node-1

Remote initialization with Node-1 completed

Transmiting local configuration information to Node-1

Initialization sequence complete with Node-1.

Tras el fin de estos mensajes protocolares, los dos NODOS del PacketCluster, están listos para el uso.

Para ver una lista de los mensajes protocolares del PacketCluster , leer el APENDICE C.

Operacion Multi-NODO

El sistema de Multi-NODOS del Packet Cluster se apoya en una serie de mensajes protocolares que intercambian entre si los NODOS. Esta seccion detalla, como se inicia el protocolo y que comandos del Operador del Sistema son utiles para controlar dicho protocolo.

Estructura de la Conexion:

La decisión para el inicio del protocolo de conexion la toma el NODO que recibe una peticion de conexion. Específicamente, sobre cada de estas conexiones, el software busca en el fichero de base de datos NODE.DAT para comprobar si la estación remota es un NODO de PacketCluster. Los sysop usan los comandos SET/NODE y SET/NONODE para especificar NODOs remotos en esta base de datos. El comando SHOW/NODE muestra la lista actual de los NODOS remotos de PacketCluster que conoce al NODO local.

Nota: Todos los NODOS en su Cluster deberían almacenarse en esta base de datos, sin considerar si ellos siempre conectan directamente a su NODO. El Software del PacketCluster presupone esto, y si no, algunos comandos no pueden funcionar correctamente.

Inicializacion del Protocolo

La iniciación del protocolo sobre el sistema remoto es aleatoria tras la deteccion de la conexion. Supongamos por ejemplo, que nos hemos conectado al NODO remoto y se "cuelga" el PC. Tras resetear el mismo,hay que reconectarse al NODO remoto. Sobre un reconexion, la TNC remota puede o no puede detectar la conexión, dependiendo de si sobrevivio o no la conexion anterior antes del reseteo del sistema. Si sobrevivio, el sistema remoto no detectará la reconexion, y por lo tanto, no recomenzará automáticamente el protocolo.

En este caso, se puede forzarla a reiniciar el protocolo usando el comando de Sysop INIT. Se puede usar tambien el comando RINIT para simular una entrada PC18. Esto es útil si se esta unido a un canal conectada a otro NODO, y se ha recibido un PC18 antes de la deconexion del canal.

Si se para el NODO de PacketCluster por medio del comando SHUTDOWN sin añadir el cualificador /DISCONNECT el comando RECOVER recupera todas las conexiones. Esto incluye a los usuarios normales y a los conectados a otros NODOS de la red de PacketCluster.

Ficheros SCRIPT para la Conexion

El PacketCluster soporta ficheros de conexion Script, que facilitan la realizacion de conexiones mediante NODOS intermedios o para permitir establecen conexiones desde archivos automáticos de comando. Todos los ficheros de conexion Scriptc deben situarse en el Directorio \PACKCLUS\CONNECT.

Comados SCRIPT

Los comandos siguientes son validos dentro de que un fichero de conexion Script:

INPUT: Simula una entrada por teclado.

Sintaxis: INPUT Texto.

PORT: Indica el Puerto Serie a usar para la conexion.

Sintaxis: PORT n

GETSTREAM: Indica al sistema que use un canal disponible de una TNC.

Sintaxis: GETSTREAM

EXIT Termina el Fichero Script

Sintaxis: EXIT

WAITFOR Esperar un tiempo antes de continuar en el sitio indicado.

Sintaxis: WAITFOR-n-label texto

n es el tiempo de espera y el label es el label para ir despues de transcurrido el tiempo de espera. (ver Ejemplo).)

Las siguientes palabras reservadas, pueden usarse dentro de un archivo de conexion Script:

% ESC Escape (Carácter de cornando para TNC tipo DRSI)

% CTRLC Control/C (Carácter de cornnando para TNC tipo KPC)

% STREAM El canal indicado por un comando previo GETSTREAM.

El PacketCluster busca un fichero de conexion Script cuando se ejecuta un comrnando CONNECT. Por ejemplo, si se entra un CONNECT EA5FMC, PacketCluster busca EA5FMC.CON en el Directorio \PACKCLUS\CONNECT. Si se encuentra, se ejecuta dicho fichero. Tambien puede hacerlo como CONNECT EA5FMC.TST lo que hace que el sistema busque el fichero EA5FMC.TST


Si no se encuentra ningun fichero de conexion Script, se pone en la cola de trabajo de conexiones una peticion de conexion ordinaria.

Ejemplo:

Para ver el uso de un fichero de conexion script, se supone que queremos conectar al NODO AK1A que es accesible a traves del NODO, K1GQ. Lo que se necesita hacer es conectar a K1GQ, y tras esto conectar a AK1A. Sin un fichero de conexion script, usted se uniria al canal, especificando que AK1A debe ser conectado y liberado, ordenando a la TNC que se conecte a K1GQ, se espera la conexión, K1GQ se encarga de conectar a AK1A y una vez conectado, usted liberaría el canal. Presuma que nosotros usamos el puerto 1 de una TNC tipo DRSI. Para hacer esto automáticamente en un archivo de conexion script, usted pondría los comandos siguientes en AKlA.CON:

Cornmandos Explicación

PORT 1 Usar el puerto serie COMM1

GETSTREAM Localizar un canal libre

INPUT ATTACH %STEAM AK1A Unirseal canal; conectar AK1A y liberar.

INPUT %ESCC K1GQ Conecte con K1GQ

WAITFOR-60-ABORT1 CONECTED Esperar mensaje de conexion; vaya a ABORT1 después de de 60 segundos

INPUT AK1A Conecte con AK1A

WAITFOR-60-ABORT2 CONECTED Esperar mensaje de conexion; vaya a ABORT2 después de 60 segundos

INPUT RELEASE Exito; libere el canal

EXIT FIN del Fichero

ABORT1 Etiqueta ABORT1

INPUT RELEARE/ABORT No se conectó a K1GQ; aborte la union al canal.

EXIT FIN del Fichero

ABORT2 Etiqueta ABORT2

INPUT % ESCD Desconexion forzosa desde KlGO

INPUT % ESCD

INPUT RELEASE/ABORT Aborte la union al canal.

EXIT Fin del Fichero

Todas las conexiones se ponen en la cola de trabajo de conexiones (CWQ). Las conexiones se realizan en serie, de uno en uno. Use el Comando SHOW/CWQ para visualizar la cola.

NOTA: Cuando usted esta unido al canal, y ha ordenado a la TNC una conexión con otro usuario, recordar que debe usarse la sintaxis que la TNC espera. Por lo tanto, en el ejemplo de arriba DRSI , para conectar a K1GQ en el el puerto 1, el comando real de la TNC es ESC C K1GQ. Si usted quiere conectarse en el puerto 2, el comando sería ESC C 1: K1GQ. Esto es porque la TNC DRSI numera los puertos 0 y 1 para la primera placa de DRSI , y 2 y 3 para la segunda placa . (Cuandolas ambas placas usan el mismo IRQ).

Protocolo Limitado de Conexion al Nodo

En ciertas configuraciones MULTI-NODO de PacketCluster, usted puede desear de la estructuración de la conexion a un NODO que no lleve todos los mensajes protocolares disponible del PacketCluster. Por ejemplo, considerar dos Clusters distintos que son propiedad de dos clubs de DX. Puede haber poca interacción entre usuarios-a-usuario de los dos Clusters, pero a ellos les gustaría compartir la información de DX y WWV .

Usando los comandos SET/SYMBOL y SET/NODE, podemos estructurar una conexion protocolar limitada entre dos NODOS del PacketCluster. En nuestro ejemplo, NODEl y NODE2 pasan mensajes protocolares que distribuyen informacion con DX y WWV, pero no pasan los mensajes de protocolo que demanden pedidos de base de datos, información de usuario, reenvio del correo, etc.

El uso más común de las conexiones protocolares limitadas es eliminar la información de usuario que se pasa normalmente entre los NODOS. Esto reduce mucho la cantidad de trafico sobre la red, pero el efecto negativo es que usted no "ve" los usuarios que se conectan al Cluster sobre el otro lado de esta conexion protocolar-limitada. En versiones previas de PacketCluster usted podría enviar los mensajes de charla o correo a través de esta conexion única manualmente dirigirendolos con la sintaxis >. Con el advenimiento de la version V5, el PacketCluster mantiene ahora una información para usuarios del "NODO doméstico". La información doméstica del NODO se mantiene en dos lugares: para usuarios del Cluster local, se guarda en la base de datos del operador; para usuarios de los clusters remotos (p. ej., a través de conexiones protocolares limitadas ), se guarda en un fichero ASCII llamado HOMENODE.LST. Esta información es usada por el software al enviar automáticamente mensajes de charla y correo al NODO apropiado, aun cuando el usuario no es "visto" debido a una conexion protocolar limitada. La manera más fácil para conseguir establecer esto es tener NODO en cada lado de la conexion protocolar limitada hecho mediante el comando de sysop CREATE/HOME_NODE. Este comando busca en la base de datos de operador, y cree un archivo ASCII con la información local de NODO para todos los usuarios de su Cluster. Este archivo puede entonces enviarse a través de la conexión protocolar limitada , renombrando a HOMENODE.LST, y distribuyendolo a todos los NODOS desde el Cluster local para permitir este acceso automático a usuarios en el otro Cluster.

Importante:

Los NODOs que están sobre el "otro" lado de una conexión protocolar limitada deberían entrarse en la base de datos del NODO (NODEDAT) con el comando SET/NODE con el texto "(R)" especificado para ese NODO. Esto informa el software que los usuarios sobre este NODO remoto no serán visible. Por ejemplo, si los usuarios de AK1A han sido filtrados por una conexion protocolar limitada, se debería entrar el comando siguiente:

SET/NODE AK1A (R)

Con el advenimiento del software V5 del PacketCluster, los mensajes protocolares PC50 que dan el número total de los usuarios locales conectadosse distribuen ahora desde cada NODO cada 15 minutos. Si el NODO se ha especificado como remoto (con la sintaxis (R)), el conteo de usuario recibido en el mensaje PC50 se agregará al número total de usuarios y podra verse con los comandos SHOW/CLUSTER y SHOW/CONFIGURATION.

Nota: cualquier simbolo que se haya definido para las conexiones protocolares limitadas deber ser modificado incluyendole un "1" para el nuevo mensaje PC50.

Ejemplo:

Para la configuración de este tipo de conexion, habria que mirar primero el APENDICE C de este manual que enumera los diversos mensajes protocolares que usa el PacketCluster, establecer la comunicacion Inter-NODOS. Seleccionandolos y añadiendoles las funciones que se quieran permitir a esta conexion.

Nota: Ciertos protocolos son necesarios para que se complete correctamente la inicializacion sucesiva entre dos NODOS. Los protocolos siguientes deben permitirse sobre ambos, transmision (XMT) y recepcion (RCV):

PC18, PCl9, PC20, PC21, PC22, PC38, PC39

Ahora, continuando con nuestro ejemplo, los protocolos adicionales que deben permitirse son:

PC11 DX Informacion

PC23 WWV Informacion

Y, si usted quiere poder hacer MERGE entre las dos estaciones:

PC25 Demanda de Merge

PC26 Merge de la informacion de DX

PC27 Merge de la informacion de WWV

Habiendo determinado que protocolos deberían permitirse, se puede definir ahora un símbolo, usando el comando SET/SIMBOL, para especificar estos protocolos. Un símbolo es un caracter cualquiera que no sea de los carácteres alfanuméricos (a-z, 0-9) o un guión (-).

Nota: No usan un guión (-) para el símbolo Este se usa para especificar un usuario que se conecta sobre un puerto que tiene inhabilitada la conexion de usuarios. Vea el comando SET/TNC en la seccion de Referencias de los Comandos para mas detalles.

Para nuestro ejemplo, se escoge el $. El formato general del comando SET/SYMBOL es:

SET/SYMBOL modo símbolo datos

donde modo es o XMT (transmision) o RCV (recepcion), el símbolo es el símbolo que usted define, y los datos es una secuencia de 0 (ceros) y l (unos)correspondientes a los mensajes protocolares PC10 a PC50.

El comandos para la configuración del símbolo apropiado, sería:

SET/SYMBOL/RCV $ 01000000111111011100

SET/SYMBOL/XMT $ 01000000111111011100

Ahora, cuando se agrega el NODO remoto a su base de datos de NODOS con el comando SET/NODE , añadir el símbolo al comienzo del Indicativo de llamada:

SET/NODE $Node2 Node2


Notar que este comando no reemplazará una definición previa de NODO. Usted debe primero quitar una definición previa con el comando SET/NONODE y entonces mandar el comando especificado anteriormente.

Cuando se conecta Node2 (AK1A) , el software usa el definicion para el símbolo $, y permite esos únicos protocolos que se definieron para ser enviados y recibidos sobre el enlace.

Como era anterioramente constatable, el uso más común del protocolo limitado es simplemente eliminar la información de conexión de usuario que se pasa entre NODOS, mientras que permite el paso de todo lo demás. Esto puede hacerse definiendo los símbolos siguientes:

SET/SYMBOL/RCV $ 11111100111111111111

SET/SYMBOL/XMT $ 11111100111111111111

Estos comandos definen los símbolos para una conexion con protocolo limitado que quite los mensajes protocolares PC16 y PC17 que que gestionan la conexion y desconexion de usuarios desde el NODO.

Control de la Vida de los Mensajes Protocolares

En la sección previa, Conexiones de Protocolo Limitado entre NODOS, nosotros discutimos la capacidad para parar mensajes protocolares que deberian pasar entre dos NODOS. Sin embargo, considerar el escenario siguiente:

AK1A-----------K1EA---------K1GQ----------NK1K

Escenario

El Cluster está comprendido de los cuatro NODOS arriba indicados. Cada NODO quiere ver los usuarios conectado a los NODOS adyacentes, pero ninguno otro. Por ejemplo, los usuarios de K1EA quieren ver los usuarios sobre AK1A y K1GQ pero no sobre NK1K. Este es, por supuesto, un ejemplo imaginario, pero como los Clusters continúan creciendo en tamaño, no es dificil ver casos como este donde las conexiones protocolaresde entre NODOS no resuelven el problema

Este ejemplo es un problema tal, que necesita una solución diferente. Esta solución se llama "control de vida protocolar del mensaje" y se hace especificando por cuántos NODOS puede circular un mensaje protocolar antes de que muera. Otro limite para el número de NODOS permitido es HOPS (Saltos entre NODOS). Este control de vida se especifica con el comando SET/HOPS.

Ejemplo

Para explicar este concepto, ver nuestro ejemplo en pag. 24 . Recuerde, nosotros queremos que la información sobre los usuarios (mensajes protocolares PC16 y PC17) sea pasada únicamente al NODO (Adyacente) con el que se conecto directamente.

La sintaxis general del comando SET/HOPS:

SET/HOPS contador-de-saltos NODO máscara-protocolo

donde contador-de-saltos es el número de NODOS del PacketCluster que el mensaje protocolar debería cruzar antes de de morir, el NODO es el Indicativo del NODO que se conecta directamente, y mascara-protocolo es una ristra de l (unos) y 0 (ceros) correspondiendo a los mensajes protocolares PC10 a PC51.

Nosotros queremos que los mensajes PC16 y PC17 vayan solo a los NODOS adyacentes, nuestro contador de saltos sera en todos los casos uno. Queremos que desde AK1A, estos mensajes protocolares se envían a K1EA, pero K1EA no los distribuya adicionalmente. Este se establecer sobre AK1A por:

SET/HOPS 1 K1EA 0000001100000000.

Similarmente, en KlEA el fichero SYSOP.DAT , especifica:

SET/HOPS 1 AK1A 000000110000000.

SET/HOPS 1 K1GQ 000000110000000.

y asi sucesivamente.

Detalles Operativos

Cuando un mensaje protocolar se crea sobre un NODO, el PacketCluster lo verifica para ver si hemos especificado un numero determinado de saltos para el NODO de destino. Si es asi, el contador asociado de saltos se pone en el mensaje protocolar. Si no, el contador de saltos por defecto es 99

Cuando un mensaje protocolar se recibe desde un NODO remoto, el contador de saltos en el mensaje se detecta y es decrementa por uno. Si el conteo resultante de salto es cero, el mensaje no es distribuido. De otra manera, el mensaje puede ser distribuido. Sin embargo, antes de de distribuirlo, se verifican los contadores de salto definidos localmente. El contador de saltos que se envía fuera en el mensaje protocolar nuevo es el mínimo entre el contador de saltos entrante y el definido localmente. Esto asegura que cada NODO puede limitar cualquier mensaje que se recibe desde un NODO remoto.

Soporte para Bases de Datos

Otros uno de los aspectos únicos del software del PacketCluster es el soporte a las bases de datos de información creadas por el operador de sistema. Estas bases de datos pueden contener cualquier tipo de información; por ejemplo estas bases de datos pueden incluir Informacion sobre QSL managers, Lista actualizada de Paises, Informacion sobre Clubs, novedades sobre Concursos, etc.

Se accede a las Bases de Datos del PacketCluster mediante el uso del Comando SHOW. Normalmente se usa de dos formas:

SHOW/Cualificador

SHOW/Cualificador Clave

El primer comando comúnmente da una información general sobre la base de datos elegida, mientras el segundo comando muestra información sobre un artículo en particular en esa base de datos. El cualificador se usa para especificar el nombre de la base de datos.

La ubicación real de la base de datos es indiferente al usuario. Todo lo que el usuario sabe es que se ha pedido una informacion al PacketCluster, y esta informacion aparece. El sysop, por supuesto, deber comprender una pizca más sobre como manipular adecuadamente estas bases de datos..

Definicion de Bases de Datos

Para comenzar con, vemos que hay dos comandos SHOW, uno sin un valor clave, y el otro con un valor clave. El PacketCluster intenta acceder a ficheros diferentes, dependiendo de que comando se recibe desde el usuario.

El cualificador sobre el comando SHOW especifica que base de datos que debe ser abierta. Por ejemplo, SHOW/QSL o SHOW/LISTA accede a la base de datos de QSL o bien a la base de datos LISTA. Si no indicamos ninguna CLAVE, el fichero se muestra en su totalidad; si se indica una CLAVE se busca esta en un segundo fichero (Fichero de Indices). Si la clave se encuentra, se nos remite la informacion.

Ejemplo

Veamos en un ejemplo real. Supongamos que tenemos un listado de un radioclub que abarca el Indicativo de los miembros, nombres, direccion, y participacion en recientes concursos. Lo que queremos es que esta base de datos sea accesible a los usuarios, o sea que los usuarios tengan acceso a una lista de los indicativos de los miembros del club, y si alguien desea mas informacion sobre un miembro particular, esta debe tambien estar disponibleque. Usando la funcion SET/COMMAND , se pueden crear los dos comandos siguientes:

SHOW/LISTA

SHOW/LISTA Indicativo

Para hacer esto, se usa el comando siguiente:

SET/COMMAND LISTA LISTA.CAL LISTA.FUL * * *

LISTA.CAL es el fichero que se visualiza si no especificamos ninguna clave; LISTA FUL es el fichero en el que se busca la clave especificada. Los asteriscos pueden ser reemplazados por nombres de ficheros; el primero indica un fichero que se ve antes de de la información pedida (Bienvenida), el segundo indica un fichero que se ve tras la información (Despedida), y el tercero indica un fichero que debe verse en caso de no encontrar la clave indicada (Registro no encontrado). Si ponemos asteriscos indicamos que dichos ficheros no existen.

Ahora supongamos que el Fichero LISTA.FUL es relativamente grande. Para optimizar el acceso a este fichero se deberia utilizar la utilidad MAKEIDX, con el fin de crear un fichero Indice para el mismo:

MAKEIDX LISTA.FUL

La utilidad MAKEIDX necesita saber cuantas entradas debe habilitar para el fichero indice. La regla básica es indicar 3 veces el numero que se tenga en el fichero basico a preveyendo el crecimiento de este.. Por ejemplo, si el fichero LISTA.FUL tiene 500 miembros, habria que indicar a MAKEIDX 1500. Si en un futuro, el fichero LISTA.FUL crece a 750 o 1000, se puede usar nuevamente la utilidad MAKEIDX e indicar un número más grande. Cuando se completa la utilidad MAKEIDX , esta habrá creado el archivo de índice LISTA.IDX se recomienda que todas sus bases de datos sean indexadas usando la utilidad MAKEIDX. Tras finalizar la utilidad MAKEIDX se ven las correspondientes estadisticas; pudemos experimentar con el tamaño de índice para intentar conseguir que la mayoría de registros sean accesibles con un número pequeño de lecturas del fichero.

Si usted desea usar la utilidad MAKEIDX desde dentro de un fichero de comandos que sea llamado automáticamente por PacketCluster (vea Ficheros Automaticos de Comandos, en esta sección), usted podra poner el número esperado de entradas en la línea de comando:

MAKEIDX LISTA.FUL 1500

para incorporar la indexacion a su comando SET/COMMAND habria que poner::

SET/COMMAND LISTA. LISTA.CAL LISTA.FUL/LISTA.IDX * * *

Finalmente, para indicar que este fichero existe sobre ambos NODOS, sobre el NODO local (AK1A) y sobre un NODO remoto en su Cluster (K1EA). Nuevamente, el comando SET/COMMAND ahora sería:

SET/COMMAND LISTA LISTA.CAL LISTA.FUL/LISTA.IDX * * * AK1A K1EA

Nota: En el comando de arriba pueden indicarse hasta un maximo de cinco NODOS, en los que existe esta base de datos.

Ahora veremos como se usan el resto de los ficheros. Supongamos que antes de ver la la información de LISTA, queremos decir algo asi como "Bienvenido, la informacion pedida es:" Esto se llama informacion pre-consulta y suponemos que la hemos puesto en una linea de un fichero llamado LISTA.PRE. Después de la visualizar de la información de LISTA queremos añadir una despedida tal como "Gracias, indicar a AK1A cualquier modificacion" Esta información se llama post-consulta, y suponemos que la hemos puesto en una linea de un fichero llamado LISTA.POS. Finalmente, si la información no es encontrada en la base de datos LISTA, debemos indicarlo con algo asi como "Lo siento dicho Indicativo no pertenece al Radioclub" Y ponemos dicha linea en un fichero llamado LISTA.NF. Incorporemos todos estos ficheros, al comando SET/COMMAND tal como:

SET/COMMAND LISTA LISTA.CAL LISTA.FUL/LISTA.IDX LISTA.PRE LISTA.POS LISTA.NF

dejemos un momento nuestro ejemplo y supongamos que la base de datos LISTA existe solo sobre K1EA, ahora el comando SET/COMMAND seria:

SET/COMMAND LISTA * * * * * K1EA

Debido a que los ficheros de la base de datos son locales, no hay ninguna necesidad de indicar los nombres reales de los ficheros a los que se accede. Solamente se necesita esta informacion cuando la base de datos se ubique sobre el NODO local.

Formato

El formato del fichero que se visualiza, si no indicamos la clave no esta predeterminado. Puede ser cualquier fichero ASCII que deseemos. El Fichero se visualiza en su totalidad.

El formato del segundo fichero, sin embargo, es específico, ya que el software del PacketCluster debe buscar la clave y mostrarla mediante el comando SHOW. En general, el formato es:

Clave

texto

texto

&&

La clave debe estar en una linea. Todo el texto que sigue a la clave puede estar en cualquier formato. Los caracteres de terminacion (&&) deben estar tal y como la clave en una sola linea.

Todos los ficheros asociados con esta base de datos, tales como el. AOK,. NOK, EXC, y los ficheros de plantilla de actualización (descrita más adelante), puede existir en el fichero de base de datos en vez de en ficheros separados. Por ejemplo, usted crearía normalmente un fichero AOK para permitir el acceso a una base de datos de usuarios específicos , usted podría crear en vez un de esto, un registro #AOK en el fichero de base de datos con la misma información. El unico fichero que no puede incluirse en el fichero de base de datos es el fichero índice. Los archivos siguientes de base de datos pueden incluirse en el archivo primario de base de datos:

Fichero Registro

AOK # AOK

NOK # NOK

EXC # EXC

USR # USR

Además, los ficheros que se indican en el comando SET/COMMAND pueden ser tambien registros del fichero de base de datos, siempre que se inicien con una señal de libra (#). En nuestro ejemplo previo, el comando LISTA podría ser:

SET/COMMAND LISTA #CAL LISTA.FUL/LISTA.IDX #PRE #POST #NF

Este comandod indica que el informacion visualizada con el comando SHOW/LISTA, si no se entra ninguna clave está en el registro #CAL. La informacion mostrado antes de la LISTA está en el registro #PRE, después de la LISTA en el registro #POST, y si la clave no se encuentra en el registro #NF.

Control de Acceso

En algunas situaciones usted puede desear restringir el acceso a una base de datos. Los ficheros de restricción son del formato database.EXC. El PacketCluster permite restringir el acceso a los grupos siguientes de usuario:

Palabra Reservada Restringidos

LOCAL A los usuarios Locales

REMOTE A los usuarios Remotos

ALL A TODOS los usuarios

USERS Usuarios especificos

call Usuarios sobre un NODO específico

Por ejemplo, supongamos que deseamos que los usuarios del NODO AK1A no puedan acceder a la base de datos QSL. En el directorio \PACKCLUS\DB , se debería crear un fichero nombrado QSL.EXC. En QSL.EXC, en una de línea debe existir AK1A. En el caso que el acceso se deba restringir tambien a otros nodos, debemos poner tambien sus indicativos en dicho fichero.

El PacketCluster tambien posibilita el acceso a bases de datos individuales de usuarios. Si se puso la palabra reservada USERS en los ficheros .EXC o .INC (o los registros #EXC o #INC ) para una base de datos particular, el sistema verificará el fichero de base de datos .USR (o el registro #USR ) para el Indicativo del usuario solicitante. Si se encuentra, al usuario le es autorizado o negado el acceso a la base de datos dependiendo sobre si era sobre el fichero .INC o .EXC donde se encontro su indicativo.

En una manera similar, se pueden crear ficheros de permiso del formato database .INC. Estos ficheros operan simplemente oponiendose a los ficheros previos .EXC. Las palabras reservadas incluyidas en el fichero .INC indican que grupos de usuarios pueden acceder la base de datos.

Para inutilizar temporalmente una base de datos, usted puede usar el comando SET/OFF. Para volver a activarla, usar SET/ON.

Las bases de datos que empiezan con los caracteres "XX" son inaccesible a todos los usuarios. Típicamente, estos nombres de base de datos son únicos y son usados para bases de datos intermedias que se encadenan a otras bases de datos.

Nota: Tanto los ficheros .EXC como los .INC pueden existir como registros #EXC y #INC en el fichero de base de datos

Bases de Datos FCC

El PacketCluster puede acceder a las bases de datos que contienen las listas de Indicativos de Radioaficionados de la Comision de Comunicaciones Federales.

Bucmaster

El CD-ROM Buckmaster contiene una base de datos de indicativos de radioaficionados editada por Bucmaster-Publishing, esta base de datos puede tambien usarse desde el PacktCluster. Para hacer esto, usa el siguiente comando de definición de base de datos:

SET/COMMAND BUCMASTER * Unidad * * *

donde unidad es la unidad de disco en la que tenemos definido el CD-ROM, (por ejemplo D:) Los dos puntos deben ponerse en el nmotecnico de la unidad. Los asteriscos puede reemplazarse con los ficheros standard pre-visualizacion, post-visualizacion y no encontrado, tal y como se hace en otras bases de datos.

HamBase

La HamBase de J-Com tambien se puede usar. Para realizar esto, usar el comando:

SET/COMMAND HAMBASE *Unidad:\dir * * *

donde Unidad:\Dir es la trayectoria donde tenemos el fichero ( Ejemplo C:\HAMBASE).

Encadenando

Con algunos tipos de bases de datos, usted puede querer "encadenar" bases de datos juntas, para que si una entrada no es encontrada en la base de datos primera, buscarla en la próxima base de datos , y asi sucesivamente. Para hacer esto, usa el comando

SET/COMMAND/CHAIN Base-de-Datos1 Base-de-Datos2...

Un ejemplo de esto con la Base de Datos de QSL Managers de W6GO/K6HHD donde si la información no es encontrada en la base de datos de las QSL, lo busca en la base de datos de QSLNEW. Esto se hace con:

SET/COMMAND/CHAIN QSL QSLNEW

Si no encontramos la informacion en la primera base de datos, la busqueda continua en la segunda base de datos . Si se indica un segundo comando de encadenado para la misma base de datos, por ejemplo,

SET/COMMAND/CHAIN QSL QSLFOUND

esta es conocida como la "cadena encontrada" En este caso, si la información se encuentra en la base de datos QSL, PacketCluster continuará la búsqueda en la base de datos especificada en segundo lugar (en este caso, QSLFOUND).

Actualización

Las bases de datos pueden ser actualizadas por usuarios del PacketCluster usando el comando UPDATE. Este comando esta disponible para todos los usuarios del PacketCluster; por lo tanto, usted, como sysop, puede restringir u otorgar el acceso a la actualización a ciertos usuarios. Más informacion sobre este punto más adelante.

Básicamente, la comando UPDATE especifica que base de datos debe ser actualizada, qué clave debe ser dada de alta o bien modificada, y qué texto ha de ser asociado con esta clave. Vea la descripción de comando UPDATE en la Sección 4 para mas detalles.

El permiso para el acceso a la actualizacion de las bases de datos, lo define el PacketCluster en dos ficheros que pueden o no estar presentes para cada base de datos. Estos son los .AOK y .NOK. Por ejemplo, en nuestra base de datos LISTA del ejemplo anterior, estos ficheros serian LISTA.AOK y LISTA.NOK . Como antes, los ficheros .AOK y .NOK pueden existir como registros en el fichero de la base de datos en vez de en ficheros separados.

El fichero .AOK se usa para especificar que los usuarios pueden actualizar la base de datos particular. El.fichero .NOK se usa para especificar que los usuarios no pueden actualizar la base de datos No tiene sentido definir ambos ficheros; si usted quiere que todos sean capaces de la actualización de la base de datos exceptúando unos pocos usuarios, crear un fichero .NOK con los Indicativos de los usuarios a los que no les esta permitida la actualizacion. Si, por otra parte, usted quiere que solo algunos usuarios actualicen la base de datos, crear un fichero .AOK con sus indicativos. Puede existir un caso especial tal que teniendo una base de datos que tiene el Indicativo del usuario como clave, y queremos permitir que cada usuario ser capaz de la actualización de su propia entrada, pero ningun otro. Esto puede hacerse poniendo la línea:

*OWNCALL*

en el fichero .AOK para esta base de datos. Si se añade cualquier otro indicativo al fichero .AOK, este usuario sera capaz de actualizar cualquier clave.. Los usuarios no especificados en el fichero .AOK solo pueden actualizar su propia entrada.

Las bases de datos pueden radicar en el Cluster sobre varios NODOS. Cuando se realiza una actualización en una base de datos ubicada sobre múltiples NODOS, la actualización se envía a estos otros NODOS. No es necesario, sin embargo, remitir la actualización desde un de NODO a todos los otros; cada vez que una actualización se produce, el PacketCluster busca un fichero .FWD , y si existe graba en el un registro para el NODO desde el que vino la actualización, la actualización se enviará a los otros NODOS enumerados sobre este registro. Por ejemplo, supongamos que tenemos una base de datos LISTA que existe sobre los NODOS AK1A, K1EA, y K1GQ en la configuración siguiente:

AK1A--------------K1EA------------------------K1GQ

En el NODO K1EA, hay un fichero llamado LISTA.FWD en el directorio \PACKCLUS\DB, que contiene la siguiente informacion:

AK1A K1GQ

K1GQ AK1A

Esto significa que cualquier actualizaciones recibidas desde AK1A debe remitirse a K1GQ, y cualquier informacion recibida desde K1GQ debe remitirse a AK1A. Ahora si un usuario hace una actualización sobre AK1A, entonces se remitirá a K1EA debido a la definición de comando:

SET/COMMAND LISTA LISTA.FUL * * * AK1A K1EA

Cuando K1EA lo reciba, entonces se remitirá a K1GQ debido a la entrada en el fichero LISTA FWD. Esta capacidad permite dos cosas:

Evita la restricción de un máximo de cinco NODOS remotos donde existe la base de datos sobre el comando SET/COMMAND , y Permite la propagación de la actualización a lo largo del Cluster en vez de tener un de NODO que la distribuya posiblemente mediante muchos saltos.

Si se ha especificado un fichero .AOK para su base de datos, se puede incluir un mensaje que se mostrará a los usuarios que NO estan incluidos en este fichero (los que estan excluidos de la actualizacion de esta base de datos). Para hacer esto, al final del fichero, incluye cualquier mensaje para comenzar cada mensaje iniciar la linea con un signo de exclamacion (!). Los mensajes pueden ser multilinea.

Como ejemplo, supongamos que tenemos una base de datos solo de lectura, (llamada QSL) y que cualquier actualizacion se debe ponen en otra base de datos (llamada QSLNEW). Se podría hacer esto creando el siguiente archivo QSL.AOK:

! Este fichero, es solo de lectura, no se permite la actualizacion.

! Si quieres dar de alta alguna QSL, usa UPDATE/QSLNEW.

Ahora, si alguien intenta de hacer un UPDATE/QSL recibirá el mensaje especificado.

Transacciones en las bases de datos:

Se puede llevar un REGISTRO de las transacciones. Este fichero guarda los usuarios que han accedido o actualizado la base de datos, a qué NODO se conectaron a, y el valor de la clave especificado. Para usar esta opcion , crear un fichero con extension .REQ en el directorio \PACKCLUS\DB. Ejemplo, si queremos ver todas las transacciones producidas en la base de datos LISTA, usted pondría LISTA.REQ en \PACKCLUS\DB. Los accesos a bases de datos remotas se registran también si el fichero .REQ asociado existe.

Plantillas para la Actualizacion

A fin de hacer los procesos de actualizacion de bases de datos más fáciles de usar, PacketCluster posibilita el uso de plantillas de actualizacion. Para demostrar su uso, suponer que usted acaba de definir la base de datos LISTA de nuestro ejemplo de arriba. Suponemos que YO quiero actualizar mi entrada. Sabiendo el formato de la información en la base de datos, Yo haría lo siguiente:

UPDATE/LISTA

Actualizacion de la Base de Datos LISTA. Entrar la Clave:

EA5AR

Entrar el texto. Acabar con ctrl/Z o /EXIT, Cancelar con ctrl/Y.

Ricardo Montoliu

Apartado 605

12080 Castelló

Indicativos Anteriores: EA3-2061U, EC5AR, EA5BRG

Primera licencia : l972

/EXIT

Actualizacion de la Base de Datos Local, COMPLETA

Cuando no se ha definido ninguna plantilla, PacketCluster contesta con la respuesta standard al comando UPDATE: " Actualizacion de la Base de Datos LISTA. Entrar la clave:" Tras la entrada de la clave nos contesta con "Entrar el texto. Acabar con ctrl/Z o /EXIT, Cancelar con ctrl/Y.", y entonces esperas hasta que la entrada se complete. Existen dos problemas con este método: 1) Los usuarios no saben que tipo de clave se esta pidiendo, y 2) Los usuarios no saben qué información debería entrarse ni como distribuirla. Estos problemas se resuelven definiendo una plantilla para el procedimiento de actualización de la base de datos LISTA.

Veremos los específicos de plantilla de definicion más adelante, pero dvayamos ahora a nuestro ejemplo. Siguiendo, nosotros queremos que la sucesión de actualización sea como:

UPDATE/LISTA

Actualizacion de nuestra LISTA, Entrar el INDICATIVO a Actualizar:

EA5AR

Actualizar EA5AR. Entrar el nombre:

Ricardo Montoliu

Entrar la direccion:

Apartado 605

Entrar codigo postal y Ciudad:

12080 Castelló

Entrar nuestros antiguos indicativos:

EA3-2061U, EC5AR, EA5BRG

Entrar el año de la primera licencia:

1972

Gracias por actualizar su entrada en la base LISTA.

Para hacer esto, nosotros creamos los ficheros de plantilla siguientes. Recuerde todos los ficheros asociados a una base de datos deben estar en el directorio \PACKCLUS \DB. Los ficheros de plantillas deben estar situadas en cada NODO del PacketCluster, aun cuando la base de datos real este sobre un NODO remoto.

Fichero LISTA.T1 Actualizacion de nuestra Lista, Entrar el Indicativo a Actualizar:

Fichero LISTA.T2 Actualizar %KEY. Entrar el Nombre:

Fichero LISTA.T3 Entrar la dirección:

Fichero LISTA.T4 Entrar Codigo Postal y Ciudad:

Fichero LISTA.T5 Entrar nuestros antiguos indicativos:

Fichero LISTA.T6 >Indicativos Anteriores: %INPUT

Entrar el año de la primera licencia:

#

Fichero LISTA.TE >Año de la primera licencia: %INPUT

>Actualizar: %USER %DATE %TIME

Gracias por actualizar su entrada en la base LISTA.

Reglas para las Plantillas

1) Denominacion. Los ficheros de plantilla se nombran como se indica a continuación:

Database.Tn: Para actualizaciones normales. database es el el nombre de base de datos y n es el un numero consecutivo que da el orden en que el fichero es ejecutado. Se admite un maximo de 99 plantillas.

Database.TAn:Para actualizacion por alta. Máximo de 9 plantillas.

Database.TE: Fin de las plantillas para actualizaciones normales

Database.TAE: Fin de las plantillas para actualizaciones por altas.

2) Llamada. Los ficheros de plantilla se llaman después de cada línea de entrada del usuario. Por ejemplo,. T1 se llama después de que los usuarios introduzcan el comando UPDATE,. T2 se llama después de que el usuario introduzca el valor clave y asi sucesivamente. No es necesario tener un archivo de plantilla para cada línea de entrada. Por ejemplo si usted simplemente quiere terminar la entrada de actualización tras 3 líneas de información, usted crearía un unico fichero de plantilla .T4 con un caracter libra (#) en el (1 y 2 son para el comando de actualizacion y el valor clave, 3 es la primera línea de información, 4 es para la segunda línea de información y para especificar con la señal de libra que la próxima línea de entrada es la ultima).

3) Keywords. Los siguiente palabras reservadas y los caracteres tienen significando dentro de los ficheros de plantilla:

%key La clave introducida por el Usuario.

%input La linea de entrada, introducida por el Usuario.

%user Indicativo del Usuario que realiza la actualizacion.

%date Fecha Actual

%time Hora Actual

> En la columna 1, indica que el resto de línea debería ser grabada en el fichero de base de datos. Este comando es optativo; si no se encuentra una línea que empiece con >, la entrada actual del usuario se graba en la base de datos al pie de la letra.


# Indica que la proxima entrada del Usuario es la ultima

Otros Las lineas que no empiezan por un > o # se muestra al usuario, tal cual.

4) Ubicación. Todos los ficheros de plantilla, así como también todos los ficheros relacionados con las bases de datos, creados por el sysop deben estar situados en el directorio\PACKCLUS\DB. Los ficheros WPXLOC.* estan en \PACKCLUS. A partir de la version V5 del PacketCluster , las plantillas pueden incluirse tambien en el fichero de base de datos. En este caso, los registros de plantilla se nombran simplemente como las extensiones de sus ficheros correspondientes, tal como #T1, #TA2, #TE, etc.

AYUDA

Como complemento, recordar que debemos actualizar los archivos de ayuda para reflejar los comandos personalizados del usuario del PacketCluster de . Específicamente, el archivo PC.HLP provee un resumen de todos los comandos, que usted puede modificar para incluir sus comandos nuevos.

También, para proveer información detallada sobre cada comando se acostumbra, a modificar el fichero \PACKCLUS\HELP\LOCAL.HLP para agregar una sección para cada de sus nuevos comandos de base de datos. Por ejemplo, para agregar ayuda para nuestro ejemplo base de datos LISTA, al final del fichero usted agregaría:

SHOW/LISTA

help Texto

help Texto

&&

Ahora cuando un usuario hace un comando HELP SHOW/ LISTA, el texto asociado de ayuda será el que se vea.

Ficheros del Sistema y Correo

Esta sección describe el correo y los ficheros del sistema en el PacketCluster. Los aspectos importantes de estos sistemas incluyen:

Funciones del Correo Normal entre usuarios de un único NODO

Envio automatico de los mensajes de correo a las direcciones donde el NODO se conecta.

Envio automático y actualizaciones de los boletines a todos los NODOS, en el momemto de la actualizacion.

Envio automático de mensajes de correo a sistemas PBBS fuera del Cluster. Envio manual de mensajes individuales de correo y ficheros a un NODO determinado del PacketCluster.

Las secciones siguientes describen de forma detallada los aspectos enumerados arriba.

Correo Normal

Todo los, usuarios sobre un NODO individual de PacketCluster pueden enviar y recibir correo en la manera normal. Los comandos de usuario que posibilitan estas funciones son SEND, READ, REPLY, DELETE, y DIRECTORY. Los mensajes de correo pueden dirigirse a cualquier direccion consistente en una ristra de caracteres. El comando DIRECTORY/BULLETIN muestra una lista de todos los mensajes que se ha dirigida a una dirección de boletín especificada en el archivo BULLETIN.LST.

En BULLETIN.LST se encuentran tres tipos de direcciones boletines locales, boletines para todos los Clusters, y boletines locales de Cluster. Un boletín local es uno que procede del NODO local y que no se remite a ninguno otro NODO. Un boletín para todos los Clusters es uno que se remitira a todos los otros NODOS en el Cluster. Finalmente, un boletín local de Cluster es uno que se remitira a cualquier otro NODO que se especificar en el Fichero LOCALx.LST. Para demostrar el uso de este tipo de boletín, considerar un grupo de NODOS en Chicago, entonces se conectan a un NODO en Indiana. Los usuarios pueden querer enviar un mensaje a todos los usuarios en Chicago, pero no a los usuarios de Indiana. Si cada NODO en Chicago tiene introducidos todos los otros NODOS de Chicago en el fichero LOCAL1.LST (con el comando SET/LOCAL), esto sería posible entonces si la dirección que se establece correctamente en el fichero BULLETIN.LST. Consultar el comando SET/BULLADDR para mas detalles sobre como establecer estas direcciones. Las bases de datos múltiples de Cluster local son soportadas con el SET/LOCAL/n.

Cuando el correo se envía a una estación que esta conectada en ese momento, este usuario recibe un mensaje indicandole que ha recibido nuevo correo. Si la estación no esta conectada, se le informara que tiene correo nuevo en cuanto se vuelva a conectar nuevamente. Si el correo se envía desde un NODO a donde el usuario no se conecta normalmente , el correo se enviará inmediatamente al NODO donde el usuario se conecta normalmente. Después que el mensaje de correo se ha leído por la estación a la que se dirige, aparece un guión (-) al lado del número de mensaje en la salida del comando DIRECTORY. Los mensajes pueden borrarse o por el remitente del mensaje o por el destinatario del mismo. Por supuesto, el operador de sistema puede borrar cualquier mensaje. Los mensajes pueden también borrarse automáticamente después de algúnos días si el comando SET/AUTO_DELETE se ha indicado. Usted puede evitar que se borren los mensajes automaticamente alcabo de varios dias usando el comando SET/NOAUTO_DELETE. Cualquier mensajes al que se le ha puesto un a noauto_delete se ve con un signo mas (+) al lado del al número del mensaje.Si el mensaje ha sido leído por el destinatario y es puesto como noauto_delete, se ve un asterisco (*) al lado del número del mensaje.

Si un boletín de correo de mensaje se borra por el remitente, un mensaje protocolar se envía a lo largo del Cluster para intentar borrar este mensaje. Si un sysop borra un boletín de mensaje, a menos que que el sysop sea el remitente, no se hace una eliminación a lo ancho del Cluster. El comando DELETE/FULL puede usarse en este caso para hacer la eliminación a lo ancho del Cluster. Los mensajes privados pueden enviarse con el comando SEND/PRIVATE. Los mensajes privados no son vistos con el comando DIRECTORY a menos que la estación sea o el remitente o el receptor del mensaje (o el operador de sistema). Recuerde que los mensajes privados pueden leerse todavía por alguien mirando el canal cuando se esta leyendo.

Los mensajes privados, cuando se ven con un comando DIRECTORY se muestran con una "p" al lado del numero del mensaje. Los sysop poder colocar mensajes privados o públicos usando los comandos SET/PRIVATE y SET/NOPRIVATE .

Para contestar a un mensaje, usar el comando REPLY. Si usted quiere borrar el mensaje tras contestarlo, usar el comando REPLY/DELETE.

Autoenvio de Mensajes de Correo

Si un mensaje de correo se envía a un usuario que esta conectado en ese instante a otro NODO en el Cluster, PacketCluster automáticamente manda este mensaje al NODO al que que la estación esta conectada. Tras la operacion de envio, el mensaje se borra en el NODO desde el que el mensaje se envió.

Si el receptor del mensaje de correo no esta conectado actualmente al Cluster, el mensaje de correo se remite a o el NODO sobre que el usuario suele estar conectado, o al NODO especificado por el usuario como su NODO habitual (con el comando SET/HOME).

Solo un unico mensaje se envia a la vez por un NODO del PacketCluster. Por lo tanto, si hay otro mensaje que requiera reenvio, esta operación se pone en una Cola de trabajo. El comando de operador de sistema para ver la Cola de trabajo de reenvios es el SHOW/FWQ. Si, durante la operación de reenvio,se pierde la conexión al NODO remoto, o el NODO remoto se "cuelga", PacketCluster cancela la operación tras aproximadamente, cuatro minutos de no recibir un reconocimiento desde el NODO remoto. Cuando la operación se completa, o se cancela por exceso de tiempo, La entrada actual en el FWQ se quita, y se inicia la próxima operación de reenvio si existe algo aun en FWQ.

Por defecto, el PacketCluster espera cuatro (4) minutos antes de de cancelar la operacion del envio del correo actual . Cualquier operacion de envio que fracase se vuelve a intentar a la hora siguiente. Si cuatro minutos no es tiempo suficiente para su Cluster, el sysop pueden aumentar el el valor del tiempo de retardo con el comando SET/MAXRESPONSE.

En los mensajes de correo se envian varias líneas a la vez. Por defecto son cinco líneas. Si usted quiere aumentar o disminuir este número, usted puede especificar el número con el comando SET/NODE.

El correo de boletín se remite automáticamente a todos los NODOS conectados. Sin embargo, si usted no quiere que suceda esto para un NODO específico, usted puede especificar el texto -BOLLETIN con el comando SET/NODE.

En cierto configuraciones con protocolo-limitado, usted puede querer enviar el correo a un usuario que se conecta a otro Cluster, pero usted no puede ver realmente los usuarios debido a los protocolos siendo devuelto Si el usuario a quien usted quiere enviar correo ha hecho anterioramente un comando SET/HOME, se le puede enviar correo de la forma normal. Sin embargo, si el usuario no ha hecho un comando SET/HOME, se debe envar el correo con el siguiente comando.

SEND Indicativo-del-usuario> Indicativo-del-NODO-remoto


Esto ocasiona que su mensaje de correo se envie al NODO que se indico que está en el Cluster remoto, y una vez se recibe, ese NODO lo manda al receptor real. Vea mas adelante la sección Manual de envio y protocolo limitado para mas detalles. Usted puede verificar si el usuario ha hecho un comando SET/HOME usando el comando SHOW/STATION.

Autoenvio de Ficheros de Boletin

Cuando un usuario envia un fichero boletín al NODO del PacketCluster (con el comando UPLOAD/BOLLETIN ), estos boletines son automaticamente reenviados a todos los demas NODOS que están en el Cluster en el tiempo de actualizacion.

El envio de ficheros funciona de la misma forma que el envio de mensajes de correo. La información necesaria para enviar el fichero se coloca sobre la Cola de trabajo, y se envia cuando llega a ser la entrada actual El envio automatico de ficheros y boletines, sin embargo, solo los envia a los NODOS que estan directamente conectados al NODO local. Una vez el archivo se ha enviado al NODO adyacente del PacketCluster, es trabajo de este NODO mandarlo a los otros NODOS conectados a el.

El sysop poder hacer que un fichero se envie de la misma manera usando el comando FORWARD.

Autoenvio del Correo Externo.

Los mensajes externos de correo se definen como los mensajes destinados a sistemas de PBBS fuera del Cluster. En la orden para que el correo externo se envie, deben configurarse las siguientes cosas.

Permitir el envio del correo externo ejecutando el comando ENABLE/FORWARDING.

Indicar sobre que NODO que tenga la conexión de la PBBS externa, debe configurarse el envio de la base de datos. Esto se hace usando el comando SET/FORWARD. El envio de la información puede organizarse para estaciones individuales y/o puede enviarse asignando una estacion por defecto.

Los usuarios deben especificar la sintaxis apropiada sobre el comando SEND para que que el sistema detecte un mensaje externo de correo. Estos esto se hace con cualquiera de los siguientes formatos del comando SEND:

SEND AK1A

SEND AK1A @ K1EA

SEND AK1A @ K1EA >KlGO

El primer formato supone que se configura el envio de la base de datos desde el NODO local para AK1A. Cuando el mensaje de correo se envía, la base de datos enviada contiene toda la información necesaria sobre como remitir el mensaje a AK1A.

El segundo formato supone que se configura el envio de la base de datos especificamente para AK1A, o que se remita por defecto a la estacion indicada. El @K1EA indica que KlEA es la PBBS a la que debe enviarse el correo.

El tercer formato es una ampliacion para un NODO multiple de PacketCluster. Es muy probable en tal Cluster que solo un NODO tenga una conexión hacia afuera. Por lo tanto, esta sintaxis indica que el mensaje de correo es un mensaje externo (por el @ K1EA), y que debe primero remitirse (usando el envio normal del Cluster) a K1GQ (indicado por el >R1GQ).

El envio de estos mensajes difiere del envio desde el Cluster normal en que la operación de envio ocurre una vez cada hora. La Cola que se usa para retener estas operaciones se llama Cola de trabajo para envio de correo (MAILFWQ), laseEntradas en esta Cola se construyen cuando la operación de envio de correo comienza y puede verse con el comando de operador del sistema SHOW/MAILFWQ. Usted puede quitar la entrada de arriba de la Cola antes de que la operación comienza usando el comando DEQUEUE/MAILFWQ.

Cuando los mensajes se envían usando un signo (@)para indicar que el usuario radica en una BBS externa, o cuando existe una entrada a enviar para el destinatario, el indicativo de la BBS se almacena en la cabecera del archivo de mensajes. Esto evita que la informacion se pierda a causa de los rebotes. Cuando se inicia la operacion de envio del correo, se repasan todos los mensajes activos, si existe alguno para el indicativo de la BBS externa, se da de alta una entrada en la cola MAILFWQ.

Los mensajes externos de correo lo primero que necesitan es que la orden de que el cluster los mande sobre el NODO en el que existe la conexion externa se entre en la cola de trabajo por procesar del correo por enviar estándard de Cluster. Para asegurase de que estas entradas no se pierden, la entrada se escribe también sobre el disco (fichero XFWQ.DAT). Si el NODO del PacktCluster de destino no esta actualmente en el Cluster,.la entrada en la cola de trabajo de correo por enviar se anula. Cuando se produce la conexion de dicho NODO al Cluster, se lee el fichero XFWQ.DAT, las entradas se ponen de nuevo en la Cola de trabajo. Cuando la operación de envio finalmente triunfa, la entrada se quita del fichero del disco.

Si se quiere empezar la operacion del envio del correo remoto, inmediatamente en vez de esperar para que se haga de forma automáticamente a la próxima hora, se puede usar el comando del operador de sistema MAILFORWARD. Este comando es funciona solo sobre los NODOS que tengan conexiones a BBS externas.

Para determinar si una BBS externa puede usarse para aceptar el correo del PacketCluster , debe cumplir con la norma siguiente

La linea de inicio (PROMPT) de la BBS debe terminar con una señal mayor que (>).

El siguiente comando es un comando de envio de correo correcto, sobre un sistema de PBBS.

SP Al-Indicativo < desde-el-Indicativo @ Indicativo-PBBS

Siguiendo el comando previo, la PBBS se da por enterada del tema del correo.

A continuacion de la recepcion del Tema del correoo, la PBBS da paso y entonces recibe el texto del correo.

El texto de correo acaba con un caracter ctr/Z.

Las estaciones externas BBS deben especificarse usando el comando SET/BBS Este comando agrega el indicativo especificado al archivo BBS.LST, que es un archivo ASCII que contiene indicativos de BBS. El comando SET/NOBBS quita uno de estos indicativos de esta base de datos, y el comando SHOW/BBS muestra la base de datos.

Manual de Envios

En las secciones anterioresarriba se ha detallado el envio automatico de mensajes de correo y ficheros de boletines en el PacketCluster. El operador de sistema puede también forzar el envio de mensajes especificos y/o ficheros a cualquier NODO del Cluster. Ver el comando de sysop FORWARD para mas detalles.

Protocolo Limitado y Envio del Correo

En grades redes de PacketCluster se establecen, a veces, conexiones limitadas en el protocolo de conexión para reducir la cantidad de trafico enviados entre los NODOS. Frecuentemente el protocolo único, que es el inhabilitado, es que que apoya la información de usuario. Debido a esto, los usuarios sobre un Cluster no "ven" los usuarios conectados al otro Cluster.

El correo puede enviarse desde un "Cluster" al otro "Cluster" normalmente si el usuario al que el correo se le envia ha hecho un comando SET/HOME_NODE. Este comando envía un mensaje protocolar a todo lo largo del Cluster, informando a cada NODO donde se conecta este usuario normalmente.. Cuando el correo se envía a este usuario, el correo se remite a este NODO, aun cuando el usuario no puede ser "visto." Usted puede determinar si el usuario ha hecho un comando SET/HOME_NODE haciendo un comando SHOW/STATION para ese usuario.

Si, sin embargo, ese usuario no ha hecho un comando SET/HOME_NODE , usted debe forzar el envio de su mensaje al otro Cluster. Esto envio puede hacerse por cualquier usuario del Cluster; no son necesarios los privilegios de sysop.

Supongamos que queremos enviar un mensaje a K1AR quien se conecta a algún NODO en un Cluster a excepción del suyo. También suponemos que K1GQ es un NODO en este Cluster, y que K1AR no ha hecho un comando SET/HOME_NODE. Para hacer esto, usted solamente tiene que enviar el mensaje con el comando siguiente

SEND K1AR > KlGO

Esto ocasiona que su mensaje sea enviado a K1GQ, y como K1AR y K1GQ están en el mismo Cluster, el software entonces entrega el mensaje a K1AR.

Plantillas de Correo

Vamos a ver ahora la forma de crear las plantillas que pueden usarse para el envio de mensajes de correo. Esto es útil especialmente en los envios de emergencias u otro trafico de mensajes donde el mensaje debería estar dispuesto en un formato fijo.

Los archivos de plantilla de correo son muy parecido a los que se crearon para las actualizaciones de base de datos. Los archivos de plantilla pueden tener virtualmente cualquier nombre, pero debe tener la extensión de fichero .T1,.T2, y asi sucesivamente.Las plantillas de correo deben ponerse en el directorio \PACKCLUS.

Los ficheros de plantilla de correo pueden usar las mismas palabras reservadas que en las plantillas de actualización y también reconocen ademas nuevas palabras reservadas:

%ADRESS Reemplazada por el texto de la dirección

%SUBJECT Reemplazada por el texto del tema

%MSGNUM Reemplazada por el número de mensaje

@PRIVATE Especifica un mensaje privado

@NOPRIVATE Especifica un mensaje público

@RR Especifica que se pide un acuse de recibo.

@SETADDRESS Sobreescribe la direccion del usuario especificado

@SETSUBJECT Sobreescribe el tema del usuario especificado.

@SETBBS Especifica la direccion de una BBS que no es del PacketCluster.

@SETGATEWAY Especifica al NODO al que debe enviarse el mensaje

Nota: Las palabras reservadas empiezan por un caracter (%) y pueden usarse en cualquier lugar dentro de una linea del fichero de plantilla, y son reemplazados por su informacion real. Por otra parte, las palabras reservadas que empiezan con una en señal (@) dan al mensaje unas caracteristicas determinadas y deben estar al inicio de una línea nueva.

Para demostrar el uso de plantilla de correo, considerar el siguiente ejemplo. Suponga usted tiene una aplicación donde los mensajes generales están para ser enviados, y usted quiere que cada mensaje tenga el formato siguiente:

TO: adress

From: sender

Date: date

Time: time

Subject Subject text

Message:

texto del mensaje

.

Message sent from PacketCluster node: call

Originating message #msgnum

Ademas, los mensajes deberían ser privados y nosotros queremos ser notificados cuando el mensaje se ha leído (acuse de recibo). En este caso usted quiere que el usuario use el comando SEND/GENMSG para envíar el mensaje. Tambiens, suponemos que el usuario no sabe que los mensajes deberían ser envíados a K1GQ que esta conectado al NODO AK1A en un Cluster remoto. El protocolo de usuario va desde su Cluster al Cluster remoto.

Para realizar esto, los siguiente ficheros de plantilla de correo deberían establecerse en el directorio \PACKCLUS.

Fichero GENMSG.T1: Sending general message. Press Enter to continue.

Esto se enviar al usuario. Note que no se envia ninguna dirección para cuando el remitente no sepa donde para enviarlo.

Fichero GENMSG.T2:Entrar el nombre de la persona a la que se envia el mensaje:

Esto se enviar al usuario. Esta entrada supone el SUBGECT

Fichero GENMSG.T3:@PRIVATE Especifica mensaje privado

@RR Especifica con acuse de recibo.

@SETADDRESS K1GQ Colocar la dirección de destino

@SETGATEWAY AK1A Colocar el NODO para el envio al Cluster remoto.

Entrar el texto del mensaje.

Acabar con ctrl/Z o /EXIT sobre una linea nueva., anula con ctrl / Y.

Estas líneas se muestran al usuario

Fichero GENMSG.T4:> To: %ADRESS

>From: %USER

>Date: %DATE

>Time: %TIME

>

Subject: %SUBGECT

>

>Message:

>%INPUT

escribe toda el texto del mensaje. Notese que cuando explícitamente se escribe la información con el >(palabra- reservada), usted debe incluir palabra reservada >%INPUT para tener la linea de entrada actual incluida en el mensaje.

Fichero GENMSG.TE: Gracias para enviar el mensaje.

Esta línea se muestra al usuario

> Message send from PacketCluster node: %NODE

>Originating message #%MSGNUM

Estas lineas se escriben en el mensaje.

Reglas para las Plantillas de Correo

1) Nombres:. Los archivos de plantilla de correo se nombran como se indica a continuación:

qual.Tn Para cada linea de entrada del correo

qual.TE Fin de la plantilla de correo.

donde "qual" es el cualificador para el vcomando SEND que usted debe especifique para invocar las plantillas.

2) Llamada.:Los ficheros de plantilla de correo se llaman con anterioridad a cada operación de correo. Referente al orden en que se llama a las plantillas, la plantilla primera fichero (.T1) debe existir en el directorio \PACKCLUS. El fichero de plantilla primero se llama en el instante cuando el correo normal pediria al el usuario la dirección. La próxima plantilla fichero (.T2) se llama para en la entrada para indicar el tema. Las plantillas subsiguientes (.T3, T6, etc.) se llaman con anterioridad a las lineas asociadas de la entrada del texto por el usuario. No es necesaria una plantilla para cada una de las entradas. Por ejemplo, usted puede tener. T1,.T2,.T3, y.. T1 para entrar la dirección,. T2 para entrar el tema, y .T3 para entrar el texto del mensaje, y .T8 fuerza el fin del mensaje tras 5 líneas de texto.

3) Ubicación: Todos los ficheros de plantilla de correo deben ponerse en el directorio; \PACKCLUS.

4) Notas adicionales: Todas las peticiones de entrada usadas deben indicarse en ficheros de plantilla. No hay peticiones de entrada por defecto.

El mensaje no es creado realmente hasta que se llama a la plantilla 4 (.T4). Por lo tanto, cualquier intento de escribir informacion en el mensaje (>) anterior a la plantilla 4 fracasara.

La sobreescritura de la direccion de un usuario-dado y/o el tema debe hacerse en la plantilla 3 (.T3).

Si no existe una plantilla asociada para la linea de entrada del usuario, la línea de entrada se escribe en el mensaje de correo al pie de la letra.

La plantilla de fin (.TE) se llama cuando el usuario introduce un caracter ctr/Z, o una linea nueva empieza por /EXIT, o después de que una plantilla previa ha especificado que la proxima entrada sera la ultima con una palabra reservada signo de libra (#).

Consolas Locales

PacketCluster permite dos consolas adicionales. Este aspecto es útil para los propósitos de concurso cuando usted necesita que dos o más posiciones de operacions tengan acceso al sistema sin tener que usar una radio y una TNC para conectarse. Una consola local puede también usarse para dar acceso al NODO por medio de un modem.

Los comandos ENABLE/CONSOLE2 y ENABLE/CONSOLE3 permiten el uso de las consolas locales adicionales. El sistema o el terminal actuando como una consola debe ser conectado a un NODO en un puerto COMM del ordenador. Similarmente, si un modem se conecta a un puerto COMM usted puede conectar con modem y se conecta como una consola local. Bonita manera de conseguir DX en el trabajo! Esta es también la manera recomendada de usar los programas KlEA y CT durante un concurso en el NODO QTH.

Fichero de Mensajes del Sistema

El archivo de mensaje de sistema, MESSAGES.DAT, contiene el texto para la mayoría de los mensajes mostrados por el software del PacketCluster. Los mensajes se cargan en la memoria en el inicio del PacketCluster. El tener los mensajes en ficheros de datos tiene dos ventajas: 1) Reduce el fichero del programa PacketCluster, y 2) permite al sysop la modificación y/o traducción de los mensajes.

Deberemos tener cuidadado sobre un aspecto importante de este fichero: Muchos de los mensajes contienen texto y tal y como %s, %i, %0f, etc. Estos simbolos representan valores que el PacketCluster introduce automaticamente en el mensaje. Estos simbolos pueden moverse dentro del mensaje, pero deben permanecer en el mismo orden, y los mismos símbolos deben permanecer en el mensaje.

Por ejemplo, el mensaje:

Attached to stream %s of TNC%i........

puede expresarse de otra manera, tal como:

Conectado al canal %s para el rendimiento explícito sobre la TNC% i...

pero no deber ser remodelado para decir:

Attaced to TNC%i, stream %s

porque los campos se han reordenado.

La reordenación o eliminacion de estos símbolos puede ocasionar resultados impredecibles en el software del PacKetCluster

Ficheros Opcionales de Datos

Hay el varios ficheros de datos que pueden crearse por el sysop para el uso con el software del PacketCluster. Estos ficheros de datos no deberían confundirse con las diversas bases de datos que pueden también ser creadas por el sysop. Esta sección describe cada de los archivos optativos de datos.

ALIAS.AOK: Este fichero de datos es una lista de Indicativos que se permiten uso del comando SET/ALIAS aun cuando la función de alias este anulada (DISABLE/USER_ALIAS).

ALLOWED.LST: Este fichero de datos es una lista de Indicativos a los que tenemos permitida la conexion a nuestro NODO. Este fichero se ignora a menos que este habilitado que el modo permitido de usuario. Los comandos SET/ALLOWED, SET/NOALLOWED, y SHOW/ALLOWED se usan para el mantenimiento de este fichero. Nota: Los SSIDS se ignoran en este archivo.

ANNOK.LST: Este fichero de datos es una lista de usuarios a quienes no esta permitido que use el comando ANNOUNCE. Si el comando ANNOUNCE es entrado en por cualquier de estos usuarios, un mensaje de error (el mensaje número 283 en MESSAGES.DAT) se muestren al usuario. Los comandos SET/ANNOK, SET/NOANNOK, y SHOW/ANNOK operan sobre este fichero. Nota: Los SSIDS se ignoran en este archivo.

BADDX.LST: Este Fichero de datos contiene una lista de indicativos de estaciones de DX erroneas, piratas, etc..que no deben distribuirse a lo largo del Cluster. Por ejemplo en un Concurso no debe llamarse a ZA1ZA, FO0L, EA0KK etc. Cuando se produce un anuncio de DX con un Indicativo contenido en este fichero el anuncio se remite al usuario que lo ha puesto, pero no se distribuye a ningun otro usuario ni se incorpora a la base de datos de DX.. Los comandos SET/BADDX, SET/NOBADDX, y SHOW/BADDX operan sobre este fichero.

BULLETIN.LST: Este fichero de datos tiene una lista de las direcciones de correo a la que deben remitirse el correo de los boletines. El PacketCluster no tiene ninguna direccion por defecto como direccion para el correo de los boletines. A fin de mantener compatibilidad con versiones anteriores de PacketCluster, BULLETIN.LST debería tener todas las direcciónes.

El formato general de este fichero es:

Direccion Comentarios

donde dirección es la direccion a la que hay que dirigir el correo y los comentarios especifican para que se usa dicha dirección de boletín, y también si la dirección es local o es de un Cluster-ampliado. Si la palabra primera del campo de comentarios es LOCAL, la dirección es para boletines locales; el correo enviado a esta dirección no se distribuirá en el Cluster-ampliado pero mostrará sobre el NODO local cuando se haga un comando DIRECTORY/BULLETIN. Si la primera palabra del campo de comentarios es LOCAL_CLUSTER, la dirección es para los boletines locales de Cluster. Estos boletines se remiten únicamente a los NODOS enumerados en el fichero LOCAL.LST.

Los mensajes enviados a direcciones especificados en BULLETIN.LST con cualquier cosa a excepción de LOCAL y LOCAL_CLUSTER como la palabra primera en el campo de comentarios se distribuen a lo largo del Cluster. Por ejemplo, usted desea de agregar las direcciones de los boletínes.TEST y AMSAT. Los comandos SET/BULLADDR, SET/NOBULLADDR, y SHOW/BULLADDR mantiene este fichero.

distro.LST: Estos ficheros tienen las listas de distribucion para los mensajes de correo. Usted puede usar el comando SET/DISTRO para hacer el fichero. Para quitar un Indicativo de la lista de distribución , se usa el comando SET/NODISTRO, y para ver la lista se usa SHOW/DISTRO. Por ejemplo, suponemos que deseamos crear una lista de distribucion de correo para el sysop de cada NODO en nuestro Cluster, esto se puede hacer de la siguiente manera:

1.) Cree una lista de distribucion con el comando SET/DISTRO:

SET/DISTRO SYSOP K1EA

SET/DISTRO SYSOP K1KG

2.-)Envíe correo a los sysop. El software busca en SYSOP.LST y si lo encuentra envia una copia del carreo a cada uno de los usuarios (SYSOP) del fichero.

DXNOK.LST: Este fichero de datos, es una lista de usuarios a quienes no se les permite el uso del comando DX. Si uno de estos usuarios introduce el comando DX, le aparece un mensaje de error (el Mensaje número 286 en messages.dat). Los comando SET/DXNOK, SET/NODXNOK, y SHOW/DXNOK mantienen este archivo. Nota: Las SSID, se ignoran en este archivo.

EXCLUDE.LST: Este fichero de datos es una lista de usuarios a quienes debe excluirse totalmente del PacketCluster. Esta función es util si un operador de concurso en categoria de operador-único desea introducir los multiplicadores que oye en el PacketCluster, pero a la vez no quiere recibir ningun anuncio pues esto anularía su condición operador-unico. En la versión previa de Packetcluster, las lista de exclusión de usuarios se compartian a lo largo del Cluster; con V4.0, solo es una funcion local. Los comandos SET/EXCLUDE SET/NOEXCLUDE, y el SHOW/EXCLUDE mantiene este archivo. Nota: Las SSID, se ignoran en este archivo.

HOMENODE.LST: Este fichero de datos contiene la información del NODO local para usuarios que estan al otro lado de las conexiones con protocolos limitados. Cuando un usuario hace un comando SET/HOME_NODE, no es visible en el Cluster local (debido al protocolo limitado de conexion al NODO), la información se añade a este fichero. Este fichero es un fichero ASCII que puede modificarse con un editor normal. La Información puede también añadirse al archivo local por el sysop con los comando SET/HOME_NODE/USER=syntax. Un fichero particular de NODO puede crearse para el uso por el Cluster remoto con el comando CRETE/HOME_NODE.

LOCALX.LST: Este fichero de datos se usa para definir qué NODOS comprenden los "Clusters locales" . Se usan conjuntamente con el fichero BULLETIN.LST que tiene las direcciones de envio de los boletines y se usa para mandar solo a los nodos del Cluster local. Los comandos SET/LOCAL/n, SET/NOLOCAL/n, y SHOW/LOCAL/n mantiene estos archivos.

LOCKOUT.LST: Este fichero de datos tiene una lista de usuarios a quienes no debe permitirse que conecten al NODO PacketCluster. Si el software detecta una conexión desde una de la estación especificada, desconecta automáticamente la estación sin ningúna la notificación. Los comandos SET/LOCKOUT, SET/NOLOCKOUT, y SHOW/LOCKOUT operan sobre este fichero. Nota: Las SSID, se ignoran en este archivo.

NORECOVR.LST: Este fichero de datos es una lista de Indicativos que debe ignorarse durante la recuperacion de la reconexion automatica del sistema. Cada dos minutos, si esta activado, el sistema averigua que estaciones estan conectadas y lo refleja en la base de datos interna. Si usted conecta a una estación mediante un NODO intermedio,

el Indicativo que la TNC muestra está es el de ese NODO, no el de la estación real que se conecto al NODO Usted debería poner NODOS intermedios en este archivo para que el sistema erroneamente no los reconecte automaticamente. Si usted desea de ser capaz de recuperar los usuarios que se conectan en esta manera, usted los debería poner en la base de datos del NODO con un guion delante de su indicativo.(SET/NODE -AK1 MASS).

REGISTER.INF: Este fichero de texto, esta en el directorio /PACKCLUS , se muestra cuando conecta a cualquier usuario no registrado (si la función de inscripción se ha permitida).

REGISTER.LST: Este fichero de datos contiene la lista de estaciones que se han registrada para usar el PacketCluster. A este archivo solo se accede si la función de inscripción se ha habilitado con el comando ENABLE/REGISTER. Las Indicativos pueden añadirse o quitarse de esta base de datos con los comandos SET/REGISTER y SET/NOREGISTER, y pueden verse con que el comando SHOW/REGISTER.

REMSYSOP.LST: Este fichero de datos contiene una lista de estaciones que tienen sysop remoto. Cuando una de estas estaciones se conecta a su NODO, es automáticamente dotada de privilegiados, sin tener que para hacer un comando SET/PRIVILEGE. Los comandos SET/SYSOP, SET/NOSYSOP, y SHOW/SYSOP operan sobre este archivo. Nota: Las SSIDS se ignoran en este archivo.

Ventanas del Operador del Sistema

Muchas de las visualizaciones pedidas por el operador de sistema se muestran en ventanas mediante movimientos usando las teclas de cursor por el sysop. Esta es una facilidad para permitirr la lectura conveniente de mensajes, ficheros, y otras visualizaciones que normalmente no serían capaces de mostrarse sobre una pantalla.

El sysop puede moverse arriba , abajo, a izquierda y derechaEl movimiento a izquierda y derecha permiten ver lineas de mas de los 78 caracteres de longitud sin tener que ver las lineas a trozos en la linea siguiente de la ventana. El troceado de líneas puede permitirse en una ventana usando la tecla alt-V.

La salida de la ventana se realiza pulsando cualquier tecla a excepción de las las teclas de movimiento del cursor.

Teclas de Cursor

Se han definido las teclas de movimiento del cursor y sus funciones tal y como se indica a continuación:

UpArrow o Flecha Arriba Una linea arriba.

DnArrow o Flecha Abajo Una linea abajo.

LtArrow o Flecha Izq. Un caracter adelante.

RtArrow o Flecha Der Un caracter atras.

Home o Inicio Ir al principio del fichero.

End o Fin Ir al final del fichero.

PgUp o Av.Pag Una pagina adelante.

PgDn o Re.Pag Una pagina atras.

ctl-Arrow, ctrl-flecha Mueve 60 caracteres en la dirección de laflecha

alt-V Cambia la linea a modo resaltado..

Entradas de Simuladas al Canal

El PacketCluster da al operador del sistema la capacidad de simular entradas al canal del usuario. Esto puede ser conveniente cuando estamos ayudando a un usuario que tiene problemas, o para cualquier otro tipo de pruebas. La versión previa del software era diferente ,un comando específico, INPUT, esta disponible ahora para esta función.

Por ejemplo, suponga que quieres poner un usuario en el canal E en modo de Conferencia, Hacemos esto ejecutando el comando siguiente:

INPUT E CONFERENCE

Ver la documentación sobre el comando INPUT para mas detalles. Los identificadores del canal se detallan en la próxima sección, Salida explícita por el Canal.

Salida explicita por el Canal

En ciertas situaciones , es beneficioso para el operador del sistema se capaz de dirigir una serie de comandos o texto a un canal especifico de una TNC. Esto puede hacerse usando el comando del operador del sistema ATTACH. Desde esta función es relacionado con la entrada simulada de un usuario, la explicación se ha incluida en esta seccion así como también una descripciónre resumida en la Sección 3.

El formato del comando ATTACH es

ATTACH canal Indicativo

donde canal es la letra que identifica al canal. A continuacion los identificadore de canal.

Identificadores para los Canales:

Tipo de TNC Num. de TNC Cualificador del Comando Idenentificador del Canal

KPC-2 TNC1 ninguno, o /1 A-Z

KPC-2 TNC2 /2 A-Z

KPC-4 TNC1 ninguno, o /1 A-Z, a-z

KPC-4 TNC2 /2 A-Z, a-z

DRSI TNC1 ninguno, o /1 1-32

DRSI TNC2 /2 1-32

El parámetro optativo, indicativo, se explica más adelante.

Una vez se ha entrado dicho comando, toda entrada adicional del operador de sistema se dirijira a dicho canal. La entrada puede incluir un ctrl/C para poner la TNC en modo de comando (para TNCS KPC), y un carácter ESC para indicar modo comando (para TNCS DRSI), o texto normal para la salida. Note que si usted puso la TNC en el modo comando, el otro canal puede ponerse en modo conversacion, un comando asi debería usarse con mucho cuidado. Toda la salida desde este canal se muestra al operador de sistema, pero es ignorada por el software del PacketCluster. Para abandonare este modo, usted debe entrar el comando RELEASE, o pulsar la tecla de funcion F1.

El comando ATTACH puede usarse para facilitar el establecimiento de NETROM o una conexion Kantronics NODO-KA. Normalmente, a fin de establecer este tipo de conexión, usted tendría que ir al modo de TNC usando los comandos de TNC, estableciendo la conexión, y entonces simular una conexión sobre el canal para conseguir que se inicie el protocolo del PacketCluster. Con el comando ATTACH, se puede hacer toda la estructuración necesaria sin ir al modo TNC ( posiblemente perdiendo algúna entrada del usuario mientras se esta en ese modo). Es esta situación es donde es util el parametro optativo Indicativo del comando ATTACH. Si usted especifica un Indicativo, por ejemplo:

ATTACH A K1AR

cuando usted saledel modo ATTACH por haber hecho un comando RELEASE, o haber pulsado la tecla F1, el software del PacketCluster automáticamente simula una conexión con K1AR. Si usted quiere abortar esta operación, debido a que usted no podría establecer la conexión, o por cualquier otra razón, introduciendo un caracter ctrl/Y o el comando RELEASE/ABORT termina la operación de ATTACH sin conectar a la estación indicada.

Con PacketCluster V4.0 y posteriores versiones, el procedimiento de arriba pueden hacerse con un fichero script de conexion. Vea la sección Ficheros script de conexion, en este mismo capitulo.

Informacion SSID

SSIDS son los números que se añaden a veces a los Indicativos de estaciones de radio de packet. Típicamente, estos se usan principalmente para producir un único Indicativo por alguna razón. También, el NODO-KA y los NODOS NETROM cambian estos números cuando una estación conecta a traves de ellos.

El PacketCluster ignora la mayoría de los SSIDS, a menos que se necesite uno para hacer la estación única. Por ejemplo, si una estación conecta por medio de un digipeater, el Indicativo que la TNC realmente detecta es AKlA-15. PacketCluster quita este -15 para todos los intentos y propósitos, la estación conectó sin un SSID.

Si, sin embargo, sucede que una estación se conecta a un NODO en un Cluster, y entonces conecta a otro sin primero desconectarse del primer NODO, el Indicativo visto en PacketCluster será el primero solo, comenzando en 1. Así, si AK1A se conecta al segundo NODO en el mismo Cluster, esa encarnación será AKlA-1. Si se hace una conexión a un tercer NODO, ese usuario será AK1A-2, y asi sucesivamente.


Note que el PacketCluster ignora la mayoria de SSIDs. A las estaciones que usan un SSID de -6 , -7, -8 o -9 no se les quitara el SSID. Hay algunas veces que quremos que el SSID permanezca; entonces colocar estos numeros, para que suceda asi..

El sistema de correo también ignora todos los SSIDS. Por lo tanto, AK1A es al igual que cualquier otra encarnación de AKlA-x, y tiene acceso a todo el correo y puede borrarlo, sin considerar a quien se envió

Si, por alguna razón, usted quiere agregar un SSID al indicativo del NODO, usar el comando SET/SSID.

Ficheros de Comandos Automaticos

PacketCluster permite ejecutar una serie de ficheros horarios, diarior o ficheros de comandos repetitivos. Los ficheros de comandos pueden ejecutarse tambien bajo demanda. Los ficheros de comandos, son sencillamente ficheros de texto con comandos validos para el PacketCluster dentro de el. Los Ficheros deben ubicarse en el directorio \PACKCLUS\CMD, y se nombrar como se indica a continuación -:

HOURLY.CMD Comandos Horarios

DA1LY.CMD Comandos Diarios

WEILLY.CMD Comandos Semanales

MONELY.CMD Comandos Mensuales

xx.CMD Comandos horarios especificos (xx=00-23)

REPEAT.CMD Comandos Repetitivos

REPEAT2.CMD Comandos Repetitivos

REPEAT3.CMD Comandos Repetitivos

REPEAT4.CMD Comandos Repetitivos

@filename Ejecutables bajo demanda

El fichero de comandos horario, si existe, se ejecuta cada hora. El fichero diario de comandos sea ejecuta tambien en una hora, pero la hora puede ser especificada usando el comando SET/AUTO_HOUR. El fichero de comandos semanal se ejecuta el Lunes en la hora indicada con un comando SET/AUTO_HOUR. Similarmente, el que fichero de comandos mensual se ejecuta el dia 1 del mes en la hora indicada en AUTO_HOUR. Los ficheros de comandos repetitivos, REPEAT.CMD, RFPEAT2.CMD, REPEAT3.CMD, y REPEAT4.CMD, se ejecutan cada tantos minutos, que se indican con el comando SET/REPEAT. Cualquier otro fichero de comandos puede ejecutarse en cualquier momento usando el comando @filename (por ejemplo, @CONNECTS.CMD).

Pueden añadirse líneas de comentario en estos ficheros de comandos iniciando la linea con un signo de exclamacion. (!).

Teclas para el Operador del Sistema

Para hacer la vida del operador de sistema más fácil, se han definido varias combinaciones de ALT-Teclas, para mostrar diversa informacion en el PacketCluster. Estas teclas se definen en el software, y no pueden modificarse. Las teclas que se han definida son:

ALT-1 SHOW/TNC_STA

ALT-2 SHOW/TNC_STA2

ALT-3 SHOW/TNC_CONNECTIONS/1

ALT-4 SHOW/ TNC_CONNECTIONS/2

ALT-A SHOW/CLUSTER

ALT-B ENABLE/BELL, DISABLE/BELL

ALT-C SHOW/CONFIGURATION

ALT-D SHOW/DX

ALT-F SHOW/FUNCTION_KEYS

ALT-G SHOW/CONFIGURATION/NODES

ALT-H SET/HERE, SET/NOHERE

ALT-I SHOW/TNC_MONITOR

ALT-J SHOW/LOCALNODES

ALT-L SHOW/LOG

ALT-M ENABLE/MONITOR, DISABLE/MONITOR

ALT-N SHOW/NODE

ALT-P SHOW/PARAMS

ALT-R SHOW/REMOTES

ALT-S ENABLE/SCREEN_MODE, DISABLE/SCREEN_MODE

ALT-T SHOW/TIME

ALT-U SHOW/USERS

ALT-W SHOW/WWV

ALT-Y SHOW/ANNOUNCES

ALT-X SWITCH

ALT-Z DIRECTORY

Cuando SE se pulsa la tecla ALT, se abre una ventana que muestra las diversas combinaciones de teclas. El tiempo transcurrido entre la pulsacion de la tecla ALT y la visualizacion de la ayuda se controla con el comando SET/ALT_WAIT. Este es un número que se usa para variar el tiempo de espera. Este número no es en segundos; es un número relativo que se aumenta o disminuye para cambiar ellapso de tiempo. El valor por defecto es 50 que es mas o menos un segundo sobre un ordenador a 4.77 MHz, o simplemente un instante en un ordenador a 10 Mh. Si damos un tiempo de espera cero, inutitizamos totalmente la ventana.

Además de las teclas ALT, algunas otras teclas se definen para apoyar al sysop. Estas se indican a continuacion:

Ctr/W o Ctr/Backspace Borra la linea actual de entrada del Sysop

Ctrl/Y o ESC Anula la base de datos de DX o el listado de busquedas

Flecha-Arriba Recupera lineas previas de entrada del Sysop

INSERT Cambia el modo Insercion/Sobreescritura al editor.

Ctrl/A Cambia el modo Insercion/sobreescritura al editor.

Ctrl/X Cambia los indicativos sysop y sysop-alias.

Conexiones por los Puertos Serie

Esta sección describe la capacidad de tener conexiones de NODO y usuario sobre sus puertos serie de comunicacion. Por ejemplo, usted puede tener dos NODOS en el mismo sitio - uno teniendo las conexiones de NODO y usuario, y el otro sin tener ningún usuario, pero sirviendo como un NODO de servidor de base de datos para el Cluster. En esta situación, usted puede conectar los puertos COMM de los dos sistemas juntos y tener una conexión de NODO por medio de estos canales de comunicacio.

Básicamente, el software del PacketCluster gestiona este puerto como una pseudo-TNC. La unica cosa rara, por supuesto, es la notificación de conexión que haria una TNC normal. Por lo tanto, esto debe ser manualmente simulado por la estación que se conecta.

Para hacer este trabajo, ambos sistemas deben ejecutar el comando siguiente:

ENABLE/CONSOLE2 COM1 4800 CONNECTION

Este ejemplo muestra la palabra reservada CONNECTION en el comando« ENABLE/CONSOLE. Esto informa al software que este puerto debería tratarse como una pseudo-TNC. Ahora sobre uno de los sistemas, usted debería adjuntar a este canal e inicia la conexión con los comandos siguientes:

ATTACH CONSOLE2 AK1A

#K1EA

<F1 tecla de funcion>

Esto atacará al puerto COMM y entonces enviará el texto #K1EA. La señal de libra (#) indica el próximo texto es el indicativo del NODO que se conecta (o usuario). Finalmente, la tecla de funcion F1 liberará el canal e informara al software sobre que canal se conecto AK1A.

Operacion Diaria

Esta sección describe algunos de los aspectos de operación diaria del NODO del PacketCluster. Esto incluye operaciones que deben hacerse regularmente, así como también las cosas que necesitan hacerse basicamente una sola vez. Una breve explicacion sobre las necesidades de memoria tambien se adjunta.

Operaciones Regulares

Verdaderamente son muy pocas las cosas que deben hacerse para tener el NODO funcionando día a día. Durante su operación, los usuarios enviarán, recibiran, y borraran mensajes de correo. Estos mensajes se guardan en el directorio \PACKCLUS\MSG. Cuando los mensajes se borran. se renombran desde sus extensiones normales .MSG a una extensión .DEL. Estos mensajes deben borrarse explícitamente para no exceder el numero de ficheros en un directorio del DOS. Para hacer esto, ir a DOS

y usar el comando de DOS DEL, o poner estas instrucciones en el fichero DAILY.CMD para que se ejecute automaticamente esta operacion.

Operaciones irregulares

Cuando se producen DX, WWV, WX, y anuncios normales, los datos asociados en los ficheros (DX.DAT, WWV.DAT, WX.DAT, y ANNOUNCE.DAT) crecen de tamaño. En particular, un DX necesita 86 octetos de espacio de disco, WWV necesita 90 octetos, y WX y anuncios normales 120 octetos. Con el tamaño actual de la mayoría de los discos duros, usted puede estar meses y meses sin preocuparse del espacio en su disco duro, pero eventualmente usted puede querer reducir el tamaño de estas bases de datos. Usted puede hacer esto con el comando TRIM.

Si usted tiene habilitado el fichero de registro PC.LOG este también crece en tamaño registrando todos los eventos que ocurren sobre el NODO. Cada entrada ocupa 65 octetos de longitud. Usted puede cerrar el registro actual e iniciar uno nuevo con el comando NEWLOG.

Uso de la Memoria

La cantidad de memoria en un PC es limitada, se deberia ser consciente que la memoria necesitada por el de PacketCluster es:

La imagen dele PacketCluster, sin usuarios, requiere aproximadamente 280Kb de memoria. Cuando un usuario se conecta, se destina una cantidad de memoria addicional intermedia para el canal (o el usuario). Cuando el usuario se desconecta, la memoria que se usaba para el es recuperada y se vuelve a usar para el próximo usuario del canal. La cantidad de memoria usada por cada usuario que se conecta es de 57l octetos. Si las funciones de filtro de DX estan habilitadas, esta cantidad se aumenta a 1553. Cada usuario remoto requiere 55 octetos de memoria. Finalmente, cada mensaje activo de correo requiere l 18 octetos de memoria.

Como ejemplo, suponemos que usted tiene 25 usuarios conectados, 100 usuarios remotos, el filtro de DX esta habilitado, y 100 mensajes de correo activos. Esto ocupara aproximadamente 336,225 octetos de memoria. Esto sin contar la memoria necesaria pora los dispositivos para una tnc tipo DRSI.

La memoria se necesita también para las ventanas del sysop, las visualizaciones amplias del sysop con SHOW/DX, mensajes de correo salientes y entrantes contexto, etc. Esta memoria puede reutilizarse cuando no esta en uso.

Esta información se da orientativamente para su información.