× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Fri, 11 Oct 2002, Werner Noll wrote:
>
> Just one question on that:
> How do you identify/specify the input parameter (stack counter), which is
> apparently passed for the QMHRCVPM API.
> I didn't understand the meanig of it although I read IBM's API description.
> Can you explain it in other words?
>

Hmmm..  I'll try.  Each time a new program is run by a job, it is added
to a stack, called the "call stack."  The "stack count" parameter tells
which stack entry's message queue should be checked for the message.

For example, you might have:

      1) An OPM CL program (created with CRTCLPGM) called PGMA might
             call another OPM CL program called PGMB.
      2) PGMB might call an ILE RPG program called PGMC.
      3) PGMC chains to a record.  When the chain fails because the
            record is locked, it calls a subprocedure called
            DISPLAY_RECORD_LOCK which will pop up a message showing
            the job that locked the record.
      4) DISPLAY_RECORD_LOCK will call the UTIL_LOCKINFO subprocedure
            to get the job name so it can include that in it's
            pop-up message.

So, when UTIL_LOCKINFO is called, the call stack will look like this:

   1   PGMA
   2   PGMB
   3   P_PEP_PGMC
   4   PGMC
   5   DISPLAY_RECORD_LOCK
   6   UTIL_LOCKINFO

When the chain to the record failed, the operating system wrote message
CPF5027 ('Record x in use by job x/x/x')  into the program message queue
for PGMC  (which is call stack #4).   The UTIL_LOCKINFO subprocedure
needs to know which call stack entry to search for that message.

So, when you call UTIL_LOCKINFO you specify a count of "how many" call
stack entries are between UTIL_LOCKINFO and the entry where the message
was received.

In this example, you'd specify 2.   UTIL_LOCKINFO would look two entries
earlier in the call stack.

However, if you decided that you didn't need a seperate
"DISPLAY_RECORD_LOCK" subprocedure, and simply called UTIL_LOCKINFO
directly from PGMC, your call stack would look liek this:

      1  PGMA
      2  PGMB
      3  P_PEP_PGMC
      4  PGMC
      5  UTIL_LOCKINFO

And in that case, you'd specify 1 for the call stack count, since you're
only one level removed from where the message was sent.

You can display the current call stack for your job by doing a
DSPJOB  and selecting option 11.   Or, you can display the call stack of
other active jobs by doing a WRKACTJOB, putting a 5 next to the job to
work with, and then selecting option 11.

I hope that explanation helps.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.