Utiliser WinZip avec de gros fichiers

Au sommaire de cette édition :

– Utiliser WinZip avec de gros fichiers
– Trouver des champs tronqués quand on utilise CPYFRMSTMF
– Ajouter une signature numérique à l’IBM i
– Travailler avec des fichiers physiques et logiques
– Créer un tampon horodateur pour FTP

Retrouvez toutes les Boîtes à Outils System iNews.

Utiliser WinZip avec de gros fichiers

Q. L’utilitaire JAR peut-il zipper convenablement un fichier quelle que soit sa taille ?  J’ai un très gros fichier d’environ 6 Go qu’une compression réduit à environ 500 Mo. J’utilise ce qui suit dans un CLP pour le comprimer :

CHGCURDIR DIR(‘/home/myfolder/’)
STRQSH CMD(‘jar cfM myfile.zip myfile.txt’)

L’endroit qui doit recevoir ce fichier utilise WinZip pour le dézippage. Quand j’ai testé à l’aide de WinZip pour extraire le gros fichier, j’ai obtenu le message « Error: Unable to extract file. » La taille du fichier extrait ne correspond pas à la taille décompressée enregistrée dans le fichier zip. Quand je crée une version plus petite du fichier d’environ 80 000 Ko, WinZip dézippe le fichier correctement.

Si j’étais certain que le fichier puisse être dézippé, je pourrais ajouter une étape FTP à mon programme CL.

R. Il faut probablement mettre à niveau la version de WinZip que vous utilisez. Jusqu’au début de 2010, WinZip avait une limite de 4 Go parce qu’il ne reconnaissait pas les extensions 64-bit du format de fichier zip, ce qui vous limitait à 65 535 fichiers et à une taille d’archive décompressée de 4 Go.

Vous obtenez l’erreur “Size of the extracted file does not match” parce que WinZip regarde seulement 32 bits de la valeur de la taille de fichier. Curieusement, la décompression fonctionne parce que c’est un processus progressif indépendant de la taille du fichier. Mais WinZip a un mécanisme protecteur qui empêche d’utiliser une archive corrompue, et c’est ce mécanisme qui est défaillant.

Les extensions 64-bit, reconnues par le plus récent WinZip, suppriment toutes les limites de capacité d’archive. Vous pouvez donc créer des archives de toutes tailles que votre système de fichiers natifs supporte, et éliminer le mécanisme protecteur qui provoque l’échec de votre décompression.

—donkeyhotey et Mel Beckman

Trouver des champs tronqués quand on utilise CPYFRMSTMF

Q. Est-il possible de déterminer quels enregistrements et/ou champs sont tronqués quand on copie des enregistrements de longueur variable à l’aide de CPYFRMSTMF, d’un fichier stream dans un fichier à longueur d’enregistrement fixe ? Je sais que des enregistrements sont tronqués parce que j’obtiens le message d’avertissement suivant dans le job log :

CPIA083 – Stream file copied to object with truncated records

J’essaie de transférer en amont des fichiers délimités par CRLF de diverses structures et je dois extraire toutes les données dans les enregistrements de longueur variable. Il est extrêmement long d’essayer de trouver les fichiers tronqués parmi des milliers ou des dizaines de milliers d’enregistrements copiés.

J’ai essayé d’utiliser le fichier d’enregistrement d’erreurs, mais comme l’enregistrement tronqué est quand même copié, je pense que le système ne le traite pas comme une erreur et ne l’enregistre pas dans le fichier des erreurs. J’ai soupçonné que la commande utilise SQL en coulisses pour faire son travail et j’ai fait une expérience avec la commande Get Diagnostics, en vain.  

R. CPYFRMSTMF demande un fichier physique plat (flat) non-DDS (c’est-à-dire créé avec une longueur d’enregistrement fixe) ou un SRCPF comme cible. D’après la documentation CPYFRMSTMF d’IBM, si les enregistrements dans FROMSTRMF sont délimités par des champs, ERRRCDFILE doit avoir une longueur d’enregistrement minimum égale à la somme de la longueur d’enregistrement TOFILE, du nombre de champs dans TOFILE, et 813. C’est le “et 813” qui peut prêter à confusion : la longueur d’enregistrement ERRCDFILE doit avoir au moins 813 octets de plus que les deux autres valeurs (longueur d’enregistrement et nombre de champs).

