rms@ACC-SB-UNIX.ARPA (Ron Stoughton) (09/14/87)
I would like to expand a bit on the comments Bob Dixon made regarding his experience with ACCES/MVS: > We use UCLA mail to front-end smtp. That causes minor problems as UCLA > mail does not allow the full smtp address syntax. Henry Nussbacher (HANK%BARILVM.BITNET@wiscvm.wisc.edu) told me recently that an associate of his has made some improvements to UCLA/MAIL, one being recognition of internet domain names. I believe these changes have been provided to UCLA, but I don't know for sure whether they are included in the public domain release. I can get you a name of a contact if you are interested in more information. > Full-screen telnet to a VM system running KNET does not work. 3270 over Telnet requires three negotiations to take place before going into full-screen mode -- terminal type (e.g., IBM-3278-2), end-of-record (EOR), and binary. When ACCES/MVS is the server, KNET refuses the EOR negotiations by returning WON'T/DON'T EOR in response to our DO/WILL EOR. This causes our server to end up in binary (EBCDIC) line-at-a-time mode, while the KNET client thinks (erroneously) that it is in full-screen 3270 mode. Our transmissions to the client are therefore terminated with an EBCDIC <cr><lf>, and KNET is waiting for an <IAC><EOR> sequence. The reverse is true in the opposite direction. At this point the Telnet session appears hung. When ACCES/MVS is the client, KNET rejects our terminal type (IBM-3278-2) and requests that we resend it with another sub-negotiation. We don't and we probably should, but even if we did, KNET does not negotiate EOR which would leave us in the state as described above. I suspect that KNET is getting confused because our sub-negotiation response is being split into two transmissions -- <IAC><SB><TERM-TYPE> in the first message followed by <IS>IBM-3278-2<IAC><SE> in the second (it's a stream protocol folks). Bob Braden has suggested that the 3270 negotiation protocol could be changed to imply EOR if, but only if, terminal type and binary are successfully negotiated, and the terminal type is IBM-3278. There is a separate group of vendors and users debating this issue. If and when there is a consensus that the protocol should be changed, we will comply. In the meantime, KNET should conform to the protocol. > FTP is very powerful in dealing with MVS files, but requires the user > to supply the MVS volume name, which is a pain. We agree, and as a result we have removed this wart, along with many others, in the latest release (2.0). If a volume name is not provided, a default volume is used. Also, DSCB attributes are now retained when writing to pre- allocated data sets. We think we have made simple transfers simple by eliminating the need to use the SITE (i.e., Unix quote) command. We en- courage our users to upgrade to the new release. > FTP allows file transfer between any 2 computers, neither of which needs > to be the MVS system. This is useful, but requires the user to provide > login info for MVS twice if one of the systems is MVS. Bob Dixon was kinder than most in describing this feature. Many users who have been introduced to networking via Unix have found the three-party model confusing, or at least more cumbersome to use. Therefore, we have rewritten the MVS FTP client to implement the command syntax of a Unix client, and mimic a two-party model (the local MVS session is hidden). This allows us to maintain the performance advantages of a three-party model (the file does not need to pass through VTAM and the TSO address space) while gaining the simplicity inherent in the two-party model. This will be available in Release 2.1 which is close to being out the door. Incidentally, before I get growls from this mailing list, I should acknowledge that we don't hold the Unix FTP client as the model of perfection, but it does provide a measure of acceptance. Therefore, we implemented it as an alternative until we can provide an SPF panel-driven client which may be a more natural interface for an IBM TSO user. Ron Stoughton rms@acc-sb-unix.arpa