Re: 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/qwsrtvoi.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/QsnGetAID.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/qusrjobi.htm
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwcrtvca.htm
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/qwcccjob.htm

Regards, Chuck