mknox@NGP.UTEXAS.EDU (Margaret H. Knox) (11/26/87)
Does this sound familiar? An application program has a large random file it creates at the beginning. Various entries are filled, but by no means all. The person in question says he used to be able to copy the files from one floppy to another using PIP with no problem. Now he has a hard disk and when he copies the random file from floppy to the hard disk (important note: NOT the same random file as he used to copy between floppies), PIP "shrinks" the file, and the application program throws up all over it. I remember some years ago a problem with using PIP to copy random files, but just added a "random copy" into my application program and forgot about it. Any solutions based on the limited info available? Any PD copy program that would NOT have this problem? tnx
XBQ@PSUVM.BITNET (Ed Winograd) (11/30/87)
The problem may be that PIP is interpreting the file as a TEXT file, and is
truncating it at the first CTRL-Z (ASCII #26) character that it finds.
Try the following version of the PIP command -- it should probably solve the
problem:
PIP destfile=sourcefile[O]
The "O" parameter tells PIP that the file being copied is a binary file,
and tells it to copy the ENTIRE file, even if it finds a CTRL-Z in it, which
would mean "END-OF-FILE" for a text file. You'll still have to include
any "G" paraemter that is necessary for copying from one user area on the
floppy to a different user area on the hard disk.
bridger%rcc@RAND-UNIX.ARPA (Bridger Mitchell) (11/30/87)
Copying randomly-written sparse CP/M files is considerably more involved than the sequential read/sequential write operation used by PIP and nearly every other file copy utility; it is especially tricky when the source and destination have different logical block sizes. When I wrote DATSWEEP for DateStamper I queried the list about interest in adding that capability; no one expressed interest. I know know of no general-purpose utility that can do it correctly. Your best bet is probably to use the database program that created the sparse file to copy it; I expect that all such programs contain an internal copy command that will work (e.g. for dbase II, "copy to <drive>"). --bridger mitchell
shaprkg@sdcrdcf.UUCP (Bob Shapiro) (12/01/87)
In article <8711261736.AA12340@ngp.utexas.edu> mknox@NGP.UTEXAS.EDU (Margaret H. Knox) writes:
<
<Does this sound familiar? An application program has a large random
<file it creates at the beginning. Various entries are filled, but by
<no means all. The person in question says he used to be able to
<copy the files from one floppy to another using PIP with no problem.
<Now he has a hard disk and when he copies the random file from floppy
<to the hard disk (important note: NOT the same random file as he used
<to copy between floppies), PIP "shrinks" the file, and the application
<program throws up all over it.
<
<I remember some years ago a problem with using PIP to copy random files,
<but just added a "random copy" into my application program and forgot
<about it. Any solutions based on the limited info available? Any
<PD copy program that would NOT have this problem?
<
< tnx
I am a little confused. There was a problem in PIP eons ago where it had
to be told that it was copying a binary file or it quit on a control Z but
this has been solved a long time ago. All versions of PIP in the last many
years copy all files as if they are binary so you do not need the [o]
option. HOWEVER there is a case where PIP still needs the option. It is
when it copies to AXO or LST. In this case PIP assumes the file is not
binary and quits on a control Z. If you want it not to then you must use
the "o" option. (BTW input from AXI is always non-binary as there is no way
for AXI to signal EOF except for control Z.)
One other possibility is that your copy program may have been written in
C. There are some compilers in the CPM world which have a problem with
binary versus non-bianry files. They have to know where the EOF mark is
and whether to translate CRLF to LF (and vice versa). So one solution used
is to have 2 fopen functions. e.g. The Digital Research compiler has 3 open
functions - fopen, fopena, fopenb. fopen and fopena are the same and open the
file for ASCII and fopenb opens the file for binary. All other functions
then take their cue from the fopen function. Thus a copy program written
under UNIX may appear to compile correctly but in fact may not work right.
Bob Shapiromarria@navajo.UUCP (Michael Marria) (12/25/87)
Primary questions here are, if you have heard of the Visual 1050 desktop computer, is it (reportedly) KAPRO compatible? One is affecting my life through my sister who aquired one, and thus far I have managed to figure out that it will talk via telenet as an "ansi" terminal on the UNIX machines. Furthermore, I have seen the supplied software includes a CPM base and Wordstar plus a few other kwown programs. The innards include a 6502 (co)processor(?) some NEC chips, two single(?) sided 96 TPI drives etc. Any help out there? I would like to grant my sis the proper termcap, an ansi sys and amongst other things, an executable for Hack, and direction towards the preferable OS whether it be xx-DOS or stick with CPM. The supplied terminal emulator called tty1050 (which I am using to compose this) seems to only be capable of ASCII file transfers via a trap method. Is there anything else available for this machine? Any responses to the effect that this boat anchor could be replaced with a (pick your favorite clone) should be directed to /dev/null. Any real help with this problem will be graciously appreciated. Thank you, Michael R.Marria