[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs
Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs
Wed, 10 Sep 1997 21:01:46 -0500 (CDT)
+ 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.
+ edit this text...
+ 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-
+ 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.
+ ; 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.
- LYNX-DEV Mainframes, 3270 and Lynx FORMs, Kevin Ternes, 1997/09/08
- Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs, Nelson Henry Eric, 1997/09/08
- Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs, Nelson Henry Eric, 1997/09/10
- Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs,
Robert Bonomi <=
- Re: LYNX-DEV Mainframes, 3270 and Lynx FORMs, Robert Bonomi, 1997/09/10