%editc

[ILEMax]

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

[Fuerchau]

Aber klar doch:
7-Stellig * 10000 ergibt doch 11-Stellig!

Zwischenergebnisse benötigen nun mal u.U. größere Felder oder mehr Nachkomma.

[ILEMax]

Ja, 11 stellen ist ok.

Ich hätte aber

00047468000

erwartet

[B.Hauser]

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

[Fuerchau]

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.

[ILEMax]

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

[Fuerchau]

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.

[B.Hauser]

@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

[Fuerchau]

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.

[ILEMax]

Ok, dann werd ich mir mal den evalR angewöhnen,

Danke an beide
der ILEMax