Que faut-il faire pour mettre en oeuvre simultanément multiple exécutions d’un même job?

qu’une bonne mise à  niveau du matériel procure généralement une amélioration
en termes de traitements interactifs et de messages, sans beaucoup investir en
temps et en personnes. C’est le principal avantage des AS/400 à  n voies. S’il
faut augmenter le nombre de transactions par station de travail sur le système,
mais on a souvent atteint le maximum, on constatera sûrement une nette amélioration
du nombre total de transactions que l’on peut traiter.

Rappelons que le simple fait de passer sur un modèle à  CPU multiples n’améliorera
pas beaucoup un job batch unique, sauf si chaque CPU est bien plus rapide que
la CPU du système actuel. Pour obtenir une CPU plus rapide, il faut généralement
passer à  un autre groupe de modèles (de 720 à  730, de 730 à  740, par exemple).

Le fait que l’AS/400 puisse se doter de processeurs multiples facilite grandement
le développement des applications interactives et en mode serveur. Celles-ci traitent
en principe chaque requête dans un temps relativement bref (par rapport à  un job
batch). Par conséquent, on peut en avoir un grand nombre tournant simultanément,
chacune travaillant sur une transaction distincte pour plusieurs utilisateurs.
Ce n’est pas le cas du traitement base de données batch, où un job s’exécute longuement.

Avec un plus gros matériel, une banque peut, par exemple, traiter davantage de
transactions de guichet et DAB.
Mais, peut-elle traiter tous les enregistrements clients qui doivent l’être et
les sauvegarder avant l’ouverture du lendemain ?
Avec un matérielplus performant, une application de paie peut traiter davantage
de mises à  jour d’enregistrements employés et avoir davantage de cartes de pointage
en ligne.
Mais peut-elle aussi traiter la paiement final et débloquer les fonds (sous forme
d’impression de chèques ou de transfert de fonds) sur les comptes dans les temps
?

La plupart des anciennes applications, comme de nombreuses nouvelles applications
batch de mise à  jour base de données, sont conçues pour s’exécuter de manière
linéaire : elles lisent un enregistrement en entrée, mettent à  jour un fichier
(paient un intérêt à  un compte bancaire, appliquent des retraits et des dépôts,
par exemple), ou génèrent un nouvel enregistrement base de données dans un fichier
(ajouter des lignes détails à  un fichier de paie, par exemple). Au terme du traitement
de la base de données, les applications passent en mode génération de rapport.
On voit donc bien que les choses sont faites les unes après les autres, et qu’elles
ne sont pas conçues pour une exécution en parallèle.

Si l’on ne peut pas diviser le job en chaînes d’exécution parallèles, il est impossible
de bénéficier pleinement d’un processeur à  n voies. On améliore un peu les choses,
mais probablement pas assez pour que le job puisse traiter des volumes trés supérieurs.
La situation la plus probable dans ce cas est que certaines des tâches SLIC (System
Licensed Internal Code) s’exécutent sur un processeur et les jobs batch isolés
sur un autre.
Dans les applications de traitement interactif et batch, un job ou un thread n’utilise
qu’une CPU à  la fois. Mais, quand un grand nombre de jobs (de multiples jobs interactifs
ou serveurs simultanés, par exemple) s’exécutent, on peut piloter en même temps
plusieurs CPU d’un processeur à  n voies.