View Full Version : %editc
Hi,
Warum ergibt
EVAL KEY11 =
%EDITC((AZKEY1*10000+AZKEY2*100+AZKEY3):'X')
mit
azkey1 = 0004746 (7 Stellen, numerisch)
azkey2 = 80 (2 stellen numerisch)
azkey3 = 00 (2 stellen numerisch)
KEY11 = '00000047468'
Das macht doch keien Sinn oder????
Der ILEMax
Aber klar doch:
7-Stellig * 10000 ergibt doch 11-Stellig!
Zwischenergebnisse benötigen nun mal u.U. größere Felder oder mehr Nachkomma.
Ja, 11 stellen ist ok.
Ich hätte aber
00047468000
erwartet
Hi,
Warum ergibt
EVAL KEY11 =
%EDITC((AZKEY1*10000+AZKEY2*100+AZKEY3):'X')
mit
azkey1 = 0004746 (7 Stellen, numerisch)
azkey2 = 80 (2 stellen numerisch)
azkey3 = 00 (2 stellen numerisch)
KEY11 = '00000047468'
Das macht doch keien Sinn oder????
Der ILEMax
Da Du nichts angegeben hast, hat der Compiler das Format des Ausdrucks eigenmächtig festgelegt und das Ergebnis auf 10 Stellen abgekürzt.
Versuch's mal mit:
/Free
KEY11 = %EDITC(%Dec(AZKEY1*10000+AZKEY2*100+AZKEY3, 11, 0): 'X');
Birgitta
Stimmt, dann prüfe mal bitte die Definition des Zielfeldes KEY11!
Der %EDITC liefert ein Alphafeld das linksbündig per Eval übertragen wird.
Ist das Ziel zu kurz, wird ohne Warnung abgeschnitten.
Wie groß das Zwischenfeld wird, das entscheidet der Compiler, aber es ist so groß, dass nichts verloren geht.
Alternativ geht auch ein "evalr %editc(....)", wenn du die ganzen Vornullen nicht brauchst.
Bei Dezimalfeldern gibt's wenigstens einen MCH.
@Birgitta
Der Compiler darf da nix kürzen und ich bezweifle das er das macht.
key11 ist 11 alpa
ich hab nun
eval key11 = editc(azkey1:'X') +
editc(azkey2:'X') +
editc(azkey3:'X')
(ich brauch die Nullen)
Der Compiler darf da nix kürzen und ich bezweifle das er das macht. Das dachte ich bisher auch
(V7R1, TR5)
der ILEMax
Wie gesagt, ein "evalr ..." tuts auch.
F1 * 10000 = 11 Stellen
+ F2 = 12 Stellen, da ja ein Überlauf stattfinden kann.
Wieviel "Reserve" der Compiler dann so einplant weiß ich nicht, da gibt's aber zum Thema Zwischenergebnisse eine Abhandlung.
In deinem Fall ist das Zwischenergebnis dann wohl 14 Stellen, was beim eval dann zum Verlust der letzten 3 Stellen führt.
@Birgitta
Der Compiler darf da nix kürzen und ich bezweifle das er das macht.
Das würde ich nicht so unterschreiben!
Bei der Berechnung des Ausdrucks wird auch nichts gekürzt, der wird mit Sicherheit korrekt gerechnet. Dann wird aber dieser numerische Ausdruck in einen Alpha-Wert konvertiert abh. von des Formats des numerischen Ergebnisses. Der fertige String wird nach den üblichen Regeln in das alphanumerische Ausgabe-Feld übernommen, d.h. am Ende bzw. bei EVALR am Anfang abgeschnitten.
Wenn's nur darum geht einen alphanumerischen String mit führenden Nullen zu generieren basierend auf einer Formel zu generieren und numerischen Feldern ohne Nachkommastellen, würde ich eh' wie folgt vorgehen:
/Free
EvalR Key11 = '00000000000' + %Char(AZKEY1*10000+AZKEY2*100+AZKEY3);
Birgitta
Wie gesagt, für Berechnungen gibt's eine Abhandlung über Zwischenergebnisse, die man ein wenig über Compileroption und eval(r) (R hat nichts mit Rundung zu tun) beeinflussen kann.
Mit %editc(nn:'X') an Stelle von %char kann ich mir das Auszählen der Nullen sparen, wenn ich sowieso "evalr" verwende.
Ok, dann werd ich mir mal den evalR angewöhnen,
Danke an beide
der ILEMax