—Peder Udesen et Mel Beckman

Ajouter une signature numérique à l’IBM i

Q. Notre banque est en train de remanier le mode d’échange de fichiers concernant les paiements (positif et compensation). Nous avons satisfait à toutes les nouvelles exigences sauf une : l’obligation de signer numériquement tous les fichiers envoyés, en particulier l’information de paiement positif.

Actuellement, nous générons le fichier au format requis dans QTEMP, puis nous faisons un FTP en utilisant SSL. Cela fonctionne bien, mais je ne sais pas comment ajouter une signature numérique au fichier. Bien sûr, nous pourrions exporter le fichier sur un PC et ajouter manuellement la signature, mais j’aimerais pouvoir le faire à partir de l’IBM i. Nous utilisons actuellement la version 5.4.

R. J’ai écrit un article sur ce sujet avec Gnu Pretty Good Privacy (GPG). L’article se trouve dans le club abonné, mois concerné. Vous pouvez aussi télécharger l’utilitaire nécessaire sur mon site web à www.scottklement.com/gnupg.

—Scott Klement

Travailler avec des fichiers physiques et logiques

Q. J’ai un fichier physique et un fichier logique dans Library 1. J’ai seulement le même fichier physique en Library 2. Je veux copier dans Library 2 le même fichier logique qui se trouve dans Library1, mais je n’ai pas le source DDS vers ces fichiers. Si je fais un CRTDUPOBJ du fichier logique de Library 1 à Library 2, je veux être certain que le nouveau fichier logique dans Library 2 pointe vers le fichier physique dans Library 2 et pas celui dans Library 1. La commande CRTDUPOBJ fonctionnera-t-elle ? Dois-je m’assurer que la liste de bibliothèques contient les deux bibliothèques (libraries) avant d’exécuter CRTDUPOBJ ?

R. CRTDUPOBJ sur un fichier logique n’utilise pas du tout la liste de bibliothèques. Mais CRTDUPOBJ suit des règles simples et directes. Si le fichier physique et le fichier logique de base sont dans la même bibliothèque et si le fichier physique existe dans la bibliothèque cible, le nouveau fichier logique sera basé sur le fichier physique cible. Dans tous les autres cas, le fichier logique dupliqué sera basé sur le fichier physique de la bibliothèque originale.

Créer un tampon horodateur pour FTP

Q. Dans pratiquement tous nos processus qui utilisent FTP, nous faisons OVRDBF du fichier  OUTPUT vers un membre source du fichier physique, pour journaliser ce qui se passe. C’est très utile, mais il manque quelque chose d’important : la date et l’heure de création du journal. Il est vraiment dommage que le client FTP n’ait pas une simple commande DATE qui renvoie la date et l’heure courantes à la sortie standard.
J’ai donc écrit un petit programme pour insérer la date, l’heure et l’utilisateur dans le journal. Dans la mesure où cela est appelé juste avant le processus FTP, tout se passe bien. Mais, pour généraliser cette méthode, il faudrait modifier une grande quantité de processus FTP.

J’aimerais pouvoir attacher mon programme horodateur à un programme de sortie, lui-même attaché au point de sortie du client FTP. Mais je me pose la question suivante : le OVRDBF sera-t-il encore respecté dans le programme de sortie ? 

R. Au lieu d’un programme de sortie, vous pourriez créer le fichier source physique pour la sortie d’erreur avec une longueur d’enregistrement de, par exemple, 150 caractères au lieu des 92 par défaut. Puis ajouter un déclencheur qui serait activé avant la mise à jour. C’est le programme déclencheur qui ajouterait un tampon horodateur à la fin du champ SRCDTA dans l’enregistrement.

—Peter Udesen