(no subject)

>From davemck@xxxxxxxxxxxxx Tue Aug 17 13:01:46 2004
Subject: Re: [MI400] Analyzing save files from a PC -- revisited
From: Dave McKenzie <davemck@xxxxxxxxxxxxx>
To: MI Programming on the AS400 / iSeries <mi400@xxxxxxxxxxxx>
In-Reply-To: <41217227.8DAFC0E3@xxxxxxxxxxx>
References: <1915.216.115.228.126.1092699522.squirrel@xxxxxxxxxxxxxxxx>
         <1092701828.6967.96.camel@xxxxxxxxxxxxxxxxxxxxx>
         <41217227.8DAFC0E3@xxxxxxxxxxx>
Date: Tue, 17 Aug 2004 14:37:13 -0700
Message-Id: <1092772906.22342.22.camel@xxxxxxxxxxxxxxxxxxxxx>
Mime-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit

In the following, note that Unicode is 2 bytes per char: x00 followed by the 
char in ASCII.

SAV save files are more complicated than SAVLIB/SAVOBJ because of the
hierarchical directory structure, and other niceties like multiple hard
links and JAR files.

The 20 (x14) you saw is a byte that identifies the command used:
  01 savobj
  02 savlib
  03 savlib QFILE
  07 savcfg
  0A savsecdta
  0B savdlo
  11 savchgobj
  14 sav

The release level byte uses a different coding for SAV:
  xAB V4R4M0
  xAC V4R5M0
  xAD V5R1M0
  xAE V5R2M0
  xAF V5R3M0

The rest of the structure is different for SAV:
(The "Offset to" fields are from the "Save cmd" byte.)

Offset(hex)  Len (bytes)  Description
   0           1          Save cmd (see above)
   1           1          Release level (see above)
   2           2          Offset to HDR struct
   4           8          Timestamp

HDR struct:
   0           3          'HDR'
   3           2          # of offsets following
   5           5          Offset to DIR struct

DIR struct:
   0           3          'DIR'
   3           2          # of offsets following
   5           5          
   A           5          Offset to LNK struct
   F           5          Offset to directory path
  14           5          Offset to numObjects struct

directory path:
   0           4          Path length (bytes)
   4           n          Directory path (Unicode)

numObjects struct:
   0           4          Number of objects saved

LNK struct:
   0           3          'LNK'
   3           2          # of offsets following
   5           5          Offset to next LNK struct (0 if last)
   A           5          Offset to Name struct

Name struct:
   0           3          Language ID
   3           2          Country ID
   5           4          Name length (bytes)
   9           n          Object name (Unicode)

Getting the names of the objects saved in the directory is then a matter of 
walking along the chain of LNK structures (one LNK per object).

BTW, for viewing save files on iSeries, my SEESAVF utility can be
useful.  If has F11 to switch between EBCDIC chars and ASCII
chars for pathnames.  It's at:

 http://www.as400network.com/noderesources/code/clubtechcode/SeeSavF.zip

--Dave


On Mon, 2004-08-16 at 19:49, James H. H. Lampert wrote:
> Dave McKenzie wrote:
> > 
> > What specific info do you want to get?
> 
> Glad you asked. (I'm going to try and remember to bring in my notebook
> tomorrow, so I can look at a downloaded specimen in Norton.)
> 
> For starters, when I looked at what my existing save file analyzer was
> getting, it was finding 20 (decimal) at the same displacement where, on
> a SAVOBJ or SAVLIB *SAVF, it was finding 1 or 2, and it was getting
> garbage for the release level, object count, and library name.
> 
> What would be really nice would be if I could pick through the contents,
> and display the directory tree therein (as a Java Swing JTree, if you
> must know).