Maybe the :TLR record could optionally include a checksum of the entire
file. I might not want to do that for every transaction I do to build a
VMARC file, but when I am finished and it is ready to transfer to
someplace else, I could see doing one last transaction to checksum the
file, put the data in the :TLR record and display the checksum for my
paper records.

/Tom Kern

Mike Walter wrote:
> 
> When one downloads a VMARC'ed package, the downloaded file (let's call
> it FUBAR VMARC in honor of the ongoing US financial "crisis") ends up
> with the date and time the FUBAR VMARC file was created on your VM
> system.   That makes it more difficult at a later date to download the
> same package and easily see if there are differences between the two
> files.  It wouldn't be too hard write a new EXEC to compare the VMARC
> LIST output from the two VMARC files, but it would be a tool required to
> check another tool (VMARC).  
> 
> Would it make sense to add new function to VMARC to provide capture of
> the date and time the FUBAR VMARC file was created (or last updated),
> and imbed that date and time within the VMARC file itself?  
> 
> With such a feature (perhaps via a new trailer record such as ":TLR" to
> complement the existing file ":CFF" header records), a new VMARC command
> (maybe called "RESTDATE"?) could be used to both confirm that the whole
> file had been downloaded (since the ":TLR" record would always be the
> last record) and be able to use DMSPLU to RESTore the DATE and time to
> that which had been saved in the ":TLR" record.
> 
> "RESTDATE" is just an example operand keyword - better suggestions would
> be most welcome.
> 
> Obviously, RESTDATE (or whatever) would have to be backward compatible
> -- just reporting something like: No ":TLR" record present; the file was
> created before yyyymmdd, or the file was truncated during download.  
> (Where yyyymmdd was the date and time that the new support was added).
> 
> Mike Walter
> Hewitt Associates
> Any opinions expressed herein are mine alone and do not necessarily
> represent the opinions or policies of Hewitt Associates.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately
> alert the sender by reply e-mail and then delete this message, including
> any attachments. Any dissemination, distribution or other use of the
> contents of this message by anyone other than the intended recipient is
> strictly prohibited. All messages sent to and from this e-mail address
> may be monitored as permitted by applicable law and regulations to
> ensure compliance with our internal policies and to protect our
> business. E-mails are not secure and cannot be guaranteed to be error
> free as they can be intercepted, amended, lost or destroyed, or contain
> viruses. You are deemed to have accepted these risks if you communicate
> with us by e-mail.
> 

Reply via email to