Re: MVS FTP interface (Was: Re: LYNX-DEV Two bugs in Lynx)

[Jim Spath (Webmaster Jim)]

On Thu, 20 Feb 1997, Foteos Macrides wrote:
> address@hidden (Paul Gilmartin) wrote:
> >In a recent note, Foteos Macrides said:
> >>    MVS servers do adhere, correctly, to the ftp protocol, so
> >> track down the ftp RFCs, and make sure you've studied and understand
> >> those as well.
> >Actually, this work has been done well by the authors of RFC 1738.  Most
> >important is to study and understand RFC 1738, and make the MVS flavor
> ...                     
>       Again, that's to ensure a clean failure.  Would it in fact
> be better to do a successful series of CWDs, and then hang on the
> retrievals, as you described in your earlier message?  Or perhaps
> succeed in a retrieval, but possibly send "bad" things to the screen
> because the gateway doesn't have code based on the server's file
> system and thus has no clue about whether what was retrieved is
> appropriate to send to the screen versus forcing a download offer?

I'm surely unqualified to write proper code for such a gateway, but I can
comment on the behavior it should exhibit.  Forgive me if the following is
common knowledge. 

On IBM mainframes, file (dataset) names are either fully or partially
qualified.  A fully qualified datasat name (FQDN) is typically enclosed in
single quotes (tickmarks).  If one does not use tickmarks, the name is
fully qualified by adding a prefix, which is dependent on the users login
name. 

When I FTP'd to epaibm.rtpnc.epa.gov, a message indicated the working
directory as "PA2.", which seems to be a synonym for "PUBLIC."  This
prefix is like a subdirectory, except that dots are used instead of
slashes. 

To change prefixes, one can command the FTP server with a CD 'PUBLIC.'
Leaving off the backticks causes the mainframe to prepend the existing
prefix, like this: 

ftp> cd PUBLIC.
250 "'PUBLIC.PUBLIC.'" is working directory name prefix
ftp> cd 'PUBLIC'
250 "'PUBLIC.'" is working directory name prefix

Unfortunately, it doesn't tell you if there are any files with that
prefix.  And if you give an invalid prefix, it silently drops you (Ms.
Anonymous) back at PUBLIC. 

Anyway, what I'm wondering is how this pre-knowledge would be encrusted
into "valid" URLs.  To use the FQDN, would this be appropriate: 

ftp:/some.big.iron/%27public.useful.data%27

which could be equivalent to:

ftp:/some.big.iron/%27public/useful/data%27

and thence, the PQDN:
ftp:/some.big.iron/useful.data

Since "/" is an invalid character for dataset names, Lynx should strip it,
and only use "." and "'" when communicating with MVS servers.  Perhaps
turn "/" into "." where the meaning of a subdirectory is implied? 

It would also be useful to have Lynx do non-anonymous FTP to such systems,
but I can't see how the prefix would be stored or used. 

BTW, Netscape fails on ftp://epaibm.rtpnc.epa.gov/ :-)

------
<http://www.cs.indiana.edu/picons/db/users/us/md/lib/bcpl/jspath/face.xbm>

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;