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
_______________________________________________
This is the MI Programming on the AS400 / iSeries (MI400) mailing list
To post a message email: MI400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/mi400
or email: MI400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/mi400.
midrange.com
