Re: QsnReadScr Api

<verndor response>
We have a product - 5250 Integrator - that lets you scrape the contents of a 5250 screen, put it into an array in a VB-like language processor, and do whatever you want. If the original poster is interested, he can call us at 888.rjs.soft toll-free for a demo or evaluation. Or contact me or Richard Schoen off -list from here.
</verndor response>

Vern

Simon Coulter wrote:

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 / \
--------------------------------------------------------------------