Re: [MI400] (no subject)

[Dave McKenzie <davemck@xxxxxxxxxxxxx>]

I think the records are still 528 bytes long with the data in the records
being compressed.  However the field at offset xCC in the descriptors refers
to the number of *uncompressed* records to the next descriptor.  So I think
you'll have to uncompress the records to find the next descriptor.

The compression is done by the MI "Convert Character to SNA" instruction
(strangely enough).  The description is available at:

  http://www.as400.ibm.com/tstudio/tech_ref/mi/CVTCS.htm

which contains a description of the compression algorithm.  It's simple run
length encoding where strings of duplicate characters are represented by a
length byte and 1 byte of the duplicate character.  Non-duplicate strings are
left as they are.

I did a SAVLIB DTACPR(*YES) (on V5R1) and it appears the first descriptor
(for the library) and the records after it are uncompressed.  Starting with
the second descriptor (record 25) the descriptors are uncompressed but the
records after them are compressed.  In each compressed 528-byte record, the
first 512 bytes are filled with compressed data, and the last 16 bytes
(4-byte RRN and 12-byte checksum) are left uncompressed.

BTW, in record 17 at offset x132 the leftmost bit indicates whether the save
file is compressed.

--Dave


On Friday 01 February 2002 07:11 am, arnaud wrote:
> C'est un message de format MIME en plusieurs parties.
> --
> [ Picked text/plain from multipart/alternative ]
> i'm creating a pc program able to read save files.
> In no compressed save files , i use an information at offset xCC in
> descriptors to find the next descriptor.(this number multiply 528 bytes)
> I've problems with compressed save files.records are not 528 bytes length.
> So How could i find the next descriptor?
>
> Thank you very much.
>
> PS : I apologize for my english.
>
> --