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

CRPence <CRPbottle-/[email protected]> Wed, 12 May 2010 09:52:58 -0500
Newsgroups gmane.comp.lang.as400.mi
Organization midrange.com
Message-ID <[email protected]>
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
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mi400.