Taille des exécutables en fonction du langage.

Bonjour,

Je viens de faire une petite expérience :

Ecriture d'un programme en RPG3 et compilation : Taille de l'objet *PGM = 196608 octets (il s'agit d'un sous fichier avec 2 ordres de tri de la liste)

Puis CVTPGMSRC en ILE et :
compilation (CRTPGM) : Taille de l'objet *PGM = 286720 octets
Création Module : Taille de l'objet *MODULE = 262144 octets

Soit un ratio de 1 / 1,46 / 1,33

Personnellement ce que j'en pense :
Convertir une appli RPG3 en ILE demande à minima d'augmenter la capacité mémoire du système d'un tiers. Bien sur, chaque config est à étudier au cas par cas.
Autre solution : Tout réécrire en ILE ou Free format. Mais même avec cela, je ne suis pas très sur du résultat (bien que le MAIN/NOMAIN puisse apporter pas mal dans la taille des objets (exclusion de la partie cycle).

Et vous, avez vous un avis la dessus ? Avez-vous déjà fait des tests de ce type ? (si vous avez besoin, j'ai les sources qui ont fait l'objet de mon test).

Autre question : Programmer une édition (avec ruptures) en cycle GAP et hors cycle GAP : Pouvez vous mesurer la différence en terme de programmation et taille des objets générés ? Et un matching de fichiers?

J'ai fait cela en COBOL, c'est un peu chiant.
Mais si la taille de l'objet est plus petite, c'est de la mémoire de gagnée (donc moins de swap en perspective et un programme sans doute plus rapide.

Merci pour vos avis et réponse.
Bonne soirée.

Ah ... Le cycle !

Pour ceux qui savent encore s'en servir, dans des traitements bien adaptés, comme souvent les éditions, il est redoutable.
Une fois qu'on a compris comment tout fonctionne, c'est simple, rapide (écriture et exécution), efficace.
Le hic, c'est que les sorties sont pour le moins... moches :D Et la plupart des utilisateurs n'en veulent pas, car manquant souvent de lisibilité.

J'ai donc rusé. Je génère non pas un printer, mais un fichier avec une clé d'impression, et des lignes, avec une sorte de XML (issu de maquettes, avec tout un paramètrage).
Une fois les enregistrements ajoutés, le programme écrit dans une DataQueue le n° d'impression générée.
Un programme sur un serveur Windows, qui est en attente de cette DataQueue, récupère alors les enregistrements, et les traite, pour mettre en forme, en fonction du XML, l'édition proprement dite.

Autre solution, qu'on utilise depuis 2 ans, mais là j'avoue que j'ai zappé le cycle, car mes collègues préfèrent la lisibilité d'un programme structuré standard, c'est d'utiliser PDFLib. Je génère le PDF directement, et transmet au programme Windows, le nom et le chemin du PDF à imprimer (ainsi que le nom de l'imprimante, le nombre d'exemplaires, etc... qui se trouvaient avant dans le XML). Mais je suis hors-sujet là. :D

Pour ce qui est de la taille, je pense que justement c'est le fait d'être en ILE qui change tout.
Le code exécutable généré en lui-même ne fait surement pas plus qu'en RPGIII. Mais pour la gestion des groupes d'activation, il doit y avoir des routines supplémentaires.

De toute manière, c'est ailleurs que le gain se fait.
Et pour la mémoire (et les accès disques...), si un programme peut effectivement demander plus de ressources, programmer en ILE avec des programmes de service, permet au contraire de gagner beaucoup à ce niveau.
Si on charge 4 programmes comportant la même routine, elle n'est chargée qu'une fois en ILE, 4 fois en RPGIII.
Et forcément, en maintenance, c'est quand même bien plus simple de ne modifier qu'à un seul endroit, qu'à x.

Je suis en train de faire des modifs dans un code qui a été modifié, adapté, depuis des lustres, et comporte encore des routines issues du 36, c'est l'horreur. Je perd un temps fou, et je ne suis même pas certain de ne pas avoir oublié des bouts, car avec les définitions internes on peut avoir une zone de fichier qui s'appelle partout ARSPHY, et qui d'un coup s'appelle STKP. Ou pire qui n'est pas définie avec les mêmes caractéristiques (genre on tronque une zone alpha pour ne prendre que les x premiers caractères), ou dont on ne prend qu'une partie avec une redéfinition (prendre que l'année d'une date).
On doit fouiller tous les CL pour voir s'il n'y a pas un OVRDBF qui traine, parce que le fichier en interne ne s'appelle pas comme d'habitude (parce qu'on l'a 2 fois par exemple). Je m'y arrache les cheveux que je n'ai plus. :D

Pour ce qui est du Cobol, que j'ai abandonné en 2000 en quittant la société dans laquelle on l'utilisait, je ne me rappelle que d'un truc. Le code source était bien plus court et l'objet généré plus efficace, quand je réécrivais un programme en RPG. Mais eux avaient la culture Cobol...

Citation:

---

Envoyé par m4k-Hurrican

Une fois les enregistrements ajoutés, le programme écrit dans une DataQueue le n° d'impression générée.
Un programme sur un serveur Windows, qui est en attente de cette DataQueue, récupère alors les enregistrements, et les traite, pour mettre en forme, en fonction du XML, l'édition proprement dite.

---

Bonjour.
C'est une écriture dans une DTAQ locale à l'IBM i et c'est l'appli windows qui vient l'écouter ou l'inverse ? Quel que soit le sens, quelle solution est utilisée pour gérer soit la lecture, soit l'écriture de cette DTAQ ? J'ai vu qu'on pouvait faire un truc dans le genre avec RabbitMQ, mais je n'ai pas encore testé.
Merci.

Citation:

---

Envoyé par pwrdwnsys

Bonjour.
C'est une écriture dans une DTAQ locale à l'IBM i et c'est l'appli windows qui vient l'écouter ou l'inverse ? Quel que soit le sens, quelle solution est utilisée pour gérer soit la lecture, soit l'écriture de cette DTAQ ? J'ai vu qu'on pouvait faire un truc dans le genre avec RabbitMQ, mais je n'ai pas encore testé.
Merci.

---

Une procédure dans un programme de service écrit les valeurs dans une DataQueue sur l'IBM i.
Un programme, en VB en l’occurrence, lit la DataQueue avec les simples API d'iSeries Access.

Voilà des bouts de code utilisé.
Sachant que le programme peut être mis en pause par programmation (écriture d'un enreg "PAUSE" dans la DataQueue, et libéré par envoi de "PLAY") ou par appui sur un bouton de la fenêtre de l'application Windows.
Sachant aussi que cette version date et est écrite en VB6.
La version .net n'est pas encore finie, j'ai trop de choses à faire avec les adaptations de notre vieil outil de gestion. Mais un de ces jours j'aurai une version plus aboutie et peut être que je fournirai les sources.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

'Public systemNames As New cwbx.systemNames Dim Systemi As New cwbx.AS400System Dim ImprAttQ As New cwbx.KeyedDataQueue ' Etablit la DataQueue utilisée Set Systemi = New cwbx.AS400System Systemi.Define NomDuSystemi Set ImprAttQ.System = Systemi ImprAttQ.QueueName = "IMPRIMK" ' Lit toutes les demandes en attente Do ' On va désormais attendre qu'une impression soit demandée. EnrDtaq = stringCvtr.ToBytes("") EnregDtaq = "" ' Lit la DTAQ, récupère la clé la plus basse (prioritaire) Cle = stringCvtr.ToBytes("000000000") EnrDtaq = ImprAttQ.Peek(Cle, cwbdqGtOrEqual, 0) ' Il y a quelque chose ? If Not IsNull(EnrDtaq) Then EnregDtaq = stringCvtr.FromBytes(EnrDtaq) End If If Trim(EnregDtaq) <> "" Then ' Fin, Pause, Reprise, ou impression demandée ? Select Case Trim(EnregDtaq) Case Is = "FIN" EnrDtaq = ImprAttQ.Read(Cle, cwbdqEqual, 0) ' Vire l'enreg de la file End Case Is = "PAUSE" EnrDtaq = ImprAttQ.Read(Cle, cwbdqEqual, 0) ' Vire l'enreg de la file bPause.Value = 1 Case Is = "PLAY" EnrDtaq = ImprAttQ.Read(Cle, cwbdqEqual, 0) ' Vire l'enreg de la file bPause.Value = False Case Else ' Traite uniquement si pas en pause If bPause.Value = False Then ' Une impression dispo ! On s'en charge immédiatement EnrDtaq = ImprAttQ.Read(Cle, cwbdqEqual, 0) Call Imprime(EnregDtaq) End If End Select End If ' Permet au PC d'effectuer les tâches courantes DoEvents Loop Until Trim(EnregDtaq) = "" Or bPause.Value = 1

---

Merci pour le code source !