Re: TNVT100 problems with protected fields

[Roger Fajman <[e-mail]>]

== For Your Information ==

MAIL VIA BITNET FROM [e-mail]  WEDNESDAY  06/09/93  10:05:37 A.M.

Received: from UMDD.UMD.EDU by NIHCU (Mailer) id 3727;
              Wed, 09 Jun 93  10:05:36 EDT
Received: from UMDD.UMD.EDU by UMDD.UMD.EDU (Mailer R2.10 ptf000) with BSMTP id
 8104; Wed, 09 Jun 93 10:06:04 EDT
Date:         Wed, 9 Jun 1993 09:53:13 EDT
Reply-To:     IBM TCP/IP List <[e-mail]>
Sender:       IBM TCP/IP List <[e-mail]>
From:         Arty Ecock <[e-mail]>
Subject:      Re: TNVT100 problems with protected fields
To:           Multiple recipients of list IBMTCP-L <[e-mail]>
In-Reply-To:  Message of Tue, 8 Jun 1993 15:17:30 EST from <JOHNSON@PURCCVM>

Hi,

On Tue, 8 Jun 1993 15:17:30 EST Will Johnson said:
>I have been experimenting with tnvt100 within the VMGOPHER client as well as
>by itself to support telnet access to unix hosts expecting vt100 connections.
>
>I have encountered a problem when using a PC TN3270 (B&W or CUTCP) to access
>VM, then using TNVT100 to telnet to UNIX hosts. I often encounter a 'protected
>field' message where input data is expected. If this is for a login name,
>if I keep carriage returning until I get to the end of the screen, I finally
>get an unprotected field and can enter the login data. After these
>'protected field' messages, the program will accept an 'enter' (i.e. Carriage
>return but no other keyed data). At other times, when this happens, basically
>no data can be entered and you are forced to abort the session.
>
>Doing the same operations on Kermit (via 7171) or on a real channel attached
>3270 works fine.
>
>Our current environment is VM/ESA 1.1.1, CMS 8, and the latest TNVT100 with
>RXSOCKET V2.
>
>Does anyone (especially Arty) have any insight on this? Is this a general
>tn3270 type problem or is it specific to TNVT100? TNVT100 provides some
>very nice functionality, but problems like this certainly lessen the
>attractiveness of GOPHER clients as a general solution on VM, especially
>as more and more of our users access VM via TCP/IP and TN3270.
>West Lafayette, IN 47907-1408       GTE:      [phone]


The problem lies within the PC emulator software (such as tn3270, Extra!, and a
few others).  RXVT100 (by default) treats the entire surface of the 3270 screen
as a single unprotected input field.  According to 3270 architecture, this is
accomplished by *omitting* Start Field orders and basically just sending data
to the unformatted screen.  The PC emulators (the ones that are broken), seem
to get sick when at least 1 Start Field order is not present in the outbound
3270 datastream.  The emulators should adhere to 3270 architecture (if in fact
they wish to emulate 3270 devices) and accept an unformatted screen as produced
by RXVT100.  The Macintosh tn3270 client, written by Peter DiCamillo, is an
example of 1 emulator package that correctly supports unformatted 3270 screens.
I think this is the only emulator that I know of that correctly supports the
3270 architecture.

As a quick hack, I've added the PROTECT option to TNVT100 (and RXVT100).  This
option formats the 3270 screen as a large PROTECTed field with a small input
field somewhere near the cursor.  Since this was a hack, it is still a little
buggy (and thus, I haven't documented it).  This option also makes the cursor
behave "funny", but that's about all I could do while still maintaining the
look and feel of a vt100.  I truly despise the PROTECT option, since real
vt100 terminals don't have the concept of protected fields.  But, I am
committed (or should be committed? yuk yuk) to getting the PROTECT option to
work nicely.

Anyway, hope this helps explain the problem.  Give PROTECT a try.  It's not
very good, but it's getting there.

Cheers,
Arty