home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / bit / listserv / ibmtcpl / 3257 < prev    next >
Encoding:
Text File  |  1993-01-28  |  1.9 KB  |  39 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!USCMVSA.BITNET!LDW
  3. Message-ID: <IBMTCP-L%93012705080894@PUCC.PRINCETON.EDU>
  4. Newsgroups: bit.listserv.ibmtcp-l
  5. Date:         Wed, 27 Jan 1993 02:08:00 PST
  6. Sender:       IBM TCP/IP List <IBMTCP-L@PUCC.BITNET>
  7. From:         Leonard D Woren <LDW@USCMVSA.BITNET>
  8. Subject:      Re: FTP Configuration Data Set Not Working
  9. Lines: 28
  10.  
  11. On Tue, 26 Jan 1993 21:34:32 GMT,
  12.    RICHARD BOND <rbond@NEVADA.EDU> said:
  13. > We are running TCP/IP for MVS version 2.1 (I know we are behind) and doing
  14. > a FTP function from TCP/IP for DOS version 2.0 to it. On the MVS side our
  15. > user has set up a userid.FTP.DATA dataset including the file parameters that
  16. > he wants to override from the tcpip.FTP.DATA default.
  17. >
  18. > It does not work. Any type of file transfer from any PC running TCP/IP for
  19. > DOS winds up with the default parameters on MVS.
  20.  
  21. I can predict the future:  IBM will respond "Working as Designed" and
  22. "Submit a Requirement."  userid.FTP.DATA was implemented as a client
  23. interface, and the FTP server does not look at it.  When you FTP into
  24. MVS from elsewhere, you are talking to the server, which has not been
  25. made to look at userid.FTP.DATA.  It would be nice if it worked the
  26. way that you want, but I'll be rather amazed if they take an APAR on
  27. this one...  I suggest that you submit a SHARE requirement -- SHARE is
  28. coming up soon.  [The TCPIP requirements coordinator has an Internet
  29. address, but I forgot who it is and where I kept the info.  Sigh.
  30. Maybe he'll speak up here?  And get flooded with requirements...]
  31.  
  32. BTW, this is one of those "least surprise" issues that so many (most?)
  33. software developers don't understand.  Software should obey the
  34. Principle of Least Surprise.  That means that if a user doesn't know
  35. exactly how something works and guesses at it, more often than not the
  36. guess should be correct.
  37.  
  38. /Leonard
  39.