Dave, 
thank you very much for your synopsis on this.
we were trying to find a way whereby the process can be interrupted.
 The programmer did manage to do this with an assembler program that
waits and accepts an interrupt from the attention key - if none is
received the panel is jus reinvoked with the time updated.

unfortuneatly, I do not see a WAIT facility in TSO REXX - there is one
in Netview- which would have eliminated the need for an assembler
program.

you are correct about the attention key, but that can be set with
emulators.

     thank you again for your response

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Salt
Sent: Friday, September 19, 2008 1:46 PM
To: [email protected]
Subject: Re: can the ENTER key be simulated in an ISPF panel

> From: [EMAIL PROTECTED]
> I agree that DISPLAY LOCK is the way to got and is about the only
thing that works. .resp=enter seems to work except that you cannot see
the panel.


DISPLAY LOCK is usually used when some sort of processing is being
performed that may take a while. For example, if a user has just
requested 20,000 members be copied to an existing data set you might
want to use DISPLAY LOCK to inform the user that the request is being
processed, and to periodically show how many members have been copied so
far. Once all 20,000 members have been copied, you would then redisplay
the panel with a "success" message. The panel would become "unlocked"
and the user could press END or ENTER to continue with the next task. In
other words, there is no action required on the part of the user for the
panel to eventually become unlocked.

If what you are trying to do is similar to the above, then everything is
fine. But I think you mentioned earlier that you wanted users to be able
to press function keys while the panel is locked? If so, something is
very wrong with this picture. The whole point of displaying a panel in
locked mode is to *prevent* users from being able to press function keys
(or other keys) until the program has decided it's ready for the panel
to be unlocked.

If you are somehow counting on a user to take some sort of action that
will cause a panel to become unlocked, I would strongly urge you to
reconsider this design. Just about the only thing a user could do is
press the ATTENTION key, and this can have *very* undesired
consequences. For one thing, different emulators use different keys for
Attention, so some users might not even know where the attention key is.
They might try to press Attention and instead press SysReq (or something
similar) which could totally mess them up. This would be especially true
if they switch to a different emulator that uses different keys. In
addition, users like myself (who always run ISPF in TEST mode so that
panel changes are always refreshed) are usually kicked out of ISPF if
the Attention key is pressed. Still other users will use their Attention
key to interact with a session manager, and so on. In other words, you
cannot guarantee that a user will even *have* an attention key to press,
or if!
  they do that they'll know where it is. Because of this I would
strongly advise against coding something that *requires* an attention
key to be pressed. But hopefully yours is similar to the first scenario
I described where the panel automatically unlocks after a given period
of time?

Dave Salt

SimpList(tm) - try it; you'll get it!
http://www.mackinney.com/products/SIM/simplist.htm

_________________________________________________________________

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

  • ... Barkow, Eileen
    • ... Visser, Hans (PinkRoccade Infrastructure Services Technisch Specialist)
      • ... Barkow, Eileen
        • ... Wolfgang Schäfer
          • ... Barkow, Eileen
        • ... Wolfgang Schäfer
    • ... Jürgen Kehr
      • ... Barkow, Eileen
        • ... Dave Salt
          • ... Barkow, Eileen
    • ... Scott Barry
      • ... Barkow, Eileen
      • ... Dave Salt
    • ... Scott Barry
      • ... Jousma, David
    • ... Thomas Berg
      • ... Barkow, Eileen
        • ... Dave Salt
          • ... Barkow, Eileen
            • ... Dave Salt

Reply via email to