jmleonar@CRDEC-VAX2.ARPA (jle) (01/21/88)
Does anybody have code to create a card-image tape (preferably w/o
labels) under VMS? Is there a permutation of the init/mount/copy
command that would do the trick?
Thanks in advance,
Joe Leonard
<jmleonar@crdec.arpa>
Disclaimer: The views of my employer do not conform to my views, or to any
accepted standard of logic that the Greeks thought up anyway...
-------bcw@rti.UUCP (Bruce Wright) (02/05/88)
In article <8801202140.aa29268@CRDEC-VAX2.CRDEC-VAX2.ARPA>, jmleonar@CRDEC-VAX2.ARPA (jle) writes: > Does anybody have code to create a card-image tape (preferably w/o > labels) under VMS? Is there a permutation of the init/mount/copy > command that would do the trick? > I'm not sure if there is any permutation of init/mount/copy which will produce card-image tapes under VMS. Whenever I need to do that I have used a simple utility I wrote to do it (it is not at all difficult if you know any VMS programming language). It's been a long time since I've needed to do anything like that, but if anyone is interested I can post it (it's not real long but I will have to try to dig it up from tape heaven). Warning: It's in PL/I, so probably not many people can just compile it directly. I suspect that there is a way to do this with either MTU or MTEXCH from DECUS, but I've only ever needed to use those for IBM tapes ..... Bruce C. Wright
gil@icus.UUCP (Gil Kloepfer Jr.) (02/06/88)
In article <8801202140.aa29268@CRDEC-VAX2.CRDEC-VAX2.ARPA> jmleonar@CRDEC-VAX2.ARPA (jle) writes: >Does anybody have code to create a card-image tape (preferably w/o >labels) under VMS? Is there a permutation of the init/mount/copy >command that would do the trick? > > Thanks in advance, > > Joe Leonard > <jmleonar@crdec.arpa> Sure...here goes: First, create (using EDIT/FDL) a FDL file that is essentially a SEQuential file, FIXed length records, of 80 bytes each. Carriage control: none. Second, using a new tape, use MOUNT to mount it as a fixed length, 80 byte, unlabelled tape. The block size should be some multiple of 80, usually around 400 bytes/block is good for most systems (if it can handle more, by all means...). $ MOUNT tape_device:/RECORD=80/BLOCK=400/NOLABEL Third, use the CONVERT utility to place your file on tape. I think in some instances you can just COPY the file directly to "tape_device:" and it will work just fine, but CONVERT will always do it correctly. $ CONVERT/FDL=that_fdl_file_above your_file.ext tape_device: /PAD=" " The last qualifier pads the record with spaces (I think, if this is wrong for some reason, don't flame me...I'm on a UNIX machine doing this right now!). To pad the record with zeros, you can use /PAD="0". In any event, I think that CONVERT complains about short records if you don't do this with variable record files. Also note that trying this with files that have record sizes greater than 80 when the tape record size is 80 is something I haven't done! This is the best and most reliable way I've found to do it. This is also a nice way to get card image files FROM tape to disk. If you just copy the file, you end up with a file with no carriagecontrol. In the FDL file, you can specify CARR as the carriage control, and the card image file will be copied in an editable form. Be sure to change the CONVERT command so that the /PAD qualifier is left off, and the tape and file names are reversed (else you lose your data if a write ring is on the tape...oops). This should be of interest to many since card image files are the primary and most standard way of interchanging data on tape between computers of different architectures. +====================================+========================================+ | Gil Kloepfer, Jr. | Net-Address: | | Senior Programmer | {boulder,ihnp4,talcott}!icus!gil | | Bowne Management Systems, Inc. | Voice: Home: (516) 968-6860 | | 235 E. Jericho Turnpike | Office: (516) 248-6840 x796 | | Mineola, New York 11501 | Internet: gil@icus.UUCP | +====================================+========================================+ | Disclaimer: My employers know I'm right, but will never admit to it... | +=============================================================================+