jSAVF can open a SAVF file with the menu or a drag-and-drop. Once a SAVF is open, the objects are listed in a format similar to the one provided by the DSPSAVF command. You can export this list to a text file using the Print menu in a format like the one provided by the DSPSAVF *PRINT command. You can order the displayed objects by one or more criteria using the list headers and search them by name.
The SAVF file format analysis has been done with a good hex editor and some info found in the archive.midrange.com forum (particularly the two IBM proprietary checksum algotithms). jSAVF supports either uncompressed SAVFs (*NO), those compressed with the old compression method (*YES before V5R3, *LOW since then), and those compressed with the more recent methods (*MEDIUM, *HIGH, or zlib which seems to have appeared since V7R5).
The internal structure of some object types has been analysed so they can either be displayed in jSAVF as text spools, or exported as files.
- The objects of type *DTAARA (data areas) of all types (*CHAR, *DEC, *LGL) can be displayed or exported as text as the DSPDTAARA command would, or more concisely as the RTVDTAARA command would.
- The objects of type *FILE with SAVF attribute (SAVF files) included within a SAVF can be exported as valid SAVF files, which can in turn be opened by jSAVF.
- The source members of objects of type *FILE with PF attribute (source physical files such as QCBLLESRC, QCLLESRC, QCLESRC, QRPGLESRC, QSQLLESRC,
...) can be exported as text, source or CSV format:
- The source format exports the SRCSEQ, SRCDAT and SRCDTA fields separated by one space, without truncating trailing whitespace.
- The CSV format exports these three fields surrounded by double quotes, separated by commas, without trailing whitespace, and escapes any double quote inside a field by doubling it.
- The text format only exports the SRCDTA field without trailing whitespace.
- The contents of database tables or non-source physical file members are exportable as CSV:
- Fields of the following types are supported: NUMERIC, DECIMAL, TINYINT, SMALLINT, INTEGER, BIGINT, FLOAT, REAL, DOUBLE, DATE, TIME, TIMESTAMP, CHAR, BINARY, VARCHAR, VARBINARY, GRAPHIC, VARGRAPHIC, DBCS, CLOB, BLOB, DBCLOB, ROWID
- NULL field values are exported without double quotes surrounding them.
- Depending on the format, it is possible that some text fields are incorrectly decoded when jSAVF can't figure out their encoding.
- Large tables with either VARYING or LOB fields will probably not be exportable completely.
- ROWID fields won't be exported correctly unless they're defined with REFSHIFT(H).
- Experimentally, the contents of *SOURCE or *LIST debug views included in some objects of type *PGM, *MODULE, *SRVPGM during compilation.
- The analysis of the other types is ongoing, meanwhile the raw objects and members can be exported.
The integrity checks performed by jSAVF are:
- The file size is validated against the SAVF header information, to ensure it is not truncated.
- The blocks read by jSAVF are checked against the block checksums in the SAVF. jSAVF will therefore control the integrity of part of the SAVF during its indexing, and will also control the blocs required to display or export the objects you chose to display or export.
- There is also a menu allowing you to verify the integrity of all SAVF blocs at once, and the global file checksum.
- The data conversions between EBCDIC and Unicode require some Java codepages which are optional in some JRE versions. If you install a JRE, ensure you check every install option, otherwise some SAVF might not be readable.
- jSAVF needs OpenJDK 18 or above, its installer includes a minimal modular image of it. If you are on Linux or already have one somewhere you can download the smaller jSAVF archive instead of the installer to save bandwidth.
- jSAVF has limited support of SAVF generated on the IFS filesystem (SAV command)
- jSAVF can sometimes fail to read SAVF generated either with exotic SAV* commands or by very old OS/400 releases.