Les fonctions GPC36/38 utilisaient l'émulation 5250 pour communiquer avec le mini, c'est à dire que la transmission d'informations se faisait via les buffers écrans. PCS/400 et C/A sont basés sur un autre concept: le dialogue APPC. rappel sur le dialogue APPC: Deux pgms situés sur des machines différentes engagent une conversation. L'un de ces deux programmes est à l'origine du dialoque (pgm source) et demande au système éloigné l'initialisation du pgm cible à l'aide de EVOKE(nom-pgm) Cette conversation est architecturée et mise en oeuvre par des verbes répertoriés dans l'architecture SNA sous le nom LU 6.2 Démarrer PCS sur le micro c'est initialiser un pgm sur le micro (le routeur) qui va activer, PAR FONCTION PCS, un job sur l'AS/400 (fonction EVOKE, traitée soit dans QCMN, soit dans QXFPCS/QSERVER pour les dossiers partagés). |
Sur le micro, c'est toujours le même programme qui dialogue. Mais sur l'AS/400, le routeur génére un job par fonction - un job par session WSF (pour le dialogue AS-Micro) - un job pour les dossiers partagés. - un job pour la fonction message - ... etc ... Chaque travail sur l'AS/400 va être initialisé avec l'ID Utilisateur COMMUN et le mot de passe, demandé au démarrage du routeur. (la fonction EVOKE permet d'indiquer sous quel profil doit être initialisé le JOB sur le système source) Le dialogue que vont engager ces programmes est un dialogue APPC ayant pour but de réaliser les fonctions demandées. Ce qui explique en partie le nombre de job que la fonction PCS génère sur l'AS/400 (sans parler des jobs de la fonction WSF/émulation-écran, puisque chaque ouverture de session va générer elle aussi un job). Vous pouvez mettre en oeuvre un dialogue APPC micro-AS/400 en écrivant |
les programmes sur micro: Tout langage capable d'utiliser les DLL WINDOWS (Visual Basic, Pascal ou C pour WINDOWS, etc...) sur AS/400: Définition d'un fichier ICFF, puis traitement en RPG,COBOL,... La DLL WINDOWS livrée avec PCS/400 est EHNAPPC.DLL ROUTINES: EHNAPPC_Allocate EHNAPPC_RqsToSend EHNAPPC_ExtendedAllocate EHNAPPC_Flush EHNAPPC_SendData EHNAPPC_QuerySystems EHNAPPC_ReceiveAndWait EHNAPPC_GetCapabilities EHNAPPC_ReceiveImmediate EHNAPPC_IsRouterLoaded EHNAPPC_Deallocate EHNAPPC_QueryConvState EHNAPPC_Confirm EHNAPPC_QueryUserId EHNAPPC_SendError EHNAPPC_GetAttribute EHNAPPC_PrepareToReceive EHNAPPC_GetDefaultSystem EHNAPPC_Confirmed EHNAPPC_RemoteProgramStart |
Une extension à APPC est APPN. APPN offre : Une gestion de réseau d'égal à égal(pas de centre "directeur") Une configuration semi-automatique (chaque AS/400 ne connaît à priori que les machines qui lui sont directement adjacentes, à chaque connexion les machines s'échangent la topologie du réseau,par le biais de "control-point sessions".) Des fonctions de routage + à chaque ligne sont attribués des poids définissant les caractéristique de celle-ci (vitesse,coût,sécurité,..) + à chaque session vous associez les paramètres souhaités (par l'intermédiaire des classes de service/*COSD) + le système examine les différents chemins possibles pour accéder au système éloigné et choisit celui qui se rapproche le plus de vos souhaits (classe de service) La possibilité de définir plusieurs contrôleurs avec le même nom de lieu éloigné(il faut alors définir un N° de TG= Transmission Group) ET SURTOUT, le passage par des noeuds intermédiaires est |
transparent (pas de pgm activé sur ces systèmes), APPN n'utilisant que les couches BASSES SNA (niveau MI) ce qui offre la possibilité d'utiliser - DDM, DRDA, ... avec des systèmes intermédiaires. - SNADS, PASSTHRU en direct(sans initialiser de job sur les systèmes traversés) ...TOULOUSE.......... ..MARSEILLE........... ..LILLE.............. : ####### : : : : ####### : : # PGM # : : : : # PGM # : : ################ : : : : ################ : : # ICF # : : : : # ICF # : : ####### : : : : ####### : MI : ! : : : : ! : MI : ! : : : : ! : : ! : : !------------! : : ! : : ! : : ! ! : : ! : : ! : : ! ! : : ! : : !------------! !------------! : :...................: :....................: :...................: |
Il existe trois types de noeuds APPN. 1/ LEN Low Entry Node = système capable d'utiliser un réseau APPN, sans y participer pleinement (il faut sur ce type de système définir tous les interlocuteurs comme s'ils étaient adjacents). Il ne peut communiquer qu'avec un seul noeud du réseau. 2/ EN End Node (noeud "terminal")=système participant à un réseau APPN (pleinement), mais ne gérant pas le réseau (ne fournit pas la topologie du réseau) 3/ NN Network Node = système gérant le réseau APPN (fournit la topologie du réseau à tous les NN et EN qui lui sont adjacents) Un micro sous PCS/400 est LOW ENTRY NODE, il peut utiliser un Réseau APPN reconnu par l'AS/400 auquel il est attaché: -attachement SDLC, LAN (Ethernet/Token Ring), TDLC (via twinax) -MAXI = 40 conversations avec 32 systèmes différents. |
Pour connecter votre micro à deux AS/400 (ou plus) avec PCS : Fichier CONFIG.PCS avec une connexion twinax RTYP 5250 <- 5250 = twinax RTLN APPN.nom-pc <- nom du PC dans le réseau EMLI nom-AS,adresse <- connexion physique ADRS nom-ASl,nom-ASp <- connexion APPN La ligne ADRS permet de définir une connexion logique (APPN/LEN) nom-ASl est le nom du système sur lequel vous voulez vous connecter. nom-ASp est le nom du système sur lequel vous êtes physiquement connecté Pour connecter votre micro à deux AS/400 avec Client/Access : Ajoutez un ligne SYSTEME= dans la section [SIDEINFO] du fichier NSD.INI Il doit exister une liaison APPN entre les systèmes, le système auquel vous êtes connecté directement doit être *NETNODE ! |