Integrador de transacciones (TI) en un entorno no DPL

Un entorno no vinculado (es decir, un entorno no DPL) es aquel que no usa Enlace de programa distribuido (DPL) de IBM. Puede usar el Integrador de transacciones (TI) para invocar a un programa de transacción (TP) de sistema central que usa los comandos de COBOL EXEC CICS RECEIVE INTO y EXEC CICS SEND FROM. Estos dos comandos de COBOL son útiles cuando se quiere que un TP de CICS asuma responsabilidades de conversación de SNA (APPC/LU 6.2) y, por tanto, omita el TP reflejado. Es decir, los comandos de COBOL EXEC CICS RECEIVE INTO y EXEC CICS SEND FROM se suelen usar en un entorno no vinculado para transferir datos hacia y desde una unidad lógica (LU) de tipo 6.2 (APPC).

TI admite el modelo LU 6.2 para entornos vinculados y no vinculados. Puede crear los siguientes tipos de entornos remotos para admitir cada modelo:

  • Vínculo CICS mediante LU 6.2 Úselo en un entorno de IBM DPL que use el TP reflejado.

  • CICS con LU 6.2: úselo en un entorno no DPL que omita el TP reflejado.

Separación de la lógica de negocios de la lógica de presentación

Muchos clientes usan TI en un entorno no DPL. La única preocupación es si la lógica de terminal está insertada en la lógica de negocios. Cuando un TP de COBOL admite DPL de IBM, la lógica de presentación ya se ha separado de la lógica de negocios, por lo que probablemente no tenga que modificar COBOL. Pero si el TP se ha escrito para comunicarse con un terminal, es probable que tenga que modificar el código de COBOL para separar la lógica de negocios de la lógica de presentación.

Por ejemplo, el siguiente código de COBOL muestra cómo controlar conjuntos de registros sin enlazar mediante los comandos de COBOL EXEC CICS RECEIVE INTO y EXEC CICS SEND FROM:

*****************************************************  
* Example showing how to send unbounded recordsets  
* to a client application.  
*****************************************************  
 IDENTIFICATION DIVISION.  
  
 ENVIRONMENT DIVISION.  
  
 DATA DIVISION.  
  
 WORKING-STORAGE SECTION.  
  
* INPUT AREA  
 01  CUSTOMER-INPUT-NUMBER                PIC 9(9).  
  
* OUTPUT AREA  
 01  CUSTOMER-DATA.  
     05  LAST-NAME                        PIC X(20).  
     05  FIRST-NAME                       PIC X(20).  
  
* ONE ROW IN A DATABASE TABLE  
 01  INVOICES.  
     05  INVOICE-NUMBER                   PIC 9(10).  
     05  INVOICE-DATE                     PIC 9(7) COMP-3.  
     05  INVOICE-AMOUNT                   PIC S9(13)V9(2) COMP-3.  
     05  INVOICE-DESCRIPTION              PIC X(40).  
  
 LINKAGE SECTION.  
  
 PROCEDURE DIVISION.  
*  
*   Get the input customer account number from the  
*   client applicaton:  
*  
     MOVE LENGTH OF CUSTOMER-INPUT-NUMBER TO RECEIVE-LENGTH  
     EXEC-CICS RECEIVE INTO(CUSTOMER-INPUT-NUMBER)  
               LENGTH(RECEIVE-LENGTH)  
               END-EXEC.  
*  
*   Do some work; then send the first and last name back:  
*  
     MOVE LENGTH OF CUSTOMER-DATA TO SEND-LENGTH  
     EXEC-CICS SEND FROM(CUSTOMER-DATA)  
               LENGTH(SEND-LENGTH)  
               END-EXEC.  
*  
*   Follow regular data with unbounded table data that  
*   the client application sees as a recordset:  
*  
     MOVE LENGTH OF INVOICES TO SEND-LENGTH  
     PERFORM UNTIL        NO-MORE-INVOICES  
*  
*   Do some work to get the next row:  
*  
     MOVE DB-INVOICE-NUMBER TO INVOICE-NUMBER  
     MOVE DB-INVOICE-DATE   TO INVOICE-DATE  
     MOVE DB-INVOICE-AMOUNT TO INVOICE-AMOUNT  
     MOVE DB-INVOICE-DESC   TO INVOICE-DESCRIPTION  
*  
*   Send the row:  
*  
     EXEC-CICS SEND FROM(INVOICES)  
               LENGTH(SEND-LENGTH)  
               END-EXEC.  
     END-PERFORM.   

Consulte también

Satisfacción de necesidades específicas del mundo real