Buenas practicas para la administración del sistema

En este articulo iré relacionando todos los consejos de practicas, que, creo deben usarse, y que,  a lo largo de los años, facilitarán la gestión de un sistema AS400.

No crear librerías que empiecen por Q

IBM denomina las bibliotecas, del sistema operativo y de sus productos (con alguna excepción), con la letra Q como caràcter inicial del nombre de biblioteca.

Si nosotros creamos bibliotecas que empiecen con esa letra, al realizar una copia de seguridad con el parámetro LIB(*ALLUSR), no se incluirán las bibliotecas Q*, excepto las bibliotecas QGPL, QUSRSYS, QPFRDATA y otras excepciones (ver ayuda mandato SAVLIB) . 

Por tanto no es una buena practica utilizar la letra Q como inicial de nuestras bibliotecas ya que si no las salvamos posteriormente no tendremos copia de las mismas.

No crear objetos en la biblioteca QSYS

No es una buena practica crear nuestros programas, ficheros, u otros objetos, en la biblioteca del sistema operativo, ni, en general, en otra biblioteca Q*, ya que afectaran a todas las aplicaciones que se ejecuten en el sistema y pueden provocarnos problemas en el futuro.

Crear la cola de mensajes QSYS/QSYSMSG

Esto es una función poco conocida del sistema operativo, al crear esta cola especial de mensajes se registraran en ella mensajes de gravedad que seguramente pasarían desapercibidos en la QSYSOPR, si hay muchos mensajes.

Activar la limpieza automàtica del sistema

Para mantener el espacio en disco a raya, una de las tareas que deben realizarse es la de limpiar logs y spools, periódicamente, para ello ver la entrada publicada: Limpiar automaticamente mensajes, joblogs, dumps, ...

También puede ser interesante borrar los archivos de spool de usuario antiguos, para ello podemos activar la fecha de expiración del archivo de spool (a partir V5R4) o planificar un trabajo con la utilidad DLTOLDSPLF, que podemos obtener en http://www-01.ibm.com/support/docview.wss?uid=nas8N1019285

Activar las estadísticas de espacio en disco

Para controlar el espacio en disco utilizado en el sistema podemos activar y planificar la tarea de recogida de uso del disco, el procedimiento esta explicado en la entrada Estadísticas de espacio en disco.
Es recomendable imprimir periodicamente la información de estas estadisticas, lo podemos, o tamien podemos utilizar la utilidad que publique para llevar un control más exhaustivo, ver la utilidad DSKINF.

Activar la seguridad del sistema

Para tener más control de lo que pasa en nuestro sistema, y seguramente poder cumplir con las auditorias de seguridad, es más que recomendable activar el diario de auditoria del sistema. El procedimento para hacerlo ya esta publicado en esta entrada: Configurar seguridad del sistema.

Lo unico que habra que tener en cuenta es que necesitaremos más espacio en disco para los receptores del diario de auditoria; además debemos crear un procedimento para gestionarlos (habitualmente guardarlos a cinta y eliminarlos)

Tambien deberíamos desactivar los usuarios con contraseña por omisión.

Asi como debemos desactivar a los usuarios sin uso.

Tareas a revisar y/o ejecutar periódicamente:

• Copia de seguridad de nuestros datos diariamente (GO BACKUP)
• Una copia completa del sistema (semanal o mensual o trimestral), y aprovechar para realizar un IPL (GO SAVE, opción 21)
• Problemas detectados por el sistemas (WRKPRB)
• Actualizar el nivel del acumulativo y grupos de ptf (WRKPTFGRP)
• Ejecutar una reclamación de espacio en disco, después de una caída no planificada del sistema (RCLSTG)
• Actualizar el sistema operativo antes de quedar sin soporte por parte de IBM.
• ...

Documentar todos los cambios realizados en el sistema

Cuando cambiamos:

• El valor de un variable del sistema.
• La configuración de un subsistema suministrado por IBM.
• Las clases con los parámetros de ejecución.
• La configuración de los pools de memoria.
• Descripción de los mensajes, en los archivos de mensajes suministrados por IBM.
• ect...

Es una buena practica documentar dichos cambios en algun documento.

Suelo utilizar un miembro fuente en la QGPL/QCLSRC, por ejemplo SYSCUST, donde voy insertando los cambios realizados con un comentario de la razón. De esta forma en caso de migrar el sistema a un nuevo hardware, tendremos todos estos cambios documentados y podremos reproducirlos más fácilmente.