View Full Version : Fehlermeldung bei SNDNETSPLF
takeoff/400
11-11-08, 04:13
SNDNETSPLF bricht ab mit dem Hinweis, daß für 697/500 keine entsprechende Umsetztabelle gefunden werden kann!? Allerdings ist bei uns überall 697/1141 hinterlegt, nirgends 697/500. aber selbst wenn, müsste es doch trotzdem funktionieren. Welche Einstellungen könnten da falsch sein? SYSVAL's und USER sind in Ordnung, WRKDIRE ebenso. Wer kennt dieses Problem?? :confused:
(V5R4)
Schau dir die SPLF-Attribute mal an, was da als CHRID (Zeichen-ID) hinterlegt ist.
Bei SNADS ist leider keine CCSID/CHRID konfigurierbar, ich nehme mal an, dass snads daher immer mit CCSID 500 (International) arbeitet.
Jetzt gibts ggf. 3 Möglichkeiten:
- SNDNETSPLF ... DTAFMT(*ALLDATA)
- Erstellen einer Remote-OUTQ zum Zielsystem
- SNDTCPSPLF
Ansonsten ist folgender Hinweis entscheidend:
i5/OS function support for CCSIDs (http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/nls/rbagsccsidsyssupport.htm)
SNACoded character set identifier (CCSID) support is built into SNA Distributed Services (SNADS). SNADS supports CCSIDs by any user ID, system name, or destination queue name. However, other SNADS services such as SNDNETF do not provide CCSID conversion.
Ich denke, SNDNETSPLF gehört ebenso dazu.
Ich möchte hier gerne auf eine professionelle Lösung hinweisen:
i-effect *EMAIL - B2B-Kanal für niedrige Übertragungsmengen (http://www.i-effect.de/de/i-effect/modul_email.php)
Mit freundlichen Grüßen
M.H.
takeoff/400
11-11-08, 21:48
Die Fehlermeldung war Tabelle Q500697A6Z nicht gefunden, allerdings gab es eine Q500697037 am System, die habe ich auf den "gewünschten" Namen kopiert und jetzt läufts wieder einwandfrei. Keine Ahnung wie das zustande kam, aber jedenfalls vielen Dank für die Hilfe!:D
Nunja, 1141 entspricht nicht 037, es wird daher bei Sonderzeichen insbesonders Umlauten und "ß" zu Umsetzungsproblemen kommen.
A6Z entspricht der 1141.
Die Tabelle Q500695A6Z scheint da eher als Basis zu passen.
takeoff/400
12-11-08, 23:33
ok, vielen Dank für die Info. Dann werde ich die 697A6Z löschen und von der 695A6Z nochmals kopieren. Wie diese Tabelle allerdings verschwinden konnte, ist fürmich nicht nachvollziehbar. Dankeschön.
Die Tabelle gibts wohl im Standard gar nicht.
Schließlich kann man nicht alle möglichen Kombinationen vorhalten.
SNADS ist ja auch ein ziemlich altes Produkt und arbeitet wohl mit den TBL-Objekten.
SQL ist da wohl nicht mehr drauf angewiesen sonst hätte man da schon des öfteren Probleme bekommen.
Ich kann mich noch an Zeiten erinneren, in denen ich auch beim Zugriff auf Dateien den Hinweis auf fehlende Tabellen bekam.
Das neue Konvertierungs-API (iconv) kann dann wohl intern automatisch den Umweg über UCS2 gehen.