RE: Input inhibited

I even put out a window which says "Please wait" that had a lock on it while
it was building the subfile, it doesn't lock out the ENTER key but does lock
all the other keys.
Here is the dds:
R WAIT
ALARM
LOCK
FRCDTA
OVERLAY
WINDOW(7 22 4 35)
WDWBORDER((*COLOR TRQ) (*DSPATR RI)-
(*CHAR ' '))
1 12'Please Wait'
DSPATR(HI)
3 8'Gathering Information'

I am going to try the invite at the SFLCTL record only, next on my list.

Craig

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Friday, June 01, 2007 1:02 PM
To: Midrange Systems Technical Discussion
Subject: Re: Input inhibited

Hi Craig,

Do you think it will work if I put the 'INVITE' at the appropriate format
level?

INVITE means "unlock the keyboard and allow input, even though I haven't
tried to READ the record yet". (Or "terminal is invited to provide input")

Obviously, you want to make certain that you don't use INVITE if you
want the keyboard to be locked! If you supplied the INVITE keyword at
the file level, then every time you write a format (including the SFLCTL
or footer) it'll immediately unlock the keyboard and let the user type
stuff, which is exactly what you're trying to avoid.

Do you really need the INVITE keyword at all? Usually the only time
you supply INVITE is if you want to wait on a data queue rather than
waiting on a READ (or EXFMT) operation. In that situation you supply
INVITE, then the user can input stuff while you're waiting on the data
queue.