Re: ACC's ACCES/MVS


Ron Stoughton (rms@ACC-SB-UNIX.ARPA)
Mon, 14 Sep 87 11:33:25 PDT


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



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT