Hexadezimal in Dezimal --> X2D

[Kampi4]

Hallo zusammen, habe mal eine kleine Frage.
Muss eine Hexadezimale Zahl in Dezimal umrechnen. Habe lange nach einer Builtin-Funktion auf der AS400 gesucht. Bin jetzt im Referenzhandbuch auf die Funktion "X2D" gestoßen. Leider ohne ein Beispiel, wie ich es benutze.
Hat jemand von euch Ahnung?

Vielen Dank für die Hilfe im Vorraus!!

Mfg KAMPI

[Fuerchau]

Ich glaube das ist eine REXX-Funktion.

[E305GL]

wo soll diese Funktion codiert werden in RPG oder CL

[E305GL]

..wenn RPG:
D WORK DS
D #G020 1 2B 0
Definiere mindestens eine 2-stellige Datenstruktur mit unterdefiniertem Binärfeld. Initiiere "WORK" mit *LOVAL. Übertrage Hex-Wert rechtsbündig nach "WORK". Anschließend kann mit #G020 jede beliebige für numerische Felder zulässige Operation durchgeführt werden

[Kampi4]

Morgen allerseits.

Danke erst mal für die Antworten.

@E305GL:

Habe es so gemacht wie du gesagt hast. Zwei Probleme. Wenn ich das Feld "#G020" als 1 2B 0 deklariere, kommt immer "Das Format des Werts ist fehlerhaft.". Ich habe es dann mal als 1 4B 0 deklariert. Da konnte ich dann die Hexadezimalzahl reinmoven. Aber folgendes Problem:

Hexadezimalzahl = "X'0F'" --> also 15
Nach dem Move hat "#G020" in der Dezimalansicht den Wert "0" und in der Hexansicht den Wert "X'0000000F'". Wenn ich es dann in ein 5I 0 Feld moven will, kommt das die Zahl zu groß ist. Wenn es richtig gehen würde könnte das ja nicht sein, weil ja "15" rauskommt.

Hast du da noch eine Idee, was ich falsch mache bzw. was ich anders machen könnte?

Danke für deine/eure Hilfe!!

Mfg KAMPI

P.S. Ich programmiere das in VARPG

[B.Hauser]

Hallo,

gesetzt der Fall, Du hast ein Feld in dem z.B. x'FF' drinsteht und Du möchtest diesen Wert in numerisch konvertieren, also das Ergebnis soll 255 sein, dann ist das Ganze einfach:

Der Ansatz von E305GL war schon mal gut!
Nur man sollte numerische Felder in ILE RPG niemals Binär (Datentyp B), sondern immer Integer (Datentyp I oder U definieren). Der Grund liegt darin, dass Binär-Felder in gepackte Felder konvertiert werden. Um einen Feld überlauf zu vermeiden, wird das Feld so definiert, dass nicht der komplette Range abgedeckt werden kann. In einem einzigen Byte können binär 256 unterschiedliche Werte hinterlegt werden (0-255 oder -128 bis +127). Ein Feld, das als 2 B0 definiert wurde könnte damit einen Range von 0-65535 oder -32768 bis +32767 abdecken. Durch die Konvertierung in gepackt kann es nur Werte zwichen -9999 und +9999 aufnehmen. Integer Felder werden NICHT konvertiert und können somit den kompletten zulässigen Range abdecken.

Ist also der Hex-Wert bekannt und steht in einem alphanumerischen String, kann dieser einfach über eine Datenstruktur konvertiert werden.
Etwa so:

D DSHex           DS                   inz            
D  MyInt                         3U 0                 
D  MyAlpha                       1A    Overlay(MyInt) 

 /Free
  MyAlpha = x'0F';     
  Dsply MyInt;
  MyAlpha = x'FF';
  Dsply MyInt;
  *InLR = *ON
 /End-Free 

... übrigens 1 Byte Binär entsprich 3U 0 oder 3I 0, 2 Byte Binär entspricht 5U 0 oder 5I 0, 4 Byte Binär 10U 0 oder 10I 0 und 8 Byte Binär entspricht 20U 0 oder 20I 0. Die Länge richtet sich immer nach der Anzahl der Ziffern, die der Maximal-Wert, der in dem Feld gespeichert werden kann benötigt!!!
Birgitta

[Kampi4]

Hallo Birgitta,
vielen Dank, das hat funktioniert. Nur habe ich jetzt ein komisches Phänomen:

Ich habe jetzt als Hexadec. Zahl X'7D03', was ja 32003 ist.
Habe MyChar auf "2A" und MyInt auf "5U 0" erweitert.

Im "grünen" Bildschirm klappt es auch perfekt. Aber in VARPG klappt es nicht, obwohl alles gleich ist. Beim Debuggen fällt auf, dass die Hex Ansicht von MyChar X'7D03' ist, aber die von MyInt 0'037D'!!! Das ist immer umgedreht und es kommt dementsprechen auch nicht 32003 sondern 893 herrau.

Warum funzt das im "grünen", aber nicht in VARPG?!?!

Danke schon mal für eure Antworten!

Mfg KAMPI

[Fuerchau]

Das hat nichts mit VARPG zu tun sondern mit dem Intel-Prozessor.
In Intel werden Integer umgekehrt gespeichert, 32bit also LOWWORD, HIGHWORD und 16Bit (Words) in der Form LOWBYTE, HIGHBYTE.

[Kampi4]

Ach so, das ist ja interresant.

Wie kann ich den Code denn jetzt änder, dass es auf Intel Maschinen funzt?

Mfg KAMPI

P.S. Sieht es bei AMD genauso wie bei Intel aus?

[kuempi von stein]

Ich verstehe gar nicht, warum das alles so kompliziert sein muss.
Computer (und damit meine ich alle PCs und auch die AS/400) sollten sowas eingentlich als "GrundTool" anbieten, ohne mit der Wimper zu zucken.
Immerhin reden wir hier vom Grundübel schlechthin, nämlich ein Zahlensystem in ein anderes konvertieren.

Aber nein, da muss man von hinten durch die Brust ins Auge irgendwie...

Anyway, back to topics:

Kenne nun die Grundanwendung bei Dir nicht, aber rechne doch den Quatsch dann auf der Kiste (Intel, AMD was immer) mit den dort gegebenen Möglichkeiten aus?
Gibt doch für so ziemlich jede Programmiersprache auf den Kisten auch ne Funktion zum Umrechnen (ausser eben auf der AS/400 scheinbar), selbst in Excel.

Als Beispiel hier mal ein Javascript
JavaScript für Alle! - HexDec-Umrechnung

was leicht zu modifizieren wäre.

kuempi

Nachtrag: für andere Sprachen siehe hier: Conversion Hexadécimal -> Décimal snippets pour c, c# 1.x, c# 2.x, c++, camllight, delphi 5, html, java, php 3, php 4, php 5, python, vb 2005, vb.net 1.x, vb6, vba, windev

[Kampi4]

Ja, ich rege mich auch seit 2 Tagen auf, dass es sowas nicht auf der AS400 gibt. Eigentlich unmöglich sowas. Das Thema hat mich bisher bestimm 10 Arbeitsstunden gekostet

In der Firma wollen wir leider am besten nur AS400 + VARPG machen und keine kleinen Zusatzprogramme haben.

Bin ja jetzt auch der Lösung relatib nah. Aufgegeben wird nicht

Mfg KAMPI

[E305GL]

..ganz einfach:
kein MOVE sondern mit Z-ADD binär nach numerisch, funktioniert bei uns im RPG400, ILE, VARPG