EVERHART%ARISIA.DECnet@GE-CRD.ARPA (02/16/88)
The source code for ARC 5.12 has been available for months via PD channels for MSDOS. While I haven't seen the source for version 5.20 (the latest SEA Arc), the earlier sources are certainly available and would be OK to send over the net. They are however fairly lengthy. I only got part 2 of the .exe posting though; anyone have part 1 they can send? Glenn Everhart Everhart%Arisia.decnet@crd.ge.com
EVERHART%ARISIA.DECnet@GE-CRD.ARPA (02/20/88)
I finally received (thanks!) the ARC part 1 of the vms ARC posting. I now have tried it... ARC does work on files created as archives either BY ARC, or by other transfer methods that store the files on disk as bitstreams or their equivalents. For example, XMODEMs typically use fixed 128 byte records in downloads. It (arc) fails badly on archives created by Kermit in binary mode (even though sweep has no problems with them and both msdos and Amiga ARC like 'em fine when transferred to those machines.) I believe ARC must be ignoring the fact that on variable length records (used by Kermit in binary files) there are two bytes of record length before each record. Accordingly, the file must be read by RECORDS, not by BLOCKS, to give the correct effect. Can anyone shed more light on the situation? I suppose one can try using vms kermit FILE TYPE FIXED to work around the problem, though there used to be a problem where the last record was less than 512 bytes which has led me not to use fixed filetypes much. Is the fix straightforward in C? Glenn Everhart Everhart%Arisia.decnet@crd.ge.com
scjones@sdrc.UUCP (Larry Jones) (02/21/88)
In article <8802202329.AA24174@ucbvax.Berkeley.EDU>, EVERHART%ARISIA.DECnet@GE-CRD.ARPA writes: > > The source code for ARC 5.12 has been available for months via > PD channels for MSDOS. While I haven't seen the source for version > 5.20 (the latest SEA Arc), the earlier sources are certainly > available and would be OK to send over the net. They are however > fairly lengthy. When I talked to SEA and mentioned getting source for 5.12 from a PD channel, they were quite surprised. They're official policy (as explained to me) is that source is NOT available except directly from them. Whether there will be restrictions on the VMS version sources I can't say yet. > I only got part 2 of the .exe posting though; anyone > have part 1 they can send? If you can't find it from someone closer, send me mail and I'll send it to you. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
scjones@sdrc.UUCP (Larry Jones) (03/04/88)
In article <8802250714.AA18420@ucbvax.Berkeley.EDU>, EVERHART%ARISIA.DECnet@GE-CRD.ARPA writes: > > I finally received (thanks!) the ARC part 1 of the vms ARC posting. > I now have tried it... > ARC does work on files created as archives either BY ARC, > or by other transfer methods that store the files on disk as bitstreams > or their equivalents. For example, XMODEMs typically use fixed > 128 byte records in downloads. It (arc) fails badly on archives > created by Kermit in binary mode (even though sweep has no problems > with them and both msdos and Amiga ARC like 'em fine when transferred > to those machines.) I believe ARC must be ignoring the fact that > on variable length records (used by Kermit in binary files) there > are two bytes of record length before each record. Accordingly, > the file must be read by RECORDS, not by BLOCKS, to give the > correct effect. > Can anyone shed more light on the situation? Well, as the "author" of the VMS version, I suppose I can. You are correct that ARC is using block access to the archive and thus variable length records are not processed correctly. This is necessitated by the way ARC manipulates the file - it is necessary to seek forward and backward to arbitrary positions within the file and this is not possible with variable length records. > I suppose one can try using vms kermit FILE TYPE FIXED to > work around the problem, though there used to be a problem where > the last record was less than 512 bytes which has led me not to > use fixed filetypes much. Bingo! Apparently you did not get the (meager) documentation that I sent out since this was mentioned explicitly as a way to transfer archives in it. I don't know which version you have (or even off hand which version I have), but it works without any problems for me. > Is the fix straightforward in C? as I said above, the fix is nigh-on impossible. Use fixed length records. ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
ac02@NTSUVAX.BITNET (03/28/88)
This is the third time I have sent this letter. I never saw it posted.
A while back I saw a message from a guy that said he had a copy of ARC
for the VAX. Info-VAX stopped working correctly on BITNET since then
though I believe the problem is fixed now. I may have miss the whole
program or something. A friend of mine has tried to reach the person
that sent out the message mentioned above without any luck. I need
a copy of ARC for the VAX badly. I have VMSSWEEP which will read ARCed
files, but I need something that will write them.
For those of you who don't about ARC, it is a MS-DOS program that
creates an archive file whichs contains other files in compressed
format. It is similiar to a BACKUP save set with two major
differences. The first is the ARC file is small than the original
files. The second is that ARC is a lot easier to use and I don't keep
putting stuff in the wrong directory with the wrong ownership as I do
with BACKUP.
IF anybody has another program that stores files in an archive and
compresses them too for the VAX, I would love a copy. I have several
compression program for the VAX, but they will only compress one file at
a time.
Thanks,
================================================================================
Billy Barron Bitnet : BILLY@NTSUVAX or AC02@NTSUVAX
Acting VAX system manager TEXNET : NTVAXB::BILLY or NTVAXB::AC02
North Texas State Univ. Internet : billy%ntvaxb.decnet@utadnx.cc.utexas.edu
SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================