Escrito en 1995 Para Documentar un sistema en red

Las reglas de programación citados mas abajo, representan el núcleo de los principios de programación de un servidor. En algunas ocasiones se verán cambios o partes de código que no siguen el esquema común del código; esto se debe a las indicaciones señaladas por el proceso en sí o por pedido del cliente.

Debido a que el acceso a las bases de datos es constante y en red el acceso es simultáneo, la red siempre se verá afectada por el número de archivos abiertos. Si se abren y cierran los archivos continuamente, la carga de red se altera de manera proporcional a la rapidez del equipo, y solo afecta el rendimiento de la terminal independiente y no de todos los nodos de la red.

Este sistema optimiza el código para aprovechar la velocidad del CPU disminuyendo al máximo el tiempo en que un archivo se encuentra bloqueado por un usuario. Aunque este abrir y cerrar de archivos afecta la velocidad, solo lo hace en las máquinas que de todas maneras alentarían la red. Sin embargo se da preferencia a dejar libre memoria, ya que la diferencia en memoria disponible afecta el rendimiento. Aunque el sistema obliga a hacer un número infinito de reintentos, realmente solo afecta a los equipos con BENCH mayor a 2. (Ver nota mas adelante)

Para reducir la baja de rendimiento del sistema en un equipo no apto para el mismo, se optó por realizar un procedimiento de acceso semejante a una biblioteca, con la diferencia que el bibliotecario será el programa, y al utilizar de manera adecuada las rutinas de bloqueo de registros del lenguaje, se crea un código mas robusto, por lo que en caso de una caída de la red lo único perdido es la ultima transacción, que puede identificarse en segundos. Así se tiene la ventaja de preservar la integridad de las bases de datos, y adicionalmente es muy fácil identificar que usuario estaba usando una base, permitiendo una corrección de errores independiente del software de Sistema Operativo de Red, a la vez que facilita asignar la responsabilidad a un equipo o persona específico y no al sistema.

La misma capacidad de las máquinas que servirán como nodos fijarán la carga de la red aparente, ya que el sistema reacciona a la máquina y no a la red. Según los índices de Red de Norton Utilities, el tráfico de la información afecta el rendimiento solo en las maquinas MUY antiguas, sin afectar a los mas nuevos. Debe recordarse que los índices Norton de Red son mejores mientras mas grande sea el valor.

En el manejo de disco en red deben considerarse los siguientes puntos:

a )Netware crea un respaldo de los archivos borrados, dicho respaldo solo se elimina si se llena el disco (produce un mensaje de error) o si se da la orden PURGE. Este inconveniente lo provoca la red, porque el dar los PURGE es mantenimiento del administrador de la red y no del sistema de suministros.
b )Los archivos temporales no deben hacerse en la red, sino en la ruta establecida por la variable de entorno TEMP, y en su defecto, se recomienda que se direccionen al disco duro local, si hay espacio suficiente.
c )En algunos lenguajes por default el archivo temporal de memoria virtual SIEMPRE se hará en el directorio donde esté el ejecutable, si no es posible cambiarlo al disco duro ( en Clipper si se puede ) es necesario que el usuario tenga derecho de creación en ese directorio, o el sistema sufrirá una caída. Esto puede evitarse usando los parámetros SWAPPATH de Clipper, pero se recomienda usarlos al administrador de la red.
d )Si el disco al que apuntan los archivos temporales esta comprimido (dblspace por ejemplo) el rendimiento del sistema (y su integridad) decrecen a la tercera parte.

Se recomienda crear un proceso para medir los tiempos de acceso a red se que pueda llamarse en cualquier momento. Un procedimiento promedio muestra los resultados de una prueba de lectura/escritura secuencial en los modos Shared y Exclusive, dando como resultado el rendimiento real de acceso a archivos por nodo, independiente de la Red (aunque el CPU y disco del servidor influyen en la prueba, lo hacen por igual en cada nodo).

Usando el módulo anterior puede verse la gran diferencia entre máquinas nuevas y otras un poco mas antiguas. El sistema se diseñó para ser usado en máquinas Pentium2 y en la primera implantación real, el sistema contó con varias máquinas Celeron con 16 mb de memoria, puede notarse que la degradación del sistema no se debe al programa.

