CIUB-ficcion: Disco A fijo

De los archivos de CIUB-L

Date:         Wed, 25 Jun 1986 14:31:07 ABC
Sender:       (ZCCBJBC@EB0UB011) via List Processor <LISTSERV@EB0UB011>
Reply-to:     Distribution List <ZACUCIUB@EB0UB011>
From:         Jose Maria Blasco Comellas <ZCCBJBC@EB0UB011>
Subject:      CIUB-ficcion: Disco A fijo

Estoy haciendo una lista de las ventajas que tendria, para los usuarios,
tener un disco A fijo. Me gustaria que tuvierais la paciencia de leerla,
y que me informaseis si conoceis alguna otra. [Especialmente, los que
sois o habeis sido usuarios].

Ventajas derivadas de tener un disco A fijo (o mejor: de no tenerlo temporal)
-----------------------------------------------------------------------------

Estoy hablando de un disco A "pequeño" (alrededor de los 512K -- un cilindro
de 3380. P. ej., caben unos 25 ficheros de una o dos paginas, o 4 sobre
las 2000 lineas). Estoy suponiendo tambien que se conserva el disco
de departamento. Ventajas:

1.- Privacidad de la informacion:

    Se sabe que la estructura de disco de departamento es absolutamente
    contraria a la privacidad de la informacion: cualquiera puede ver
    lo que otro usuario (del mismo departamento) tiene en su disco.
    Esto no es importante en el supuesto [falso] de la Honestidad Universal,
    pero puede causar problemas en el caso de que se almacenen en ese disco
    informaciones (p. ej., tesis o tesinas) que pueden ser copiadas.

    Por otra parte, con la generalizacion del uso del correo electronico,
    y el acceso a otros nodos, puede aumentar el numero de comunicaciones
    electronicas de tipo estrictamente privado.

    Tener un disco A fijo permitiria al usuario

    1.1.- Mantener de forma totalmente privada informacion confidencial
          (p. ej., correo electronico)

    1.2.- Mantener en el disco de departamento informacion 'criptografiada'
          de forma que fuese indecifrable por los demas miembros del
          departamento, guardando en el disco A las partes necesarias
          para realizar la des-criptografia.

2.- Clarificacion del tipo de servicio que debe prestar el CIUB

    Es frecuente encontrarse con un usuario que tiene problemas con algun
    producto, y observar que los problemas se deben a que algun listillo
    (normalmente sin consultar con los demas miembros del departamento)
    ha copiado en el disco D un perfil del sistema, para modificarlo a su
    gusto, y luego, naturalmente, no ha estado al tanto de las cambios
    que introducia el CIUB en el disco G. Es mi opinion que no debe darse
    servicio de productos manipulados por el usuario (o, si se quiere en
    positivo, que el CIUB solo debe dar servicio de los productos que el
    mismo define); por otra parte, reconozco que algunos usuarios precisan
    de perfiles propios (la estructura de perfiles esta hecha para esto).
    Por tanto, creo que se deberia:

    2.1.- Definir una politica de servicio en la que se negase este a los
          usuarios que tuviesen perfiles no estandar (en las areas afectadas
          por tales perfiles). Para ello, se podria establecer la
          recomendacion de desaconsejar el almacenamiento de perfiles no
          estandar en el disco de departamento, y pedir a los usuarios
          que quisiesen un entorno personalizado que guardasen sus perfiles
          en el disco de usuario.

          Podria ser interesante desarrollar un EXEC que verificase la
          presencia de ficheros no autorizados en el disco de departamento,
          como ayuda a la conversion.

    2.2.- Correspondientemente, ampliar los mecanismos de perfilizacion de
          productos (como el editor) que no permiten varios niveles de
          perfil para que pudieran tener perfil de usuario (y quiza de
          departamento).

3.- Potenciacion de los mecanismos de correo electronico y de la red EARN

    Los productos de correo electronico estan pensados para tener un
    disco A fijo; aunque se pueden utilizar con disco temporal,
    su uso en tales condiciones requiere conocimientos especializados del
    usuario, y es bastante trabajoso.

    Por ejemplo:

    * los ficheros generados por las utilidades estandar de IBM
      para correo electronico (esto es, ficheros NAMES, NETLOG y NOTEBOOK)
      son creados por defecto con filemode AO. El O en el filemode indica que
      tales ficheros solo son visibles por una persona que tenga acceso
      read/write al disco que los contiene, y, por tanto, necesitan, si
      quieren ser conservados en el disco D, de un cambio de numero.

    * algunos de esos ficheros tienen nombres que no son unicos (dependientes
      de usuario), como el ALL NOTEBOOK. Si algun usuario despistado
      copia en el disco D un ALL NOTEBOOK, nadie mas puede hacerlo sin
      riesgo de cargarselo.

    * Algunos productos mas inteligentes que los de IBM (como por ejemplo
      el MAIL) dejan en el reader una copia de los ficheros leidos si
      el NOTEBOOK esta en un disco temporal.

    Pienso que, con la propaganda que hacemos de la red, no es logico que
    ofrezcamos un nivel de servicio que dificulta su utilizacion.

4.- Mejora en el funcionamiento y la eficiencia del sistema

    La posesion de un disco A fijo mejoraria la eficiencia del sistema al
    menos en las siguientes areas:

    4.1.- Se evitaria el tener que formatear un disco cada vez que
          un usuario hace LOGON (como se sabe, el formateo de un disco
          es extremadamente caro).

          Como corolario, se podria tener un control mas estricto de quien
          y como esta utilizando los temporales.

    4.2.- Bastantes procesos BATCH podrian funcionar con solo unas diez lineas
          por fichero BATCH, al estar la mayoria de ficheros necesarios
          en el disco A del usuario o en el disco de departamento: menos
          carga del area de SPOOL.

    4.3.- El tener un disco A fijo permitiria al usuario guardar en el los
          ficheros mas utilizados (siempre que fuesen pequeños) y reduciria
          notablemente el numero de accesos al disco D. [LINK Y ACCESS son
          operaciones tambien muy caras].

    4.4.- El comando DEFAULTS podria ser utilizado sin problemas (su uso sin
          disco de usuario fijo es casi imposible).

Ahora no se me ocurre nada mas. Por favor, si teneis alguna idea,
comunicadmela.

J. M. Blasco