RE: new display file features

Now, I'll ask the idiot's question:  Is this the sort of thing that API's or
MI coding would resolve well?  Is there a way through those methods to read
keystrokes?


-----Original Message-----
From: dhandy@isgroup.net [mailto:dhandy@isgroup.net]
Sent: Friday, November 12, 1999 12:19 AM
To: boothm@goddard.edu
Subject: Re: new display file features


James,

>IMHO, one of the failures of OV/400 was the performance degradation when
>you had too many people choking the system with keystroke activity.

I surprising amount of that processing was done by the WS controller
itself, not the OV programs.  To enable OV, the WS controllers for the
S/36 and AS/400 added a whole new mode and set of data streams.

When a program (such as OV) would enable "word processing" mode in the
controller (instead of the normal "data processing" mode), it also
sends a series of data streams which load tables in the WS controller
with the text for various error state messages and Fx key prompt
texts, as well as numerous display stream orders defining portions of
the screen, the scale line, audit window, etc.   (Among other things
this let them handle multiple languages for the prompts, and make
changes via PTFs instead of being part of the WS controller hardware.)

Unlike a normal DP mode program, when you pressed an AID key, the WS
controller handled much of the work and required zero cycles from the
program in main storage.  The WS controller also automatically
displayed text in the "audit window" based on what character the
cursor was placed under.  (These texts were also downloaded to the
controller at start-up.)

So although it may appear that the OV program is processing keystroke
level activity, it really wasn't near as much as you may think.  The
controller was performing lots of it without taking any resources from
the main processor.

Can you set word processing mode yourself?  Sure, if you send the
right data streams.  But WP mode cannot co-exist with DP mode on the
screen at the same time, and regular input field orders are not
accepted by the controller while a screen is in WP mode.  So it would
be a royal pain to implement.  And it wouldn't help anyway.  There
still is no data stream order I can find that tells the WS controller
to send each keystroke back as it happens, even in WP mode.  Only AID
keys that the controller can't handle by itself return control to the
program.

Here is how I think this would have to be implemented on the AS/400:

 1) Define your screen like normal, with a regular "position to" field
 2) Display the format using WRITE, not EXFMT, and DFRWRT(*NO)
 3) Start a loop in your code which issues either a READ IMMEDIATE or
a READ MODIFIED IMMEDIATE ALTERNATE data stream command.  This lets
you get the current contents of all input fields, or only those with
MDT set, without regard to whether an AID key has been pressed.
 4) When the input field changes, reposition/refill your subfile and
WRITE it again, putting the cursor at the current address
 5) Check if an AID byte is pending; if not return to step 3
 6) Issue READ to resume normal operations

Step 3 can be accomplished either using UDDS and the USRDFN keyword,
or by using the Dynamic Screen Manager API's QsnReadImm or
QsnReadMDTImmAlt.  Using QsnReadImm would be easier since you would
get a consistent input buffer feedback for the format.

Step 5 has me wondering.  There has got to be an easy way to just test
if the WS controller has locked the keyboard following an AID key
press and is ready for one of the read commands.  But I don't see one
offhand in the 5250 data streams or the DSM API's.

So the only thing I can think of to avoid the AID wait inherent with
the read commands is to make the DSPF have a WAITRCD() value of *IMMED
or 1 second or whatever.  Then code the same way you would for
displays which auto time-out.  Issue the RPG READ operation and if an
error occurs check the INFDS to make sure it was a time-out.  If it
timed out then no AID was available so return to step 3.

By using a WAITRCD() of 1-2 seconds, you would at least be yielding
some processor time.

This process may work great for a lightly loaded system, or if only a
couple of users are in this loop at any given time.  But I'd hate to
think of what it would mean it was used regularly.

That's part of the appeal of client/server.  Let an intelligent WS
handle the user interface, and the 400 handle the back end.

Doug

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---