Cette version ajoute un extracteur d'objets bytestream depuis les sauvegardes de l'IFS (*STMF), qui n'extrait que les données de ce type d'objets. L'extracteur n'effectue aucune conversion de CCSID car je ne suis pas sur que l'encodage des données dans ces objets soit conservé quelque part, et j'ai constaté du contenu binaire pour des fichiers Zip, de l'ASCII et de l'EBCDIC, donc il est préférable de conserver les octets tels qu'ils sont jusqu'à ce que je trouve un moyen fiable de déterminer leur encodage. Une foit extraites, si les données se trouvent être encodées en EBCDIC il est toujours possible de les convertir ultérieurement avec un programme comme iconv et la bonne page de code: iconv -f cp297 -t utf8 votre_stmf.txt > votre_stmf.utf8.txt

Cette version corrige également un bug mineur:

La taille des objets IFS de type bytestream était affichée sans l'arondir au KO le plus proche, donc les petits fichiers se retrouvaient la plupart du temps avec une taille de 0. Le surlignage de la taille affichait la taille correcte en octets, mais ceci pouvait induire des gens a penser qu'il n'y avait pas de donnée dedans. La table affiche maintenant une taille arondie au KO le plus proche, donc pour les bytestream de plus de 500 octets elle devrait afficher 1 au lieu de 0.

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

Cette version améliore l'extraction expérimentale de sources de programmes en ajoutant le support des programmes CLP, qui semblent inclure dans leur espace associé le même type d'informations source que celles présentes dans les vues de déboguage des programmes CLLE (probablement pour la commande RTVCLSRC), mais en plus le CCSID du source est présent ce qui est probablement plus fiable pour des sources avec des caractères non latins.

Cette version corrige également un bug:

La boite de dialogue A Propos affichait deux points d'interrogation rouge à la place du lien vers ce site car j'utilise pour ce lien la capacité de Swing à instancier des objets à partir de tags HTML (avec une syntaxe du style <object classid="...), et ceci est maintenant désactivé par défaut dans les versions récentes de Java. Je l'ai autorisé pour le moment en utilisant la propriété système Java swing.html.object, mais je réévaluerais ceci pour d'éventuels problèmes de sécurité plus tard.

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 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.

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.