En ce moment, j'essaye de télécharger et de télécharger des fichiers avec des longueurs d'enregistrement variables à partir d'un mainframe IBM exécutant zOS 2.1. Comme ce type: How to FTP a variable length file from linux to mainframe z/OSQuelle est la signification du premier octet de chaque jeu d'enregistrements lors du téléchargement du fichier av (b) depuis z/OS via FTP en utilisant "TYPE E" et "MODE B"
curl --user "******" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'" | hexdump
0000000 dead cafe babe
0000006
curl --user "******" --quote "site RDw" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'" | hexdump
0000000 000a 0000 dead cafe babe
000000a
Cela semble bon. Le rdw est "000a 0000" et l'enregistrement "dead cafe babe". Mais. Si je le télécharge à nouveau - même en utilisant "quote site RDw" le serveur va ignorer le RDW et le stocker dans le cadre des données réelles.
curl --user "******" --quote "site RDw" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'" > SOME.FILE.NAME
cat SOME.FILE.NAME | curl --user "******" --upload-file "-" --quote "site RDw" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'"
0000000 000c 0000 0008 0000 dead beef
000000c
Puisque ce n'est pas ce que je voulais, j'ai cherché un peu plus. Et - J'ai trouvé cet article: http://www-01.ibm.com/support/docview.wss?uid=swg21188301
Et lui a donné un autre essai.
curl --user "******" --quote "TYPE E" --quote "MODE B" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'" | hexdump
0000000 4000 04de adbe ef00
0000007
Cela semblait intéressant. Donc, je l'ai comparé avec un autre fichier, contenant un ensemble de données plus ...
0000000 4002 cbdc...
00002ce
Et un autre ...
0000000 8000 16f0...
0000019 4000 16f0...
0000032
Ma première impression est: 80 semble indiquer qu'il y aura plus ensembles de données, tandis que le 40 indique le dernier. Cela semblait être vrai pour chaque fichier que j'ai essayé. Pour un fichier normal avec des longueurs d'enregistrement variables ainsi que pour un fichier bloqué avec les longueurs d'enregistrement variables.
J'ai donc essayé de le télécharger à nouveau ...
curl --user "******" --quote "TYPE E" --quote "MODE B" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'" > SOME.FILE.NAME
cat SOME.FILE.NAME | curl --user "******" --upload-file "-" --quote "TYPE E" --quote "MODE B" --verbose --silent --show-error "ftp://themainframe/'SOME.FILE.NAME'"
Et il semblait travailler
bien - au moins maintenant, je suis en mesure de transférer des fichiers avec des longueurs d'enregistrement variables et de la mainframe tout en préservant les longueurs d'enregistrement.
Mais - et voici la question: est le premier octet de chaque enregistrement « seulement » un indicateur pour wheather il y aura plus de jeux de données? Ou est-ce que je manque quelque chose?
Vous devez utiliser '--quote « locsite RDW »' si vous téléchargez. [locsite] (https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.halu001/locsite.htm) est l'inverse de 'site'. –
Malheureusement, cela ne fonctionnera pas: '> emplacement rdw <500 unknown command locsite' –
Désolé, mon mauvais. locsite n'est valide que pour un transfert z/OS vers z/OS. Unix/Windows etc n'ont pas de concept de fichiers orientés enregistrement, il n'est donc pas possible de faire ce que vous voulez. Il y a un bon fil à ce sujet [ici] (https://groups.google.com/d/msg/bit.listserv.ibm-main/QIAmIGxP0XA/2ssqVJtTIRcJ). –