Discussion :

[Metalman]

Bonjour,

Je recherche quelques infos sur la possibilité de lire du zFS depuis un zLinux.
Je n'ai pas tout à fait compris le redbook sur zFS... on utilise un DASD pour mettre une zFS dedans ? ou un crée des VSAM en LDS qui contiendront de la zFS ?

Du coup : est-il possible de lire de la zFS sur un zLinux ?

Merci d'avance !

[Jean GVE]

Bonsoir,
Les partitions zLinux tournent sur la même machine physique que zOS, mais sont complètement indépendantes.
En principe, les communications peuvent se faire par transferts de fichiers (pélican, CFT, etc.) ou par un système de message (MQ Series, etc.).
En espace développement, cela peut être plus laxiste car il y a moyen de travailler comme sous TSO sur un poste Linux ou Windows avec RDz (qui est un Eclipse adapté pour et par IBM). En "Prod", je pense qu'il faut même pas réver, tu risques d'être virer du bureau avant même d'avoir fini de poser la question !
Je ne peux que rester très vague, je ne suis pas ingénieur système mais développeur.
@+
Jean-Michel

[M.Dlb]

Je connais pas très bien les zFS et HFS. De ce que je sais, Les zFS sont des systèmes de fichiers Unix qui sont stocké dans un DataSet, et montés (au sens mount du monde Unix) par BPX. une fois montés ces zFS sont accessible par USS.

Pour zLinux, la notion de DataSet n'existe pas. zLinux est installé sur des DASD qui sont formatés pour Linux (le format est différent du format z/OS, par exemple il n'y a pas de VTOC à proprement parlé, enfin si il y a une mais elle a un fonctionnement très différent). A ma connaissance, il n'existe pas aucun moyen pour lire un DataSet zFS depuis zLinux. Il existait un driver zLinux, mvsdasd, non développé par IBM, pour lire des DataSet MVS depuis zLinux mais son utilisation est très limité (seulement les DataSet PS je crois) et il n'est pas plus disponible pour le download.

Il reste la solution du FTP ou du transfert de fichiers

[Metalman]

Wormful m'a donné la réponse !
Merci !

@Jean : pour les LPAR et z/VM je l'avais lu et compris. Mais c'est vrai que je n'avais pas pensé aux services pour accéder à des données... mais bref, je parlais surtout pour un accès direct aux disques sans réseau ou autre.

Je voulais en effet savoir si on pouvait lire les zFS et HFS depuis zLinux.
Les DASD zLinux doivent probablement être formatés comme les linux classiques : ext3/4, reiserFS ou autres...

Mais au final : il n'y a aucun outil officiel pour lire directement des DataSets z/OS depuis un zLinux, selon wormful. C'est ce que je voulais savoir.

[bernard59139]

Bonjour

Je ne suis pas spécialiste Unix (et autres trucs aix..), mais la commande CP m'a l'air de convenir, si elle est passée depuis l'unix ibm. trouvé dans le doc ibm:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 CP le.fichier.unix "//'le.fichier.mvs'"

Les quotes simples et doubles sont importantes. Les // aussi.

On peut aussi copier un fichier mvs vers unix avec un IEBGENER ou un REPRO. Nos équipes le font tous les jours.

Bien sur, il faut avoir toutes les autorisations RACF nécessaires..

[Luc Orient]

Bonjour,

et en regardant du coté des fichiers NFS (Network File System) ?

[Metalman]

Nanananana !
Je ne veux absolument pas de NFS ou autre service réseau !


Je veux juste savoir si une partition z/OS peut être lue ou écrite depuis un zLinux !
On m'a expliqué plus haut qu'un driver pour zLinux a existé, mais qu'il n'était pas ultra fonctionnel, et qu'il a probablement disparu.


Pour le CP et IEBGENER, je pense que ça passe pour les USS ? Mais pas pour zLinux ?
Où avez-vous trouvé l'explication pour le CP ? (c'est fortiche de le proposer celui-là)

[bernard59139]

USS, je ne sais pas ce que c'est (en informatique).

Nous envoyons des fichiers vers "unix", et nous en recevons.
Lorsque nous envoyons, c'est avec IEBGENER ou des scripts unix qui s'occupent de faire la copie. J'ai trouvé CP dans un script.
Mais 99% de nos copies/transferts sont habillées de scripts divers.

Je suis bien incapable de dire quelles sont les contraintes.

CP est documenté, et pour IEBGENER la doc à regarder est celle du JCL.

Bernard

[Metalman]

USS : Unix System Services, l'espèce de started task qui donne un environnement Unix dans le z/OS

Mais votre Unix est dans le mainframe ? (dans un zBx ?) ou à côté sur une autre machine ?
Mais en effet, s'il y a plein de scripts... c'est pas impossible que ça transfert par le réseau

Merci de toutes vos réponses en tout cas !

[bernard59139]

un exemple ecrit vite fait à partir de la doc IEBGENER:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
//S1 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD PATH='/samples/comics.lst',
//  FILEDATA=TEXT,PATHOPTS=ORDONLY,
//          LRECL=100,BLKSIZE=1000,RECFM=FB 
//SYSUT2 DD SYSOUT=*

J'utilisais parfois ce genre de jobs pour récupérer une log.

Ensuite, dire de quel unix il sagit, je n'en sais strictement rien. Désolé.

[Metalman]

Merci bien du détail !

Mais je n'avais pas encore vu de JCL utilisant un chemin dans le style Unix (avec des /) !
Je vais me renseigner là dessus... mais il est très très probable que ça soit un USS qui soit associé... merci bien encore une fois !

EDIT : En allant là dessus (merci google) : http://ibmmainframeforum.com/viewtopic.php?f=48&t=2490
Je vois en effet que ça passe par USS... donc pas de zLinux à l'horizon...
Mais maintenant j'ai une idée de la complexité pour transférer un dataset z/OS vers un fichier USS

EDIT2 : Après discussion avec quelqu'un de plus expérimenté que moi... en effet il faut toujours passer par plusieurs services réseaux pour transférer un fichier depuis zLinux vers z/OS... (zLinux (NFS/FTP/SFTP/...) -> USS -> z/OS) et pareil dans le sens inverse.
Et on m'a aussi soufflé : vous ne connaissez peut être pas USS, car il se fait aussi appeler OMVS ou Open edition MVS

[Luc Orient]

...
Et on m'a aussi soufflé : vous ne connaissez peut être pas USS, car il se fait aussi appeler OMVS ou Open edition MVS

Petite précision, Open edition MVS (OMVS) est l'ancien nom de USS. Comme souvent chez IBM, les noms des produits changent et on finit un peu par s'y perdre ...