base de données, recherchez l'entrée as-data. Pour démarrer un serveur hôte, utilisez la commande STRHOSTSVR. Par exemple, si le serveur de base de données ne figure pas sur l'écran WRKTCPSTS, entrez la commande STRHOSTSVR suivante pour démarrer le serveur en question :

STRHOSTSVR *DATABASE

Si le serveur hôte a démarré mais que la commande cwbping a échoué, il est probable que le client en réseau ne peut pas se connecter au serveur hôte. Le plus souvent c’est parce qu’un pare-feu personnel ou réseau bloque les ports TCP utilisés par le serveur hôte i. Cela n'est généralement pas un problème pour le Windows Firewall sur Vista et XP parce que la requête sortante ouvre le port approprié dans le pare-feu personnel. Mais ce n'est pas le cas pour la plupart des pare-feu d'infrastructure réseau ; là, les ports doivent être ouverts explicitement. Chaque serveur hôte i utilise son propre port TCP/IP. Par défaut, le serveur hôte base de données utilise le port 8471. La figure 1 donne un résumé des ports par défaut utilisés par System i Access.

En suivant les étapes ci-dessus, vous résoudrez la plupart des problèmes de connectivité client. Mais que faire si, bien que vous ayez une connexion, votre application client ODBC, OLE DB, ou .NET ne fonctionne toujours pas ? Vous devez alors déterminer si les jobs appropriés tournent sur le i.

Chaque serveur hôte utilise des jobs spécifiques sur le i. Le tableau de la figure 2 montre les jobs qui traitent les requêtes base de données. Le job daemon est à l'écoute des requêtes entrantes et les achemine vers le job du serveur approprié. QZDASOINIT traite la plupart des requêtes d'accès aux données. Si ces jobs ne sont pas actifs, essayez de redémarrer le serveur de base de données hôte comme expliqué précédemment.