Feliz Navidad y 2010

eyeOS y IBM

Hoy he leído esta noticia IBM distribuirá el software de una 'start up' catalana en El Periódico que me ha llamado la atención.

Una compañía creada por dos estudiantes catalanes ha desarrollado el escritorio web EyeOS,  basado en tecnología "cloud computing" y con software libre, y que ha sido adoptado por IBM para usarlo en sus system Z (mainframe). Más información en el blog de EyeOS:

eyeOS y IBM – Trabajando juntos

¡ Buena idea !, ¿para cuando para los system i?

Biblioteca de trabajo TEMP

Para poder crear objetos de trabajo es muy recomendable utilizar la biblioteca QTEMP, que el sistema crea solo para nuestro trabajo automáticamente. Pero si los objetos creados en esa biblioteca deben ser usados en mas de un trabajo, o sesión, o accedidos por odbc, bajados por ftp, o tenerlos en el sistema durante unos días, es muy conveniente tener una biblioteca que no desaparezca y que pueda ser compartida por mas de un trabajo, para ello nada mejor que crear la biblioteca TEMP (o como queráis llamarle), con autorización *PUBLIC *ALL. Para ello ejecutar los mandatos:

• CRTLIB LIB(TEMP) TYPE(*TEST) TEXT('Temporary library (cleared weekly automatically)')
• CHGOBJOWN OBJ(TEMP) OBJTYPE(*LIB) NEWOWN(QPGMR)

Con la misma idea podemos crear el directorio /home/temp:

• CRTDIR DIR('/home/temp') DTAAUT(*RWX) OBJAUT(*ALL)
• CHGOWN OBJ('/home/temp') NEWOWN(QPGMR)  

Para que esta biblioteca y directorio, no se conviertan en un contenedor de basura es muy recomendable realizar una limpieza periódica de su contenido.

Los objetos que se crean en esta biblioteca y directorio se podrían  eliminar automáticamente todos los domingos a las 06:00h (por ejemplo), con el trabajo planificado CLRTEMP.

Mandato para planificar dicho trabajo:

ADDJOBSCDE JOB(CLRTEMP) CMD(CALL PGM(MYLIB/CLRTEMP)) FRQ(*WEEKLY) SCDDATE(*NONE) SCDDAY(*SUN) SCDTIME(060000)

JOBQ(QUSRNOMAX) TEXT('Clear library TEMP and /home/temp')

Código del programa CLRTEMP

Planificador de trabajos

El objeto de planificación de trabajos contiene entradas que configuran una planificación de trabajos (WRKJOBSCDE). Puede planificar trabajos añadiendo una entrada de planificación de trabajos al objeto de planificación de trabajos (ADDJOBSCDE). 
Para que funcione el planificador de trabajos debe estar activo el trabajo QSYSSCD en el subsistema QCTL (o QBASE) y se arranca automáticamente después del IPL.

El objeto de planificación de trabajos, QDFTJOBSCD, está en la biblioteca QUSRSYS y tiene un tipo de objeto *JOBSCD. No puede crear, suprimir, redenominar ni duplicar el objeto de planificación de trabajos, y no puede moverlo a otra biblioteca. Este objeto de planificación de trabajos se suministra con la autorización de uso público *CHANGE. Esta es la mínima autorización necesaria para añadir, cambiar, retener, liberar y eliminar entradas de planificación de trabajos.

Cómo guardar o restaurar objetos de planificación de trabajos

El objeto de planificación de trabajos puede salvarse con los mandatos Salvar Biblioteca (SAVLIB), Salvar Objeto (SAVOBJ) o Salvar Objetos Cambiados (SAVCHGOBJ), y después restaurarse con los mandatos Restaurar Biblioteca (RSTLIB) o Restaurar Objeto (RSTOBJ). La restauración del objeto de planificación de trabajos hace que la próxima fecha de sometimiento se actualice para cada entrada. Puede restaurar el objeto de planificación de trabajos al sistema desde el que se salvó o a un sistema distinto, pero no puede restaurarlo a una biblioteca que no sea QUSRSYS. Si restaura el objeto de planificación de trabajos a un sistema diferente, el registro histórico de sometimiento de trabajos se borra en cada entrada.

Información extraída del manual Gestión de Trabajos, capitulo Planificación de trabajos (pag.267)

IBM i Manifest

Por el boletín mensual de Common Europe España del mes de noviembre me he enterado de la iniciativa de 71 partners de IBM en Japón de publicar un anuncio en los periódicos pidiendo que IBM de un apoyo claro a la plataforma system i (o sea el AS400), extraído del comunicado podemos leer:

"Aprovechando la oportunidad del 20º aniversario de IBM i hemos creado el Manifiesto i de IBM para solicitar a los usuarios volver a reconocer el valor y los logros de IBM i. Les pedimos que renueven su firme confianza y la creencia de que IBM i es la mejor infraestructura disponible para apoyar la innovación gerencial y operativo."

Help400 nos cuenta en varios artículos en su blog como esta evolucionando esta iniciativa:

• Manifiesto por el IBM i, un ejemplo a seguir 
  
• La iniciativa "IBM i Manifest" sigue ganando adeptos
• i + POWER: The Spanish iManifest

Ahora ya podemos adherirnos a esta iniciativa en la web de IBM i Manifest de Europa.

Esperemos que IBM oiga nuestras "plegarias" que, aunque no tienen nada que ver con el cambio climático, si  tienen que ver con el cambio en los escenarios que se nos avecinan (cloud computing) y que me recuerdan a que es el enésimo vaivén hacia una estructura informática de "cliente ligero" y sistema central. ¿No os recuerda a pantalla verde + AS400?, este binomio viene mejorado en cada cambio que se ha hecho en la historia de la informática.

Pensar un poco en esta evolución: Pantalla verde + Entorno de ventanas + Navegador + Navegador que ejecuta aplicaciones remotas = Computación en nube.

Cancelar un rollback

En un artículo anterior se explicaba como averiguar el porcentaje rollback realizado por un trabajo.

Pero en muy contadas excepciones nos puede interesar cancelar un rollback, cosa realmente peligrosa sino conocemos, pero que muy bien, lo que esta haciendo el trabajo en la base de datos.

Por norma un rollback NUNCA se debe cancelar, debemos esperar que termine.

No se os ocurra realizar un IPL para forzar la finalización de un rollback, ya que el sistema lo terminara durante el IPL, con lo os quedareis sin sistema durante un tiempo indeterminado.

Dicho lo anterior, unos ejemplos de casos en que nos puede interesar cancelar el rollback:

