CEEDOD im Hauptprogramm

[Fuerchau]

Falsch!
Wenn du das externe Programm immer nur aus ILERPG mittels Prototyp aufrufst, legt der Compiler eben eine entsprechend große Kopie an, es gibt dann keinen Müll.
Durch "varying" wird eine 2-byte-Längeninformation vorangestellt, die du einfach mit %len() abfragen kannst.
%len() liefert die Länge des Inhaltes bei varying (bzw. DDS-varlen) Feldern, %size() die tatsächliche definierte Größe.
Bei fixed Variablen liefert %len() und %size() die selbe Information.

Beim Aufruf von CLP definierst du eben eine 1002-Byte-Variable und stellst die Länge per %bin(&Ziel 1 2) voran.

[XMan]

Ah, OK Danke!

Wieder etwas gelernt ;-)

Werde ich ausprobieren.

Danke!!

[mk]

Ah, OK Danke!

Wieder etwas gelernt ;-)

Werde ich ausprobieren.

Danke!!

Hi,

zum Beispiel kann man so die Länge feststellen:

/free                                           
    values = %char(%len(%size(In_Group))) ; 
                                                
/end-free 

Gruss
Michael

[mk]

Ah, OK Danke!

Wieder etwas gelernt ;-)

Werde ich ausprobieren.

Danke!!

Hi,

zum Beispiel kann man so die Länge feststellen:

/free                                           
    values = %char(%len(%size(In_Group))) ; 
                                                
/end-free 

Wobei
%len die Feldgröße 1000 angibt
%size die tatsächliche Länge des Inhalts
Gruss
Michael

[Anton Gombkötö]

mk, mal davon abgesehen, dass die Antwort eine relative Themenverfehlung ist, was tut denn Dein Code Deiner Meinung nach genau und wann sollte man das brauchen können???

Denn wenn "In_Group" 1000 Bytes lang ist, und es steht zum Beispiel "Ich sollte den Dingen die Zeit schenken, die sie verdienen." in dieser Variable, liefert Dein Code das Ergebnis "4".

[mk]

Hi,

sorry, ich schäme mich.

Hatte das einfach so runtergetippt.

Um die Länge eines Feldes festzustellen kann man aber folgendes
verwenden.

values = %char(%len(%trim( In_Group))) 

Gruß
Michael

[Fuerchau]

Wofür dann noch die Umwandlung in CHAR ?

Zu beachten ist, dass %trim() auch Leerzeichen am Anfang entfernt!

[XMan]

Mal davon abgesehen das die Leerzeichen weg sind hilft das ja auch nicht weiter. Denn wenn der übergebene Parameter 1000 Zeichen hat aber vom aufrufenden Pgm nur 100 bekommt, so steht auch dieser "Datenmüll" drinnen.
Somit ist auch die Länge ein falsches (%len(%trim(...))) Ergebnis.
Mein Problem ist ja das ich dieses Pgm aus verschiedensten Anwendungen (CL, RPGIII, RPG ILE, ...) aufrufen können muss.
Da ich mir das Leben aber selber nicht schwerer machen wollte, habe ich nun einen zusätzlichen Parameter mitgegeben der mir die Länge des Text-Parameters mit gibt. Somit kann ich dann richtig reagieren.

Dennoch Danke ich Euch für die Anregungen!

LG und schönen Abend!

[BenderD]

... das ist kein Datenmüll, das ist Speicherbereich aus dem aufrufenden Programm - wenn der verändert wird geht im Call Stack oberhalb des Aufrufers der Punk ab!!!

D*B
, Kopf schüttelnd

[XMan]

@BenderD

das ist mir bewusst das dieser "Müll" benötigt wird!
Siehe 2. Posting von mir "...der Rest des Parameters nur "Müll" enthält (wobei der Müll ja vom System benötigt wird)..."

Ich bezeichne in deshalb als "Müll" (auch bewusst unter Anführungszeichen geschrieben) weil ich im Pgm damit nichts anfangen kann wenn das im Parameter steht!


LG

[Fuerchau]

Dies deutet wie immer darauf hin, dass Aufrufkonventionen nicht eingehalten wurden.
Dies wird ja auch (in vereinfachter Form) durch die Prototyp- und Interfacedefinitionen (leider nur zur Compile-Zeit) einigermaßen geprüft.

[Anton Gombkötö]

XMan will hier den ersten Parameter übergeben, wie er möchte (was kein Problem ist) UND er möchte herausfinden, wie groß die Variable im aufrufenden Programm ist (das ist das Problem). Wozu auch immer er das brauchen mag, das wissen wir leider nicht.

Und er hat das Problem auf genau die gleiche Weise wie die IBM selber bei z.B. QCMDEXC gelöst.

"Schöner" wäre natürlich irgendeine einfache Funktion in RPG selber, die einem die Infos liefert. Aber die gibt's halt leider (noch) nicht.