Hi Simon,
Thanks for the helpful info. I should have stated in my original post
that I cannot modify "Program A" because it is intended to be a
customers "canned" application, like BPCS, MAPICS, Infor, SimonSoft:),
etc... I am trying to ultimately snap myself in as a true "no
programming" solution.
SO, the plan is to configure my program as a trigger program (and be
called that way), and when called I can sniff out the screen, function
key pressed, snapshot of the screen, etc... and perform some execution
based upon analysis of collected data. I already have an application
where users can build a screen template over their applications screen,
and tell me where key pieces of info are located on the screen, and
using the DSM Apis I can retrieve those when I get called (even from the
trigger). Currently, I have an option where my app is fired using the
pre-attention key exit point, but now we want the option to run from a
db trigger also.
Initially, I felt it would be much easier to explain the
ProgramA/Program B scenario, and actually research/develop this
component of my system using this simple model first. However in the
end, the db trigger program is going to be the model I will try to
implement.
So when the trigger program (ME) gets called, IF I have the ability to
know that the file is being updated due to being on a particular screen,
after a particular FKEY is pressed, and conditions on the screen match
the conditions that are setup in my template, then I can execute (or
simply return) when deemed appropriate and tie my application into
whatever application my customer is running, without them having to do
any coding changes at all.
That's pretty much the overview, I hope I explained it ok.
I believe that the chain of WCB->DMCQ->ODP->I/O Feedback route is the
path I must take here, I am unable to access Leifs page here from work
(it's considered a social networking site according to my work's filter?
- must be a pretty groovy group involved lol). But I will check it out
from home.
I guess the system state access could be a showstopper - I was really
hoping that MI could help me bridge the gap to retrieve that information
without having to have to deal with the program state.
Your help and insight is much appreciated.
Dave
-----Original Message-----
From: mi400-bounces@xxxxxxxxxxxx [mailto:mi400-bounces@xxxxxxxxxxxx] On
Behalf Of Simon Coulter
Sent: Monday, May 10, 2010 7:04 PM
To: MI Programming on the AS400 / iSeries
Subject: Re: [MI400] Question about accessing internal object
*PTCSPCprogrammatically from my job
On 11/05/2010, at 8:06 AM, Dave Fiorillo wrote:
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.
Umm ... if you're PGMB and PGMB is called when F9 is pressed then
surely you can infer that F9 was pressed in the caller but really why
do you care? PGMB has been invoked so it should do whatever it is that
it does. Why does it matter which F-key was used to invoke it?
That's a serious question because if we know WHY you're trying to do
something we may be able offer a different (better) solution.
Its 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.
Information about the last display file is easy. See the QWSRTVOI
(Retrieve Output Operation) API.
The Work Control Block (or PCO Associated Space) of the job has some
of this information at position x'451' but the API is the approved
mechanism.
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).
I think you're finding the pointer to the ODP of the display file in
the Data Management Communications Queue.
Leif's MI Book has some information on the DMCQ including how to walk
the ODP chain. See:
http://www.leif.org/as400/
You can compare the layout of the data you've found with the Feedback
structures described in the (I keep thinking Appendix A. of the Data
Management Guide because that's where it used to be) buried in the
Reference Chapter of the Database File Management manual.
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.
Easy is such a relative term. As far as I know there is no MI
instruction to materialise the information you want, nor is there an
API, so you'll have to follow the chain of WCB->DMCQ->ODP->I/O
Feedback and you'll need system-state to access these objects so if
you're after a commercial solution then I suspect you'll need to find
another way.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
_______________________________________________
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
