| 
Version 4.30 de l'OS/400 GRANDES ORIENTATIONS 1/ support de WARP server et de novell sur IPCS jusqu'en 2001 ! (sous entendu, après on ne sait pas) les deux produits sités vont restés figés ==> HORS de NT, point de salut ! 2/ IBM annonce que NT TSE (Terminal Server Edition, la suite de WInFrame) est compatible avec NT sur IPCS 3/ Rochester propose sur son site WEB une pré-version de la prochaine édition de Client Access : "Client Access Express" Il s'agit d'une version FULL IP (plus d'APPC, plus de routeur) |
|
Détail de la 4.30 WEB : + support de la certification X.509 (auparavent par API uniquement) et de SSL (sessions cryptées) + fonction cache amméliorée et fonctionnement en multi-thread. (c'est le deuxième produit après DOMINO) + Servlets JAVA (Applets s'exécutant sur le serveur) + NetQuestion : produit d'indexation et de recherche de vos pages WEB |
|
TCP/IP Filtrage IP Limitation et/ou journalisation des accès NAT Network Adresse Translation on construit une table des correspondances adresse-ip-locale/adresse-ip-externe et on masque complètement le réseau aux yeux extérieurs en fournissant des adresses Ip fictives (externes). LOAD BALANCING attribution d'une même adresse IP à deux cartes LAN. le système répartie la charge sur les deux cartes Dial ON Demand la connexion ne se fait qu'en cas de besoin (NUMERIS) |
|
Programmation : pas grand chose, - le compilateur C accepte les entiers sur 64 bits - le compilateur C admet comme source un fichier IFS - le compilateur C++ admet le SQL intégéré - java Toolbox for JAVA revue et intégrée à Visual Age for JAVA v2.0 Euro : support de l'Euro pour la version 4.30 ainsi que pour les versions : - V3R20 -- > via PTF - V4R10 & V4R20 -- |
|
Client Access : - nouvelle version 3.20 >support de WIndows 98 >ODBC version 3.0 >AFP Workbench version 32 bits et complète visualisation de spools AFP et d'images (TIFF, GIF) génération en mode WYSIWYG de *PAGSEG et *OVL >installation plus granulaire >support de TCP/IP sur Twinax - Pour Windows 3.1 >IP : support des noms d'écran et des sessions imprimantes |
|
IBM AS/400 SDK for ActiveX and OLE DB norme Microsoft (successeur d'ODBC ?) pour accèder à des inforamtions diverses. le problème d'ODBC est qu'il ne permettait d'accèder qu'à des bases de données relationnelles. or il existe d'autres types d'informations > annuaires par exemple ... ADO propose l'accès à des informations distribuées en retournant les données sous forme de fichiers à plats séparés par des tabulations et en technologie objet (ADO = ActiveX Data Object). le produit IBM (intégré à Client Access) permet donc l'accès - à la base de données en SQL - à la base en mode ligne à ligne (comme read, chain, ...) - aux données comme les data area, les dtaq, etc... - aux des commandes ou aux procédures cataloguées - .... |
|
L'accès peut se faire à partir de tout produit (sur palteforme Windows) supportant ActiveX. + Visual Basic (pour celui-ci il existe un assistant) + Delphi, Powerbuilder, Visual C++, ... + IIS (serveur Web de Microsoft sur NT) + Lotus 123, Excel, Access et autres produits bureautique Le produit AS/400 OLE DB Data Provider est la partie Run-time Ces deux produits sont livrés sur le CD-ROM de Client Access |
|
Operation navigator Ce produit a été complètement revu : l'installation est modulaire. les options suivantes sont nouvelles : > Envoi de messages (avant seule la visu était possible) > paramétrage des nouveautés TCP/IP (NAT, filtrage, ...) > Gestion des annuaires LDAP > gestion des actions admises des répertoires admis par utilisateur ! (V4r30 impératif) > Assistant de configuration de la sécurité (analyse ET propose) > Visualisation des performances de vos AS en mode graphique |
|
Operation navigator > gestion des journaux remote. > gestion des alias (voir ci-après) > Mise à jour des tables possible > copie/déplacement possible entre systèmes Netserver implémenté en V4R20, c'est la fonction voisinnage réseau de l'AS/400 > utilisation complète de LM 0.12(en V4r20 on utilisait seulement SMB) ==> performances accrues > l'AS/400 CLIENT des serveurs NT (nouvelle racine IFS : /QNTC) l'OS voit tous les serveurs NT du sous réseau IP, pour les autres, lancer la commande MD '/QNTC/192.168.1.5 (si telle est son adresse) |
|
DB2/400 C'est la partie la plus spectaculaire : - gestion des ALIAS un ALIAS permet de renommer un fichier (lui donner un nom long) ou préciser un membre pour un fichier multi-membres. CREATE ALIAS MABIB.MBR2_ALIAS FOR MABIB.FIC1P1 (MBR2) mettre à jour MBR2_ALIAS revient à mettre à jour MBR2 dans FIC1P1 ATTENTION : DROP TABLE nom-alias détruit le fichier PHYSIQUE il faut écrire DROP ALIAS pour supprimer l'ALIAS Un alias portant sur un fichier inconnu, peut exister. |
|
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. SUPPRIMER les clients sans commande : Delete from client C where not exists ( select * from commande where nocli = C.nocli ) Cette synatxe est maintenant acceptée dans la clause SET du UPDATE UPDATE command C set priha = (select pritarif from article WHERE codart = C.codart ) WHERE priha = 0 UPDATE recap R set SALAIRAN = (select sum(salair + primes) from personp1 where matricule = R.matricule) |
|
Les nouveaux Index EVI (Encoded Vector Index) à l'origine était l'index b-tree : +-------+ de A à N |AN - OZ| de O à Z +-------+ / \ / \ +-------+ de A à M |AM - N.| (tout ce qui est Nxxx) +-------+ / \ +------+ (tout ce qui est NAxxx) | A. | ____________ +------+ |TES=878787| <-- NANTES / \ / +------+ | N. | +------- ____________ \ |CY =124578| <-- NANCY |
|
Ces index fonctionnent très bien quand il s'agit de retrouver un petit nombre de clés dans un grand nombre d'enregistrements (type CHAIN) mais ils sont assez lents si vous réalisez une requête retournant 80 % des enregistrements, particulièrement lors des tris. En effet les enregistrements doivent être retournés dans l'ordre des clés et ils sont stockés dans physiquement sur le n° de RANG(dans le physique) Vous multipliez alors les E/S disque sauf si vous réorganisez souvent vos fichier par RGZPFM KEYFILE(xxx) ^ en indiquant le nom de l'index le plus fréquement utilisé ici ---! Certains SGBD utilisent la technique des index bitmap |
|
soit la table suivante : l'index bitmap associé sera ##################### rang # client ville # valeur bitmap ##################### ...................... 1 # 1 NANTES # : NANTES : 10000100 : 2 # 6 ANGERS # : ANGERS : 01000000 : 3 # 3 RENNES # : RENNES : 00100010 : 4 # 7 CHOLET # : CHOLET : 00010000 : 5 # 8 BREST # : BREST : 00001000 : 6 # 5 NANTES # : VANNES : 00000001 : 7 # 4 RENNES # :........:...........: 8 # 2 VANNES # 12345678 # # ##################### On place un "1" pour chaque enregistrement ayant cette clé à la position du n° de rang pour NANTES les enregistrements 1 et 6. |
|
Cette technique pose plusieurs problèmes : 1/ la place utilisée peut-être importante pour des clés composées. 2/ la maintenance d'une clé génère DEUX E/S (sur l'ancienne clé et sur la nouvelle) L'AS/400 n'utilise pas les index bitmap, par contre la technologie bitmap est utilisée pour gérer vos requêtes avec des tests depuis la V4R20. Il utilise un index B-tree pour chaque critère et construit un nuage de point (bitmap) sur chaque résultat, et applique une fonction booleènne AND/OR sur les deux. le résultat indique par un "1" la liste des enregistrements ayant vos un (OR) ou deux (AND) critères vrais. NANTES ou ANGERS fournit 10000100 puis 01000000 11000100 ==> les lignes 1,2 et 6. |
|
EVI pour finir, qui est un concept Rochester (il y a un brevet), l'AS/400 étant le premier à l'utiliser. EVI est une utilisation avancèe des index Bitmap Vecteur ##################### +-------------+ rang # client ville # ........................... | code | rang | ##################### : Table des symboles : +------+------+ 1 # 1 NANTES # :.........................: | 1 | 1 | 2 # 6 ANGERS # :Valeur:code:Deb:Fin: nbre: | 2 | 2 | 3 # 3 RENNES # : : : : : : | 3 | 3 | 4 # 7 CHOLET # :NANTES: 1 : 1 : 6 : 2 : | 4 | 4 | 5 # 8 BREST # :ANGERS: 2 : 2 : 2 : 1 : | 5 | 5 | 6 # 5 NANTES # :RENNES: 3 : 3 : 7 : 2 : | 1 | 6 | 7 # 4 RENNES # :CHOLET: 4 : 4 : 4 : 1 : | 3 | 7 | 8 # 2 VANNES # :BREST : 5 : 5 : 5 : 1 : | 6 | 8 | # # :VANNES: 6 : 8 : 8 : 1 : +-------------+ ##################### :......:....:...:...:.....: |
|
Le vecteur contient un poste par enregistrement, la position donnant le n° de rang, MAIS on indique un code et non une valeur de clé. tout cela lève les deux désavantages des index bitmap. On indique en plus une table des symboles qui contient - la correspondance entre chaque valeur de clé et son code associé - des statistiques destinées au "Query Governor" l'optimiseur de requêtes Il faut simplement indiquer le nombre de valeurs différentes lors de la création afin de savoir s'il faut créér un vecteur sur 1,2 ou 4 octets si vous ne connaissez pas ce nombre de valeurs différentes SQL va les rechercher pour vous et la création de l'index sera un peu plus longue CREATE ENCODED VECTOR INDEX on fichier(clé1, clé2, ...) FOR x DICTINCT VALUES |
|
On parle de place occupée divisée par 16 de temps de réponse divisés par 10 --> tout cela reste à vérifier sur VOTRE BASE ! Mais quand même, les tests du lab sont les suivants : sur un 53S (4 voies) avec une table de 255 GO sans index : 30 minutes b-tree : 18 minutes EVI : 0,58 minutes (il n'y a pas d'erreur de frappe !) ATTENTION : les index EVI sont destinés à SQL (et QUERY, QM, ...) ILS NE SONT PAS UTILISABLES PAR PROGRAMME (CHAIN, READ, etc) il nous faudra donc probablement faire cohabiter les deux ! |
|
DIVERS DB2/400 -------------- deux nouvelles commandes CPYTOIMPF (copy to imported file) et CPYFRMIMPF (from imported file) permettent l'importation/exportation de fichiers physiques de/vers des fichiers à plat avec séparateurs (type CSV). |