Debido a que el sistema en red espera una operación simultánea por varios nodos, hay que tratar de usar lecturas no exclusivas siempre que fuera posible, almacenando los campos necesarios en variables de memoria dejando el archivo cerrado excepto al leerse o escribirse datos. Para evitar que el carácter “fijo” de estas variables afecte los resultados, algunas operaciones solo pueden ser realizadas si hay un solo usuario en la red o con un nivel de acceso determinado en el sistema y/o en la red.

Como se mencionó anteriormente, el mantener archivos cerrados siempre que sea posible aumenta la fiabilidad del sistema. Por ejemplo, una operadora del sistema puede recibir una llamada de un cliente que no se exprese claramente, y en lugar de mantener el archivo abierto hasta que los datos sean introducidos, restringiendo por lo tanto el acceso de otros usuarios o procesos, este sistema asegura que en un lapso no mayor de 3 segundos, y esto es en casos extremos, el archivo estará disponible para el usuario que lo requiere. En pruebas durante el desarrollo el tiempo de acceso cambia entre 30 y 40 centésimas de segundo, y la integridad de los archivos se asegura usando los datos solo cuando se requieran. La experiencia ha demostrado que el tiempo total de atención a un cliente normal, por una operadora capacitada, se limita a 18 segundos desde el momento en que se levanta el teléfono hasta que se despide el cliente, tomando como base 10000 registros de clientes.

En la mayor parte de las tablas de CONSULTA no modificables, que necesiten la base abierta se trabaja sobre la base en sí y no sobre bases temporales. Esto es con el fin de presentar información mas confiable, causando uno de los puntos débiles del sistema, aunque esta debilidad es relativa, ya que en las pruebas en que se cortó intencionalmente la energía eléctrica, no se dañó la información. Como la base se abre en modo no exclusivo, no se pierde información en caso de fallas de la corriente eléctrica, pero mientras se esté usando la tabla, no es posible que otra terminal utilice un proceso que requiera exclusividad. En otras palabras, se debe dar prioridad a la actualización On-line de información que “solidez” relativa del sistema, si es necesario usar tablas directas sin cerrar la fuente de datos.

