Accéder aux datasets z/OS depuis le shell UNIX : notation //'HLQ.NAME', tsocmd et balises d'encodage

Objectif

Copier des données entre un fichier z/OS UNIX (USS) et un dataset MVS classique depuis le shell, en évitant la corruption liée à l'EBCDIC/ASCII.

Prérequis

• Une session shell z/OS UNIX (SSH, telnet ou rlogin vers USS).
• Une autorisation de lecture/écriture sur le dataset cible (voir l'article sur RACF) et, pour tsocmd, un segment TSO dans le profil RACF de l'utilisateur.

Étapes

1. Pour référencer un dataset classique dans une commande shell, utilisez la notation MVS //'HLQ.DATA.SET', entre guillemets. Sans les apostrophes internes, //NAME est préfixé par le préfixe TSO de l'utilisateur, en général son identifiant. Par exemple, cp traite cette notation comme n'importe quel autre chemin :

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

   IBM documente un piège qu'elle classe comme un comportement conforme à la conception : copier ou déplacer un fichier USS vers un dataset séquentiel portant exactement le même nom et la même casse (par exemple cp SMPL.DATA "//'SMPL.DATA'" dans le répertoire courant) échoue avec FSUM6259/EDC5045I. Le contournement documenté consiste à préfixer la source par ./, comme dans cp ./SMPL.DATA "//'SMPL.DATA'".
2. Pour exécuter une commande TSO plutôt qu'une copie de dataset, utilisez tsocmd "COMMAND ..." (ou, sur les versions récentes, l'utilitaire tso) depuis le shell. Par exemple, tsocmd "LISTDS 'HLQ.MYFILE'" permet de vérifier les attributs d'un dataset, notamment son format d'enregistrement (RECFM) et sa longueur d'enregistrement logique (LRECL). Ces deux valeurs doivent être compatibles entre la source et la cible pour qu'une copie produise un résultat correct : enregistrements fixes ou variables, LRECL différents, etc. sont des causes fréquentes de données tronquées ou illisibles, indépendamment de tout problème d'encodage.
3. Avant de transférer du texte entre USS et un dataset, vérifiez et définissez la balise d'encodage du fichier. Les fichiers z/OS UNIX peuvent porter une balise identifiant leur jeu de caractères codé ; les datasets classiques contenant du texte sont par convention en EBCDIC (couramment la page de codes IBM-1047), alors que la plupart des outils que connaît déjà un agent supposent de l'ASCII/UTF-8. Utilisez chtag -p filename pour afficher la balise actuelle d'un fichier et chtag -t -c codeset filename pour en définir une, par exemple chtag -t -c ISO8859-1 filename pour un fichier ASCII/Latin-1.
4. La conversion automatique des fichiers texte balisés est pilotée par la variable d'environnement _BPXK_AUTOCVT (ON, ou ALL pour inclure la conversion Unicode ; la valeur par défaut du système provient de AUTOCVT dans BPXPRMxx), associée à une balise correcte avec l'indicateur texte activé (chtag -t). Sans ces deux éléments, une copie « transparente » déplace silencieusement les octets sans les convertir, ce qui ressemble à une corruption de données plutôt qu'à une erreur d'encodage évidente. Pour une conversion explicite et ponctuelle, utilisez iconv -f ISO8859-1 -t IBM-1047 in > out.

Résultat attendu

Une copie ou un transfert dans lequel les limites d'enregistrement (RECFM/LRECL) et l'encodage du texte correspondent à ce qu'attend le côté récepteur. Vérifiez-le en ouvrant le résultat, et non en vous fiant au succès rapporté par la commande de copie (une copie d'octets avec le mauvais encodage « réussit » quand même).

Limites et base de vérification

La syntaxe des commandes et le comportement de FSUM6259 sont ceux décrits dans les sources IBM citées. Vérifiez les valeurs RECFM/LRECL réelles avec tsocmd "LISTDS ..." sur les datasets concernés plutôt que de supposer des valeurs par défaut, car une incompatibilité est un problème de données, pas un problème de permissions. Aucune expérience ni mesure n'est revendiquée.