RE: Subfile question

On Tue, 13 Jul 2004 CarollaT@xxxxxxxxxxxxxx wrote:
>
> Scott:  That's what I thought, but I also know that the workstation
> controller has the data contained in the subfile, in its belly somewhere.
> And since we are using TCP/IP, the workstation controller is just a program
> running on the iSeries.  Even so, it probably doesn't trap when a record
> changed... But if it does, I am willing to explore the complexity of it, due
> to the amount of man-hours this might save us.  How complex is complex?
> *grin*

AFIAK, there's no "workstation controller" when working with TN5250 (i.e.
5250 over TELNET.)  There's a telnet server, which might be what you're
thinking of.

Again, the iSeries (whether it be a 5250 controller of some sort, a telnet
server, or whatever) sends an entire screen at once to the terminal.  It
does not get any data back until the entire screen comes back.  It has no
way to know which fields on that screen were updated in which order --
just that the screen was updated (or not)

There's a "modified data tag" that's sent to indicate that the field has
been changed -- but that's only an 1 or 0 to indicate IF the field was
updated.  It doesn't know when.


> We have our iSeries web-server turned off for security/HIPAA reasons, so
> that leaves VARPG, which I might consider using for this purpose.

That might be exactly what you need to do.



> Walden:  I'm not sure I understand what you mean.  CHECK (the op code,
> right?) checks a field to contain only characters in another string of
> characters.  This wouldn't seem to help, because the problem I am facing is
> the fact that I still can't tell when each individual changed record in the
> subfile was changed.  I can only read 'top to bottom' for changes.

CHECK(ER) causes "enter" to be automatically pressed when the user types
anything in the last position of a field.   (Technically, enter isn't
pressed -- just the screen is returned to the program as if it had been
pressed.)

Walden was suggesting this because when the user types something into the
field, control would be passed back to your program.  You could then use
SFLCSRRRN or CSRLOC or similar to determine which record the user had
updated and shove a timestamp into a hidden field of that subfile record.

The other problem with this is that the user can exit the field using the
arrow keys or something rather than filling in the entire field, in which case
the auto-enter would not be signalled.  I suppose you could also specify
"field exit required" and/or "manditory fill" to force the user to fill
the field in properly.