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

["M. Lazarus" <mlazarus@xxxxxxxx>]

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@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx] On
> Behalf Of CRPence
> Sent: Monday, May 10, 2010 8:36 PM
> To: mi400@xxxxxxxxxxxx
> 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