Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs

[Robert Bonomi]

+ Date: Wed, 10 Sep 1997 18:12:51 -0500 (CDT)
+ From: Klaus Weide <address@hidden>
+ Subject: Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs
+ 
+ On Mon, 8 Sep 1997, Kevin Ternes wrote:
[..  snip description of  IBM mainframe/3270 terminal set-up ..]
+ 
+ Did you have to modify Lynx in any way for this to work, or do you have to
+ use specific options of run-time flags for lynx?  Or did you have to
+ compile Lynx in some special way, maybe using replacement libraries (for
+ example, for curses), or some other modifications on the UNIX side to make
+ this A-Net work?

LYNX would think it is being run from a straight telnet connection.  
the only 'funny business' is that telnet is likely running in LINE-BY-LINE 
mode... this due to the inherent characteristics of a 3270 terminal.
+ 
+ > Everything appears to work great except for FORM textboxes.  
+ 
+ Does that include both TEXTAREA and INPUT TYPE=text fields?

I'd expect so. 3270s  have 'protected' and 'unprotected' character 
positions on the screen.  By default, anything that the host has -written-
to is 'protected'.  you have to take special steps to make a field 'un-
protected' (i.e. modifiably).
+ 
+ > The first
+ > time a user accesses a FORM, he can enter anything he wants and move in
+ > and out of the text box and easily edit what he enters and then submit
+ > the FORM.  However, if the user uses back to return to the FORM (to do
+ > something like refine a query), he cannot edit the string in the textbox
+ > that he entered before submitting.  He can _add_ to what is in the text
+ > box, but he cannot delete anything or change it.

COMMENT:  on any form, there _should_ be a "clear" button.  invoking that
   will get rid of any and all 'previously entered' text on the form, and
   render it 'usable' again.  This *does* have the dis-advantage that it
   will also erase any information that the user _wanted_ to preserve.

COMMENT:  you _may_ be able to 'force' an empty form, by positioning on the
   link _to_ that form, and hitting 'x', and then SENDing.

+ 
+ I assume the same kind of problem occurs if the form field contains some
+ default text (e.g. 
+        <TEXTAREA>
+        edit this text...
+        </TEXTAREA>
+ in the HTML)?

pretty much guaranteed.
+ 
+ Also, in that environment, is there a way to do a screen REFRESH of which
+ Lynx is aware - i.e. not local withing the terminal or between the 
+ terminal and emulator, but Lynx gets sent a Control-L character?
+ If yes, what is the effect? 

probably *NOT*.   3270's are "smart" _block_mode_ devices, connected to
"smart" controllers, designed -specifically- to minimize the amount of
'traffic' back-and-forth between the terminal and mainframe.  All
'interactive' stuff is entirely local _in_the_terminal_.  Stuff is sent
to the mainframe a *screen-ful* at a time.  Thus, in this case, Lynx
_cannot_ see *anything* until the 3270 user has hit the "Send" key.

+ 
+ > For instance, if the first query was "one AND two", then after going
+ > back he could change it to "one AND two AND three"  but he cannot change
+ > it to "one OR two" or "one AND three".  If you know how 3270s work, it
+ > sort of makes sense that this could happen.
+ 
+ What happens if the user fills in a field, then (without submitting) pages
+ down to the next screen, then up again?  can the text be modified?

If the page-up/page-down is done *without* 'sending' the terminal =page-
image= back to the _mainframe_ (which is a *distinct*, *separate* operation
from "submitting" the _form_), then there is -no- record of that 'input',
you get an empty field, and full input is possible.

If, on the other hand, one 'sends' the modified page-image, then Lynx *does*
see it, and when you 'return' to that part of the form, the text will be 
there, and (in all probability) be _not_ modifiable.

+ What I am getting at with my questions: as far as Lynx's output is
+ concerned, when the screen is painted, the only difference between the
+ filled-in text in such a form field and the free space is that the latter
+ is filled with underscore characters.  So how does the A-Net software, or
+ whatever is between it and the 3270 terminal, know which parts of the
+ screen should be made editable?

*THIS* is the critical question, indeed.  And the A-Net software _is_ what
is making that determination.
+ 
+ My only guess is that it applies some heuristic which gives a sequence of
+ '_' characters some special significance (maybe in connection with some
+ text attributes only). 

It _has_ to look at the page, and =guess= as to "intentions".

I *suspect* (_without_ ANY knowledge of the A-Net product :) that it 
looks for  A) a sequence of two or more consecutive '_'s,  B) a '[' and ']'
occur on the _same line_, and *MAYBE* C) from wherever the cursor is
positioned, to the next _printing_ character, or end-of-line.  That anything
where any of those conditions is met is designated an "input" field, and thus
'modifiable', and that everything else _retains_ the 3270 *default* of 'un-
modifiable'.

+                         If that is the case, would it help to delay
+ filling-in of the text - first write all-underscores, then refresh() the
+ screen, then fill in the text and do a (partial?) refresh again?

"maybe".  A product like A-Net's has a *very*difficult* job to do.
In addition to figuring out 'input fields', it has to =guess= as to 
when the 'host' (in this case, the system where Lynx is actually _running_)
is *finished* writing the screen -- to know when to display it to the user.
I _would_not_ be surprised of the above logic resulted in *two* pages of
output to the user -- the first without the 'editable' text, and the second
with it, but 'un-editable'.

I once tackled trying to write code todo the job that the A-Net software is
doing.  I'm *EXTREMELY*IMPRESSED* that it works 'as well as it does'!

*IF* the A-Net software recognizes Lynx 'pop-up' lists as an INPUT field,
*THEN* if one were to modify Lynx's handling of INPUT or TEXTAREA items
to begin each line thereof with a '[', and end it with a ']',  the A-Net
software should provide the behavior you desire.

I'll suggest that this should be a 'local modification' to _your_ copy of
Lynx -- this is a compatibility issue that is *specific* to an IBM mainframe
running the A-Net software and accessing a remotely hosted copy of Lynx.

If the above suggestion does _not_ work, the next step is to contact the
A-Net folks and _find_out_ *how* the software decides what is a "modifiable"
field.  With that information, somebody can probably point you in the 
right direction, as far as modifying your Lynx to accomodate it.

+ If my wild guesses have something to do with reality, you might be able to
+ modify the Lynx code to do that without too many changes.
+ 
+ 
+       Klaus
+ 
+ ;
+ ; To UNSUBSCRIBE:  Send a mail message to address@hidden
+ ;                  with "unsubscribe lynx-dev" (without the
+ ;                  quotation marks) on a line by itself.
+ ;
+ 
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;