Re: Scrape 5250 to 5250 with help from DSM?

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.