× 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.



Scott,

thank you very much for that lesson. It was clear enough also for people
like me, who uses English occasionally only for reading manuals.
Many thanks once more for spending your time. Hope to get a chance for
paying back.
Kind regards,
GEFIS Gesellschaft für
Individual-Software mbH
Werner Noll

-----Ursprüngliche Nachricht-----
Von: Scott Klement [mailto:klemscot@klements.com]
Gesendet: Freitag, 11. Oktober 2002 11:44
An: 'rpg400-l@midrange.com'
Betreff: Re: AW: locked record




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.

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.