Hay dos esquemas para desplegar un release de una aplicación: se pueden sustituir todos los objetos de la aplicación o se pueden sustituir únicamente aquellos que hayan cambiado. Muchas aplicaciones de IBM® i se despliegan instalando parches o revisiones sobre un conjunto base de objetos. A este conjunto de nuevos objetos lo llamamos un "fixpack". Cuando una aplicación pasa por releases, acumula un conjunto de fixpacks y, con el paso del tiempo, habrá varios fixpacks para una base concreta. Es posible construir estos fixpacks de forma que deban aplicarse en serie o para que sean acumulativos. También puede construir estos fixpacks para que sustituyan objetos existentes o establecer la vía de acceso de búsqueda de la lista de bibliotecas para que encuentre los objetos del fixpack en lugar de los objetos existentes.
Fíjese en este ejemplo. Una aplicación consta de varios programas, archivos y otros objetos, todos los cuales residen en un pequeño conjunto de bibliotecas. Estas bibliotecas están todas en la lista de bibliotecas cuando un usuario ejecuta la aplicación. Un fixpack para la aplicación sustituye algunos de los objetos de estas bibliotecas por versiones nuevas y deja los otros intactos. Debido a la naturaleza de enlace tardío de los programas de servicio en el entorno de lenguajes integrados (ILE) y en programas en general en el OPM, sustituir estos objetos resulta en que se dispone de una nueva versión de la aplicación.
Como alternativa, el usuario puede optar por situar las bibliotecas del fixpack antes de la aplicación base en la lista de bibliotecas y permitir que se produzca enlace dinámico utilizando la lista de bibliotecas. Si todo el enlace se realiza utilizando la lista de bibliotecas, este aplica el fixpack de forma efectiva sin sustituir ninguno de los objetos de la biblioteca base.
Puede utilizar Rational Team Concert para construir fixpacks de cualquiera de estos tipos.
En este ejemplo asumiremos que tenemos dos bibliotecas de origen, FIX y BASE. Para que sea más simple, también asumiremos que los objetos de la aplicación se crearán directamente en la biblioteca FIX. El archivo de origen BASE/QRPGLESRC contiene los miembros A y B. El archivo de origen BASE/QRPGLEINC contiene el miembro I. I es un miembro incluido utilizado por A y B. En este ejemplo todo origen incluido se sitúa en QRPGLEINC y recibe el tipo de origen RPGLE. Consideremos que BASE es de sólo lectura. Todos los cambios se realizan en FIX. Asuma también que BASE contiene todos los objetos creados en BASE y que FIX contiene todos los objetos que conformarán el fixpack. Inicialmente FIX está vacía.
La programadora desea modificar QRPGLESRC(A). Para ello debe copiar QRPGLESRC(A) de BASE a FIX. Lo hace y modifica el miembro. Una compilación debería crear el módulo FIX/A a partir de este origen.
Ahora la programadora desea modificar QRPGLEINC(I). Copia ese a QRPGLEINC(I) de BASE a FIX y realiza la modificación. Ahora una compilación debería crear el módulo FIX/A a partir de este origen, pero también crear el módulo FIX/B. No hay ningún módulo asociado a QRPGLEINC(I), aunque este sea del tipo RPGLE ya que este es un miembro incluido y no debería compilarse.
La organización del proyecto, la configuración de la compilación y el proceso de compilación deben ser suficientemente flexibles para determinar lo siguiente:
La organización básica del proyecto para este ejemplo del soporte de Proyectos i en Rational Developer for Power Systems Software es muy simple. Hay un único proyecto con dos archivos de origen: QRPGLESRC y QRPGLEINC. Cada archivo de origen mantiene los miembros mencionados anteriormente. Tenga en cuenta que hay un único proyecto. Como el repositorio realiza el seguimiento de todo el historial de este proyecto, su contenido puede variar con el tiempo. No es necesario crear un proyecto distinto para introducir una mejora o una revisión a una aplicación.
Podemos compartir este proyecto en una secuencia de repositorio. En esta secuencia crearemos una instantánea que será la base para esta aplicación. En este ejemplo asumiremos que la biblioteca BASE ya se ha llenado.
Cuando comencemos a realizar cambios a la aplicación, la secuencia mantendrá los cambios que realicemos. Asociamos un espacio de trabajo de compilación y su definición de compilación con esta secuencia. La definición de compilación tendrá la biblioteca FIX en IBM i como su carga y su biblioteca de objetos. Esta definición de compilación tendrá la biblioteca BASE en su definición de compilación como la única biblioteca de referencia.
An tes de enviar una compilación, el proceso de carga de la instantánea mantiene la biblioteca FIX y el espacio de trabajo de la compilación sincronizados. Cuando se realizan cambios en la secuencia, estos fluirán a su espacio de trabajo de compilación y desde allí a la biblioteca FIX en el sistema IBM i. Sin embargo, como hemos creado una instantánea de la base, únicamente los archivo distintos a los de la base se cargarán en la biblioteca de la revisión.
En nuestro ejemplo, la programadora realiza un cambio en QRPGLESRC(A) y luego entrega dicho cambio a la secuencia. Esto hace que el cambio se dirija al espacio de trabajo de compilación. Como es un cambio respecto a la base, el miembro se carga en la biblioteca FIX del sistema IBM i. De forma similar, QRPGLEINC(I) se ha cambiado y pasa a la biblioteca FIX. Nuestra biblioteca FIX ahora contiene dos miembros fuente.
Una lista de bibliotecas consta de cuatro secciones: la lista de bibliotecas del sistema, la biblioteca actual, una o dos bibliotecas de productos y la lista de bibliotecas de usuario. Ignoraremos las secciones del sistema y de productos de la lista de bibliotecas de momento. La biblioteca actual es una biblioteca única. La lista de bibliotecas de usuario son varias bibliotecas. Una biblioteca puede ser la biblioteca actual y también aparecer en la lista de bibliotecas de usuario, pero no puede haber duplicados en la lista de bibliotecas de usuario.
si usamos nuestro ejemplo anterior, está claro que queremos compilar en FIX. Esta debería ser nuestra biblioteca actual. Todos los mandatos create crearán objetos en esta biblioteca de forma predeterminada. Como estamos compilando objetos en FIX, especificamos eso en nuestra definición de compilación.
BASE tiene que estar también en la lista de bibliotecas para que los compiladores encuentren los miembros. Será la única biblioteca en nuestra lista de bibliotecas de usuario. Especificamos esto en nuestra definición de compilación como una biblioteca de referencia.
La lista de bibliotecas también puede contener otras bibliotecas después de BASE. Sin embargo, si buscamos candidatos para compilar queremos buscar únicamente en FIX y en BASE y no en las bibliotecas siguientes.
La especificación de la compilación dirige el proceso de compilación describiendo qué se compila y cómo se debe compilar. En nuestro ejemplo, la especificación de la compilación para el proyecto tiene dos conjuntos de mandatos: uno para ILE RPG y uno para crear programas a partir de los módulos. La especificación de la compilación también tiene dos programa de creación, uno que describe qué compilar para RPG y uno para crear el programa. Normalmente podríamos reutilizar los conjuntos de mandatos en varios programas de creación, pero al ser un ejemplo simple no hay reutilización.
Para resumir, tenemos QRPGLESRC(A) de tipo de origen RPGLE en FIX y en BASE. Tenemos QRPGLEINC(I) de tipo de origen RPGLE en FIX y en BASE. Tenemos QRPGLESRC(B) en BASE. Tanto A como B incluyen I.
El proceso de compilación tiene que examinar todos los candidatos de compilación en QRPGLESRC del tipo RPGLE. Como la lista de bibliotecas puede contener bibliotecas distintas a FIX y BASE, describimos la lista de candidatos utilizando la variable especial &SP. Esta variable contiene las bibliotecas del proyecto que deben buscarse al buscar el origen para compilar. En nuestro caso, &SP la define el motor de conjunto para que sea la lista (FIX BASE).
En la definición de nuestro programa de creación definimos la expresión de candidatos de compilación de la siguiente forma:
También definimos las dependencias potenciales de este modo:
Si se aplica la primera expresión a nuestro ejemplo nos da los siguientes candidatos de compilación tras haberse creado y modificado FIX/QRPGLESRC(A):
Si se aplica la segunda expresión a nuestro ejemplo nos da la siguiente lista de dependencias para estos candidatos:
Así, si se cambia QRPGLEINC(I) hará que FIX/QRPGLESRC(A) y BASE/QRPGLESRC(B) compilen y creen los módulos FIX/A y FIX/B. Si se cambia únicamente QRPGLESRC(A) hará que sólo compile FIX/QRPGLESRC(A) y cree el módulo FIX/A. Así, la biblioteca FIX contendrá únicamente aquellos módulos que sean necesarios para un fixpack.
Consulte Jazz.net para obtener más información.