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.

L'ancienne option -noUI a été remplacée par quelques options fournissant une interface permettant de contrôler jSAVF en ligne de commande. Ces options permettent d'exécuter des commandes batch au travers d'une API limitée soit sur la ligne de commande soit au moyen de fichiers. Lorsque jSAVF est lancé en mode --console, il exécutera les expressions et/ou fichiers batch après avoir ouvert un SAVF si un était spécifié sur la ligne de commande. Lorsqu'aucun script n'est fourni, un script par défaut affiche le résultat de l'impression du SAVF décrivant les objets qu'il contient.

Pour l'instant l'API batch de jSAVF permet principalement d'ouvrir un SAVF, de le vérifier, et d'afficher son contenu, mais j'ajouterais d'autres moyens d'interagir avec le reste des fonctionnalités de jSAVF dans des versions futures.

La documentation de l'API batch de jSAVF batch API est inclue dans les archives ou installers en téléchargemet, avec un fichier batch démontrant ce qu'on peut faire avec.

Le langage de script sous-jascent est basé sur Apache JEXL et offre une syntaxe entre Java et JavaScript:

var savf = jsavf:openSaveFile("~/some.savf");
out.println(savf.displaySaveFile());
jsavf:exit(0);

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

Un utilisateur a signalé un problème lors de l'utilisation de jSAVF avec un message lié au chargement de la configuration de l'application. Il semble que la manière dont les fichiers de propriétés XML Java sont chargés a changée dans une version récente de la JRE, et depuis jSAVF n'était plus capable de charger sa configuration ou de démarrer.

Apres quelques recherches, le bug Java qui a été corrigé et reporté dans les versions LTS des JREs était probablement le suivant: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8214820.

Apparament la méthode Properties.loadFromXML() rejette maintenant des fichiers properties XML avec une DTD intégrée tels que :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties [
<!ELEMENT properties (comment?, entry*)>
<!ATTLIST properties version CDATA #FIXED "1.0">
<!ELEMENT comment (#PCDATA)>
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry key CDATA #REQUIRED>
]>
<properties>
...

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
...

J'ai donc converti la configuration vers l'ancien format de properties car ce format a moins de chance de subire une régression de la sorte, et aussi parceque la configuration n'avait pas vraiment besoin d'être conservée en XML.

J'ai aussi profité de cette occasion pour mettre à jour la version du JRE OpenJDK intégré dans l'installer Windows (v11.0.7+10), l'installeur NSIS lui même (v3.0.5), et quelques autres dépendences (slf4j, outils de build, ...).

Si vous découvrez un problème avec cette version n'hésitez pas à me le remonter.