Re: Question about accessing internal object *PTCSPC programmatically from my job

Dave Fiorillo wrote:

<<SNIP>>

Not sure how these forums work (I've been living in the dark
ages) so if this response is duplicate of what I replied to Simon
I apologize,

The message would be an effective duplicate then. See the archive:
http://archive.midrange.com/mi400/201005/msg00017.html
http://archive.midrange.com/mi400/201005/threads.html#00017

However, because the original /long/ subject line caused your email [I infer not a newsreader] client to reformat the Subject line on the reply, effectively having removed a space\blank character [probably as side effect of having replaced it with a CRLF and that probably from the forum software removing that CRLF], the message did not properly thread in my NewsReader Client; it did thread properly in the archive. Consider posting with subject lines that do not exceed the default wrap width for your email client's subject line, or configure the client not to wrap the subject line into more than one line.

but basically "Program A" is the customer's program
and I cannot modify it. I plan to put myself into the picture
ultimately as a trigger program in this instance, and when called
as a result of the db operation collect a bunch of data -
screensnapshot, function key pressed, anything else, and then
execute based on analysis of this collected data.

Ughh. A database file trigger being used as a means to implement a stealth screen scraper.? Imaginative, but hardly something that I would describe as an worthwhile approach. Knowing about the screen activity only when a database I\O occurs does not seem very complete since not every, even possibly very few, interactions will necessarily effect a database I\O. And what if one F-key activates many I\O versus just one? Seems like a lot of assumption about the workings of an unknown underlying application will lead to endless difficulties like for most screen scraping concepts.

I think my next step need to be to see how deep into memory I can
get by chaining my way through the job's memory by using the MI
calls. I have a feeling that I might find some locked doors along
the way, but I will keep you posted how it goes.

If you will want to run the program on a system with QSECURITY above level-30, then the program will need to be created on that system and\or patched to run in system state on that system. That will likely be a locked door encountered; might be worth knowing how that issue will be bypassed, before spending much [more] time trying to figure out the other stuff.

Regards, Chuck