lowry@srcsip.UUCP (Dave Lowry) (03/25/88)
I've just tried my first ftp from sumex-aim. I used binary ftp and got a Stuffit file onto my vax. What I'm having problems with is getting the file from the vax to my mac. I've tried all variations on Kermit, but Stuffit always rejects the result because of a "bad header". I've also tried a thing called macput that came with Sumacc many years ago. Again, no luck. Can anybody help?
hallett@hamlet.steinmetz (Jeff A. Hallett) (03/29/88)
In article <2678@altura.srcsip.UUCP> lowry@srcsip.UUCP () writes: > >I've just tried my first ftp from sumex-aim. I used binary ftp and got a >Stuffit file onto my vax. What I'm having problems with is getting the file >from the vax to my mac. I've tried all variations on Kermit, but Stuffit >always rejects the result because of a "bad header". I've also tried a thing >called macput that came with Sumacc many years ago. Again, no luck. Can >anybody help? Yeah. Often, when you get things from archive, there is a small blurb put at the start of the file explaining what to do with it. We have had problems with Stuffit not skipping this. While on the VAX, bring the file up in some editor, strip off everything before the actual start of the hex (everything except "(This file must be decoded with BinHex 4.0)" - that is required for BinHex decoding), then download it to your Mac with Kermit (make sure linefeeds are stripped). That should work a little better. Jeffrey A. Hallett | ARPA: hallett@ge-crd.arpa Software Technology Program | UUCP: desdemona!hallett@steinmetz.uucp GE Corporate Research and Development | (518) 387-5654 +--------------------------------------+--------------------------------------+ | Credo Quia Absurdum Est | +-----------------------------------------------------------------------------+
wrp@biochsn.acc.virginia.edu (William R. Pearson) (03/29/88)
>I've just tried my first ftp from sumex-aim. I used binary ftp and got a >Stuffit file onto my vax. What I'm having problems with is getting the file >from the vax to my mac. I've tried all variations on Kermit, but Stuffit >always rejects the result because of a "bad header". I've also tried a thing >called macput that came with Sumacc many years ago. Again, no luck. Can >anybody help? Your problem is probably due to using binary ftp. Most of the stuff on sumex-aim is in *.hqx format, an ascii coding of binary. So to get the stuff from sumex-aim, you need to do an ascii transfer. You should be able to read the line: (This file must be ... with binhex 4.0) or some such at the begining. You then download it and convert it with binhex (and then perhaps stuffit or pit). sumex-aim (a tops-20 machine) has binary that is very very strange. Bill Pearson wrp@virginia.EDU
kraut@ut-emx.UUCP (Werner Uhrig) (03/29/88)
>> the first poster had problems using binHex on files retrieved from SUMEX, > the second poster suggests that the instructions should be stripped from > the beginning of the file running binHex ... and then you can obtain a copy of xbin and macput from the archives. xbin converts a hex file into 3-resource files (ignoring all the junk at the beginning until if encounters the magic line with "(This file must be decoded with BinHex 4.0)") which you can then download with macput, creating "real" Macintosh files directly (you must use a terminal emulator which knows how to do the Mac Xmodem protocol, such as VersaTerm). there are some other, useful programs, such as macbin you may want to get familiar with .... makes me wonder, maybe some of these "basic" Macintosh tools should be reposted regularly (annually) to benefit the "new kids on the block" ..... as well as help others obtain the latest versions or that "great utility" they may have missed .... just a thought (which *REAL* Usenetters with only comp.binaries.mac as a source for things might want to pursue; fortunately, I have archives and user-groups to get things from) -- (prefered mailbox:) werner%rascal@sally.utexas.edu ....!ut-sally!rascal.ics.utexas.edu!werner (if rascal is unreachable:) werner@astro@sally.utexas.edu werner@utastro.uucp
rick@seismo.CSS.GOV (Rick Adams) (03/30/88)
Wrong answers provided by people guessing about what the problem might
be are worse than no answers at all. If you aren't familiar with simtel20
you shouldn't be responding.
simtel20 is a DEC-20 machine wiht 36 bit words. 8 bit bytes don't
fix evenly in 36 bytes, so they are packed. If you transfer
a "binary" fine in either "ascii" mode OR "binary" mode you will get
the wrong answer (unless you are on another DEC-20 or DEC-10!). You need
to do the transfer in "tenex" mode.
Following are the actual instructions from the simtel20 people.
They explain exactly what is happening and how to avoid it.
--rick
FILE TYPES
Files are stored in two formats: Text files such as those with
names that end with DOC, HEX, INF and ASM are sometimes stored as
ASCII files, but usually these files are stored in binary squeezed
form. Binary storage is also used for executable (COM) and library
files. Squeezed and library files are described below. All binary
data are stored as four 8-bit bytes per 36-bit SIMTEL20 word, with the
low-order four bits of each word filled with zeros. If such a file is
interpreted as a contiguous string, as will happen if a straight
binary transfer is made to a 16 or 32-bit UNIX machine, the four zero
filler-bits per 36-bit group will cause rather bizarre and frustrating
results. The methods for dealing with this situation, which differ
from machine to machine, are explained in a following paragraph.
Squeezed files have been compressed using programs available in
directory <CPM.SQUSQ> to obtain an approximate 35-percent size
reduction. These files can be identified by the letter Q in the
extension field. For example, the file PD:<CPM.ASMUTL>RMACPAT.AQM is
a squeezed file. It must be transferred as a binary file, and then
unsqueezed. The unsqueezing can be done on a CP/M system using
USQ-xx.COM (where "xx" is the current version) from directory
<CPM.SQUSQ>, or there are several host-based unsqueezers in the <CPM>
and <UNIX> archives (see for example, directories <MISC.TOPS-20> and
<UNIX.SQ-USQ>).
CP/M library files (those with names ending in LBR) combine
several regular CP/M files into a single BINARY file which contains an
internal directory of its contents. They are created using the CP/M
library utility LUxxx.COM (where "xxx" is the current version) or some
other compatible utility. The complete packages for LUxxx and a newer
compatible program called NULUxx (where "xx" is the version) can be
found in directory PD:<CPM.CPMLIB>. C-language source code for a
compatible UNIX utility called LAR (library archiver) is in directory
PD:<UNIX.CPM>.
All files with names ending in ".1" are stored in binary format, and
those with names ending in ".2" are stored in ASCII. This
relationship will continue to apply for files in the <SIGM>, <CPMUG>
and <PC-BLUE> archives until further notice.
...
FILE TRANSFER VIA FTP
FTP stands for File Transfer Protocol, a formalized procedure for
moving files among machines on the Defense Data Network (DDN) and
other networks that connect with the DDN. The protocol is implemented
by a program often called FTP. The different mainframe operating
systems implement FTP with variations in command syntax. Some systems
have the remote-file-name precede the local-file-name in the command.
Others reverse this order. Some versions have the whole command on a
single input line, while others use multiple lines. Read the
documentation for your local system, or consult a friendly system
wizard for the details of your local FTP command syntax.
Users of TOPS-10, TENEX, TOPS-20 or ITS systems can use "image"
or "paged" mode for ALL transfers. UNIX users must use "ascii" mode
for ASCII files, and "tenex" or "type L 8" mode for binary files.
MULTICS users can use "ascii" mode for ASCII files, but binary files
require special treatment that is best described by the following
example provided by Paul Schauble <Schauble@mit-multics.arpa>:
!ftp simtel20
220 SIMTEL20.ARPA FTP Server Process 5Z(14)-7 at Mon 10-Sep-84 00:27-MDT
user_ftp: !login anonymous
331 ANONYMOUS user ok, send real ident as password.
Password: !guest
user_ftp: !quote "type l 8" <--(NOTE: That's lowercase "L" 8.)
200 Type L bytesize 8 ok.
user_ftp: !get micro:<cpm.zcpr3>alias.hlp alias.hlp
150 Retrieve of MICRO:<CPM.ZCPR3>ALIAS.HLP.1 started.
226 Transfer completed.
Total elapsed time: 35.7 seconds.
4348 bytes transferred in 18.5 seconds (1850 bits/sec).
user_ftp: !quit
221 QUIT command received. Goodbye.
Lines beginning with "!" are typed by the terminal user. The received
files are stored on MULTICS with one 8-bit byte per 9-bit word, and
can be trans- ferred to a microcomputer with Kermit (described in a