L'éventail des applications en langage REXX ne serait pratiquement limité que par l'imagination du programmeur s'il n'y avait le problème des performances d'un langage interprété. En fait il faut relativiser ce point : d'une part la puissance des machines croît au fil des années, d'autre part le volume des données à traiter est le plus souvent très raisonnable, les limites ne dépendent que du soin apporté à l'écriture des programmes. Les quelques conseils qui suivent ne sont pas applicables systématiquement, il faudra toujours rechercher le meilleur compromis suivant les circonstances.
Concevoir les programmes de façon modulaire (structurée), ainsi un prototype écrit en REXX sera traduit en C sans problème.
Une notion importante en programmation efficace est celle de code réutilisable, certaines fonctions peuvent faire l'objet de sous routines externes ou incorporées. Mais il ne faut pas tomber dans le travers de les rendre universelles au prix d'un code trop lourd, mieux vaut adapter des structures types ou squelettes.
Pour les accès fichiers :
- structurer les données en vue d'une lecture ou recherche aisée ;
- séparer les lecture et écriture sur un PC (sauf si deux disques physiques différents) ;
- lire ou écrire les fichiers en entier par 'EXECIO' sous VM et TSO, en totalité ou du moins en gros blocs sous WinX et Linux et travailler en mémoire.
Inversement le traitement des données dans les applications interactives peut être fractionné, un temps de réponse de l'ordre du quart de seconde à l'écran est transparent pour l'utilisateur (voir le programme du paragraphe 6.1.1).
Chercher tout d'abord à remplacer les boucles répétitives par des fonctions internes : Pos() ou Wordpos() pour les recherches, ou externes si disponibles : SysStemSort() pour un tri de tableau, etc... ou un utilitaire proposé par le système.
Sinon éviter si possible dans le bloc d'instructions :
- les débranchements, mieux vaut écrire quelques lignes supplémentaires car une sous routine est interprétée à chaque appel ;
- les structures conditionnelles en séparant en boucles distinctes suivant les cas, ou tout au moins tester le plus fréquent en premier.
Les commandes système différentes sont le seul obstacle à la portabilité d'un environnement à l'autre. La transposition est plus facile à l'intérieur des groupes VM et TSO d'une part et WinX et Linux de l'autre. Un programme peut même fonctionner indifférement sous l'un ou l'autre système d'un groupe : il suffit d'identifier l'environnement et soumettre la bonne commande, ou pour le second groupe utiliser les fonctions externes si présentes des deux côtés (par exemple SysFileTree() au lieu de 'DIR' ou 'ls').
La traduction dans une autre langue est facilitée en regroupant les messages dans un tableau initialisé en début d'exécution, voire dans un fichier (utiliser les services d'ISPF sur les grands systèmes).
© G. Navarre, 2003 - 2006.