Pause-Café Volubis

pause-café

rendez-vous technique
Pause-Café est une réunion technique
destinée aux informaticiens sur plateforme IBM i.
Elle a lieu 3 à 4 fois par an : en Bretagne et sur internet.

Pause-café # 9

Mai 1996

Fin


  Structure (jusqu'à la V3R05) de l'Espace Adressable Unique
   - QSYS est le point d'entrée
   - Certains objets ne peuvent être attachés qu'à QSYS (profil,unité)
   - Seul QDOC (qui est une "extension" à l'EAU) supporte les arborescences.
 ................................QSYS.....................................
 :                              /   \ \ _ ______________                 :
 :                            /      \   \             |-QSECOFR         :
 :                          /          \    \          |-DSP01           :
 :                        /              \    \                          :
 :                   QDOC(DLS)         COMPTA   \- PAIE                  :
 :                   /   \                |           |                  :
 :                 /       \              |-fic1      |-fic11            :
 :            dossier1    QIWSFLR         |           |                  :
 :             /  \            \          |-fic2      |-fic12            :
 :           /      \           \         |                              :
 :         /          \        PCSADM.EXE |-pgm1                         :
 :    sous-dossiera   document1                                          :
 :    /   \                                                              :
 :   /      \                                                            :
 : doca1.doc doca2.doc                                                   :
 :.......................................................................:

 V3R10 : Structure IFS.         "root"
 ................................ / ......................................
 :          -------------------/  | \------------------\                 :
 :        /      /           /    |   \home             \                :
 :      /      /            /     |                      \QLANSrv(FSIOP) :
 :     /    QOpensys       /     QSYS.lib _____________                  :
 :    /    (UNIX "like")  /         \    \             |                 :
 : madir      /          /           \     \           |-QSECOFR.USRPRF  :
 :   |       /  \       /              \     \         |-DSP01.DEVD      :
 :   |      /   user   /                 \     \___                      :
 :   /     bin       QDLS              COMPTA.lib  PAIE.lib              :
 :  / \              /   \                |           |                  :
 : /   \           /       \              |-fic1.FILE |fic11.FILE        :
 :dir1  \     dossier1    QIWSFLR         |           |                  :
 :     dir2    /  \            \          |-fic2.FILE |fic12.FILE        :
 :           /      \           \         |      ######################  :
 :         /          \        PCSADM.EXE |-pgm1 #                    #  :
 :    sous-dossiera   document1                  # la branche QSYS    #  :
 :    /   \                                      #  est inchangée     #  :
 :   /      \                                    # (non arborescente) #  :
 : doca1.doc doca2.doc                           ######################  :
 :.......................................................................:


 Chaque répertoire principal définit un système de fichier


  - structure simple (/home, /madir) plutôt destinée aux clients optimisés


  - structure OS/400 (/QSYS.LIB)


  - structure dossiers partagés (/QDLS) clients standards & OFFICE


  - structure compatible POSIX (QOpensys)


Chaque système de fichier à ses particularités (attributs), ses limites.


  ==> transférer un fichier d'un système de fichier vers un autre
       entraîne la perte de certains attributs.
        (descripteur de document propre au documents OFFICE par exemple)




 QOpenSys est implémenté uniquement pour la compatibilté POSIX.


 QLANSrvs est LE support de FSIOP.

                    


 QDLS semble destiné (à terme) aux dossiers OFFICE uniquement


      -support des attributs spécifiques à ce type d'objets (dans QDOC)


      -vitesse (lente)


      -MAIS envoi du document possible via OFFICE ou FTP




 "root" est à utiliser pour les dossiers micros
            (si vous avez un parc homogène de clients optimisés)


      -en ajoutant un premier niveau à la racine afin que les utilisateurs
        ne "voient" pas la totalité de l'EAU à travers Client/Access.


      -ATTENTION


        La gestion des dossiers de CAWIN se fait avec des commandes IFS


        vous devez organiser vos sauvegardes avec des commandes
         SAV et non plus SAVDLO pour le dossier "/microopt"

 FSOBJ                         Commandes d'objet 
                                                            Système:   S44B0164 
 Choisissez l'une des options suivantes :      .......................
                                               : commandes associées :
      1. Gérer les liens d'objets              :       WRKLNK        :
      2. Afficher les liens d'objet            :       DSPLNK        :
      3. Copier un objet                       :       CPY           :
      4. Rebaptiser un objet                   :       RNM           :
      5. Déplacer un objet                     :       MOV           :
      6. Ajouter un lien                       :       ADDLNK        :
      7. Enlever un lien                       :       RMVLNK        :
      8. Verrouiller un objet                  :       CHKOUT        :
      9. Libérer un objet                      :       CHKIN         :
     10. Copier dans fichier STREAM            :       CPYTOSTMF     :
     11. Copier depuis fichier STREAM          :       CPYFRMSTMF    :
     12. Sauvegarder un objet                  :       SAV           :
     13. Restaurer un objet                    :       RST           :
                                               :.....................:
 Option ou commande 
 ===> 
                                                                                
 F3=Exit   F4=Invite   F9=Rappel   F12=Annuler   F13=Informations techniques 


  Un certain nombre de ces commandes ont des "alias"


    CD pour CHGCURDIR, MOVE pour MOV, REN pour RNM ,...


  Les commandes SAV, RST, MOV , ...


   peuvent tout à fait être utilisées pour manipuler des objets OS/400.
    (mais quel intérêt ???)


  Pour sauvegarder "/microsrv/microopt" :


       SAV DEV('QSYS.LIB/TAP01.DEVD')
           OBJ('/MICROSRV/MICROOPT/*') SUBTREE(*ALL)


  Pour sauvegarder tous les répertoires :


       SAV DEV('QSYS.LIB/TAP01.DEVD)
           OBJ(('/*') ('/QSYS.LIB' *OMIT) ('/QDLS' *OMIT) SUBTREE(*ALL)


  Pour sauvegarder/restaurer OBJ('/*') [tout votre système]
   vous devez être en mode restreint.

                        Gérer les liens d'objets (WRKLNK)      


 Indiquez vos choix, puis appuyez sur ENTREE. 


 Objet  . . . . . . . . . . . . . OBJ            '*'
                    
 Type d'objet . . . . . . . . . . OBJTYPE        *ALL    
 Détail . . . . . . . . . . . . . DETAIL         *PRV      
 Option d'affichage . . . . . . . DSPOPT         *PRV  






















                                                                            Fin 
 F3=Exit   F4=Invite   F5=Réafficher   F12=Annuler   F13=Mode d'emploi invite

                           Gestion des liens d'objet 


 Répertoire . . . . :   /                                                      


 Indiquez vos options, puis appuyez sur ENTREE. 
   3=Copier   4=Enlever       5=Niveau suivant   7=Rebaptiser 
   8=Afficher les attributs   11=Modifier répertoire en cours... 


 Opt   Lien objet             Type     Attribut     Texte 
       home                   DIR                   les "HOMDIR" des profils   
       QDLS                   DIR                   dossiers OFFICE            
       QOpenSys               DIR                                              
       QPWXCGY                DIR                   Graphical operation        
       QPWXCPC                DIR                   PC-5250                    
       QPWXCRB                DIR                   RUMBA p. CAWIN             
       QPWXCRBD               DIR                      idem / DBCS             
       QPWXCWN                DIR                   CAWIN                      
       QPWXCWND               DIR                      idem / DBCS             
       QSYS.LIB               DIR      PROD         Bibliothèque système       
 Paramètres ou commande 
 ===>                                                                           
 F3=Exit           F4=Invite           F5=Réafficher   F9=Rappel   F12=Annuler 


 QPWXCWN = CAWIN (Client Access p WIndows 3.1)


           il existe un répertoire /QDLS/QPWXCWN qui n'est utilisé que par
            les commandes SAVLICPGM et RSTLICPGM.


           en exploitation il doit être vide.


 QPWXCPC = PC5250


 QPWXCRB = RUMBA


 QPWXCGY = Graphical operation


 QPWXCSO = System Object Access


 QPWXCGO = Graphical Access




 QPWXG.. = idem pour OS/2 optimisé


 les anciens dossiers QIWSxxxx sont restés dans QDLS.

         P R O G R A M M A T I O N    O R I E N T E E    O B J E T S   


 La notion d'objet propose d'écrire du logiciel :


   + de manière plus fiable (des petites entités sont plus faciles à tester)


   + plus rapide (réutilisation maximale de code existant)


   + plus évolutive (des petites entités sont plus faciles à maintenir)


Cela induit, en fait, un nouvel état d'esprit.




Pour simplifier la programmation et tendre vers plus de qualité, différentes
 méthodes ont étés implémentées:


 - programmation structurée


   Un code plus facile à lire, à maintenir.


   Mais cela n'empèche pas les programmes d'atteindre une taille critique.

                    

 - programmation modulaire


   des petits éléments de code (correspondant à une action et une seule)


   Maintenance simplifiée, mais reste le problème du partage des variables


   En effet, si les variables sont partageables, la modification d'un sous
    programme peut alterer les variables utilisées par les autres.


 - règle de visibilité.


  Avec des langages comme le C ou PASCAL, chaque sous programme possède ses
   propres variables qui ne sont partageables que si elles sont déclarées
   en tant que variables GLOBALES ou en tant que paramètres.


  En pascal on parle de procédure:
 sous programme exécutant une action à l'aide de paramètres recus.




                  et de fonction :
 sous programme renvoyant une valeur, recevant des paramètres, elle peut
  être utilisée en lieu et place de la valeur qu'elle renvoie

exemple: (en pascal)


Il est possible de "typer" des variables c'est à dire de déclarer de
 nouveaux types de variables:


TYPE
 C20 = STRING[20]


VAR
 NOM,VILLE:C20






PROCEDURE proc1(x:C20 y:INTEGER);
VAR (* déclaration de variable interne au sous-prog *)
 a:INTEGER;  (* la variable a n'est connue que du sous-pgm PROC1 *)
BEGIN
     ...
     ...
     ...
END;

                    




 Maxi est à la fois le nom de la fonction
       et le nom de la variable retournée




FONCTION maxi(x:INTEGER y:INTEGER):INTEGER (* renvoi un entier *)
BEGIN
  IF x < y THEN
             maxi := Y
           ELSE
             maxi := x;
END


BEGIN (* pgm principal *)
 proc1(nom, 15)
 x := maxi(a, b)
END.






  En C, la distinction procédure/fonction n'est pas faite.

/*********************************************************************/
/* min - renvoi le nombre le plus petit des 2 (fonction)             */
/*********************************************************************/
int  min( const int a1, const int a2)
{
    if (a1 < a2)
         return a1 ;
    else
         return a2 ;
}
/*********************************************************************/
/* clear - remplie la variable (pointée par cptr) de (len) blancs.   */
/* (void = pas de valeur en retour ==> procédure)                    */
/*********************************************************************/
void clear(char *cptr, const int len)
{
   int i;
   char *charptr;


   charptr = cptr;
   for (i = 0; i < len; i++, charptr++) *charptr = ' ';
}

 Les concepts de la programmation orientée objet utilisent ces principes:


 Il s'agit de déclarer un nouveau TYPE d'entité (un objet)


 Qui regoupe la définition de donnée(s) et les procédures associées dans
  une même structure (on parle d'ENCAPSULATION)


 Les données gardent le nom de VARIABLES.
 les procédures associées aux données sont appellées METHODES.


  les données sont "protégées", le seul moyen d'y accéder (en lecture comme
   en écriture) est d'utiliser leurs méthodes.
                                                               
                 |      \         Ajouter             /      | 
 OBJET:          |        \                         /        | 
                 |            Données:                       | 
  CDECLI         | lister     N° client article              | 
                 |               date   quantité     livrer  | 
(commande client |                                           | 
                 |       /                          \        | 
                  |     /          Modifier            \      | 

                    

 Les objets dialoguent entre eux par l'intermédiaire de messages


  un message demande à un objet l'exécution d'une de ces méthodes


     ex: cdecli.lister


  Si une méthode à besoin d'informations complémentaires elles seront
   fournies sous forme de paramètres comme pour une fonction.


     ex: rtn = cdecli.ajouter(4015, A1, 10/12/94, 132,25)


         (rtn est ici, un code retour renvoyé par la méthode)


 La définition théorique d'un objet (le "typage") est appellée CLASSE


 l'objet en tant que notion contenant des valeurs (comme une variable)
   est une INSTANCE.
                                                                            
 Le microcode de la V3R60 a été écrit en C++


 Sont annoncés pour cette version, Le compilateur C++
                                   Le support de SOM/DSOM.

                             I L E   


L'une des particularités de l'AS/400 est (était) de générer en une seule
 phase des pgms directement exécutables et autonomes.


Le lien avec d'autres pgms se faisant à l'exécution.


Ce type de pgm est appelé aujourd'hui OPM (Original Program Model),
   les liens générés à l'exécution étant des liens dynamiques


IBM nous propose aujourd'hui le concept ILE :


 Integrated Language Environment


Apportant : des liens statiques ET dynamiques
            des routines communes
            du débogage avec visualisation de source


en V2R30 ILE/C
en V3R10 ILE/RPG , ILE/COBOL et CL
         ce sont de nouveaux compilateurs, de nouveaux produits,
         un nouveau type de source (RPGLE par ex.)


LIEN STATIQUE:


unité d'utilisation = procédure  - partie de code à point d'entrée unique
                                 - réalise une fonction, une action
                                 - n'est PAS un objet OS/400


                                   + RPG      : une procédure par source
                                   + COBOL    : une procédure par compil
                                   + C/400    : x procédure(s) par compil
                                                [main() + les fonctions]


Appel d'une procédure = "call bound"
                (CALLB en RPG, CALL PROCEDURE en COBOL, CALLPRC en CL)


les procédures apparaissent dans la liste d'invocation (DSPJOB/opt 11)


unité de compilation = module    - résultat d'une compil.
                                 (base = un membre source)
                                 - contient une ou plusieurs procédures
                                 - c'est un objet OS/400 *MODULE 
                                 - n'est PAS EXECUTABLE


LIEN STATIQUE:


unité d'exécution = programme    - objet de type *PGM
                                 - lien dynamique (appel par CALL)
                                 - OPM = CRTxxxPGM
                                   xxx étant le type de source
                                   ILE = CRTPGM
                                         phase de liage de modules existants
                                         = LIENS STATIQUES (copie de code)


AVANTAGES:


          - meilleures performances
          - meilleure intégration de langages différents
          - préambule à la POO ? (Programmation Orientée Objet)


INCONVENIENTS:


          - duplication du code = moins de souplesse, duplication en mémoire
                                = maintenance des applicatifs !!!

                    

                         CRTxxxMOD           CRTPGM PGM(PROG01) +
                                                    MODULE(A B C)
 ..fichier source............
 : .RPG...................  :
 : :                     :  :   ############### 
 : :        membre A     :  :-> # MODULE A    # --  ####################### 
 : :.....................:  :   ###############  !  # PROG01 : *PGM       # 
 :                          :                    !  ####################### 
 : .COBOL.................  :   ###############  !  #      #       #      # 
 : :        membre B     :  :-> # MODULE B    #   > #      #       # P1   # 
 : :.....................:  :   ###############  !  #  A   #   B   ######## 
 : .C.....................  :                    !  #      #       #      # 
 : : membre C | P1  | P2 :  :-> ###############  !  #      #       # P2   # 
 : :.....................:  :   # MOD.C P1 P2 # --  #      #       #      # 
 :..........................:   ###############     ####################### 


la création de PROG02 à partir des modules A,E,F,G entraînerait la
 duplication du module A dans cet autre programme.


==> pas de recherche d'adresse,de mémoire,etc.. à l'appel de module A


==> si modification du module A : recréation des pgms PROG01 et PROG02.


MAIS: les liens dynamiques (CALL) sont toujours valides


ET


    Pour diminuer les problèmes de duplication de code pour les procédures
     souvent utilisées, ILE introduit un nouveau type d'objet:  *SRVPGM 
     (programme de service,équivalent des DLL Windows ou OS/2)


    Objet contenant un ensemble de modules(donc de procédures)


    Le lien est fait par référence (dynamique) à l'appel du pgm principal,
     ensuite l'appel d'une procédure est statique.


    (les modules système sont des *SRVPGM = bibliothèques de fonctions)




    Les fonctions fournies avec le compilateur C sont livrées sous forme
     de programmes de service:


        QC2IO, QC2SYS, QC2UTIL1 et QC2UTIL2.

                    

                         CRTxxxMOD           CRTPGM PGM(PROG01) +
                                                    MODULE(A B C)
 ..fichier source........
 : .RPG...............  :                           !              _________
 : :                 :  :   ###############         V             /*P1 adr1!
 : :    membre A     :  :-> # MODULE A    # --  ################ / !P2 adr2!
 : :.................:  :   ###############  !  # PROG01: *PGM #   !-------!
 :                      :                    !  ################   !       !
 : .COBOL.............  :   ###############  !  #      #       #   !  P1   !
 : :    membre B     :  :-> # MODULE B    #   > #      #       #   !-------!
 : :.................:  :   ###############  !  #  A   #   B   #   !       !
 : .C.................  :                    !  #      #       #   !  P2   !
 : : membre| P1 | P2 :  :-> ###############  !  #      #       #   !-------!
 : :.................:  :   # MOD.C P1 P2 # --  #      #       #   !_______!
 :......................:   ###############     ################       ^
                                                                       !
                                                      CRTSRVPGM SRVPGM(SRV1)
                                                                MODULE(C)


==> Une seule recherche d'adresse,de mémoire,etc.. à l'appel de PROG01
==> si modification du module P1, il faut modifier SRV1 (par UPDSRVPGM)
     mais on ne touche pas aux programmes utilisant P1.


 Nous venons de voir que la plupart des compilateurs modernes (souvent d'
  origine micro) mettent en oeuvre deux concepts qui vont de pair :


  - la notion de variables locales


    Un "sous programme", déclare ses propres variables, ne voit qu'elles.


     les seules informations communes sont les paramètres


    Nous fonctionnons déja comme cela avec les programmes indépendants
                                               (exécutés par CALL)


  - la notion de fonction (ou de procédure)


    c'est la possibilité d'utiliser un sous programmes comme élément du
     langage.(donc d'enrichir le langage de ses propres codes.)


    ET, ces fonctions peuvent renvoyer une valeur. La fonction peut alors
     être utilisée à la place d'une valeur si l'argument retourné est
     compatible.

                    


 Exemple : je crée une fonction FINDEMOIS qui accepte un argument de type
             date, et qui retourne un chiffre qui correspond au N° du
             dernier jour du mois.


          1/ la fonction peut déclarer une variable nommée "DATE", elle
              n'aura aucun lien avec une variable de même nom dans le
              programme principal ou dans une autre fonction.




          2/- l'appel peut se faire sous la forme :


               numjour = findemois(datcde)


             mais aussi sous la forme implicite suivante :


               if findemois(datcde) > 30
                  ----------------
                     |
                     |--> cette partie de l'expression est remplacée par la
                           valeur retournée lors la réalisation du test.

                    


 Ces possibilités sont annoncées pour ILE/RPG-IV, prochaine version :


 - support des variables locales


 - Sous programmes de type fonction, utilisables avec la nouvelle spécif C


 - Ces fonctions peuvent être dans le même source ou compilées séparément
     (modules ou programmes de service) puis liées.


 - un source peut ne contenir que des fonctions (sous programmes) afin de
    servir de base à la création d'un programme de service.


 Définition d'une fonction :
 ===========================


  A/ déclaration du prototype, c'est à dire:  du type de valeur retournée
                                               et des paramètres attendus.


   cette déclaration doit se faire dans le programme qui UTILISE la fonction
   par le biais de spécifs D

                    


 Exemple, Pour notre fonction FINDEMOIS :


 * Définition du prototype pour la procédure FINDEMOIS
D FINDEMOIS       PR             2P 0
D  Dateenv                        D


 Ce prototype ce déclare avec les spécifs D du pgm principal.


 Il indique que la fonction retourne une valeur Packée 2 dt 0
                            et attend une variable DATE.


  B/ définition de la fonction :


 2 Nouvelles spécifs "P" pour définir le début et la fin de la fonction


 des Spécifs D  pour définir les variables locales


 Les spécifs C de traitement,


     avec sur le code-opération RETURN un facteur 2 qui indique la valeur
       à retourner (vous pouvez coder plusieurs RETURN).

                  structure générale d'un pgm RPG-IV :  
H  Spécif H générale       |contient NOMAIN s'il n'y a pas de pgm principal
F  Déclaration de fichiers |(ouvertures globales)
D  variables globales      |
D proc1           PR       | prototype procédure 1
D proc2           PR       | prototype procédure 2
I  variables des fichiers  | (globales)
C  traitement              | programme principal
O  sorties                 | sorties du programme principal


P proc1           B       -|
D                 PI       | définition de l'interface
D                          | variables locales
C                          | traitement
P                 E       -|


P proc2           B       -|
D                 PI       |  2ème procédure (idem)
D                          |
C                          |
P                 E       -|
**CTDATA


P Findemois       B
 * Définition de l'Interface de procédure  (PI)
 *  doit être conforme avec le prototype.
D                 PI             2P 0
D Datein                          D
 * variables locales
DDATEDS           DS
D Wdate                           D   DATFMT(*DMY)
D  Wjour                         2S 0 OVERLAY(wdate)
D     slash1                     1     OVERLAY(wdate:3)
D  Wmois                         2S 0 OVERLAY(wdate:4)
D     slash2                     1     OVERLAY(wdate:6)
D  Wan                           2S 0 OVERLAY(wdate:7)
 * traitement
C                   eval      wdate = datein
C                   eval      wjour = 1
C                   ADDDUR    1:*M          WDATE
C                   SUBDUR    1:*D          WDATE
C                   RETURN    Wjour
P Findemois       E

                    


 Le source de cette fonction peut être un source à part et produire
   un module ne contenant que des fonctions. Il faut alors spécifier NOMAIN
   en spécif H du programme.


 Il y a autant de procédures dans le module qu'il y a de procédures dans le
  source (programme principal compris)


 l'appel d'une procédure qui ne retourne pas de valeur peut se faire par
                                                                     CALLB.


 Un programme sans programme principal peut utiliser des fichiers, déclarer
  des variables globales (spécifs D hors procédure)


 les ouvertures de fichiers et les indicateurs sont communs à une unité de
  compilation (déclaration obligatoirement globale au sein d'un même source)




  Si vous ne voulez pas partager les fichiers ouverts ou les indicateurs,
   placez vos procédures dans des sources séparés.
  (le résultat système est le même ,il y a une phase de liage)

                    


 Le but d'une telle nouveauté est clair : l'écriture de routines standards
  qui pourront être utilisées :


 1/ facilement (comme des fonctions intégrées)


 2/ sans risque (variables globales)


 3/ sans dégradation de performances (liage ILE)




           Ce sont des concepts très orientés OBJET .




 ILE RPG-IV n'est PAS un compilateur OBJET. mais,


     - Syntaxiquement tout est prêt.


     - Techniquement c'était nécessaire pour supporter SOM/DSOM


     il n'y a pas encore de FRAMEWORK sur le marché, mais peut-être
      trouverons-nous bientôt des programmes de service prêts à l'emploi.


début