L’exécution de DLMSCR prend beaucoup de temps par bande, et la tâche prend beaucoup de temps lors de l’utilisation d’un lecteur de bande hors ligne

L’exécution de DLMSCR prend beaucoup de temps. Si vous examinez le journal sur la DLm, il peut s’écouler 2 ou 4 secondes entre les bandes traitées (que le traitement réussisse ou non). Ce qui différencie ce problème des autres problèmes de performances, c’est que le délai survient entre les résultats d’une bande (rayée ou non rayée) et la demande suivante. Souvent, la demande et la réponse dans cette situation sont presque immédiates, mais la demande suivante prend plus de temps. Cela exclut pratiquement la responsabilité des performances DLm ou back-end.

Ce problème est peut-être dû au partage d’un disque hors ligne avec d’autres programmes, tels que DLMCMD, DLMHOST ou GENSTATS, dans le même LPAR ou un autre. On ignore pour le moment si le problème peut se produire lorsque les programmes sont dans des LPAR différents.

Une fois la confirmation effectuée, veillez à ne pas partager simultanément les appareils hors ligne entre deux programmes différents.  Notez également que DLMHOST peut exécuter des commandes même en cas d’inactivité.  Modifiez l’une des tâches pour utiliser un autre appareil.

Pour confirmer ce problème, examinez le journal DLm pendant que le problème se produit.  Notez les heures des lignes DLm0500I pour la demande, et soit « DLm0501I » pour la bande rayée, soit un message DLm05xx avec un W ou E (DLm0524W est déjà rayée, DLm0523E est « créée trop récemment »), et il existe d’autres réponses d’erreur.  Un retard de la part de DLm0500I et de la réponse peut être dû à un problème de performances qui n’est pas l’objet de cet article de la base de connaissances.  Mais si le délai survient entre la réponse et la demande suivante, vous pouvez examiner plus en détail ces éléments :

Une exécution normale peut afficher plusieurs demandes dans la même seconde ; avec ce problème, il y a un écart de 2 ou 4 secondes entre la réponse à une demande (rayée ou non avec une raison donnée) et la demande suivante.

Cela est différent d’un possible problème de performances back-end, où le délai surviendrait entre la demande et la réponse.

Remarque : ces informations doivent provenir du journal DLm, en particulier lorsqu’un rapport complet est exécuté (pas seulement lors de l’envoi des bandes DLm récemment rayées).  Cela est dû au fait qu’il peut y avoir un certain nombre de demandes envoyées à la DLm qui ne parviennent pas au journal : les demandes de rayer une bande déjà rayée sont envoyées à la DLm mais ne sont pas répertoriées (le nombre total de ces bandes est inclus dans le récapitulatif à la fin).

Pour confirmer, effectuez une collecte de données du VTE sur lequel il s’exécute (en cas de ralentissement des performances) et ouvrez une demande de service.  Joignez la collecte de données à la demande de service et reportez-vous à cet article de la base de connaissances.  Il existe des informations sur la façon d’obtenir les commandes de canal et de constater que quelque chose est injecté dans les commandes normales pour rayer une bande.  Certaines de ces commandes, comme celles de DLMHOST, ont un délai de 2 secondes intégré : une ou deux de ces bandes (comme nous l’avons vu) ajoutent 2 ou 4 secondes par bande.