jSAVF v1.82

jSAVF enables you to consult the contents and check the integrity of an IBM iSeries (AS/400) SAVF save file on a workstation with a recent Java runtime environment. No connection to an iSeries is needed.

jSAVF can open a save file (SAVF, ISO9660 or AWSTAPE magnetic tape image) with the menu or a drag-and-drop. Once a save file 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 is 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 data in objects of type *STMF in IFS save files can be exported without conversion.
• 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.
  For files whose field CCSID doesn't match the field contents (corrupted accents or special characters), it's possible to force the use of the default CCSID configured in the file/preferences dialog to ensure jSAVF reads the source data correctly. Source files are always exported as UTF-8 by jSAVF.
• 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.
  • Tables with large values in CLOB or BLOB fields will possible not be exportable completely. BLOB field values are exported as hexadecimal strings.
  • 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, and the source of some CLP programs which include them.
• 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.

Prerequisites

• 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 21 or above, its Windows 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.

Limits

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

If you find issues in jSAVF you can reach out to me to solve them, but please don't send me any save file without clearing it first with the system owners and stakeholders for confidentiality and security reasons. Also please don't send me any save file without discussing it with me first.

Screenshots:        

Latest news: [ v1.82 ]  [ v1.81 ]  [ v1.80 ]  [ v1.72 ]  [ v1.71 ]  [ v1.70 ]  [ v1.60 ]  [ v1.51 ]  [ v1.50 ]  [ v1.40 ]  [ v1.32 ]  [ v1.31 ]  [ v1.30 ] 

Downloads: [ jSAVF (1 MiB, Linux JARs only)SHA1 (2D524F817C9AD417AEAA32A6C426A9CD70B03CDE)  ] [ jSAVF (1 MiB, Windows JARs only)SHA1 (AA345EEFB324DADD066E36682CEA47F996328A4F)  ] [ jSAVF (32 MiB, Windows Installer, includes OpenJDK 21.0.1+12 x64)SHA1 (0368FC5317E7B5252A3172191E83C54A1D44F4EA)  ]