Cómo transferir datos desde IBM AIX hasta IBM z/OS

Este artículo analiza las posibles cuestiones que se deben afrontar al transferir aplicaciones XL C/C++ desde la plataforma IBM® AIX® hasta la plataforma IBM® z/OS® platform. También se analizan ideas y sugerencias para obtener una mejor performance de la aplicación en la plataforma z/OS después de finalizada la transferencia.

La transferencia de aplicaciones desde una plataforma hasta la otra no es siempre una transición indolora y perfecta. Muchas cuestiones pueden causar problemas en el proceso de la trasferencia. Sin embargo, es posible reducir y mitigar estos problemas, y hacer que el proceso de trasferencia sea más fácil y con menos errores, especialmente con un plan.

Después de trasladar la aplicación de una plataforma a otra, la aplicación debería ajustarse para obtener la máxima performance en la nueva plataforma. Generalmente, la nueva plataforma posee características y restricciones que la anterior no tenía. El ajuste a la nueva plataforma puede ayudar a obtener beneficios que no estaban presentes en la plataforma original, y sacar provecho del nuevo hardware.

Rajan Bhakta, Staff Software Developer, IBM

Rajan Bhakta trabaja para IBM. Hace cuatro años trabaja con IBM z/OS C/C++ test team experience, y además posee cuatro años de experiencia en el desarrollo de z/OS y IBM AIX C. Actualmente es el representante de ISO C Standards de Canadá, y el representante de C Standards para IBM en INCITS. Es además arquitecto técnico de los compiladores z/OS XL C/C++.



Zach Zylawy, Staff Software Developer, IBM

Zach Zylawy trabaja para IBM. Posee cuatro años de experiencia en el trabajo con IBM z/OS C/C++ test team experience, además de cinco años en el desarrollo de z/OS y IBM AIX C++.



18-02-2011

Visión general

Este artículo presenta sugerencias sobre cómo resolver algunas cuestiones comunes que se pueden presentar al transferir una aplicación C o C++ desde IBM® AIX® hasta la plataforma IBM® z/OS® . También se analizan las maneras de mejorar la performance de la aplicación en z/OS cuando esta ha sido transferida.

Los temas analizados en la sección dedicada a la transferencia son:

  • Dependencias externas
  • Código hardware específico
  • Dependencias de alineamiento
  • Formatos de punto flotante
  • Codificación de caracteres
  • Extensiones de idioma
  • DLLs
  • Niveles de idioma
  • Entornos de programación

Los temas analizados en la sección dedicada a la performance son:

  • Cuando optimizar
  • El tiempo de compilación en comparación con el tiempo de ejecución
  • Los modificadores del tiempo de compilación
  • El entorno del tiempo de ejecución
    • La interoperabilidad interidioma
    • Las responsabilidades del tiempo de ejecución
  • Los modificadores del tiempo de ejecución basados en los compiladores
  • Los modificadores del tiempo de ejecución basados en los sistemas
  • El uso de la memoria
  • Ayudas para la performance y la exactitud del nivel de fuente
    • Funciones integradas
    • Formatos de punto flotante
  • Tiempo de carga
    • DLPA (dynamic link pack area)
    • VLF/LLA (virtual look-aside facility/library lookaside)
  • Opciones del tiempo de ejecución
  • Performance I/O

La transferencia

Antes de comenzar el proceso de transferencia

La transferencia de cualquier aplicación no trivial desde una plataforma hasta la otra es por lo general bastante complicada. Sin embargo, prepararse antes de comenzar el proyecto de transferencia de AIX a z/OS hace el proyecto más sencillo y minimiza los errores del compilador en z/OS.

Nota: La mayoría de las sugerencias aplican a cualquier transferencia entre plataformas, no son específicas para una transferencia desde AIX hasta z/OS.

Atención de los mensajes del compilador

