Glad to know the trick -- just in case I have to handle 80+ byte file names
some day.
I briefly fiddled with bldparms with "dir" into a local file, but I didn't
keep copies of my failure(s) and can only guess that since I was running
ftp in binary mode maybe I changed line 2 of my bldparms file instead of
line 1 (?). I didn't spend much time on it before it I switched to "ls" and
everything became easy.
In re-testing today I see that ftp builds the local file for "dir" & "ls"
according to line 1 of bldparms (the "ascii" line) even if I am in binary
mode and line 2 is used when I actually do an ftp "get". OK, now that I
know.
And no, I probably don't need to be in binary mode there anyway.
Dave Powell, MMfab
----- Original Message -----
From: "Gary S Robillard" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, April 22, 2009 10:42
Subject: Re: [HP3000-L] ftp patch ----- reminds me of something else with
ftp
Hello All,
Sorry, I had responded only to Dave when I replied to him yesterday .
I had no problem having my listing file created according to the
specifications in BLDPARMS.
On 7.0 (using first FTPHD67A, then updating to the latest FTPHDJ4A).
On 7.5 (FTPHDH9A) I originally could not get it to work, but it was a
problem with the BLDPARMS.ARPA.SYS file, which once I recreated it from
BLDSAMP.ARPA.SYS, I was also able to get to work.
It also worked on my (gasp) MPE/iX 6.0 system...
Since Dave is doing a 2 step FTP, he could use a file equation to a BLDPARMS
file with the ASCII transfer definition set to 100 (or whatever size doesn't
get the 'records truncated' error) for the DIR, then use the standard
BLDPARMS for the actual transfers.
Since the 'ls' works maybe he just wants the filenames now anyway ;-)
I copied BLDPARMS.ARPA.SYS to my local group as BLDPA100, changed the first
line to have -100 instead of -80 (from ";REC=-80,,F,ASCII;DISC=204800" to
";REC=-100,,F,ASCII;DISC=204800").
Then issued "FILE BLDPARMS.ARPA.SYS=BLDPA100,OLD" before issuing the
FTP.ARPA.SYS command.
Without the file equation, I get an 80 byte record listing file (with
truncated records from my HP-UX system) and with the file equation I get a
100 byte record listing file with no truncated records from my HP-UX
system...
Thanks,
Gary Robillard
----- Original Message -----
From: "donna hofmeister" <[log in to unmask]>
To: [log in to unmask]
Sent: Wednesday, April 22, 2009 10:20:13 AM GMT -07:00 US/Canada Mountain
Subject: Re: [HP3000-L] ftp patch ----- reminds me of something else with
ftp
A frequent recommendation on this list has been to do two-step ftp's. it's
not a perfect solution but in many situations it workable.
It appears that when using 'dir' in this manner -- DIR [remote-directory]
[local-file] -- 'local file' is purged (if needed) and (re-)built as an
80-byte file just as you discovered. I don't see a way around it. And yes,
ftp is it's glorious short-sightedness will truncate file names in order to
fit information into an 80-byte record. (the format is listfile,2)
Fwiw, 'ls' (LS [remote-directory] [local-file]) will also by-default,
without-asking, I-don't-care-what-you-want build an 80-byte file too. As
dave discovered, the advantage here is you'll get a simple, vertical list of
file names. So unless you have file names that exceed 78-bytes (because of
the leading './') you're ok using 'ls'. (the format is listfile,6)
Fwiw #2, neither dir nor ls will walk the directory tree...
So dave, you found the solution/work-around -- use ls and be happy (cause we
ain't gettin' no patch now!) - d
---
Donna Hofmeister
Allegro Consultants, Inc.
408-252-2330
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
> Behalf Of Dave Powell, MMfab
> Sent: Tuesday, April 21, 2009 1:27 PM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] ftp patch ----- reminds me of something else
> with ftp
>
> (Well, donna's link works)
>
> Several weeks ago I had a project where ftp "mget" could have been the
> solution except I wanted to rename the remote files to be classsic MPE
> 8-char local file names. The remote file names, on a unix server, are
> some
> constant letters followed by a time-stamp, so they are different every
> day,
> and not known in advance).
>
> My solution was to run ftp twice. The first time uses ftp's "ls"
> command
> with the local-file option to get a file onto the HP with a list of the
> files we can download. Then a command-file reads that file and builds
> a
> series of "get" commands with the remote files names and the mpe-
> friendly
> local names I assign them. When we run ftp again those "get" commands
> snag
> the remote files.
>
> This approach has been working fine, and fwiw, might be workaround for
> anyone hit by the "mget" bug donna is referring to.
>
>
> The one thing that bugged me was the characteristics of the local file
> that
> holds the list of remote files, specifically the fixed 80-byte record
> length. I first tried using the "dir" command, like ">dir
> fileset*.txt
> FILELIST.PUB", but it kept blowing up because the remote records were
> over
> 80 bytes. I fiddled with file equations and ftp's buildparms and never
> managed make ftp use anything except an 80-byte fixed-length file for
> my
> file-list. So eventually I switched to ">ls fileset*.txt
> FILELIST.PUB"
> and it worked because the "ls" command has a much shorter format.
>
> So, was I missing something? Is there an easy way to make the local-
> file
> option of ftp's "dir" or "ls" use a file with a longer record than 80
> bytes
> ?
>
>
> Dave (just ticked-off that I couldn't over-ride it, don't really need
> an
> answer now) Powell, MMfab
>
> ----- Original Message -----
> From: "donna hofmeister" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Tuesday, April 21, 2009 08:27
> Subject: [HP3000-L] ftp patch
>
>
> > Several months ago (right before support ended <sigh>) the collective
> 'we'
> > discovered a bug in ftp:
> > http://raven.utc.edu/cgi-bin/WA.EXE?A2=ind0809D&L=HP3000-
> L&P=R7306&I=-3&K=1&
> > X=3CC8B565BEB43FC87D&d=No+Match%3BMatch%3BMatches
> > (hope that works, otherwise search for 'ftp mget' in September and
> October
> > of last year...and of course mind the wrap)
> >
> > A (the last?) patch was produced that repairs this problem --
> FTPHDK7A (id
> > for 7.5). currently the patch is in beta status. In order for the
> patch
> > to
> > be GR'd more people need to request/install the patch. If you still
> have
> > a
> > sw support contract and are willing to apply the patch (for the good
> of
> > the
> > community, frankly), please call the RC.
> >
> > Be a good sport and place a call :-) - d
> >
> > ---
> > Donna Hofmeister
> > Allegro Consultants, Inc.
> > 408-252-2330
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
