|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.