Re: Scrape 5250 to 5250 with help from DSM?

["Rory Hewitt" <roryhewitt@xxxxxxxxx>]

Darren,

You probably *will* need to not ignore the SAVE/RESTORE operations - they
are used extensively when windows are used, for instance - the full screen
is saved, a window is displayed, and then when the window disappears, the
previous screen is restored.

However, as Scott points out, you can send *anything* in response to a SAVE
and it will come back with a RESTORE. I just send the current screen data,
along with a bunch of my own data and get it back after the restore. No need
to bother with managing your own saved copy of the screen...

Rory


On 10/25/07, darren@xxxxxxxxx <darren@xxxxxxxxx> wrote:
> Thank you for the response.  I cannot reconstruct the screen, because I
> filter out a lot of data I'm not interested in, for example, field
> attributes and definition.  You ask if dealing with the SAVE/RESTORE
> screen
> is really required, and I think you're on to something there.  I can
> virtually ignore these requests, and the application keeps chugging.  The
> downside, is that the buffer I get back right after the RESTORE SCREEN and
> WRITE TO DISPLAY is a little funky, but perhaps I can respond with a blank
> screen on the READ SCREEN request to purge the buffer.  I could then
> manage
> a saved copy of the screen on my own end to construct a somewhat accurate
> representation.
>
>
>
>
>
>
>             Scott Klement
>             <rpg400-l@scottkl
>             ement.com>                                                 To
>             Sent by:                  RPG programming on the AS400 /
>             rpg400-l-bounces@         iSeries <rpg400-l@xxxxxxxxxxxx>
>             midrange.com                                               cc
>
>                                                                    Fax to
>             10/25/2007 01:04
>             PM                                                    Subject
>                                       Re: Scrape 5250 to 5250 with help
>                                       from DSM?
>             Please respond to
>              RPG programming
>              on the AS400 /
>                  iSeries
>             <rpg400-l@midrang
>                  e.com>
>
>
>
>
>
>
> Hi Darren,
>
> Just to see if I understand...   You're using the VT APIs to interact
> with an existing 5250 application.  In your program's memory, you've
> constructed a buffer that acts as a "virtual screen" so that, as your
> program receives data from the server, it knows what's on the screen and
> can respond to it, correct?   When you receive a SAVE SCREEN command
> from the server, you have to re-construct the 5250 datastream for your
> virtual screen buffer, and you'd like to use the DSM APIs to do that?
>
> As far as I know, this isn't possible.  IBM provides a means of getting
> a pointer to an *input* buffer, but does not give you access to the
> contents of a command buffer.  So I think you're out of luck.  You'll
> have to reconstruct the 5250 data stream manually.
>
> On the other hand -- AFIAK, the RESTORE SCREEN command simply sends back
> whatever you sent to the system in the SAVE SCREEN command.  I've always
> constructed a 5250 data stream in response to SAVE SCREEN, but is it
> really required?  I wonder.  Maybe you can get by with just sending your
> buffer (just a binary dump of it) to the server, and restoring it
> directly...   Not sure if it would work, but it'd be relatively easy to
> try...
>
>
> darren@xxxxxxxxx wrote:
> > Question first:
> > Is it possible to use the DSM API's to interact with a buffer that is
> > not actually attached to an active 5250 session?  I see lots of talk
> > about buffers in these API's, and I'm wondering if it would be legal
> > to pass 5250 data back and forth to a buffer in these API's but to
> > not have a terminal screen to display it.  Things like the 5250 SAVE
> > SCREEN and RESTORE SCREEN functions are of particular interest.
> >
> > Background:
> > I think I'm almost to completion on a project to scrape 5250 screen
> > data, as its generated in another virtual session, interpret that in
> > a local application, and respond back.  To do this, I'm using the
> > Virtual Terminal API's, ie. QTVOPNVT)  My reasoning is to alter the
> > interface to a 3rd party ERP package, without access to the source.
> >
> > Things have gone pretty well.  My service program returns a picture
> > of the screen as its parsed from the 5250 datastream, and then I send
> > a response back.  I've run into an issue with the SAVE SCREEN and
> > RESTORE SCREEN commands.  Since I don't have the actual screen
> > rendered anywhere on a 5250 screen, its difficult to respond to these
> > requests.  It would also be nice if there was a more structured way
> > of interpreting the screen, rather than parsing through the raw 5250
> > stream as it comes out of QTVRDVT.  I'm hoping that DSM might help
> > with this too.  But, I'm not familiar enough with DSM to know whether
> > its smart enough to work on a virtual buffer, rather than a real 5250
> > interpreter.
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
>
>
>
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.