Discussion :

[m4k-Hurrican]

Bonjour,

Je tourne en rond sur un truc dingue, qui ne m'étais jamais arrivé, et je pense être tombé sur un bug du compilateur.
Je pose le tableau. La version d'abord, V6R1. PTF à jour.
J'ai un programme (RPGLE), chargé de gérer les affichages/créations/modifs/suppressions d'enregistrement d'un fichier.
Il a un paramètre d'entrée (un code client), mais ce paramètre n'est pas obligatoire. J'utilise souvent une technique consistant à tester (dans un Monitor) la valeur du paramètre d'entrée pour savoir s'il est transmis, ce qui me permet par exemple ici de limiter les enregistrements affichés (ou créés/modifiés/supprimés) à un seul client.
Tout se passe bien si j'appelle le programme directement sans passer le paramètre. La liste principale s'affiche correctement, et lorsque j'affiche le format de création (un format de contrôle avec son sous-fichier), toutes les zones sont bien ouvertes à la saisie.
Maintenant si j'appelle le programme en passant un code client en paramètre, la liste principale s'affiche correctement, mais l'affichage du format de création pose un gros souci. Les zones normalement ouvertes en saisie sont bien soulignées, mais le curseur est en haut à gauche, et tout est verrouillé.
J'ai vérifié les indicateurs, ils sont OK (strictement identiques à ce qu'ils sont lorsque l'appel se fait sans paramètres).
L'EXFMT du format de contrôle est bien OK.
Je n'ai aucun mot-clé Lock qui traine dans le DSPF.
Je suis à court d'idées, je tourne le code dans tous les sens depuis ce matin, j'ai fait debug sur debug, et je n'ai même pas trouvé de solution pour contourner le problème.
Avez-vous une idée de ce qui pourrait se passer ?

[dlandr]

Bonjour,

normalement, on teste la transmission d'un paramètre de la façon suivante (où p_client est le paramètre reçu à tester) :

if %parms >= %parmnum(p_client) and %addr(p_client) <> *null;
w_client = p_client;
endif;

%parms représente le nombre de paramètres transmis et %parmnum le rang du paramètre dans la liste transmise.
%addr permet de voir si le paramètre a pu être omis (options(*omit))

Mais quel peut être le lien avec la gestion de l'écran ? il faudrait les sources (écran et programme) pour trouver une piste....

[m4k-Hurrican]

J'utilise %parms dans mes procédures, mais pas dans les programmes j'avoue (surtout que certains doivent tourner sur de vieilles machines).
Difficile de coller le code du programme et de l'écran ici.
De toute manière je suis en rapport avec IBM depuis ce matin, on cherche si une PTF ne manquerait pas, malgré tout. Un symptôme "semblable" a été corrigé mais pour les compilateurs CLE et CLLE.Reste que je vois gros comme une maison qu'ils vont finir par me demander de passer en V7, et çà c'est pas possible.

[m4k-Hurrican]

Je viens de faire un test parce que çà me sort par les yeux cette histoire.
Avec une copie du programme, j'ai retiré le test des paramètres, et je passe toujours le code client. 0 si pas de client, sinon le code.
Et bien ... pareil !
Et du coup j'ai fini par isoler le problème, sans pour autant avoir de solution.
Ce format pour lequel toutes les zones se retrouvent verrouillées, comme si elles avaient toutes un DSPATR(PR) actif, est un format de contrôle de sous-fichier.
Si le sous-fichier contient des enregistrements, ce qui est le cas pour un client connu (donc avec le code client renseigné), le format de sous-fichier se retrouve verrouillé.
Si le sous-fichier est vide (cas du client non transmis), le format de contrôle fonctionne correctement.

Et je ne comprend pas pourquoi !
Les indicateurs sous-fichier et format de contrôle, sont OK.
Pas de mot clé PROTECT ou LOCK.
La compilation de l'écran ne présente aucune erreur (pas de chevauchements).
Il n'y a comme opération d'entrée/sortie, que le write du format guide de touches (qui efface l'écran), suivi de l'exfmt du format de contrôle (en overlay).

3 jours que je me bagarre avec çà, que je charge et applique toutes les PTF existantes pour la V6R1, que je vérifie, teste et reteste écran et RPGLE.
Je deviens dingue.

[m4k-Hurrican]

J'ai enfin réussi à remonter jusqu'à la source !
Et le fait est, que le problème n'est pas dans le programme, comme je m'en doutais.
J'ai conclu de tous mes tests, que quelque chose dans le sous-fichier posait souci.
J'ai donc décidé de retirer les champs un à un pour trouver si l'un d'eux provoquait l'erreur.
Et bizarrement, c'était un champ tout bête (le code utilisateur, champ character de 10 de long codé en 1147).
J'ai donc étudié ce champ de plus près, et j'ai découvert, que pour une raison que j'ignore encore (mais il va falloir que je trouve), 2 enregistrements étaient "vérolés".
En fait ils contenaient un code hexa 10, en plus des caractères habituels. Après nettoyage de ces champs, tout est rentré dans l'ordre !
Me reste donc a trouvé quel programme/procédure a pu généré çà (merci les journaux ! ), corriger l'erreur, et surtout, mettre une contrainte pour éviter que çà se reproduise.