Ce scénario explique ce qui se passe lors du démarrage du serveur lorsque la fonction de reprise de console est activée et que plusieurs connectivités Operations Console sont utilisées. En d'autres termes, une unité de console locale directement raccordée (il ne peut y en avoir qu'une) est connectée, ainsi que trois unités Operations Console de réseau local.
Configuration : le type de console est Operations Console (LAN). Le PC directement connecté s'appelle CABLED, et les PC LAN s'appellent LAN1, LAN2 et LAN3. Le mode sans opérateur est utilisé (mode normal) et un IPL est effectué sur le serveur. Lorsque l'unité de console est déterminée lors de l'IPL, la première unité à se connecter dont le type est indiqué par le paramètre de console (réseau local dans notre exemple) devient la console et affiche les écrans de console habituels correspondant au type et aux circonstances associés au démarrage du serveur. Sur chaque unité supplémentaire qui se connecte affiche l'un des deux écrans.
Supposons que LAN1 soit la première unité connectée. Au cours du démarrage du serveur, cette unité affiche les modifications d'état comme n'importe quelle autre console, puis éventuellement la fenêtre de connexion au système d'exploitation i5/OS. LAN2 et LAN3 affichent un écran d'ouverture de session DST spécial avec une nouvelle ligne de données indiquant ATTENTION : Cette unité peut devenir la console. Le reste de la fenêtre est identique à la fenêtre d'ouverture de session DST. L'unité appelée CABLED ne se connecte pas initialement, car son type ne correspond pas à Operations Console (LAN). Toutefois, si l'adaptateur de communication asynchrone est activé avec la fonction 66, la fenêtre Etat des informations console s'affiche pour permettre à l'utilisateur de lire les données associées à la console en cours. La zone Reprise de console contient la valeur NON du fait que le type n'est pas correct, le type correct étant Operations Console (LAN). Sur LAN2, un utilisateur pouvant reprendre la console se connecte. Cet utilisateur voit le même écran Etat des informations console, et la zone Reprise de console contient OUI pour indiquer que la reprise est possible. Sur LAN3, un utilisateur sans le droit de reprise de console se connecte. La zone Reprise de console contient la valeur NON pour indiquer que l'utilisateur n'est pas autorisé à effectuer la reprise.
A ce stade, une seule unité remplit toutes les conditions pour une reprise de console. Au bas de de l'écran, F10=Remplacer la connexion console s'affiche. En appuyant sur F10, l'utilisateur voit apparaître l'écran de reprise de la connexion de console à partir d'un autre utilisateur. Il s'agit d'une fenêtre de confirmation qui donne à l'utilisateur une dernière possibilité d'annuler la reprise. A ce stade, si l'utilisateur sélectionne 1 et appuie sur Entrée, la reprise a lieu. Presque immédiatement, LAN1 obtient l'écran d'ouverture de session DST spécial, et LAN2, l'unité qui a initié la reprise, dispose d'exactement du même écran que LAN1 au moment où le transfert a eu lieu. Tout travail qui était en cours d'exécution se poursuit comme si de rien n'était. En fait, la console d'origine peut être en train d'installer le microcode sous licence ou le système d'exploitation i5/OS, ou même d'exécuter une sauvegarde complète du système dans l'état restreint sans que le serveur s'en rende compte. Vous pouvez même déconnecter la connexion console, vous reconnecter ultérieurement et obtenir les données de l'écran du travail en cours sans aucune incidence sur celui-ci. Si un volume important de données d'écran a été envoyé par le travail et que ces données n'ont pas pu être envoyées, elles sont stockées. Lorsqu'une console est reconnectée par un utilisateur autorisé (détenant le droit de reprise de console) à partir d'une unité éligible, l' utilisateur peut voir une suite de régénérations d'écran rapides jusqu'à ce que toutes les données stockées soient envoyées. En réalité, le fait de se déconnecter, puis de se reconnecter est considéré comme une récupération et non une reprise.