Ejemplo de código de programa IMS

Estos fragmentos de programas EGL muestran la interacción con terminales, colas de mensajes y archivos serie IMS.

Ejemplo de E/S de cola de mensajes

A continuación figuran algunos fragmentos de código de un programa EGL que accede a colas de mensajes. El programa lleva a cabo las siguientes tareas:
  1. Solicita entrada desde un terminal mediante un formulario
  2. Lee la respuesta
  3. Actualiza un registro serie con información basada en la entrada del usuario
  4. Coloca como salida el registro serie en otra transacción para un proceso por lotes posterior
El programa presupone las siguientes asociaciones en el entorno IMS:
  • El código de transacción IMS MYTRXCD1 debe estar asociado con un PSB denominado MYTRXCD1
  • El código de transacción IMS NEXTTRX debe estar asociado con un PSB denominado MYTRXCD2
//definir el PSB
Record addToQueue type PSBRecord { defaultPSBName="MYTRXCD1" }
	// tres PCB necesarios para CBLTDLI en IMS
	iopcb IO_PCBRecord { @PCB { pcbType = TP } };
	elaalt ALT_PCBRecord { @PCB { pcbType = TP } };
	elaexp ALT_PCBRecord { @PCB { pcbType = TP } };
	// otros PCB de base de datos
	...
end


Record myTransactionPart type serialRecord
	{ fileName=”MYMSGQUE” }
	...
end

program addtrans type textUIProgram
	{ alias = “MYTRXCD1”,           // IMS requiere que el pgm coincida con el nombre PSB
		segmented = yes,
		@DLI { psb = “mypsb” }}

use MYFORMS;  // MYFORMS es un formGroup que contiene FORM1

// declarar variables
myTransaction myTransactionPart;  // registro serie para cola de mensajes
mypsb addToQueue;                 // psb

	function main()
		converse FORM1;  
		// realizar el proceso necesario
		move FORM1 to myTransaction byName;
		add myTransaction;
	end
end
Al realizar la generación, debe especificar un componente de asociación de recursos que asocie el archivo serie con una cola de mensajes y que suministre el nombre de la transacción a la que debe enviarse conjuntamente con el nombre del PCB que debe utilizarse. Fíjese en el ejemplo siguiente que también incluye un elemento de asociación que hace posible la entrada de los datos de cola de mensaje por parte de un programa de proceso por lotes, tal como se describe más adelante:
<ResourceAssociations name="RESOURCEASSOC601_REORDER">
   <association fileName="MYMSGQUE">
      <imsvs>
         <smsgq systemName=”NEXTTRX" pcbName="elaalt"/>
      </imsvs>
   </association>   
   <association fileName="MYINQUE">
      <imsvs>
         <smsgq systemName=”NEXTTRX" pcbName="iopcb"/>
      </imsvs>
   </association>
</ResourceAssociations>

Dado que addtrans es un programa textUI, EGL hará que se comporte adecuadamente en un entorno IMS y lea la cola de mensajes hasta esté vacía. Esto significa que EGL creará un bucle en el programa a fin de que, una vez que éste haya terminado de colocar la transacción en el archivo serie para el proceso por lotes posterior, volverá a la sentencia converse para solicitar otra transacción desde el terminal.

Ejemplo de proceso por lotes IMS

También puede crear un programa para procesar los mensajes que el programa addtrans escribe en la cola de mensajes. Debe ser un programa básico que obtenga registros de un archivo serie y asocie el archivo serie con el PCN de E/S.

El programa puede utilizar el mismo registro serie que addtrans pero con un archivo nuevo porque se necesita un nombre de PCB distinto. Los cambios clave se muestran en negrita en el ejemplo siguiente:
//definir el PSB
Record getFromQueue type PSBRecord { defaultPSBName="MYTRXCD2" }
	// tres PCB necesarios para CBLTDLI en IMS
	iopcb IO_PCBRecord { @PCB { pcbType = TP } };
	elaalt ALT_PCBRecord { @PCB { pcbType = TP } };
	elaexp ALT_PCBRecord { @PCB { pcbType = TP } };
   	// otros PCB de base de datos