• Supongamos que lanzamos un programa que crea una tabla temporal, abre un ciclo de commit y empieza a insertar registros en esta tabla, el programa se mete en un bucle y continua insertando registros, cuando lleva unos cuantos millones de insert nos damos cuenta y cancelamos el trabajo. Entonces empieza a realizar el rollback eliminando millones de registros insertados. En este caso si pudiéramos cancelar el rollback y eliminar la tabla temporal seguro que terminaría más rápido que esperar el final del rollback.
• Un programa se mete en un bucle actualizando miles de veces el mismo registro, es importante verificarlo con las entradas del diario. Al cancelarlo el rollback empezara a realizar miles de update en sentido inverso hasta dejarlo en el valor original. También en este caso si supiéramos el valor del registro al inicio del bucle, podríamos cancelar el rollback y después realizar un update manual del registro a su valor inicial; con esto ahorraríamos seguramente mucho tiempo.
• Un trabajo realiza cambios en una o mas tablas, utilizando un solo ciclo de commit, cuando lleva unos millones de cambios cancelamos el trabajo. Si tenemos la absoluta seguridad que tenemos una copia de las tablas antes de empezar el proceso y que ningún otro trabajo ha realizado cambios en las mismas, podríamos valorar la posibilidad de cancelar el rollback y restaurar las tablas.
  

A partir de la V5R3 existe un procedimiento para cancelar un rollback, es el siguiente:

1. Definir la estrategia para reparar la base de datos: Asegurarse de que tenemos los datos necesarios, verificar que tenemos las copias de seguridad, son accesibles  y contienen las tablas implicadas (recordar los ejemplos).
   
2. Conectarse con usuario con permisos *SECOFR.
   
3. Lanzar el ENDJOB, con OPTION(*IMMED), del trabajo que empezara a realizar el rollback.
4. Averiguar el ciclo de compromiso del rollback que vamos a cancelar:
5. WRKCMTDFN JOB(012345/MYUSER/MYJOB)
6. Pulsar F23 para ver más opciones y  aparecerá la opción 20=End rollback.
7. Introducir la opción 20 en el ciclo de compromiso a cancelar y pulsar Intro.
8. Nos aparecerá una pantalla (ver imagen) que nos advierte del peligro de cancelar el rollback, ya que dejaremos inconsistente la base de datos y eso podría afectar a otros trabajos.
9. Si estamos seguros pulsaremos Intro. Sino podemos pulsar F12 para volver atras.
10. A partir de ese momento el trabajo empezará a liberar los registros bloqueados por el commit, cancelando el rollback. Esto puede tardar algún tiempo dependiendo de la cantidad de registros.
    
11. Una vez a finalizado el rollback y el trabajo, podremos reparar la base de datos, según la estrategia decidida en el primer paso. En los ejemplos: Eliminar la tabla temporal, Actualizar manualmente el registro implicado, Restaurar la/s tabla/s implicadas.
    

ADVERTENCIA FINAL: Es responsabilidad vuestra el utilizar, o no, este procedimiento. Como comprenderéis podéis causar un daño irreversible a la base de datos, si no estáis absolutamente seguros de lo que vais a hacer. En caso de la más mínima duda os recomiendo esperar al final del rollback.

Más información en el documento: Ending A Rollback - V530 and Later Releases

Cambio hora verano/invierno

La madrugada del ultimo domingo de Octubre los sistemas deben cambiar la hora al horario de invierno, o sea a las 3:00 se retrasara la hora a las 2:00 horas.

Actualmente, a partir de la V5R4, podemos configurar el sistema para que automáticamente realize el cambio de hora sin nuestra intervención, para ello debéis seguir las indicaciones del articulo:

Sincronizar la hora del AS400

Pero si tenemos un sistema con una versión anterior del OS400, podemos utilizar mi utilidad SUMWIN para realizar el cambio de hora automáticamente.

La estrategia para realizar el cambio de hora es añadir un trabajo automático al planificador de tareas el siguiente mandato (con usuario QSECOFR):

ADDJOBSCDE JOB(SUMWIN) CMD(CALL PGM(SUMWIN)) FRQ(*MONTHLY) SCDDATE(*NONE) SCDDAY(*SUN) SCDTIME(020000) RELDAYMON(*LAST) JOBQ(QSYSNOMAX) TEXT('Cambio automático a horario de verano-invierno')

Con esto conseguimos que cada ultimo domingo de mes se lance el trabajo y solo cambiara la hora cuando sea:

• El ultimo domingo del mes de Marzo a las 02:00:00 sumara una hora o
• El ultimo domingo del mes de Octubre esperara a las 03:01:00 y restara una hora,
• En ambos casos envía un mensaje al operador.
• El resto de meses no hará nada.

Podéis bajaros el código en este enlace.

Cambios en variable de sistema QLMTDEVSSN (V6R1)

La nueva versión del i5/OS V6R1, incluye un muy esperado nuevo valor para la variable del sistema QLMTDEVSSN (Limit device session).

Hasta la versión V5R4 podíamos tener los siguientes valores:

0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.

1=Limit = El usuario solo puede abrir una sesion interactiva.

Con la V6R1 se modifican los valores de esta variable como sigue:

0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.

1-9=Maximum device sessions = Este valor nos indica cuantas sesiones podrá abrir como máximo un usuario 1,2,.. y hasta 9 sesiones interactivas concurrentes.

Para ver que valor tiene el sistema: 
DSPSYSVAL SYSVAL(QLMTDEVSSN)

Por defecto es preferible, sobretodo en los sistemas de Producción, que este valor de sistema este a 1, así todos los usuarios, que en el parámetro LMTDEVSSN de su perfil de usuario tengan el valor *SYSVAL, solo podrán abrir una sesión interactiva por defecto. A los Operadores y/o Administradores podemos darles más sesiones cambiando este valor en su perfil de usuario.

Pero puede ser interesante tener el valor de sistema a 2 o 3 en los sistemas de Desarrollo, para que al crear un nuevo programador, y sin tener que cambiar su perfil de usuario, ya pueda tener más de una sesión interactiva, cosa muy solicitada y recomendable para poder realizar pruebas, del código que están creando y probando, mas cómodamente.

Auditar uso de comandos

Hay ciertos mandatos que nos puede interesar que los usuarios no utilicen, pero en cambio hemos de permitir el uso de otros.
Al crear un usuario y definir que clase de usuario es (USRCLS), de alguna forma ya estamos limitando que mandatos podrá usar y cuales no. Con las autorizaciones especiales (SPCAUT) del perfil de usuario, podemos limitar aun más el acceso a los mandados críticos.
Pero ademas podemos auditar la utilización de un mandato, sin limitar su uso, por ejemplo el mandato CLRPFM.

¿Como podemos hacerlo? Simplemente cambiando el valor de auditoria del objeto QSYS/CLRPFM de tipo *CMD.

Para ver el valor actual de auditoria de un objeto, hemos de utilizar el mandato:

DSPOBJD OBJ(QSYS/CLRPFM) OBJTYPE(*CMD) DETAIL(*FULL)

Pulsando una vez la AvPág, podremos observar que tiene el valor "Object auditing value" igual a *NONE. Para cambiarlo y empezar a auditar su uso, ejecutaremos el mandato:

CHGOBJAUD OBJ(QSYS/CLRPFM) OBJTYPE(*CMD) OBJAUD(*ALL)

Esto hará que cada vez que se utilice el mandato CLRPFM, se grabara una entrada en el diario de auditoria del sistema (QSYS/QAUDJRN).

Posteriormente podemos obtener un listado del uso del mandato ejecutando:

