OK, here's a summary of the replies so far and my thoughts... phsiii replied (in part).... ------------------- > If the site says that the VMARC is from 9/1/2007 and you have a downloaded copy created 1/1/08, you don't need to worry (much) about whether you have the current version. and... > Or they could name it appropriately -- XYZ VMARC907
Reply: Depending on the site, that could be the date the VMARC file was uploaded there, right? Sometime the same VMARC file is loaded to different site at different times, perhaps an older release of the VMARC files loaded to a new site years later. Is XXX VMARC208 actually Feb 08, or December 08 with the leading 1 truncated from the 12? Don't __EVEN__ suggest VMARCC08 (12=C)... I'm trying to make things obvious for the VM newbie, not techie! :-) Tom posted... -------------- >Maybe the :TLR record could optionally include a checksum of the entire file. Reply: Good idea, but way more that I'm willing, capable of, or have time to do. Then again, anyone who has a business need for that idea has the source code, too. :-) "Scope creep". Rob suggested: ----------------- > You could build also VMARC file to contain just the VMARC file... Reply: Which would require VMARC to be modified to run VMARC again against the initial VMARC file, and then UNPACK it twice when someone downloaded it to their site. Lots more I/O for what could be a large file to begin with, right? And... wouldn't that introduce an incompatibility if someone downloaded a double-VMARCed file but only had the old VMARC MODULE? They'd have to manually VMARC it a second time, if they knew to do it. And if the downloaded file had some other error (perhaps silent truncation during download), the failure root cause becomes more involved. > I would like to see an index for the VMARC (to avoid sequentially scanning it to retrieve the individual FST's). Reply: Good idea, but way more that I'm willing, capable of, or have time to do. Then again, anyone who has a business need for that idea has the source code, too. :-) "Scope creep" - again. Kris wrote: >Yes, DMSPLU is nice for that (I sometimes do the same), but, as mentioned, once you download it, that date gets wiped out, and if you then upload to a VM system, using FTP or PCOMM, that date gets wiped out in its turn... Reply: Yep, all true, and the source of this RESTDATE operand inspiration. Everyone has DMSPLU MODULE Y2, so there's no need for modern plumbing or the SETDATE EXEC from the IBM VM Download page. A couple *small*, backward and forward compatible changes to VMARC and... everything needed to restore the FUBAR VMARC file date/time to that of the original VMARC'ers file is in one place. Now, barring further discussion... we'll see if I ever actually find time for what should be a pretty trivial assembler update. 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.