|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
