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
_______________________________________________
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.