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 de 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.