El primer y más sencillo paso que se debe realizar para transferir una aplicación desde AIX a z/OS es atender todos los mensajes de diagnóstico generados por el compilador sobre AIX. Aunque el comportamiento del programa podría aún corregirse con estas advertencias, la presencia de las mismas indica un posible problema que podría surgir cuando la aplicación es compilada en z/OS. Responder a las advertencias antes de realizar la trasferencia puede prevenir posibles problemas en z/OS, y evitar pasar tiempo eliminando errores para rastrear un problema.

Dependencias externas

Al realizar la trasferencia, usted también debe identificar si los archivos de cabecera o programas externos que no están disponibles en z/OS son llamados o utilizados por su aplicación, y si este es el caso, modificar el código fuente de la aplicación de forma adecuada.

Tipos de códigos

El segundo paso en la transferencia es localizar e identificar las áreas en su programa fuente que utilizan los siguientes tipos de códigos:

  • Código de hardware específico: cualquier código relacionado con aspectos de hardware que varían de una plataforma a otra. Por ejemplo, cualquier sentencia ASM (Assembly) debe cambiarse para ajustarse al idioma y la sintaxis de la plataforma destino ASM.
    • Orden de bytes ("Endian-ness") es el mismo entre AIX y z/OS, de modo que no es necesario realizar modificaciones al respecto.
  • Código de alineamiento específico: el diseño de la estructura puede variar entre AIX y z/OS. Por ejemplo, un campo de bits de longitud cero como el primer miembro en los resultados de AIX de diferente tamaño y alineamiento luego en z/OS. La estructura C que se observa en el Listado 1 tiene un alineamiento de cuatro, y un tamaño cuatro en AIX, sin embargo tiene un alineamiento de uno y un tamaño de uno en z/OS.
    • Este no es por lo general el problema, porque la mayor parte del código bien escrito no depende críticamente del tamaño y el alineamiento de la estructura.
    • La opción AGGR (aggregate) muestra el mapa global, que despliega el diseño de la estructura.
Listado 1. Código con alineamiento y tamaño diferentes en AIX y z/OS
struct A {
   int :0;
   char a;
};
  • Rangos en punto flotante: Los rangos de algunos tipos de punto flotante son diferentes en AIX y en z/OS. Por ejemplo, el tipo long double podría tener diferentes rangos, dependiendo del formato del punto flotante que usted utilice. Los formatos de punto flotante disponibles son también diferentes y serán analizados más adelante en el paper.
    • Este no es por lo general un problema salvo que se requieran precisión y resultados específicos.

Estos tipos de construcciones dependientes del hardware son la parte más difícil del proceso de transferencia, porque generalmente representan código nuevo actual que se debe ingresar. Sin embargo, el compilador IBM® proporciona funciones para facilitar este proceso, como la opción FLOAT(IEEE|HEX), además de diversos #pragma's que permiten modificar el alineamiento y las estructuras de empaquetamiento.

Codificación de caracteres

El conjunto de caracteres utilizado por omisión es también diferente en AIX y z/OS. AIX utiliza codificación ASCII , pero z/OS usa EBCDIC (Extended Binary Coded Decimal Interchange Code). Usted puede utilizar la opción ASCII|NOASCII en z/OS para codificar caracteres en ASCII. Sin embargo, usted todavía debe prestar mucha atención a esta parte de la trasferencia, porque las codificaciones de los caracteres pueden ser una fuente de errores muy sensible y difícil de diagnosticar.

El problema principal con las codificaciones diferentes de conjuntos de caracteres es encontrar código que dependa de valores numéricos o patrones de valores numéricos para los caracteres. Por ejemplo, el fragmento de código que se observa en el Listado 2 muestra true para ASCII pero false para EBCDIC si la variable contiene la letra "A".

