Restauration ADRDSSU sur PC

Bonjour,

Je suis en train d'étudier la restauration de sauvegardes ADRDSSU sur un PC, soit par un outil existant soit en le développant.

J'ai une bonne expérience PC, un bonne expérience du monde de la sauvegarde (ayant travaillé par le passé chez un éditeur) et quelques notions du monde mainframe (plutôt AS/400) qui me proviennent de cette même expérience.

La sauvegarde en question est réalisée sur z/OS puis compressée et passée à AMATERSE.

A-priori ces étapes permettent de préserver l'intégrité des données pendant le transfert (FTP).

Se pose alors la question de l'interprétation du contenu du fichier récupéré. J'ai trouvé de la documentation sur le site d'IBM, notamment sur ADRTAPB.

Au point où j'en suis, je me dis qu'il s'agit ni plus ni moins que de se déplacer dans un bloc de données en interprétant les différents champs qu'il contient pour y retrouver le début et les attributs (notamment le nommage) des fichiers. D'un autre coté, je ne suis pas vraiment rassuré par le peu de littérature sur le sujet…

Je suis bien conscient que j'y trouverai de l'EBCDIC et qu'il faudra (éventuellement) le traduire.

Est-ce qu'un tel projet a des chances d'aboutir (idéalement sur un succès :mrgreen:) ?

Y a-t-il des outils qui le permettent déjà ?

Quels sont les écueils que je risque de rencontrer ?

Est-ce que certaines spécificités des fichiers z/OS (bloc fixe / bloc variable notamment) risquent de me bloquer ?

Enfin, comment m'assurer que les données qu'on me fournit sont intègres et que les données que je génère le sont également (dans le monde PC on a l'habitude d'utiliser des sommes de contrôle - MD5, SHA, etc.) ?

Merci d'avance.

Quel interêt?
Dans tout ton processus, tu a oublié amaterse qui est un format propriétaire, pas ou peu documenté. J'ai déjà entendu parler de programmes pour faire un UNPACK sur PC, mais je n'en retrouve plus les références.

Pour ce qui est des problèmes pendant l'exploitation de ton fichier DUMP, prépare toi à bien des soucis de toutes sortes ( rien que changement de version de z/os peut donner du fil à retordre).
Et à moins de baigner dans les macro MVS et C (pour adaptation au pc), je doute de la réussite.

Merci pour la réponse.

Quel intérêt ? Pour être tout à fait franc, le contexte de la demande (plein d'infos techniques et peu de temps pour répondre) a fait que cette question est passée à la trappe. Je m'interroge moi-même mais j'imagine qu'il y en a un. J'ai questionné sur l'éventualité d'une approche différente, mais le but est justement de minimiser les manips sur le z et de reporter le traitement sur PC.

Le passage par AMATERSE est la méthode choisie par la personne qui exploite la machine pour me fournir un jeu de données d'exemple, mais on doit pouvoir faire plus simple (le Redbook « IBM System z Personal Development Tool Volume 3 Additional Topics » mentionne xmit, qui est peut-être un peu mieux documenté).

Mais si je comprends bien, même en éclaircissant cette zone c'est pas gagné pour autant…

Pour ce qui est de baigner dans MVS et C, je dois pouvoir mettre en place une équipe qui aurait ces compétences.

Bonjour,

Une piste ici

Cordialement,

Merci pour le lien !

J'étais justement en train de lire cette discussion (très intéressante dans laquelle on lit notamment que TERSE est une implémentation de LZW et doit donc être exploitable via un outil capable de prendre en charge cet algo - je suis en train de creuser du côté de « ncompress », original Lempel-Ziv compress/uncompress programs) et je me demandais si j'allais pouvoir mettre la main sur le fichier « tersepc
.zip » dont il est question. Voilà qui est fait. Encore merci !

Hello,

A mon humble avis, il faut se poser les bonnes questions sur l'intérêt de faire ça hors du z/OS, sachant qu'il y a déjà tout ce qu'il faut dans z/OS. Si vous souhaitez perdre du temps précieux pour faire du reverse engineering de fonctions de base du z/OS, vous allez dans la bonne direction !

Pour commencer, voici quelques questions en vrac :
Quel est l'objectif final de cette manipulation ? Pour exploiter quels fichiers ? Quels traitements doivent être effectués par la suite ? Est-ce que ces traitements ne peuvent pas être faits sur z/OS ?
Qui vous a demandé ça ? Quelles sont ses motivations ?

Bonjour,

Je me suis justement posé ces questions (ainsi qu'à mes interlocuteurs).

La finalité est simple, migrer d'un environnement z/OS vers un environnement Unix/Linux.

La raison du souhait de voir le traitement fait en dehors du z/OS, est simplement motivée par l'envie d'investir au minimum sur des manipulations z/OS. On a des sauvegardes qui contiennent de vieilles données (qui n'ont pas bougé depuis), exploitons-les directement.

Les retours que j'ai de mes interlocuteurs sont presque tous rassurants, m'indiquant que tout ça est suffisamment documenté pour qu'on puisse s'en sortir. Pourtant, la documentation «*Format of the DFSMSdss Dump Data Set*» du «*DFSMSdss Storage Administration Guide*» me paraît loin d'être suffisante…

D'un autre coté, les lectures que je fais en parallèle (et les échanges ici) me laissent entendre que je pars dans un projet obscur dans lequel je risque de laisser des plumes.

Bonjour

J'ai deja eu à faire ce genre de travail pour alimenter un infocentre. Ce que nous avions mis en place à l'époque (+ 15ans)

1. création d'un environnement de test, dans le même mvs surtout pour avoir accès aux archives sur k7 & bandes.
2. mise en place d'une sécurité très stricte pour ne pas maj les données mvs (avec, par ex, interdiction absolue de maj les données de prod)
3. restor dans cet environnement
4. traitements divers (depack des zones packées, mise au format csv,..)
5. envoi sur serveur

Toute la partie MVS était automatisée (demande, traitement, rapports...). Nos seules interventions (de l'équipe mvs) étaient la maj de référentiels : description des fichiers mvs , maj des copy_cobol, .....

Si ton projet démarre comme tu le souhaite actuellement, les problèmes peuvent venir de plusieurs origines différentes:

• si les DSORG sont différents de PS, il faudra convertir en PS sur le PC. le PC ne connaît que le DSORG=PS, et ne connaît pas VS (vsam), U (undefine), PSE (PS extended)....
• si le contenu des fichiers est compressé (compress ispf ou hard mvs/sms), ca risque de coincer
• si le contenu de fichiers est crypté

bon courage
B59

ps: on peut très bien transférer un fichier ADRDSSU vers un PC, pas besoin d'AMATERSE. si tu es interessé, je pense avoir gardé des exemples.

Bonjour,

Je vous remercie tous pour vos avis et les pistes que vous m'avez données.

Les différentes recherches que j'ai menées, ainsi que les échanges que j'ai eus avec vous m'ont amené à la conclusion que ce projet n'est pas une bonne idée.

Beaucoup trop de risques techniques, beaucoup trop d'incertitudes qui conduiraient à une réponse qui ne serait pas acceptée car trop couteuse par rapport au travail de migration qui pourrait être fait directement sur le z.

Encore merci pour votre aide.