The following message is a courtesy copy of an article that has been posted to alt.folklore.computers,bit.listserv.vmesa-l as well.
Anne & Lynn Wheeler <[EMAIL PROTECTED]> writes: > search engine even turns up one of my old pasts mentioning VOL1 and > HDR1: > http://www.garlic.com/~lynn/2004q.html#20 Systems software versus > applications software definitions > > which discusses an old backup/archive system that i had written for > internal use ... which then went thru several iterations and > eventually released as workstation datasave facility, morphed into > adsm and is now known as tsm > http://www.garlic.com/~lynn/subtopic.html#backup re: http://www.garlic.com/~lynn/2006t.html#20 Why these original FORTRAN quirks?; Now : Programming practices old email from the other person working on CMSBACK version 2. this is on enhancing the pattern matching capability in the user interface file retrieval process (from the backup/archive repository). as noted in the above reference, Melinda's history starts with what would be CMSBACK version 3 (or possibly 4 ... depending on how you classify all the work done between the initial CMSBACK deployment and assignment of the people mentioned in Medlinda's history). To: wheeler Date; 10/25/79 02:11:58 I had to make one change to OSPATM to make it work. The macro SREGS is a bit too much for me tonite so I replaced the one to set up addressability to the work area using R5 with the L R5,8(,R1) and USING PATSPC,R5. AND...... it works like a super star!!!! Try issuing the CMSBACK exec, ask for a report, and enter whatever patterns you like.. Disk load the returned RPT file and see what you get.. I've been playing with it now for a while and it really works great. (I will make the matching available on date and time tommorrow.. why stop with just the filename and filetype). ... snip ... for the original low-level CMSBACK interface to tape, I used a highly modified version of VMFPLC (mentioned in the old email below) that I had renamed VMXPLC. Not mentioned in the below ... but it was also enhanced to provide optimal processing for the paged mapped filesystem implementation that I had done http://www.garlic.com/~lynn/subtopic.html#mmap start of buffers were page aligned ... and 15 800 byte data blocks could be three 4096 byte blocks. For small files, the minimum size data block on tape could be 800 bytes. With separate FST record and data block, a tape with a lot of small files would have half (or more) of the length could be taken up with interrecord gaps. Merging the FST record and the first data record into the same physical tape record, would cut the tape devoted to interrecord gaps in half (when lots of small files was involved). From: wheeler Date: 03/21/80 13:41:39 To: somebody in endicott The original VMFPLC was an update to release 2 DMSTPE. The code took the FST record which is placed in a trailing 800 byte record following the file dumped and placed it in a 59 byte record in front of the file dumped. It also blocked up to 5 800 byte data blocks per physical tape block. I captured the update early and maintained it (I heard that the development lost it and didn't have a copy) against the current release & plc level. I also enhanced the update to block up to 15 800 byte data blocks, to merge the FST record into the 1st physical data block dumped and to avoid rewriting the MFD after each file loaded. VMFPLC2 appears to have several new features which would indicate that it is not a modification of the original VMFPLC (since as far as I know, I'm the only one with the source) but it still maintains the original tape format. I must confess that I've not looked at the new release 6/bsepp tape source (although I've heard that it has grown substantially and has been split into several files). ... snip ... and for an even earlier CMSBACK related email. standard CMS could "share" various filesystem areas across multiple virtual machines. However, the filesystem status information would be duplicated in every virtual address space. A hack was done to place a copy of some shared CMS filesystem information in shared (r/o protected) memory ... so there only need to be a single physical copy of the filesystem metadata (shared across everybody). The "problem" for DMSDSK, DMSTPE, VMFPLC and VMXPLC was that there was a hack where they temporarily modified the file metadata that forced the logical record size to match the physical disk record ... and then restore it when they were done. This hack would fail if the file metadata information was located in shared (r/o protected) memory. From: wheeler Date: 04/02/79 19:22:35 Yorktown has done an update for DMSDSK (DISK DUMP) to handle the problem of dumping from a disk with FST in shared memory (DMSDSK YK187DMS). Can you merge with what you have been doing to DMSTPE for TAPE, VMFPLC, & VMXPLC?????? ... snip ...