Listado 2. Código que verifica un caracter ASCII
if (is_this_char_variable_the_capital_letter_A == 65) {

Una modificación adecuada de dicho código se muestra en el Listado 3.

Listado 3. Código que verifica un caracter EBCDIC
if (is_this_char_variable_the_capital_letter_A == ‘A’) {

Otros patrones comunes que dependen de la codificación de caracteres ASCII son la escritura en mayúscula de cadenas y el escaneo en busca de letras (a diferencia de números o caracteres especiales) en los rangos.

Extensiones de idioma

También debe asegurarse de que no todas las extensiones de idioma que están disponibles en AIX están actualmente disponibles en z/OS (y viseversa), aunque IBM continuamente salva la diferencia entre lo que está disponible y lo que está disponible en las dos plataformas. Los dispositivos como OMP/SMP (Open Multi-Processing support/Symmetric Multiprocessing) y AltiVec (a floating point and integer SIMD (single instruction, multiple data) instruction set) no están disponibles en z/OS, ni son todos de extensiones de compatibilidad GCC (GNU Compiler Collection). Para verificar qué dispositivos están disponibles en z/OS, consulte la z/OS XL C/C++ Language Reference cuyo enlace se encuentra en la secciónResources.

DLLs

La creación de la Dynamic link library (DLL) también difiere entre las dos plataformas. Las DLLs en z/OS dependen de un archivo de texto generado por compilador, denominado Definition Sidedeck, que por convención tiene la extensión de archivo .x. Los Definition Sidedecks son exclusivos de z/OS, y usted debe generar uno para cada una de las DLLs que crea en z/OS. Estos sidedecks pueden incluirse en el paso de enlace de cualquier aplicación que utiliza uno o más símbolos de la DLL.

Si desea más información sobre las DLLs, consulte la sección "Build and use a DLL" del capítulo "Binding z/OS XL C/C++ Programs" de la z/OS XL C/C++ User’s Guide cuyo enlace se encuentra en la sección Resources .

Niveles de idioma

Finalmente, los niveles de idioma disponibles durante la compilación de XL C/C++ for AIX están también disponibles en XL C/C++ for z/OS. Para C, sin embargo, AIX usa xlC stanzas para determinar el nivel de idioma, mientras z/OS usa una opción de compilador (si está usando herramienta utilitaria c89/cxx en lugar de la herramienta utilitaria xlC, que fue introducida en z/OS V1R7).

Para hacer la transferencia más sencilla para el personal, los mantenedores, y los desarrolladores del proyecto que están familiarizados con UNIX®, utilice USS (UNIX System Services) en lugar de MVS (Multiple Virtual Storage). La transferencia es posible en ambos entornos, pero USS es más parecido a un entorno UNIX tradicional, y es familiar a los desarrolladores con experiencia en AIX. El entorno de POSIX (Portable Operating System Interface for UNIX) es establecido al usar USS.


Mejoras de performance

Después de transferir la aplicación, usted deberá realizar algunos ajustes para aprovechar los beneficios que ofrece z/OS además de su confiabilidad y solidez. Algunas de las mejoras en la performance nombradas en esta sección también están disponibles y pueden realizarse en los compiladores XL C/C++ en todas las plataformas.

Sin embargo, el ajuste de performance debería realizarse al final del proceso de transferencia. La parte más importante de la trasferencia es la obtención de la aplicación para trabajar correctamente. Usted puede perder mucho tiempo buscando errores en código optimizado prematuramente. Así que es mejor hacer el ajuste de optimización después de realizar exitosamente la transferencia.

"La optimización prematura es la raíz de todo mal" -- C.A.R. Hoare

La mejora en la performance es un asunto complejo y existen muchas técnicas para lograrla. Algunos rápidos consejos para mejorar la performance de la aplicación transferida son detalladas a continuación en las secciones siguientes.

Los recursos al final de este artículo puede pueden dar información más profunda sobre estas y otras técnicas para mejorar la performance que están más allá del alcance de este paper.

Usted puede obtener la mayoría de las mejoras de performance a través de las opciones de optimización del compilador en z/OS, al igual que AIX. Como con otras plataformas y otros compiladores, hay generalmente un elemento de compensación entre el tiempo de compilación y el de ejecución.

El tiempo de compilación en comparación con el tiempo de ejecución

Existe un balance relativo entre el tiempo que toma la compilación de un programa versus el tiempo que lleva ejecutar el programa compilado resultante. En general, cuanto más tiempo lleve la compilación de un programa (usando optimización), más rápido será ejecutado el programa. Tenga en cuenta que esta relación NO es lineal, ni es siempre el caso que los resultados de tiempo de compilación más largo resulten en tiempo de ejecución más rápido. Por ejemplo, a veces hay ciertos programas donde un nivel de optimización más bajo puede resultar en tiempo de ejecución más rápido.

Como desarrollador, usted puede experimentar con la performance, y lograr un elemento compensatorio justo entre el tiempo de compilación y el de ejecución. Experimentando con las opciones del compilador, puede descubrir el conjunto de optimizaciones adecuado para su programa particular. Las herramientas de IBM como Performance Analyzer pueden ayudarlo a monitorear, analizar e informar sobre la performance de la aplicación.

En general, durante el desarrollo, usted no debería usar ninguna optimización o debería utilizar baja optimización para facilitar tiempos de respuesta en la estructura más rápidos y el soporte en la eliminación de errores. Todas las estructuras para prueba o producción, sin embargo, deberían compilarse con el nivel de optimización en el cual se pretende enviar el producto final.

La mayoría de las opciones del compilador de optimización disponibles bajo XL C/C++ for AIX se encuentran también disponibles en XL C/C++ for z/OS, entre ellas:

  • O2, O3, O4, y O5
  • IPA, HOT, PDF1, y PDF2
  • INLINE, ARCHITECTURE, y TUNE

Sin embargo, por lo general vale la pena tomarse el tiempo para ajustar estas opciones en la nueva plataforma, porque las diferencias en la arquitectura podrían provocar que un conjunto de opciones diferentes sea mejor en z/OS. Para suministrar más beneficios de performance después de la trasferencia, no utilice sólo las configuraciones de optimización idénticas que usó en AIX. Esto se debe a las diferencias de hardware entre las plataformas, y las oportunidades de optimización creadas para el optimizador por estas diferencias.

La performance del tiempo de compilación

La performance del tiempo de compilación puede mejorarse utilizando la siguiente guía:

  • Asegúrese de que la ruta de búsqueda de los archivos de cabecera de la aplicación esté en orden. Por ejemplo, cada archivo de cabecera del usuario se encuentra en el primer directorio de la ruta de búsqueda del archivo de cabecera del usuario.
  • Especifique la opción OE correcta para encontrar los archivos de cabecera adecuados en los conjuntos de datos o en el sistema de archivos USS. Por ejemplo, si usted está en USS y utiliza archivos, especifique OE. Si usted está en el entorno MVS y utiliza conjuntos de archivos, especifique NOOE. Si desea más información sobre la opción OE, consulte la z/OS XL C/C++ User’s Guide cuyo enlace se encuentra en la sección Resources.
    • Use los archivos de cabecera del sistema desde z/OS USS (en lugar de conjuntos de datos particionados) para mejorar el tiempo de compilación.
  • Si usted está trabajando en USS, brinde a cada usuario un sistema de archivos montable separado para evitar la confrontación de I/O.
  • Use el clasificador para permitir la reclasificación de los módulos en caso de cambios pequeños.

Nota: El clasificador tiene limitaciones de extensión de nombre de símbolo más largas que el editor de enlaces.

Al ajustar su programa, recuerde tener en cuenta que z/OS se optimiza para el rendimiento I/O primordialmente, de modo que usted puede obtener mayores beneficios de performance centrándose en esta fortaleza de la plataforma z/OS.

La performance del tiempo de ejecución

A diferencia de AIX, z/OS utiliza un tiempo de ejecución administrado denominado Language Environment (LE). El Language Environment crea un único entorno de tiempo de ejecución para múltiples idiomas de alto nivel, incluyendo:

  • C/C++
  • COBOL
  • PL/I
  • Programas ensambladores con Language Environment habilitado

Con un único entorno de tiempo de ejecución, las incompatibilidades entre los entornos de tiempo de ejecución de idioma específico quedan eliminados. Esto significa que las aplicaciones COBOL y C, por ejemplo, pueden comunicarse de manera eficaz y sencilla dadas las configuraciones adecuadas. Además, usted puede crear aplicaciones con programas de componentes escritos en diversos idiomas. El resultado final es un código que se ejecuta más rápidamente, es menos propenso a errores, y es más fácil de mantener.

Estas son algunas de las funciones de Language Environment:

  • Carga de DLL
  • Inicialización estática para programas reentrantes
  • Administración de las llamadas a la biblioteca, por ejemplo printf() y malloc()

Sin embargo, la mayor parte del tiempo, el hecho de que usted esté utilizando Language Environment será evidente para los programadores, y presenta pocas diferencias para los desarrolladores que provienen de un entorno AIX. Puede encontrar más información sobre LE en la z/OS Language Environment Concepts Guide cuyo enlace se encuentra en la sección Resources .

Puede mejorar la performance del tiempo de ejecución teniendo en cuenta la siguiente guía:

  • Generalmente, si muchas funciones son llamadas por lo general (como los métodos get y set en los objetos C++), use el dispositivo XPLink para utilizar una forma diferente de enlace que debería mejorar la performance del tiempo de ejecución de este tipo de aplicación. Las bibliotecas del tiempo de ejecución del idioma tienen versiones XPLink de funciones para aprovechar al máximo los beneficios que proporciona el dispositivo XPLink.
  • Use la opción -qinfo=als en AIX antes de realizar la trasferencia a z/OS para asegurarse de que el código siga las normas de solapamiento de ANSI. Esta opción está disponible en XL C/C++ V10.1 y en sus versiones posteriores. Esta enumera las posibles violaciones de solapamiento de ANSI en el código fuente, y las probables ubicaciones de estas violaciones.
    • Si no posee violaciones de solapamiento de ANSI, esto le da al compilador más oportunidades de optimización en niveles de optimización del compilador más altos.
    • Si usted tiene problemas funcionales al usar las optimizaciones del compilador, pruebe utilizando NOANSIALIAS para ver si el código no está siguiendo las reglas de solapamiento de ANSI en los casos en los cuales la opción -qinfo=als no encontrara ningún problema (porque la opción -qinfo=als no puede descubrir todos los casos). Si la performance es importante, esta opción no debería utilizarse en compilaciones de producción, y en su lugar deberían corregirse todas las violaciones al solapamiento de ANSI.
  • Utilice niveles más altos de optimización y profile directed feedback. Los niveles más altos de optimización hacen que el compilador analice más en profundidad la aplicación, lo que le brinda mayores oportunidades de mejora a la performance del tiempo de ejecución. Profile directed feedback da como resultado el ajuste para cargas de trabajo representativas para beneficios de performance de tiempo de ejecución adicionales.
  • Coloque el conjunto de datos de la carga en DLPA, y la búsqueda de caché en VLF/LLA. Estos conceptos z/OS permiten cargas y búsquedas más rápidas. Estos conceptos serán analizados con más detalle más adelante en este artículo. Su programador de sistema z/OS puede ayudarlo a implementar esto.
  • Si su programa C no depende de Language Environment, use la opción del compilador METAL para C (Metal C). Metal C permite código Language Environment-independiente que puede evitar la sobrecarga de gastar el tiempo de ejecución administrado.
    • Por favor tenga en cuenta que no todas las funciones de la biblioteca C están disponibles en Metal C. Consulte z/OS Metal C Programming Guide and Reference cuyo enlace se encuentra en la sección Resources si desea más detalles.
  • Use the nivel máximo común de la opción ARCH/TUNE soportado por el hardware en el cual se ejecuta su aplicación. Esto permite instrucciones adicionales, y aprovecha mejor el hardware. Por ejemplo, si usted despliega su aplicación en tres máquinas que soportan ARCH 6, 9, y 8 respectivamente, entonces compile su aplicación con ARCH(6), el nivel ARCH máximo soportado por las tres máquinas.

Uso de la memoria de la aplicación

El uso de la memoria a menudo es también un factor importante. Muchas opciones están disponibles para la reducción del tamaño de los módulos y los objetos. La aplicación puede utilizar reentrancia y DLLs para reducir las huellas en la memoria de las múltiples invocaciones de una aplicación y las partes compartidas de las diversas aplicaciones. En un nivel inferior, la opción COMPRESS puede reducir el tamaño de los objetos generados. Además, asegúrese de que las constantes sean realmente constantes, y utilice las opciones del compilador ROCONST y ROSTRING para reemplazar las constantes en la memoria de solo lectura. Esto facilita la solución de los problemas, y la liberación de secciones estáticas escribibles para otros propósitos.

Mejoras de la performance del tiempo de ejecución del nivel de fuente

Algunas técnicas que involucran la modificación del código fuente de la aplicación pueden utilizarse para mejoras de performance. Para lograr las máximas mejoras, como mencionamos anteriormente en este artículo, asegúrese de que el código fuente siga las reglas presentadas bajo la opción del compilador ANSIALIAS para obtener los máximos beneficios de las optimizaciones de los niveles más altos.

Funciones integradas

Las funciones integradas de Hardware permiten al compilador utilizar código de ensamblado en línea preempaquetado para realizar operaciones comunes que de otro modo requerirían la llamada de una función. El beneficio de utilizar funciones integradas es que usted elimina la sobrecarga de los prólogos y epílogos de la función, lo cual puede incrementar mucho la sobrecarga. Esto puede aumentar significativamente la velocidad de ejecución de la aplicación si, por ejemplo, las funciones integradas son utilizadas en un bucle que es llamado muchas veces. Además de eliminar la función prólogos y epílogos, el compilador puede mejorar el código de optimización que utiliza las funciones integradas.

No es estrictamente necesario utilizar las funciones integradas de hardware directamente: IBM proporciona funciones integradas que permiten a los usuarios llamar funciones comunes.

Estas funciones integradas son suministradas a través de cabeceras de la biblioteca estándar de idioma como:

  • abs()
  • floor()
  • strcpy()

Estas funciones mapean directamente a funciones integradas de hardware, suministrando así oportunidades de performance sin la intervención explícita del usuario.

Estas funciones integradas son proporcionadas a través de cabeceras de la biblioteca estándar de idioma como:

  • stdlib.h
  • math.h
  • decimal.h

La z/OS XL C/C++ Programming Guide (cuyo enlace se encuentra en la sección Resources) contiene más información sobre las funciones integradas, y sus funciones integradas subyacentes de hardware.

El compilador utiliza la opción ARCH para determinar cuáles son las funciones integradas disponibles en su hardware. Los valores ARCH más altos utilizan una cantidad mayor de funciones integradas. En otras palabras, cuanto más nuevo sea su hardware z/OS, más funciones integradas tendrá disponibles.

Aunque la mayoría de las funciones integradas utilizadas por el compilador XL C son compartidas entre AIX y z/OS, hay diferencias entre las funciones integradas XL C++ utilizadas en cada plataforma. El uso explícito de funciones integradas en su código fuente en AIX podría causar errores de "símbolo indefinido" cuando los compile en z/OS.

La z/OS XL C/C++ Programming Guide (cuyo enlace se encuentra en la sección Resources ) contiene una lista de las funciones integradas que están disponibles en z/OS (tanto para C como para C++).

Las funciones integradas existen para muchas operaciones comunes de programación, además de la administración de varios tipos comunes de datos específicos de IBM, como los tipos de datos de punto flotante.

Los tipos de datos de punto flotante soportados en z/OS son:

  • Decimal: permite hasta 31 dígitos y representa exactamente los números decimales.
  • Punto flotante decimal: representa números decimales de forma exacta y compacta.
    • Por ejemplo, long long __d64_to_long_long(_Decimal64);
  • Punto flotante hexadecimal: Base 16. Rangos de precisión diferentes, pero rangos de exponente iguales para tipos de punto flotante.
  • Punto flotante binario: Sigue la especificación IEEE-754.

El libro z/OS Principles of Operation(cuyo enlace se encuentra en la sección Resources ) contiene información muy detallada de todas las funciones integradas de hardware.

Algunas funciones integradas simplemente realizan conversiones de tipo en hardware en lugar de software (lo cual acelera muchísimo el tiempo de ejecución), tal como se observa en el Listado 4.

Listado 4. Conversiones de tipo de funciones integradas
int __srstu(unsigned short *op1, unsigned short *op2, unsigned short pattern, 
   unsigned short **found_char);

Esta función integrada busca un patrón de caracter dentro de las subcadenas. Normalmente esto sería implementado en una función, que si fuera llamada miles de veces crearía demasiada sobrecarga de performance debido a la gran cantidad de llamadas a las funciones. El compilador de IBM busca oportunidades para utilizar esta función integrada, eliminando de este modo la sobrecarga de los prólogos y epílogos de la función, y permitiendo movimientos de código y otras optimizaciones que no podrían estar disponibles de otro modo alrededor de la función integrada.

Optimización de System/OS

El entorno donde la aplicación se ejecuta puede además utilizarse para ayudar a mejorar la performance de la aplicación. Muchos aspectos del entorno en z/OS pueden ayudar a acelerar la carga de programas, la búsqueda de bibliotecas, y la ejecución del programa mismo.

LPA/DLPA

El Link Pack Area (y Dynamic LPA) es esencialmente un área de la memoria en los sistemas z/OS que permite al programador del sistema cargar bibliotecas y módulos al mismo, para hacerlos residentes en la memoria para todos los usuarios. Esto aumenta muchísimo la performance de la carga y del arranque de estas bibliotecas y los módulos para todos los usuarios del sistema. El administrador del sistema z/OS puede establecer esto para su aplicación.

Al usar LPA y DLPA, las bibliotecas y los módulos son precargados de manera eficaz para cualquiera que necesite utilizarlos. Normalmente cada llamada a una biblioteca o a un módulo requiere que el sistema los encuentre y los cargue, lo cual puede aumentar mucho la sobrecarga de cualquier cosa comúnmente utilizada por una gran cantidad de usuarios o aplicaciones, de modo que la DLPA puede dar como resultado aumentos importantes en la performance.

Los programas que se supone que residan en LPA/DLPA deben ser compilados con la opción del compiladorRENT para hacer al programa reentrante si es que no lo es ya naturalmente.

LLA/VLF

Junto con LPA/DLPA, usted puede utilizar library lookaside (LLA) y virtual lookaside facility (VLF) para acelerar significativamente la performance en el sistema en general.

Los índices y las tablas de búsqueda comúnmente usados son almacenados y optimizados en la memoria, reduciendo ampliamente la actividad I/O por parte la O/S, y por lo tanto acelerando el sistema en general.

En resumen, LLA y VLF son utilizados para acelerar la búsqueda de archivos y conjuntos de datos en un sistema, mientras que LPA y DLPA son utilizados para acelerar la carga de las bibliotecas y los módulos de un sistema.

Cuando LLA/VLF y LPA/DLPA son utilizados juntos, el proceso de búsqueda y carga de módulos y bibliotecas se hace mucho más ágil.

Usted puede ajustar varias opciones del tiempo de ejecución y probar la performance para tratar de aumentar la performance de la aplicación. Por ejemplo:

  • HEAP
  • STACK
  • STORAGE

La z/OS Language Environment Programming Guide (cuyo enlace se encuentra en la sección Resources ) contiene información de referencia detallada sobre estas variables del tiempo de ejecución. También contiene sugerencias sobre qué variables utilizar, dependiendo del tipo de aplicación que se posea.

La mayoría de estas opciones del tiempo de ejecución aumentan la performance a costa del espacio de Direct Access Storage Device (DASD), lo cual a menudo es conveniente en estos días porque el espacio de almacenamiento es relativamente económico.

Nota: DASD es el término de z/OS para lo que es esencialmente un disco duro.

La performance I/O

z/OS ya es generalmente considerado uno de los mejores sistemas en lo que se refiere a la performance I/O y al rendimiento de la carga de trabajo. Esto no significa que usted no pueda obtener todavía mayor performance en las operaciones I/O. El capítulo "I/O Performance Considerations" de la z/OS XL C/C++ Programming Guide (cuyo enlace se encuentra en la sección Resources ) tiene varios consejos sobre cómo optimizar las operaciones I/O en ambos conjuntos de datos y archivos USS/HFS (osea UNIX) en z/OS. Tenga en cuenta que varios de estos consejos aplican a C/C++ (u otro idioma) en general, no sólo a XL C/C++ for z/OS.

z/OS le proporciona a usted (como desarrollador) la capacidad de utilizar archivos de la memoria. Estos son archivos que permanecen residentes en la memoria mientras son utilizados, eliminando de este modo la necesidad de lecturas y escrituras mucho más lentas al almacenamiento DASD actual. Los archivos de la memoria en z/OS son más o menos equivalentes a los mapas de la memoria y los mapas de memoria compartida en AIX.

Los archivos Hiperspace son otro tipo de archivo de memoria que puede utilizar. Los archivos Hiperspace residen en un tipo especial de memoria que no usa el espacio de la dirección de una aplicación. Esto significa que usted puede tener archivos de memoria muy grandes en aplicaciones de 32 bits sin reducir la cantidad de memoria disponible al programa. Tenga en cuenta que los archivos Hiperspace no están disponibles en aplicaciones de 64 bits.


Lo que ha aprendido

La transferencia de aplicaciones C y C++ desde AIX a z/OS puede ser fácil y, con un ajuste cuidadoso, puede resultar en performance comparable mientras todavía captura los beneficios únicos de la pila de hardware y software de z/OS.

Existen varios métodos para mejorar la performance de la aplicación en z/OS. Esto incluye la mejora de la performance de la carga, la búsqueda, y la ejecución de la aplicación, junto con la reducción del tiempo y la sobrecarga de las operaciones I/O de la aplicación.

Recursos

Aprender

  • Obtenga más información en la z/OS Internet Library. Conozca muchos más detalles sobre funcionalidades con estos importantes manuales de desarrollador y programador de z/OS:
    • Guía del usuario de z/OS C/C++
    • Guía de programación de z/OS C/C++
    • Referencia de idioma de z/OS C/C++
    • Referencia de la biblioteca en tiempo de ejecución z/OS C/C++
    • Principios de las operaciones en z/OS
    • Guía de programación de Language Environment de z/OS
  • Descubra más sobre z/OS:
  • Descubra más sobre AIX:
    • Navegue en la developerWorks page de AIX para encontrar enlaces a artículos técnicos y muchos recursos relacionados. La página de entrada de developerWorks Rational software es también un buen punto de partida.
    • Explore el Information Center de AIX.
    • Únase al forum de AIX para hacer preguntas y participar en discusiones.
  • Aprenda sobre otras aplicaciones en la IBM Rational Software Delivery Platform, incluyendo las herramientas de colaboración para el desarrollo paralelo y los equipos geográficamente dispersos, además del software especializado para la administración de la arquitectura, la administración de activos, la administración de cambios y releases, la administración de requisitos integrados, la administración de procesos y carteras, y la administración de la calidad. Usted puede encontrar manuales de productos, guías de instalación, y otra documentación en el IBM Rational Online Documentation Center.
  • Visite el Rational software area on developerWorks para encontrar recursos técnicos y las mejores prácticas relacionados con los productos de Rational Software Delivery Platform.
  • Explore Rational computer-based, Web-based, and instructor-led online courses. Mejore sus habilidades y aprenda más sobre las herramientas Rational con estos cursos, los cuales abarcan desde el nivel introductorio hasta el avanzado. Los cursos en este catálogo se pueden comprar como capacitación basada en computadora o capacitación basada en la Web. Algunos de los cursos "Getting Started" pueden adquirirse en forma gratuita.
  • Suscríbase al IBM developerWorks newsletter, una actualización semanal de lo mejor de los tutoriales, artículos, descargas, actividades comunitarias, webcasts y acontecimientos de developerWorks.

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=627788
ArticleTitle=Cómo transferir datos desde IBM AIX hasta IBM z/OS
publish-date=02182011