Discussion :

[Jutige]

Bonjour,

J'ai une problème concernant le temps de traitement d'un programme qui accès en lecture/écriture via les ordres natifs COBOL : read et write.
La volumétrie étant importante (6 millions d'enregistrement), je souhaite savoir si passer par IMS (ordre CBLTDLI) permettrait d'optimiser les temps d'accès aux fichiers ?
En vous remerciant d'avance.

Cordialement,

[Darkzinus]

De mémoire, l'intérêt d'IMS pour ce genre de traitement était surtout lié aux possibilités de redémarrage en cas d'Abend ce qui permettait de ne pas relire le fichier en entier en cas de plantage. Pour ce qui est du temps de traitement je ne sais pas s'il y a un réel gain. Mais après cela dépend surtout de ce que fait ton traitement, effectue-t-il des accès DB2 ?

[Jutige]

Merci Darkzinus de ton retour.
IMS gère une sorte de tampon et un procopt à GS (resp LS) pour la lecture (resp l'écriture) de fichiers permet d'optimiser le temps de traitement sur les fichiers volumineux.
D'où ma question.

C'est un traitement uniquement fichier-fichier, pas de DB2 en lecture ou écriture.

Y a pas de problématique lié au mode reprise.

[Luc Orient]

A mon sens, aucun intérêt à passer par IMS par accélérer le temps de traitement.

Bien au contraire, ça peut même être contre productif ...

[Darkzinus]

Cela étant, 6 millions de lignes c'est certes volumineux mais pas non plus extraordinaire pour du MAINFRAME. Il faut peut être voir du côté des instructions d'INITIALIZE par exemple s'il y a quelque chose à gagner en temps de traitement. S'il y a une également une bonne gestion des tableaux si ton programme en contient.

[el_slapper]

Cela étant, 6 millions de lignes c'est certes volumineux mais pas non plus extraordinaire pour du MAINFRAME. Il faut peut être voir du côté des instructions d'INITIALIZE par exemple s'il y a quelque chose à gagner en temps de traitement. S'il y a une également une bonne gestion des tableaux si ton programme en contient.

+1

6 millions de lignes, MVS est fait pour. Passer par IMS est hautement casse-gueule, pour un gain mineur et aléatoire. Les seuls problèmes de performances que j'ai eu se situaient presque toujours dans les accès référentiel(DB2 ou IDMS), et le peu qui restait dans des algorithmes non optimisés. Si il n'y a pas d'accès référentiel, alors voir l'algorithme.

P.S. : l'accès au fichier est-il indexé(genre VSAM)? auquel cas le plus performant est la bonne vieille méthode : on trie dans l'ordre d'accès prévue dans un séquentiel, et on fait tourner le programme sur le séquentiel.

Ce que je veux dire par là, c'est que si personne n'utilise les subtilités d'IMS, c'est que le risque ne vaut pas le bénéfice. En prenant le temps de mesurer les parties couteuses, on peut vraiment optimiser un traitement classique...qui restera classique, maintenable et utilisable.

[Luc Orient]

...
IMS gère une sorte de tampon et un procopt à GS (resp LS) pour la lecture (resp l'écriture) de fichiers permet d'optimiser le temps de traitement sur les fichiers volumineux.

Pour un fichier GSAM, le S qui suit le PROCOPT G ou L signifie :

Large-scale sequential activity. Use GSAM multiple-buffering option
(BUFFIO).

Source : IBM V12 - System Utilities


Il doit être possible de coder des options voisines sur un fichier classique (hors IMS) en jouant sur certains sous-paramètres du paramètre DCB de la carte DD du JCL (paramètre BUFNO par exemple).

Mais j'ai très rarement vu ce style de codage être utilisé ...