Hexadezimal in Dezimal --> X2D

[Kampi4]

Auch mit Z-ADD bekomme ich keinen richtigen Wert.

Habe jetzt mal versucht den Hex-Wert an die AS400 zu übergeben und da im Programm die Umrechnung zu machen. Leider kommt da nicht der Hex Wert an, wie ich ihn im VARPG übergebe. Wie kann das denn sein?!!?

So langsam verzweifel ich. Ich meine, ich will nur zwischen zwei Zahlensystemen umrechnen. Das ist normal eine Befehl und Arbeit von 10 Sekunden!!!!


Danke für eure Hilfe!

Mfg KAMPI

[E305GL]

beim Datenaustausch mit AS/400 erfolgt bei char-Feldern eine EBCDIC ASCII konvertierung

[BenderD]

... das hat mit der AS/400 wenig zu tun, wer Schmutzbuckelig programmiert, muss mit sowas rechnen. Zu den Schmutzbuckeleien zählen hier unter anderem:
- Redefinition von Speicherbereichen, beliebt in RPG und COBOL
- rechnen mit Pointern, beliebt in C
- memcopy beliebt in C und Assembler
- u.v.m. (soll kein Kurs werden)

gerne wird sowas verwendet von Programmierern, die sich für tricky halten

gefördert wird das von Programmiersprachen die mit Typbindung huddeln, wie RPG, Assembler und (teilweise) C

erschwert wird das von defensiven Programmiersprachen wie ALGOL, PASCAL und Java

in den ganz wenigen Fällen (ob deiner dazu gehört ist noch fraglich), wo man solchen Unfug braucht, gehört sowas in eine gekapselte Funktion mit ordentlichen Prüfungen.

D*B

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

[Fuerchau]

AMD und Intel sind da kompatibel, da sonst keine Software laufen würde (z.B. Pointer sind immer 32-Bit (bz. bei 64-Bit eben 64).
Motorola (e.g. Mac) arbeitet da wieder wie die AS/400.

Für diese Umrechnung musst du nun eben Byteweise arbeiten, da die Interpretation eine 2/4/8-Byte-Integers auf Intel eben w.o. läuft.

Also:

D DSHex DS inz
D MyInt1 3U 0
D MyInt2 3U 0

MyInt1 * 256 + MyInt2

[Kampi4]

Ok, werde das mal ausprobieren Baldur.

Aber noch mal zu deinem Z-ADD:
In der Binärzahl steht in Hex X'000000F6', aber nach dem Z-ADD in eine interger hat die einem Wert von "-72160".


@BenderD: ?? Was soll das denn heissen? Was kann ich denn dafür, dass ich von einem Drucklufttester einen Hexadezimalen Wert bekomme und den umrechnen muss? Irgendwie verstehe ich dein Posting nicht.

Mfg KAMPI


P.S. Versuche im Moment auf beiden Wegen irgendwie zur Lösung zu kommen. Also nach dem Weg von Birgitta und E305GL. Bei Birgitta habe ich nur noch das Problem wie ich den Austausch zwischen VARPG (also PC) und As400 hinbekomme.

[BenderD]

wo kommt denn dein ominöser Hexfrickel überhaupt her???

So langsam verzweifel ich. Ich meine, ich will nur zwischen zwei Zahlensystemen umrechnen. Das ist normal eine Befehl und Arbeit von 10 Sekunden!!!!

Mfg KAMPI

[Kampi4]

Zuerst einmal:

Nach Baldurs Hinweis klappt es jetzt. Vielen Dank dafür, aber auch an alle anderen die geholfen haben. Bin euch echt sehr danbar.

@Bender:
Unsere Tochterfirma macht Rad-Reifen Montage und wir programmieren für die. Die haben von der Firma Testo ein Gerät bekommen, das den Druck mist. Kommunikation über RS232 und da bekomme ich halt Hexadezimale Werte zurück. Das gute ist, dass ich Milliampere Werte zurückbekomme und die dann in Bar umrechnen kann ;-)


Mich hat einfach nur geärgert, dass man an einer eigentlich banalen Sache wie das Umrechnen von Zahlensystemen in RPG so einen Aufwand hat.
Im Enteffekt ist es ja "relativ" einfach, aber wenn man nicht weiss wie, ist man da echt geschmissen.


