logoAnerty's Lair - News << Home
^ Software Documents

BugFix & Update: jSAVF 1.70

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.
jSAVF now offers a raw object export with and without unpacking to help debug this kind of issues, so if you're facing an incorrect export which seems to be related to an unpacker bug you can now send me a sample.

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.


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.


Update: jSAVF 1.60

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");

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


BugFix & Update: jSAVF 1.51

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)>
and will now only accept documents such as :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
despite the two DTDs describing the exact same constraints, and the elements actually respecting them.

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.


BugFix & Update: jSAVF 1.50

An user reported having some issues working with Japanese SAVF. The source extraction failed due to unsupported DBCS fields, and there were also some font issues with Japanese characters. I reproduced both issues with some free Japanese SAVF found on the net (thanks http://hrm.fixa.jp/free/freesoft.htm).

For this release I've improved the globalization support in jSAVF:

  • I've added the support of DBCS fields to the source extractor, so it can now export Japanese sources.
  • I've made a few things configurable:
    • The monospaced fonts used for the display of spools and text are now configurable, and show a preview of how well they're able to render a few international characters using the following string made of machine translations of the word "Left" in various languages: "Gauche Lénks Слева Αριστερά اليسار שמאלה Trái 剩下 左 ひだり レフト 왼쪽 बाएं ਖੱਬੇ ".
    • A new configuration tab is dedicated to text conversions, and now allows the user to override jSAVF's best guess of which Charset should be able to decode which CCSID. For CCSIDs which jSAVF couldn't find a matching Charset, when the JVM has a Charset which can decode a related CCSID this also allows the user to use that Charset to decode the otherwise unsupported CCSID. For example CCSID 5026 is unsupported by the JVM, but CCSID 930 is through Java Charset IBM930, so by adding an user conversion of CCSID 5026 with Charset IBM930 you can get most of the text to come out correctly in an export.
    • The default CCSID which is used whenever jSAVF doesn't know how to decode something (mostly things related to the job CCSID) can now be configured on that tab too, and can now use a CCSID which isn't supported by the JVM as long as there's an user conversion defining a Charset for it.

On the packaging side I've updated the OpenJDK bundled with the jSAVF Windows installer to a more recent version (v11.0.4+11), and I'm now building everything from Linux. I knew the Windows NSIS installer could be build with a makensis compiled on Linux, but I was pleasantly surprised to discover that jlink can build a modular OpenJDK image for Windows while running under Linux.

As always, if you encounter any trouble with this jSAVF version or cannot open a SAVF with it, don't hesitate to report it to me.