Un utilisateur souhaitait ouvrir un volumineux fichier image d'une bande magnetique contenant plusieurs sauvegardes avec jSAVF, donc j'ai effectué quelques changements pour le permettre. Ca m'a aussi permis d'ajouter un support limité des fichiers images de disques optiques (ISO9660 uniquement pour l'instant, pas d'UDF) vu que ceux-ci peuvent aussi contenir plusieurs sauvegardes.

L'outil d'acquisition de bande magnétique qu'il a utilisé produit un fichier au format AWSTAPE (cf. Description, Emulateur Hercules-390), qui insère une entête de 6 octets avant chaque block de la bande magnétique.

Ce format n'est pas idéal vu qu'il décrit la taille du segment précédent et suivant sur des mots de 16bit, alors que les bandes magnétiques modernes semblent avoir des blocks de 256KO ou plus. Ceci produit des débordements, donc par exemple un block dont la taille est décrite par 0xF000 dans l'entête de block peut vouloir dire soit 0x0F000, 0x1F000, 0x2F000 ou 0x3F000 pour une bande avec des blocs de taille 0x40000 (256KO) décrits dans le libellé de bande ANSI X3.27-1978 correspondant au fichier.

jSAVF contourne le problème en cherchant aux différents déplacements une entête de block AWSTAPE valide et décrivant une taille de block précédent égale à celle du block courrant modulo 65536. En cas de malchance il peut arriver que de la donnée du block à un de ces déplacements ressemble à l'entête recherchée, donc dans le cas ou jSAVF trouve plus d'une entête suivante possible la lecture s'interrompra avec une erreur. Si vous vous retrouvez dans ce cas je pourrais peut-être améliorer cette recherche en considérant le block suivant, mais vu que pour le moment ceci semble suffisant je n'ajouterais pas de complexité en plus sauf si quelqu'un n'arrive pas a ouvrir une bande magnétique sans.

Vu que parcourir l'ensemble des entêtes alternatives d'une bande de plusieurs giga-octets pour trouver toutes les sauvegardes présentes dedans peut prendre un temps certain, jSAVF va générer un fichier d'index nommé "xxx.jsavf_awstape_index.bin" à côté d'un fichier image de bande magnétique nommé "xxx" si ce parcours prend plus de 3s. L'index contient les libellés de bande pour chaque fichier, ainsi que des tables décrivant la position des entêtes de block afin de pouvoir rapidement convertir une position dans une des sauvegardes en une position dans le fichier image de bande magnétique. Ceci permet a jSAVF d'ouvrir le fichier quasi instantanément la prochaine fois, et ne nécessite que peu de place (~1MO d'index pour une bande de ~30GO).

Lorsqu'il y a plusieurs sauvegardes dans un fichier, jSAVF va maintenant demander à l'utilisateur d'en sélectionner un à ouvrir. Pour les scripts batch ceci est géré en utilisant une nouvelle API jsavf:openMultiSaveFile(path, selector) qui applèle une fonction selector fournie par l'utilisateur avec la liste des sauvegardes trouvées dans la bande magnétique ou le disque optique, et s'attend en retour a recevoir le fichier à ouvrir. Ceci permet à un script de sélectionner une sauvegarde par sa taille, son nom ou son numéro d'ordre. La dépendence JEXL a été mise à jour en v3.3 pour rendre ceci possible, donc si vous rencontrez des incompatibilités dans vos scripts merci de m'en informer pour que je vois si c'est quelque chose que je peux corriger. J'ai ajouté quelques classes à l'API batch pour permettre de convertir du texte en int ou long, et décrit ceci dans la documentation de l'API.

Cette version corrige aussi deux bugs:

• Certaines extractions n'arrivaient pas à déterminer la structure d'un élément sauvegardé à cause d'une erreur dans la manière dont jSAVF calculait la position de la première section lorsque l'entête faisait exactement 4096 octets.
• Certaines extractions CSV avec des champs CHAR VARYING, CLOB ou BLOB ne pouvaient pas être réalisées lorsque la quantité totale de données dans ces champs dépassait une certaine taille, ce qui se produit avec des tables ayant beaucoup d'enregistrements ou avec assez de donnée dedans. jSAVF arrive maintenant a extraire ce type de tables mais peut encore avoir des difficultés si la longueur des valeurs dans les champs CLOB ou BLOB est très grande. N'hésitez pas à me contacter si vous êtes confrontés à un problème de ce type.

L'extraction CSV des champs de type BLOB a été modifiée pour extraire leurs valeurs sous forme de chaine hexadécimale, en effet écrire du binaire brut dans un CSV encodé en UTF-8 n'était pas très exploitable.

J'ai aussi mis à jour les dépendences de jSAVF ainsi que la version du JRE embarqué pour la version installable pour Windows. jSAVF nécessite donc maintenant une version Java 21 ou plus récente.

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.

Cette version corrige un bug qui empêchait jSAVF d'ouvrir des SAVFs avec des fichiers ayant un attribut particulier.

Le bug se produisait dans certains cas lors de l'analyse de fichiers avec un attribut BASED ON, ce qui est dommage car ceci n'est actuellement affiché nulle part.

J'ai aussi mis à jour les dépendences de jSAVF ainsi que la version du JRE embarqué pour la version installable pour Windows. jSAVF nécessite donc maintenant une version Java 19 ou plus récente.

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.

Cette version corrige un bug qui empêchait jSAVF d'ouvrir de grand SAVFs (plus d'un téra-octets).

