Datenübertragung von IBM i

[mahones]

Hallo zusammen,

wir haben bei der Umstellung von Win7-PC-Systemen auf Win10 auch i ACS installiert.
Da es auf den alten Kisten auch die guten TTOs gabe, musste also auch auf dem neuen System (in der Kürze der Zeit) eine solche Datenübertragung angeboten werden.

Leider sind die Ergebnisse unterschiedlich. Und da der Output an einen Geschäftspartner gesendet wird, kann dieser die Daten nun nicht mehr importieren / verarbeiten...

Wie war die Config?
Auf dem alten System haben wir bei "IBM i" eine Datei "BIBLIOTHEK/DATEINAME" angegeben, und bei "PC" als Ausgabeeinheit "Datei" / Dateiname "c:\...\datei.txt".
Bei den Details haben wir als Dateityp einen "ASCII-Text" ausgewählt und die Systemdaten in "ASCII" umsetzen lassen.

Wenn man dieses in der neuen i ACS genau so machen will, stellt man fest, dass es "ASCII-Text" gar nicht mehr gibt, also ist "Text (.txt)" wohl das naheliegendste gewesen.
Bei der Umsetzung gibt es "ASCII" leider so auch nicht mehr.

Was ist das Ergebnis?
Gleich beim ersten Feld sieht man Abweichungen. Dieses ist nämlich ein gepacktes Feld (2,0). In der alten Version wurde es als vierstelliges Feld dargestellt - in der neuen Version nur noch dreistellig. So zieht sich das durch...
Wir haben bei der Umsetzung verschiedenste Möglichkeiten ausprobiert (UTF-8, windows1252, IBM01141, ...) Bei den meisten war zwar der Inhalt als solches zu lesen...aber nie in der richtigen (spaltengenauen) Darstellung.
Da der Partner seine Schnittstelle aber an die bisher gültigen Längen abgestimmt hat, ist eine Änderung an der Stelle sicherlich nicht so einfach. Schön wäre es, wenn man "DEN" entscheidenden Parameter noch einstellen kann, um das alte, gewünschte Ergebnis zu erzielen.

Ich sehe als Alternative aktuell nur die Lösung, dass wir die Ausgangsdatei auf unserer IBM i schon so umstellen, dass dort ein einziger String entsteht, weil wir dort die Abstände, etc. genau und gezielt porgrammieren können.

Aber vielleicht übersehen wir ja auch nur eine Kleinigkeit!?
Wisst ihr mehr?

Danke!

[camouflage]

Habt ihr es auch mal mit Text und US-ASCII versucht?
578

[Fuerchau]

Ich glaube nicht, dass es an der Codepage liegt, sondern an der korrigierten Darstellung numerischer Felder.
2,0 alt = 'xx00' => was wurde denn da zusätzlich ausgegeben?
2,0 neu = 'x00' (x=Vorzeichen Blank/-)

[camouflage]

Hi Baldur,
Glaube ich nicht. Ich hab das Ganze mal mit beiden CA's ausprobiert. Ich komme auf's gleiche Resultat - also keine Unterschiede. Im ACS kann man auch angeben, ob Vornullen ausgegeben werden sollen, damit die Felder kontrolliert werden können. Nicht verhindern konnte ich den Dezimalpunkt. Allerdings mochte ich mich auch nicht allzu tief reinknien.

p.s.
Die Verarbeitungsgeschwindigkeit des ACS ist wirklich zum heulen. Das olle CA, läuft auch unter W10 klaglos und schnell.

[Fuerchau]

Dann sollte hier noch mal geprüft werden:

"Gleich beim ersten Feld sieht man Abweichungen. Dieses ist nämlich ein gepacktes Feld (2,0). In der alten Version wurde es als vierstelliges Feld dargestellt - in der neuen Version nur noch dreistellig. So zieht sich das durch..."

Also ich komme bei 2,0 nicht auf 4 Stellig.
Ggf. liegt es auch am NULL-Anzeiger?
Wobei ich mir nicht vorstellen kann, dass es bei solchen Schnittstellen NULL-Felder überhaupt gibt.

Ich bin da aich immer den Weg von CPYfrm/toIMPF/CPYfrm/toSTMF gegangen. das war immer schnell und flexibel.

Bzgl. ACS und 5250 habe ich da keine Schwierigkeiten. Ein wesentlicher Vorteil ist die Unicode-Unterstützung, die im CA eher rudimentär ist.

[mahones]

Danke schonmal für die Rückmeldungen - evtl. helfen diese Infos noch weiter (sofern man überhaupt dort eingreifen kann). Wenn es tatsächlich "nur" die korrigierte Darstellung numerischer Werte ist, dann wird es schwierig.



So sieht der Output aus:

ALT
---
8 38728 4062020 513986
8 38728 4062020 513986
8 38728 4062020 513986

NEU
---
8 38728 4062020 513986
8 38728 4062020 513986
8 38728 4062020 513986

Hier ist einmal der Inhalt der fdf(x) - und ein DSPFFD
...

alt neu
[F0001] [F0001]
Length=4 Length=3
Name=RSFIRM Name=RSFIRM
Type=2 Type=2

IBM i (DSPFFD): RSFIRM PACKED 2 0

[F0002] [F0002]
Length=8 Length=7
Name=RSLINR Name=RSLINR
Type=2 Type=2

IBM i (DSPFFD): RSLINR PACKED 6 0

[F0003] [F0003]
Length=10 Length=9
Name=RSLIDT Name=RSLIDT
Type=2 Type=2

IBM i (DSPFFD): RSLIDT PACKED 8 0

[F0004] [F0004]
Length=8 Length=7
Name=RSRENR Name=RSRENR
Type=2 Type=2

IBM i (DSPFFD): RSRENR PACKED 6 0



Es klingt aber so, als müsse man intern schon die Daten korrekt aufbereiten und nicht dem Tool dieses überlassen...

[Fuerchau]

Sieht mir sehr danach aus, dass eben die alte Software einen Fehler gemacht hat und die neue das korrigiert hat.
Das sieht halt nach dem Motto aus: "Verlasse dich nie auf einen vorhandenen Fehler".

[DKSPROFI]

Moin, leider kenne ich das Problem mit dem Datenaustausch nur zu gut. Partner A will dies, Partner B will das, ......... Mittlerweile geben wir nur noch CSV-Daten weg. Lediglich für die alten internen /3er Dateien b bereit wir eine CSV per RPG auf. mfg DKSPROFI

[mahones]

Danke für euer Feedback - dann schauen wir mal, ob der Partner eine neue Schnittstelle (csv) verarbeiten kann...bis dahin werden wir tatsächlich intern die Daten aufbereiten.