TI (Transaction Integrator) dans un environnement non-DPL
Un environnement non lié (autrement dit, un environnement non-DPL) est un environnement qui n’utilise pas la fonctionnalité IBM DPL (Distributed Program Link). Avec TI (Transaction Integrator), vous pouvez appeler un programme transactionnel (TP) mainframe qui utilise les commandes COBOL EXEC CICS RECEIVE INTO et EXEC CICS SEND FROM. Ces deux commandes COBOL sont utiles si vous souhaitez qu’un TP CICS prenne des responsabilités de conversation SNA (APPC/LU 6.2) et contourne ainsi le TP miroir. En d’autres termes, les commandes COBOL EXEC CICS RECEIVE INTO et EXEC CICS SEND FROM sont le plus souvent utilisées dans un environnement non lié pour transférer des données vers et à partir d’une unité logique (LU) de type 6.2 (APPC).
TI prend en charge le modèle LU 6.2 à la fois pour des environnements liés et des environnements non liés. Vous pouvez créer les types d’environnement distant (RE) suivants pour permettre la prise en charge de chaque modèle :
Liaison CICS à l’aide de LU 6.2 Utilisez-le dans un environnement IBM DPL qui utilise mirror TP.
CICS avec LU 6.2 Choisissez ce type dans un environnement non DPL qui contourne le TP miroir.
Séparer la logique métier de la logique de présentation
Beaucoup de clients utilisent TI dans un environnement non DPL. La seule préoccupation est alors de savoir si la logique de terminal est incorporée à la logique métier. Quand un TP COBOL prend en charge IBM DPL, la logique de présentation a déjà été séparée de la logique métier. Vous n’aurez donc probablement pas besoin de modifier le code COBOL. En revanche, si le TP a été écrit en vue de communiquer avec un terminal, vous devrez sans doute modifier le code COBOL pour séparer la logique métier de la logique de présentation.
L’exemple de code COBOL suivant montre comment gérer des recordsets non liés à l’aide des commandes COBOL EXEC CICS RECEIVE INTO et 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.