OK, now for a more complete reply...
 
On Wed, 11 Oct 1995 14:09:37 EDT James B. Byrne said:
>I have a question regarding executable (program) file transfers between
>HP3000's vis the Internet.  Paul Gobes of Robelle and myself spent a great
>deal of Tuesday getting the HP3000 LYNX program transferred from his 3000
>to mine [...]  The steps that we eventually took to transfer a file which
>could run on the target machine were these:
>
>1       Use MOVER.PRVXL.TELESUP to compress the 3000 NMPRG file:
>        syntax  MOVER.PRVXL.TELESUP "-c LYNXT /SYS/USRBIN/LYNX"
 
In general, use MOVER whenever moving from 3000 to 3000 no matter what's in
between.  MOVER does some compression, but the Posix compress is better and
I recommend you compress the resulting MOVER truck file.  To keep some form
of convention, name the truck file LYNX.M (or whatever.M).
 
>2       Convert to ASCII using UUENCODE.HPBIN.SYS
 
This is only necessary if you are planning to e-mail the file.  Rather than
converting the file, I suggest instead that you compress it.  From the shell
you would "compress LYNX.M" and you will now have a file LYNX.M.Z which is
smaller than you started with (generally speaking).
 
>3       Transfer file to public gateway machine (HP9000) using FTP.ARPA.SYS
>3.1     Run FTP from HP3000
>        syntax  FTP.ARPA.SYS
>                >BINARY       (must use binary transfer even if ascii file)
 
You need to understand this part -- for the TIME BEING the FTP process on
the 3000 doesn't handle ascii bytestream files correctly.  There is an SR
filed on this by me (SR#5003-272690).  While in your case BINARY works since
all three machines are bytestream filesystems, it would not work if you have
a PC in the middle (the resulting transfer would work, but you will NOT have
a text file on the PC in the traditional sense).  This was the heart of my
problem outlined in http://opus.admin.utc.edu/downupld.html.
 
But assuming you followed my earlier recommendation, you WILL need binary
mode to transfer LYNX.M.Z.  I won't elaborate on the FTP transfer further.
Now from the 3000 side:
 
>4.1     Run FTP.ARPA.SYS
syntax  :FTP.ARPA.SYS gwhp9000
        >binary
        >get /bin/dock/LYNX.M.Z ./LYNX.M.Z
        >exit
 
And finally:
        :uncompre.hpbin.sys "./LYNX.M"  (it will look for the .Z file)
        :mover.mpexl.telesup "-x ./LYNX.M"
 
This will result in a /SYS/USRBIN/LYNX file, since you stored it with an
absolute path.  It would be preferable if you built the original file by
changing into the directory of the LYNX object file, and doing something
like:  mover.mpexl.telesup "-c LYNX.M LYNX" (or "-c LYNX.M ./LYNX") so
that the file is stored "relative" rather than "absolute".  Then the
receiver can unpack the mover file into whatever directory they wish.
 
>My questions are these.
>
>Was it necessary to use UUENCODE and UUDECODE to transfer the file [...]
 
No.
 
>I am told that the ASCII/BINARY question regarding FTP was discussed on this
>list earlier this year.  Can someone point me to the correct place to review
>this discussion or kindly give me a precis of the important points raised?
 
If you need more info, drop me a note.
 
Then later, Chris Bartram replied with some more advice, particularly in
regards to Reflection 5.0 and Posix file transfers.  This is about the only
way to cleanly exchange ASCII bytestream files (like html, for example)
until FTP is fixed.
 
On a more general note... if the source and destination machines are MPE/iX
5.0, by all means use the MOVER+compress to make a binary "blob" as Chris
calls it (RYDER or MOVER either one, if you have the former, update to the
latter!).  These "blobs" can be variable-length, fixed-length, whatever, as
long as you transfer them in binary MOVER can generally pull something out
of them (with the exception of httpd transfers if you don't have mime.types
configured right for the .M.Z files).
 
[\] Jeff Kell <[log in to unmask]>