Problem mit Steuerzeichen in Datenbank?

[Stoeberl]

Hallo zusammen!

Hab hier ein Phänomen das mir so noch nicht aufgefallen ist. Einige unserer Kunden kopieren ihre Texte (Name, Anschrift, Ort, etc.) aus eMails. Hierbei kann es z.B. vorkommen das Zeichen wie "…" (Windows Ansi 1252 Hex '85') mitkopiert und in die AS400 Datei eingefügt werden. Aus diesem Zeichen wird durch die Umwandlung von Client Access ein Hex '15' was laut einer Tabelle das Steuerzeichen New Line (NL) ist. Beim erneuten Einlesen und Anzeigen des Satzes stürzt dann das Programm mit Fehler RNQ1251 ab.
Ich könnte jetzt natürlich z.B. via XLATE solche Zeichen eliminieren und durch Blank ersetzen. Da wir aber das Problem wahrscheinlich bei vielen Programmen haben hab ich mich gefragt ob es von der AS400 aus eine Möglichkeit gibt, das z.B. solche Zeichen mit Ersatz-Zeichen (Stern mit Strich drüber wie im Query) angezeigt werden und das Programm nicht abstürzt.
Oder vielleicht gibt es noch andere Ideen wie man das Problem schnell lösen könnte?

Das Problem tritt z.B. unter folgender Konfiguration auf:

- Physische Datein mit CCSID 273 (Alpha Felder)
- Programm und Displayfile ebenfalls mit CCSID 273 gespeichert und erstellt (Zugriff auf Dateien erfolgt über SETLL, CHAIN, READ, etc.)
- Client Access auf CCSID 273 eingestellt


MfG
Martin

[Fuerchau]

Da gibts leider keine Möglichkeit.
Bei der Erfassung muss sichergestellt sein, dass solche Daten nicht erfasst werden oder eben bei der Ausgabe.
Alternativ per Programm (oder SQL) alle Sonderzeichen eliminieren.

[Stoeberl]

Danke für die schnelle Antwort!

Hab ich fast befürchtet ...

Da werd ich mir wohl an Hand der QADBIFLD mal ein kleines Prüfprogramm basteln das die betroffenen Dateien ausgibt und evtl. gleich die Zeichen eliminiert ... und dann noch die ganzen Programme ändern, ein Traum!

[BenderD]

Hallo,

m.E. ist da auch die JOBCCSID mit im Spiel, die meist auf 65TausendIrgendwas (transparent Data) steht. Wenn man die korrekt einstellt, dann lässt sich da möglicherweise doch was machen, notfalls mit einer modifizierten Translation Table.

mfg

Dieter Bender

Da gibts leider keine Möglichkeit.
Bei der Erfassung muss sichergestellt sein, dass solche Daten nicht erfasst werden oder eben bei der Ausgabe.
Alternativ per Programm (oder SQL) alle Sonderzeichen eliminieren.

[Fuerchau]

Die hilft da nicht wirklich, da eine Umsetzung zwischen Job und Terminal nicht stattfindet.
Die Umsetzung EBCDIC<->Ascii zwischen AS/400 und Sitzung erledigt hier eben die Sitzung.

Ggf. hilft hier eine Anpassung der Umsetztabellen im Emulator.

[BenderD]

Hallo,

ich dachte da eher ans Verursacherprinzip, sprich den Quatsch beim schreiben zu bereinigen, war aber auch nur so eine Idee und so von leichter Hand kann man nicht von der 65xxx weg, da passiert ja dann einiges...

mfg

Dieter Bender

Die hilft da nicht wirklich, da eine Umsetzung zwischen Job und Terminal nicht stattfindet.
Die Umsetzung EBCDIC<->Ascii zwischen AS/400 und Sitzung erledigt hier eben die Sitzung.

Ggf. hilft hier eine Anpassung der Umsetztabellen im Emulator.

[Stoeberl]

@BenderD:
Ja, die CCSID 65535 ist bei uns auch eingestellt (Systemwert QCCSID) und wird durch *SYSVAL in allen Userprofiles verwendet. So einfach könnten wir das nicht ändern.

@Fuerchau:
Wie kann man den die Umsetztabellen im Emulator ändern? Finde nur was zu Umsetztabellen bei Datenübertragung, was sich aber bei der 5250er Sitzung nicht auswirkt.

MfG
Martin

[Fuerchau]

Das Ändern von *HEX auf z.B. 273 bringt hier tatsächlich nichts.

