z/OS-Datasets aus der UNIX-Shell erreichen: die Notation //'HLQ.NAME', tsocmd und Encoding-Tags

Ziel

Daten aus der Shell zwischen einer z/OS-UNIX-Datei (USS) und einem klassischen MVS-Dataset kopieren und dabei EBCDIC/ASCII-Beschädigungen vermeiden.

Voraussetzungen

• Eine z/OS-UNIX-Shell-Sitzung (SSH, Telnet oder rlogin in USS).
• Lese-/Schreibberechtigung auf das Ziel-Dataset (siehe den RACF-Artikel) und, für tsocmd, ein TSO-Segment im RACF-Profil des Benutzers.

Schritte

1. Um ein klassisches Dataset in einem Shell-Befehl anzugeben, wird es in der MVS-Notation //'HLQ.DATA.SET' in Anführungszeichen gesetzt (ohne die inneren einfachen Anführungszeichen wird //NAME mit dem TSO-Präfix des Benutzers, in der Regel der Benutzerkennung, ergänzt). So behandelt beispielsweise cp die Angabe wie jedes andere Pfadargument:

   cp ./myfile.txt "//'HLQ.MYFILE'"
   

   IBM dokumentiert einen Stolperstein, den es als beabsichtigtes Verhalten einstuft: Wird eine USS-Datei in ein sequenzielles Dataset mit exakt gleichem Namen und gleicher Schreibweise kopiert oder verschoben (zum Beispiel cp SMPL.DATA "//'SMPL.DATA'" im aktuellen Verzeichnis), schlägt dies mit FSUM6259/EDC5045I fehl. Der dokumentierte Workaround besteht darin, der Quelle ./ voranzustellen, wie in cp ./SMPL.DATA "//'SMPL.DATA'".
2. Soll statt einer Dataset-Kopie ein TSO-Befehl ausgeführt werden, dient tsocmd "COMMAND ..." (oder in aktuellen Releases das Utility tso) aus der Shell, zum Beispiel tsocmd "LISTDS 'HLQ.MYFILE'", um die Attribute eines Datasets zu prüfen, darunter Satzformat (RECFM) und logische Satzlänge (LRECL). Beide müssen zwischen Quelle und Ziel zueinander passen, damit eine Kopie sinnvolle Ausgaben liefert (feste gegenüber variablen Sätzen, abweichende LRECL und Ähnliches sind häufige Ursachen für abgeschnittene oder verstümmelte Daten, unabhängig von jedem Encoding-Problem).
3. Vor dem Verschieben von Text zwischen USS und einem Dataset ist das Encoding-Tag der Datei zu prüfen und zu setzen. z/OS-UNIX-Dateien können ein Tag tragen, das ihren Zeichensatz (Coded Character Set) angibt. Klassische Datasets mit Text sind üblicherweise EBCDIC (häufig Codepage IBM-1047), während die meisten Tools, die ein Agent bereits kennt, ASCII/UTF-8 voraussetzen. Mit chtag -p filename wird das aktuelle Tag einer Datei angezeigt, mit chtag -t -c codeset filename wird eines gesetzt, zum Beispiel chtag -t -c ISO8859-1 filename für eine ASCII-/Latin-1-Datei.
4. Die automatische Konvertierung getaggter Textdateien wird über die Umgebungsvariable _BPXK_AUTOCVT gesteuert (ON, oder ALL, um auch die Unicode-Konvertierung einzuschliessen; der systemweite Standard stammt aus AUTOCVT in BPXPRMxx) und setzt ein korrektes Tag mit gesetztem Text-Flag voraus (chtag -t). Fehlt eines von beiden, überträgt eine «transparente» Kopie die Bytes stillschweigend ohne Umsetzung, was wie eine Datenbeschädigung aussieht und nicht wie ein offensichtlicher Encoding-Fehler. Für eine explizite, einmalige Konvertierung dient iconv -f ISO8859-1 -t IBM-1047 in > out.

Erwartetes Ergebnis

Eine Kopie bzw. Übertragung, bei der Satzgrenzen (RECFM/LRECL) und Text-Encoding beide den Erwartungen der Empfängerseite entsprechen. Geprüft wird dies durch Öffnen des Ergebnisses und nicht anhand der Erfolgsmeldung des Kopierbefehls (eine Bytekopie mit falschem Encoding «gelingt» trotzdem).

Grenzen und Prüfbasis

Befehlssyntax und das Verhalten bei FSUM6259 entsprechen den zitierten IBM-Quellen. Aktuelle RECFM-/LRECL-Werte sind mit tsocmd "LISTDS ..." an den tatsächlich betroffenen Datasets zu prüfen und nicht als Standardwerte anzunehmen, da eine Abweichung ein Datenproblem ist und kein Berechtigungsproblem. Es wird kein Experiment und keine Messung beansprucht.