Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!bingvaxu!sunybcs!rutgers!att!chinet!dwtamkin From: dwtamkin@chinet.chi.il.us (David W. Tamkin) Newsgroups: comp.sys.cbm Subject: Re: Can REL files be copied? Summary: yes, but very carefully Keywords: relative file copying Message-ID: <8190@chinet.chi.il.us> Date: 10 Apr 89 22:02:10 GMT References: <10180@ihlpb.ATT.COM> Reply-To: dwtamkin@chinet.chi.il.us (David W. Tamkin) Organization: Chinet - Public Access Unix Lines: 61 Michael Rios wrote in <10180@ihlpb.ATT.COM> in comp.sys.cbm: | Is there a way to copy REL files from one drive to another for archival and | backup purposes? Ideally, copying from a 1571 to a 1581 would be good. Most copy utilities will not touch relative files. I've seen a couple that will, and somewhere I have one for the 64 and any drive. Obviously, disk backup programs, which don't care how any sector relates to any other, would do the job but can't copy from a 1571 to a 1581 properly. One difficulty in copying relative files is that EOI (st=64) is sent at the end of every record. The only way to know when to stop reading is an error 50 (record not present) from the source disk. The other is that BASIC's INPUT#, GET#, and PRINT# commands respectively untalk, untalk, and unlisten the addressed device when they are done, and unlistening or untalking a disk drive with an open relative file bumps the record pointer to the start of the next higher record. One possible algorithm is this: read the block count and record length of the source file from its directory entry on the source disk. Allow for side sectors and take an estimate of how many records there are (empty as well as used). Try to position to that record in the source file, and if you get an error 50, try one record lower; if you get an ok from the drive, try one record higher. Keep going until you've had at least one 50 and one ok so that you have the proper count of records in the source file. Now, knowing the number of the highest record and the record length, open the target file, position to the highest record you're going to make, and write a CHR$(255); [with the semicolon from BASIC to suppress the CR or just without a CR from ML]. Then from record 1 on up to the highest one, read in a record and write it; read a record and write it, etc. Be careful to repeat position commands wherever advisable and to allow for the bumping to the start of the next record after INPUT#, GET#, and PRINT#. If you are doing this in BASIC, avoid INPUT# unless you are positive of exactly how many commas, colons, and carriage returns are inside each record, counting both data characters and field separators. GET# is safe but hard to use because you need a different variable name for each character in the record and have to run a long variable list in the GET# command. If you know the exact number of fields in every record and the fields are separated with commas, colons, or CR's (and never have any of those characters inside the fields), then you can use INPUT# with a variable list, one variable per field. If you are brave enough, you could even use the bumping of the record pointer as a way to get into position for the next record. You cannot use a loop to do the right number of GET#'s or INPUT#'s per record, because with each run through the loop, the disk drive will get untalked and move the record pointer to the start of the next record. For writing the target file, there is a similar problem: you have to assemble the whole record into a single string before doing the PRINT# or concatenate its parts with semicolons and use a single PRINT# command per record. It's probably best of all to use ML and to be careful of unlistening or untalking at risky times: at least in ML you can control it. But yes, relative files can be copied. The c: DOS command in dual drives (both from Commodore and from MSD) did it flawlessly. Now if only someone will produce a peripheral where drive 0 is a 1571 and drive 1 is a 1581, we'll all be thrilled. David W. Tamkin POB 567542 Norridge IL 60656-7542 | CIS: 73720,1570 dwtamkin@chinet.chi.il.us 5 Nisan 5749 | GEnie: D.W.TAMKIN Agreement with me cannot logically be imputed to anyone else who uses Chinet.