• EMUFRAME

    EMUFRAME

    Desde 2015, enseñando sobre el sistema operativo z/OS de IBM en esta web.

    z/OS se utiliza en máquinas llamadas Mainframe y es utilizado por grandes empresas (bancos, aseguradoras, hoteles, etc.).

    Aquí aprenderás a instalar y configurar productos relacionados con z/OS.

     

  • Emulación de Mainframe y z/OS

    Emulación de Mainframe y z/OS

    Para realizar el contenido, utilizo el producto de IBM llamado z/Development and Test Environtment Personal Edition.

    Este software permite emular un Mainframe y así poder utilizar z/OS para aprender.

     

  • z/OS - ADCD

    z/OS - ADCD

    ADCD es una distribución de z/OS que contiene productos de IBM como IMS, DB2, CICS, ZOWE, TWS, NetView, System Automation, etc.

    Así tenemos un entorno de desarrollo o de aprendizaje, como es mi caso, muy completo.

     

z/OSMF z/OS Connect EE z/OS Explorer - Mejorar rendimiento JAVA en zPDT

z/OSMF z/OS Connect EE z/OS Explorer - Mejorar rendimiento JAVA en zPDT

Adjuntos:
Descargar este archivo (IZUCACHE.txt)IZUCACHE[Paso para cargar Snapshot]0.2 kB
Descargar este archivo (JCACHER.txt)JCACHER[Rexx para crear snapshots Java]2 kB

Al utilizar emulador zPDT, las aplicaciones que utilizan Java tienen un rendimiento inferior al que tendrían en una máquina real. Este problema puede ocurrir con el arranque de tareas como: z/OSMF, z/OS Connect, z/OS Explorer…

Por suerte, hay personas que ya han investigado esto y han tratado de mejorar el tiempo de arranque de estas tareas.

Como esta entrada está basada en la documentación que han aportado esas personas que han investigado este problema, me gustaría que, igual que estáis leyendo este contenido, les deis una oportunidad y leáis su trabajo:

THE MAIN FRAME Autor: Greg Keuken

Turbo Java in ADCD

ColinPaice – Autor: Colin Paice

Why do they ship java products on z/OS with the handbrake on? And how to take the brake off.

Taking the brakes off ZFS on z/OS – move it to OMVS

El proceso consiste en configurar la caché de Java para que se guarde en disco y cargar ese “snapshot” antes del arranque de la tarea. De esta forma, se reduce el tiempo de arranque.

También hay otra configuración adicional (aportada por Colin Paice) que consiste que la tarea zFS se ejecute bajo OMVS (esto es posible desde z/OS 2.2). Esto debería mejorar el rendimiento de aquellas tareas que utilizan ficheros zFS en puntos de montaje de OMVS.

En mi caso, si he notado una mejora gracias a esto en el sentido de velocidad de arranque de la tarea o en que el sistema no se quede “pillado” por el uso de CPU o de “IOs”.

zFS running in the z/OS UNIX address space

Voy a explicar cómo he hecho la configuración y luego añadiré unos pantallazos en los que se puede ver la diferencia de tiempos de arranque, según la configuración.

En el caso de esta instalación, la caché ya estaba configurada en z/OSMF en este fichero:

/global/zosmf/configuration/local_override.cfg 

01 watermark

 

Xshareclasses:cacheDir=/javasc/izusvr1,name=izusvr1cache

02 watermark

 

También podemos comprobar en el arranque de la tarea z/OSMF que esta configuración está en uso.

03 watermark

 

Una vez tenemos configurada esta parte y hemos arrancado la tarea, debemos sacar un “snapshot”. Esto se puede hacer en cualquier momento antes de parar el sistema. Por ejemplo, ejecutar el siguiente job de forma manual o que se lance de forma automática cuando empezamos a parar el sistema.

Para hacer esto, yo uso una utilidad REXX (creada por Greg Keuken) llamada JCACHER:

zPDT_Pub - JCACHER

Simplemente, lo guardé en una librería haciendo el siguiente nombre ya que mi caché se llama izusvr1:

sfwc.4 = 'zosmf'

Por:

sfwc.4 = 'izusvr1'

04 watermark

 

El siguiente job crea el snapshot (se puede descargar al principio de la entrada):

05 watermark

 

06 watermark

Finalmente, tenemos que añadir un paso previo en el arranque de la tarea para cargar el “snapshot”.

Habría que añadir este paso en la tarea IZUSRV1.

