Rich Greenberg <[EMAIL PROTECTED]> writes: > One possibility is that VMFPLC only understands 800 byte block > disks.
baiscally tape, vmfplc, and vmfplc2 put data on tape similarly; read the FST, write the FST to tape, open the file, modify the file characteristics to match the physical disk format ... file record reads and physical data blocks then are the same. processing the tape, read fst and save it, read physical blocks from tape and write them to disk file (the file records then may, or may not be the same as the physical disk records), when finished reading each cms file on tape, close the file being written to disk and zap the FST for the new disk file with the FST information read from disk. vmfplc2 was update to add misc. new function and also handle FSTs for both original filesystem (800 physical records) and EDF filesystem (1k, 2k, 4k physical records) ... but there were some FST format changes (and edf had filesystem call that avoided having to do some of the FST fiddling). old (ibm-main) posting about VMFPLC2 http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format in the above, the source code modification from vmfplc to vmfplc2 are identified as @V62B0H2. i've even heard of peopledoing REXX code to handle old format tapes ... getting image copy of several physical blocks from tape is frequently enuf to figure out what to do in the REXX code. -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