Wünsch euch allen ein schönes Wochenende!!!!

Mfg KAMPI

[BenderD]

bei der Speicher Überlagerung von einem String und einer als Integer definierten Zahl geht die interne Zahlendarstellung (Prozessor abhängig) in die Umrechnung ein, was zu deinem Problem führt.
Dein Drucklufttester muss eine genaue Spezifikation haben, nach der er seine Werte liefert und genau dafür brauchst du eine Umrechnung. Wenn du an den Wert nur Binär oder Hex bekommst, dann bleibt dir in RPG halt nur der Weg über Umrechnung zu Fuss, am Besten in einer SubProcedure eines Serviceprogrammes.
Falls ihr sowas in der Schule nicht gehabt habt, suche ich dir gerne ein Beispiel raus.

mfg

Dieter Bender

@BenderD: ?? Was soll das denn heissen? Was kann ich denn dafür, dass ich von einem Drucklufttester einen Hexadezimalen Wert bekomme und den umrechnen muss? Irgendwie verstehe ich dein Posting nicht.

Mfg KAMPI

[Kampi4]

bei der Speicher Überlagerung von einem String und einer als Integer definierten Zahl geht die interne Zahlendarstellung (Prozessor abhängig) in die Umrechnung ein, was zu deinem Problem führt.
[...]
mfg

Dieter Bender

Wusste nicht, dass es da von Prozessor zu Prozessor unterschiede gibt. Aber man lernt nie aus.

Genaue Spezifikationen gibt es von dem Tester nur über die Kommunikation. Zum umrechnen von Milliampere nach Bar weiss ich aber, dass 1,6 Milliampere 1 Bar sind. Das reicht ja zum Umrechnen.

Mfg KAMPI

[Fuerchau]

Da ja bei "00F6" "F6" das höherwertige Byte ist ergibt das F600, und da das oberste Bit gesetzt ist, ist der Wert negativ.
Bei der Definition U für Unsigned, sollte das eigentlich ignoriert werden.

Um aber Prozessorneutral zu sein, muss man eben per Spezifikation (siehe Dieter) genau wissen, wie Daten zu interpretieren sind und natürlich auch über Speicherungen auf Prozessoren informiert sein.
Auch Terminologien sind da manchmal unterschiedlich.
Bei Intel (und fast allen PC'lern) werden Bits in Bytes z.B. von rechts nach links gezählt, bei IBM und somit AS/400 aber von links nach rechts.

Wo ist also Bit 0 ?

Naja, und das mit den LOWORD/HIWORD bzw LOWBYTE/HIGHBYTE stammt auch aus der C++/C-Programmierung, wo eben Makros je nach Zielsystem (also Hardware) die Interpretation zur Compilezeit auflösen.

[wwg]

Wusste nicht, dass es da von Prozessor zu Prozessor unterschiede gibt. Aber man lernt nie aus.

Eine ganz brauchbare Erklärung gibt es schon in der Wikipedia: Byte-Reihenfolge – Wikipedia

Intel hat schon bei seinem ersten 8-Bit-Prozessor, dem 8008 (1972), mit diesem Unfug angefangen; da hatten die Adress-Register schon stolze 14 Bit, die seit dem 4-Bit-Vorgänger hinzugekommenen 6 Bit wurden einfach an den alten 16-Bit Befehl des 4004 (8 Bit Befehl, 8 Bit Adresse) angehängt (das war aus Sicht der Entwickler - hard und soft -vermutlich sogar sinnvoll).

Bei dem 8080 (1974) wurden dann die 14 Bit auf 16 Bit erweitert, und man hatte ein 16-Bit Adressformat, mit dem man volle 64K(!) adressieren konnte.

Dieses verquere Format hat man dann aus Kompatibilitätsgründen bis heute beibehalten müssen.

Prozessorhersteller, die früher (IBM) oder später (Motorola) auf den Markt kamen, haben es anders gemacht.

mfg
Werner

(der noch einen Intel-Katalog von 1977 im Regal stehen hat)