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

Dave,

  You may want to look into the DSM APIs.  They are quite 
comprehensive when it comes to screen retrieval and manipulation.

  -mark


At 5/11/10 04:01 PM, you wrote:
>Hi Chuck,
>
>Thank you for the response, you provided me with a lot of food stuff.  I
>did try the QsnGetAID as you suggested, and when called it seems to want
>to wait on the user to input a Function key, but it was worth a shot.
>
>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, 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.
>
>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.
>
>I greatly appreciate your response and effort.
>
>Dave
>
>-----Original Message-----
>From: mi400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected] [mailto:mi400-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On
>Behalf Of CRPence
>Sent: Monday, May 10, 2010 8:36 PM
>To: mi400-Zwy7GipZuJhWk0Htik3J/[email protected]
>Subject: Re: [MI400] Question about accessing internal object *PTCSPC
>programmatically from my job
>
>Dave Fiorillo wrote:
> >
> > <<SNIP>>
> >
> > I have been "challenged" to find a way to determine from a
> > program that gets called to be able to figure out what the last
> > function key was that was pressed.  I cant use the INFDS
> > directly, because I am running in a different program than the
> > program where the DSPF is defined (DDS), and the handling of the
> > function key being pressed.
> >
> > For example, Program A has the logic that when F9 is pressed -
> > then call program B - and I am program B.   So, in Program B I
> > want to be able to retrieve from memory what was the last
> > function key pressed in Program A.  It's OK if I have to tell
> > Program B the name of the display file for now, but phase 2 might
> >  be nice to be able to figure out the last display file used.
>
>    By "tell program-B" does that mean a constant would be coded?  Or
>perhaps that it means program-A can be changed to pass the name of
>the display file?  If the latter, why not just pass the function key
>that was pressed, instead of the display file name?  Or better, why
>not just change program-A to do the more obvious thing, and just ask
>of program-B, to do what program-B would apparently decide to do if
>it knew that F9 had been pressed?
>
>    Regardless, there is the Retrieve Output Information (QWSRTVOI)
>API which might be able to assist to determine the last DSPF record
>format processed.
>http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwsrt
>voi.htm
>
> > What I have been able to figure out so far, by using DMPJOB, is
> > that when I search on the DSPF name in the dump, I can
> > consistently see a space defined with the identifier of "19 FC"
> > for the display file used in program A, and at offset x'7D3' from
> >  this particular section is the AID byte of the function key.  I
> > am assuming that this is the place in memory of the job that
> > stores the INFDS for program A.   I tried this with 5 different
> > function keys and got consistent results with the AID byte so I
> > am very hopeful that this is the sweet spot in memory (at least
> > for V5R4).
> >
> > My question:  is there an easy way to access this information
> > using MI? From my research so far, I have learned that a "19 FC"
> > is a *PTCSPC internal object to the job, and I keep scouring the
> > dump to try and glean more information.
>
>    IIRC that is a "protected space" object, for which I believe the
>term /protected/ implies the space is always in the system domain,
>so only a system state program can "touch" the storage.
>
> > Any help from the experienced would be greatly appreciated.
> >
>
>    If one were so inclined to so tightly entwine a called program
>with its caller, as if the caller could not just request the called
>program to do what is required or have a stateless callee, then
>perhaps...
>
>    Does the Get AID (QsnGetAID) API handle the request directly when
>passing in null inputs, even though there may not be a DSM environment?
>http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/QsnGe
>tAID.htm
>
>    FWiW, for just the manner in which an interactive application
>panel\display is exited, via F12 "return key" or F3 "cancel key", is
>available in a couple of other APIs; QUSRJOBI & QWCRTVCA.  QWCCCJOB
>API is used to set the value in a user application.  My unattributed
>code snippet & text:
>http://www.as400network.com/clubtech/TNT400/bo400ng/as400qrykey.htm
>    The APIs:
>http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qusrj
>obi.htm
>http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwcrt
>vca.htm
>http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwccc
>job.htm
>
>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.