Un composant qui permet à jSAVF d'éviter de vérifier plusierus fois le checksum d'un même bloc était limité à 2147483647 blocs, ce qui pose problème lorsque le SAVF en contient davantage.

Vu le coût mémoire de conserver cet état de vérification, j'ai désactivé le cache pour les SAVF dépassant cette limite. Ceci peut légèrement dégrader les performances si vous lisez plusieurs fois le même bloc, mais c'est peu probable sur un SAVF de cette taille. Si c'est pénalisant je réfléchirais à une structure de donnée plus efficace que celle utilisée actuellement pour conserver ces données, peut être qu'un interval-tree ferait l'affaire.

J'ai aussi mis à jour les dépendences de jSAVF ainsi que la version du JRE embarqué pour la version installable pour Windows. jSAVF nécessite donc maintenant une version Java 18 ou plus récente.

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.

Cette version corrige un certain nombre de bugs dans la manière dont jSAVF implémente les différents algorithmes de décompression nécessaires pour lire le contenu des SAVF:

• La décompression *LOW/SNA pouvait dans certains cas produire plus de données que prévu ce qui corrompait l'extraction de fichiers SAVF inclus dans d'autres SAVF.
• La décompression *MEDIMU/TERSE gère maintenant beaucoup plus de cas exotiques dans la manière dont le dictionnaire de cet algorithme semble se comporter une fois plein, qui se produisent majoritairement en présence d'objets à forte entropie tels que des programmes, des fichiers SAVF inclus, sur lesquels TERSE donne un taux de compression négatif.
• La décompression zlib qui semble nécessaire pour lire les fichiers SAVF à partir de la V7R5 est maintenant supportée.

Cette version apporte une première mouture d'un export CSV pour les tables de base de données (membres de fichiers physiques non-source). La plupart des types de champs sont gérés sauf DECFLOAT qui viendra éventuellement plus tard. Il est cependant possible que certaines variantes que je n'ai pas pu tester ne soient pas exportées correctement.

Pour le moment j'ai pu tester les types de champs suivants: NUMERIC, DECIMAL, TINYINT, SMALLINT, INTEGER, BIGINT, FLOAT, REAL, DOUBLE, DATE, TIME, TIMESTAMP, CHAR, BINARY, VARCHAR, VARBINARY, GRAPHIC, VARGRAPHIC, DBCS, CLOB, BLOB, DBCLOB

Le volume des échantillons que j'ai pu trouver en libre accès sur Internet étant assez limité, il est probable que l'export de grosses tables pose des problèmes (en particulier si celles-ci contiennent des champs VARYING ou LOB vu la manière dont ceux-ci sont stockés lorsqu'ils ne tiennent pas dans l'espace qui leur est alloué dans l'enregistrement principal). En cas de problème il est possible d'obtenir plus d'information en activant le mode debug/expérimental dans les préférences et en redémarrant jSAVF.

J'envisage par la suite de rendre l'export CSV des tables configurable pour choisir les champs et leur formattage, ainsi que permettre de forcer leur encodage.

Cette version ajoute aussi une première version expérimentale de l'extraction du contenu des vues de débogage *SOURCE ou *LIST inclues dans certains programmes à la compilation. Ceci est disponible sur les objets de type *PGM, *MODULE et *SRVPGM lorsque le mode debug/expérimental est activé au démarrage de jSAVF.

Pour le moment c'est assez basique, l'ensemble des vues sont exportées ensembles sans autre traitement qu'une éventuelle décompression si nécessaire, donc les sources peuvent représenter le contenu de plusieurs spools ou fichiers sources.

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.