CCSID 273/37 und Java-Objekte im IFS

[Ahrendt]

Hallo,
ich habe ein Problem bei der Installation von Java-Objekten von einer AS/400 auf eine Andere.

Hierbei hat das Quellsystem die folgenden Systemwerte:
QCNTRYID DE,
QLANGID DEU
QCHRID Zeichensatz 697 und Codepage 273

Das Zielsystem hat die Werte
QCNTRYID EN,
QLANGID ENU
QCHRID Zeichensatz 697 und Codepage 37

Bestimmte Hexwerte sind bei dieser Kombination unterschiedlich definiert und hier vermute ich auch das Problem:

Übertragene Java-Programme lassen sich nicht aufrufen und auch nicht neu umwandeln. Es gibt immer den gleichen Fehler

java.lang.UnsatisfiedLinkError

(Im Sourcecode kann ich sehen, daß z.B. die Zeichen [ und ] anders umgesetzt wurden.)

So bin ich bei der Installation vorgegangen:
1. Das Hauptverzeichnis ist im \Root angelegt. CCSID der Quelle ist 850 für Hauptverzeichnis, alle Unterverzeichnisse und Streamfiles 850
2. Auf der Zielmaschine habe ich das Hauptverzeichnis manuell angelegt (geht glaube ich nicht anders) mit CCSID des Jobs 37.
3. Das Hauptverzeichnis habe ich aus Laufwerk zugeordnet und über IFS freigegeben
4. Alle Unterverzeichnisse habe ich auf CD gebrannt und dann mit map und drop übernommen . Diese haben dann auch alle CCSID 850

Wer kann mir bei diesem Problem helfen?

Viele Grüße
Stefanie Ahrendt

[Fuerchau]

Genau das ist das Problem !
Bei der Übertragung darf kein Wechsel der CCSID erfolgen, da (wie schon bemerkt) sich Hexcodes in ihrer Bedeutung ändern.
Oder für deine Quellen solltest du per CPYTOSTMF die CCSID generell auf 850 (ASCII)bzw 1252 (ANSI) ändern (dabei erfolgt auch eine Codeanpassung).
Bei Java-Objekten (Klassen) ist das Problem noch größer !
Java-Objekte enthalten kompilierten Code der beim Wechsel zu einer anderen CCSID auch zu einem anderen Binärcode wird. Damit verliert das Objekt seine Gültigkeit.

Am besten packst du deine Java-Quellen/Objekte per SAV in eine Save-File die du dann per CD auf dem Zielsystem mit RST wiederherstellst. In diesem Fall werden alle CCSID's der Objekte/Verzeichnisse übernommen.

[Ahrendt]

Hallo Fuerchau,

vielen Dank für die schnelle Rückmeldung.
Ich werde das mal ausprobieren...

Eine paar kleine Fragen hätte ich aber noch:

Auf meinem Zielsystem haben ja alle Unterverzeichnisse und Objekte schon ID 850 - liegt es nur an der Hauptverzeichnis-ID 37? Mein Job hat im Standard 65535 (nicht 37) als ID - sollte ich das umstellen?

Beim Restore von Cobolsourcen hatte ich auch schon das Problem -> aus }} wurde üü in der Quelle. Und das obwohl ich über Savefile gesichert und restored habe (allerdings mit SAVOBJ/RSTOBJ). Die Sourcedateien haben die gleiche CCSID. Hat beim Restore die CCSID des Jobs eine Bedeutung?

Um hier sicherzugehen werde ich wohl das Programm ändern und direkt auf die Hexwerte abfragen... - das geht ja zum Glück.

Viele Grüße
Stefanie

[Fuerchau]

Das mit den Hexwerten solltest du lassen !
Wichtig ist, dass der Job eine korrekte CCSID hat. Bei 65535 erfolgt KEINE Korrektur der Codes.
Wenn du in COBOL das Zeichen "}" auf den Hexcode für 273 prüfst, wird das auf dem System mit 037 nicht funktionieren, da dort der Hexcode ein anderer ist !!!
Du musst dir die Hexcodes der "varianten" Zeichen aus einer Datei mit CCSID 273 laden. Die Zeichen werden beim Lesen dann in die CCSID des Job's konvertiert und können nun gegen die Eingabe geprüft werden.

Was die CCSID allgemein angeht, so ist sie immer Objekt-bezogen !
Ich kann also durchaus bei jeder Datei eine andere CCSID haben. Wichtig ist jedoch, dass zur Ausführungszeit der Job eine CCSID hat, da es sonst zu Datenproblemen kommt.

[Ahrendt]

Generell hast du sicherlich Recht mit den Hexwerten. In meinem speziellen Fall sehe ich das aber nicht als so problematisch an. Es geht hier um fix definierte Hexwerte in Zahlungsverkehrsformaten. Hier ist z.B. das Ä mit dem Hexwert 4A vorgegeben. Ob es in der Darstellung ein Ä oder [ ist ist egal. Wichtig ist, daß der Wert 4A rauskommt...- das fertige Format geht dann von der AS/400 über einen GatewayPC über ISDN an die Deutsche Bundesbank... .

Hier habe ich aber dadurch noch ein ganz anderes Problem. Der Anwender (Kunde) sieht in seiner Anwendung (DSPF zur Zahlungsauftragerfassung) aufgrund seiner Einstellungen (CCSID in Job-66353, Emulation mit ClientAccess 500 MNCS -)

Sonderzeichen; in der Datenbank ist dies mit korrekten "deutschen" Hexwerten belegt und es geht ok raus.

Gerne hätte ich natürlich die Darstellung als ÄÖÜß UND in der Datenbank korrekte Hexwerte. Dies scheint aber nur zu funktionieren, wenn ich die Hexwerte in der Datei per Programm manipuliere - Umsetzung 37 nach 273 im Ausgang und 273 nach 37 im Eingang. Dann ist es in der Ansicht richtig und auch im Hexwert.

Die Werte für die CCSID im Userjob, Emulation und Systemwerte kann ich leider nicht ändern. Ich habe nur die Möglichkeit die Dateien mit einer bestimmten CCSID zu erstellen und meinen eigenen Job zu verändern.

[Fuerchau]

Das Thema CCSID ist auch hier wieder falsch betrachtet !
Wenn die Emulation auf CCSID 500 steht MUSS der Job auch auf 500 stehen.
Beim DB-Zugriff wird zwischen 500 und 273 oder 500 und 037 korrekt gewandelt.

Wichtig ist, dass das Terminal IMMER zum Job passen muss. 65535 kann nur dann verwendet werden, wenn ich innerhalb des Systems konsistent bin und auch die DB besser auf 65535 steht.
Sobald ich aber ein Aussenverhältnis eingehe muss ich mich darum kümmern.

Das Thema CCSID wird im übrigen genauso stiefmütterlich behandelt wie das Thema Sicherheit. Irgendwie wirds schon hinhauen.