CPYAUDJRNE ENTTYP(CD) OUTFILE(MYLIB/CMD_USE)

Esto volcara las entradas de uso de cualquier objeto, que se este auditando, a un fichero. Después con SQL podremos seleccionarlas:

SELECT CDTSTP, CDJOB, CDUSER, CDNBR, CDPGMLIB, CDPGM, CDCMDS FROM
MYLIB/CMD_USECD WHERE CDCMDS LIKE '%CLRPFM%'

Nota: El mandato CPYAUDJRNE añade los caracteres CD al nombre del fichero de salida.

Ahora ya podemos ver cuando, quien y desde que programa se ha utilizado el mandato CLRPFM. Si el programa es el QCMD, nos indicara que se ha ejecutado desde la linea de mandatos.

Este tipo de auditoria nos puede también servir para investigar algún problema en nuestros programas o aplicaciones, ver quien usa ciertos objetos, o simplemente llevar un registro del uso de ciertos objetos importantes.

CHGOBJAUD OBJ(MYLIB/MYOBJECT) OBJTYPE(*CMD) OBJAUD(*ALL)

Hay que tener en cuenta que estas entradas del diario de auditoria ocupan espacio en disco y habrá que tener un procedimiento de salvado y borrado de los receptores de diario para evitar comernos el espacio en disco si auditamos demasiados objetos.
También el rendimiento del sistema puede verse afectado, ligeramente, si auditamos muchos objetos muy usados.

Una vez analizado sería conveniente desactivar la auditoria de uso, a no ser que queramos llevar un registro.

CHGOBJAUD OBJ(MYLIB/MYOBJECT) OBJTYPE(*CMD) OBJAUD(*CHANGE)

Podemos usar el valor *CHANGE que habitualmente es el valor por omisión del valor de sistema QCRTOBJAUD, o *NONE para no auditar nada en absoluto ese objecto (solo es recomendable en unos pocos casos).

Mas información:

• Planning security auditing
  
• Securing Powerful and Sensitive Commands
  

Conexion automatica al AS400

¿Como realizar una conexión automática desde un servidor Windows, o un cliente de red, al AS400?

A veces necesitamos para lanzar un cmd, o bat, en un pc en que la conexión al AS400 ya este establecida; para hacerlo automáticamente debemos tener instalado el producto iSeries Access y entonces podremos utilizar el comando c:\Program Files\ibm\Client Access\cwblogon.exe.

Básicamente se trata de cargar en un buffer de windows el usuario y la contraseña que utilizamos para conectar a el AS400 y así cuando los requiera la conexión windows la suministrara sin ninguna intervención.

Sintaxis
Para iniciar la sesión en un servidor:
CWBLOGON sistema /u ID_usuario /p contraseña

Para borrar un ID de usuario específico:
CWBLOGON sistema /u ID_usuario /c

Para borrar todos los ID de usuario de un servidor:
CWBLOGON sistema /c

Para borrar todos los ID de usuario de la antememoria:
CWBLOGON /c

Parámetros
sistema designa el nombre del servidor para el que debe almacenarse la información de ID de usuario y contraseña
/u ID_usuario designa el ID de usuario del servidor que debe almacenarse en la antememoria de iSeries Access para Windows
/p contraseña designa la contraseña del servidor asociada al ID de usuario proporcionado
/c borra la información de ID de usuario y contraseña de la antememoria de iSeries Access para Windows

Para más información:
http://www.redbooks.ibm.com/pubs/html/as400/v4r5/ic2924/info/rzaiimst.pdf

Como saber si el AS400 necesita mas RAM

¿Como podemos saber cuando un sistema AS400 necesita mas memoria RAM?

Nota: En AS400 no se denomina Memoria RAM sino Memoria Principal (Main storage), y el disco Memoria Auxiliar (Auxiliary storage) que puede estar dividido en ASP (Auxiliary storage pool) a modo similar del concepto de volúmenes.

El concepto de uso de la memoria, y la CPU, en el AS400 es muy diferente a la de los sistemas Windows y esa es la base de muchos errores de concepto, cuando provienen de personas que no tienen mucha idea de como funciona un AS400 y, además llegando a conclusiones totalmente equivocadas.

Con el mandato DSPSYSSTS puedes ver la cantidad de memoria (pool size) que esta "usando" el sistema, en los diferentes pool de memoria definidos en el sistema (ver Memoria para subsistema), pulsa F21=Select assistance level y selecciona 3=Advanced para acceder a toda la información en la misma pantalla.
El i5/OS, el nuevo nombre del sistema operativo del AS400, siempre consume siempre TODA la memoria disponible.

Normalmente yo me fijo, básicamente, en cuantas paginas en estado Inelegible (Wait-Inel, Act-Inel) aparecen en el DSPSYSSTS.

¿Que nos indica este parámetro Inel? pues básicamente que cuando el s.o. ha necesitado cargar una pagina de memoria de disco a memoria RAM (ya que estaba paginada), no ha podido, porque toda la memoria RAM estaba ocupada por trabajos que están activos y usando la CPU, esto explicado de manera simple y para que se entienda, ya que intervienen otros factores, como por ejemplo el TIMESLICE y el PURGE.

Además habría que analizar las causas de la paginación, ya que podría tener una "fácil" solución que no implique comprar mas RAM, sino solamente algo de "tunning" del tamaño de los pool de memoria y/o en el numero de hebras (threads) activos en cada momento.

Puedes leerte las siguientes entradas de mi blog www.as400howto.com, para ver si te aclaro un poco más el tema:

• Memoria para trabajos batch
• Subsistema de Control

También tienes un link a un documento de IBM que puede servirte de ayuda:

• Experience Report

Recuperar configuracion dispositivos

¿Como recuperar la configuración de dispositivos, controladores y lineas configuradas en nuestro AS400?. Para ello ejecutar el siguiente mandato:

RTVCFGSRC CFGD(*ALL) CFGTYPE(*ALL) SRCFILE(QGPL/QCLSRC) SRCMBR(SYSTEM_CFG)

Podemos utilizar la información recuperada como backup histórico o para, incluso, duplicar la configuración en otros AS400.

Un ejemplo de como buscar dos impresoras con la misma dirección IP:

1. RTVCFGSRC CFGD(PRT*) CFGTYPE(*DEVD) SRCFILE(QGPL/QCLSRC) SRCMBR(PRINTERS)
2. Esto crea el miembro fuente QGPL/QCLSRC.PRINTERS.
3. Doy por supuesto que todas las impresoras se denominan PRT*, sino habrás de hacerlo por cada una, o por grupos, en ese caso acuérdate de utilizar la opción MBROPT(*ADD) para que no sobrescriba el miembro.
4. Después editar el fuente:
5. STRSEU SRCFILE(QGPL/QCLSRC) SRCMBR(PRINTERS)
6. Utilizar la opción de búsqueda de string del SEU, para encontrar la dirección IP
7. Utilizar la tecla F14 (o el comando F) + Direccion_IP y pulsar F16 para buscarla.
8. Si aparece mas de una vez es que esta duplicada.
   

