| 
P A R T A G E D E C . A A L ' O U V E R T U R E Paramètre SHARE(*YES) sur les commandes CRTxF et OVRDBF. Pour chaque travail le système se reserve un espace memoire necessaire au bon déroulement de ce job. Cet espace memoire s'appelle le P A G (Process Access Group) ............................... VISUALISABLE : JOB information : <- *LIBL,RUNPTY,TIMESLICE :-----------------------------: PAR : Pgm stack : <- Pgm actifs :-----------------------------: DSPJOB : JOBLOG (qjobmsgq) : <- Historique :-----------------------------: : Spool : <- Fichiers spoules :-----------------------------: : O D P OPEN : <- Fichiers ouverts : DATA : : PATH : :.............................: |
|
Pour qu'un programme puisse travailler avec un fichier il a besoin d'un ODP qui contient la reconnaissance du fichier du format du chemin d'accès Les informations nécessaires au type d'utilisation (pointeurs) Lecture Màj Sup Ecriture ET d'autres (Verrouillage, etc ...) C'est l'ordre OPEN qui crée cet ODP dans le PAG du travail (un ODP ne peut donc être partageable qu'entre pgm d'un même JOB) |
|
En standard chaque pgm crée son ODP à l'ordre OPEN le détruit à l'ordre CLOSE. MEME S'il EN EXISTE DEJA UN (c'est le cas si PGM1 (utilisant PRODUIP1) appelle PGM2 (lui aussi utilisant PRODUIP1) C'est l'option la moins "risquée" nous allons le voir mais aussi la moins performante (l'ordre OPEN est l'un des plus COUTEUX en machine) Si l'on renseigne le paramètre SHARE à *YES (définitivement avec CRTxF ou CHGxF provisoirement avec OVRDBF) Cela ne changera rien pour PGM1 (l'ODP n'existant pas) mais PGM2 utilisera l'ODP crée par PGM1 TEMPS D'OUVERTURE DU FICHIER DIVISE PAR 10 !!! TAILLE DU PAG REDUITE. |
|
ATTENTION aux problemes éventuels : + Le pgm qui réutilise un ODP réutilise aussi les paramètres d'ouverture - Type d'ouverture (lecture/maj/sup/ajout) - Type de CA (arrivée ou par clé) - Avec ou sans contrôle de validation Ex: si PGM1 à ouvert le fichier en lecture et que PGM2 avait prévu lecture/màj (PGM2 va quand même partager cet ODP mais se plantera sur l'ordre de màj , pas avant !!) = Ce problème peut être résolu en specifiant pour PGM1 un type d'ouverture plus large que nécessaire (attention en RPG il faudra écrire un accès "bidon") par exemple: MOVE '1' *INLR RETRN UPDATformat ou en utilisant en CL la cde OPNDBF OPTION(*ALL) ou *INP,*OUT |
|
+ Les deux pgms partageront les mêmes pointeurs Ex: si PGM1 lit le fichier en sequentiel (chgt sous-fichier) jusqu'à clé 10, appelle PGM2, qui lit en accès direct clé 3 la prochaine lecture de PGM1 sera clé 4 ! s'il ne prévoit pas de repositionnement avant. Le partage doit donc être pensé dans la logique du pgm. + Si un fichier est déja ouvert en SHARE(*YES) et que vous lancez la commande STRDBG UPDPROD(*NO) avant l'appel d'un pgm de mise à jour, le contrôle se faisant à l'ouverture, le fichier sera quand même mis à jour. + la commande OPNQRYF nécessite un partage d'ODP si l'on veut que le pgm utilise l'ODP crée par cette commande, mais refuse d'utiliser un ODP existant. |
|
En conclusion : Ce paramètre est très intéressant notamment en ce qui concerne les performances il est parfois obligatoire (OPNQRYF) (il faut donc en connaître les défauts) il doit être "pensé" à tous points de vue Il est aussi valide avec les fichiers UNITE (DSPF par exemple) ce qui permet à un RPG de retrouver la position curseur d'un écran affiché par CL de charger un sous-fichier qui sera affiché par un autre pgm etc.. Pour ces fichiers le temps d'ouverture est divisé par 11 !!! ET ENFIN, ILE introduit la notion de champs d'ouverture limité au groupe d'activation (voir ces concepts dans le cours ILE), ce qui permettra de mieux gérer les programmes devant partager une ouverture de fichier. |
