Re: Problems using api's qmhsndpm amd qmhrcvpm

> My 2 programs are attached . they are just spool files copied to
> desktop. If they do not appear properly go to format and uncheck word
> wrap.

Huh?  Are you assuming that everyone uses the same e-mail client that you
do?!

> I have been using the AS/400 Programmer's Handbook and Api's at Work, in
> addition to searching everywhere I can think of on the net.
>
> There seem to be no good examples of using qmhrcvpm.
>
> Basically I seem to be getting nothing back to my base program . CSUPDT.
>
> It is highly like I am using Monitor improperly, but no good examples of
> that either. Or maybe I should not be using monitor.
> But if I don't, I get system forced messages.
>
> Any help would be appreciated, no snickers allowed.
> For some reason this is just not coming together for me.

Are you sure that escape messages will even work for this task?

Sending an escape message is intended for when a program calls another
program.  If the second program ends abnormally, it uses an escape message
to trigger an exception to the caller.  If the caller doesn't catch that
exception, then it will also crash, and the cycle continues until either a
program handles the error, or you get back to the command line.

However, in your case, what you've got is the operating system running a
routine to update/insert a record in your database.  You see, when you
tell your RPG program to update or write a record, it calls a DB2/400
routine in order to do the actual work. That DB2/400 routine will,
eventually, call your trigger program.

So, your program stack at the time that the trigger runs will look
something like this:

1  P_PEP_CSUPDT  <-- ILE program entry procedure for CSUPDT
2  CSUPDT        <-- ILE procedure CSUPDT
3  _DB_UPDATE    <-- database update routine
4  QDBUDR        <-- routine called by database update
5  _TRGCSDELR    <-- entry procedure for trigger
6  TRGCSDELR     <-- the trigger's main procedure

(You can see the actual stack at the time the trigger fires by adding a
QCMDEXC call in your trigger that does DSPJOB OPTION(*PGMSTK)... just for
debugging purposes, mind you...)

So, if you want TRGCSDELR to send an escape message to CSUPDT, it needs to
send it back 4 call stack entries.  That means that your SMStack# variable
must be set to 4, rather than the 3 that you have it set to.

There are a few things to keep in mind, however, when using *ESCAPE
messages:

1) Escape messages will end all call stack entries that are at the same or
later in the call stack.  So, issuing an escape message from TRGCSDELR
will end TRGCSDELR, it's entry procedure, QDBUDR, and _DB_UPDATE.  If
there were tasks that any of those things needed to do before the
call-stack is ended, it could be a problem.  You need to make sure that
the update/write database routines are designed for this sort of thing.

2) You can't control how many different callstack entries IBM will use in
it's database routines.  So, although the number 4 might work today, it
might break in V5R3.  Or V5R4.  Or V6R1... or at some unspecified time in
the future.  This is one big disadvantage of using a call stack entry
count to determine where the message goes.

3) The QMHRCVPM (Receive program message) API receives *ESCAPE messages in
LIFO order.  LIFO = Last In, First Out.  So, if your routine sends a
CPF9898, and then due to it's call-stack entry ending, the database
routine sends an RNX1299, the program will first receive the RNX1299 and
then receive the CPF9898.

You can call QMHRCVPM in a loop in order to search through all of the
messages, looking for your CPF9898.  Just be very careful to make sure
that your program won't go into an infinite loop if the CPF9898 isn't found.

The following logic is from a program of mine where it searches for
CPF9897 (which is identical to CPF9898, except it has to period at the
end):

  * check the last 5 messages in the program message queue
  * for CPF9897:
 c                   eval      wwMsgKey = *ALLx'00'
 c                   eval      wwMax = 5

 c                   dou       dsM1_MsgID = 'CPF9897'
 c                                or wwMax = 0
 c                   callp     QMHRCVPM( dsM1
 c                                     : %size(dsM1)
 c                                     : 'RCVM0100'
 c                                     : '*'
 c                                     : 0
 c                                     : '*PRV'
 c                                     : wwMsgKey
 c                                     : 0
 c                                     : '*SAME'
 c                                     : dsEC)
 c                   eval      wwMsgKey = dsM1_MsgKey
 c                   eval      wwMax = wwMax - 1
 c                   enddo

  ** retrieve message data so that it can be printed on the screen
 c                   if        wwMax > 0
 c                   eval      wwMsg = %subst(dsM1_Dta: 1: dsM1_DtaLen)
 c                   endif

And YES, you do need the monitor op-code (or equivalent) in order to
handle an escape message.  otherwise your program will come crashing down
when the escape message is received...

Hope that helps...