Como cargar lista de bibliotecas

A veces nos puede interesar cargar en un trabajo la lista inicial de bibliotecas.

Esto nos puede servir, por ejemplo, en un menú, para nuestro operador, que realice llamadas a programas o someta otros y estos cambian la lista de bibliotecas. Es conveniente dejar la lista de bibliotecas como estaba después de cada ejecución para evitar errores del operador al tener cargada una lista de bibliotecas diferente a la que él cree tener.

El código que habríamos de insertar en nuestro programa seria el siguiente:
DCL VAR(&BLANKS) TYPE(*CHAR) LEN(2764)
/* Incluir estas sentencias inmediatamente después de declarar las variables */
CHGVAR VAR(&BLANKS) VALUE(' ')
DOWHILE COND(&COUNT <= &LEN) CHGVAR VAR(&BLANKS) VALUE(&BLANKS *CAT ' ') CHGVAR VAR(&COUNT) VALUE(&COUNT + 1) ENDDO /* Este mandato guarda en la variable &USRLIBL el valor de la lista de bibliotecas actual */ RTVJOBA USRLIBL(&USRLIBL)
....
Inserte su código aquí
....
/* Construir el mandato CHGLIBL con el valor de la lista de bibliotecas en blanco */
CHGVAR VAR(&CMD) VALUE('CHGLIBL LIBL(' *TCAT &BLANKS *TCAT ')')
/* Limpia la lista de bibliotecas del trabajo */
CALL PGM(QCMDEXC) PARM(&CMD &LEN)
/* Construir el mandato CHGLIBL con el valor de la lista de bibliotecas inicial */
CHGVAR VAR(&CMD) VALUE('CHGLIBL LIBL(' *TCAT &USRLIBL *TCAT ')')
/* Cargar la lista de bibliotecas inicial del trabajo */
CALL PGM(QCMDEXC) PARM(&CMD &LEN)
ENDPGM

Se utiliza el QCMDEXC para ejecutar el CHGLIBL, en lugar de CHGLIBL LIBL(&USRLIBL), ya que en este caso solo nos cargaría en la lista la primera biblioteca de la variable &USRLIBL; eso es porque el parámetro LIBL es un parámetro de listas y el interprete de mandatos del sistema operativo los trata de forma diferente.
Para utilizar CHGLIBL deberíamos hacer CHGLIBL LIBL(&LIB1 &LIB2 ..... &LIBn), o sea utilizar tantas variables como bibliotecas contenga la variable &USRLIBL y eso complicaría aun mucho más el código.

Arrancar registro por diario automaticamente

Como arrancar automáticamente el registro por diario de los objetos creados en una biblioteca.

Para ello debemos crear la especial área de datos QDFTJRN en nuestra biblioteca, MYLIB por ejemplo. Los datos de este área de datos informan al sistema operativo que diario debe utilizar para arrancar el registro por diario de los nuevo objetos creados en la biblioteca MYLIB si los objetos son "journalizables" (de tipos de objeto * FILE, DTAARA * y * DTAQ) se añaden a la biblioteca.
Cuando se crea un objeto en la biblioteca el sistema operativo busca este área de datos, en la misma biblioteca, y utiliza los datos que contiene para decidir si el registro por diario debe ser arrancado para ese objeto. Esto solo funciona en sistemas con la versión V5R4 del OS400, en V6R1 tenemos otra manera de hacerlo (STRJRNLIB) .

Como ejemplo para arrancar el registro por diario de TODOS los archivos creados en la biblioteca MYLIB, deberíamos de ejecutar los siguientes mandatos:

• CRTDTAARA DTAARA(MYLIB/QDFTJRN) TYPE(*CHAR) LEN(100)
• CHGDTAARA DTAARA(MYLIB/QDFTJRN (1 10)) VALUE(MYLIB)
• CHGDTAARA DTAARA(MYLIB/QDFTJRN (11 10)) VALUE(MYJRN)
• CHGDTAARA DTAARA(MYLIB/QDFTJRN (21 10)) VALUE(*FILE)
• CHGDTAARA DTAARA(MYLIB/QDFTJRN (31 10)) VALUE(*ALLOPR)

Para crear los receptores de diario y el diario de una biblioteca MYLIB, podemos utilizar mi utilidad CHGSTSJRN, o ejecutar los siguientes mandatos.

• CRTJRNRCV JRNRCV(MYLIB/JRNRCV0001) THRESHOLD(10000)
• CRTJRN JRN(MYLIB/MYJRN) JRNRCV(MYLIB/JRNRCV0001) MNGRCV(*SYSTEM) DLTRCV(*YES)

Más información en el documento de IBM Journaling at object creation on DB2 for iSeries

¿El AS400 ha muerto?

Con el último cambio de nombre del AS400, que ha hecho IBM, parece que finalmente conseguirá su objetivo de hacerlo desaparecer por "mimemitación" con el entorno.

Repasemos:

1. AS/400: AS quiere decir Application Server (¡¡que no estaba tan mal!!)
   
2. AS/400: AS de Advanced Series.
   
3. AS/400e
   
4. eServer
5. iSeries
6. System i
7. Power Systems

Pero realmente el ultimo cambio implica que ya no sabremos diferenciar, por el nombre, un sistema con sistema operativo AIX de otro con el i5/OS (antes llamado OS400), esto finalmente implica que desaparece virtualmente nuestro AS400 y se convierte en un mero "plugin" del nuevo hardware controlado por una consola HMC que no funciona en i5/OS.

Pros:


(espacio intencionadamente en blanco)



Contras:


(espacio intencionadamente en blanco)

Nota: Que cada cual lo rellene con sus opiniones, aunque realmente tardaremos unos años en ver el resultado de tanto "marear la perdiz".

Entradas de direccionamiento

¿Para que sirven las entradas de direccionamiento?

En anteriores artículos he hecho referencia a las entradas de direccionamiento de un subsistema (Memoria para subsistema, Asignar prioridad automáticamente y Memoria para trabajos batch), en este artículo intentaré explicar como funcionan y para que las podemos utilizar.

Utilizaremos como ejemplo las entradas del subsistema QBATCH. Para verlas hemos de utilizar el mandato DSPSBSD SBSD(QBATCH) y seleccionaremos la opción 7. Routing entries:En este subsistema (de ejemplo) tenemos 4 entradas de direccionamiento y la secuencia en que se ejecutaran (Seq Nbr), las entradas hacen referencia a:

• QIGC: Para trabajos que utilicen el sistema DBCS (Double-byte character set), si esta instalado.
• QS36EVOKE: Para trabajos que utilizan el entorno compatible con IBM S/36.
• QCMD38: Para trabajos que utilizan el entorno compatible con IBM S/38.
• *ANY: Para el resto de trabajos del subsistema.

Para entender como el sistema asigna una clase al trabajo y los atributos de ejecución del mismo, deberíamos tener claro como el sistema operativo somete un trabajo y que parámetros utiliza, para ello nada mejor que leer el articulo Someter trabajos batch.

Enrevesado, no?, veamos ahora como se asigna la clase:

