Tivoli Service Desk 6.0 Developer's Toolkit - Guide du concepteur d'interfaces (Interface Designer)

Chapitre 7 : Utilisation de l'interface CPIC

Retour à la table des matières


Introduction

Généralités

L'interface CPIC (Common Programming Interface for Communications) fournit une API cohérente destinée aux applications impliquant des communications entre plusieurs applications. L'interface CPIC utilise la LU 6.2 des services SNA pour créer un ensemble de services inter-applications, qui comprend :

Les commandes CPIC sont intégrées au langage de TSD Script afin que le programmeur de TSD Script bénéficie de l'extension de ces services. Le choix de l'interface CPIC a été privilégié sur les macros de base APPC, de manière à garantir la compatibilité entre les plateformes.

La présente section a pour objet de servir de guide d'élaboration des programmes de transactions de TSD Script exploitant l'interface CPIC. Pour obtenir des informations détaillées sur la programmation SAA CPIC, reportez-vous au manuel d'IBM, Systems Application Architecture Common Programming Interface for Communications Reference, SC26-4399.

Pour permettre l'exécution des commandes CPIC, l'interface CPIC doit être installée sur votre machine. Si tel n'est pas le cas, à chaque lancement d'une commande CPIC, la boîte à outils du développeur de Tivoli Service Desk signale par un message d'erreur que le chargement de CPIC est impossible.

Termes et concepts

APPC

Les communications APPC représentent un système évolué de communications d'égal à égal.

Conversation de base

La conversation de base est un type de conversation dans lequel des applications procèdent à des échanges de données au format train d'octets standard. Ce format contient des zones d'une longueur de deux octets (appelées zones LL) qui définissent la longueur de la mémoire tampon à respecter. Chaque regroupement de données LL s'appelle un enregistrement logique.

Conversation

Une conversation est une connexion logique entre deux applications qui échangent des données via CPIC ou APPC. Il existe deux types de conversation : mappée ou de base. Une conversation connecte les applications par l'intermédiaire d'une session. Une application CPIC peut converser avec une application APPC, de même qu'avec une autre application CPIC.

DDF

Un fichier DDF (fichier de description de données) a pour fonction de mapper les relations entre les structures d'enregistrement de TSD Script et les mémoires tampons d'octets transmis.

LU

Une LU (Unité logique) est, à proprement parler, une machine virtuelle. Outre le fait qu'il est possible de désigner chaque machine physique comme étant une LU, il est également permis de configurer plusieurs LU afin qu'elles constituent une machine physique unique. CPIC utilise uniquement les noeuds de LU Type 6.2.

Conversation mappée

Une conversation mappée désigne un type de conversation dans lequel différents partenaires échangent des enregistrements de données arbitraires, suivant des formats déterminés à l'avance.

Nom de mode

L'interface APPC utilise un nom de mode pour désigner les propriétés de la session entre les LU, durant une conversation. Ces propriétés incluent la classe de service.

Noeud de fonction

