Discussion :

[m4k-Hurrican]

Bonjour,

Me voilà à devoir corriger un problème sur un bon vieux programme en RPG ILE, avec un écran vert et ses DDS.
Ce programme étant sensible et conséquent (8000 lignes, sans compter les includes et procédures externes), je ne peux me permettre de le réécrire avec mes outils et interfaces habituels.

Cette saisie de commandes, affiche un sous-fichier des lignes, qui peut être tronqué ou non, via le mot-clé SFLDROP.
Quand on appelle une ligne en modification on lit le sous-fichier, on ouvre le format de saisie en bas d'écran, puis on met à jour le sous-fichier en conséquence quand l'utilisateur valide.
Çà fonctionne parfaitement, sauf dans un cas.
Si l'utilisateur appelle la ligne en modification, puis qu'il presse la touche liée à SFLDROP, l'écran affiche correctement le sous-fichier (tronqué ou étendu), mais à la validation, paf. CPF5011, Update sans Read préalable.
Or le SFLDROP est géré par le système, il se fait sans que le programme n'en sache rien (le contrôle n'est pas rendu, même avec une touche CF). Du coup, mon code n'est jamais au courant s'il doit relire le sous-fichier.

Quelqu'un a t-il déjà vécu la même chose, ou y aurait-il une idée de génie qui me permettrait de régler le problème ? Relire le sous-fichier avant de le mettre à jour est bien une solution, mais extrême, car il y a presque 80 champs dedans, qu'il faudrait sauvegarder avant lecture puis remettre après lecture.

[pwrdwnsys]

Est-ce qu'il y a le mot clé SFLNXTCHG ? peut-être en l'activant juste avant d'appeler l'écran de modification ?

[m4k-Hurrican]

Est-ce qu'il y a le mot clé SFLNXTCHG ? peut-être en l'activant juste avant d'appeler l'écran de modification ?

Oui, mais çà ne change pas mon souci. L'appui sur la touche F22 qui gère le SFLDROP, ne rendant jamais le contrôle au programme, il n'est au courant de rien.

Je sens que je vais devoir me taper une jolie copie de chaque champ en mémoire, puis relecture du sous-fichier, recopie dans l'autre sens des champs, puis update sous-fichier.
Tout çà parce que j'ai du ajouté un SFLDROP à la demande des utilisateurs.

[vazymimil]

Bonjour,

Je n'ai jamais rencontré le problème et je ne vois pas comment le résoudre autrement que par une relecture du SFL. Ceci-dit, peut-être qu'en lisant le SFL dans une ds déclarée en likerec et en ignorant le résultat de lecture l'opération serait plus simple ?

[m4k-Hurrican]

Bonjour,

Je n'ai jamais rencontré le problème et je ne vois pas comment le résoudre autrement que par une relecture du SFL. Ceci-dit, peut-être qu'en lisant le SFL dans une ds déclarée en likerec et en ignorant le résultat de lecture l'opération serait plus simple ?

J'ai déjà fait les modifs, backup, relecture et remise en place, des valeurs.
Mais effectivement, je n'y avais pas pensé, la relecture du sous-fichier dans une DS qualifiée m'aurait évité bien des manips, et serait bien plus efficace. Je vais peut être modifier mon code.
Merci.

Edit : Modif effectuée et validée, çà allège bien le code !