Discussion :

[le_thon]

Bonjour,

Je cherche à imiter PDM …
Cela veut dire :

• afficher un sous fichier (nombre d'enregistrements du physique inconnu, mais possiblement et certainement supérieur à 9999).
• possibilité de saisir des options.
• possibilité de se positionner dans la liste (même au delà du 9999 iéme enregistrement du fichier physique) sans perdre les options saisies avant.

De plus après validation par "entrée", toutes les options saisies doivent être traitées (même si options saisies sur les enregistrements 12, 15782 et 271687)
Donc le fait de se repositionner dans la liste ne doit pas supprimer les options déjà saisies dans la liste.

Bien sur, une action sur une touche de fonction annule toutes les options saisies SAUF F16 (début de liste) ou F17 (fin de liste).

En clair ce que fait PDM.
A vos stylos pour me proposer une solution.

Bonne année.

[badaze]

Bonjour,

Quel est le budget ?


J’oubliais. Même avec PDM il y a une limite dans le nombre de lignes d’un sous fichier. Je ne connais pas sa valeur exacte mais c’est dans les 32.000.

[pwrdwnsys]

Bonjour.
C'est "juste" une manière de programmer : il faut charger un SF dynamique avec un SFLRCDNBR qui ne part pas de 0, mais d'une valeur "médiane" (ex. : 5000), histoire de pouvoir charger des pages en avant et en arrière, et de charger complètement le SF en cas de répétition d'une option à partir d'un enregistrement. Mais c'est plutôt compliqué à gérer. Et de mémoire, le SFLRCDNBR est déclaré en 4.0, donc 9999 enreg. maxi dans le SF.
Après, il reste la solution de la programmation en MI, voire en PNLGRP, pour les spécialistes, mais c'est pointu.

[dgayte]

Bonjour,

il y a la possibilité de n'avoir dans le sous fichier que les enregistrements d'une seule page. A chaque pagination avant ou arrière, on met à blanc le sous fichier et on le rempli avec les seuls enregistrements à afficher. C'est un peu plus complexe au niveau programmation, mais, du coup, on n'a plus de limites liées au sous-fichier.

Toutefois, on peut s'interroger sur l'utilité de proposer à l'utilisateur plus de 9 999 enregistrements, soit au moins 500 pages… il faut peut être proposer un filtre qui permettra à l'utilisateur de préciser sa demande. A notre époque, je ne vois pas un utilisateur paginer plus de 500 fois avant d'avoir son information !

Dominique

[badaze]

Bonjour,

il y a la possibilité de n'avoir dans le sous fichier que les enregistrements d'une seule page. A chaque pagination avant ou arrière, on met à blanc le sous fichier et on le rempli avec les seuls enregistrements à afficher. C'est un peu plus complexe au niveau programmation, mais, du coup, on n'a plus de limites liées au sous-fichier.

Toutefois, on peut s'interroger sur l'utilité de proposer à l'utilisateur plus de 9 999 enregistrements, soit au moins 500 pages… il faut peut être proposer un filtre qui permettra à l'utilisateur de préciser sa demande. A notre époque, je ne vois pas un utilisateur paginer plus de 500 fois avant d'avoir son information !

Dominique

Il y a très très longtemps j’avais fait un sous fichier dynamique avec des écrans virtuels car ce que je devais afficher tenait sur plus de 80 colonnes. Cerises sur le gâteau je faisais aussi des totalisations sur 5 niveaux.
J’ai aussi fait une simulation de sous fichier avec uniquement des champs « fixes » pour simuler la saisie des requêtes SQL dans STRSQL.

[condate]

Bonjour,

il y a la possibilité de n'avoir dans le sous fichier que les enregistrements d'une seule page. A chaque pagination avant ou arrière, on met à blanc le sous fichier et on le rempli avec les seuls enregistrements à afficher. C'est un peu plus complexe au niveau programmation, mais, du coup, on n'a plus de limites liées au sous-fichier.

Toutefois, on peut s'interroger sur l'utilité de proposer à l'utilisateur plus de 9 999 enregistrements, soit au moins 500 pages… il faut peut être proposer un filtre qui permettra à l'utilisateur de préciser sa demande. A notre époque, je ne vois pas un utilisateur paginer plus de 500 fois avant d'avoir son information !

Dominique

Oui, c'est comme cela qu'il faut le faire. N'afficher que les enregistrements d'une seule page. En cas de défilement avant ou arrière, stocker les options saisies en tableau avec une identification des lignes devant lesquelles ces options ont été saisies. Idem en cas de repositionnement. Faire un système qui montre les options stockées en tableau lorsque l'on ré-affiche les mêmes lignes.

Et lorsque l'on valide globalement par "ENTREE", toutes les options stockées dans le tableau sont exécutées.

Je fais comme cela depuis des années. Je pense que PDM utilise un système similaire.

C'est très sportif, mais une fois que le modèle est fait, il suffit de le reprendre d'un programme à l'autre. L'identifiant de ligne que j'utilise est le rang de l'enregistrement affiché. (Attention, cela ne fonctionne plus en cas d'affichage de logique joint).

[le_thon]

Bonjour et merci pour vos solutions.

Celle de condate me semble la plus pertinente à ceci près qu'un tableau est lui aussi limité.
C'est pourquoi je vais utiliser un fichier de travail qui va stocker la clé du fichier affiché et l'option choisie.
Le code n'est pas si compliqué que cela.

Encore merci et bonne journée.

[condate]

J'ai probablement manqué de clarté. Lorsque je stocke en tableau, je ne stocke QUE les options saisies et les identifiants des enregistrements que l'utilisateur a choisis. Je peux donc afficher et me repositionner dans un ficher base de données comportant des milliards d'enregistrements sans aucun problème. Par contre il est vrai que l'utilisateur ne pourra pas saisir plus de 9999 options globalement.

De plus, gérer ceci dans un fichier, c'est choisir un bulldozer pour écraser une noix (créer le ficher, gérer les conflits lorsque plusieurs programmes utilisent ce ficher de travail, sans compter la récursivité si on la gère). Franchement en tableau c'est le top, Bien entendu penser à remplir le tableau de travail par la fin (poste 9999 puis 9998.... etc), parce qu'à un moment vous devrez faire un LOOKUP pour voir si un identifiant à afficher est déjà associé à une option saisie. Il faudra donc lancer ce LOOKUP à partir du niveau courant de remplissage du tableau sinon vous constaterez des temps de réponse un peu difficiles.

Cerise sur le gâteau, si vous voulez réordonner votre sous-fichier en changeant d'index de lecture en cours de saisie d'options, si vous n'avez pas effacé ce tableau de travail, vous constaterez que vous récupérer vos options déjà saisies devant les bons enregistrements selon le nouvel ordre d'affichage. (Les rangs d'enregistrements d'un fichier logique sont ceux du fichier physique tant que ce n'est pas un fichier logique joint).

NB: Personne ne s'est encore jamais plaint de ne pas pouvoir saisir plus de 9999 options. J'attends toujours !!!

[le_thon]

Bonsoir Condate

Pas de problèmes pour les conflits d'accès à ce fichier de travail. Il suffit d'appeler le programme au travers d'un CLP qui fait ceci (création par copie du fichier dans QTEMP). Je fais toujours ceci pour les fichiers de travail. Pour les autres fichiers, je met le paramètre WAITRCD à *NOMAX lors de la compilation des PF. Ca évite bien des problèmes …

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
              DLTOVR     FILE(*ALL)      
              MONMSG     MSGID(CPF0000) 

              DLTF       FILE(QTEMP/TESTO)  
              MONMSG     MSGID(CPF0000)

              CPYF       FROMFILE(WORK) TOFILE(QTEMP/WORK) +         
                            CRTFILE(*YES)                               
              MONMSG     MSGID(CPF0000)                                
                                                                      
              OVRDBF     FILE(WORK) TOFILE(QTEMP/WORK) MBR(*FIRST)   

              CALL       PGM(TEST)                                    
                                                                       
              DLTF       FILE(QTEMP/WORK)                             
              MONMSG     MSGID(CPF0000)                                
                                                                       
              DLTOVR     FILE(*ALL)                                    
              MONMSG     MSGID(CPF0000)

Donc ceci règle le problème des conflits d'accès. Pour la récursivité, j'évite de faire.

En ce qui concerne la gestion des différents ordres de classement de la liste, il suffit de prévoir l'ensemble des clés dans le fichier de travail et d'avoir les mêmes fichiers logiques sur le fichier de travail que sur le fichier à lister.
Ils seront aussi créés par copie dans QTEMP par le CLP.

Ensuite le programme doit lire le fichier de travail à chaque chargement d'une ligne dans le SFL (pour récupérer et repositionner l'option éventuelle), mettre à jour le fichier de travail dans le cas de pagination ou repositionnement ou changement ordre de la liste (une option a put-être ajoutée, modifiée ou supprimée), et enfin traiter le fichier de travail quand ENTREE (en pensant au F12 sur un programme de traitement d' une option, qui doit ramener sur le programme de liste en gardant les options non traitées).

En tout cas, merci beaucoup pour vos idées, remarques et avis.

Bonne soirée.

[condate]

En fait, ce qu'il nous manque à nous autres développeurs AS/400, ce sont des modèles de programmation de qualité qui pourraient servir de référence dans le monde AS/400 au lieu que chacune fasse sa tambouille dans son coin. Il est peut-être encore temps de lancer un tel chantier ?

L'avantage, est qu'en confrontant les idées et les expériences de chacun, nous pourrions avoir des standards communs, strictement référencés dans lesquels nous pourrions puiser selon nos besoins. Il faudrait de plus que ces standards soient ouverts à la critique afin de les faire évoluer selon les bugs trouvés ou les améliorations souhaitées. A nous tous, on pourrait peut-être se faire d'excellents modèles non ?

Comment pourrions-nous faire ? Existe t'il une plateforme spécialisée dans l'hébergement de modèles de programmation ? Avez-vous des idées ?

[le_thon]

Bonjour condate

Je suis en train de réaliser un tutoriel dans ce sens qui devrait être publié sur le site (si tout va bien). J'ai choisi volontairement le langage RPG 3 en raison de la rigueur qu'il impose (surtout au niveau de la base de données). Il ne traite que de la partie interactive d'une application. Je pense qu'il est plein de bonnes idées, mais bien sur il y aura toujours des choses a améliorer. Il doit permettre de créer très rapidement et simplement une appli (1 journée de dév pour gérer un fichier avec programmes de liste, modif, création, copie, suppression et visu) tout en simplifiant la maintenance ultérieure.
Je devrais avoir terminé d'ici 15 jours et si tu es abonné à la News letter, tu devrais le voir prochainement.

Ce tutoriel devrait répondre à ta demande.
Bonne journée

[m4k-Hurrican]

RPG 3 ?
Mais c'est antédiluvien !
Plus personne ne programme en RPG 3. Le minimum c'est le RPG IV ILE, et question rigueur justement il est bien mieux positionné. ne serait-ce qu'à cause des appels de procédures.

J'avoue que de mon côté, tout ce qui est écran vert désormais c'est de la maintenance.
Les nouveaux programmes sont tous développés autrement (PHP ou VB.net). C'est certes un peu moins réactif en règle générale (bien que le PHP soit surprenant), mais autrement plus efficace.
Un écran d'aujourd'hui de taille raisonnable (22 ou 24"), ne peut se contenter d'afficher aussi peu d'informations (27x132 maxi).
Et devoir limiter la taille des champs parce qu'on a pas de place sur l'écran est inconcevable.
Afficher une image est parfois essentiel, le glisser-déposer aussi, etc...

Autant je défends ce serveur pour ses qualités, autant je me dis qu'IBM a fait une sacrée boulette en arrêtant VisualAge RPG. Il fallait au contraire y mettre plein de ressources, et peaufiner cet outil. Le System i serait vu totalement différemment aujourd'hui.

[le_thon]

Bonjour m4k-Hurrican,

Loin de moi le désir de polémique … mais voici quelques éléments qui étayent le choix que j'ai fait pour le RPG 3.

Tout d'abord, c'est le premier compilateur RPG (à description de fichier externe) implémenté sur AS400. Je pense qu'il est plus évident d'apprendre n'importe quel langage par ses fondamentaux plutôt que de commencer avec la dernière version. Aller de l'avant est plus facile que revenir en arrière.
J'ai trop vu de code ILE ou free format tellement mal écrit (par manque de bon sens ou par envie de se faire plaisir) que j'ai préféré supprimer le source et le réécrire.
Avec les nouveaux code opération proposés, on ne sait plus comment programmer un contrôle de date ou transformer un chiffre en lettres … Pourtant ce sont des grands basiques de programmation.
Ensuite, l'ensemble du code et des codes opérations du RPG 3 se retrouvent en ILE ou en free format. Donc rien empêche d'écrire un programme ILE ou free format en utilisant uniquement du RPG 3.
Une contrainte propre au RPG 3 : la longueur des facteurs 1 et 2 est limitée à 6 caractères. Donc il faut limiter la longueur du nom de chaque champ de fichier à 6 caractères (pas leur longueur ou type …), tout en pouvant les rendre unique. Avec cette contrainte, la description (pas fonctionnelle mais physique) de la base de données est éclairante si l'on applique une bonne méthode.

Au départ (et c'est toujours d'actualité) l'AS400 est surtout une machine utilisée dans les PME/PMI et orientée "gestion". Les écrans "verts" sont encore légion et je ne parle pas des émulations 5250. (Si tu vas faire un tour dans la boutique du "contrat de confiance" et bien d'autres aussi, tu jettes un œil sur leurs écrans) … Les écrans 24 pouces (voir plus) prennent trop de place sur un petit comptoir de point de vente ou renseignement dans un magasin.
Avoir beaucoup d'informations sur une page n'est pas forcément l'idéal, on est obligé de rechercher celle dont on a besoin. En 24 lignes par 80 colonnes on a 1920 caractères, en 27 lignes par 132 colonnes ça fait 3564 … C'est déjà pas mal … Si tu veux afficher 20.000 caractères sur une page, c'est qu'il y a un gros problème.

En dernier lieu, l'utilisation de l'AS400 comme base de données pour des applications Web ou se servir d'un AS400 pour générer sur un serveur (UNIX, Win ou autre) des documents avec un traitement de texte ou un tableur sont de très bonnes choses. Il ne faut pas oublier que l'AS400 est avant tout un ordinateur destiné à la gestion et pas aux graphismes.

[badaze]

On est un peu OT. Pour moi aussi l’AS400 est une super machine. Certes ce n’est pas beau mais c’est efficace et ça ne plante quasiment pas (hormis le hardware). J’ai fait des programmes par exemple qui créent des fichiers .xlsx. Bon on ne fait pas tout ce qu’on veut mais ça le fait quand on compare avec les fichiers.csv. J’avais aussi fait des programmes qui généraient des fichiers Excel xml (bien plus simple que le .xlsx) multi onglets et plein de couleurs. Si j’y pense je posterai des exemples. Autres trucs sympas; une vraie barre de progression ou bien un écran qui se rafraichit tout seul. Je vais pas résumer + de 20 ans d’expérience en quelques lignes .
Un des trucs dont je suis le plus fier car il y a quasiment aucune ressource sur le net et que je ne connais pas le RPG (*) c’est la création d’écrans dynamiques sans compilation uniquement avec des propriétés stockées dans un fichier...

(*) je programme en Adelia mais à force de debugger je sais lire le RPG.

https://www.developpez.net/forums/d1...-as400-5250-a/

[badaze]

Un exemple de fichier .xlsx et Excel xml. L'intérêt du xml est qu'on peut faire très facilement du multi-onglet.
Ouvrir le fichier .xml avec Excel.

[condate]

Bonjour condate

Je suis en train de réaliser un tutoriel dans ce sens qui devrait être publié sur le site (si tout va bien). J'ai choisi volontairement le langage RPG 3 en raison de la rigueur qu'il impose (surtout au niveau de la base de données). Il ne traite que de la partie interactive d'une application. Je pense qu'il est plein de bonnes idées, mais bien sur il y aura toujours des choses a améliorer. Il doit permettre de créer très rapidement et simplement une appli (1 journée de dév pour gérer un fichier avec programmes de liste, modif, création, copie, suppression et visu) tout en simplifiant la maintenance ultérieure.
Je devrais avoir terminé d'ici 15 jours et si tu es abonné à la News letter, tu devrais le voir prochainement.

Ce tutoriel devrait répondre à ta demande.
Bonne journée

Bonjour, je reprends ce vieux message... Moi, contrairement à d'autres, je suis très intéressé par votre modèle de programme et par toutes les idées qu'il doit y avoir. Peu importe le langage, tant que j'arrive à le comprendre. En contrepartie je ne pourrai pas y placer mes modèles tout simplement parce qu'un programme est écrit selon tout un environnement qu'il sera quasi-impossible (très complexe) d'étaler... Et en plus, ce que je fais (en dehors de mon temps de travail) est plus un "proof of concept" qu'un développement réellement en exploitation. Mais je pense y avoir placé aussi quelques bonnes idées...

Grossièrement : Sur tous mes écrans 5250 (liste, fenêtre ou saisie), chaque zone, constante ou variable, peut avoir un menu contextuel sur lequel s'affichent toutes les options possibles pour cette zone. Cas d'école : Sur un code devise par exemple je pourrais faire directement Modifier, Copier, Supprimer, Afficher, Liste des valeurs en fonction de la date... etc.... Avec une gestion des droits sur les actions autorisées. Il est vrai que ça n'a pas toujours beaucoup d'intérêt mais comme je l'ai déjà écrit plus haut c'est un "proof of concept". Toutes les constantes ont aussi leur menu contextuel afin de pouvoir les traduire par exemple... Et comme les possibilités de navigation sont infinies dans tout ce dédale de programme, je suis obligé de gérer la récursivité dans les appels de programme. Cela se gère plutôt bien avec beaucoup de méthode.

Par contre cela arrive trop tard, j'ai 20 ans de retard. C'est pas mal mais le 5250 va probablement disparaitre maintenant et j'aimerais refaire la même chose en interface Web mais là je ne possède aucune culture... Si quelqu'un pouvait m'exposer comment faire l'équivalent d'un écran de liste, un écran de mise à jour, un fenêtrage, un menu contextuel etc, ce serait sympa. Dans quel langage dois-je m'investir ? Java ? Php ? Autre ? J'ai déjà un petit vernis de Php datant pas mal, mais aucune pratique.

Quelqu'un pourrait-il m'indiquer une bonne piste ?