|
On 19/07/2005, at 1:05 AM, Wilt, Charles wrote:
Since the I/O service program doesn't know where it could be call from, ideally the SndErrMsg() program needs to determine where the message should be sent.
Easy. Pretend the ILE call stack doesn't exist and send all messages to the program entry point. Use *PGMBDY.
However, so far, I've been unable to get even a hard coded test case working.Some areas I'm wondering about:1) Behavior difference between DDS SFLPGMQ(10) and SFLPGMQ(267) when program is ILE?
SFLPGMQ(267) is wrong. You probably mean SFLPGMQ(276) which simply allows a fully qualified ILE procedure name. You can ignore this if you use *PGMBDY and keep using the SFLPGMQ(10) definition.
2) Behavior difference between '*' and the *PROC name from program status DS when loaded to SFLPGMQ field.
I presume you mean '*' for the call stack entry on the QMHSNDPM API? If so then that means the call stack entry of the function that invoked QMHSNDPM. In other words the caller of QMHSNDPM.
*PROC is the name of the procedure where the SDS is defined. Because an SDS is generally defined at the global level *PROC equates to the name of your program (equivalent to *PROGRAM in RPG III) but it could be a real procedure name.
In your case '*' equates to SndErrMsg and *PROC equates to something else.
3) Does it matter where (mainline or sub-procedure) the error message subfile control record is written or when the SFLPGMQ field is loaded.
No. What matters is that the call stack message queue named in SFLPGMQ is the same as the call stack message queue where the messages are sent.
Of course, the SFLPGMQ field has to be loaded before you write the message subfile control record.
4) What the heck do *PGMBDY, *PGMNAME, and *CTLBDY mean in English?
*PGMBDY means where a new program is called.*CTLBDY means activation group boundary. It will be the same as *PGMBDY if the program has a *NEW activation group and any service program sending the message has *CALLER activation group. Valid only if ILE objects are active in the call stack.
*PGMNAME means same as *PGMBDY for OPM but for ILE means the most recently called (i.e., lowest) PROCEDURE found in the named PROGRAM or SERVICE PROGRAM (optionally qualified by MODULE). This seems insane and I've not found any use for it.
Does anybody have any tips/tricks/info that would help?
For ILE programs always use *CTLBDY and 0 relative invocation number when sending messages for display in a subfile. Set the SFLPGMQ value to the *PROC variable value. Life should be grand. When sending messages for display at a previous level use *CTLBDY and 1 relative invocation number and let the receiver worry about what happens.
For OPM use * and 0 relative invocation number when sending messages for display in a subfile. Set SFLPGMQ value to the *PROGRAM variable value. When sending messages for display at a previous level use * and 1 relative invocation number and let the receiver worry about what happens.
These guidelines will handle most cases but in some instances you will have to mess with either the call stack entry name, the relative invocation number, or the program/service program, module, procedure values.
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