end

program gettrans type basicProgram
  { alias = “MYTRXCD2”
    @DLI { psb = “mypsb” }}

// declarar variables
myTransaction myTransactionPart             // registro serie para cola de mensajes
  {fileName="MYINQUE"};  
mypsb getFromQueue;               // psb

	function main()
     while (myTransaction not endOfFile)
		get next myTransaction;
      		// realizar el proceso necesario
     end
	end
end

Al generar el programa para los entornos IMS/VS o BMP IMS, también debe especificar un componente de asociación de recursos que asocie el archivo serie con una cola de mensajes y que suministre el nombre de la transacción a la que debe enviarse, así como el nombre del PCB que debe utilizarse. En este caso, el PCB de E/S se utiliza como entrada, como se muestra en el componente ResourceAssociations en la sección anterior.

Varios usuarios y colas de mensajes

La situación se vuelve más compleja en IMS cuando hay varios usuarios que compiten por los recursos. Supongamos que los usuarios USER1 y USER2 especifican ambos MYTRXCD1 simultáneamente en sus terminales. Supongamos que el código de transacción de USER1 termina primero en la cola de mensajes asociada con MYTRXCD1.
  1. IMS planifica el PSB asociado con el código de transacción MYTRXCD1. Dicho PSB se denomina también MYTRXCD1, aunque no tiene porqué. El programa asociado con el PSB, sin embargo, debe tener el mismo nombre que el PSB de IMS. Por tanto, IMS carga el programa MYTRXCD1 (conocido como addtrans en EGL).
  2. La lógica de control generada por EGL en el programa MYTRXCD1 determina que esta es la primera vez que el programa se ha invocado para USER1, por lo que el proceso empieza por el principio.
  3. Finalmente, el programa alcanza la sentencia converse y realiza las siguientes acciones:
    • Guarda los datos para todos los registros y formularios que el programa está utilizando.
    • Guarda información relativa al punto del programa en el que se ha producido la sentencia converse
    • Ejecuta el mandato ISRT con el formulario especificado
  4. Siguiendo la lógica añadida por EGL, el programa vuelve al principio y encuentra USER2 esperando en la cola de mensajes. El programa sigue los mismos pasos para USER2 que para USER1, alcanzando la sentencia converse, enviando el formulario y luego volviendo para comprobar de nuevo la cola de mensajes.
  5. Aquí, es probable que el programa busque la respuesta de USER1 a la sentencia converse. La lógica de control generada por EGL determina que esta respuesta es una continuación del proceso de USER1, y hace lo siguiente:
    • Restaura los datos de USER1 (incluida la ubicación de la sentencia converse)
    • Renueva diversas variables del sistema
    • Ejecuta las comprobaciones de validez solicitadas por FORM1
    • Suponiendo que no haya errores de entrada, reanuda el proceso en la sentencia posterior a la sentencia converse
  6. Finalmente, el programa llega a otra sentencia converse, guarda todos los datos y envía una respuesta a USER1. A continuación, el programa efectúa un bucle de retorno para comprobar de nuevo la cola de mensajes.
  7. Supongamos que USER2 ha salido a comer y no ha quedado nada en la cola de mensajes asociada con el código de transacción MYTRXCD1. IMS cierra el programa MYTRXCD1.
  8. Más tarde, si USER1 responde al mensaje de consola más reciente, IMS tendrá de nuevo un mensaje en la cola asociada con el código de transacción MYTRXCD1 e iniciará de nuevo el programa MYTRXCD1. La lógica de control generada por EGL determina que esta respuesta es una continuación del proceso de USER1, restaura todos los datos y continúa el proceso.
Comentarios
(C) Copyright IBM Corporation 2000, 2005. Reservados todos los derechos.