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 and *HIGH).
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 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 requires a JRE v1.8 or above.
- 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.