//STEP1 EXEC PGM=IRXJCL,PARM='JCACHER izusvr1 restoreFromSnapshot'

//SYSEXEC DD DSN=IBMUSER.REXX,DISP=SHR                            

//SYSTSPRT DD SYSOUT=*  

 

07 watermark

 

Después de un IPL, cuando arranquemos la tarea, deberíamos ver el siguiente mensaje:

Attempting restoreFromSnapshot for: izusvr1

JVMSHRC698I Non-persistent shared cache "izusvr1cache" has been restored successfully from the snapshot

08 watermark

 

El siguiente cambio que podemos realizar es hacer que ZFS se ejecute por OMVS.

El cambio no se puede hacer de forma dinámica. Es necesario hacer IPL.

Antes de realizarlo, debemos comprobar a qué cosas de nuestro sistema puede afectar. En mi caso, es un sistema emulado de pruebas y el riesgo de realizar este tipo de cambios es mucho menor.

Para identificar si ZFS se está ejecutando en OMVS o no, usaremos el siguiente comando. Si en “ASNAME” aparece algún valor diferente a N/A, no se está ejecutando en OMVS.

D OMVS,PFS

09 watermark

 

Para realizar los cambios, he copiado BPXPRM00 desde ADCD.Z24C.PARMLIB a USER.Z24C.PARMLIB.

El primer parámetro que he añadido es:

KERNELSTACKS(ABOVE)

Esto sirve para tener más capacidad de hilos (threads). En el siguiente enlace hay una explicación sobre esto:

z/OS V2R2 z/OS UNIX Increase Kernel Thread Capacity Option KERNELSTACKS()

El segundo cambio es modificar la definición de ZFS para quitar el parámetro “ASNAME”.

FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS)

Por:

FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM)     

10 watermark

 

Una vez hecho el IPL, podemos comprobar el resultado con el comando (ASNAME = N/A):

D OMVS,PFS

11 watermark

 

El resultado del parámetro KERNELSTACKS(ABOVE) lo veremos con el comando (parámetro MAXIMUM THREADS):

D OMVS,STORAGE

12 watermark

 

La comparación de tiempos de arranque de z/OSMF.

Sin cargar el “snapshot” y sin el cambio del OMVS, tardó unos 262 segundos.

13 watermark

 

Cargando el “snapshot” y sin el cambio del OMVS, tardó unos 211 segundos.

14 watermark

 

Cargando el “snapshot” y con el cambio del OMVS, tardó unos 171 segundos.

15 watermark

 

Queda comprobado que, con estos cambios, la mejora es evidente.

En cuanto a ZOWE, el cambio en el ZFS no ha reducido el tiempo de arranque, pero si mejora la respuesta del sistema. Cuando se arranca ZOWE en el emulador, suele ocurrir que el sistema no responde mientras se produce el arranque (pueden ser unos 10 minutos).

También intenté configurar la caché y hacer snapshot en las tareas de ZOWE que usan Java, ya que son las que más tardan en arrancar, pero no afectó al tiempo de arranque. Quizá lo hice mal…

16 watermark

 

Los scripts que habría que modificar serían:

/Z24C/usr/lpp/zowe/components/api-mediation/bin/start.sh

/Z24C/usr/lpp/zowe/components/files-api/bin/start.sh

/Z24C/usr/lpp/zowe/components/jobs-api/bin/start.sh

Añadí lo siguiente:

-Xshareclasses:nonFatal \                                  

-Xshareclasses:groupAccess \                               

-Xshareclasses:cacheDirPerm=0777 \                         

-Xshareclasses:cacheDir=/javasc/zwe1ad,name=zwe1adcache \  

-Xscmx50m \                                              

-Xlp:objectheap:pagesize=1m,warn,pageable \     

-Xlp:codecache:pagesize=1m,pageable \            

17 watermark

 

Modificando el directorio de caché en cada tarea:

-Xshareclasses:cacheDir=/javasc/zwe1ad,name=zwe1adcache \

-Xshareclasses:cacheDir=/javasc/zwe1ac,name=zwe1accache \

-Xshareclasses:cacheDir=/javasc/zwe1ag,name=zwe1agcache \

-Xshareclasses:cacheDir=/javasc/zwe1ef,name=zwe1efcache \

-Xshareclasses:cacheDir=/javasc/zwe1ej,name=zwe1ejcache \

 

Quizá en el futuro vuelva a probar. Espero que os haya gustado esta entrada y os parezca interesante esta mejora de rendimiento.

 

 

 

Publish modules to the "offcanvs" position.