Architecture IBM i

AS/400, iSeries, System i, Power system (Évolution de la Gamme)




                     
Historique des Minis IBM


75  |   3X
    |
    |   32/34
81  |              38
    |              /                        ................................
83  |   36        /                         : Minis  : Gros syst.: OS/400 :
    |      \     /      ....................:...............................
88  |        AS/400     :  modèles   B      | B10/B20 | B30-B70   : V1     :
    |                   :...................|.........|...........:........:
    |                   :          : D      | D06-D20 | D35-D80   : V2     :
    |                   :          :........|.........|...........:        :
    |                   :          : E      | E02-E25 | E35-E90   :        :
    |                   :          :........|.........|...........:        :
    |                   :          : F      | F02-F25 | F35-F97   :        :
    |                   :..........:........|.........|...........:........:
95  |                   :    Advanced       |   200   |   400     : V3R10  :
    |                   :        Series     |         |           :        :
    |                   ....................................................
96  |                   :  Advanced Series  |  400    |   500     : V3R60  :
    |                   :...................|.........|...........:........:
97  |                   :  eSeries          |  600    |   620     :        :
    |                   :                   |         |   630     : V4R10  :
    |                   :.........................................:........:
99  |                   :  eSeries          |  170    |   720     :        :
    |                   :                   |  700    |   730     : V4R40  :
    |                   :.........................................:........:
2001|                   :  System i         |  270    |   8xx     : V5R10  :
    |                   :.........................................:........:
2004|                   :   i5 (i5/OS)      |  520    | 550 à 595 : V5R3/R4:
    |                   :.........................................:........:

2007|                   :   i5 (i5/OS)      |  515/525|           : V5R4   :
    |                   :(OS facturé à l'utilisateur) |           :        :

    |                   :.........................................:........:
2008|                   
:   Power System    | 520/550 | 570 et +  : V6R1   :
    |                   : (IBM i et soft facturés à l'utilisateur :
                :
    |                   :.........................................:........:
2010|                   
:   Power System    | 720/740 | 750 et +  :IBMi 7.1:
    !                   :.........................................:........:
2014!                   :   Power System    | 814/824 |           :IBMi 7.2:
    V                   :.........................................:........:

A partir des modèles 400/500 la famille de processeur change
  (POWER-PC [technologie RISC], à 64 bits), actuellement le POWER 8


le plus puissant : 256 cœurs, 8 To de mémoire, 1.248 To disque (Power System,795)

Depuis 2001, chaque processeur accepte plusieurs partitions


Évolutions de l'AS/400 en version 4 et 5

 


 

DB2/400 de la V3 (1995) à la V7(2014)

Rappel sur des fonctions de DB2/400 récentes et donc, parfois, sous-employées :

Variables de Type DATE, HEURE, HORODATAGE

Notion de variable obligatoire/facultative (valeur NULLE)

Remarques : le support de la valeur nulle est disponible pour ILE/RPG-IV Version 3.70.

Les vues

(elles sont dans de nombreux cas plus puissantes que les fichiers logiques SDD):

On admet des vues portant sur des vues, des calculs, des sélections complexes, la clause GROUP BY

 

contraintes

contrainte d'entité : Notion d'unicité

Notion de clé primaire

intégrité référentielle une clé étrangère doit se rapporter à une clé primaire d'une table déclarée parente.

(On ne peut pas insérer une commande se rapportant à un client non enregistré dans le fichier client)

il est alors possible de préciser comment gérer l'intégrité dans le sens parent/enfant. 
C'est à dire que faire si l'on tente de supprimer un client ayant des commandes.

l'utilisation du commit est fortement conseillée et dans certains cas obligatoire.( particulièrement la suppression en cascade)

contraintes de domaine depuis la V4R20

vérification de type comp, range, values avec des constantes ou avec d'autres colonnes du même fichier.

quelques exemples

ADDPFCST FILE(CLIENT) TYPE(*PRIKEY) KEY(NOCLI) CST(client_unique)

ADDPFCST FILE(ENTCDE) TYPE(*REFCST) KEY(NOCLI) CST(client_existe) PRNFILE(CLIENT)

ADDPFCST FILE(ENTCDE) TYPE(*CHKCST) CST('commande_valide') CHKCST('nocde > 0 and datliv > datcde')

triggers

Triggers Associé à une action base de donnée

(on associe un pgm "maison" à l'action «insérer un client» ou «modifier un client» ou «supprimer un client».)

Remarques :

depuis la V3R70 un trigger peut modifier l'enregistrement base de données qu'il a reçu en tant que paramètre.

Les triggers peuvent être écrit dans n'importe quel langage
C, RPG III ou IV ,COBOL, depuis la V5R10 en SQL PSM (comme le PL/SQL)

exemple :

ADDPFTRG FILE(ENTCDE) TRGTIME(*AFTER) TRGEVENT(*UPDATE) PGM(MONPGM) ALWREPCHG(*YES) 

ou bien CREATE TRIGGER ...c'est le dernier paramètre qui autorise la mise à jour de l'enregistrement

 

jointure

DB2/400 admet maintenant la jonction norme SQL-92

C'est à dire SELECT * FROM CLIENT JOIN COMMANDE ON client.NOCLI = cde.NOCLI [WHERE ...]

Ce qui autorise les jointures externes :

(LEFT OUTER JOIN, c.a.d, tous les clients qu'ils possèdent ou non des commandes)

et les différences :

(EXCEPTION JOIN, c.a.d, les clients SANS commande))

EN V5r30 la clause USING peut être utilisée : select * from vins join producteurs using(pr_code)

ainsi que les opérateurs EXCEPT et INTERSECT

DRDA

Two PHASES COMMIT

il est possible d'inclure dans une même transaction des fichiers se trouvant sur des bases de données différentes (dans le cadre de DRDA)

Exemple :

    connect to base 1

        moins 100 dans la quantité pour le produit A1

    connect to base 2

        plus 100 dans la quantité pour le produit A1

    Commit

la phase de validation sera réalisée en deux temps :

demande de préparation à la validation (prepared wave)
validation effective (commited wave)

 

Procédures cataloguées

Un ensemble d'actions base de données devant être réalisées sur une base distante peut être demandé par l'appel à une procédure (un programme) stockée sur le serveur distant.

Cela normalise un ordre CALL (en tant qu'ordre SQL), avec passage de paramètres et ce, en étant affranchi de l'OS du serveur.

Sur l'AS/400 les procédures cataloguées peuvent être écrites dans n'importe quel langage et leur déclaration est optionnelle.

V4R20, on reconnaît le PL/SQL pour l'écriture des procédures cataloguées.
V5R10 le compilateur C n'est plus obligatoire.

exemple :

Create Procedure bib/p1
    (in nomatin DEC(6, 0),
    in newcoef DEC(3, 0),
    out codert int)
language SQL
P1:
Begin

Declare coeflu DEC(3, 0);
Declare Exit handler for SQLExecption Set codert=SQLCODE;

Select coef from personp1 into coeflu where nomat = nomatin;

if newcoef > coeflu then
    update personp1 set coef = newcoef where nomat = nomatin;
end if;

End

Alter TABLE

L'ordre ALTER TABLE permet maintenant de modifier la structure d'une table, dynamiquement :

Pour les programmes réalisant leur entrés/sorties à l'aide de SQL, cette seule action suffit, pour les autres il faut recompiler.

Sous sélection admise dans l'ordre UPDATE

  la notion de sous-sélection permettait de mettre un ordre SELECT dans la clause WHERE d'un ordre SQL.

Cette syntaxe est maintenant acceptée dans la clause SET de UPDATE 

mettre à jour le fichier command, mettre dans priha la valeur retournée par la clause select qui dit
      (je vais chercher le pritarif dans le fichier article,   
         de la ligne ayant le code article lu dans le fichier commande )

 

- Les sous selections sous admises aussi dans l'ordres SELECT

• Historiquement dans la clause WHERE

• Depuis la V4R40 dans le from


Depuis la V5R10 dans la liste des colonnes

 Select codart , qte * prix as montant, (select sum(qte * prix)  
                                           from commandes where

                                            famcod = c1.famcod) as totfam
from commandes c1

 

- tables dérivées :


  on peut indiquer un ordre SELECT dans la clause from d'un ordre SELECT
     ou bien déclarer juste avant le SELECT une "vue temporaire" par WITH.

exemple , soit un fichier des cours, chaque cours est enregistré sous un module de cours.

 je veux le nombre de cours du module qui en a le plus.

 

 deux nouveaux types de donnée apparaissent en V4R40
    les types de données LARGES (jusqu'à 15 Mo en V4, 2Go en V5)
    les DATALINK (ou URL)

 

1/ les LOB (Large Object)

   ils sont de trois sortes
     + CLOB Chararcter Large Object, supportent la notion de CCSID
     + DBCLOB Double Byte CLOB, idem CLOB mais en DBCS
     + BLOB Binary Large Object, binaires, donc prévus pour les images
                                                            la video, etc...
     ex: CREATE TABLE VOITURE (image as BLOB 2M)

 

2/ les types de colonne DATA LINK
  

il s'agit de colonnes dont le contenu référence un fichier externe.
     a/ le nom du fichier est donné sous forme d'URL
     b/ le fichier reste à l'exterieur de la base de données
           (utilisable par votre serveur WEB, par exemple)

     c/ le serveur Base de données peut vous fournir un contrôle de type:
                     - je vérifie que le fichier existe lors de l'insertion
                     - je vérifie la présence du fichier tant qu'il est  
                          référencé dans la base.

  vous devez lancer un serveur TCP/IP appelé DLFM
       (DATA LINK FILE MANAGER), pour gérer ces contrôles temps réel.

 

ET ENFIN, orientation objets (V4R40)

les fonctions définies par l'utilisateur       [UDF]

les types de données définis par l'utilisateur [UDT]

une fonction est un programme ou une procédure dans un programme de service
 enregistré(e) dans les catalogues SQL par CREATE FUNCTION.


 par exemple :

notre routine RGP4 de vérification de mail, peut devenir

Etre compilée par CRTRPGMOD puis CRTSRVPGM SRVMAIL ... EXPORT(*ALL)

et enfin, être déclarée à SQL, par :

    CREATE FUNCTION AF4TEST/CHKMAIL ( CHAR(50) ) RETURNS CHAR(1)   
         EXTERNAL NAME 'AF4TEST/SRVMAIL(CHKMAIL)'    (1)
 
          PARAMETER STYLE GENERAL                    (2)
           RETURNS NULL ON NULL INPUT  ;             (3)

 

(1) fait référence à CHKMAIL dans SRVMAIL (*SRVPGM)
(2) le passage de paramètres se fait sans gestion de la val. nulle
(3)
  la fonction retourne nul si un des argument est nul (il n'y aura pas d'appel)

Vous pouvez aussi créer des fonctions à l'aide du PL/SQL

 

les versions 5.2 et 5.3 amènent les clés générées automatiquement (compteur)

LA V6R10 continue la série des options OLAP, cette fois pour le GROUP BY


enfin , au fur et à mesure des versions, nous avons la possibilité d'avoir une vision graphique de la base de données
via Iseries Navigator :

sur un fichier, vous pourrez éditer son contenu ( ATTENTION ! ) ,


mais aussi avec le menu contextuel (clic droit)

- obtenir un aperçu (consultation uniquement)

- voir les caractéristiques d'un fichier (table ou vue)
(liste des champs ou description système)

remarquez ici, le nombre maxi d'enregistrements

créer un nouvel objet

Gérer les statistiques (nouvelle fonction de l'OS/400, pouvant éviter la création d'index)



Pour vos requêtes SQL, utilisez le gestionnaire de scripts CWBUNDBS.EXE
==> sur "base de données" (ou sur le nom "rdb" en 5.2), click droit, puis gestionnaire de scripts.



Vous pourrez :

• sauvegarder et relire un script SQL

• lancer tout ou partie du script

• voir l'historique du travail sur l'AS/400

• Obtenir des informations d'optimisation (VISUAL EXPLAIN)


ce dernier vous proposant, en V5r20, un outil de conseil (optimisation)


EN V6, Visual Explain peut être lancé et réactualisé, pendant l'exécution, les informations ayant bougé sont surlignées.



Dès la V5R20 une aide précieuse à la saisie d'un ordre SQL est fournie par F4




Pour terminer le gestionnaire de scripts subit de nombreux changements en V6R10

1/ une option ALLOW SAVE RESULT, permet la sauvegarde des enregistrements extraits:

 

ensuite, avec un clic droit sur les lignes affichées :


Les formats admis, sont :

Les paramètres de connexion (JDBC) peuvent être modifiés temporairement ou définitivement

et proposent maintenant l'affichage des COLHDG plutôt que les noms de zone en entête de colonne


La(les) requêtes(s) peuvent être sauvegardée(s) sur le serveur (fichier physique ou IFS)

Ce qui accompagne très bien le nouveau paramètre SRCSTMF de la commande RUNSQLSTM

 


Enfin, iSeries navigator est l'outil idéal de surveillance des performances Base de données

En V5R40

  1. Le centre de santé affiche des informations sur vos base en % des maximas DB2
  2. Les moniteurs SQL propose des sélections (bibliothèque, tables, durée) au lancement et à l'affichage
  3. Consultation du cache des plans d'accès avec le même affichage que les moniteurs
  4.   ce dernier suggérant les index manquant en temps réel (assistant de gestion des index)
  5. La liste des index indique quand un index a été utilisé, même implicitement pour la dernière fois

En V6R10

• Moniteurs

Sur un affichage récapitulatif, à l'affichage des instructions (Analyse, puis clic droit sur une ligne / instructions),
   l'option fichier propose, maintenant, une sauvegarde de la liste des instructions SQL

Sur le même affichage, vous pouvez maintenant, placer la requête SQL dans le gestionnaire de script avec les valeurs des variables, ou les marqueurs SQL (?)
     

Enfin, vous pouvez comparer deux moniteurs

 

• Cache des plans d'accès

- la taille peut être ajustée par CALL QQQOOOCACH PARM('R:1024')
         [tapez CALL QQQOOOCACH pour avoir une liste des paramètres.]
ou par iSeries Navigator V6 (Mémoire cache de plan SQL/propriétés)

Les possibilités d'affichage sur une instruction ont été étendues :

- l'affichage des instructions les plus longues est limité aux 500 premières
- vous pouvez demandez la liste des travaux utilisant actuellement cette instruction
-  et la liste des utilisateurs ayant utilisé cette instruction (historique de l'utilisateur)

Vous pouviez déjà en V5R40 sauvegarder le cache sous forme d'images instantanées :

par l'interface graphique sous Images instantanées de mémoire cache de plan SQL
par la procédure cataloguée DUMP_PLAN_CACHE , qui en V6 est automatiquement enregistrée au même endroit.

Quand le cache est plein il est automatiquement épuré, en V6 il est possible de placer un moniteur sur cet événement afin de le sauvegarder en fichier avant

• Gestion des index

Vous pouvez demander la liste des index pour un bibliothèque entière (et non table par table) en cliquant sur Tables

Vous remarquerez aussi l'affichage des MQT, la génération d'instruction SQL (toujours pour toute la bibliothèque)

l'assistant de gestion d'index (qui affiche les index suggérés, globalement, pour une bibliothèque ou pour une table) a été amélioré :

- Affichage de l'instruction SQL est nouveau en V6

- ainsi que l'accès direct aux instructions qui ont provoqué cette suggestion (dans le cache)

- l'assistant affiche aussi le nombre de fois ou un index a été suggéré et, s'il a été créé automatiquement (MTI), le nombre de fois ou il a été utilisé

Ce compteur peut-être réinitialisé pour la table, par le menu contextuel suivant :

L'affichage de l'instruction SQL pour un travail a été revu :

 

 

 

© AF400 - Volubis