Ansonsten bleibt nur noch eine Update/Insert-Trigger der auf den entsprehchenden Feldern einen Replace macht.
Charmanter Nebeneffekt:
Bei Always-Update kann mittels simplen SQL "update file set name=name" eine Sofort-Bereinigung durchgeführt werden.

[BenderD]

Hallo,

nochmal zur Ausgangsfrage:
Carriage Return ist m.E. x'0D'
Line Feed ist m.E. x'0A'
und bei diesen Zeichen bekomme ich zumindest im interaktiven SQL kein Problem.
Bei x'15' schmiert mir der Mocha ab (Client Verhexel kommt mir nicht auf die Büchse), ich hab das nicht nachgesehen, aber das muss ein Bildschirmsteuerzeichen sein.
Aus obigem folgt für mich erst mal zweierlei:
- mit Cut and Paste krieg ich das x'15' nicht rein (da müsste der Bildschirm dasselbe Problem haben)
- rausfiltern darf ich das bei der Anzeige nicht, dann geht die Bildschirmsteuerung nicht mehr (zum Beispiel Cursor Positionierung)

Und da wird die 65535 für mich wieder zum Schwachpunkt, da selbiges dazu führt, dass aller Scheiß in die Datenbank durchgereicht wird, wobei es mich ein wenig irritiert, dass SQL bei einem insert ein Literal x'15' klaglos in die Datenbank malt, bei einem T e x t f e l d!!!

mfg

Dieter Bender

Hallo zusammen!

Hierbei kann es z.B. vorkommen das Zeichen wie "…" (Windows Ansi 1252 Hex '85') mitkopiert und in die AS400 Datei eingefügt werden. Aus diesem Zeichen wird durch die Umwandlung von Client Access ein Hex '15' was laut einer Tabelle das Steuerzeichen New Line (NL) ist.
MfG
Martin

[Fuerchau]

Naja, ein Textfeld kennt die DB/400 nicht deshalb heißts ja auch CHAR und kann deshalb alles von x'00' - x'FF' aufnehmen.

Dass vom Ursprung X'85' (ASCII) ein X'15' EBCDIC wird ist, denke ich ein Emu-Fehler, da eigentlich alle Zeichen > X'20' (ASCII) im Wesentlichen darstellbare Zeichen sind.

Aber sei's drum.
Mit der Hex-Eingabe von CA (Mocha kanns ggf. auch?, Stichwort Farbcodes in SEU), kann ich ein X'15' ja eingeben und mal schauen, was passiert.

Unabhängig davon werden auch alle Codes < X'3F' EBCDIC weitestgehend unverändert durch alle CCSID's gereicht.

[BenderD]

Hallo,

was ich noch nicht ganz auf die Reihe bekomme ist, dass ich über cut and paste ein Zeichen rein bekomme, das bei der Anzeige zu einem permanenten E/A Fehler führt, Codepage hin, Codepage her.
Rein Programm technisch krankt hier, dass weder bei der Bildschirmoperation noch global Errorhandling vorhanden ist, da bleibt dem armen Programm kein anderer Ausweg als der Wald...

mfg

Dieter Bender

Naja, ein Textfeld kennt die DB/400 nicht deshalb heißts ja auch CHAR und kann deshalb alles von x'00' - x'FF' aufnehmen.

Dass vom Ursprung X'85' (ASCII) ein X'15' EBCDIC wird ist, denke ich ein Emu-Fehler, da eigentlich alle Zeichen > X'20' (ASCII) im Wesentlichen darstellbare Zeichen sind.

Aber sei's drum.
Mit der Hex-Eingabe von CA (Mocha kanns ggf. auch?, Stichwort Farbcodes in SEU), kann ich ein X'15' ja eingeben und mal schauen, was passiert.

Unabhängig davon werden auch alle Codes < X'3F' EBCDIC weitestgehend unverändert durch alle CCSID's gereicht.

[Stoeberl]

@ Fuerchau:
Werd im ersten Schritt jetzt erst mal schauen welche Dateien / Programme von dem Problem betroffen sind. Prinzipiell sollten es eher die Ausnahme sein, das Daten aus anderen Dokumenten per Cut and Paste in die Emu kopiert werden.

@ Bender:
Finde auch das so ein Zeichen eigentlich erst gar nicht bis in die Datenbank durchgereicht werden sollte (zumindest nicht über die Emu). Vielleicht gibt's ja mal ein PTF für ...

MfG
Martin