Dans les entrées de coding RPG en format fixe (comme des entrées de champs I-spec et O-spec, Factor 1, Factor 2, Result Field), on ne peut utiliser que des noms qualifiés simples. Un tel nom peut avoir deux formes: DS.SUBF ou DS.SUBF(index). Des noms plus complexes, comme DS.SUB1.SUB2 ou DS(index).SUBF,
Certaines restrictions
ne peuvent être spécifiés que dans des calculs /FREE.
Le code opération SORTA et les fonctions intégrées %LOOKUP ne supportent pas les matrices de structures de données. Pour les trier et les rechercher, il faut recourir à un autre coding, comme des appels adressés à qsort() ou vos propres boucles codées à la main.
Si vous utilisez l’I/O de structure de données pour les fichiers disque et les fichiers écran, vous apprécierez rapidement la logique « déplacement de champs » du RPG. Quand il y a le même champ dans le fichier disque et le fichier écran, il suffit de lire le fichier disque et le champ est envoyé, comme par magie, vers le fichier écran. Quand on utilise l’I/O champ-résultat de structure de données, il faut copier manuellement les champs d’une structure de données dans une autre. Si RPG permettait de copier d’une structure de données dans une autre, sous-champ par sous-champ, il faudrait beaucoup moins de code pour utiliser l’I/O de structure de données entre différents fichiers.
Espérons que dans les prochaines releases, certaines de ces fonctions manquantes seront ajoutées au RPG. Entre temps, j’espère que les améliorations exposées ici vous seront utiles.
Téléchargez cette ressource
Guide sur les espaces de travail intelligents
Au menu de ce nouveau guide Kyocera, les solutions pour stimuler la transformation & la résilience de l’entreprise avec des espaces de travail hybrides. Découvrez maintenant comment équiper vos équipes, connecter vos collaborateurs et optimiser vos processus pour transformer votre organisation en un espace de travail hybride, ou améliorer votre configuration hybride actuelle.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