[color=#00FF00]Criterios de programación:

1. Salvo en casos excepcionales, solo un archivo de base de datos estará abierto a la vez. Ejemplo, al guardar en bitácora.
2. El usuario MAESTRO será el único autorizado para dar altas o cambios de usuarios del sistema, incluyendo niveles de acceso.
3. Un usuario no debería usar simultáneamente dos nodos. Sin embargo PUEDE hacerlo, al igual que el sistema de Novell. Las medidas de seguridad y los niveles de acceso adoptados cumplen y modifican parcialmente este objetivo y permiten detectar la razón de caídas del sistema.
4. La información en tránsito se evitará siempre que sea posible para evitar que los usuarios manejen información desactualizada , prefiriéndose leer nuevamente la información cuando sea necesario.
5. Entrada de datos por menús o tablas., list y similaresPara preservar la integridad relacional, debe facilitarse la introducción de los mismos a través de listas para evitar se introduzcan datos erróneos. Para aumentar otra opción en los menús (para descripción por ejemplo) es suficiente con modificar las características del mismo, y en las listas se carga por si solo el dato, y el código es autoexplicativo.
6. Aunque los Índices pueden agilizar la búsqueda, hay información que debería estar en orden consecutivo para evitar omisión de datos: Por ejemplo, no debería asignarse el número de ruta 41 si no hay una ruta 40. Siguiendo el ejemplo, si el número de Pipa que el usuario intenta introducir es mayor al que corresponde consecutivamente, aparecerá un mensaje pidiendo que capture previamente los registros intermedios, o fijará automáticamente el valor correcto. Es decir, si el ultimo registro es de la ruta 40, no debe permitirse otro registro nuevo que el 41. Aun así es valido hacer modificaciones a registros anteriores (1-40).Debe evitarse incorporar la función de edición directa en las tablas, ya que puede prestarse a error en la información capturada , porque suele suceder que se causen cambios no deseados.De manera adicional, es preferible evitar los índices para manejo en red, ya que al usar el índice la base debe abrirse en modo exclusivo, o realizando un número excesivo de comprobaciones, afectando esto al rendimiento del programa en red.Debe tomarse en cuenta que ciertas búsquedas deben ser secuenciales y por lo tanto el uso de índices resulta poco práctico. Para evitar las demoras en búsquedas no secuenciales debe tratarse de hacer búsquedas directas y/o inversas cuando es posible, y si se usa SQL con campos sencillos.
7. Las operaciones que solo debe realizar el Usuario Maestro, no aparecerán para otros usuarios, o marcarán un mensaje de Opción no disponible.
8. Los procedimientos y menús deben ser lo mas modulares posibles y reutilizables por otros sistemas.
9. Las variables locales serán desechadas siempre que sea posible para evitar efectos secundarios. NO DEBEN USARSE STATICS de manera indiscriminada por que afectan el volumen de memoria disponible y solo tienen visibilidad dentro del *.obj correspondiente. Debe restringirse el uso de Privates en lenguajes como Clipper, y de Public en sistemas como VB , y por lo tanto solo se usan en aquellas ocasiones en que realmente es indispensable.Aunque el uso de funciones y procedimientos Static para facilitar el encapsulamiento es una opción aparente, tiene el problema que aumenta los requerimientos de memoria del programa, por lo que solo debe usarse en Clipper en casos de procesos homónimos dentro de diferentes módulos.
10. Si se aplica, los procedimientos y funciones deberán de guardar pantalla, color y fuente siempre que estos sean afectados como resultado de su proceso, para eliminar efectos secundarios ( Encapsulado ). Además no deben dejar índices en disco duro, si se utilizan, ni bases abiertas ( si el sistema es de red ). Preferentemente no deben dejarse archivos o tablas abiertas.
11. El programa debe permitir modificaciones-adaptaciones para cumplir con las necesidades de empresas del mismo giro, pero con el mismo código..
12. NO DEBE PERMITIRSE BAJAS FISICAS O LOGICAS DE INFORMACIÓN QUE PONDRÍAN EN PELIGRO LA INTEGRIDAD RELACIONAL DEL SISTEMA
13. Se debe dar prioridad a Legibilidad sobre eficiencia de código, y a bajo consumo de memoria sobre velocidad.
14. En Clipper No debe utilizarse la instrucción SET DELETE ON salvo en casos indispensables, y siempre debe dejarse en OFF al salir de los procedimientos que lo utilicen.
15. Es importante recordar que el usuario debe tener acceso a TODOS los derechos de los directorios de red, ya que de no hacerlo se corre peligro de pérdida de información al reordenar, compactar, en procesos propios del programa
16. Es deseable que el programa diga “No puedo continuar debido a que AQUIROZ está usando el archivo”, a decir “el usuario esta usando el archivo”, esto hace que los usuarios estén mas tranquilos, y se den cuenta que muchas veces el error es de ellos y no del programa.

[color=#00FF00]Requerimientos de memoria (Clipper):

Según Nantucket los programas de Clipper 5.2 necesitan un mínimo de 120 en memoria convencional para funcionar, y 160 para un uso óptimo. Esta memoria debe sumarse al numero de Kb que reporta RTLINK, y estar disponible en memoria convencional ANTES de llamar al sistema. Ejemplo:

Memoria Total
Total RTLINK 311
Memoria Mínima 120 311+120 = 431
Memoria Recomendada 160 311+160 = 471
Algunos procesos necesitan mas memoria que otros, así que donde ha sido posible, se hacen comprobaciones adicionales de memoria disponible sobre la marcha. Esto es muy importante en los procedimientos que crean arrays de gran tamaño.

NOTA Sobre EXOSPACE:

El uso de EXOSPACE de Clipper 5.3 crea situaciones especiales de memoria. Se sugiere leer detenidamente el anexo correspondiente. Por otro lado, todos los chequeos de memoria que aparentemente sobran en 5.2, son necesarios para 5.3, pero después del crecimiento que ha tenido suministros, es posible que deban ponerse mas líneas de chequeo de memoria en lugares estratégicos.