1. El trabajo de control del subsistema QBATCH (WRKJOB JOB(QSYS/QBATCH) lee, de la cola/s de trabajos que tiene asignada, los trabajos que están pendientes por ejecutar.
2. Recupera el valor del parámetro RTGDTA del trabajo, por omisión QCMDB.
3. Ira comparando el valor RTGDTA del trabajo con el valor de CMPVAL de las entradas de direccionamiento, en el orden de la secuencia indicada en "Seq Nbr".
4. Cuando encuentre una entrada de direccionamiento que sea igual, ejecutará el programa que se indica en la entrada de direccionamiento. Como el valor por omisión de RTGDTA es QCMDB, la entrada de direccionamiento a asignar es la 9999, que tiene el valor especial *ANY y por tanto llamará al programa QSYS/QCMD, pasando como parámetro el mandato indicado en el parámetro CMD del SBMJOB.
5. En la entrada de direccionamiento puede definirse en que posición del parámetro RGTDTA, debe empezar a comparar (CMPVAL), con lo que se amplían las posibilidades de asignación.
   
6. Entonces asignará, al trabajo, los valores de los atributos de ejecución indicados en la clase asignada a dicha entrada. Por omisión, en nuestro ejemplo, asignará los valores de la clase QSYS/QBATCH, o sea RUNPTY(50) y TIMESLICE(5000), para ver los valores de la clase podemos utilizar el mandato DSPCLS CLS(QSYS/QBATCH).
7. También asignará el trabajo al pool de memoria donde se ejecutara, esto se indica en el parámetro POOLID de la entrada de direccionamiento, ver también Memoria para subsistema.

De esta forma el sistema asignará al trabajo los atributos de ejecución de la clase QBATCH a los trabajos que contengan cualquier cadena de caracteres en el campo RTGDTA que no sean igual a: QIGC, QS36EVOKE o QCMD38. Es obvio explicar que pasaría si contiene alguno de estos valores.

Nota: Después de lo visto habréis podido deducir que el interprete de mandatos del OS400 es el programa QSYS/QCMD, tiene similitud con el interprete de comandos de windows que es c:\windows\system32\cmd.exe; y del entorno S/38 es el QSYS/QCL.

Analicemos, ahora, las entradas de direccionamiento del subsistema QINTER:

Vemos algunas diferencias, pero creo que ya podéis deducir que:

• QCMDI es para llamar al interprete de mandatos del OS400, pero con la clase QINTER, que asigna por omisión los atributos de ejecución QGPL/QINTER, o sea RUNPTY(20) y TIMESLICE(2000) para trabajos interactivos. Notar la diferencia entre los valores QCMDInteractivo y QCMDBatch. Es por esta entrada de direccionamiento por donde se arrancarán nuestras sesiones 5250.
  

• 525XTEST esta es una entrada muy especial para ejecutar un programa de test de las pantallas 5250. Esto se conseguía pulsando una combinación de teclas al encender el terminal y aparecía una pantalla de test (programa QARDRIVE).
• El resto de trabajos entrarán con *ANY, que por omisión utiliza la misma clase QINTER.

En este ultimo punto podríamos implementar un sencillo truco para evitar que usuarios "listillos" sometan trabajos batch por el subsistema QINTER, con la "sana" intención de que sus trabajos obtengan más prioridad en la ejecución y terminen antes, pero claro a costa de que consuman más recursos del sistema. Para ello lo único que deberíamos hacer, es cambiar la clase de la entrada de direccionamiento *ANY, del subsistema QINTER, para asignarle la clase QBATCH, en lugar de la clase QINTER:

CHGRTGE SBSD(QSYS/QINTER) SEQNBR(9999) CLS(QSYS/QBATCH)

De esta forma cuando realizan el SBMJOB, como el valor RTGDTA es QCMDB, se les asignara la prioridad de un trabajo batch en lugar de interactivo. Esto no lo soluciona todo, ya que no podremos evitar que consuman memoria del mismo pool que el asignado a los trabajos interactivos en el subsistema QINTER, habitualmente *INTERACT.

Colas de trabajos

Cuando hemos de controlar la ejecución de los trabajos batch en el sistema, normalmente usamos los subsistemas, las colas de trabajo y las prioridades en la cola de trabajo (parámetro JOBPTY del CHGJOB).
Este articulo es para entender mejor como un subsistema trabaja con las colas de trabajo que tiene asignadas y como podemos crear colas de trabajo especificas para ciertas tareas. Para ello explicare algunos conceptos relacionados con las colas de trabajo, en los ejemplos nos basaremos en el sistema QBATCH (DSPSBSD SBSD(QBATCH) y opción 6).

• El subsistema tiene un numero de trabajos máximo que puede ejecutar, se cambia con el mandato CHGSBSD SBSD(QBATCH) MAXJOBS(*NOMAX), en este ejemplo estamos diciendo al sistema, que puede ejecutar un numero ilimitado de trabajos en el subsistema, bueno el limite es el rendimiento del sistema, ya podríamos llegar a colapsarlo.
  
• El subsistema tiene colas de trabajo asignadas y estas tienen un numero de secuencia, o sea el sistema primero mira si hay trabajos en la cola de trabajos de la secuencia 10, después de la 20, ..., hasta la 9999.
• Cada cola de trabajos, asignada a un subsistema, tiene también un numero máximo de trabajos que puede ejecutar. El numero máximo de trabajos de una cola de trabajos se puede cambiar con el mandato CHGJOBQE.
• Para complicarlo un poco más, también pueden definirse en cada cola de trabajo el numero de trabajos máximo por prioridad del trabajo, aunque por lo que he podido ver se usa poco.
• Si el sistema encuentra un trabajo en la cola de trabajos, y no hay ejecutándose el numero máximo de trabajos activos de esa cola y el subsistema tiene menos trabajos que el máximo que tiene definido para el subsistema, entonces entraran tantos trabajos de esa cola hasta que no queden trabajos en la cola o hasta que el subsistema tenga el numero máximo de trabajos.
• Una cola de trabajos puede estar definida en dos subsistemas diferentes, pero solo se asigna al primer subsistema que arranca.
• Una cola puede no estar asignada a algún subsistema (o el subsistema no esta activo), en ese caso nunca entran trabajos de esa cola.
  

Ejemplo1:

• En este ejemplo supongamos que el subsistema QBATCH puede ejecutar un numero ilimitado de trabajos (*NOMAX).
• En este caso podríamos tener el numero máximo de trabajos ejecutándose de todas las colas porque 10+1+4 = 15.
• Si en la cola QBATCH hay 17 trabajos solo se ejecutaran como máximo 10, aunque el subsistema no este ejecutando ningún trabajo del resto de colas.

Ejemplo2:

Igual que en el Ejemplo1 pero con dos colas más (con *NOMAX) y el subsistema QBATCH puede ejecutar 50 trabajos al mismo tiempo como máximo:

• Supongamos que se están ejecutando 3 trabajos de la cola QBATCH y llegan de golpe 160 trabajos a la cola QSRCTXT, de estos entraran 47 trabajos, ya que 3+47=50 es el numero máximo de trabajos activos en el subsistema, quedando el resto en cola.
• Si en ese momento llega un trabajo por la cola QBATCH1X1, esté no podrá entrar hasta que finalice algún trabajo.
• Si finaliza un trabajo que ha entrado por la cola QSRCTXT, entonces entraría el trabajo de la QBATCH1X1, porque tiene una secuencia mas baja que la cola QSRCTXT, cuando termine otro, si no hay ninguno en las colas de las secuencias inferiores a la QSRCTXT, irán entrando más trabajos a medida que finalicen.
• Si mientras llega algún trabajo a la cola QBATCH pasaría antes que los de la QBATCH1X1, ya que su numero de secuencia es menor.

Recomendaciones:

• Si queremos asignar a una cola un numero de trabajos *NOMAX, mi recomendación es ponerla al final, y deberíamos solo enviar a esa cola trabajos de ejecución muy rápida, para no colapsar la cola ni el sistema.
• Prefiero asignar al subsistema un numero máximo de trabajos ilimitado (*NOMAX), pero debemos vigilar que las colas *NOMAX no nos puedan colapsar el sistema, en ese caso no nos quedara más remedio que asignar un numero máximo de trabajos al subsistema que nos pueda soportar el sistema (CHGSBSD), habitualmente empezaríamos por asignar la suma del numero máximo de trabajos de cada cola más un numero n de trabajos, si vemos que es demasiado para el sistema, ir reduciendo el numero máximo de trabajos activos.
  

Cola de trabajos independiente

A veces hemos tenido la necesidad de aislar ciertos tipos de trabajo para que se ejecuten en orden secuencial; como la cola de trabajos QBATCH (asignada al subsistema QBATCH), puede, por omisión, ejecutar varios trabajos simultáneamente, no podemos utilizar esa cola para ejecutar trabajos secuencialmente.

Para crear una cola de trabajos independiente y asignarla al subsistema QBATCH, para que ejecute trabajos de uno en uno seguiremos los siguientes pasos:

1. Crear una nueva cola de trabajos donde someteremos los trabajos que queramos ejecutar secuencialmente:
2. CRTJOBQ JOBQ(QGPL/QBATCH1X1) TEXT('Job queue for run one by one')
3. Asignar esa nueva cola de trabajos al subsistema QBATCH:
4. ADDJOBQE SBSD(QBATCH) JOBQ(QGPL/QBATCH1X1) MAXACT(1) SEQNBR(15)
5. El numero de secuencia (SEQNBR) sera el orden de cola que el subsistema utilizará para ejecutar los trabajos.
6. Puede ser necesario ampliar el numero máximo de trabajos que se ejecutan en el subsistema QBATCH, y que por omisión es *NOMAX. Para comprobarlo DSPSBSD QBATCH opción 1 y ver el numero máximo de trabajos en el subsistema. Para cambiarlo usar CHGSBSD SBSD(QSYS/QBATCH) MAXJOBS(jobs que existan + 1)
   
7. También podemos modificar las descripciones de trabajo, que creamos conveniente, para que se sometan siempre por esa cola de trabajos:
8. CHGJOBD JOBD(mylib/myjobd) JOBQ(QGPL/QBATCH1X1)

Cola de mensajes QSYSMSG

El sistema operativo del AS400 tiene una función oculta y especial para enviar los mensajes que requieran alguna acción por parte del usuario (operador o administrador), a la cola de mensajes especial QSYSMSG. Esta cola de mensajes no existe al instalar el sistema operativo y debemos de crearla manualmente:

CRTMSGQ MSGQ(QSYS/QSYSMSG) TEXT('Special system messages queue') MSGQFULL(*WRAP)

Otorgamos la propiedad a QSECOFR: 

CHGOBJOWN OBJ(QSYS/QSYSMSG) OBJTYPE(*MSGQ) NEWOWN(QSECOFR)

Con esto los mensajes de cierta gravedad se escribirán en la cola de mensajes QSYSMSG, ademas de en la cola QSYSOPR. Esto puede facilitarnos la monitorización de mensajes del sistema.

Podéis encontrar información sobre esta funcionalidad en el IBM Information Center

Controlar trabajos batch

Para averiguar la duración de un trabajo batch, que no ha dejado rastro (joblog), podemos utilizar el histórico del sistema para ver cuando se arranco, cuando finalizo y con que código.

Para ello debemos utilizar el mandato DPSLOG, por ejemplo para ver la duración del trabajo MYJOB del usuario QUSER, del cual no sabemos el numero de trabajo, pero si que se debió ejecutar el día 30 de abril por la tarde:

DSPLOG PERIOD((120000 300409)) JOB(QUSER/MYJOB) MSGID(CPF1124 CPF1164)

Con esto obtendremos el siguiente resultado:El message id CPF1124 nos indica la hora de arranque del trabajo y el CPF1164 la hora de terminación y con que código; para ver el código hemos de situar el cursor sobre la línea del mensaje y pulsar F1, con ello podremos ver la siguiente pantalla:

Ahí podremos ver el código de terminación, en el ejemplo 0.

• Si un trabajo tiene código de terminación 10, puede que haya terminado correctamente.
• Si pulsamos Av.Pag. podremos ver la razón de todos los códigos de terminación.
• Si pulsamos la tecla F6 imprimiremos este mensaje en nuestro el spool.
• Si volvemos a ejecutar el mismo mandato DSPLOG, pero sin el parámetro MSGID, veremos todos los mensajes que el trabajo ha enviado al histórico del sistema.
• Si pulsamos la tecla F9 sobre el mensaje podremos ver que programa ha grabado el mensaje (a veces toda ayuda es poca):

• Tener en cuenta que el histórico del sistema se limpia automáticamente con las opciones de limpieza del sistema (GO CLEANUP), por omisión solo conserva los últimos 15 días.

Otra forma de controlar los trabajos es utilizar mi utilidad HSTJOBLOG.

Caja de busqueda en el blog

He añadido una caja de Google en el blog para facilitaros la búsqueda de temas en el blog.

Espero que os sea útil

Someter trabajos batch

Para entender como el sistema somete un trabajo, explicaré cual es el procedimiento básico que utiliza el OS400.Para someter un trabajo utilizamos el mandato SBMJOB, indicando en el parámetro CMD el programa, o mandato, que queremos ejecutar, grabando una entrada en la cola de trabajo:

• Es conveniente indicar un nombre de trabajo (JOB) que nos ayude a controlarlo, ya que por omisión utilizara el valor *JOBD, o sea utilizara el nombre de la descripción de trabajo para todos los trabajos que sometamos sin nombre.
  
• El trabajo ira a la cola de trabajo (JOBQ) que este especificada en el SBMJOB, por omisión tiene *JOBD que nos indica que cogerá el valor de la cola de trabajo especificada en la descripción de trabajo, indicada en el parámetro JOBD.
  
• El parámetro JOBD nos indica la descripción de trabajo que utilizará, por omisión tiene el valor *USRPRF, este nos indica que cogerá el valor de la descripción de trabajo del usuario que esta sometiendo el trabajo. Esto se define en el perfil del usuario (DSPUSRPRF parámetro JOBD).
• El valor del parámetro JOBD(*USRPRF) puede forzarse para tener otro valor, al usar el parámetro USER del SBMJOB (por omisión *CURRENT), que indica que usara otro usuario para ejecutar el trabajo, evidentemente hemos de estar autorizados al perfil de usuario a utilizar ya que puede suponer un agujero de seguridad.
• Podemos definir la prioridad que tendrá nuestro trabajo en la cola de trabajos (JOBPTY) y/o en la cola de salida (OUTPTY). Por omisión utiliza el valor *JOBD recuperando este valor de la descripción de trabajo que habitualmente es 5. Podemos indicarle otro valor que puede ir de 1 (alta prioridad) a 9 (baja prioridad), de todas formas tenemos un limite que esta indicado en el parámetro PTYLMT de nuestro perfil de usuario y que por omisión es 3.
• Con el parámetro OUTQ definimos a que cola de salida irán los listados que genere nuestro trabajo, por omisión es *CURRENT con lo que utiliza la cola de salida que tienen asignada el trabajo desde donde se ejecuta el SBMJOB.
• Otro parámetro muy importante es INLLIBL (Initial library list) donde indicaremos en que bibliotecas y en que orden el sistema operativo debe buscar los objetos (programas, archivos, áreas de datos, etc..) que se utilicen en el trabajo. Por omisión tiene el valor *CURRENT y por tanto la lista de bibliotecas sera la misma que la del trabajo desde donde se ejecuta el SBMJOB. Otro valor que puede tener el parámetro INLLIBL, y muy recomendable utilizar, es *JOBD que utilizara la lista de bibliotecas definida en la descripción de trabajo que utilicemos para someter el trabajo.
• El parámetro RTGDTA (Routing data) es importante para asignar los atributos de ejecución del trabajo, esta relacionado con las entradas de direccionamiento que explicaré en un próximo articulo.
  
• Después vendrían los parámetros relacionados con el log del trabajo: LOG, LOGCLPGM, LOGOUTPUT, JOBMSGQMX. Todos ellos tienen por omisión *JOBD. Habitualmente para que un trabajo deje rastro para que podamos ver los que se ha ejecutado es utilizando los valores LOG(4 00 *SECLVL) LOGCLPGM(*YES).

Para el resto de parámetros y valores os recomiendo leer con más calma la ayuda del propio mandato SBMJOB (SBMJOB + F4+F1+F2, F14 para imprimirla) para entrar en más detalle.

Para mucha más información:
Gestión de Trabajos en el IBM iSeries InformationCenter
Manual de IBM iSeries Systems management and Work management

Intercambio archivos entre AS y PC

En este documento se explican los tipos de intercambios de archivos más comunes entre AS400 y PC; deben servir solo como referencia y adaptar los parámetros según nuestras necesidades:

Archivos formato texto ("planos" de 1 solo campo):
De AS400 a PC, en un directorio ubicado en un servidor de archivos (por ejemplo):
CPYTOIMPF FROMFILE(mylib/myfile) TOSTMF('/QNTC/myserver/mysharedfolder/mytextfile.TXT') MBROPT(*REPLACE) STMFCODPAG(*PCASCII) RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM(*NONE)

Para generar ficheros sin caracter CR (retorno carro) y solo LF (final de linea):
CPYTOIMPF FROMFILE(mylib/myfile) TOSTMF('/home/temp/myascii.txt') MBROPT(*REPLACE) FROMCCSID(37) STMFCODPAG(*PCASCII) RCDDLM(*LF) DTAFMT(*DLM) STRDLM(*NONE) STRESCCHR(*NONE) RMVBLANK(*TRAILING)
FLDDLM('')

Ejemplo para subir un archivo plano de PC (desde un servidor) al AS400:

1. Primero averiguar la longitud del archivo TEXTO.TXT, por ejemplo en este caso 132.
2. Crear un archivo de destino en el AS400:
3. CRTPF FILE(MYLIB/TEXTO) RCDLEN(132)
4. Copiar el archivo:
5. CPYFRMIMPF FROMSTMF('/QNTC/myserver/mysharedfolder/mytextfile.TXT') TOFILE(MYLIB/TEXTO) MBROPT(*REPLACE) RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM(*NONE) RMVBLANK(*NONE) FLDDLM(*TAB)

Para convertir y copiar un archivo de AS400 a formato CSV (para Excel y/o Access) y dejarlo en la carpeta de un servidor de archivos (p.e. WinNT) puedes utilizar el mandato:

CPYTOIMPF FROMFILE(mylib/myfile) TOSTMF ('/QNTC/myserver/mysharedfolder/mycsvfile.CSV') MBROPT(*REPLACE) STMFCODPAG(*PCASCII) RCDDLM(*CRLF) DTAFMT(*DLM) STRDLM('"') FLDDLM(';')

Tener en cuenta que la ruta "/QNTC/myserver/mysharedfolder/" solo funciona si:

1. La carpeta compartida del servidor //myserver/mysharedfolder es accesible desde la red.
   
2. El servicio Netserver del AS400, esta correctamente configurado.
3. El usuario y la contraseña que lanza el mandato CPY???IMPF es igual en el AS400 y en el servidor de archivos.

Comprimir archivos en IFS

Para comprimir un archivo ASCII ubicado en el IFS del AS400 podemos utilizar el comando jar en una sesión del shell de UNIX en el AS400.

Como hacerlo, pues ahí va un ejemplo:

1. Desde la línea de mandatos tecleamos STRQSH, o simplemente QSH.
2. En la pantalla de "QSH Command Entry" teclear:
3. jar -cfM /home/compress_folder/myfile.zip /home/myfolder/myfile1.txt

Si queremos comprimir todo el contenido de un directorio:

1. jar -cfM /home/compress_folder/mydirectory.zip /home/folder_to_compress

Si queremos comprimir varios archivos, dentro de un CL:

1. PGM
2. ...
   
3. QSH('jar -cfM /home/compress_folder/myfile.zip /home/myfolder/myfile1.txt /home/myfiles/myfile2.csv')
4. ...
   
5. ENDPGM

Take Control of DB2 for i Performance with V6R1 System i Navigator

Articulo que hace referencia a como controlar el rendimiento de las aplicaciones de AS400 que usan SQL:

Take Control of DB2 for i Performance with V6R1 System i Navigator

y otro articulo relacionado:

Making the Best Use of V6 SQL OLAP Functions

Monitorizar F3 en mandato

Como controlar si un usuario a salido pulsando F3 o F12 de la ejecución de un mandato en un programa CL interactivo.

Para ello solo hemos de monitorizar el mensaje CPF6801 en el programa, por ejemplo:

PGM
....
?DSPLOG                   
MONMSG MSGID(CPF6801) EXEC(GOTO END)
...
END:
RETURN
ENDPGM  

Calcular tamaño objeto

Para obtener el tamaño de un objeto de más de 10 Gbytes, con DSPOBJD a *OUTFILE, hay que realizar la siguiente operacion ODSIZU * ODBPUN, ya que el campo ODOBSZ esta definido 10,0 Packed y no admite objetos mayores.

Ejecutar comandos DOS desde AS400

Para poder ejecutar un programa de pc desde un programa CL del AS400, hemos de ejecutar los mandatos STRPCO y STRPCCMD.

Podemos por ejemplo ejecutar un .BAT o un .CMD pasándole parámetros (solo de ida)

Un ejemplo para abrir la web de Google con el navegador Interner Explorer:
STRPCO
MONMSG MSGID(IWS4010)
STRPCCMD PCCMD('"C:\Archivos de programa\Internet Explorer\IEXPLORE.EXE" www.google.com')

Otro ejemplo para ejecutar el programa c:\Myscripts\program1.BAT pasándole un parámetro:
DCL VAR(&PCCMD) TYPE(*CHAR) LEN(512)
DCL VAR(&VAR1) TYPE(*CHAR) LEN(256)
CHGVAR VAR(&VAR1) VALUE('VALOR1')
CHGVAR VAR(&PCCMD) VALUE('C:\Myscripts\program1.BAT' *BCAT &VAR1)
STRPCO
MONMSG MSGID(IWS4010)
STRPCCMD PCCMD(&PCCMD)

Despues deberiamos controlar la ejecucion del programa

Bibliotecas productos instalados

Como averiguar en que bibliotecas están instalados los productos del sistema OS400.

Para ello podemos utilizar el mandato DSPSFWRSC con salida a pantalla, impresora o fichero, si ejecutamos DSPSFWRSC OUTPUT(*) nos aparecerá la siguiente pantalla:

Si pulsamos F11=Display libraries/releases se visualizará la columna "Library" con el nombre de la biblioteca del producto de la primera pantalla.

Esto nos puede servir cuando hagamos limpieza de bibliotecas y saber cuales corresponden a productos del limpieza, no todas las que empiezan por Q pueden ser del sistema.

También hemos de tener en cuenta que los productos, cada vez más, utilizan directorios del IFS.

QPFRADJ=0 ???

Bueno, bueno, como he visto que mi tocayo Martín, de SIDRA400, se ha tomado la molestia de explicarnos, con más detalle el valor de sistema QPFRADJ, ya que yo lo daba por supuesto para no extenderme, os paso el enlace de su artículo para que podáis ampliar el conocimiento en el tema del ajuste de rendimiento del sistema.

QPFRADJ=0 ???

¡¡ Cuidado no entréis en un bucle de blogs !!

Corregido bug utilidad CPYJOBSPL

Se ha corregido un pequeño bug cosmético de la utilidad CPYJOBSPL


Copiar archivos spool

Hitos históricos AS/400

Hitos históricos del AS/400, iSeries, System i y Power Systems (extraído del boletín de Common Europe España):

1988: Junio 21: IBM anuncia el AS/400, la abreviatura de Application Server/400, que junto con más de 1000 paquetes de software es el anuncio con más aplicaciones simultáneas de la historia de los ordenadores. (En el momento en que el primer AS/400 se envió, más de 2500 aplicaciones estaban disponibles)

1989: Se anuncia el B70, el nuevo modelo de la gama alta junto con impresoras matriciales de alta velocidad para ser usadas con la familia AS/400

1990: La línea de AS/400 se amplía con 2 procesadores de bajo coste diseñados para pequeños negocios o departamentos para grandes empresas

1991: Se anuncia un nuevo modelo de punto de entrada AS/400 junto con la V2R1 de OS/400 por 12.000 $

1992: IBM envía su AS/400 número 200.000, un 9406 modelo E35 y se instala en una de las principales empresas de distribución de los Países Bajos: Heineken

1993: Un nuevo modelo F que proporciona hasta un 60% de potencia y ofrece una mejora en precio/rendimiento de un 26%

1994: IBM envía su AS/400 número 250.000 modelo F80 a la compañía Coca Cola Company en Bélgica

1994: IBM presenta la nueva generación de AS/400 llamada AS/400 Advanced Series

1995: Se anuncia el AS/400 Advanced Portable, una versión compacta y de bajo coste del AS/400

1995: IBM convierte el procesador del AS/400 de CISC a RISC

1996: La compañía lanza el AS/400 Advanced Entry system, el primero de ellos (y el número 400.000 de los AS/400 vendidos) es presentado en Rochester a Grez LeMond, el ganador por 3 veces del tour de Francia y además un pequeño empresario.

1996: El OS/400 (V3R2 y V3R7) se convierte en el primer sistema operativo que es certificado como Year 2000 ready por la ITAA (Information Technology Association of America)

1997: IBM anuncia la nueva familia de AS/400e servers para ayudar a las pequeñas empresas a aprovechar las ventajas de las oportunidades de negocio en Internet

1998: Se introduce la tecnología SOI (Silicon-on-insulator), marcando un avance fundamental en la manera de construir los chips.

1998: IBM entrega un AS/400 a un cliente cada 12 minutos de cada día laborable durante el año 1998.

1999: El AS/400 es el ordenador de carácter comercial multi usuario más popular con más de 700.000 sistemas instalados en 150 países.

1999: Se anuncia la V4R4 de OS/400 con más de 3,2 millones de nuevas líneas de código escritas principalmente para e-business

2000: El AS/400 cambia de nombre y se convierte en IBM eServer iSeries e IBM anuncia el primer servidor de aplicaciones Web en la familia eServer.

2000: IBM comienza el lanzamiento de la nueva línea de AS/400e con la primera producción mundial de microchips hechos de transistores SOI y cableado de cobre.

2001: World Access, un proveedor de servicios de telecomunicaciones, compra el sistema eServer iSeries más grande (un i840) para procesar facturas para más de 100 millones de llamadas telefónicas al día.

2002: IBM anuncia el microprocesador POWER4. El sistema i890 de 32 vías ejecutándose en V5R2 dobla la capacidad de proceso de la anterior línea de producto iSeries.

2003:Como parte de una amplísima transformación de la familia iSeries en más de una década, IBM anuncia el 825 y el 870 junto al 890 en la gama alta. Usados por más de 200.000 clientes alrededor del mundo, el IBM eServer iSeries es uno de los servidores más populares de la industria.

2004: IBM anuncia el eServer i5, los primeros sistemas en ser gestionados por los microprocesadores POWER5. También cambia el nombre de OS/400 a i5/OS y libera la V5R3.

2005: IBM anuncia la estrategia OnDemand y comienza a lanzar al mercado las herramientas de virtualización e integración.

2006: En Enero, la compañía saca al mercado la línea IBM System i5 con procesadores POWER5+ y la V5R4 de i5/OS pero después elimina el 5 del i5 comenzando la era System i.

2007: IBM anuncia los microprocesadores POWER6 y ofrece unos nuevos modelos System i 515 y 525 Express con el precio basado en número de usuarios.

2008: i5/OS se convierte en un sistema operativo soportado por las soluciones IBM BladeCenter

2008: El System i se unifica con el System p para convertirse en Power Systems. El nombre del sistema operativo cambia a IBM i