Re: Save file to tape

[CRPence <CRPbottle@xxxxxxxxx>]

  I think more accurate information than displaying the *SAVRST 
data [e.g. number of objects, object names & types], would be 
displaying the "Current number of records" for the file; see DSPFD 
output.

  The save file is the combination of the external object type 
*FILE and the internal object type *DMPSPC.  Either of those objects 
might account for a difference in size, even changes that do not 
affect the actual data within the file.dumpspace that was created as 
part of the restore, into which the data was then loaded.  If both 
files still exist to enable the DSPSAVF & DSPFD, then a comparison 
of the "SIZE" recorded for each of the objects presented for both of 
the DMPOBJ output spool files would enable revealing which object 
was the source of the size difference.

  If the size difference is due to truncation of the object [e.g. 
actual or effective partial damage], then a reduced number of rows 
may be reflected, but DSPSAVF probably will *not* expose any 
truncation because the object mimics sequential media, where the 
details of the save are unlikely to be part of whatever might be 
truncated [data follows details].  If the new dump space is smaller, 
then that is not a problem if all of the records actually exist.  If 
a restore is attempted from the save file, and the restored save 
file had been truncated, the restore will likely fail or leave 
partially restored objects that are or should become marked damaged 
when the partially restored objects are then accessed.

Regards, Chuck

John Earl wrote:
> Has anyone ever heard of a restored save file being of a
> different size than the original save file that was saved?
>
> We have a situation where we wrote a save file with 5300+ objects
> in it to tape, then later restored the save file and to the same
> system and found that the size of the restored file was about
> 190K smaller than the the original save file.
>
> A DSPSAVF indicates that the same number of objects are in the
> save file, and there is no obvious loss of data.  The next step
> is to do a object by object inspection, but before I go down that
> road I was wondering if there might be a simple explanation that
> I am just not aware of.