On 10/10/2008, at 11:53 PM, Smith, Julius Michael wrote:
Based on Scott Klement's article in System iNetwork Programming Tips:
Q: We have a requirement to extract data from an existing green-screen
display into an Attention-key program.
Gene Gaunt published code years ago that used the raw 5250 data
stream to extract the current screen. His was an April-Fools joke
that then reversed the screen data to confound the user.
I published code that also used the raw 5250 data stream to find and
show display attributes in an emulator session.
You may find one of these a more suitable base to start from.
I used this technique with success on a display without the "INVITE"
keyword.... however, when using it on one that did have the "INVITE"
keyword the following happened:
1> The QsnReadScr API worked and retreived the screen buffer
2> From that point forward, no keys worked.... Fkeys, enter, anything,
therefore the screen was unuseable to the user. Based on that
observation, it is my thought that the QsnReadScr API turns the
"INVITE"
keyword off
Specifying INVITE on a record format in the display file DDS enables
Read From Invited Device.
Read From Invited Device works by sending data to a terminal with an
instruction to put the device in a read state even though the host
application has not yet issued a read operation. This allows the user
at the terminal to start entering data while the host application is
doing other things. At some point the host application issues a read
and gets the data entered by the user.
Any READ of the screen will satisfy the outstanding INVITE.
However, given that an application can issue multiple reads to a
screen I would not have expected the screen to be disabled.
Does anyone have a resolution for this issue.
First question: Why are you using INVITE? What does your application
do that depends on INVITE being active?
Second Question: Do you need to extract data the user has typed on
the screen (before pressing an AID key) or only static data supplied
by whatever program caused the screen to be displayed?
You may find QsnSavScr more suitable. That won't satisfy the invite.
You might have to use QsnRstScr to put things back in the previous
state but I suspect not.
You could try issuing QsnPutOutCmd with Command x'52' and Data
x'0000' followed by a QsnPutBuf call to put the device back into a
read state.
The big question is how to determine if the device is currently in an
invited state because you won't want to do this for all screens.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