Un noeud de fonction désigne une application (ou un ensemble d'applications) permettant de fournir à une LU des fonctions utilitaires de base. Les fonctions délivrées comprennent la manipulation d'informations annexes, le traitement du démarrage d'applications et les processus de fermeture d'application. Des noeuds de fonction d'OS/2 sont fournis avec Communications Manager (CM) ou Communications Manager/2 (CM/2).

Partenaires

Le mot "partenaires" désigne deux applications CPIC qui échangent des données grâce à des conversations CPIC.

Les conversations CPIC peuvent être en duplex intégral, ce qui signifie qu'à une période quelconque d'une conversation CPIC, l'un des partenaires a le droit d'envoyer des données, tandis que l'autre se trouve en état d'en recevoir. Lorsqu'une application se trouve en état Réception, elle peut émettre une demande d'envoi de données lorsque cela est nécessaire. Le partenaire reçoit alors la notification de cette requête, tandis que l'application demandeuse reçoit une notification dans le paramètre StatusReceived.

Nom de destination symbolique

Le nom de destination symbolique (SDN) est un nom de configuration CPIC utilisé par Communications Manager/2, qui permet à une application d'indiquer l'ensemble des attributs requis pour une demande d'attribution de conversation.

Session

Une session désigne une connexion logique entre deux LU. Les LU communiquent entre elles par l'intermédiaire de sessions.

Informations annexes

Il s'agit des informations d'initialisation utilisées par CPIC lors des tentatives d'établissement de conversations. Les informations annexes portent sur le nom de la LU partenaire, le nom de mode et le nom du programme de transactions (TP). Ces informations sont configurées avant que la conversation ne soit établie.

Remarque : Les informations annexes sont référencées par un nom de destination symbolique.

Réseau SNA

Un réseau SNA st un réseau logique composé de plusieurs LU.

Niveau de synchronisation

Le niveau de synchronisation indique le degré de synchronisation qui caractérise une conversation CPIC. Les niveaux de synchronisation peuvent être les suivants :

SYNC_POINT

SYNC_POINT indique que votre application prend en charge les opérations de récupération SAA intégrales, telles que les notifications Take Commit et Take Backout.

Remarque : La prise en charge de SYNC_POINT n'est pas assurée sur OS/2.

Programme de transactions (TP)

Le programme de transactions (TP) est une application utilisant des commandes CPIC ou APPC pour participer à une conversation.

Nom du programme de transactions

Le nom de programme de transactions est le nom d'une application de transaction, qui est spécifié dans les informations annexes. Suivant le système d'exploitation utilisé, le nom du programme de transactions peut définir une entrée de table pour appliquer les services du noeud de la LU cible. Cette table est utilisée pour rechercher les informations nécessaires au lancement du programme de transactions.

Démarrage d'une conversation avec un autre programme

Exemple de conversation simple

Le chapitre ci-dessous illustre brièvement l'exemple d'une méthode utilisée lorsqu'une application lance une conversation avec une autre application.

  1. Le programme A exécute une commande CPICInitialize qui prépare le lancement de la conversation. Il indique un nom de destination symbolique servant à définir le programme C comme cible de la conversation. Le programme A reçoit un identifiant unique pour la conversation.
  2. Le programme A exécute une commande CPICAllocate en utilisant l'identifiant de la conversation.
  3. Par le biais du noeud de fonction, CPIC signale à la LU partenaire (spécifiée dans les informations annexes de l'étape 1) que le programme C doit être démarré pour que la nouvelle conversation soit acceptée.
    Résultat : Le programme C est démarré, et exécute la commande CPICAccept. Il reçoit un identifiant de conversation destiné à être utilisé avec les autres commandes CPIC échangées au cours de la conversation.

Fichiers de description de données TSD Script

Généralités

TSD Script ne permet pas de contrôler directement la taille allouée à l'espace mémoire. Les développeurs n'ont donc plus à se soucier de la taille des enregistrements qu'ils déclarent.

Bien que cette caractéristique soit jugée intéressante pour un langage de quatrième génération, certaines difficultés peuvent voir le jour lors du travail avec les applications CPIC. Ces dernières envoient et reçoivent des mémoires tampons caractérisées par une taille et un format spécifiques. Une application partenaire peut utiliser des formats d'enregistrement différents de ceux de l'application locale, tels que des nombres entiers non reconnus par Intel ou des chaînes de caractères EBCDIC.

Les fichiers de description de données (ou fichiers DDF) offrent la possibilité de définir différentes tailles de mémoire tampon. Un fichier DDF définit le format exact d'une mémoire tampon contenant les données transmises et précise le mode de transcription ou de conversion du format. La boîte à outils du développeur de TSD se sert de ces fichiers DDF comme de "filtres" avec les tampons entrants et sortants d'une application CPIC.

La structure fondamentale d'un fichier DDF est la suivante :

-- Les deux tirets indiquent un commentaire de fin de ligne.
-- La première section concerne les partenaires.
*PARTNER
-- types de conversion de caractères
EBCDIC=TRUE
-- ordre des octets entiers
NON_INTEL=TRUE
-- table de conversion de caractères. A défaut, la boîte à outils du développeur
-- utilise la table AE de CM/2. Cette table par défaut peut s'avérer
-- insuffisante pour vos besoins (par exemple, elle
-- convertit les espaces en x'00'). Si vous souhaitez
-- utiliser une table de conversion plus normale, configurez
-- le nom du fichier de table ACSGTAB.DAT, fourni avec
-- CM/2. Ensuite, attribuez à CUSTOM_CONVERT la valeur TRUE.
CUSTOM_CONVERT=TRUE
-- Cette section concerne les zones. Elle sert à décrire
-- chaque zone de l'enregistrement, ainsi que le mappage et
-- la conversion des octets. Cette section indique essentiellement
-- l'aspect que doit avoir le tampon de données juste avant sa
-- réception (avant conversion), ou juste avant son envoi
-- (après conversion).
*FIELDS
-- Fieldname Type ByteWidth SendUnknowns? Default
   name CHAR 20 FALSE
   street CHAR 20 TRUE
   age INTEGER 20 TRUE
   birthDate CCYYMMDD 8 FALSE

Dans cet exemple, l'application partenaire est exécutée sur une machine EBCDIC à nombres entiers non-Intel (par exemple, IBM System 370). L'enregistrement envoyé est déclaré comme suit dans TSD Script :

SomeRecordName IS RECORD
   name :STRING;
   street :STRING;
   age :INTEGER;
   birthDate :DATE;
   description:STRING;
    END;

La zone réservée à la description n'est pas incluse dans le fichier DDF, ce qui implique que le transfert de cette zone n'a pas lieu lors des communications CPIC.

Section "Partner"

Cette section d'un fichier DDF contient la description du type de machine de l'application partenaire. Elle débute par le texte *PARTNER. La section Partner indique les types de conversion de données employés par la boîte à outils du développeur de TSD. Par exemple, la définition de la valeur EBCDIC=TRUE signifie que la boîte à outils convertit toutes les chaînes de caractères, depuis ou vers EBCDIC, lors des communications avec l'application partenaire.

Attributs des partenaires

Il convient de définir les attributs ci-dessous dans la section Partner. Tout attribut non défini suppose que la valeur par défaut est prise en compte.

Section "Fields"

Cette section du fichier DDF définit les zones et types de zones qui doivent être compressés et décompressés dans les tampons de données CPIC. Cette section de fichier DDF commence par la ligne contenant le mot "*FIELDS". Chacune des lignes de la section Fields correspond à une zone d'enregistrement transférée par TSD Script. Ces lignes adoptent le format suivant :

{fieldname} {fieldtype} {bytewidth} {sendunknowns?} {default}

Les espaces servent à différencier les colonnes. Celles-ci sont définies conformément à la liste ci-dessous :

Commande $INCLUDE

La commande $INCLUDE simplifie la configuration d'un fichier DDF. Cette commande permet de "relier" dynamiquement d'autres fichiers. Lorsque la commande $INCLUDE est détectée par la boîte à outils du développeur de TSD, celle-ci charge le fichier DDF simplifié et ajoute ses définitions de zones dans le fichier DDF en cours.

La commande $INCLUDE peut être incorporée en tout point de la section Fields. Le format de la commande $INCLUDE est le suivant :

$INCLUDE({DDFname})

Lorsque le fichier ne se trouve pas dans le répertoire en cours, la boîte à outils du développeur de TSD recherche le chemin DPATH de ce fichier. Lorsque ce dernier est introuvable, une erreur est renvoyée par la boîte à outils du développeur de TSD.

Commande $SIZEOF

La commande $SIZEOF exécute automatiquement un nouveau calcul de la taille des fichiers inclus. Il n'est pas nécessaire de les recompter manuellement lorsque de nouvelles zones sont ajoutées.

Les commandes $SIZEOF et $INCLUDE sont utilisées pour les cas particuliers, tels que la configuration d'une mémoire tampon vectorisée. Elles peuvent être utilisées en combinaison, comme suit :

*PARTNER
   EBCDIC =TRUE
   NON_INTEL =TRUE
   CUSTOM_CONVERT =TRUE
*FIELDS
GDS1310 INT 2 TRUE 4880
GDS1311LEN INT 2 TRUE
   $SIZEOF(1311.DDF) + 2 $INCLUDE(1311.DDF)
GDS1549LEN INT 2 TRUE
   $SIZEOF(1549.DDF) + 2 $INCLUDE(1549.DDF)
DataLen INT 2 TRUE
   $SIZEOF(RTRNDATA.DDF) + 2 $INCLUDE(RTRNDATA.DDF)

Types de zones DDF

Les types reconnus pour le traitement du fichier DDF sont les suivants :

Utilisation de l'interface CPIC avec Communications Manager/2

Généralités

Plusieurs détails doivent avoir été portés à votre connaissance avant de commencer l'écriture d'applications CPIC pour OS/2. Ces dernières peuvent, dans certains cas, être regroupées en fonction du type de services de noeud disponibles sur votre système.

Demandes de connexion

Compte tenu de la manière dont le noeud de services définit les programmes de transactions en vue de recevoir les demandes de connexion, il est impossible de définir une application CPIC pour OS/2 en tant que programme de transactions de service SNA. Vous devez tenir compte des étapes suivantes, qui résument la méthode de traitement des demandes de connexions :

  1. Le noeud de services procède au lancement des processus et configure la variable d'environnement APPCTPN pour qu'elle corresponde au nom du programme de transactions.
  2. Lorsque l'application exécute la commande Accept, le noeud de service contrôle la variable APPCTPN dans l'environnement de l'application réceptrice.
  3. Le noeud de services lance un scannage des demandes de connexion en attente, en recherchant dans la liste un nom de programme de transactions identique.
  4. Une fois que ce nom a été trouvé, l'appel est validé. Du fait que le nom des programmes de transactions pour les services SNA commencent par un nombre hexadécimal, ils ne peuvent pas être configurés au sein d'une variable d'environnement OS/2.

Fonctionnement d'applications TSD Script multiples avec les programmes de transactions

Si vous souhaitez configurer un programme de transactions pour plusieurs applications TSD Script, vous devez faire appel à une procédure spéciale. Communications Manager/2 vous autorise uniquement à définir kml.exe comme variable PATH et nom de ficher d'application OS/2 pour une définition de programme de transactions. Pour un autre programme, vous devez créer un fichier de commande OS/2 comprenant les commandes suivantes :

SET APPCTPN={nom de votre programme de transactions}
START /C KML /U {chemin d'accès à la base de connaissances} {nom de la base}
EXIT

Communications Manager/2 - Version 1.1 (CM/2)

Communications Manager/2 permet à un processus CPIC unique d'accepter des conversations multiples. De plus, une application CPIC ne peut exécuter qu'une seule commande Initialize tant qu'aucune commande Accept n'a encore été lancée.

Exemple d'utilisation de l'interface CPIC avec TSD Script

Généralités

La présente section expose brièvement le procédé de création d'une application CPIC simple. Cette application est conçue pour effectuer un transfert de fichier.

Pour illustrer les avantages de CPIC, deux exemples de modules sont présentés. L'application est créée dans le premier exemple de module. Dans le deuxième exemple, certains changements mineurs ont été apportés à l'application afin d'en améliorer les performances.

Dispositions préalables

L'étude du cas de cet exemple suppose à plusieurs égards que vous maîtrisez le fonctionnement de CPIC, de Communications Manager/2 et des applications de communications en général. Il est par exemple implicite que vous possédez de bonnes connaissances de l'utilitaire CMSETUP de Communications Manager/2.

Application partenaire (RCV.CMD)

Vous devez en premier lieu examiner l'application partenaire développée en langage REXX.

Le nom de l'application partenaire REXX est RCV.CMD. Il s'agit essentiellement d'une application qui reçoit des données (en les enregistrant dans une variable indicée), jusqu'à ce qu'un paramètre d'état indique que l'application peut dorénavant envoyer des données.

L'échantillon de code ci-dessous fournit des explications détaillées sur l'application.

/* RCV.CMD */ 
/* Reçoit des chaînes de données en les regroupant par tampons. /*Après la*/
/* réception, le tampon de données est renvoyé. */
/* Commandes CPIC utilisées : CMACCP */
/*                     CMCFMD */ 
/*                     CMDEAL */ 
/*                     CMRCV */ 
/*                     CMSEND */ 
/* constantes couramment utilisées */
CM_OK               = 0 
/* état reçu */
CM_SEND_RECEIVED    = 1 
CM_CONFIRM_RECEIVED = 2 
/* données reçues */
CM_NO_DATA_RECEIVED = 0
MaxLength           = 257; 
BufferLen           = 0; 
FileBuffer.0        = 0; 
'CPICREXX' 
address cpicomm 
'CMACCP Conv_ID RetC'; 
if \(RetC = CM_OK) then do 
     SAY 'ACCP = 'Retc 
   end; 
   'CMRCV Conv_ID Data MaxLength DataReceived 
    ReceivedLength StatusRecvd ReqToSendRecvd Retc'; 
if \(RetC = CM_OK) then do 
      SAY 'RCV = 'Retc 
   end; 
do while (RetC = CM_OK) & 
  (StatusRecvd \= CM_SEND_RECEIVED) 
  if (DataReceived \= CM_NO_DATA_RECEIVED) then do 
/*    SAY Data */ 
      FileBuffer.0 = FileBuffer.0 + 1; 
      i = FileBuffer.0; 
      FileBuffer.i = Data; 
   end; 
   if (StatusRecvd = CM_CONFIRM_RECEIVED) then do 
      'CMCFMD Conv_ID RetC'; 
   end; 
   'CMRCV Conv_ID Data MaxLength DataReceived 
    ReceivedLength StatusRecvd ReqToSendRecvd Retc'; 
   if (RetC \= CM_OK) then do 
      SAY 'RCV = 'Retc 
end; 
   end; 
SAY 'Fichier de retransmission' 
DO i = 1 TO FileBuffer.0 
   BufferLen = LENGTH(FileBuffer.i); 
   Data = FileBuffer.i; 
   'CMSEND Conv_ID Data BufferLen ReqToSendRecvd RetC'; 
   if (RetC \= CM_OK) then do 
      SAY 'SND = 'Retc 
   end; 
    END; 
'CMDEAL Conv_ID RetC'; 
address cmd 
'EXIT'

Exemple de module n° 1 - FILESND.KB

Cette application consiste à lire un fichier texte et à transmettre chacune des lignes à une application partenaire. Une fois le transfert de fichier terminé, l'application commence par recevoir à nouveau le fichier, puis affiche les lignes une par une dans une fenêtre.

  1. Analysez le fichier à l'aide de la commande KP FILESND.
  2. Démarrez l'application CMSETUP à partir du dossier CM/2.
    Résultat : La boîte de dialogue de l'utilitaire de configuration de CPI Communications Manager s'affiche.
  3. Dans la fenêtre, entrez le nom FILESND.
  4. Dans le menu CPI Communications, sélectionnez l'option SNA Features.
    Résultat : La boîte de dialogue CM/2 Configuration Definition s'affiche.
  5. Définissez l'entrée d'informations annexes.
  6. Dans la boîte de dialogue SNA Features, sélectionnez CPI Communications Side Information.
  7. Sélectionnez l'option Create.
  8. Entrez les données suivantes dans la boîte de dialogue :
    SDN = FILESND
    Target LU = {indiquez le nom de la machine cible}
    TP Name = FILERCV
    Security = NONE
    Mode = #INTER
  9. Cliquez sur OK.
  10. Sélectionnez Transaction Program Definitions
  11. Sélectionnez l'option Create.
  12. Entrez les valeurs suivantes dans la boîte de dialogue :
    Service TP = deselected
    TP Name = FILERCV
    OS/2 Program PATH and Filename = CMD.EXE
    Conversation security required = deselected
    Program Parameters = /C {chemin d'accès au code du tutoriel} RCV.CMD
  13. Sélctionnez l'option Continue.
  14. Entrez les données suivantes :
    Presentation Type = Background
    Operation Type = Queued, Attach Manager started

Examen de la procédure de configuration

En commencençant à l'étape 3, vous définissez une entrée dans la table des informations annexes de Communication Manager/2. La table d'informations annexes est utilisée lors de l'initialisation d'une conversation. L'initialisation s'accomplit de la manière suivante :

  1. Une application appelle CPICInitialize, en transférant un paramètre de nom de destination symbolique. Celui-ci se comporte comme une clé avec la table d'informations annexes.
  2. CPIC utilise le nom de destination symbolique pour définir les attributs d'une nouvelle conversation. Les attributs peuvent représenter la machine et le programme de transactions cibles.

En appliquant cette méthode, les applications CPIC peuvent être écrites sans contenir d'informations figées dans le code ni spécifiques au site. Cette méthode permet également de standardiser l'accès de toutes les applications CPIC à ce type d'informations.

En commençant à l'étape 8, une définition de programme de transactions est créée. Cette entrée indique la manière dont le noeud de services doit démarrer un programme de transactions particulier.

Lorsqu'une conversation a été attribuée, la LU responsable de la demande d'attribution envoie le nom du programme de transactions souhaité vers le système du noeud de services de la LU cible. Celui-ci contrôle que le nom du programme de transactions a été défini sur le système. Si tel est le cas, les services de noeud se conforment aux instructions concernant le mode de démarrage du programme de transactions. Si l'application peut être démarrée, le lancement est effectué (lorsque le gestionnaire de connexions est configuré pour le programme de transactions). Le programme de transactions lance alors la commande CPICAccept. La LU demandeuse reçoit une confirmation de bonne exécution, et la conversation est lancée.

Pour cette application REXX, un processeur de commandes OS/2 est démarré (CMD.EXE). La chaîne de paramètres indique à CMD.EXE de quitter l'application lorsque l'exécution de la commande a abouti (/C), en précisant la commande à exécuter (RCV.CMD).

Exécution du fichier RCV.CMD à partir d'une ligne de commande

La partie suivante de l'étude de cas consiste à exécuter le fichier RCV.CMD à partir d'une ligne de commande OS/2.

  1. Définissez un indicateur permettant à CM/2 d'identifier le programme de transactions en attente de conversation entrante. Pour cela, vous devez configurer une variable d'environnement pour la session de commande :

    SET APPCTPN=FILERCV

    (Facultatif) Afin d'éviter que les demandes de connexion ne subissent une attente indéfinie, vous pouvez éditer le fichier de définition du noeud (NDF) accessible par le répertoire CMLIB. Ce fichier porte le même nom que le fichier de configuration de Communications Manager/2.
  2. Recherchez la section définissant les attributs du programme de transactions FILERCV (recherchez FILERCV).
  3. Modifiez la valeur des attributs INCOMING_ALLOCATE_TIMEOUT et RECEIVE_ALLOCATE_TIMEOUT en leur assignant des entiers positifs (les unités sont en secondes ; une valeur de 180 est satisfaisante).
  4. Enregistrez le fichier.
  5. Pour que les modifications prennent effet, lancez l'utilitaire de configuration de CM/2 et modifiez un nombre suffisant de zones de données pour que le programme demande la confirmation des changements. Enfin, appliquez les modifications de façon dynamique.
  6. Lancez l'application REXX en tapant RCV et en appuyant sur la touche ENTREE.
    Résultat : L'application est suspendue jusqu'à ce qu'une affectation soit acheminée, ou que le délai d'attente de RECEIVE_ALLOCATE_TIMEOUT soit dépassé. Une fois l'exécution achevée, cette application quitte le processus de commande en cours.
    Remarque : Ne démarrez l'application REXX que lorsque vous êtes prêt à lancer FILESND.KB.

Exécution de FILESND.KB

Cette commande permet d'envoyer alternativement le fichier source entre les deux applications, puis d'afficher les résultats de l'opération dans une fenêtre.

Ce double transfert peut nécessiter un temps d'exécution assez long. La durée d'exécution est affichée en bas de la liste de fichiers.

Par ailleurs, vous pouvez noter les numéros de ligne correspondant à chaque ligne du fichier. Ces numéros sont transmis dans les deux directions de transfert, pour chaque ligne du fichier de texte.

Liste de lignes FILESND.KB

A la suite de la présente section de lignes numérotées figure un descriptif du contenu de ce fichier.

1
2      KNOWLEDGEBASE FILESND;
3
4      ROUTINES 
5      PROCEDURE DoConversation(VAL Args:List of String);
6                              (* sdn, infile *) 
7
8
9      PRIVATE 
10
11     CONSTANTS 
12        CPIC_SUCCESS IS 1; 
13
14     TYPES 
15        FileRec IS RECORD 
16           LineNbr:Integer; 
17           Buff:String; 
18        END; 
19
20     ROUTINES 
21
22     FUNCTION RcvData(REF w:WINDOW, VAL 
                        Conv:Conversation) 
                        :INTEGER IS 
23     VARIABLES 
24        totalBuff :FileRec; 
25        dataRcvd  :integer; 
26        statRcvd  :integer; 
27        reqTSRcvd :integer; 
28        rc        :integer; 
29     ACTIONS 
30        IF (not(Known(w))) THEN 
31        WinCreateScrollWindow($DESKTOP,w, 
32                              $NullHandler, 
                                1,1,67,7, 
                                'FileSnd','', 0, 
                                  $WinBorder+ 
                                  $WinTitle+ 
                                  $WinHScroll+ 
                                  $WinVScroll+ 
                                $WinSysMenu+ 
                                  $WinResize); 
    END; 
33       REPEAT 
34       rc := CPICReceive(Conv,'FILEREC.DDF', 
                             totalBuff,DataRcvd, 
                             StatRcvd,ReqTSRcvd); 
35          IF (rc > 0) THEN 
36          IF ((StatRcvd = $CPICConfirmReceived) or 
37             (StatRcvd = $CPICConfirmSend 
                Received)) THEN 
38              rc := CPICConfirmed(Conv); 
39       END; 
40            totalBuff.buff := StrTrim 
                           (totalBuff.buff); 
41             WinWriteLn(w,totalBuff.lineNbr:5&' 
                         :'&totalBuff.buff); 
42        END;
43       UNTIL ((rc <> 1) OR ((StatRcvd =
                         $CPICSendReceived) OR 
44             (StatRcvd = $CPICConfirmSend
                     Received))); 
45       Exit(rc);
46    END; -- RcvData
47
48
49 --------------------------------------------- 
50 -- Description : Lit le fichier spécifié,
         en transmettant chaque ligne via CPIC 
51 -- vers le partenaire spécifié dans le
      nom de destination symbolique concerné.
52 --------------------------------------------- 
53 PROCEDURE DoConversation(VAL Args:List of 
                            String) IS 
54 VARIABLES 
55    Conv     :Conversation; 
56    fRec     :FileRec; 
57    ReqTSRcvd:INTEGER; 
58    rc       :INTEGER; 
59    inf      :FILE; 
60    w        :WINDOW; 
61    t1,t2    :TIME; 
62 ACTIONS 
63    t1       := $NOW; 
64    IF (ListLength(Args) <2) THEN WinMessageBox($DESKTOP,Ò