This version fixes a bug which prevented jSAVF from opening large SAVFs (more than a terabyte).

A component which allows jSAVF to check a block's checksum only once was limited to 2147483647 blocs, which is problematic when the SAVF contains more.

Given the memory cost of keeping this state for all blocks, I've disabled the cache for SAVF which have more blocs than this limit. This can reduce the performance a bit if you read the same bloc more than once, but it's unlikely on a SAVF this big. If this proves to be too detrimental to performance I'll think about using a more efficient data structure than the one currenlty used to hold this data, maybe an interval-tree could work there.

I've also updated the jSAVF dependencies and the embedded JRE bundled in the installable version for Windows. So jSAVF now needs a Java 18 version or better.

If you encounter any issue with this version don't hesitate to reach out to me.

This version fixes a few bugs in the way jSAVF implements the various unpacking algorithms needed to read the SAVF contents:

• The *LOW/SNA unpacking could in some cases produce too many bytes, which corrupted the extraction of SAVF embedded in other SAVF.
• The *MEDIMU/TERSE unpacking now handles many edge-cases in the way this algorithm dictionary behaves when full, which mostly happens on objects with high entropy such as programs or embedded SAVF, on which TERSE usualy gives negative compression ratios.
• The zlib unpacking which seems to be needed to open some SAVF since V7R5 is now supported.

This version offers a first shot at CSV export of database tables (members of non-source physical files). Most field types are handled except DECFLOAT which will probably come later. It's possible that some variants I have not tested may be incorrectly exported.

For now, I could export the following field types: NUMERIC, DECIMAL, TINYINT, SMALLINT, INTEGER, BIGINT, FLOAT, REAL, DOUBLE, DATE, TIME, TIMESTAMP, CHAR, BINARY, VARCHAR, VARBINARY, GRAPHIC, VARGRAPHIC, DBCS, CLOB, BLOB, DBCLOB

Given that the size and number of samples which I could find freely available on Internet is rather limited, it is probable that exporting large tables will be buggy (especially if they contain VARYING or LOB fields given the way these are stored when they do not fit their allocated space in the main record). More information can be obtained when enabling the debug/experimental mode in jSAVF preferences and restarting jSAVF.

I am considering making the CSV table export configurable to allow the selection of exported fields and their formatting, and to force their encoding.

This version also brings a first experimental shot at extracting *SOURCE or *LIST debug views which are included in some programs during compilation. This is available on objects of types *PGM, *MODULE and *SRVPGM when the debug/experimental mode is enabled at jSAVF startup.

For now the feature is quite basic, all debug views are exported together without further post-processing besides some unpacking when needed, so such exports may include the content of multiple source files or compilation spools.

If you encounter any issue with this version don't hesitate to reach out to me.

The old -noUI option has been replaced by a few options which provide a working command line interface to jSAVF, and exposes a limited API to batch commands which can be specified either on the command line or in files. When jSAVF is run in --console mode, it will now execute the provided batch files or expressions, after having open a SAVF if one was given as the last command line argument. When no script is provided, it will by run a default batch which display a spool of the objects within the SAVF.

At the moment the jSAVF Batch API mostly allows one to open a SAVF, verify it, and print the list of objects in it, but I'll be adding ways to interract with the rest of jSAVF in later versions.

The documentation for the jSAVF batch API is included in the downloadable archives and in the installer, with a batch file demonstrating what can be done with it.

The underlying script language is based on Apache JEXL and offers a syntax between Java and JavaScript:

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

If you encounter any issue with this version don't hesitate to reach out to me.

An user reported issues running jSAVF with messages related to the loading of the application config. It seems the way the Java XML properties files are loaded changed in one of the recent Java releases, and as a result jSAVF was no longer able to load its configuration or start.

After doing a bit of digging, the Java bug that was fixed and backported to the LTS JREs was probably the following: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8214820.

Apparently the Properties.loadFromXml() method now rejects XML properties with an embedded DTD such as :

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

So I've converted the config back to the old properties format is less likely to suffer such regressions in the future, and also because it didn't really need to be XML.

I've also taken this opportunity to update the OpenJDK JRE which is bundled in the Windows installer (v11.0.7+10), the NSIS installer itself (v3.0.5), plus some other dependencies (slf4j, some build tools...).

If you encounter any issue with this version don't hesitate to reach out to me.