Re: Scrape 5250 to 5250 with help from DSM?

[Pete Helgren <Pete@xxxxxxxxxx>]

Darren,

If you hadn't said "I think I'm almost to completion on a project to 
scrape 5250 screen data" and if you were familiar with Java or had 
access to someone who was, I would have pointed you to the tn5250j open 
source project that basically built an object oriented 5250 browser.  It 
has a 5250 protocol bean that is particularly useful for this kind of 
stuff (I used it for the web5250 project).  Though this post is OT from 
your particular post, I stuff it in here so that if you come to a dead 
halt, or want an alternative approach, you could check out tn5250j and 
work with some Java experienced person in your shop (if you have one) to 
wrap it in RPG.

One option if you get completely stuck.

Pete Helgren

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.
>
>
>
>
>